VPC ネットワークの概要

Virtual Private Cloud(VPC)ネットワークは、Andromeda を使用して Google の本番環境ネットワーク内に実装された物理ネットワークを仮想化したネットワークです。VPC ネットワークには次の機能があります。

  • Google Kubernetes Engine(GKE)クラスタApp Engine フレキシブル環境インスタンスなどの Compute Engine 仮想マシン(VM)インスタンスや、Compute Engine VM 上に構築された他の Google Cloud プロダクトに向けた接続を提供します。
  • 内部 HTTP(S) 負荷分散用のネイティブな内部 TCP / UDP 負荷分散システムとプロキシ システムを提供します。
  • Cloud VPN トンネルと Cloud Interconnect アタッチメントを使用してオンプレミス ネットワークに接続します。
  • Google Cloud の外部ロードバランサからバックエンドにトラフィックを分散します。

プロジェクトには複数の VPC ネットワークを設定できます。この設定を禁止する組織のポリシーを作成しない限り、新しいプロジェクトは、各リージョンに 1 つのサブネットワーク(サブネット)を持つデフォルトネットワーク(自動モード VPC ネットワーク)が設定された状態で開始されます。

仕様

VPC ネットワークの特性は次のとおりです。

  • 関連ルート、ファイアウォール ルールを含む VPC ネットワークはグローバル リソースです。特定のリージョンやゾーンには関連付けられていません

  • サブネットはリージョン リソースです。サブネットごとに IP アドレスの範囲が定義されます。

  • インスタンス間のトラフィックは、ネットワークのファイアウォール ルールで制御できます。ルールは VM 自体に実装されるため、トラフィックは VM から離れるとき、または到着するときにのみ制御され、ログに記録されます。

  • VPC ネットワーク内のリソースにはネットワーク ファイアウォール ルールが適用されます。こうしたリソースは、内部(プライベート)IPv4 アドレスを使用して相互に通信できます。詳細については、ネットワーク内の通信をご覧ください。

  • 内部 IP アドレスを持つインスタンスは、Google API およびサービスと通信できます。詳細については、サービスのプライベート アクセス オプションをご覧ください。

  • ネットワーク管理は、Identity and Access Management(IAM)のロールを使用して保護できます。

  • 組織共有 VPC を使用して、共通ホスト プロジェクト内で VPC ネットワークを維持できます。同じ組織内の他のプロジェクトの承認済み IAM メンバーは、共有 VPC ネットワークのサブネットを使用するリソースを作成できます。

  • VPC ネットワーク ピアリングを使用して、異なるプロジェクトや組織の VPC ネットワークと VPC ネットワークを接続できます。

  • ハイブリッド環境の VPC ネットワークは、Cloud VPN または Cloud Interconnect を使用して安全に接続できます。

  • VPC ネットワークは、Cloud VPN のトラフィックを除く GRE トラフィック(ベータ版)、Cloud Interconnect、Cloud NAT、負荷分散プロトコル転送の転送ルールをサポートします。GRE を使用すると、セキュア アクセス サービスエッジ(SASE)や SD-WAN などのサービスを使用できます。

  • VPC ネットワークは、IPv4 ユニキャスト トラフィックのみをサポートします。ネットワーク内でのブロード キャストマルチキャスト、または IPv6 トラフィックはサポートされていません。VPC ネットワーク内の VM は、IPv4 の宛先のみに送信でき、IPv4 の送信元からのトラフィックのみを受信できます。ただし、グローバル ロードバランサの IPv6 アドレスを作成することは可能です。

ネットワークとサブネットの用語

サブネットとサブネットワークという用語は同義語です。Google Cloud Console、gcloud コマンド、API ドキュメントでは同じ意味で使用されます。

サブネットは(VPC)ネットワークと同じではありません。Google Cloud では、ネットワークとサブネットは異なる種類のオブジェクトです。

ネットワークとサブネット

各 VPC ネットワークはサブネットと呼ばれる、区分された 1 つまたは複数の有用な IP 範囲で構成されます。各サブネットはリージョンに関連付けられています。VPC ネットワークには、IP アドレス範囲が関連付けられません。IP 範囲はサブネットに対して定義されています

