はじめに

GCPのデータパイプラインを構築するプロダクトである、Dataflowを利用して
DataStoreにデータを登録した時のパフォーマンスやオートスケールについて共有します。

初めての方は、以下記事を前提にしておりますので、参照をお願いします。
https://qiita.com/sasuke9097/items/c3538933060f18b4c199

前提

Dataflowを利用してDataStoreにデータが登録できること
オートスケールの概要について理解していること

できるようになること

DataFlowのオートスケールの仕組みについて概要をつかめる
簡単なパフォーマンスチューニングができるようになる

結果

最初に結果からお伝えします。
１０万件を超えたあたりから、JOB実行時間が変わってきます。
2分間はワーカーの起動や停止に費やしているようです。
CPU時間はきれいにデータ量に比例しています。

処理件数	JOB実行時間	CPU時間(Read)	CPU時間(Regist)	Worker数
1	2分11秒	1秒	1秒	1
100	2分12秒	1秒	1秒	1
1,000	2分12秒	1秒	3秒	1
10,000	2分49秒	1秒	33秒	1
100,000	6分33秒	3秒	5分28秒	1 -> 2
1,000,000	12分4秒	9秒	58分16秒	1 -> 11 -> 13

オートスケールの仕組み

DataFlowのオートスケールの指標は、スループットです。
まずは、2、3分処理を動かしてみてスループットやCPU使用率等をもとに
Worker数を決めているようです。
以下が、1,000,000件処理時のオートスケールログです。

パフォーマンスチューニング

パフォーマンスチューニングとして、設定可能なオプションは以下となります。

デフォルトWoker数
VMのCPU
ディスク（HDD or SSD）

やはり、一番簡単なのはデフォルトWoker数だと思います。
VMのCPUは課金への影響が大きそうなので避けたいです。
今回は、1,000,000件処理を10分以内に完了できるようにチューニングします。

コマンドの実行

ポイントは、「--num-workers=6」です。
JOB実行時のWorker数を指定できます。

gcloud dataflow jobs run testText2Datastore --gcs-location gs://dataflow-templates-asia-northeast1/latest/GCS_Text_to_Datastore --region asia-northeast1 --staging-location gs://test-20201003/temp/ --parameters textReadPattern=gs://test-20201003/test1m.json,datastoreWriteProjectId=ace-charter-291406,errorWritePath=gs://test-20201003/error/failure.txt --num-workers=6

実行結果

9分35秒で完了しました。
Worker数は、12までスケールしました。

最後に

オートスケールを利用すると、データ量が急増しても、ある程度処理時間を抑えることが
できることが分かりました。
10倍に増えても処理時間が10倍になることはありませんでした。
データ量に応じて、初期のWorker数を変更するのがパフォーマンスチューニングの基本になるのかなと思います。

次は、DataflowのUDF（ユーザー定義関数）を利用して、加工処理を入れたいと思います。