Cloud Runの「ネットワーキング」設定とは？サービス間の通信と外部連携を制御する

Cloud Runのサービスは、単独で動作することもあれば、他のCloud Runサービス、あるいはデータベース、外部APIなど、様々なサービスと連携して動作することがほとんどです。
このようなサービス間の通信や外部へのアクセスを制御するのが「ネットワーキング（Networking）」の設定項目です。

Cloud RunのUIで「ネットワーキング」のセクションを見ると、いくつかのチェックボックスがあります。
今回は、これらの項目が何を示し、Cloud Runサービスの挙動にどのような影響を与えるのかを解説していきます。

設定項目一覧
1. HTTP/2 エンドツーエンドを使用する
2. セッションアフィニティ
1. 設定のポイント
2. ユースケース
3. アウトバウンドトラフィック用の VPC に接続する
1. 設定のポイント
2. ユースケース
4. サービスメッシュに参加します
1. 設定のポイント
2. ユースケース
まとめ

設定項目一覧

現在のCloud Runのネットワーキング設定には、主に以下の4つのチェックボックスがあります。

HTTP/2 エンドツーエンドを使用する
セッションアフィニティ
アウトバウンドトラフィック用の VPC に接続する
サービスメッシュに参加します

1. HTTP/2 エンドツーエンドを使用する

Cloud Runが、クライアント（またはロードバランサなど）から受け取ったHTTP/2リクエストを、そのままコンテナ内部までHTTP/2で転送するかどうかを定義します。

Cloud Runにおいてデフォルトの動作では、HTTP/2リクエストをコンテナに送信する際に、HTTP/1にダウングレードしています。

HTTP/2 エンドツーエンドを使用すると、コンテナがHTTP/2を直接処理するようになります。

設定のポイント

デフォルトでは、Cloud RunはクライアントからHTTP/2でリクエストを受け取ったとしても、コンテナへの転送はHTTP/1.1で行われます。このチェックボックスをオンにすると、コンテナへの転送もHTTP/2で行われます。
コンテナがHTTP/2をサポートし、HTTP/2でリクエストを待ち受けるように構築されている必要があります。
HTTP/2は、単一のTCP接続で複数の並列リクエストを処理できる、ヘッダー圧縮機能を持つなど、HTTP/1.1に比べてパフォーマンス上の利点（特に多くの小さなリクエストがある場合）があります。

ユースケース

アプリケーションがgRPCを使用する場合（gRPCはHTTP/2上で動作する）
HTTP/2のパフォーマンス上のメリットを最大限に活用したい場合
クライアントとコンテナ間でHTTP/2の機能（例: サーバープッシュ）を利用したい場合

使用するためには？

コンテナが gRPC ストリーミングサーバーである
コンテナがHTTP/2リクエストを処理できる

2. セッションアフィニティ

同じクライアント（ユーザー）からの連続するリクエストを、常に同じコンテナインスタンスにルーティングし続けるかどうかを定義します。

設定のポイント

デフォルトでは、Cloud Runはセッションアフィニティをサポートしません。つまり、同じクライアントからの次のリクエストが、別のコンテナインスタンスにルーティングされる可能性があります（ロードバランシングの原則）
このチェックボックスをオンにすると、HTTPクッキーまたはクライアントIPに基づいてセッションアフィニティが有効になります。
セッションアフィニティを有効にすると、特定のインスタンスに負荷が集中する可能性があるため、注意が必要です。

ユースケース

セッション状態をインメモリで管理するレガシーアプリケーション: 永続的なセッションストレージ（データベース、Redisなど）を使用せずに、コンテナのメモリにユーザーセッション情報を保持しているアプリケーションの場合に、ユーザーエクスペリエンスを維持するために必要になることがあります。

3. アウトバウンドトラフィック用の VPC に接続する

Cloud Runサービスから外部（インターネット、他のGCPサービス、オンプレミスなど）へのアウトバウンド（送信）トラフィックを、Google CloudのVPCネットワーク経由でルーティングするかどうかを定義します。

設定のポイント

デフォルトでは、Cloud Runからのアウトバウンドトラフィックは、Googleの共有ネットワークを介してインターネットに直接ルーティングされます。
このチェックボックスをオンにし、VPCネットワークコネクタを設定すると、Cloud Runサービスが指定されたVPCネットワークに接続され、そこからアウトバウンドトラフィックがルーティングされます。
この設定は、主にプライベートIPアドレスを持つGCPサービス（例: Cloud SQL Private IP、Memorystore、GKE内部負荷分散サービス）にアクセスする場合や、VPCネットワークを介してオンプレミスネットワークに接続する場合に必要です。

ユースケース

Cloud SQLのプライベートIP接続: データベースのセキュリティを高めるため。
Memorystore (Redis/Memcached) へのアクセス。
VPC Service Controls: 組織のデータ境界を強化するため。
オンプレミスネットワークへのアクセス: Cloud VPNやCloud Interconnectで接続されたオンプレミスリソースへのアクセス。
固定IPアドレスでのアウトバウンドトラフィック: VPCコネクタとCloud NATを組み合わせることで、Cloud Runからのアウトバウンドトラフィックに固定のグローバルIPアドレスを付与できます。

4. サービスメッシュに参加します

Cloud Runサービスを、Traffic DirectorまたはIstioベースのサービスメッシュに参加させるかどうかを定義します。

設定のポイント

Google CloudのサービスメッシュソリューションであるTraffic Director（マネージドなサービスメッシュ）または自己管理型のIstioの利用を前提とした設定です。
サービスメッシュに参加することで、Cloud Runサービスは、トラフィック管理（例: リトライ、タイムアウト、トラフィックシフト）、可観測性（例: トレース、メトリクス）、セキュリティ（例: mTLS）といった高度な機能を、アプリケーションコードを変更せずに利用できるようになります。

ユースケース

マイクロサービスアーキテクチャ: 多数のマイクロサービスが連携する複雑なシステムにおいて、サービス間の通信を効率的に管理し、可観測性を高めたい場合。
高度なトラフィックルーティング: ブルー/グリーンデプロイ、カナリアリリース、A/Bテストなど、より高度なトラフィック管理戦略を実装したい場合。
統一されたポリシー適用: サービス間の認証・認可ポリシーを集中管理したい場合。

まとめ

Cloud Runの「ネットワーキング」設定は、サービスがどのように外部と通信し、他のリソースと連携するかを決定する設定群です。

HTTP/2 エンドツーエンド: gRPCやパフォーマンス最適化のためにコンテナまでHTTP/2を維持したい場合。
セッションアフィニティ: ステートフルなレガシーアプリケーションで同じクライアントを同じインスタンスにルーティングしたい場合（通常は非推奨）。
アウトバウンドトラフィック用の VPC に接続する: Cloud SQL Private IPやオンプレミスなど、VPCネットワーク経由での内部アクセスを必要とする場合。
サービスメッシュに参加します。: 大規模なマイクロサービス環境で、高度なトラフィック管理、可観測性、セキュリティ機能を利用したい場合。