はじめに

Google Cloud の Cloud Runは、サーバーレス環境でコンテナを簡単に実行できるプラットフォームとして人気が高まっています。
しかし、Cloud Run はデフォルトでは VPC ネットワーク内に存在するリソースと直接通信できません。
そこで、Serverless VPC Access connector と 2024年に GA された Direct VPC Egress という2つの選択肢が用意されています。

本記事では、この2つの方法を徹底比較し、それぞれのメリットとデメリット、そして具体的な使い分けをわかりやすく解説します。

以下は構成例で Cloud Run から Cloud SQL 、Memorystore などのマネージドサービス VPC へ接続する場合の2パターンを図で表した内容となります。

Cloud Run の VPC アクセスパターン紹介

1. Serverless VPC Access connectorとは

Serverless VPC Access connector は、VPC ネットワークと Cloud Run 、 Cloud Functions などのマネージドサービスを接続するためのコンポーネントで、作成することで、 VPC リソースへのアクセスを実現できます。

以下に図解しメリデメについて、纏めています。

Serverless VPC Access connectorのメリデメ

以下に詳細について記載していきます。

1.1 主な特徴

  • 自動スケーリング: 負荷状況に応じて、自動的にスケーリングします。
  • インスタンスタイプ選択可能: 必要な性能に合わせて、インスタンスタイプを選択できます。
  • シンプルな設定: 複雑な設定や管理が不要で、簡単に利用できます。

1.2 メリット

  • 自動スケーリング: 負荷状況に応じて自動的にスケーリングするため、手動でのスケール処理は不要です。また、 Cloud Run 自体が急激なスケールが行われる場合も、このコンポーネントに依存することなく、スケールすることが可能です。

1.3 デメリット

  • コスト: インスタンス料金が発生します。
  • レイテンシー: Direct VPC Egress と比べると、レイテンシーが高くなります。また、(Serverless VPC Access connector が)既存の数量で足りない場合、スケール時によりレイテンシーが増加します。
  • スループット: Direct VPC Egress と比べると、スループットが低くなります。

2. Direct VPC Egressとは

Direct VPC Egressは、Cloud Run から VPC への下り通信を、追加コンポーネントなしで直接 VPC へ送信できる機能です。

以下に図解しメリデメについて、纏めています。

Direct VPC Egress のメリデメ

以下に詳細について記載していきます。

2.1 主な特徴

  • 低レイテンシー: VPC ネットワーク内のリソースと直接通信するため、低レイテンシーを実現できます。
  • 高スループット: 上記と同様な理由で高スループットです。

2.2 メリット

  • 低レイテンシー: VPC ネットワーク内のリソースと直接通信するため、低レイテンシーを実現できます。
  • 高スループット: 上記と同様な理由で高スループットです。
  • コスト: インスタンス料金が発生しません。

2.3 デメリット

  • スケーリング: Cloud Run が急激なスケールが必要になった場合、当該機能に依存し、新しい VPC ネットワークインターフェース作成時に、スケールが遅くなります。
  • IP アドレス制限: 利用する際に、その NW 内で利用可能な IP アドレス数を考慮する必要があります。

3. 判定基準とそれぞれの適したケース

これ以降の各項目の比較は、基本的にはこの比較表を中心に確認し、その内容を解説しています。
制限事項注意事項としては、以下の内容以外に IP アドレス数を考慮するなどあるかと思いますが、そういった最低限の環境は準備できている前提での記載となります。
記載したような制限の詳細をご覧になりたい場合、こちらをご覧ください

3.1 コスト

  • Serverless VPC Access connector: インスタンス料金が発生します(数量、インスタンスタイプによって金額が変動します)。
  • Direct VPC Egress: インスタンス料金が発生しません。

一定のアクセス数でスケールが少ない場合、かつ Cloud Run jobs を利用していない場合は、Direct VPC Egress の方がコストを抑えることができます。
※ Cloud Run jobs を記載している理由としては、Cloud Run jobs 対応の Direct VPC Egress は Preview のためです。

3.2 スループットとレイテンシー

  • Serverless VPC Access connector: レイテンシーが高く、スループットが低い。
  • Direct VPC Egress: レイテンシーが低く、スループットが高い。

リアルタイム性が求められるシステムの場合は、 Direct VPC Egress の方が適しているように見受けられます。

3.3 スケール

  • Serverless VPC Access connector: 急激なスケールに対応できます。
  • Direct VPC Egress: 新しい VPC ネットワークインターフェース作成時に、スケールが遅くなります。

急激なトラフィック増加が予想される場合は、Serverless VPC Access connectorの方が適しています。

