ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan 2016

®
© 2016 MapR Technologies 1
®
© 2016 MapR Technologies
草薙昭彦, MapR Technologies
2016 年 2 ⽉ 8 ⽇

®
⾃⼰紹介
•  草薙昭彦 (@nagix)
•  MapR Technologies
データエンジニア
NS-SHAFT
無料!

®

®
ストリーミングの5つの⾒かた
•  エンタープライズ・チーム
•  マイクロサービス
•  アブストラクト・コンピューティング
•  結果の配送
•  統合

®
File upload
web service
Files
Thumbnail
extraction
Transcoding
uploads
thumbs
recodes
Files

®
File upload
web service
Files
Thumbnail
extraction
Transcoding
uploads
thumbs
recodes
Files
映画「羅⽣⾨」あらすじ
都にほど近い⼭中で、貴族の⼥性と供回りの侍が⼭賊に襲わ
れた。そして侍は死亡、事件は検⾮違使によって吟味される
事になった。だが⼭賊と貴族の⼥性の⾔い分は真っ向から対
⽴する。検⾮違使は霊媒師の⼝寄せによって侍の霊を呼び出
し証⾔を得るが、その⾔葉もまた、⼆⼈の⾔い分とは異なっ
ていた…

®
第1話
エンタープライズの盗賊
The enterprise bandit

®
巨⼤なモノリシックシステムからの進化
•  ⼀枚岩のメインフレームシステムの複雑性が専⾨化を引き起こ
した
–  ストレージ
–  データベース
–  システム分析
–  プログラマ
–  オペレーション
–  データ⼊⼒
•  n層アーキテクチャが次のステップとなった

®
3層アーキテクチャ
Web tier
Middle tier
Data tier

®
3層アーキテクチャで重要な部分
Web tier
Middle tier
Data tier

®
現実の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

®
分断を補うために「コントロール」を追加
•  エンタープライズ・サービス・バスの進化により、専⾨化とコ
ントロールの集中が再確⽴
•  重要な点は、メッセージングとコントロール・バックボーンに
埋め込まれた⾼度な処理

®
エンタープライズ・サービス・バス (ESB)

®
第1話のまとめ
•  階層化はパズルのような (Tic-Tac-Toe) アーキテクチャを引き起
こした
•  ESB はコントロールが複雑な⽷の⽟を引き起こす
–  泥の⽟よりはましだが、ちょっとだけ
•  問題は解決していない

®
第2話
スタートアップの侍
The startup Samurai

®
振り⼦が揺り戻す時
•  ESB はまだ有効でよく使われている
•  しかし、反動が進⾏中
–  Google, Facebook, Netflix, Amazon, LinkedIn
–  さらに数多くの知られていない企業も
–  シリコンバレー・スタートアップの世界と深く関連している
–  JavaScript, Python コミュニティでの開発と深く関連している
•  Meteor.js, node.js
•  Swagger
•  n層アーキテクチャの置き換えを考慮

®
RPC layer
Logic
Disk
RPC layer
Logic
Disk
RPC layer
Logic
Disk
まずパーティショニングを考える

®
ジョブとコミュニケーションの⽅法を与えてやる
Light-weight を
維持することが重要！

®
結果は素晴らしいものになり得る
•  このスタイルを採⽤した企業と、素晴らしい成功の間には関連
がありそう
–  前のページのリストをご覧ください
•  採⽤していない企業はどうかというと …
•  もちろん、これは優秀な技術者を雇えた企業のみが実現できた
だけかもしれない
–  実際、ものすごく優秀なチームでないとできないかも …

®
しかし …
•  多くの議論では RPC (コール／レスポンス) サービスが話題に上
る
•  これ⾃体はよいが、これだけでは不⼗分
•  重要なのは遅延処理 (Deferred Processing)
–  ⼀部は急いで処理
–  メッセージをキューに⼊れて後で完了させる

®
しかし …
•  RPC はシンプル …
–  REST
–  Protobuf
–  Avro
–  などなど
•  ネットワーク + DNS + ロードバランサー以外には何の基盤もい
らない
–  そして既にそれらはある
•  スケーラブルではない永続化レイヤーがしばしば使われている

®
メッセージ・ベース・サービスを実現するには
•  メッセージ受信者は現時点で動作していないかもしれない
–  永続化キューが必要
•  メッセージの数は⾮常に多い
–  外部へのリクエストの総数（5〜10倍）
–  永続化オペレーションの総数（2〜3倍）
•  秒間数百万メッセージ、GB/s ものトラフィックは⼗分あり得る
•  スタートアップはいいとして、エンタープライズが採⽤する際
には新たな課題

®
第2話まとめ
•  マイクロサービスは耐障害性のある⾼性能なメッセージング
キューを必要とする
•  これらのシステムは耐障害性と⾼性能が好ましいだけではない
•  これらのシステムは耐障害性が必須。⾼性能も必須
•  伝統的なキューは適⽤できない

