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、負荷分散プロトコル転送の転送ルールをサポートします。GRE を使用すると、SASESD-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 ネットワークに関する考慮事項をご覧ください。

デフォルト ネットワーク

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

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)用に予約されています。
プライベートに再利用されたパブリック 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 アドレスは http://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 アドレスに接続するサードパーティのモニタリングを構成する場合は、このことを考慮する必要があります。

下りスループット容量

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

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 アドレスを受け取ります。サブネットはリージョン リソースであるため、インスタンスは、ゾーンを含む同じリージョンのサブネットに関連するネットワーク インターフェースを持つことができます。

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

レイテンシ

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 日間トラッキングされます。

次のステップ