ダイレクト VPC 下り（外向き）

ダイレクト VPC 下り（外向き）は、App Engine サービスが Virtual Private Cloud（VPC）ネットワークにトラフィックを送信するための高性能なネットワーキング ソリューションを提供します。ダイレクト VPC 下り（外向き）を使用すると、ワークロードは VPC ネットワーク リソースにシームレスにアクセスでき、サーバーレス VPC アクセス コネクタを構成する必要がなくなります。

主なメリット

  • 管理の簡素化: コネクタ インスタンス、マシンタイプ、スケーリング設定の管理に伴う運用上のオーバーヘッドを排除します。App Engine は、サービス内の app.yaml ファイルで構成を直接処理します。
  • 費用効率: ダイレクト VPC 下り（外向き）を使用する場合、追加料金は発生しません。また、コネクタ VM の月額固定料金を支払う必要もありません。
  • パフォーマンスと信頼性の向上: コネクタを使用する必要がなくなるため、ダイレクト VPC 下り（外向き）は、VPC ネットワーク リソースへのより高速で信頼性の高い接続を提供します。App Engine サービスと同じくらい迅速にスケーリングされ、メンテナンス中にコネクタで発生する可能性のある接続の切断を回避します。

  • きめ細かいセキュリティ: ネットワーク タグを App Engine サービスのバージョンに直接適用して、サービス固有の正確なファイアウォール ルールとネットワーク ポリシーを有効にできます。

  • VPC Flow Logs をサポート: サブネットで VPC Flow Logs を有効にして、App Engine サービスからの下り（外向き）トラフィックをロギングできます。

制限事項

  • IP アドレスの使用量: サービスの IP アドレスの使用量は、実行中のインスタンスの数に比例してスケーリングされます。スケーリング機能は、選択したサブネットで使用可能な IP アドレスの数によって制限されます。

  • メンテナンス イベント: ネットワーク インフラストラクチャのメンテナンス イベント中に、サービスで接続が一時的に切断される可能性があります。ときどき発生する接続リセットを処理するクライアント ライブラリを使用することをおすすめします。

  • コールド スタート: 最初のコールド スタート時間は、リージョンと特定のユースケースによって異なります。まれに、コールド スタートに 1 分ほどかかることがあります。

  • ダイレクト VPC 上り（内向き）: App Engine はダイレクト VPC 上り（内向き）をサポートしていません。

  • インスタンス数: ダイレクト VPC 下り（外向き）を使用するように構成できるインスタンスは、App Engine バージョンあたり最大 100 個です。

  • VPC Flow Logs: ログレコードに App Engine サービス バージョンが表示されません。サービス名が AppEngineServiceDetails フィールドに表示されます。

IP アドレスの割り振り

App Engine サービスを VPC ネットワークに配置するには、VPC ネットワークとサブネットのいずれかまたは両方を指定します。ネットワークのみを指定した場合、サブネットにはネットワークと同じ名前が使用されます。App Engine はサブネットから IP アドレスを割り振ります。

この IP アドレスは一時的なものであるため、個別の IP に基づくポリシーは作成しないでください。IP に基づくポリシー（ファイアウォール ルールなど）を作成する必要がある場合は、サブネット全体の IP アドレス範囲を使用する必要があります。

サービスが使用するネットワークまたはサブネットを変更するには、新しいネットワークとサブネット値を使用する新しいバージョンをデプロイします。

スケールアップとスケールダウン

トラフィックの急増時に迅速にスケールアップできるように、App Engine は 16 個（28 サブネット マスク）のブロックで IP アドレスを予約します。App Engine 全体で使用できる十分な IPv4 アドレスを確保するには、サブネットの IPv4 アドレス範囲を /26 以上にする必要があります。

IP の割り振りを効率的に行うと同時に管理を容易にするには、複数のリソースを同じサブネットに配置します。IPv4 アドレス空間が限定されている場合は、サポートされている IPv4 範囲で他の選択肢をご確認ください。

サブネットを削除するには、App Engine サービスを削除するか再デプロイしてサブネットの使用を停止した後、1 ～ 2 時間待ちます。

サービスの IP アドレスの使用量

安定した状態で、App Engine はインスタンス数の 2 倍の IP アドレスを使用します。バージョンがスケールダウンされると、App Engine は最大 20 分間 IP アドレスを保持します。合計で、IP アドレス数の 2 倍以上を予約し、バージョン更新を考慮してバッファを追加します。

