Cloud DataflowのオートスケーリングとSpark,Hadoopの比較

下記サイトの意訳とメモです。（例はとばしてます）。画像などは下記サイトのものを引用してます。

Google Cloud Dataflowのプログラミングモデルは現在Apache Beamになっている。Beam pipelineをCloud Dataflowサービス上で実行することの利点について紹介する。

MapReduceやSpark,Hadoopではユーザはジョブのチューニングに多くの時間を費やしている。これにはworkerの数を推測する時間も含まれている。シングル構成（固まった構成）は正しい解ではなく、ジョブのライフサイクルに応じて使用するリソース量を動的に変化させるべきである。
Google Cloud Dataflowのオートスケーリングでは、シンプルな設定（workerの数を指定する必要がない）とコスト削減（worker数の課題見積もりをなくす）をもたらす。これを実現するために、Google内部で使われている似たようなシステムの経験をベースに開発されている。

動的スケーリングの必要性

ワークロードのプロビジョニングには、適切なworkerの数を選択（一般的にユーザによって選択される）しデータパーティション（一般的にworkerの数やデータサイズで見積もられる）することを含んでいる。
固定数のworkerを選ぶのは時間がかかってしまう。たとえある時に適切なworker数を得たとしても、入力データの変化などによってチューニングしていかないといけない。
ストリーミングと関連づけられたでソースを紐解いた状態で、入力レートの変化に対する対応が最も関心のあることである。
なぜなら原始的な方法で自動化を行う場合、ユーザはオーバープロビジョニングやアンダーププロビジョニングを何回もやりなおさないといけない。

pipelineはリアルタイムに変化するインプットを扱う必要はない。なぜなら、それらはとても扱いにくいからである。Pipelineに必要なwokerの数を理解する作業は、推理ゲームをしていることとほとんど同じのことだ。「ある時間内でジョブが終了するのに、１００のworkerが必要なのか10で十分なのか」。固定数のworkerを使用することにより、リソースの超過やコストの増加、またはジョブが遅くなる可能性もある。
workerの数を固定することにより、パーティション数の設定に関する問題を引き起こすかもしれない。
あまりにもパーティション数が多すぎるとオーバーヘッドが大きくなってしまう。あまりにも少ないと全てのworkerは効率的ではなくなる。パーティションの数が固定されていれば、ユーザは正しいクラスタのサイズを推測しなければならなくなる。

スケーリングオプション

Cloud DataflowとSparkは自動的でリソースをプロビジョニングする手段を持っているが、異なる振る舞いをする。
Sparkではユーザがクラスタをデプロイし、クラスタ上でジョブもデプロイする。
それに対して、Cloud Dataflowでは、ジョブのみをデプロイすればよい。ジョブが実行されるときのみworkerはデプロイされ、必要なくなったらなくなる。
Sparkでは動的にworkerを追加するために、Dynamic Resource Allocationという機能がある。この機能はクラスタ上のジョブに対して動的にリソース（worker)を追加することができる。（ただし下記図にあるとおり、Spark Clusterのリソース内から割り当てる。Spark Clusterへのリソース追加はマニュアル）。事前にSpark Clusterはマニュアルで作っておかないといけないので、コストの削減にはつながらない。 クラウドプロバイダーのオートスケーリングサービスはworkerの追加と削除ができるかもしれないが、データ並列の制限やCPUやIOの制限があるかもしれない。
より大規模なジョブを実行するためにクラスタをスケールさせたとしても、実行しているジョブには影響しないかもしれない。例えば、Sparkでは動的にタスクの数を変更することができない。これは、たとえSparkクラスタをスケールさせることができたとしても、実行しているジョブはその恩恵を受けないことを意味している。

Cloud Dataflowはオートスケールすることを考慮して、クラウドで実行するようデザインされている。Cloud DataflowのオートスケールはFlumeやMapReduceから引き継いだ次世代のリソース管理アルゴリズムであり、バッチジョブに対して動的にworkerとtaskの数、両方を調整しスケールすることができる。
要するに、Sparkではユーザはジョブとリソースをスケールするために2つのインタフェースがあり自分で何とかしないといけないが、Cloud Dataflowではインタフェースは1つだけ(ジョブ)で、サービスが自動でスケールしてくれる。

まとめ

Cloud Dataflowのオートスケールの能力、そしてそれがSparkやHadoopといった似たようなシステムと何が違うかについて紹介した。
Cloud Dataflowではworkerの数やパーティション数を指定する必要がなく、動的にworker数を調整することができる。

Alex Harvey（SwiftIQのチーフアーキテクト）は”我々は必要なリソースを推測するのが好きなのではない。我々はアルゴリズムにもっと時間を費やしたい。Dataflowは私達のためにそれを行なってくれる。"とコメントした。
Riju Kallivalappil(Nestのソフトウェアエンジニア）も同様のことを言っていた。”渡しはDataflowのオートスケーリングのファンだ。もはやmapperやreducer、partionの数などの推測をする必要はなく、要求されるのはjobを実行することだけだ。"

今のところ、--autoscalingAlgorithm=THROUGHPUT_BASEDをコマンドラインで指定しないといけないが、近い将来すぐに全てのバッチジョブに対してデフォルトでオートスケールを有効にすることができるようになる。ストリーミングオートスケールはEAP（EarlyAccessProgram）のユーザのみ使える。