ネットワークを使用するには、そのネットワークに少なくとも 1 つのサブネットが必要です。自動モード VPC ネットワークは、各リージョンのサブネットを自動的に作成します。カスタムモード VPC ネットワークはサブネットなしで開始し、サブネットの作成を完全に制御できます。リージョンごとに複数のサブネットを作成できます。自動モード VPC ネットワークとカスタムモード VPC ネットワークの違いについては、VPC ネットワークの種類を参照してください。

Google Cloud でリソースを作成する場合は、ネットワークとサブネットを選択します。インスタンス テンプレート以外のリソースの場合は、ゾーンまたはリージョンも選択します。ゾーンを選択すると、その親リージョンが暗黙的に選択されます。サブネットはリージョン オブジェクトであるため、リソースに選択したリージョンによって、使用できるサブネットが決まります。

  • インスタンスを作成する場合は、ゾーン、ネットワーク、サブネットを選択します。選択可能なサブネットは、選択したリージョンのサブネットに限定されます。Google Cloud は、サブネットで使用可能なアドレス範囲から IP アドレスを取得し、インスタンスに割り当てます。

  • マネージド インスタンス グループを作成する場合は、グループの種類に応じてゾーンまたはリージョンを選択し、インスタンス テンプレートを選択します。選択可能なインスタンス テンプレートは、定義したサブネットがマネージド インスタンス グループと同じリージョンにあるテンプレートに限定されます。

    • インスタンス テンプレートはグローバル リソースです。インスタンス テンプレートを作成する場合は、ネットワークとサブネットを選択します。自動モード VPC ネットワークを選択する際に、自動サブネットを使用してサブネットの選択を延期できます。その場合は、テンプレートを使用するマネージド インスタンス グループのリージョンで利用可能なサブネットを選択することになります。定義上、自動モード VPC ネットワークはリージョンごとにサブネットを 1 つずつ持ちます。
  • Kubernetes コンテナ クラスタを作成する場合は、クラスタの種類に応じてゾーンまたはリージョンを選択し、ネットワークとサブネットを選択します。選択可能なサブネットは、選択したリージョンのサブネットに限定されます。

サブネット作成モード

Google Cloud では、サブネット作成モードで決定される 2 種類の VPC ネットワークを提供します。

  • 自動モード VPC ネットワークを作成すると、各リージョンから 1 つのサブネットがネットワーク内に自動的に作成されます。このような自動作成されたサブネットでは、一連の事前定義された IP 範囲10.128.0.0/9 CIDR ブロック)が使用されます。Google Cloud の新しいリージョンが利用可能になると、そのブロックの IP 範囲を使用して、リージョン内で新しいサブネットが自動モード VPC ネットワークに自動的に追加されます。自動作成されるサブネットに加え、10.128.0.0/9 以外の IP 範囲を使用して、選択したリージョン内でサブネットを自動モード VPC ネットワークに手動で追加できます。

  • カスタムモード VPC ネットワークを作成すると、サブネットは自動的に作成されません。この種類のネットワークでは、そのサブネットと IP 範囲を完全に制御できます。選択したリージョン内で、指定した IP 範囲を使用して、作成するサブネットを決定します。

VPC ネットワークは、自動モードからカスタムモードに切り替えることができます。これは一方方向の変換で、カスタムモード VPC ネットワークを自動モード VPC ネットワークに変更することはできません。どの種類のネットワークが必要かを判断するには、自動モード VPC ネットワークに関する考慮事項をご覧ください。

デフォルト ネットワーク

無効にしない限り、新しい各プロジェクトはデフォルト ネットワークで開始されます。デフォルト ネットワークは、事前入力ファイアウォール ルールがある自動モードの VPC ネットワークです。

compute.skipDefaultNetworkCreation 制約付きの組織のポリシーを作成することで、デフォルト ネットワークの作成を無効にできます。このポリシーを継承するプロジェクトには、デフォルト ネットワークがありません。

自動モード VPC ネットワークに関する考慮事項

自動モード VPC ネットワークは設定と使用が簡単であり、次の属性を持つユースケースに適しています。

  • 各リージョンにサブネットを自動的に作成すると便利である場合

  • サブネットの事前定義された IP 範囲が、異なる目的(たとえば、オンプレミス リソースへの Cloud VPN 接続)で使用する IP 範囲と重複しない場合

