正解:B
🎯 要件の分析
-
問題: Dataflow ストリーミングジョブのパフォーマンスが低い。
-
設定: 水平オートスケーリングが有効(最大 1000 ワーカー)。
-
現象: 実際にはわずか 10 ワーカーしか使用しておらず、オートスケーラーがスケールアウトしていない。
-
ボトルネックの場所: CSV ファイルを読み取り、行ごとに要素を出力する変換。
🔑 現象の分析
Dataflow のオートスケーラーが設定された最大値(1000)までスケールアウトしない主な理由は、並列処理のボトルネックがあるためです。
このパイプラインでは、Cloud Storage の通知(Pub/Sub メッセージ)から処理が始まります。通知メッセージの数や、そのメッセージが処理される最初のステップが非常に少ない場合、パイプラインの初期段階で並列処理が制限されます。
問題文にある変換「CSV ファイルを読み取り、行ごとに要素を出力する」は、前のステップの出力(Cloud Storage 通知)に**結合(フュージョン)**されています。
フュージョンが発生すると、前のステップ(Pub/Sub からの読み取り)の並列処理の度合いが、次のステップ(CSV 読み取り)の並列処理の度合いを決定します。もし、Pub/Sub からの入力が少数のワーカー(この例では 10 ワーカー)によって処理されている場合、その後の処理も同じワーカーにフュージョンされ、ジョブ全体が 10 ワーカーに制限されてしまいます。
💡 解決策
-
B. パイプラインコードを変更し、フュージョンを防ぐために
Reshuffleステップを導入します。-
Dataflow は、可能な限り多くの変換をフュージョン(結合)して、ワーカー間でのデータ転送のオーバーヘッドを削減しようとします。しかし、これにより並列処理が制限されることがあります。
-
Reshuffle変換は、Dataflow にデータの再シャッフルを強制し、意図的にフュージョンを防ぎます。CSV ファイルを読み取った直後、またはそれ以前のステップでReshuffleを挿入することで、大量の CSV 行データ(要素)の後にパイプラインが強制的にデータを再分配し、オートスケーラーが処理負荷に基づいて追加のワーカーをスピンアップできるようになります。これが、パフォーマンスを向上させるための適切なコーディング上の解決策です。
-
-
A & D. 垂直スケーリング / Dataflow Prime:
-
垂直スケーリング(ワーカーを大きくする)は、ワーカー数が少なすぎるという根本的な並列処理のボトルネックを解決しません。ワーカーは 1000 個まで使えるはずです。
-
-
C. 最大ワーカー数を増やす:
-
最大ワーカー数はすでに 1000 と非常に大きく設定されています。オートスケーラーが 10 個からスケールアップしないのは、最大値が低いためではなく、処理がボトルネックによって並列化できていないためです。
-
結論として、オートスケーラーを機能させるには、Reshuffle ステップを導入して、データがワーカー間で効果的に分散されるようにすることが必要です。

コメント