たとえば、version 1 でインスタンス数が 100 から 0 にスケールダウンされ、version 2 で 0 から 100 にスケールアップされるようにバージョンをアップグレードすると、スケールダウン後、最大 20 分間 App Engine は version 1 の IP アドレスを保持します。20 分間の保持期間中は、400 個以上の IP アドレス（(100 + 100) * 2）を予約する必要があります。

サポートされている IPv4 範囲

App Engine では、サブネットで次の IPv4 範囲をサポートしています。

  • RFC 1918
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • RFC 6598
    • 100.64.0.0/10
  • クラス E
    • 240.0.0.0/4

始める前に

  1. プロジェクトに既存の VPC ネットワークとサブネットがあることを確認します。既存の VPC がない場合は、VPC ネットワークを作成するの手順に沿って作成します。

  2. Compute Engine API と Cloud Build API を有効にします。

    API の有効化

  3. ダイレクト VPC 下り（外向き）を使用するには、Google Cloud CLI の最新バージョンを実行していることを確認してください。

    gcloud components update

必要なロール

次のロールをデプロイするサービス アカウントに付与して、App Engine が VPC ネットワークにアクセスできるようにします。

  • App Engine サービス エージェントのロール: デフォルトでは、App Engine サービス エージェントには、必要な権限を含む App Engine サービス エージェントのロール（roles/appengine.serviceAgent）が付与されています。

  • カスタム権限: より詳細に制御するには、プロジェクトに対する次の追加権限を App Engine サービス エージェントに付与します。

    • compute.networks.get
    • compute.subnetworks.get
    • プロジェクトまたは特定のサブネットに対する compute.subnetworks.use
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.create
    • compute.addresses.delete
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal
    • compute.regionOperations.get

  • Compute ネットワーク ユーザー ロール: デフォルトの App Engine サービス エージェント ロールまたはカスタム権限を使用しない場合は、App Engine サービス エージェント サービス アカウントに Compute ネットワーク ユーザー ロール（roles/compute.networkUser）を付与します。外部 IPv6 を使用するサブネットには、Compute パブリック IP 管理者ロール（roles/compute.publicIpAdmin）も必要です。

    たとえば、Compute ネットワーク ユーザーのロールを付与するには、次のコマンドを実行します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@gcp-gae-service.iam.gserviceaccount.com" \
--role "roles/compute.networkUser"

    次のように置き換えます。

    • PROJECT_ID: 実際のプロジェクトの ID。
    • PROJECT_NUMBER: App Engine サービスをデプロイするプロジェクト番号。

ダイレクト VPC 下り（外向き）で App Engine サービスを構成する

新規または既存の App Engine サービスが VPC ネットワークに直接接続できるようにするには、次の操作を行います。

  1. 次の vpc_access 設定を app.yaml ファイルに追加します。

    vpc_access:
  network_interface:
    network: NETWORK
    subnet: SUBNET
    tags:
        - NETWORK_TAGS
  vpc_egress: EGRESS_SETTING

    次のように置き換えます。

    • NETWORK: アプリケーション インスタンスが接続する既存のネットワークの名前（例: default）。VPC ネットワークとサブネットのいずれかまたは両方を指定します。ネットワークのみを指定した場合、サブネットにはネットワークと同じ名前が使用されます。

    • SUBNET: アプリケーション インスタンスが接続する既存のサブネットワークの名前（例: default）。VPC ネットワークとサブネットのいずれかまたは両方を指定します。ネットワークのみを指定した場合、サブネットにはネットワークと同じ名前が使用されます。

    • 省略可: NETWORK_TAGS: ファイアウォール ルールとルーティング ポリシーで使用するために、App Engine サービスのインスタンスに関連付けるネットワーク タグのリスト。

    • 省略可: EGRESS_SETTING: アウトバウンド トラフィックのルーティング方法を制御します。このフィールドは、次の構成設定をサポートしています。

      • all-traffic: すべてのアウトバウンド リクエストが VPC ネットワーク経由で転送されます。
      • private-ranges-only（デフォルト）: 内部 IP アドレスへのトラフィックのみが VPC ネットワーク経由でルーティングされます。インターネット トラフィックはデフォルトの App Engine パスを使用します。

  2. 次のコマンドを実行して、App Engine にデプロイします。

    gcloud beta app deploy

サービスを接続解除する

VPC ネットワークからサービスを切断するには:

  1. app.yaml ファイルから vpc_access セクションを削除します。

  2. サービスを再デプロイします。

    gcloud beta app deploy

IP 管理のベスト プラクティス

