はじめに
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（ユーザー定義関数）を利用して、加工処理を入れたいと思います。