🕌

Dataflow ワークロードでスケールを考慮した VPC 設計

2025/04/21に公開

クラウドエースのダッフィ、安田、羽田です。

Dataflow ワークロードでスケールを考慮した VPC 設計について紹介します。

 概要結論として、Dataflow ワークロードでスケールを考慮した VPC 設計の最適解は使用するサービスなどによって変わります。

この記事では、最適解を見つける方法として以下の 3 つのポイントに基づいて解説します。
小さいサブネットを作って適切な範囲を調査する
デフォルトのスケールアウト制限を基にして /21 に設定する

max_num_workers を指定しスケールアウト上限を設ける
上記の方法を試すことで自身の使用する Dataflow に最適な VPC を設計していきましょう。

 はじめに
 Dataflow ワーカーのスケーリングと IP アドレス消費

Dataflow ワーカーのスケーリングと IP アドレス消費を表した図

Dataflow は、フルマネージドサービスとして、ワーカーという VM を立ち上げてスケーリングしながらデータ処理を実行します。
このとき、各 VM ごとに IP アドレスを使用するためスケールアウトをすればするほど IP アドレスも大きく消費することになり、スケールアウトを考慮したネットワーク設計が重要となります。
もし IP アドレス不足によるスケールアウト制限が懸念されるのであれば、CIDR 範囲を広げることで対応できると考えるかもしれません。

しかし、IP アドレスは有限のため、CIDR 範囲を必要以上に広げると将来的に他のリソースに対して割り当てる IP アドレスが不足してしまう可能性があります。
そのため、今回は、最適な VPC 設計をするための方法を紹介します。

 最大ワーカー数と必要な CIDR 設計Dataflow では基本的に最大 2,000 個の VM インスタンスを使用できます。

したがって、CIDR サイズも /21 であれば足りると考えられることがあります。
しかし、実際に自分が処理するデータがどのくらいのワーカーを使用するかを調査するのはフルマネージドサービスであるため難しいです。
そのため、適切な CIDR を設定するには試行錯誤し、徐々に CIDR の範囲を広げていくことが望ましいです。
処理するデータが一定である場合は上記の方法で最適な CIDR の範囲を設定することができます。

ただ、意図せず想定以上のスケールアウトが発生した場合、IP アドレスが枯渇してしまうため、ケースによって最適な CIDR の範囲を求める方法は変わってきます。
最大ワーカー数についての詳しい情報は公式ドキュメントを参考にしてください。

 Dataflow のスケールアウトと VPC への影響Dataflow のジョブ実行において、スケールアウトは非常に重要な機能です。しかし、適切な監視と管理を怠ると、思わぬトラブルを引き起こす可能性があります。ここでは、スケールアウト時に発生する VPC への影響と、その監視方法について詳しく見ていきましょう。

 スケールアウト時に何が起こるのか？Dataflow ジョブがスケールアウトする際、システムは自動的にワーカーの数を増やしていきます。各ワーカーには VPC サブネットから IP アドレスが割り当てられます。例えば、100 個のワーカーが必要な場合、VPC サブネットから 100 個の IP アドレスが消費されることになります。
重要なのは、この IP アドレスの割り当ては動的に行われるという点です。つまり、ジョブの要求に応じてリアルタイムで IP アドレスが確保されていきます。

 IP 枯渇のリスクIP アドレスの枯渇は、多くの場合、以下のような症状として現れます：
新規ワーカーの起動失敗
ジョブのパフォーマンス低下
スケールアウトの停止
特に注意が必要なのは、複数の大規模ジョブが同時に実行される場合です。このような状況では、予想以上のスピードで IP アドレスが消費される可能性があります。 IP 枯渇が発生した場合、以下のような警告が表示されます。



IP 枯渇の画面

 Google Cloud Console での監視方法VPC ネットワークの使用状況は、Google Cloud Console で簡単に確認することができます。以下の手順で確認できます：
Cloud Console にアクセス



Google Cloud のコンソールページ
VPC ネットワーク > サブネットに移動



Google Cloud の VPC ページ



Google Cloud のサブネットページ
対象のサブネットを選択



Google Cloud のサブネット詳細ページ
「使用中の IP アドレス」セクションを確認



Google Cloud の IP アドレス使用中ページ
また、gcloud compute instances list | grep {prefix_job_name} コマンドで現在の使用状況を確認することができます。



コマンドで使用中の IP アドレス表示画面

 執筆中に負荷かけで使用したサンプルコード以下は、Python スクリプト内で Dataflow ジョブを構成し起動するサンプルコードです。パイプライン自体はシンプルな処理（1 から 5 までの数値の二乗を計算して出力）にしていますが、ポイントとなるのは PipelineOptions の設定と DataflowRunner による実行部分です。
dataflow_job.py

