ストリーミングアーキテクチャ: State から Flow へ

ビッグデータの処理モデルとしては、最近までバッチ処理が中心でしたが、最近 Apache Spark や Apache Kafka のようなストリーミングアーキテクチャを採用する例が出てきています。これらはシステムをシステムをシンプルかつロバストにするという観点で大きなメリットがありますが、一方で従来のメッセージキューイングの設計と大きな違いがあります。この講演では、いくつかのストリーミングシステム特有の考え方や設計パターンを例に挙げながら、モダンなストリーミングシステムの構築の指針をご紹介します。2016年2月8日に開催されたHadoop / Spark Conference Japan 2016での講演資料です。

Transcript

1. ® © 2016 MapR Technologies 1 ® © 2016 MapR Technologies 草薙 昭彦, MapR Technologies 2016 年 2 ⽉ 8 ⽇
2. ® © 2016 MapR Technologies 2 ⾃⼰紹介 •  草薙 昭彦 (@nagix) •  MapR Technologies データエンジニア NS-SHAFT 無料!
3. ® © 2016 MapR Technologies 3
4. ® © 2016 MapR Technologies 4 ストリーミングの5つの⾒かた •  エンタープライズ・チーム •  マイクロサービス •  アブストラクト・コンピューティング •  結果の配送 •  統合
5. ® © 2016 MapR Technologies 5 File upload web service Files Thumbnail extraction Transcoding uploads thumbs recodes Files
6. ® © 2016 MapR Technologies 6 File upload web service Files Thumbnail extraction Transcoding uploads thumbs recodes Files 映画「羅⽣⾨」あらすじ 都にほど近い⼭中で、貴族の⼥性と供回りの侍が⼭賊に襲わ れた。そして侍は死亡、事件は検⾮違使によって吟味される 事になった。だが⼭賊と貴族の⼥性の⾔い分は真っ向から対 ⽴する。検⾮違使は霊媒師の⼝寄せによって侍の霊を呼び出 し証⾔を得るが、その⾔葉もまた、⼆⼈の⾔い分とは異なっ ていた…
7. ® © 2016 MapR Technologies 7 第1話 エンタープライズの盗賊 The enterprise bandit
8. ® © 2016 MapR Technologies 8 巨⼤なモノリシックシステムからの進化 •  ⼀枚岩のメインフレームシステムの複雑性が専⾨化を引き起こ した –  ストレージ –  データベース –  システム分析 –  プログラマ –  オペレーション –  データ⼊⼒ •  n層アーキテクチャが次のステップとなった
9. ® © 2016 MapR Technologies 9 3層アーキテクチャ Web tier Middle tier Data tier
10. ® © 2016 MapR Technologies 10 3層アーキテクチャで重要な部分 Web tier Middle tier Data tier
11. ® © 2016 MapR Technologies 11 現実の3層アーキテクチャ Web tier Middle tier Data tier Web tier Middle tier Data tier Web tier Middle tier Data tier Web tier Middle tier Data tier
12. ® © 2016 MapR Technologies 12 分断を補うために「コントロール」を追加 •  エンタープライズ・サービス・バスの進化により、専⾨化とコ ントロールの集中が再確⽴ •  重要な点は、メッセージングとコントロール・バックボーンに 埋め込まれた⾼度な処理
13. ® © 2016 MapR Technologies 13 エンタープライズ・サービス・バス (ESB)
14. ® © 2016 MapR Technologies 14 第1話のまとめ •  階層化はパズルのような (Tic-Tac-Toe) アーキテクチャを引き起 こした •  ESB はコントロールが複雑な⽷の⽟を引き起こす –  泥の⽟よりはましだが、ちょっとだけ •  問題は解決していない
15. ® © 2016 MapR Technologies 15 第2話 スタートアップの侍 The startup Samurai
16. ® © 2016 MapR Technologies 16 振り⼦が揺り戻す時 •  ESB はまだ有効でよく使われている •  しかし、反動が進⾏中 –  Google, Facebook, Netflix, Amazon, LinkedIn –  さらに数多くの知られていない企業も –  シリコンバレー・スタートアップの世界と深く関連している –  JavaScript, Python コミュニティでの開発と深く関連している •  Meteor.js, node.js •  Swagger •  n層アーキテクチャの置き換えを考慮
17. ® © 2016 MapR Technologies 17 RPC layer Logic Disk RPC layer Logic Disk RPC layer Logic Disk まずパーティショニングを考える
18. ® © 2016 MapR Technologies 18 ジョブとコミュニケーションの⽅法を与えてやる Light-weight を 維持することが重要！
19. ® © 2016 MapR Technologies 19 結果は素晴らしいものになり得る •  このスタイルを採⽤した企業と、素晴らしい成功の間には関連 がありそう –  前のページのリストをご覧ください •  採⽤していない企業はどうかというと … •  もちろん、これは優秀な技術者を雇えた企業のみが実現できた だけかもしれない –  実際、ものすごく優秀なチームでないとできないかも …
20. ® © 2016 MapR Technologies 20 しかし … •  多くの議論では RPC (コール／レスポンス) サービスが話題に上 る •  これ⾃体はよいが、これだけでは不⼗分 •  重要なのは遅延処理 (Deferred Processing) –  ⼀部は急いで処理 –  メッセージをキューに⼊れて後で完了させる
21. ® © 2016 MapR Technologies 21 しかし … •  RPC はシンプル … –  REST –  Protobuf –  Avro –  などなど •  ネットワーク + DNS + ロードバランサー以外には何の基盤もい らない –  そして既にそれらはある •  スケーラブルではない永続化レイヤーがしばしば使われている
22. ® © 2016 MapR Technologies 22 メッセージ・ベース・サービスを実現するには •  メッセージ受信者は現時点で動作していないかもしれない –  永続化キューが必要 •  メッセージの数は⾮常に多い –  外部へのリクエストの総数（5〜10倍） –  永続化オペレーションの総数（2〜3倍） •  秒間数百万メッセージ、GB/s ものトラフィックは⼗分あり得る •  スタートアップはいいとして、エンタープライズが採⽤する際 には新たな課題
23. ® © 2016 MapR Technologies 23 第2話まとめ •  マイクロサービスは耐障害性のある⾼性能なメッセージング キューを必要とする •  これらのシステムは耐障害性と⾼性能が好ましいだけではない •  これらのシステムは耐障害性が必須。⾼性能も必須 •  伝統的なキューは適⽤できない
24. ® © 2016 MapR Technologies 24 第3話 使い古されたメタファー The tired metaphor
25. ® © 2016 MapR Technologies 25 第3話 使い古されたメタファー The tired metaphor 雲の上からの眺め The view from the clouds
26. ® © 2016 MapR Technologies 26 チューリングが念頭に置いていなかったこと •  従来型のプログラムはほとんどバッチ処理 –  有限の⼊⼒、有限の出⼒ –  重要なパラメータは処理時間、コスト、可⽤性、正しさ –  バッチ処理でも OK、クエリ／レスポンスでも OK •  ストリーム処理は「違う」 –  無限の⼊⼒のデータ列、無限の出⼒のデータ列 –  ⼀部の出⼒についての捉え⽅を変えても差し⽀えない –  重要なパラメータはレイテンシ、コスト、コミットメント・レベル
27. ® © 2016 MapR Technologies 27 Δt t provisional Input Output 暫定的な出⼒の存在は暫定的 な⼊⼒も取り扱う必要がある ことも注意
28. ® © 2016 MapR Technologies 28 より複雑な要素 •  このレイテンシだけがすべてではない •  データの取得は即座にはできない •  レイテンシがゼロからのスタートがそもそもできない •  実際、遅延はフローベース・コンピューティングでは重要課題
29. ® © 2016 MapR Technologies 29 思考問題 •  地球上のあらゆる場所の温度は何度か –  たった今 –  これを知ることは不可能 •  1時間前の地球上のあらゆる場所の温度は何度だったか? –  これを知ることは難しい •  先⽉の地球上のあらゆる場所の温度は何度だったか? –  これは⽐較的簡単 •  では今⽇の天気について話すのは不可能なのか?
30. ® © 2016 MapR Technologies 30 State の問題 •  現在の地球の気温の数値は存在するかも／しないかも •  遅延つきの気温のみが現実の処理の対象となる •  処理によって遅延はバラバラ •  (気温についての例をあげましたが、全てのデータも同様です)
31. ® © 2016 MapR Technologies 31 第3話まとめ •  重要な問題には、分散コンピューテーションをメッセージとフ ローで表現する必要がある •  これは便利だからという問題ではない
32. ® © 2016 MapR Technologies 32 第n話 現実世界に適⽤するには Getting stuff done in the real world
33. ® © 2016 MapR Technologies 33 mySQL mySQL files Web-site Auth service Upload service Image extractor Transcoder User profiles Search User action logging Recommendation analysis mySQL mySQL mySQL Oracle Solr Elastic
34. ® © 2016 MapR Technologies 34 mySQL mySQL files Web-site Auth service Upload service Image extractor Transcoder User profiles Search User action logging Recommendation analysis mySQL mySQL mySQL Oracle Solr Elastic
35. ® © 2016 MapR Technologies 35 マイクロサービス・ダイアグラム File upload web service Raw files Thumbnail extraction Transcoding Video metadata Video files DB updater DB snapshots Metadata snaps Metadata snaps Metadata snap db Live metadata DB uploads thumbs recodes video adds snaps Image files サムネイル 抽出 アップロード サービス ファイル ファイル フォーマット 変換 ビデオ メタデータ DBスナップ ショット DBアップ データ 画像 ファイル メタデータ スナップ DB ライブ メタデータ DB
36. ® © 2016 MapR Technologies 36 省略された詳細部分 File upload web service Files Thumbnail extraction Transcoding uploads thumbs recodes Files サムネイル 抽出 フォーマット 変換 アップロード サービス ファイル ファイル
37. ® © 2016 MapR Technologies 37 さらに詳細 Thumbnail extraction uploads thumbs metrics exceptions checkpoints Input Output Monitoring Restart ⼊⼒ 出⼒ 監視 再開処理 サムネイル 抽出
38. ® © 2016 MapR Technologies 38 現実世界における前提 •  メッセージング機能は耐障害性があり、基盤として存在しなけ ればならない –  送信者、受信者の動作に依存してはならない •  メッセージがすべてに適しているということはない –  1TB のメッセージ? •  (スケーラブルな) ファイルが必要 •  (スケーラブルな) テーブルが必要 •  (スケーラブルな) メッセージストリームが必要 •  可能であれば永続化レイヤーもサービスから分離すべき
39. ® © 2016 MapR Technologies 39 現実世界において考慮すべきこと •  耐障害性のある⾼速なキューイングが必要 –  Kafka なら OK –  MapR Streams なら OK –  それ以外の製品はほとんど対応できない •  従来のメッセージングは全く対応できない –  耐久性を確保すると、ほとんどのキューは1万メッセージ/秒 (MB/s) 未 満に –  ⾼性能システムは100万メッセージ/秒 (GB/s) 超を扱う •  1ミリ秒未満のレイテンシは別のシステムで扱う必要がある •  グローバル規模のシステムには、ここでは取り上げなかったさ らなる制約が加わる
40. ® © 2016 MapR Technologies 40 まとめ •  マイクロサービスは⾃然な進化 •  マイクロサービスは耐障害性があ り、⾼速で、Kafka ⾵のキューイ ングを前提とする •  マクロ・マイクロの両⽅のアーキ テクチャが必要 •  インフラは単なるキュー以上の機 能を備える必要がある。ファイル やテーブルも必要 Web tier Middle tier Data tier Web tier Middle tier Data tier Web tier Middle tier Data tier Web tier Middle tier Data tier Thumbnail extraction uploads thumbs metrics exceptions checkpoints Input Output Monitoring Restart
41. ® © 2016 MapR Technologies 41
42. ® © 2016 MapR Technologies 42 Q & A @mapr_japan maprjapan sales-jp@mapr.com お問い合わせはこちらまで MapR Japan maprtech mapr-technologies