ただし、カスタムモード VPC ネットワークのほうが柔軟性が高く、本番環境に適しています。以下は、カスタムモード VPC ネットワークが推奨される、または必須とされるユースケースを示しています。

  • 各リージョンに 1 つのサブネットを自動的に作成する必要がない場合

  • 新しいリージョンが利用可能になるときに新しいサブネットを自動的に作成すると、手動で作成したサブネットや静的ルートによって使用される IP アドレスと重複したり、ネットワーク計画全体に影響したりする可能性がある場合

  • 使用するリージョンや IP アドレス範囲など、VPC ネットワーク内で作成されるサブネットを完全に制御する必要がある場合

  • すべての自動モード ネットワークのサブネットは同じ事前定義された IP アドレス範囲を使用するため、自動モード ネットワークを相互に接続できないことから、VPC ネットワーク ピアリングまたは Cloud VPN を使用して VPC ネットワークに接続する予定がある場合

サブネットの範囲

サブネットを作成するときは、プライマリ IP アドレス範囲を定義する必要があります。VM インスタンス、内部ロードバランサ、内部プロトコル転送の各リソースのプライマリ内部アドレスは、サブネットのプライマリ IP アドレス範囲から取得されます。必要に応じて、エイリアス IP 範囲でのみ使用されるセカンダリ IP アドレス範囲をサブネットに追加できます。ただし、インスタンスのエイリアス IP 範囲は、サブネットのプライマリ IP アドレス範囲またはセカンダリ IP アドレス範囲のいずれでも構成できます。

VPC ネットワーク内のすべてのサブネットの各プライマリまたはセカンダリ IP 範囲は、一意の有効な CIDR ブロックである必要があります。定義できるセカンダリ IP 範囲の数については、ネットワークごとの制限をご覧ください。

サブネットが、事前定義された連続した CIDR ブロックを形成する必要はありませんが、必要に応じて連続させることができます。たとえば、自動モード VPC ネットワークでは事前定義された自動モード IP 範囲に収まるサブネットが作成されます。

詳細については、サブネットの操作をご覧ください。

有効な範囲

サブネットのプライマリ IP アドレス範囲とセカンダリ IP アドレス範囲は、リージョン内部 IP アドレスです。次の表に、有効な範囲を示します。

範囲 説明
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
プライベート IP アドレス RFC 1918
100.64.0.0/10 共有アドレス空間 RFC 6598
192.0.0.0/24 IETF プロトコルの割り当て RFC 6890
192.0.2.0/24(TEST-NET-1)
198.51.100.0/24(TEST-NET-2)
203.0.113.0/24(TEST-NET-3)
ドキュメント RFC 5737
192.88.99.0/24 IPv6 から IPv4 へのリレー(サポート終了)RFC 7526
198.18.0.0/15 ベンチマーク テスト RFC 2544
240.0.0.0/4

RFC 5735RFC 1112 に記載されているとおり、将来の使用(クラス E)用に予約されています。

一部のオペレーティング システムではこの範囲を使用できません。この範囲を使用するサブネットを作成する前に、OS でサポートされていることを確認してください。

プライベートに再利用されたパブリック IP アドレス この表に記載されている RFC 範囲と制限付きセットの一部ではない IP アドレスが含まれます。これらのアドレスをサブネット範囲として使用する場合、Google Cloud はそれらのアドレスにトラフィックを公開しません。

VPC ネットワーク ピアリングの場合、パブリック IP アドレスのサブネット ルートは自動的に交換されません。サブネット ルートは自動的にエクスポートされますが、使用するにはピア ネットワークを明示的に構成する必要があります。

サブネット範囲には次の制約があります。

  • サブネットの範囲は、制限付きの範囲よりも狭い範囲または緩い範囲に設定することはできません。たとえば、169.0.0.0/8 は制限された範囲であるリンクローカル範囲 169.254.0.0/16(RFC 3927)と重複しているため、有効なサブネット範囲ではありません。

  • サブネット範囲は、RFC 範囲(前の表で説明)とプライベートで使用されるパブリック IP アドレス範囲にまたがることはできません。たとえば、172.16.0.0/10 は RFC 1918 やパブリック IP アドレスと重複するため、有効なサブネット範囲ではありません。

  • サブネット範囲は複数の RFC 範囲にまたがることはできません。たとえば、192.0.0.0/8192.168.0.0/16(RFC 1918 から)と 192.0.0.0/24(RFC 6890 から)の両方を含むため、有効なサブネット範囲ではありません。ただし、プライマリ範囲が異なる 2 つのサブネットを作成できます。1 つは 192.0.0.0/16、もう 1 つは 192.0.0.0/24 です。どちらか一方をセカンダリ範囲にすると、両方の範囲を同じサブネット上で使用できます。

