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