App Engine ネットワーキングのベスト プラクティス

このページでは、App Engine リソースのネットワーク オプションを構成するためのベスト プラクティスの概要を説明します。このページのすべてのセクションを確認して、App Engine でサポートされているネットワーキング オプションとその影響を理解することをおすすめします。

ベスト プラクティス:

IP アドレス管理。
IP アドレスの使用状況をモニタリングする。
RFC 1918 以外の IP アドレスを使用する。
IPv4 と IPv6（デュアルスタック）のサブネットを使用する。
接続プールを使用して接続を再利用する。
サポートされているランタイムを使用する。
インターネットへの外部スループットの高速化。
Google API への内部スループットの高速化。

IP 管理

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

  • 代替 IP 割り振り: 標準のプライベート範囲または代替 IP 範囲を割り振って、IP アドレスの枯渇を軽減します。IP アドレス枯渇対策をご覧ください。

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

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

IP アドレスの使用状況をモニタリングする

ダイレクト VPC 下り（外向き）を使用している場合は、サブネットに十分な IP アドレスが割り振られていることを確認してください。使用する IP アドレスの数は、ワークロードが実行するインスタンスの数によって異なるため、IP アドレスの使用状況をモニタリングすることをおすすめします。時間の経過に伴う IP 使用量がサブネットでサポートされている範囲内に収まるようにしてください。

IP アドレスの使用量を推定する手順は次のとおりです。

  1. Google Cloud コンソールで [Metrics Explorer] ページに移動します。

    Metrics Explorer に移動

  2. 指標タイプ appengine.googleapis.com/system/instance_count を使用して、プロジェクト内のインスタンス数を検索します。この指標は、プロジェクト全体のすべての App Engine インスタンスをカウントします。ダイレクト VPC 下り（外向き）で構成されたバージョンの場合は、サービスを識別する module_id ラベルまたは version_id ラベルでフィルタします。Cloud Monitoring では、この指標の値の経時的な変化を確認できます。

  3. インスタンス数指標の値に 2 を掛けて、使用中の IP アドレス数を見積もります。

IP アドレス枯渇対策

多数の App Engine ワークロードがある場合、ダイレクト VPC 下り（外向き）で RFC 1918 プライベート IP アドレス空間を使用すると、IP の枯渇の問題が発生する可能性があります。次の方法は、代替の IP アドレス範囲を使用して IP アドレスの枯渇を管理するのに役立ちます。

RFC 1918 以外の IPv4 アドレスを使用する

App Engine は、RFC 1918 IPv4 アドレス範囲のほかに、RFC 6598 範囲とクラス E/RFC 5735 範囲もサポートしています。すべてのGoogle Cloud サービスと機能は、VPC ネットワーク、Cloud Load Balancing、Private Service Connect など、RFC 1918 以外の範囲で動作します。

互換性を最大限に高めるには、RFC 6598（100.64.0.0/10）範囲から始めることをおすすめします。この範囲を他の場所ですでに使用している場合は、代わりにクラス E/RFC 5735（240.0.0.0/4）を検討してください。クラス E は 2 億 6, 800 万を超える IP アドレスを使用できる巨大な空間であるため、長期的な成長をサポートできます。ただし、クラス E にはいくつかの制限があります。たとえば、Windows や一部のオンプレミス ハードウェアではサポートされていません。IPv4 クラス E アドレス空間を活用して GKE での IPv4 枯渇の問題を軽減するをご覧ください。

Cloud NAT または Private Service Connect を使用する

App Engine ワークロードが RFC 1918 以外の範囲にあり、RFC 1918 のみを受け入れるオンプレミスの宛先にアクセスする必要がある場合は、次のいずれかの解決策を選択します。

  • ハイブリッド NAT を使用して、小さな RFC 1918 範囲を介したアドレス変換と下り（外向き）送信を実施します。
  • オンプレミス サービスを Private Service Connect ハイブリッド サービスとして公開します。

IPv4 と IPv6（デュアルスタック）のサブネットを使用する

IPv4 の枯渇を軽減することはできませんが、アプリを IPv6 に移行することを検討してください。今後 IPv4 の枯渇の問題が発生しないように、デュアルスタック リソースを設定します。

ポートの枯渇を軽減する対策

次のセクションでは、App Engine でポートの枯渇を軽減するための対策について説明します。

接続プールを使用して接続を再利用する

App Engine アプリから単一の宛先 IP アドレスに大量のリクエストを送信する場合は、接続プールを使用して、宛先への接続を維持して再利用します。1 つの IP アドレスへの接続率が高いと、アウトバウンド ポートが使い果たされ、接続拒否エラーが発生する可能性があります。

