では、#devsumi 2014 初日に行ってきた（前編）
正直、お世辞にもわたしが参加してきた #devsumiE のトラックはあまり個人的には新しい収穫はなかったなぁと思っているんですが、折角とってきたメモですので、公開しておきます。
わたしが参加した #devsumiE トラックのセッションは以下の 3 つのセッションです。
- 【13-E-4】「さくらのクラウド」開発と運用、裏話的な何か 鷲北 賢氏 〔さくらインターネット〕
- 【13-E-5】Stormで実現するビッグデータのリアルタイム処理プラットフォーム 鈴木 貴典氏 〔Acroquest Technology〕
- 【13-E-6】～非常事態で慌てないために～自在にスケールするクラウド・インフラを作るためのベスト・プラクティス Phil Jackson氏 〔SoftLayer〕
では、以降がわたしが各セッションで取ってきたメモです。
14:10～14:55 【13-E-4】「さくらのクラウド」開発と運用、裏話的な何か 鷲北 賢氏 〔さくらインターネット〕
- さくらのクラウドの開発の裏側
- 中間管理職的 PM の立場からの紹介
＊＊＊＊＊
- @ken_washikia
- 199804 入社
- さくらインターネット研究所、所長
- 仮想化技術の研究等々
＊＊＊＊＊
さくらインターネット
- ハウジング
- レンタルサーバ
- 専用サーバ
- VPS
- クラウド (IaaS)
＊＊＊＊＊
さくらのクラウド開発に至る経緯
- 200905 、さくらは VPS はやらないと宣言したが
- 現実、社内に仮想化サービスを検討するプロジェクトは皆無だった
- Xen のファンだった一部エンジニアは隠れて使うようになった
＊＊＊
- 200907 に研究所設立
- 面白いと思ったことはなんでもやるというモットーを掲げた
- そこで選んだのが仮想化技術の研究だった（やらないとまずいだろうという危機感）
＊＊＊
- 2009 ごろの事情
- EC2 がすごいと評判に
- クラウド破産の例も
- ただサーバつくって消してはが楽しいという雰囲気→データセンター事業者としては陥りやすい罠
＊＊＊
- 仮想化されたサーバサービスはすごい
- 時間単位でサーバが借りられる、これだけでも破壊的
- どうやってサービスを実装しているか想像するだけでも楽しい、恐ろしい
- まじめに取り組まないととてもじゃないがつくれないと焦った
＊＊＊
- さくらインターネット研究所の方針（3つのテーマを掲げた）
- サーバ仮想化
- Linux KVM
- ネットワーク仮想化
- NW 設計は独自に
- ストレージ仮想化
- 痛い目にあう原因に
＊＊＊
- 201001
- 社長が突然にクラウドをやろうといいはじめた
- 社長がいうからにはがんばらないといけないということになった
＊＊＊
- さくらインターネットのこわいところ
- 日曜プログラミングの延長で社長がプロトタイプをつくってきちゃう
- エンジニアは逃げ場がなくなる
＊＊＊
- さくらの VPS プロジェクト発足
- HW の選定と構築
- コントロールパネルと課金体系構築
- 研究所の役割
- KVM の性能評価と EC2 との比較はすでにレポート化していた
- スーパーバイザーとしてミーティングに参加する程度だった
＊＊＊
- 201009 VPS 正式サービスに
- 6ヶ月でサービスにこぎつけた開発部すげー、と
- 現在 VM で 50,000
＊＊＊
- 20110302
- AWS 東京リージョンのローンチ
- 研究所と新規事業質でクラウドつくってくれない？と社長からいわれた
- 本来は開発部の仕事だったが、 VPS に手一杯だった
＊＊＊
- VPS ではクラウドと呼ぶのには足りない部分を補っていくことをミッションとした
- NW 柔軟性がない
- ストレージも固定化、不便
- 時間課金できない
＊＊＊
- さくらのクラウド、システム概要
- NW (ホストサーバ、ストレージ)
- UI - API - DB
- 課金システム
- 販売管理システム
＊＊＊
開発チーム体制とスケジュールの紹介
- 開発の流れとメンバーの役割
- NW 基本設計はできていた
- ホストサーバは VPS の運用実績をもとに再設計
- API と DB はプロトタイプをベースに再設計
- 課金システム
- さくら社内では一番の課題
- 時間課金がネックだった
- UI は自由度 MAX で
＊＊＊
- 最初はサーバ 120 台から
＊＊＊＊＊
リリースとその後の開発状況
- 石狩データセンターの開設にあわせたローンチが決定、てんてこまい
- リリースは無事に出来たが、直後にトラブル
- 予想以上のユーザ増加、ストレージが悲鳴をあげた
- ストレージのシステムは作りなおすことに
- 大型ストレージシステムから、小型ストレージシステムへ転換
＊＊＊
- 機能追加、増強の内容の紹介
- 2014 だと
- スタートアップスクリプト
- 新コンパネ
＊＊＊
- システム俯瞰と運用のポイント
- ギリギリ純増だが、つくられるインスタンスと壊されるインスタンスがほぼ同じくらい
＊＊＊
- 運用の話
- 物理構成のスライド（スキップされてしまい、ほとんどみれなかった）
- クラウドによる運用の変化
- 仮想リソースの障害＝設定・ SW の問題
- 自動化・ツール化が容易
- しかし、課題はまだまだ多い
- サービス開発と運用ツール作成が並行している
＊＊＊
- 物理構成とクラウドは非常に様相が異なる
- 1点の物理障害が、クラウドのどんな障害につながるか非常にわかりづらい
- 極力 SPOF をなくす
- すべてのコンポーネントを監視する
＊＊＊
- 運用体制について
- NW機材は楽
- だが、ストレージは課題
所感
- さくらのクラウドができるまでの背景に終始されてしまったのが残念。
- おそらくみんなが聞きたかったのは最後の方にすっとばされてしまった運用の裏話のほうだったのでは、と。
15:15～16:00 【13-E-5】Stormで実現するビッグデータのリアルタイム処理プラットフォーム 鈴木 貴典氏 〔Acroquest Technology〕
スライドはこちら
- @takaorig
＊＊＊＊＊
- ビッグデータとリアルタイム
- In 60 Sec でなにが起こっているのかという例 - facebook, twitter, skype, etc...
- なぜリアルタイムが必要なのか？
- Internet of things - センサーなどがネットワークに繋がったりと機器が増えている
- ビッグデータ関連プロダクトのパラダイム
- Google GFS
- MR
- BigTable
- Google Percolator, Dremel
- OSS の流れ
- Hadoop
- HBase
- Twitter Storm
- Drill
- ビッグデータとリアルアイムに今後求められるもの
- 不正利用、不正アクセス
- センサーデータ
- 緊急災害時の対応
- ユーザの直近の行動に基づくサービス向上
- ビッグデータ処理のみっつのタイプ
- Batch : MR
- Query : OLTP
- Stream : Stream Processing Latency は上になるほど高 要件に応じて単体もしくは組み合わせて実行
- タイプ的に代表的なプロダクト
- バッチ処理： Hadoop
- インタラクティブクエリ：Drill, Impala, String, Presto
- ストリームデータ処理： Storm, Spark Streaming
- ストリームデータ処理とは？
- 基本的には連続的に発生し続けるデータを処理し続けること
- センサー、ログ、 SNS
- ストリームデータ処理の適用モデル
- 大量データの事前処理
- リアルタイムデータ集計
- センサーデータの集計分析
- セキュリティ
＊＊＊＊＊
ストリームデータ処理を実現する Storm
- Storm とは？
- 分散し、耐障害性の高いリアルタイム処理システム
- Twitter の OSS
- 20130918 より Apache Incubater
- ストリームデータ処理の代表的なプロダクト
- 導入事例
- GROUPON, OOYALA, Twitter, アリババ etc...
- Storm の7つの特徴
- 簡単な統合 MessageQ や NoSQL との組み合わせが容易
- シンプルな API
- スケーラブル
- 耐障害性
- 欠損のないデータ処理 処理の失敗を検知し、再処理を自動的に実行
- 複数の開発言語のサポート
- 簡単なデプロイ・運用
- Storm Cluster : 物理構成
- Nimbus (master node)
- Zookeeper (cluster の協調処理)
- Supervisor
- そのなかに Worker (実際の処理を担当)
- 最小の実行単位は Executor
- そのなかに Worker (実際の処理を担当)
- Storm Topology (論理構成)
- Spout : Stream のデータソースを Tuple として創出
- Bolt : Steram から Tuple を受信し変換・加工する
- Storm Key features
- Stream Grouping
- Disributed RPC
- Transactional
- Trident
- Metrics
- Storm のパフォーマンス
- 300,000 Tuples/Sec (EC2, c1.xlarge)
- 1,640,000 Tuples/sec (On the node of Twitter Cluster)
＊＊＊＊＊
ストリームデータ処理のアーキテクチャ
- 検討ポイント
- 大量データの収集方法
- 増減するストリームデータへの対応
- 分散処理および分散の単位
- 中間データの扱い
- 基本的なアーキテクチャ
- データ発信元
- データ受信部（受信、または収集: Kafka, fluentd）
- メッセージキュー : データの増減に柔軟に対応
- データ処理部 : ここは Storm がやってくれるところ
- 最後にデータの永続化、またはキャッシュ用データストアに保持
- 事例： infochimps 者のリアルタイム分析サービス
- 政府系からビジネス系まで
- 事例： Loggy 社のログマネジメントサービス
- Kafka + Storm + Elasticsearch
- 事例： Cloudn 、クラウド上でセンサーデータのリアルタイム判定＋集計
- Something + Storm
- Storm on YARN
- Amazon Kinesis + Storm Storm でオンライン機械学習 Stream-ML
- 自社プロダクトの紹介
- AcroMUSASHI Stream
- モチベーション
- イベント処理→CEP→機械学習
- スケーラブルで高信頼性のリアルタイムで使える機会学習のための機能が欲しかった
- 特徴
- スケーラビリティを備えた高速分散処理
- 機械学習のアルゴリズム単体ではなく、、、（書けなかった） バッチとリアルタイムのハイブリッド
- ラムダアーキテクチャ (バッチ x ストリーム)
- 関係する OSS
- Hadoop, SploutSQL, ElephanDB, HBase, Cassandra, Srorm, Impala
＊＊＊＊＊
本日のまとめ
- ビッグデータ処理はリアルタイム性が求められるように
- Storm はそれを実現するひとつのフレームワーク
- Storm の応用範囲は広い
所感
- devsumiE トラックでは一番安定した内容のセッションだったかな、と。
- 自社製品のプロモの側面が強かったのかな、とは思いますが。
16:20～17:05 【13-E-6】～非常事態で慌てないために～自在にスケールするクラウド・インフラを作るためのベスト・プラクティス Phil Jackson氏 〔SoftLayer〕
Best Practices in Scaling Cloud Architectures
- @underscorephil
＊＊＊＊＊
SOFTLY-R
- 100k servers
- 21k customers
- 20 M domains
＊＊＊＊＊
- Softlayer Portal & Customer App
- Softlayer API
- Softlayer Infra
＊＊＊＊＊
- Design
- The most significant change is Cloud movement
- Capacity planning, typical analogy is like road
＊＊＊＊＊
- Different Class Apps
- Enterprise apps
- Internet scale apps
＊＊＊＊＊
- Internet scales?
- tumblr's scale example
- 51 M blogs
- 57 M daily posts
- 21 B reblogs ** OMGPOPS example
- tumblr's scale example
＊＊＊＊＊
Scenario - video transcoding publishing service
- introduction of tHe speaker's product
＊＊＊＊＊
- Keeping things simple - that is the principle.
- Sateless
- Asynchronous
＊＊＊＊＊
- Devided the process each one can work independently.
- Finally combine the result using message queues.
＊＊＊＊＊
- Scaling
- TRTFTJ - The Right Tool For The Job
- Analyze the system and decide with you scale the system horizontally or vertically.
＊＊＊＊＊
- PODs
- Portable Organizational Deployment
- Measure the each of POD, how much workload that of POD enable to handle.
- And then decide how many PODs to add when the workload become more higher.
- Portable Organizational Deployment
＊＊＊＊＊
- Bottlenecks
- key point need to find first.
＊＊＊＊＊
- DR
- Redundancy / HA
- It's the const trade off.
＊＊＊＊＊
Summary
- Keep it simple
- Keep it async etc...
所感
- 日本語で所感を書いてしまってもうしわけないのだが、正直、論点がよくわからなかった。（一応、英語でわたしは聞いてた）
- タイトルから期待していることはほとんど喋っていなかったように思います。
- とくにカンガルーの話は一体何だったのか…
と以上で、わたしが参加してきた #devsumi 2014 のセッションのメモの公開は以上です。
ちょっとした感想のようなものをあとで追記しようとは思いますが、とりあえず、今はここまでにしておこうと思います。
では、今はこんなところで。
