このドキュメントでは、Dataflow の割り当てとシステムの上限について説明します。
- 割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、Dataflow などの Google Cloud サービスによって定義されます。
- システムの上限は固定値で、変更できません。
Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。
Cloud Quotas システムは次のことを行います。
- Google Cloud のプロダクトとサービスの消費量をモニタリングする
- これらのリソースの消費量を制限する
- 割り当て値の変更をリクエストする方法を提供する
ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。
割り当ては通常、Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。
通常、割り当てを調整するには、Google Cloud コンソールを使用します。 詳細については、割り当ての調整をリクエストするをご覧ください。
Dataflow リソースにはシステムの上限もあります。システムの上限は変更できません。
Dataflow マネージド サービスには、次の割り当てと上限があります。
- 各 Google Cloud プロジェクトでは、1 分あたり最大 3,000,000 件のリクエストを作成できます。
- 各 Dataflow ジョブでは最大 2,000 個の Compute Engine インスタンスを使用できます。ただし、ワーカーゾーンを指定しない場合、Streaming Engine を使用する各ストリーミング ジョブ、またはサービスベースの Dataflow Shuffle を使用するバッチジョブは、最大 4,000 個の Compute Engine インスタンスを使用できます。
- 各 Google Cloud プロジェクトでは、デフォルトで最大 25 個の 同時 Dataflow ジョブを実行できます。
- 各 Dataflow ワーカーでは、一定期間に出力できるログの上限が設定されています。正確な上限については、ロギングのドキュメントをご覧ください。
- 組織レベルの割り当てにオプトインすると、各組織は最大で 125 個の同時 Dataflow ジョブをデフォルトで実行できます。
- 各ユーザーは 1 分あたり最大 15,000 個のモニタリング リクエストを作成できます。
- 各ユーザーは 1 分あたり最大 60 個のジョブ作成リクエストを作成できます。
- 各ユーザーは 1 分あたり最大 60 個のジョブ テンプレート リクエストを作成できます。
- 各ユーザーは 1 分あたり最大 60 個のジョブ更新リクエストを作成できます。
- 各 Google Cloud プロジェクトにはリージョンごとに以下のシャッフル スロットがあります。
- asia-east1: 48 スロット
- asia-northeast1: 24 スロット
- asia-northeast3: 32 スロット
- asia-south1: 64 スロット
- asia-southeast1: 64 スロット
- australia-southeast1: 24 スロット
- europe-west1: 640 スロット
- europe-west2: 32 スロット
- europe-west3: 40 スロット
- europe-west4: 512 スロット
- northamerica-northeast1: 512 スロット
- us-central1: 640 スロット
- us-east1: 640 スロット
- us-east4: 64 スロット
- us-west1: 384 スロット
- us-west2: 24 スロット
- us-west3: 24 スロット
- その他: 16 スロット
- Dataflow のバッチジョブは 10 日後にキャンセルされます。
Compute Engine の割り当て
パイプラインを Dataflow サービス上で実行すると、Dataflow によってパイプライン コードを実行する Compute Engine インスタンスが作成されます。
Compute Engine の割り当てはリージョンごとに指定されます。プロジェクトの Compute Engine 割り当てを確認し、必要に応じて次の調整をリクエストします。
- CPU: 以下のリージョンにおける Dataflow のデフォルトのマシンタイプは、バッチの場合は
n1-standard-1
、Streaming Engine を使用するジョブの場合はn1-standard-2
、Streaming Engine を使用しないストリーミング ジョブの場合はn1-standard-4
、Flexible Resource Scheduling(FlexRS)を使用するジョブの場合はn1-standard-2
です。FlexRS で使用される VM は、90% がプリエンプティブル VM、10% が通常の VM です。asia-east1
asia-east2
asia-northeast1
asia-northeast2
asia-northeast3
asia-south1
asia-south2
asia-southeast1
asia-southeast2
australia-southeast1
australia-southeast2
europe-central2
europe-north1
europe-west1
europe-west2
europe-west3
europe-west4
europe-west5
europe-west6
northamerica-northeast1
northamerica-northeast2
southamerica-east1
us-central1
us-central2
us-east1
us-east4
us-west1
us-west2
us-west3
us-west4
他のリージョンにおけるデフォルトのマシンタイプは、バッチの場合は
e2-standard-2
、Streaming Engine を使用するジョブの場合はe2-standard-2
、Streaming Engine を使用しないストリーミング ジョブの場合はe2-standard-4
、FlexRS を使用するジョブの場合はe2-standard-2
です。Compute Engine では、各インスタンスの総 CPU 数を合計することによって、CPU の数が計算されます。たとえば、実行中の 10 個の
n1-standard-4
インスタンスは 40 CPU として計算されます。マシンタイプと CPU 数のマッピングについては、Compute Engine のマシンタイプをご覧ください。 - 使用中の IP アドレス: プロジェクトで使用中の IP アドレスの数は、必要なインスタンス数に十分に対応できる必要があります。 10 個の Compute Engine インスタンスを使用するには、10 個の使用中 IP アドレスが必要です。
- Persistent Disk: Dataflow では Persistent Disk が各インスタンスに接続されます。
- デフォルトのディスクサイズは、バッチの場合は 250 GB、ストリーミング パイプラインの場合は 400 GB です。10 インスタンスの場合、デフォルトでは、バッチジョブに 2,500 GB の Persistent Disk が必要になります。
- Dataflow Shuffle バッチ パイプラインのデフォルトのディスクサイズは 25 GB です。
- Streaming Engine ストリーミング パイプラインのデフォルトのディスクサイズは 30 GB です。
- Dataflow サービスは、ストリーミング ジョブの実行時に、ワーカー インスタンスあたり 15 個の永続ディスクに制限されています。各永続ディスクは、個々の Compute Engine 仮想マシンに対してローカルです。リソース割り当てでは、ワーカーとディスクの 1:1 の比率が最小要件になります。
- Compute Engine の使用量は平均ワーカー数に基づき、永続ディスクの使用量は
--maxNumWorkers
の値に基づきます。永続ディスクは、各ワーカーにアタッチされたディスク数が等しくなるように再配布されます。
- リージョン マネージド インスタンス グループ: Dataflow は Compute Engine インスタンスをリージョン マネージド インスタンス グループとしてデプロイします。次の関連割り当てが使用可能であることを確認する必要があります。
- Dataflow ジョブごとに 1 つのインスタンス グループ
- Dataflow ジョブごとに 1 つのインスタンス テンプレート
- Dataflow ジョブごとに 1 つのリージョン マネージド インスタンス グループ
- ストリーミング ジョブにマネージド インスタンス グループが 7 日間以上存在しない場合、ジョブはキャンセルされます。
- マネージド インスタンス グループがバッチジョブに 1 時間以上存在しない場合、ジョブはキャンセルされます。
追加の割り当て
使用しているソースとシンクに応じて、追加の割り当てが必要になることもあります。
- Pub/Sub: Pub/Sub を使用している場合は、追加の割り当てが必要になる場合があります。割り当てを計画する場合は、Pub/Sub からのメッセージを 1 つ処理するには 3 つのオペレーションが必要なので注意してください。カスタム タイムスタンプを使用する場合は、カスタム タイムスタンプを追跡するために Dataflow によって別のサブスクリプションが作成されるため、予想されるオペレーション数を 2 倍にする必要があります。
- BigQuery: BigQuery にストリーミング API を使用している場合は、割り当て上限とその他の制限が適用されます。
割り当ての確認と引き上げ
確認できるのは、Dataflow での現在の割り当て使用量です。
- Google Cloud Console で、[API とサービス] ページに移動します。
[API とサービス] に移動 - 現在の Shuffle スロットの割り当て使用量を確認するには、[割り当て] タブのテーブルで、[シャッフル スロット] 行を探して、[使用状況グラフ] 列で [使用状況グラフを表示] をクリックします。
ジョブ割り当てを引き上げるには、Google Cloud サポートにお問い合わせください。必要に応じて上限を引き上げることができます。デフォルトの割り当ては、プロジェクトで 25 個の同時 Dataflow ジョブ、または組織で 125 個の同時 Dataflow ジョブです。
さらに、サポート リクエストを送信し、プロジェクト内のすべてのジョブに対して予想される同時シャッフル データセットの最大サイズを指定することで、バッチジョブのシャッフル スロットの割り当てを増やすことが可能です。追加のシャッフル割り当てをリクエストする前に、Dataflow Shuffle を使用してパイプラインを実行して実際のシャッフル割り当て使用量を確認してください。
ストリーミング ジョブの場合は、Google Cloud Platform サポートにサポート リクエストを送信することで、Streaming Engine のスループットを向上させることが可能です。リクエストで、ジョブを実行しているリージョンごとに毎分ワーカー間でシャッフルするデータの最大量を指定します。
Dataflow サービスは、BigQuery、Cloud Storage、Pub/Sub、Compute Engine など、Google Cloud のさまざまなコンポーネントを使用します。これら(また、その他の Google Cloud サービス)は、プロジェクト内で使用できるリソースの最大数を制限する割り当てを使用します。Dataflow を使用する場合は、これらのサービスの割り当て設定の調整が必要になることがあります。
Dataflow Prime
Dataflow と Dataflow Prime に対する割り当てと上限は同じです。Dataflow の割り当てがある場合、Dataflow Prime を使用してジョブを実行するための追加の割り当ては、必要ありません。
上限
このセクションでは、Dataflow で提供される実際のサービスの上限について説明します。
上限 | 値 |
---|---|
パイプラインあたりの最大ワーカー数。 | 2,000 |
ジョブ作成リクエストの最大サイズ。パイプラインの説明のステップ数が多く、非常に長い名前が含まれていると、この上限に達する可能性があります。 | 10 MB |
テンプレートのリリース リクエストの最大サイズ。 | 1 MB |
副入力シャードの最大数。 | 20,000 |
単一要素値の最大サイズ(Streaming Engine などのより厳しい条件が適用される場合を除く) | 2 GB |
バッチ パイプラインの最大キーサイズ。 | 1.5 MB |
ワーカーあたりの、特定の期間におけるログエントリの最大数。 | 30 秒ごとに 15,000 件のメッセージ |
プロジェクトあたりのカスタム指標の最大数。 | 100 |
推奨事項の保存期間。 | 30 日 |
Streaming Engine の上限 | 量 |
---|---|
Pub/Sub メッセージの最大バイト数。 | 7 MB |
単一要素値の最大サイズ。 | 80 MB |
ラージキーの最大サイズ。64 KB を超える鍵を使用するとパフォーマンスが低下します。 | 2 MB |
副入力の最大サイズ。 | 80 MB |
TagValue と TagBag で使用される状態タグの最大長。 |
64 KB |