import apache_beam as beam
from apache_beam.io.textio import WriteToText
from apache_beam.options.pipeline_options import PipelineOptions

def run():
    # Cloud Dataflow 用のパイプラインオプションを設定
    pipeline_options = PipelineOptions(
        runner="DataflowRunner",
        project="<PROJECT_ID>",
        region="<REGION>",
        staging_location="gs://<BUCKET_NAME>/staging",
        temp_location="gs://<BUCKET_NAME>/temp",
        job_name="dataflow-write-gcs",
        save_main_session=True,
        num_workers=3,  # 最低ワーカー数
        max_num_workers=5,  # 最大ワーカー数
        network="<NETWORK>",
        subnetwork="regions/asia-northeast1/subnetworks/<SUBNETWORK>",
        autoscaling_algorithm="THROUGHPUT_BASED"
    )

    # 出力先をコード内に直接指定
    output_path = "gs://<BUCKET_NAME>/output"
    words_list = ["1", "2", "3", "4"]

    with beam.Pipeline(options=pipeline_options) as pipeline:
        (
            pipeline
            | "Create elements" >> beam.Create(words_list)
            | "Write Files" >> WriteToText(output_path, file_name_suffix=".txt")
        )

if __name__ == "__main__":
    run()


 VPC サブネットの拡張方法

項目
CIDR 拡張
新規サブネット作成


実装方法
• 既存サブネットの CIDR 範囲を拡張
• プレフィックス長を短くする
• 新しいサブネットを作成
• 新しい IP 範囲を割り当て
• 必要に応じて異なるリージョンにも作成可能


 IP アドレス不足時の対策IP アドレスの不足が発生した場合、または近い将来不足が予測される場合、主に 2 つの対策を検討する必要があります。それぞれの対策について、詳細な説明とユースケースを見ていきましょう。


項目
CIDR 拡張
新規サブネット作成


実装方法
既存サブネットの CIDR 範囲を拡張
新しいサブネットを作成し、IP 範囲を割り当て

メリット
設定変更が最小限、即時対応可能
独立した環境構築、柔軟な IP 設計

デメリット
通信断の可能性、既存環境への影響
新規設定作業、運用管理の複雑化

適しているケース
緊急対応、小規模拡張、コスト重視
計画的な大規模拡張、環境分離

準備作業
IP 使用状況確認、影響範囲調査
新規 IP 範囲設計、ネットワーク設計

実施時の注意点
作業時間選定、通信試験実施
テスト期間確保、段階的移行


 1.CIDR を拡張する

CIDR 拡張のプロセス


状態
サブネット範囲


既存
10.0.0.0/24

拡張後
10.0.0.0/21


 2.新たにサブネットを作成する

Google Cloud VPC でのサブネット追加画面


既存環境
サブネット範囲


Subnet-A (本番環境)
10.0.0.0/24

Subnet-B (新規追加)
10.0.1.0/24

コマンドでの実装例：
# CIDR拡張の場合
gcloud compute networks subnets expand-ip-range test-subnet1 \
    --region=asia-northeast1 \
    --prefix-length=21

# 新規サブネット作成の場合
gcloud compute networks subnets create test-subnet2 \
    --network=default \
    --region=asia-northeast1 \
    --range=10.0.1.0/24

 対策選択のための判断基準：

判断基準
CIDR 拡張
新規サブネット作成


緊急度
◎ 緊急対応に適する
△ 計画的な実施が必要

規模
○ 数十 IP 程度の追加に最適
◎ 数百 IP 以上の大規模に最適

運用影響
◎ 既存環境への影響最小限
△ 新規払い出しによる飛び地が生まれる可能性が高い

凡例: ◎:最適 ○:適している △:条件付き対応可能

 小さいサブネットを作って適切な範囲を調査するこの方法を利用する場合は処理するデータ量が都度変化してしまうパイプラインには向かない方法です。
理由として、この方法はデータ処理に必要なワーカー数の目安を検証することで最適化を狙うためです。

そのため、データ量などがその時々で変化してしまう場合は、意図せず多くのワーカーがスケールアウトしてしまい、IP アドレスが不足してしまう可能性が出てきます。
適切な CIDR 範囲を調査する方法としては、subnet をまずは最小範囲で作成し、実際に処理したいデータを Dataflow に流し込み処理がしっかりとできるかを判定します。
もし処理に時間がかかりすぎて、IP アドレスの不足によるエラーが出た場合、サブネットのプレフィックスを 1 段階上げて再度データを流し込む作業を行います。
そうすることで、 IP アドレスの不足によるエラーが出ないプレフィックスまで subnet を拡張できたら、最適な VPC の設計が完了します。
メリット
最適な IP アドレスの範囲がわかる
コスト最適化
他リソースを導入する際に IP アドレスに余裕ができる
デメリット
データがその時々で量が違うと IP 不足を引き起こしてしまう可能性が出る
調査に時間がかかる

 デフォルトのスケールアウト制限を基にして /21 に設定するDataflow のワーカーはデフォルトで最大 2,000 個の Compute Engine インスタンスを使用できます。

