この記事は Google Cloud Japan Advent Calendar 2023 (入門編) の 16 日目の記事です。
本記事では Cloud Run の入門記事として Cloud Run の認証とネットワークについて改めて整理できればと思います！
Cloud Run とは
Cloud Run は、Google Cloud が提供するフルマネージドのサーバーレス プラットフォームでコンテナ イメージをビルドできるものであれば、任意のプログラミング言語で記述されたコードをデプロイすることができます。Cloud Run の特徴や機能に関しては下記の記事にも掲載されておりますので、是非ご覧ください。
ネットワークセキュリティ
Cloud Run では、Cloud Run サービスに対する上り（内向き）のトラフィックを「内部」、「内部と Cloud Load Balancing」、「すべて」の 3 パターンの中から選択することで簡単に制御することができます。
| 設定 | 許可される接続元 |
|---|---|
| 内部 | ・内部アプリケーション ロードバランサ ・VPC Service Controls の境界で許可されるリソース ・Cloud Run サービスと同じプロジェクトまたは VPC Service Controls の境界内にある VPC ネットワーク ・共有 VPC 上り（内向き) ・ Cloud Scheduler, Cloud Tasks, Eventarc, Pub/Sub, Workflows, BigQuery |
| 内部と Cloud Load Balancing | ・内部によって許可されるリソース ・外部アプリケーションロードバランサ |
| すべて | インターネットから直接送信されるリクエストを含むすべてのリクエストを許可 |
上記表はやや簡略して記載しており、実際に共有 VPC が「内部」として認識されるには考慮事項が必要です。詳細については下記を参照ください。
VPC ネットワークへの接続
Cloud Run はサーバーレスのサービスであり、VPC ネットワークの外に作成されるため、そのままでは VPC 内のリソースに Private IP でアクセスすることができません。しかし、Memorystore のインスタンスや Public IP を持たない Cloud SQL への接続など、VPC 内のリソースに Private IP で Cloud Run から接続したいユースケースも多くあるかと思います。そのため、Cloud Run サービスを VPC ネットワークに接続するための選択肢としてサーバーレス VPC アクセスと Direct VPC Egress の二つがあります。（Direct VPC Egress は 2023 年 12 月時点でプレビュー）
サーバーレス VPC アクセス
サーバーレス VPC アクセスはコネクタと呼ばれるリソースを用いてサーバーレス環境と VPC ネットワークとの間のトラフィックを処理します。
なお、サーバーレス VPC アクセス は Cloud Run に限らず、App Engine、 Cloud Functions などの他のサーバーレス環境からも同様に利用することができます。
サーバーレス VPC アクセスを利用する場合はまずコネクタを作成する必要があります。コンソールでの設定は下記のような画面になっており、名前やリージョン、 コネクタを接続する VPC ネットワーク等を選択します。
サブネットに関しては、コネクタのサブネットを作成するか [IP 範囲] のフィールドに、予約されていない CIDR /28 の内部 IP 範囲の最初のアドレスを入力します。この IP 範囲は、VPC ネットワーク内の既存の IP アドレス予約と重複してはいけません。また、スケーリング設定やコネクタ インスタンスのタイプに関してもオプションで設定可能です。また、コネクタはトラフィックの使用量に応じて指定された最大値にスケールアウトしますが、トラフィックが減少してもスケールインしない点はご注意ください。
コネクタが作成されたあとは Cloud Run のサービスを作成する際にネットワークタブから[アウトバウンド トラフィック用の VPC に接続する] を選択し、[サーバーレス VPC アクセス コネクタを使用]にチェックを入れ、コネクタを作成した接続する VPC ネットワークを選択します。
また、この際に「プライベート IP へのリクエストだけを VPC にルーティングする」か「すべてのトラフィックを VPC にルーティングする」を選択することも可能です。
すべてのトラフィックを VPC コネクタ経由でルーティングした場合、Cloud NAT を利用することでCloud Run サービスからの外部へのリクエストの IP アドレスを固定させることも可能です。
Direct VPC Egress
Direct VPC Egress は 2023 年の 8 月に登場した比較的新しい機能となっており、2023 年 12 月時点でプレビューとして提供をしています。本機能を有効にするとサーバーレス VPC アクセスコネクタを使用せずに VPC ネットワークにトラフィックを直接送信できるようになります。
設定はサーバーレス VPC アクセスと同様に Cloud Run のサービスを作成する際にネットワークタブから[アウトバウンド トラフィック用の VPC に接続する] を選択し、[VPC に直接トラフィックを送信]にチェックを入れたうえでトラフィックを送信する VPC ネットワーク、サブネットを選択するだけです。また、サーバーレス VPC アクセスと同様にルーティングするトラフィックの種類を選択することもできます。
サーバーレス VPC アクセスと Direct VPC Egress の比較
サーバーレス VPC アクセスと Direct VPC Egress はどちらも Cloud Run から VPC ネットワークにトラフィックを送信させる際に利用することができますが、コストやパフォーマンス等に違いがあります。
まず費用面に関しては、サーバーレス VPC アクセスはコネクタを構成するインスタンスを起動させる必要があるため、マシンタイプに応じたコンピューティング費用とネットワーク トラフィックに対して料金が発生します。 一方で Direct VPC Egress に関してはコネクタ インスタンスの起動が必要ないため、ネットワーク トラフィックに対してのみ料金が発生し、サーバーレス VPC アクセスよりも低額になります。
パフォーマンスに関しても、インスタンスを介さない分ネットワーク パス内のホップが減少するためDirect VPC Egress のほうが、レイテンシが低減されます。
しかし、サーバーレス VPC アクセスはコネクタ インスタンスに対する IP 割り振りだけ考慮すればよい一方で、Direct VPC Egress ではCloud Run のインスタンスの数に応じた IP アドレスが必要になる点を考慮する必要があることに加えて、いくつか制限事項もございます。(Cloud NAT も非対応のため、サーバーレス VPC アクセスのところでご紹介した外部 IP アドレスの固定化もできません)
また、前述の通り Direct VPC Egress は記事執筆時点(2023 年 12 月)でプレビューでの提供という点もご注意ください。
サーバーレス VPC アクセスコネクタと Direct VPC Egress の詳細な比較はこちらもご参照ください。
リクエストの認証
Cloud Run サービスはデフォルトで非公開としてデプロイされます。そのため、リクエストで認証情報(IAM)を提供しないと、サービスにアクセスできません。呼び出し元はユーザーだけでなくサービス アカウントの際も同様で、Cloud Run 起動元（roles/run.invoker） ロールを割り当てる必要があります。
公開アクセス
前述の通り、Cloud Run サービスはデフォルトでは非公開でデプロイされますが、公開 API またはウェブサイトのコンピュート リソースとして Cloud Run を利用したいケースもあるかと思います。その際は allUsers メンバータイプに対して、Cloud Run 起動元（roles/run.invoker） ロールを割り当てるだけで簡単に認証を行わずにサービスを呼び出すことができます。コンソールから設定する場合、 [認証] の設定箇所で [未認証の呼び出しを許可] にチェックを入れることで同様の設定が可能です。
gcloud コマンドを利用して Cloud Run サービスをデプロイする場合は --allow-unauthenticated オプションを付与することで同様の設定が可能です。
gcloud run deploy [SERVICE_NAME] ... --allow-unauthenticated
セッション アフィニティ
Cloud Run では複数のコンテナインスタンスを起動することができ、クライアントからのリクエストはいずれかのインスタンスにルーティングされます。しかしデフォルトでは同じクライアントからのリクエストが同じインスタンスに転送される保証はなく、異なるインスタンスによって処理される場合があります。
そこでセッション アフィニティを有効にするとCloud Run は特定のクライアントからの連続したリクエストを同じリビジョン インスタンスに転送します。次の図のように、Cloud Run は TTL を 30 日に設定したセッション アフィニティ Cookie を使用し、その値により同じクライアントによる複数のリクエストを識別し、リクエストを同一のインスタンスに転送します。
ただし、Cloud Run の自動スケーリング動作のため、セッション アフィニティは、ベスト エフォート アフィニティになる点にご注意ください。コンテナ インスタンス間でのデータの同期に関しては、同じく Google Cloud Japan Advent Calendar 2023 (入門編) の下記記事でも解説しておりますので、ぜひご確認ください。
セッション アフィニティの設定
設定は非常に簡単でコンソール上の[ネットワーキング]タブから[セッション アフィニティ]の項目にチェックを入れるだけです。
もしくはコマンドラインから --session-affinity オプションを指定することでセッション アフィニティを有効にすることもできます。
gcloud run deploy [SERVICE_NAME] --session-affinity
エンドツーエンドの HTTP/2 サポート
Cloud Run サービスのデフォルトでは、Cloud Run は HTTP/2 リクエストをコンテナに送信する際に、リクエストを HTTP/1 にダウングレードします。しかし、コンテナが gRPC ストリーミング サーバーであったり、HTTP/2 クリアテキストでリクエストを直接処理できる場合などでは、そのようなダウングレードをせずにエンドツーエンドで HTTP/2 を使用するように構成することができます。
エンドツーエンドの HTTP/2 の設定
セッション アフィニティと同様にこちらに関しても設定は非常に簡単でコンソール上の[ネットワーキング]タブから[HTTP/2 エンドツーエンドを使用する]の項目にチェックを入れるだけです。
もしくはコマンドラインから --use-http2 オプションを指定することでHTTP/2 を使用するようにサービスを設定することもできます。
gcloud run deploy [SERVICE_NAME] --session-affinity
まとめ
本記事では Cloud Run の基本的なネットワーク設定や認証について解説しました。Direct VPC Egress をはじめ、今年も Cloud Run では多くの進化がありました！益々使いやすくなっていく Cloud Run を今後も是非ご注目ください！！
Discussion