ストリーミングアーキテクチャ: 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



Files


Transcoding

uploads

thumbs

recodes

Files

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


第1話エンタープライズの盗賊

Theenterprisebandit


巨⼤なモノリシックシステムからの進化 •  ⼀枚岩のメインフレームシステムの複雑性が専⾨化を引き起こ

した –  ストレージ –  データベース –  システム分析 –  プログラマ –  オペレーション –  データ⼊⼒

•  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話スタートアップの侍

ThestartupSamurai


振り⼦が揺り戻す時 •  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話使い古されたメタファー

Thetiredmetaphor


第3話使い古されたメタファー

Thetiredmetaphor雲の上からの眺め

Theviewfromtheclouds


チューリングが念頭に置いていなかったこと •  従来型のプログラムはほとんどバッチ処理

–  有限の⼊⼒、有限の出⼒ –  重要なパラメータは処理時間、コスト、可⽤性、正しさ –  バッチ処理でも OK、クエリ／レスポンスでも OK

•  ストリーム処理は「違う」 –  無限の⼊⼒のデータ列、無限の出⼒のデータ列 –  ⼀部の出⼒についての捉え⽅を変えても差し⽀えない –  重要なパラメータはレイテンシ、コスト、コミットメント・レベル


Δt

t provisional

InputOutput

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


より複雑な要素 •  このレイテンシだけがすべてではない •  データの取得は即座にはできない •  レイテンシがゼロからのスタートがそもそもできない

•  実際、遅延はフローベース・コンピューティングでは重要課題


思考問題 •  地球上のあらゆる場所の温度は何度か

–  たった今 –  これを知ることは不可能

•  1時間前の地球上のあらゆる場所の温度は何度だったか? –  これを知ることは難しい

•  先⽉の地球上のあらゆる場所の温度は何度だったか? –  これは⽐較的簡単

•  では今⽇の天気について話すのは不可能なのか?


State の問題 •  現在の地球の気温の数値は存在するかも／しないかも

•  遅延つきの気温のみが現実の処理の対象となる

•  処理によって遅延はバラバラ

•  (気温についての例をあげましたが、全てのデータも同様です)


第3話まとめ •  重要な問題には、分散コンピューテーションをメッセージとフ

ローで表現する必要がある

•  これは便利だからという問題ではない


第n話現実世界に適⽤するには

Gettingstuffdoneintherealworld


mySQLmySQL

filesWeb-site

Auth service

Upload service

Image extractor

Transcoder

User profiles

Search

User actionlogging

Recommendationanalysis

mySQLmySQL

mySQL

Oracle

Solr

Elastic


mySQLmySQL

filesWeb-site

Auth service

Upload service

Image extractor

Transcoder

User profiles

Search

User actionlogging

Recommendationanalysis

mySQLmySQL

mySQL

Oracle

Solr

Elastic


マイクロサービス・ダイアグラム


Rawfiles


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


省略された詳細部分


Files


Transcoding

uploads

thumbs

recodes

Files


フォーマット変換

アップロードサービス

ファイル

ファイル


さらに詳細


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


uploads

thumbs

metrics

exceptions

checkpoints

Input

Output

Monitoring

Restart



Q & A

@mapr_japan maprjapan

[email protected]

お問い合わせはこちらまで

MapR Japan

maprtech

mapr-technologies

Data & Analytics

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