パフォーマンスとスループットの対策

このセクションでは、インターネットと Google サービスへのネットワーク パフォーマンスとスループットを改善するためのスケーラブルなオプションについて説明します。

サポートされているランタイムを使用する

ダイレクト VPC 下り（外向き）は、標準の第 2 世代のランタイムでのみサポートされています。サポートされているランタイムは、標準の言語実装を実行し、最新のライブラリ統合をサポートし、より高速で堅牢なネットワーキング パフォーマンスを提供します。

ダイレクト VPC 下り（外向き）を使用して下り（外向き）ネットワーク スループットを高速化する

ネットワーク下り（外向き）接続全体でのスループットを向上させるには、ダイレクト VPC 下り（外向き）を使用して VPC ネットワーク経由でトラフィックをルーティングします。

例 1: インターネットへの外部トラフィック

外部トラフィックを公共のインターネットに送信する場合は、app.yaml ファイルで vpc_egress フィールドを all-traffic に設定して、すべてのトラフィックを VPC ネットワーク経由でルーティングします。このアプローチでは、公共のインターネットに接続するように Cloud NAT を設定する必要があります。

App Engine サービスに Cloud NAT を設定するには、静的アウトバウンド IP アドレスを設定するをご覧ください。Public NAT または Private NAT のダイレクト VPC 下り（外向き）で使用する Cloud NAT ゲートウェイの設定については、Cloud NAT のダイレクト VPC 下り（外向き）の相互作用をご覧ください。

例 2: Google API への内部トラフィック

ダイレクト VPC 下り（外向き）を使用して Cloud Storage などの Google API にトラフィックを送信する場合は、次のいずれかを選択します。

  • プライベート Google アクセスで private-ranges-only（デフォルト）を指定します。
    1. app.yaml ファイルで vpc_egress: private-ranges-only を設定します。
    2. 限定公開の Google アクセスを有効にします。
    3. プライベート Google アクセス用に DNS を構成します。ターゲット ドメイン（storage.googleapis.com など）が次のいずれかの内部 IP アドレス範囲にマッピングされていることを確認します。
      • 199.36.153.8/30
      • 199.36.153.4/30
  • プライベート Google アクセスで all-traffic を指定します。
    1. app.yaml ファイルで vpc_egress: all-traffic を設定します。
    2. 限定公開の Google アクセスを有効にします。

App Engine のデフォルトの MTU 設定を使用する

App Engine で VPC ネットワークを使用する場合は、VPC ネットワークの最大伝送単位（MTU）設定を変更しないでください。代わりに、デフォルトの MTU（1,460 バイト）を使用します。

費用に関する考慮事項

リソースのネットワーキング オプションを構成する際は、次の点を考慮してください。

  • リソースを同じ場所に配置する: App Engine リソースを、Cloud SQL、Firestore、Cloud Storage バケットなどのバックエンド データベースと同じリージョンにデプロイします。同じリージョン内の Google Cloud リソース間のデータ転送は無料です。
  • ダイレクト VPC 下り（外向き）に切り替える: トラフィックを内部 VPC ネットワーク リソースに安全にルーティングする場合は、サーバーレス VPC アクセス コネクタからダイレクト VPC 下り（外向き）に切り替えることを検討してください。ダイレクト VPC 下り（外向き）では、ベースラインのコンピューティング料金が発生しないため、コネクタ インスタンスに関連するベースラインのコンピューティング オーバーヘッドとアイドル費用がなくなります。
  • Cloud CDN を使用する: App Engine リソースの前に Cloud CDN を配置して、静的アセットとキャッシュに保存可能なコンテンツをオフロードします。エッジからデータを提供すると、App Engine から直接標準のインターネット下り（外向き）料金を支払うよりも大幅に安くなります。デフォルトの appspot.com URL で Cloud CDN を直接有効にすることはできません。代わりに、サーバーレス ネットワーク エンドポイント グループ（NEG）バックエンドを持つ外部アプリケーション ロードバランサを介してリクエストをルーティングします。詳細については、App Engine を使用してグローバル外部アプリケーション ロードバランサを設定するをご覧ください。
  • インターネットの下り（外向き）をモニタリングする: リージョン境界を越える、またはパブリック インターネットに送信されるアウトバウンド トラフィックには、標準料金が発生します。リージョンの境界を越えるアウトバウンド トラフィックにモニタリングの重点を置きます。

詳細については、App Engine の料金を確認するか、料金計算ツールで費用を見積もってください。

次のステップ