そのため、スケールアウトする最大数である 2,000 個の IP アドレスを確保できる /21 でサブネットを構成することで IP アドレスの不足によってスケールアウトができなくなることを阻止することができます。
条件を満たすとワーカー数を 4,000 個まで増やすことも可能です。

詳しい内容は公式ドキュメントを参照してください。
メリット
Dataflow を導入するまでの時間が短い
スケールアウト時の IP アドレスの不足を防ぐことができる
デメリット
処理するデータ量によっては 2,000 個もワーカーを必要としない可能性がある
他リソースを同様の IP 範囲内に置く際に IP アドレスが枯渇する可能性がある

 max_num_workers を指定しスケールアウト上限を設けるmax_num_workers を指定するとスケールアウトするワーカーの最大数を制限することができます。

最大数を指定することで IP アドレスの不足を防ぐことができます。加えて、想定以上にワーカーが立ち上がり、予算を大幅に超えてしまう可能性も排除することができます。
メリット
IP アドレスの不足が起きることがない
最大のワーカー数が想定できるので予算を立てやすい
処理するデータが増えた時にも自身の設定で気軽に変更することができる
デメリット
データ量が多すぎるとデータ処理に時間がかかる可能性がある
ワーカー数を予測して設定したプレフィックス長が実際の使用に比べて大きすぎると、IP アドレスを過剰に確保する可能性がある

 まとめスケールに強い VPC 設計をする方法は以下の 3 つです。
小さいサブネットを作って適切な範囲を調査する
デフォルトのスケールアウト制限を基にして /21 に設定する

max_num_workers を指定しスケールアウト上限を設ける
この記事では、Google Cloud Dataflow を利用する際の VPC 設計について、スケールを考慮した適切な CIDR 設定や IP アドレスの管理の重要性について解説しました。
Dataflow は自動スケール機能を備えた強力なデータ処理基盤ですが、ワーカーの増減に伴い VPC 内で消費される IP アドレスの管理が欠かせません。

IP アドレスが枯渇するとスケールアウトが制限され、ジョブの実行に影響を及ぼす可能性があります。

そのため、適切な CIDR 設計を行い、事前に最大ワーカー数を想定した IP 範囲を確保することが重要です。
また、IP アドレス不足に対する対策として、CIDR の拡張や新規サブネットの作成といった方法を紹介しました。

それぞれの方法にはメリット・デメリットがあり、運用の影響を考慮した上で最適な手法を選択する必要があります。
VPC 設計は Dataflow ワークロードのスケーラビリティや安定性に大きく関わる要素です。本記事を参考に、適切な VPC 設計を実施し、スケールに強い Dataflow 環境を構築していきましょう。

項目	CIDR 拡張	新規サブネット作成
実装方法	既存サブネットの CIDR 範囲を拡張	新しいサブネットを作成し、IP 範囲を割り当て
メリット	設定変更が最小限、即時対応可能	独立した環境構築、柔軟な IP 設計
デメリット	通信断の可能性、既存環境への影響	新規設定作業、運用管理の複雑化
適しているケース	緊急対応、小規模拡張、コスト重視	計画的な大規模拡張、環境分離
準備作業	IP 使用状況確認、影響範囲調査	新規 IP 範囲設計、ネットワーク設計
実施時の注意点	作業時間選定、通信試験実施	テスト期間確保、段階的移行

既存環境	サブネット範囲
Subnet-A (本番環境)	10.0.0.0/24
Subnet-B (新規追加)	10.0.1.0/24

判断基準	CIDR 拡張	新規サブネット作成
緊急度	◎ 緊急対応に適する	△ 計画的な実施が必要
規模	○ 数十 IP 程度の追加に最適	◎ 数百 IP 以上の大規模に最適
運用影響	◎ 既存環境への影響最小限	△ 新規払い出しによる飛び地が生まれる可能性が高い

概要

はじめに

Dataflow ワーカーのスケーリングと IP アドレス消費

最大ワーカー数と必要な CIDR 設計

Dataflow のスケールアウトと VPC への影響

スケールアウト時に何が起こるのか？

IP 枯渇のリスク

Google Cloud Console での監視方法

執筆中に負荷かけで使用したサンプルコード

VPC サブネットの拡張方法

IP アドレス不足時の対策

1.CIDR を拡張する

2.新たにサブネットを作成する

対策選択のための判断基準：

小さいサブネットを作って適切な範囲を調査する

デフォルトのスケールアウト制限を基にして /21 に設定する

max_num_workers を指定しスケールアウト上限を設ける

まとめ

Discussion