3.4 Cloud Run jobs 利用有無

  • Serverless VPC Access connector: 対応しています。
  • Direct VPC Egress: ブログ記載時点では GA しておらず、Preview となります。

Cloud Run jobs を利用している場合は、Serverless VPC Access connector を選択する必要があります。

3.5 障害点

  • Serverless VPC Access connector: GCE として提供され、それを介するため、障害点となります。
  • Direct VPC Egress: GCE としてリソースは存在していませんが、障害の内容に応じて、VPC ネットワークインターフェースの作成に影響がある場合、障害点となります(※稀なケースと考えられます)。

どちらも障害点となる可能性はあるものの、Direct VPC Egress で影響を受ける事象の方がケースとしては少ないと考えられます。

3.6 Cloud NAT 利用

  • Serverless VPC Access connector: 当該機能を経由し、VPC から Cloud NAT を利用して、インターネットへ出る機能があることが可能です。
  • Direct VPC Egress: VPC を経由した Cloud NAT からインターネットへ出る機能は Preview となります。利用する場合、Direct VPC Egress の IP アドレスと Cloud NAT のポート割当ての関係によって、インターネット出ることに影響があることもありそうなので、ポート割当と IP アドレスの関係は気にしておいた方が良さそうです。

Cloud NAT を商用利用する場合、 Serverless VPC Access connector の利用が必要となります。

4. まとめ

項目 Serverless VPC Access connector Direct VPC Egress
コスト インスタンス料金が発生 インスタンス料金が発生しない
スループット/レイテンシー 低速/高 高速/低
スケール 急激なスケールにも影響なし 急なスケール時に遅延する可能性あり
Cloud Run jobs 利用 利用可能 Preview
障害点 あり なりうる可能性が低い
Cloud NAT を利用 利用可能 Preview

Serverless VPC Access connectorは、以下の場合に適しています。

  • Cloud Run にて急激なスケールの可能性がある
  • Cloud Run jobs が VPC 経由でリソースへアクセスしたい
  • Cloud NAT を経由して、インターネットに出たい(主に IP を固定したい場合に利用)

Direct VPC Egressは、以下の場合に適しています。

  • 低レイテンシーと高スループットが必要
  • コストを抑えたい

5. その他 Direct VPC Egress　に関する制限事項ピックアップ

  • Cloud Run の使用料割当により、当該機能を使用するように構成できるインスタンスの最大数が100-200(リージョンで変動)で制限されてますので、使用料割当を確認し、場合によっては、デフォルトの制限の割当を増やす方法にて、申請が必要となります。
  • NW インフラストラクチャのメンテナンスイベント中に切断される可能性があるため、不定期の接続リセットを処理できるクライアントライブラリを利用することが推奨されています。
  • Cloud Run jobs を利用したい場合、8インスタンスをこえる同時インスタンスを利用しないジョブのみで使用し、最低1,024個の IP アドレスを確保しておく必要があります。
  • サブネットのインスタンスの IP アドレスは多く確保することが推奨されており、基本的には起動するインスタンス数の4倍は確保した方が安全です。ドキュメント上は100を超えるような場合には4倍は確保、と記載されています。

IP アドレスの挙動として、例えばスケールダウンすると、Cloud Run はその個数分の IP アドレスを最大20分間確保してしまいます。
例えば、100 インスタンス起動しているリビジョン1に対して、リビジョン2をデプロイした場合、リビジョン1でスケールダウンし(100 x 4)、リビジョン2で100インスタンス起動する(100 x 4)数量分の IP アドレスが必要となるため、開放されるまでの20分間は800個の IP アドレスを利用する必要があります。以下の図を参照。

IPアドレス確保の説明

6. 所感
既存で Serverless VPC Access connector を利用している環境は多いと思うので、その環境において、移行を検討されいているようであれば、こちら参考にしていただけるとありがたいです。
調査していて思った点としては、急なスケールな面など、Serverless VPC Access connector が有利な点があり、利用中の環境も報われたようで少しうれしかったです。
なお、急激なスケールの度合いについて、重要な事項である場合、両パターンの負荷試験を実施し、より適している方を選択した方が良いと思います。
すべての用途で Cloud Run の急なスケールを要するものではないと思うので、公式ドキュメントの比較表にもある通り、基本的には Direct VPC Egress を検討し、状況に応じて Serverless VPC Access connector を検討する形が良いと思いました。
記事内では各種 Preview 中の機能に関しても記載しておりますが、最新の情報は Google Cloud のドキュメントを参照し、ご検討ください。
Cloud Run 及びその周辺はアップデートが多いので引き続き追いかけていきたいと思います。