GYAOのtsです。
我々のチームは、オールパブリッククラウドで、Microservice Architectureを採用した次期バックエンドを設計中です。
経緯
前回の投稿で、目指すゴールはだいたい決まったので、それぞれのサブシステムについて、チーム内でプロトタイピングを行っていく。
今回はDataFlowをやってみる。
前提
いくつかCloudDataFlowの事前知識としてまとめておいたほうが良いものがあったので、まとめておく。
※順次増やします。
概要
CloudDataFlowは下記のようなpipeline（route）を作成する。実装は、現時点ではjava SDKとPython SDK（β）が提供されている。
Pipelineオブジェクトに対して、transforms（データ変換）をapplyしていく。input、outputに関しても、BigQueryやDatastore等、SDKによって提供される。もちろん拡張も可能。PipelineIOに関してはこちらを参照。
Source: https://cloud.google.com/dataflow/pipelines/design-principles#a-basic-pipeline
どことなくApache Camelを思い出す。。。
deploy
EclipseやMavenで作成した成果物をCloudStorageに転送する。
CloudStorageにjarファイル等の成果物が転送されるとほぼ同時に、GCEのインスタンスが自動で作成され、
そこにデプロイされる模様。今回はこちらを参考にEclipseで構築する。
Runner
定義したパイプラインの起動mode（Runner）としていくつか提供されている。
| PipelineRunner | 概要 |
|---|---|
| DataflowPipelineRunner | パイプラインは、Googleのクラウド上で非同期に実行される。ジョブの進捗状況を監視することが可能。 |
| BlockingDataflowPipelineRunner | DataflowPipelineRunnerと同じように、クラウド上で実行されるが、立ち上げたジョブが終了するのを待ちます。ジョブを実行しながら、待っている間、ジョブステータスの更新とコンソールメッセージを出力する。 |
| DirectPipelineRunner | local execution, not in Google Cloud. ローカルマシンからの実行（クラウド上で実行しない） |
Source: https://cloud.google.com/dataflow/pipelines/specifying-exec-params#asynchronous-execution
bounded & unbounded
上述のようにデータはPCollectionオブジェクトでやり取りするのだが、2種類の形式が存在する。
| PCollection | 概要 | in,out |
|---|---|---|
| bounded | 有限リソース | TextIO,BigQueryIO,DatastoreIO |
| unbounded | 断続的リソース（stream） | PubsubIO,BigQueryIO |
Source: https://cloud.google.com/dataflow/model/pcollection#bounded-and-unbounded-pcollections
今回は in（PubsubIO）-out(DatastoreIO)なので、streamデータをある程度の塊で扱わなければならない。
ソリューションとしてWindowingが提供されているのでそれを使用する。
Streaming Autoscaling
2016/10現在、
Beta
This is a Beta release of Streaming Autoscaling. This feature might be changed in backward-incompatible ways and is not subject to any SLA or deprecation policy.
Streaming Autoscalingに関してはβだ。。。うーむ。。。
The number of workers used for a streaming autoscaling pipeline ranges between N/15 and N workers where N is the value of --maxNumWorkers. For example, if your pipeline needs 3 or 4 workers in steady state, you could set --maxNumWorkers=15 and the pipeline will automatically scale between 1 and 15 workers.
--maxNumWorkers can be 1000 at most.
worker 3 or 4で --maxNumWorkers=15を指定する例が提示されている。実際に処理をしていく上でパフォチューが必要そう。
Source: https://cloud.google.com/dataflow/faq
Cloud Pub/Subのメッセージ順序性（余談）
途中で気付いたが、Cloud Pub/Subはメッセージの順序性を一切担保しない。というか、下記を見る限り順序性って必要？というスタンスっぽい。そこまでは言っていないが、要は拡張性、高可用性とトレードオフですよと。
なるほど。おっしゃる通り。Apache kafkaと同じ勢いでこんな感じで設計したが、考え直さなければ。。。
やっぱり皆でいじっていくことは必要ですね。
次回
予備知識が相当必要ですね。自分のロースキルが悩ましい。。。
次回やっとハンズオン！