制限付きの範囲

次の表に示すように、制限付きの範囲には Google のパブリック IP アドレスと一般的に予約されている RFC 範囲が含まれます。これらの範囲は、サブネット範囲には使用できません。

範囲 説明
Google Cloud Netblock を含む Google API とサービスのパブリック IP アドレス。 これらの IP アドレスは、https://gstatic.com/ipranges/goog.txt で確認できます。
199.36.153.4/30199.36.153.8/30 限定公開の Google アクセス固有の仮想 IP アドレス
0.0.0.0/8 現在の(ローカル)ネットワーク RFC 1122
127.0.0.0/8 ローカルホスト RFC 1122
169.254.0.0/16 リンクローカル RFC 3927
224.0.0.0/4 マルチキャスト(クラス D)RFC 5771
255.255.255.255/32 ブロードキャストの宛先アドレスの制限(RFC 8190RFC 919

サブネット内の予約済み IP アドレス

どのサブネットにも、プライマリ IP 範囲に 4 つの予約済み IP アドレスがあります。セカンダリ IP 範囲には予約済み IP アドレスがありません。

予約済み IP アドレス 説明
ネットワーク サブネットのプライマリ IP 範囲の最初のアドレス 10.1.2.010.1.2.0/24
デフォルト ゲートウェイ サブネットのプライマリ IP 範囲の 2 番目のアドレス 10.1.2.110.1.2.0/24
最後から 2 番目のアドレス 将来使用される可能性があるために Google Cloud によって予約されているサブネットのプライマリ IP 範囲の最後から 2 番目のアドレス 10.1.2.25410.1.2.0/24
ブロードキャスト サブネットのプライマリ IP 範囲の最後のアドレス 10.1.2.25510.1.2.0/24

自動モード IP 範囲

次の表に、自動モード VPC ネットワークで自動的に作成されるサブネットの IP 範囲を示します。このサブネットの IP 範囲は 10.128.0.0/9 CIDR ブロック内にあります。自動モード VPC ネットワークはリージョンごとに 1 つのサブネットで構築され、新しいリージョンで新しいサブネットを自動的に受信します。10.128.0.0/9 の未使用部分は Google Cloud で今後使用するために予約されています。

リージョン IP 範囲(CIDR) デフォルト ゲートウェイ 使用可能なアドレス(両端を含む)
asia-east1 10.140.0.0/20 10.140.0.1 10.140.0.2~10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 10.170.0.2~10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 10.146.0.2~10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2~10.174.15.253
asia-northeast3 10.178.0.0/20 10.178.0.1 10.178.0.2~10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2~10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2~10.148.15.253
asia-southeast2 10.184.0.0/20 10.184.0.1 10.184.0.2~10.184.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2~10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 10.166.0.2~10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 10.132.0.2~10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 10.154.0.2~10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 10.156.0.2~10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 10.164.0.2~10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2~10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2~10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2~10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 10.128.0.2~10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 10.142.0.2~10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 10.150.0.2~10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 10.138.0.2~10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 10.168.0.2~10.168.15.253
us-west3 10.180.0.0/20 10.180.0.1 10.180.0.2~10.180.15.253
us-west4 10.182.0.0/20 10.182.0.1 10.182.0.2~10.182.15.253

ルートとファイアウォール ルール

ルート

ルートは、インスタンスから出るパケット(下りトラフィック)のパスを定義します。Google Cloud のルートは、システム生成とカスタムの 2 つのカテゴリに分かれています。

新しいネットワークはすべて、以下の 2 つのタイプのシステム生成ルートで開始します。

  • デフォルト ルートは、VPC ネットワークから出るトラフィックのパスを定義します。これにより、インターネット アクセスの要件を満たす VM への一般的なインターネット アクセスが提供されます。また、限定公開の Google アクセスに対する一般的なパスも提供されます。

  • サブネット ルートは、サブネットに関連付けられた各 IP 範囲に対して作成されます。すべてのサブネットには、プライマリ IP 範囲のサブネット ルートが少なくとも 1 つあり、セカンダリ IP 範囲を追加すると、サブネット用に追加のサブネット ルートが作成されます。サブネット ルートは、サブネットを使用する VM に到達するトラフィックのパスを定義します。サブネット ルートを手動で削除することはできません。

カスタムルートは、手動で作成した静的ルートか、1 つ以上の Cloud Router によって自動的に保持される動的ルートのどちらかです。詳細については、カスタムルートをご覧ください。

Google Cloud でのルーティングの詳細については、ルートの概要をご覧ください。

動的ルーティング モード

各 VPC ネットワークには関連付けられた動的ルーティング モードがあり、これによってネットワーク内の Cloud Router の動作が制御されます。Cloud Router は、動的ルーティングを使用した Cloud VPN トンネルDedicated Interconnect、または Partner Interconnect を使用する他のネットワークに VPC ネットワークを接続する場合、VPC ネットワークを共有し、接続されたネットワークからカスタムの動的ルートを学習します。

  • リージョン動的ルーティングがデフォルトです。このモードでは、VPC ネットワーク内の所定の Cloud Router によって学習されたオンプレミス リソースへのルートが、Cloud Router と同じリージョン内のサブネットにのみ適用されます。カスタム アドバタイズによって変更されない限り、各 Cloud Router はそのリージョン内のサブネットへのルートのみをオンプレミス側と共有します。

  • グローバル動的ルーティングは、ネットワーク内のすべての Cloud Router の動作を変更するため、リージョンに関係なく、学習したオンプレミス リソースへのルートは VPC ネットワーク内のすべてのサブネットで使用できます。カスタム アドバタイズによって変更されない限り、各 Cloud Router は VPC ネットワーク内のすべてのサブネットへのルートを、そのオンプレミス側と共有します。

Cloud Router によって共有されるルートのセットをカスタマイズする方法については、カスタム アドバタイズをご覧ください。

動的ルーティング モードは、VPC ネットワークを作成または変更するときに設定できます。動的ルーティング モードは、リージョンを問わずグローバルに変更できます。また、その逆も可能です。手順については、動的ルーティング モードの変更をご覧ください。

ファイアウォール ルール

ファイアウォール ルールは、ネットワーク内の送信(下り)トラフィックと受信(上り)トラフィックの両方に適用されます。ファイアウォール ルールは、トラフィックが完全に特定のネットワーク内にある場合でも(VM インスタンス間の通信など)、トラフィックを制御します。

すべての VPC ネットワークには、2 つの暗黙のファイアウォール ルールがあります。1 つの暗黙ルールはほとんどの下りトラフィックを許可し、もう 1 つはすべての上りトラフィックを拒否します。暗黙のルールを削除することはできませんが、独自のルールでオーバーライドできます。Google Cloud は、ファイアウォール ルールに関係なく、常に多少のトラフィックをブロックします。詳細については、トラフィックのブロックをご覧ください。

どのファイアウォール ルールが特定の接続を許可または拒否したかを確認するには、ファイアウォール ルールのロギングをご覧ください。

通信とアクセス

ネットワーク内の通信

システム生成のサブネット ルートは、内部(プライベート)IP アドレスを使用して、ネットワーク内のインスタンス間でトラフィックを送信するためのパスを定義します。どのネットワークにも上り(内向き)トラフィックに対する暗黙の拒否ファイアウォール ルールが構成されているため、インスタンス間で通信を行う場合は、適切なファイアウォール ルールを構成する必要があります。

デフォルト ネットワークを除いて、インスタンスが相互に通信できるように、優先度がより高い上り(内向き)ファイアウォール ルールを明示的に作成する必要があります。デフォルト ネットワークには、暗黙的なルールに加えて、ネットワーク内でのインスタンス間の通信を許可する default-allow-internal ルールなど複数のファイアウォール ルールが含まれています。また、RDP や SSH などのプロトコルを許可する上り(内向き)ルールも含まれています。

デフォルト ネットワークに含まれるルールは、Cloud Console を使用して作成する新しい自動モード VPC ネットワークに適用するためのオプションとしても表示されます。

インターネット アクセスの要件

インスタンスにインターネットへの送信を許可するには、次の条件を満たす必要があります。

  • ネットワークには、有効なデフォルト インターネット ゲートウェイ ルート、または宛先 IP 範囲が最も一般的なカスタムルート(0.0.0.0/0)が必要です。このルートは、インターネットへのパスを定義します。詳細については、ルートをご覧ください。

  • ファイアウォール ルールでは、インスタンスからの下りトラフィックを許可する必要があります。優先度の高いルールでオーバーライドされない限り、下り(外向き)トラフィックの暗黙的に許可されたルールによって、すべてのインスタンスからの発信トラフィックが許可されます。

  • 以下のいずれかの条件を満たす必要があります。

    • インスタンスに外部 IP アドレスが必要です。外部 IP アドレスは、インスタンスの作成時または作成後にインスタンスに割り当てることができます。

    • インスタンスで、Cloud NAT または静的 0.0.0.0/0 ルートのターゲットであるインスタンス ベースのプロキシを使用できる必要があります。

App Engine の通信とアクセス

VPC ファイアウォール ルールは、Compute Engine VM などの VPC ネットワークで実行されるリソースに適用されます。App Engine インスタンスの場合、ファイアウォール ルールは次のように動作します。

  • App Engine スタンダード環境: 上り(内向き)トラフィックには App Engine ファイアウォール ルールのみが適用されます。App Engine スタンダード環境インスタンスは VPC ネットワーク内で実行されないため、VPC ファイアウォール ルールは適用されません。

  • App Engine フレキシブル環境: 上り(内向き)トラフィックには App Engine と VPC の両方のファイアウォール ルールが適用されます。受信トラフィックは、両方のタイプのファイアウォール ルールで許可されている場合にのみ許可されます。送信トラフィックには、VPC ファイアウォール ルールが適用されます。

App Engine インスタンスへのアクセスを制御する方法の詳細については、アプリのセキュリティをご覧ください。

外部 IP アドレスへの Traceroute

Google Cloud では、内部的な理由から、Google のネットワーク内のネクストホップを通過するパケットの TTL カウンタが増加します。traceroutemtr などのツールでは、一部のホップで TTL が期限切れにならないため、結果が不完全になることがあります。Google のネットワーク内外のホップは、次のような状況では表示されません。

  • Compute Engine インスタンスから外部 IP アドレス(インターネット上の他の Google Cloud リソースや宛先の外部 IP アドレスを含む)にパケットを送信する場合。

  • Compute Engine インスタンスまたは他の Google Cloud リソースに関連付けられた外部 IP アドレスにパケットを送信する場合。

非表示のホップ数は、インスタンスの Network Service Tiers、リージョンなどの要素によって異なります。ホップ数が少ない場合は、すべて非表示にできます。traceroute または mtr の結果からホップが欠落していても、送信トラフィックが破棄されるわけではありません。

この動作の回避策はありません。VM に関連付けられた外部 IP アドレスに接続するサードパーティのモニタリングを構成する場合は、このことを考慮する必要があります。

下り(外向き)スループット容量

ネットワーク スループットの情報は、[ネットワーク帯域幅] セクションで確認できます。

パケットサイズ

パケットサイズに関する情報は、最大伝送単位(MTU)をご覧ください。

VPC ネットワークの例

次の例では、2 つのリージョンに 3 つのサブネットがあるカスタムモード VPC ネットワークを示します。

VPC ネットワークの例(クリックして拡大)
VPC ネットワークの例(クリックして拡大)
  • subnet1 は、us-west1 リージョンで 10.240.0.0/24 として定義されています。
    • us-west1-a ゾーン内の 2 つの VM インスタンスはこのサブネットにあります。これらの IP アドレスは、subnet1 の使用可能なアドレス範囲から取得されます。
  • subnet2 は、us-east1 リージョンで 192.168.1.0/24 として定義されています。
    • us-east1-a ゾーン内の 2 つの VM インスタンスはこのサブネットにあります。これらの IP アドレスは、subnet2 の使用可能なアドレス範囲から取得されます。
  • subnet3 は、us-east1 リージョンで 10.2.0.0/16 として定義されています。
    • us-east1-a ゾーンの 1 つの VM インスタンスと us-east1-b ゾーンの 2 つ目のインスタンスは、subnet3 にあり、それぞれが使用可能な範囲から IP アドレスを受け取ります。サブネットはリージョン リソースであるため、インスタンスは、ゾーンを含む同じリージョンのサブネットに関連するネットワーク インターフェースを持つことができます。

最大伝送単位

VPC ネットワークのデフォルトの最大伝送単位(MTU)1460 バイトです。ただし、MTU が 1500 バイトになるように VPC ネットワークを構成できます。

MTU は、ネットワーク レイヤ プロトコルでサポートされる、ヘッダーとデータの両方を含めた最大パケットのサイズ(バイト単位)です。Google Cloud では VPC ネットワークごとに MTU を設定します。そのネットワークを使用する VM インスタンスもその MTU を使用するように構成する必要があります。VM が DHCP を使用して IP アドレスをリクエストするときに、ネットワークの MTU の設定が VM に通知されます。DHCP オプション 26 にネットワークの MTU が含まれます。

MTU は、UDP トラフィックと TCP トラフィックの両方に影響します。

  • Don't-Fragment フラグが設定されている場合、宛先で受信可能なサイズより大きい UDP パケットや、宛先までのパス上にある一部のネットワーク リンクの最大 MTU を超える UDP パケットはドロップされます。ドロップされた場合、Fragmentation-Needed タイプの ICMP パケットが送信元に返されます。PMTUD をご覧ください。
  • Don't-Fragment フラグが設定されていない場合、宛先で受信可能なサイズより大きい UDP パケットや、宛先までの一部のネットワーク リンクの最大 MTU を超える UDP パケットは断片化されます。この断片化は不一致が検出された時点で行われます。断片化は中間ルーターで発生することも、送信されるパケットが MTU より大きい場合は送信元で行われることもあります。
  • TCP は、接続の確立時に最大セグメント サイズ(MSS)をネゴシエートします。その後、接続の両方のエンドポイントで小さいほうの MTU サイズにパケットが分割されます。

VM と MTU の設定

Google 提供の OS イメージに基づく Linux VM の場合、その作成時に VPC ネットワークの MTU がインターフェースの MTU に自動的に設定されます。VM に複数のネットワーク インターフェースがある場合、接続されたネットワークの MTU が各インターフェースに設定されます。VM を実行している VPC の MTU を変更する場合は、VM を停止して再起動し、新しい MTU を取得する必要があります。VM が再起動すると、変更されたネットワーク MTU が DHCP から通知されます。

Windows VM のインターフェースは、起動時に VPC ネットワークの MTU を使用するように自動的に構成されません。代わりに、Google 提供の OS イメージに基づく Windows VM には固定の MTU 1460 が構成されています。各 Windows VM で次のコマンドを実行して、MTU を設定します。netsh interface ipv4 set subinterface NAME mtu=1500 store=persistent

カスタム イメージを使用する VM で MTU 設定を確認します。VPC ネットワークの MTU が優先される可能性もありますが、MTU が固定値に設定されている可能性もあります。

予期しないネットワーク接続を最小限に抑えるため、Google Cloud では次の手順で VPC ネットワークの MTU を変更することをおすすめします。

  1. VPC ネットワーク内のすべての VM を停止します。
  2. VPC ネットワークの MTU を変更します。
  3. VPC ネットワーク内のすべての VM を起動します。Google ゲスト環境を備えた Linux VM と、DHCP オプション 26 を使用して MTU を設定した VM の場合、起動時に MTU が正しく設定されます。
  4. Windows VM と MTU が固定されている VM の場合は、新しい MTU 値を使用するように構成します。

別の MTU ネットワークへのサービスの移行

既存のネットワークの MTU を変更する代わりに、新しいネットワークの新しい VM にサービスを移行することもできます。その場合、移行中にすべての VM からアクセス可能なサーバー(データベース サーバーなど)が必要になります。次の一般的な方法を使用すると、移行を適切に行うことができます。

  1. 新しい MTU で新しいネットワークを作成します。
  2. 新しいネットワークで必要なファイアウォール ルールとルートを作成します。
  3. 古いネットワークで複数のネットワーク インターフェースを持つ VM を作成します。1 つのインターフェースは新しい MTU を使用して新しいネットワークに接続し、もう 1 つは古い MTU を使用して古いネットワークに接続します。
  4. この新しい VM を既存の VM のセカンダリ サーバーとして構成します。
  5. プライマリ サーバーをセカンダリ サーバーにフェイルオーバーします。
  6. 新しいネットワークで新しい VM を作成します。イメージを最初から作成することも、既存の VM のスナップショットを作成して新しい永続ディスクで使用することもできます。
  7. 稼働しているサーバーを使用するように、これらの VM を構成します。
  8. トラフィックを新しい VM に移行します。
  9. 古いネットワークを削除する場合は、新しいネットワークで新しいサーバーを作成し、それを既存のサーバーと同期してフェイルオーバーします。
  10. 古いサーバーと古いネットワークを削除します。

MTU の不一致

MTU の不一致は、通信を行う 2 つの VM で MTU の設定が異なる状態を意味します。これにより、接続の問題が発生することがあります。インスタンスをルーターとして使用し、VM 内で Kubernetes を使用しているケースもあります。

ほとんどの場合、異なる MTU のインスタンス間の TCP 接続は、MSS ネゴシエーションによって成功しますが、その場合、接続の両端で低いほうの MTU が使用されます。

ピアリングされる VPC ネットワーク間での MTU の違い

VPC ネットワーク ピアリングがネットワークの MTU の違いを処理する方法については、MTU に関する考慮事項をご覧ください。

Cloud VPN での MTU の違い

Cloud VPN と MTU の詳細については、トンネル MTU をご覧ください。

Cloud Interconnect での MTU の違い

Cloud Interconnect の現在の MTU は 1,440 です。

通信する VM の MTU が 1500 の場合、MSS クランプにより TCP 接続の MTU が 1440 に変更され、TCP トラフィックが転送されます。

MSS クランプは UDP パケットに影響しません。VPC ネットワークの MTU が 1500 の場合、1,412 バイトを超える UDP データグラム(1,412 バイトの UDP データ + 8 バイトの UDP ヘッダー + 20 バイトの IPv4 ヘッダー = 1,440 バイト)はドロップされます。その場合、次のいずれかを行います。

  • 接続された VPC ネットワークの MTU を 1,460 に下げる。
  • 小さい UDP パケットを送信するようにアプリケーションを調整する。

ネットワーク パフォーマンス

レイテンシ

Google Cloud ネットワークで測定されたリージョン間のレイテンシは、ライブ ダッシュボードで確認できます。ダッシュボードには、PerfKit Benchmarker を使用してこれらの結果を再現するための、Google Cloud のリージョン間レイテンシとスループットのパフォーマンス指標の中央値が表示されます。

Google Cloud は通常、同じゾーン内の c2-standard-4 VM インスタンス間で、50 パーセンタイルで 55 マイクロ秒未満の往復のレイテンシと、99 パーセンタイルで 80 マイクロ秒未満のテール レイテンシを測定します。

Google Cloud は通常、同じ低レイテンシ ネットワーク内の c2-standard-4 VM インスタンス間で、50 パーセンタイルで 45 マイクロ秒未満の往復のレイテンシと、99 パーセンタイルで 60 マイクロ秒未満のテール レイテンシを測定します(コンパクト プレースメント ポリシー)。コンパクト プレースメント ポリシーでは、VM が物理的に同じ低レイテンシ ネットワーク内に配置されるため、ネットワーク レイテンシが短縮されます。

手法: ゾーン内レイテンシは、C2 インスタンスが有効なすべてのゾーンの C2 タイプの VM 間で netperf TCP_RR ベンチマークを常に実行するブラックボックス プローバーでモニタリングされます。コンパクト プレースメント ポリシーの有無にかかわらず、P50 と P99 の結果を収集します。TCP_RR ベンチマークは、トランザクション レートを測定してリクエスト / レスポンスのパフォーマンスを測定します。アプリケーションに最適なレイテンシが必要な場合は、C2 インスタンスをおすすめします。

パケットロス

Google Cloud は、すべてのリージョン間での定期的な往復ロスを測定することで、リージョン間のパケットロスを追跡します。Google では、これらの測定値の世界平均を 0.01% 以下にすることを目標としています。

手法: VM 間のブラックボックス プローバーは、ping を使用してすべてのゾーンペアのパケットロスをモニタリングし、その結果を 1 つのグローバルな損失指標に集約します。この指標は 1 日間トラッキングされます。

次のステップ