®
第3話
使い古されたメタファー
The tired metaphor

®
第3話
使い古されたメタファー
The tired metaphor
雲の上からの眺め
The view from the clouds

®
チューリングが念頭に置いていなかったこと
•  従来型のプログラムはほとんどバッチ処理
–  有限の⼊⼒、有限の出⼒
–  重要なパラメータは処理時間、コスト、可⽤性、正しさ
–  バッチ処理でも OK、クエリ／レスポンスでも OK
•  ストリーム処理は「違う」
–  無限の⼊⼒のデータ列、無限の出⼒のデータ列
–  ⼀部の出⼒についての捉え⽅を変えても差し⽀えない
–  重要なパラメータはレイテンシ、コスト、コミットメント・レベル

®
Δt
tprovisional
Input
Output
暫定的な出⼒の存在は暫定的
な⼊⼒も取り扱う必要がある
ことも注意

®
より複雑な要素
•  このレイテンシだけがすべてではない
•  データの取得は即座にはできない
•  レイテンシがゼロからのスタートがそもそもできない
•  実際、遅延はフローベース・コンピューティングでは重要課題

®
思考問題
•  地球上のあらゆる場所の温度は何度か
–  たった今
–  これを知ることは不可能
•  1時間前の地球上のあらゆる場所の温度は何度だったか?
–  これを知ることは難しい
•  先⽉の地球上のあらゆる場所の温度は何度だったか?
–  これは⽐較的簡単
•  では今⽇の天気について話すのは不可能なのか?

®
State の問題
•  現在の地球の気温の数値は存在するかも／しないかも
•  遅延つきの気温のみが現実の処理の対象となる
•  処理によって遅延はバラバラ
•  (気温についての例をあげましたが、全てのデータも同様です)

®
第3話まとめ
•  重要な問題には、分散コンピューテーションをメッセージとフ
ローで表現する必要がある
•  これは便利だからという問題ではない

®
第n話
現実世界に適⽤するには
Getting stuff done in the real world

®
mySQL
mySQL
ﬁles
Web-site
Auth
service
Upload
service
Image
extractor
Transcoder
User
proﬁles
Search
User action
logging
Recommendation
analysis
mySQL
mySQL
mySQL
Oracle
Solr
Elastic

®
マイクロサービス・ダイアグラム
File upload
web service
Raw
files
Thumbnail
extraction
Transcoding
Video
metadata
Video
files
DB updater
DB
snapshots
Metadata
snapsMetadata
snapsMetadata
snap db
Live
metadata
DB
uploads
thumbs
recodes
video
adds
snaps
Image
files
サムネイル
抽出
アップロード
サービス
ファイル
ファイル
フォーマット
変換
ビデオ
メタデータ
DBスナップ
ショット
DBアップ
データ
画像
ファイル
メタデータ
スナップ
DB
ライブ
メタデータ
DB

®
省略された詳細部分
File upload
web service
Files
Thumbnail
extraction
Transcoding
uploads
thumbs
recodes
Files
サムネイル
抽出
フォーマット
変換
アップロード
サービス
ファイル
ファイル

®
さらに詳細
Thumbnail
extraction
uploads
thumbs
metrics
exceptions
checkpoints
Input
Output
Monitoring
Restart
⼊⼒
出⼒
監視
再開処理
サムネイル
抽出

®
現実世界における前提
•  メッセージング機能は耐障害性があり、基盤として存在しなけ
ればならない
–  送信者、受信者の動作に依存してはならない
•  メッセージがすべてに適しているということはない
–  1TB のメッセージ?
•  (スケーラブルな) ファイルが必要
•  (スケーラブルな) テーブルが必要
•  (スケーラブルな) メッセージストリームが必要
•  可能であれば永続化レイヤーもサービスから分離すべき

®
現実世界において考慮すべきこと
•  耐障害性のある⾼速なキューイングが必要
–  Kafka なら OK
–  MapR Streams なら OK
–  それ以外の製品はほとんど対応できない
•  従来のメッセージングは全く対応できない
–  耐久性を確保すると、ほとんどのキューは1万メッセージ/秒 (MB/s) 未
満に
–  ⾼性能システムは100万メッセージ/秒 (GB/s) 超を扱う
•  1ミリ秒未満のレイテンシは別のシステムで扱う必要がある
•  グローバル規模のシステムには、ここでは取り上げなかったさ
らなる制約が加わる

®
まとめ
•  マイクロサービスは⾃然な進化
•  マイクロサービスは耐障害性があ
り、⾼速で、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

®

®
Q&A
@mapr_japan maprjapan
sales-jp@mapr.com
お問い合わせはこちらまで
MapR Japan
maprtech
mapr-technologies

ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan 2016

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan 2016

Similaire à ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan 2016 (20)

Plus de MapR Technologies Japan

Plus de MapR Technologies Japan (8)

ストリーミングアーキテクチャ: State から Flow へ - 2016/02/08 Hadoop / Spark Conference Japan 2016