ダイレクト 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 アドレスの割り振り

VPC ネットワークに App Engine サービスを配置するには、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." \
--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_egress が private-ranges-only に設定されている場合、App Engine は、サーバーレス ワークロード間で共有される動的 IP アドレスのリージョン プールを介してアウトバウンド インターネット トラフィックを送信します。IP レピュテーションに依存するワークロードや、大量のプローブ トラフィックを生成するワークロードには、このデフォルトの共有プールを使用しないでください。

代わりに、vpc_egress: all-traffic を設定し、次の場合に専用の静的アウトバウンド IP アドレスを使用して Cloud NAT 経由でアウトバウンド トラフィックをルーティングします。

  • サービスが、レピュテーションに敏感な外部エンドポイント（Payment Gateway、ホスト型データベース、サードパーティのウェブ アプリケーション ファイアウォール（WAF）の背後にあるパートナー API など）に接続する。専用の静的 IP アドレスを使用すると、共有プール上の他のテナントからのノイズの多いトラフィックによって外部 WAF ブロックや HTTP 403 エラーがトリガーされるのを防ぐことができます。
  • サービスが、承認されたネットワーク スキャン、ポート列挙、ホスト フィンガープリント、脆弱性プローブ、ウェブ スクレイピング、負荷テストを実行している。これらのワークロードをデフォルトの共有 IP プールで実行すると、IP レピュテーションが低下し、Google Cloud 利用規定に違反して他の顧客のサービスが中断される可能性があります。また、Google がワークロードをスロットルまたは一時停止する可能性があります。

Cloud NAT を介して承認済みスキャンまたは高接続ワークロードを実行する場合は、十分な静的 IP アドレスを割り振り、ポート予約を構成してポートの枯渇を防ぎます。

トラブルシューティング

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

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

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

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

デプロイに失敗した

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

  • VPC メタデータが正しくない（app.yaml ファイル内のネットワーク名やサブネット名のスペルミスなど）。潜在的なエラーを修正するには、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 アドレスのリージョン。