Cloud Run jobs 利用におけるNW設計

こんにちは。SCSKの磯野です。

Cloud Run jobsを利用するにあたり、VPC/NAT/IPアドレスの作成単位や設計に迷ったので、当チームで最終的に採用したものをご紹介します。なぜ（Why）その方針としたのか、どのように（How）実装したのか、という2つの観点で記載しています。

前提

当チームでは、Cloud Run jobsを用いて外部からのデータ取得を行っています。一般公開されているデータから、購入しているデータまで、さまざまなデータをAPIやスクレイピングを通して取得しています。

アクセス先の外部サービスによっては接続元のIPアドレスを固定する必要があるため、当チームのCloud Run jobsには以下の2種類が存在します。

dev/stg/prdの3環境で構成されています。

組織全体に対するルートやファイアウォール、サブネット IP アドレス範囲、VPN 接続などの作成を一元管理するため、共有VPCを利用しています。

公式ドキュメントを参照ください。

「前提」に記載した通り、外部サービス側にて静的外部IPアドレスのホワイトリスト登録が必要なケースがあります。静的外部IPアドレスを設定するためには、NAT経由の通信とする必要がありました。
一方で、静的外部IPアドレスが不要なCloud Runについても、NAT経由の通信を採用しています。理由は以下の通りです。
- ソースIP/ポート枯渇を避けられる (参考)
  - Cloud Runから大量の同時接続が必要な場合、NATに外部IPを追加してポート数を増やすことができるため。NATを経由しない場合は、IP/ポートを調整不可のため、枯渇する可能性があり。
- egressをNAT経由にする=VPC経由となるので、Google/Google Cloud APIへの通信をGoogleのネットワーク内に閉じることが可能。スループット/セキュリティ面の向上につながる。
- ログ分析と監査の容易さ
  全ての通信がNATを経由することで、外部向け通信とログ確認や監査がしやすくなる (接続不可時のトラフィック状況の確認や、コードベースを乗っ取られデータ漏洩していることの確認等)。

Cloud Run サービスまたはジョブから VPC ネットワークに下り（外向き）トラフィックを送信する方法としては、以下の2種類があります。

費用・パフォーマンスの観点から「ダイレクト VPC 下り（外向き）」を採用していますが、執筆時点ではCloud Run ジョブにおける「ダイレクト VPC 下り（外向き）」はプレビュー版です。利用の際はご注意ください。

devからの通信が多すぎることでNATのポートが枯渇し、prdの通信ができなくなることを防ぐため、静的外部IPアドレスは環境ごとに（dev/stg/prd）に分離しています。
- 費用の観点から用途ごとには分けず、チーム全体で共通のIPアドレスを使用する
サービスによっては登録できるIPアドレス数が限られているため、状況に応じてdev/stg/prdで同じIPを使用しています。