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

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

主な特典

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

制限事項

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

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

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

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

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

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 サービス エージェント ロールまたはカスタム権限を使用しない場合は、 Compute ネットワーク ユーザー ロール（roles/compute.networkUser） を App Engine サービス エージェント サービス アカウントに付与します。外部 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. app.yaml ファイルに次の vpc_access 設定を追加します。

    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 をすでに使用している場合は、サブネットで RFC 1918 以外の範囲（クラス E （240.0.0.0/4）など）を使用できます。

  • サブネットのサイズ設定: スケーリングに十分なアドレスを提供するには、サブネットの 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 CLI を使用して、リークした IP アドレスを手動で削除します。 Google Cloud

    コンソール

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

      [IP アドレス] に移動

    2. クエリを実行して、前の手順で特定したリークした IP アドレスを選択します。

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

    gcloud

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

    gcloud compute addresses delete ADDRESS_NAME --region=REGION

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

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