サービスの各インスタンスがサブネットから IP アドレスを使用するため、IP アドレスを管理する必要があります。IP アドレスの管理には、次の戦略を使用します。

  • 推奨 IP 範囲: 互換性を最大限に高めるには、RFC 6598（100.64.0.0/10）範囲から始めることをおすすめします。

  • 代替 IP 範囲: 推奨の IP 範囲 100.64.0.0/10 をすでに使用している場合は、サブネットでクラス E（240.0.0.0/4）などの RFC 1918 以外の範囲を使用できます。

  • サブネットのサイズ設定: スケーリングに十分なアドレスを提供するために、サブネットの IPv4 アドレス範囲が /26 以上であることを確認します。

  • IP をオーバープロビジョニングする: サブネットで使用可能な IP の数をオーバープロビジョニングして、枯渇を防ぐことをおすすめします。通常、Cloud Run サービスと同様に、実行中のインスタンス数の 4 倍の IP アドレス（安定した状態で 2 倍、デプロイ中にさらに 2 倍）を使用すると、スムーズなスケーリングと更新が可能になります。

トラブルシューティング

このセクションでは、ダイレクト VPC 下り（外向き）を使用して App Engine サービスをデプロイする際に発生する可能性のある一般的なエラーについて説明します。

サブネットを削除できない

サブネットを削除するには、そのサブネットを使用するすべてのリソースを先に削除する必要があります。App Engine がサブネットを使用している場合は、サブネットを削除する前に、App Engine のサービスを VPC ネットワークから切断するか、別のサブネットに移動します。

App Engine サービスを削除または移動した後、App Engine が IP アドレスを解放するまで 1 ～ 2 時間待ってからサブネットを削除してください。

デプロイに失敗した

デプロイが失敗すると、Google Cloud CLI に根本原因を示すエラー メッセージが表示されます。一般的な問題としては、次のようなものがあります。

  • app.yaml ファイル内のネットワーク名やサブネット名のスペルミスなど、VPC メタデータが正しくない。潜在的なエラーを修正するには、app.yaml ファイルの VPC 構成を確認します。

  • IAM 権限が不十分です。デプロイするサービス アカウントに必要な権限を付与してください。デプロイ中に権限エラーが発生した場合は、サービス アカウントに次の追加ロールが付与されていることを確認してください。

IP アドレスの枯渇

サブネットで使用可能な IP アドレスがなくなると、App Engine は新しいインスタンスの起動に失敗し、エラーをログに記録します。この問題を解決するには、サブネットの IP 範囲を拡張するか、サービスをより大きなサブネットに移動します。

IP アドレスの漏洩

IP アドレスのリークは、IP アドレスの枯渇につながる可能性があります。通常のオペレーション中に IP アドレスが漏洩する可能性は低いですが、次の原因で漏洩する可能性があります。

  • デプロイするサービス アカウントには、アドレスを予約する権限（create、createInternal）のみがあり、アドレスを解放する権限（delete、deleteInternal）がありません。
  • 他の Google Cloud アドレス予約がアクティブな状態で、サービス アカウントが削除されました。
  • Cloud 請求先アカウントが削除され、サーバーレス アドレスの予約が有効な間にプロジェクトで再度有効になった。
  • サーバーレス アドレスの予約がまだ存在している間に、プロジェクトが削除されてから復元された。 Google Cloud

この問題を解決する方法は次のとおりです。

  1. ログ エクスプローラで次のログをクエリして、リークされたアドレスを特定します。

    protoPayload.authorizationInfo.permission=~"compute.addresses.delete.*"
protoPayload.authorizationInfo.resourceAttributes.type="compute.addresses"
protoPayload.resourceName=~"projects/.*/regions/.*/addresses/serverless-.*"
severity>=WARNING

    このクエリで結果が返されない場合、IP アドレスの漏洩はなく、これ以上の対応は必要ありません。

  2. クエリが結果を返す場合は、デプロイするサービス アカウントに App Engine サービス エージェントのロール（roles/appengine.serviceAgent）が含まれていることを確認します。このロールを使用できない場合は、デプロイするサービス アカウントに他の必要なロールと権限が付与されていることを確認します。

  3. Google Cloud コンソールまたは Google Cloud CLI を使用して、漏洩した IP アドレスを手動で削除します。

    コンソール

    1. Google Cloud コンソールで [IP アドレス] ページに移動します。

      [IP アドレス] に移動

    2. クエリを実行して特定した、漏洩した IP アドレスを選択します。

    3. [静的アドレスを解放] をクリックして、漏洩したアドレスを削除します。

    gcloud

    gcloud compute addresses delete コマンドを実行します。

    gcloud compute addresses delete ADDRESS_NAME --region=REGION

    次のように置き換えます。

    • ADDRESS_NAME: 漏洩した IP アドレスの名前。
    • REGION: 漏洩した IP アドレスのリージョン。