Dataflow のリージョンでは、Dataflow ジョブに関するメタデータが保存され、処理されます。また、Dataflow ワーカーがデプロイされ、制御されます。
リージョンの名前は、Compute Engine リージョン名に基づく標準の規則に従います。たとえば、米国中部リージョンの名前は us-central1 です。
この機能は、Dataflow がサポートされているすべてのリージョンで使用できます。使用可能なロケーションを確認するには、Dataflow のロケーションをご覧ください。
リージョンの選択に関するガイドライン
Dataflow ジョブでのリージョンの指定は必須です。
セキュリティとコンプライアンス
プロジェクトのセキュリティとコンプライアンスのニーズに対応するために、Dataflow ジョブの処理を特定の地理的リージョンに制限する必要が生じることがあります。
データの局所性
ネットワークのレイテンシおよびネットワーク転送のコストを最小限に抑えるには、Dataflow ジョブをそのソース、シンク、ステージング ファイルのロケーションや一時ファイルのロケーションと同じリージョンから実行します。使用するソース、シンク、ステージング ファイルのロケーションや、一時ファイルのロケーションがジョブのリージョン外である場合、データがリージョンを越えて送信される可能性があります。
パイプラインの実行では、ユーザーデータは Dataflow ワーカープールによってのみ処理され、データの移動はプール内の Dataflow ワーカーを接続するネットワーク パスに制限されます。
ユーザーデータは、割り当てられた地理的リージョンにある Dataflow ワーカーによって必ず処理されますが、パイプライン ログメッセージは、Google Cloud 内で単一のグローバル プレゼンスを持つ Cloud Logging に保存されます。
パイプライン ログメッセージのロケーションをより細かく制御するには、次の操作を行います。
_Defaultログ ルーター シンクに除外フィルタを作成して、Dataflow ログが_Defaultログバケットにエクスポートされないようにします。- 任意のリージョンでログバケットを作成します。
- 新しいログバケットに Dataflow ログをエクスポートする新しいログルーター シンクを構成します。
ロギングの構成については、転送とストレージの概要とログ ルーティングの概要をご覧ください。
一般的な Dataflow ジョブソースに関する注意事項:
- Cloud Storage バケットをソースとして使用する場合は、読み取りオペレーションをバケットと同じリージョンで行うことをおすすめします。
- Pub/Sub トピックをグローバル Pub/Sub エンドポイントに公開すると、最も近い Google Cloud リージョンに保存されます。ただし、トピック ストレージ ポリシーは特定のリージョンまたはリージョン セットに変更できます。同様に、Pub/Sub Lite トピックはゾーン ストレージのみをサポートしています。
復元力と地理的分離
通常の Dataflow オペレーションを、停止が生じる可能性ある他の地理的リージョンから分離するのが適切な場合があります。または、リージョン全体に及ぶ災害が発生した場合の事業継続のために、代替サイトを計画する必要が生じることもあります。
障害復旧計画および事業継続計画に、Dataflow ジョブで使用されるソースおよびシンクの詳細を組み込むことをおすすめします。お客様の要件を満たせるよう、Google Cloud セールスチームがお手伝いします。
リージョン プレースメント
デフォルトでは、選択したリージョンにより、リージョン内で使用可能なすべてのゾーンを利用するように Dataflow ワーカープールが構成されます。ゾーンの選択は、作成時に各ワーカーに対して計算され、リソースの取得と未使用の予約の利用が最適化されます。
リージョン プレースメントには、次のようなメリットがあります。
- リソースの可用性の向上: Dataflow ジョブは、ゾーンリソースの可用性エラーに対する復元力が強化されます。これは、使用可能な他のゾーンでワーカーを引き続き作成できるためです。
- 信頼性の向上: ゾーンに障害が発生しても、ワーカーが他のゾーンで再作成されるため、Dataflow ジョブを引き続き実行できます。
次の制限が適用されます。
- リージョン プレースメントは、Streaming Engine または Dataflow Shuffle を使用するジョブでのみサポートされます。Streaming Engine または Dataflow Shuffle からオプトアウトしたジョブでは、リージョン プレースメントを使用できません。
- リージョン プレースメントは VM にのみ適用され、Streaming Engine と Dataflow Shuffle のバックエンド リソースには適用されません。
- VM の複製が複数のゾーンにわたって行われることはありません。たとえば、ある VM が利用できなくなった場合、その作業は失われたと見なされ、別の VM によって再処理されます。
- リージョン全体でストックアウトが発生した場合、Dataflow サービスは VM を作成できなくなります。
自動ゾーン プレースメント
リージョン プレースメントでサポートされていないジョブの場合、ジョブ作成リクエスト時に使用可能なゾーン容量に基づいて、リージョン内の最適なゾーンが自動的に選択されます。自動ゾーン選択機能により、ジョブワーカーはジョブに最適なゾーンで実行できるようになります。
ジョブは単一のゾーンで実行するように構成されているため、十分な Compute Engine リソースを使用できない場合は、ゾーンリソースの可用性エラーでオペレーションが失敗する可能性があります。
また、ゾーンを使用できない場合はストリーミング バックエンドも使用できなくなり、データが失われる可能性があります。
リージョンを指定する
ジョブのリージョンを指定するには、--region オプションをサポートされているリージョンのいずれかに設定します。--region オプションは、メタデータ サーバー、ローカル クライアント、または環境変数に設定されているデフォルト リージョンをオーバーライドします。
Dataflow コマンドライン インターフェースでは、--region オプションでリージョンを指定することもできます。
ワーカーのリージョンまたはゾーンをオーバーライドする
デフォルトでは、--region オプションを指定してジョブを送信すると、ジョブの種類に応じてリージョン内の複数のゾーンまたはリージョン内の最適な単一ゾーンがワーカーに自動的に割り当てられます。
Dataflow ジョブのワーカーが特定のゾーンでのみ実行されるようにする場合は、次のパイプライン オプションを使用してゾーンを指定できます。Dataflow ジョブでは、この使用パターンは一般的ではありません。
Java
--workerZone
Python
--worker_zone
Go
--worker_zone
それ以外の場合は、ワーカー ロケーションのオーバーライドはおすすめしません。一般的なシナリオの表に、これらの状況に関する使用上の推奨事項を示します。
ジョブは単一のゾーンで実行するように構成されているため、十分な Compute Engine リソースを使用できない場合は、ゾーンリソースの可用性エラーでオペレーションが失敗する可能性があります。
gcloud compute regions list コマンドを実行して、ワーカーのデプロイに使用できるリージョンとゾーンのリストを表示できます。
一般的な事例
次の表に、一般的な事例における使用上の推奨事項を示します。
| 事例 | 推奨事項 |
|---|---|
| サポートされているリージョンを使用し、そのリージョン内のゾーンであれば特定のゾーンを指定する必要はありません。この場合、使用可能な容量に基づいて最適なゾーンが自動的に選択されます。 | ジョブのリージョンを指定するには、--region を使用します。これにより、Dataflow でジョブが管理されて、指定されたリージョン内のデータが処理されます。 |
| リージョン内の特定のゾーンでワーカー処理を行う必要があります。 | --region と一緒に --workerZone または --worker_zone を指定します。
|