Google Cloud では、仮想ネットワーク インターフェース（vNIC）や IP アドレスごとではなく、コンピューティング インスタンスごとの帯域幅が考慮されます。インスタンスのマシンタイプで最大限可能な下り（外向き）レートが定義されていますが、そのレートに達するのは特定の状況に限られます。
このページでは、デプロイ計画に役立つ想定値について説明します。帯域幅は、次の 2 つの基準で分類されます。
- 下り（外向き）または上り（内向き）: このページで使われているように、下り（外向き）と上り（内向き）とは、常に Google Cloud インスタンスから見た方向を指します。
- Google Cloud インスタンスから送信されるパケットは、下り（外向き）トラフィック（アウトバウンド トラフィック）になります。
- Google Cloud VM に送信されるパケットは、上り（内向き）トラフィック（インバウンド トラフィック）になります。
- パケットのルーティング方法: ネクストホップが VPC ネットワーク内にあるルートまたは VPC ネットワーク外のルートを使用して、パケットを送信側インスタンスから、あるいは受信側インスタンスへとルーティングできます。
仮想ネットワーク インターフェース（vNIC）や vNIC あたりの IP アドレスを追加しても、コンピューティング インスタンスの上り（内向き）または下り（外向き）の帯域幅は増加しません。たとえば、22 個の vCPU を備えた C3 VM では、下り（外向き）帯域幅の合計が 23 Gbps に制限されます。2 個の vNIC を使用して C3 VM を構成しても、VM の下り（外向き）帯域幅は vNIC あたり 23 Gbps ではなく、合計で 23 Gbps に制限されます。
このページの説明は、Compute Engine コンピューティング インスタンスと、Compute Engine インスタンスに依存するプロダクトを対象としています。たとえば、Google Kubernetes Engine ノードは Compute Engine インスタンスです。
帯域幅の概要
次の表に、帯域幅の想定値を示します。これらの値は、パケットがコンピューティング インスタンスから送信されるもの（下り）か、あるいはインスタンスで受信するもの（上り）かどうかと、パケット ルーティングの方法に基づいています。
下り（外向き）
| 帯域幅の想定値 | |
|---|---|
| VPC ネットワーク内のルーティング |
|
| VPC ネットワーク外のルーティング |
|
上り（内向き）
| 帯域幅の想定値 | |
|---|---|
| VPC ネットワーク内のルーティング |
|
| VPC ネットワーク外のルーティング |
|
下り（外向き）帯域幅
Google Cloud では、インスタンスあたりの最大下り（外向き）レートを使用して、アウトバウンド（下り）帯域幅を制限しています。これらのレートは、パケットを送信するコンピューティング インスタンスのマシンタイプと、パケットの宛先にアクセスするためのルートが VPC ネットワーク内または VPC ネットワーク外のどちらにあるかに基づいています。アウトバウンド帯域幅には、インスタンスのすべての NIC から送信されたパケットと、インスタンスに接続されているすべての Hyperdisk および Persistent Disk ボリュームに転送されるデータが含まれます。
インスタンスあたりの最大下り（外向き）帯域幅
インスタンスあたりの最大下り（外向き）帯域幅は、通常は vCPU あたり 2 Gbps ですが、マシンシリーズによってはいくつかの違いと例外があります。次の表に、VPC ネットワーク内でルーティングされるトラフィックの最大下り（外向き）帯域幅の範囲を示します。これは VM あたりの Tier_1 ネットワーキングのパフォーマンスではなく、標準ネットワーキング ティアに限定されたトラフィック帯域幅に関するものです。
| マシンシリーズ | 標準のインスタンスあたりの最大下り（外向き）帯域幅の最小値 | 標準のインスタンスあたりの最大下り（外向き）上限 |
|---|---|---|
| C4 と C4A | 10 Gbps | 100 Gbps |
| C3 | 23 Gbps | 100 Gbps |
| C3D | 20 Gbps | 100 Gbps |
| C2 および C2D | 10 Gbps | 32 Gbps |
| E2 | 1 Gbps | 16 Gbps |
| H3 | 該当なし | 200 Gbps |
| M3 と M1 | 32 Gbps | 32 Gbps |
| M2 | 32 Gbps | Intel Cascade Lake CPU プラットフォームでは 32 Gbps 他の CPU プラットフォームでは 16 Gbps |
| N4 | 10 Gbps | 50 Gbps |
| N2 および N2D | 10 Gbps | 32 Gbps |
| N1（vCPU が 1 個の VM を除く） | 10 Gbps | Intel Skylake CPU プラットフォームでは 32 Gbps Intel Skylake より前の CPU プラットフォームでは 16 Gbps |
| 1 個の vCPU、f1-micro、g1-small を備えた N1 マシンタイプ | 2 Gbps | 2 Gbps |
| T2D | 10 Gbps | 32 Gbps |
| X4 | 該当なし | 100 Gbps |
| Z3 | 23 Gbps | 100 Gbps |
すべてのマシンタイプのインスタンスあたりの最大下り（外向き）帯域幅の一覧は、次のそれぞれのマシン ファミリーのページで確認できます。
- C、E、N、T シリーズ: 汎用マシン ファミリー
- Z シリーズ: ストレージ最適化マシン ファミリー
- C2 シリーズと H シリーズ: コンピューティング最適化マシン ファミリー
- M シリーズと X シリーズ: メモリ最適化マシン ファミリー
インスタンスあたりの最大下り（外向き）帯域幅は必ずしも保証されません。実際の下り（外向き）帯域幅は、たとえば次のようなさまざまな要因によって減少する可能性があります。
- gVNIC と VirtIO の両方をサポートするコンピューティング インスタンスで gVNIC ではなく VirtIO を使用する場合
- パケットサイズ
- プロトコルのオーバーヘッド
- フロー数
- コンピューティング インスタンスのゲスト OS でのイーサネット ドライバの設定（チェックサム オフロード、TCP セグメンテーション オフロード（TSO）など）
- ネットワークの輻輳
- Persistent Disk I/O が他の下り（外向き）ネットワーク トラフィックと競合する状況では、最大ネットワーク帯域幅の 60% が Persistent Disk の書き込みに割り当てられ、残りの 40% が他の下り（外向き）ネットワーク トラフィックに割り当てられます。詳細については、ディスクのパフォーマンスに影響する要因をご覧ください。
インスタンスあたりの最大限可能な下り（外向き）帯域幅をできるだけ大きくするには、次のようにします。
- より大きいマシンタイプを使用して、VM あたりの Tier_1 ネットワーキング パフォーマンスを有効にします。
- ネットワーク トポロジでサポートされている、VPC ネットワーク最大伝送単位（MTU）の最大値を使用します。MTU を大きくすると、パケット ヘッダーのオーバーヘッドが削減され、ペイロード データのスループットが向上します。
- 最新バージョンの gVNIC ドライバを使用します。
- Titanium を使用する第 3 世代以降のマシンシリーズを使用して、ホスト CPU からネットワーク処理をオフロードします。
VPC ネットワーク内でルーティング可能な宛先への下り（外向き）
送信側インスタンスから見て VPC ネットワーク内にあるルートを使用してアクセス可能な宛先 IP アドレスについては、Google Cloud は次のルールを使用してアウトバウンド トラフィックを制限します。
- VM あたりの最大下り（外向き）帯域幅: インスタンスあたりの最大下り（外向き）帯域幅セクションをご覧ください。
- プロジェクトあたりのリージョン間下り（外向き）帯域幅: 内部宛先または内部宛先へのネクストホップが送信側インスタンスとは異なるリージョンにある場合、Google Cloud はリージョン間の最大下り（外向き）帯域幅の上限を適用します。ほとんどのお客様は、この上限に達することはありません。この上限についてご不明な点がある場合は、サポートケースを登録してください。
- Cloud VPN と Cloud Interconnect の上限: インスタンスから、ネクストホップの Cloud VPN トンネルまたは Cloud Interconnect VLAN アタッチメントによってルーティング可能な内部 IP アドレスを宛先としたトラフィックが送信される場合、下り（外向き）帯域幅には次の制限が適用されます。
- Cloud VPN トンネルあたりの最大パケットレートと帯域幅
- VLAN アタッチメントあたりの最大パケットレートと帯域幅
- ECMP ルーティングを使用して複数のネクストホップの Cloud VPN トンネルまたは Cloud Interconnect VLAN アタッチメントの帯域幅を最大限活用するには、複数の TCP 接続（一意の 5 タプル）を使用する必要があります。
VPC ネットワーク内でルーティング可能な宛先には、次の宛先のすべてが含まれます。これらの宛先には、送信側インスタンスから見て、ネクストホップがデフォルトのインターネット ゲートウェイではないルートによってアクセスできます。
- サブネット プライマリ IPv4 アドレス範囲とサブネット セカンダリ IPv4 アドレス範囲に含まれるリージョン内部 IPv4 アドレス。これには、これらの宛先リソースで使用される、プライベート IPv4 アドレス範囲とプライベートで使用されるパブリック IPv4 アドレス範囲に含まれるリージョン内部 IPv4 アドレスも該当します。
- 受信側インスタンスのネットワーク インターフェース（vNIC）のプライマリ内部 IPv4 アドレス。（送信側インスタンスが別のインスタンスの vNIC 外部 IPv4 アドレスに接続する場合、パケットはネクストホップのデフォルト インターネット ゲートウェイを使用してルーティングされるため、VPC ネットワーク内ではなく VPC ネットワーク外の宛先への下り（外向き）が適用されます）。
- 受信側インスタンスの vNIC のエイリアス IP 範囲内の内部 IPv4 アドレス。
- プロトコル転送または内部パススルー ネットワーク ロードバランサで使用される内部転送ルールの内部 IPv4 アドレス。
- 次に示す宛先リソースのグローバル内部 IPv4 アドレス。
- 次に示す宛先リソースで使用される内部 IPv6 サブネット アドレス範囲。
- デュアルスタックの受信側インスタンスの vNIC に割り当てられた
/96IPv6 アドレス範囲に含まれる IPv6 アドレス。 - プロトコル転送または内部パススルー ネットワーク ロードバランサで使用される内部転送ルールの
/96IPv6 アドレス範囲に含まれる IPv6 アドレス。
- デュアルスタックの受信側インスタンスの vNIC に割り当てられた
- 次に示す宛先リソースで使用される外部 IPv6 サブネット アドレス範囲（パケットが VPC ネットワーク内のサブネット ルートまたはピアリング サブネット ルートを使用してルーティングされる場合、あるいはデフォルトのインターネット ゲートウェイ ネクストホップを使用しない VPC ネットワーク内のカスタムルートを使用してルーティングされる場合）。
- デュアルスタックの受信側インスタンスの vNIC に割り当てられた
/96IPv6 アドレス範囲に含まれる IPv6 アドレス。 - プロトコル転送または外部パススルー ネットワーク ロードバランサで使用される外部転送ルールの
/96IPv6 アドレス範囲に含まれる IPv6 アドレス。
- デュアルスタックの受信側インスタンスの vNIC に割り当てられた
- 次の VPC ネットワーク ルートを使用してアクセスできるその他の宛先。
- 動的ルート
- 静的ルート（デフォルトのインターネット ゲートウェイのネクストホップを使用するルートを除く）
- ピアリング カスタムルート
次のリストは、最大限可能な帯域幅の値が最も大きいものから順に、送信側インスタンスから内部宛先へのトラフィックを並べたものです。
- 同じゾーン内のコンピューティング インスタンス間のトラフィック
- 同じリージョンの異なるゾーンのコンピューティング インスタンス間のトラフィック
- 異なるリージョンのコンピューティング インスタンス間のトラフィック
- コンピューティング インスタンスから Google Cloud API およびサービスへの限定公開の Google アクセスを使用してアクセスするトラフィック、またはインスタンスの外部 IP アドレスから Google API にアクセスするトラフィック。これには、Google API の Private Service Connect エンドポイントが含まれます。
VPC ネットワーク外の宛先への下り（外向き）
送信側インスタンスから見て VPC ネットワーク外にある宛先 IP アドレスについては、Google Cloud はアウトバウンド トラフィックを次のレート（最初に到達した方）で制限します。
インスタンスあたりの下り（外向き）帯域幅: コンピューティング インスタンスから VPC ネットワーク外の宛先へのすべての接続の最大帯域幅は、インスタンスあたりの最大下り（外向き）帯域幅または次のいずれかになります（いずれか小さい方）。
- 25 Gbps（Tier_1 ネットワーキングが有効な場合）
- 7 Gbps（Tier_1 ネットワーキングが有効でない場合）
- 1 Gbps（H3 インスタンスの場合）
- 物理 NIC あたり 7 Gbps（複数の物理 NIC をサポートしているマシンシリーズ（A3 など）の場合）
たとえば、
c3-standard-44インスタンスの VM あたりの最大下り（外向き）帯域幅は 32 Gbps ですが、c3-standard-44VM から外部宛先への接続の VM あたりの下り（外向き）帯域幅は、Tier_1 ネットワーキングが有効になっているかどうかに応じて 25 Gbps または 7 Gbps のいずれかになります。フローあたりの最大下り（外向き）レート: コンピューティング インスタンスから VPC ネットワーク外の宛先への一意の 5 タプル接続ごとの最大帯域幅は 3 Gbps です（ただし、H3 では 1 Gbps）。
プロジェクトあたりのインターネット下り（外向き）帯域幅: プロジェクトの各リージョンのコンピューティング インスタンスから VPC ネットワーク外の宛先へのすべての接続の最大帯域幅は、プロジェクトのインターネット下り（外向き）帯域幅の割り当てに基づいて定義されます。
VPC ネットワークの外部にある宛先には、次の宛先のすべてが含まれます。これらの宛先には、ネクストホップがデフォルトのインターネット ゲートウェイとなっている、送信側インスタンスの VPC ネットワーク内のルートでアクセスできます。
- 外部プロキシ ネットワーク ロードバランサと外部アプリケーション ロードバランサのグローバル外部 IPv4 および IPv6 アドレス。
- Google Cloud リソースのリージョン外部 IPv4 アドレス（VM vNIC 外部 IPv4 アドレス、外部プロトコル転送用の外部 IPv4 アドレス、外部パススルー ネットワーク ロードバランサ、Cloud NAT ゲートウェイへのレスポンス パケットなど）。
- 外部 IPv6 アドレス範囲を持つデュアルスタック サブネット内にあるリージョン外部 IPv6 アドレスで、デュアルスタック インスタンスの外部 IPv6 アドレス、外部プロトコル転送、外部パススルー ネットワーク ロードバランサで使用されるもの。このサブネットが、ピアリングされていない別の VPC ネットワーク内に配置されていることが要件となります。宛先 IPv6 アドレス範囲には、ネクストホップがデフォルトのインターネット ゲートウェイとなっている、送信側インスタンスの VPC ネットワーク内のルートを使用してアクセス可能である必要があります。外部 IPv6 アドレス範囲を持つデュアル スタック サブネットが同じ VPC ネットワークまたはピアリングされた VPC ネットワーク内に配置されている場合は、VPC ネットワーク内でルーティング可能な宛先への下り（外向き）をご覧ください。
- 送信側インスタンスの VPC ネットワーク内の静的ルートを使用してアクセス可能なその他の外部宛先（ルートのネクストホップがデフォルトのインターネット ゲートウェイとなっていることが前提）。
どの Google Cloud リソースがどのタイプの外部 IP アドレスを使用するかについて詳しくは、外部 IP アドレスをご覧ください。
上り（内向き）帯域幅
Google Cloud は、受信パケットが受信側コンピューティング インスタンスにルーティングされる方法に応じて、インバウンド（上り）帯域幅を処理します。
VPC ネットワーク内でルーティング可能な宛先への上り（内向き）
受信側インスタンスでは、そのマシンタイプ、オペレーティング システム、その他のネットワーク条件で許容される数だけのパケットを処理できます。Google Cloud では、VPC ネットワーク内の次のルートを使用してインスタンスに配信される受信パケットに対し、帯域幅の制限を設けていません。
- 受信側インスタンスの VPC ネットワーク内のサブネット ルート
- ピアリングされた VPC ネットワーク内のピアリング サブネット ルート
- ネクストホップが Cloud VPN トンネル、Cloud Interconnect（VLAN）アタッチメント、または受信側インスタンスの VPC ネットワーク内のルーター アプライアンス VM となっている、別のネットワーク内のルート
VPC ネットワーク内でルーティングされるパケットの宛先は次のとおりです。
- 受信側インスタンスのネットワーク インターフェース（NIC）のプライマリ内部 IPv4 アドレス。プライマリ内部 IPv4 アドレスは、サブネットのプライマリ IPv4 アドレス範囲から取得されるリージョン内部 IPv4 アドレスです。
- 受信側インスタンスの NIC のエイリアス IP 範囲内の内部 IPv4 アドレス。エイリアス IP 範囲は、サブネットのプライマリ IPv4 アドレス範囲またはセカンダリ IPv4 アドレス範囲のいずれかから取得されます。
- デュアルスタックの受信側インスタンスの NIC に割り当てられた
/96IPv6 アドレス範囲に含まれる IPv6 アドレス。コンピューティング インスタンスの IPv6 範囲は、次のサブネット IPv6 範囲から取得されます。- 内部 IPv6 アドレス範囲。
- 外部 IPv6 アドレス範囲（このセクションですでに一覧した VPC ネットワーク ルートのいずれかを使用して、受信パケットが内部で受信側インスタンスにルーティングされる場合）。
- 受信側インスタンスへの内部プロトコル転送で使用される転送ルール、または受信側インスタンスがロードバランサのバックエンドとなっている内部パススルー ネットワーク ロードバランサへの内部プロトコル転送で使用される転送ルールの内部 IPv4 アドレス。内部転送ルールの IPv4 アドレスは、サブネットのプライマリ IPv4 アドレス範囲から取得されます。
- 受信側インスタンスまたは受信側インスタンスがバックエンドとなっている内部パススルー ネットワーク ロードバランサへの内部プロトコル転送で使用される転送ルールの
/96IPv6 範囲に含まれる内部 IPv6 アドレス。内部転送ルールの IPv6 アドレスは、サブネットの内部 IPv6 アドレス範囲から取得されます。 - 受信側インスタンスまたは外部パススルー ネットワーク ロードバランサへの外部プロトコル転送で使用される転送ルールの
/96IPv6 範囲に含まれる外部 IPv6 アドレス。このセクションですでに一覧したルートのいずれかを使用して受信パケットが VPC ネットワーク内でルーティングされる場合、この受信側インタンスはロードバランサのバックエンドに該当します。外部転送ルールの IPv6 アドレスは、サブネットの外部 IPv6 アドレス範囲から取得されます。 - 受信側インスタンスをネクストホップ インスタンス（
next-hop-instanceまたはnext-hop-address）として使用するカスタム静的ルートの宛先範囲に含まれる IP アドレス。 - 受信側インスタンスが内部パススルー ネットワーク ロードバランサのバックエンドである場合、そのロードバランサ（
next-hop-ilb）のネクストホップを使用するカスタム静的ルートの宛先範囲に含まれる IP アドレス。
VPC ネットワーク外の宛先への上り（内向き）
Google Cloud では、VPC ネットワーク外のルートを使用して受信側インスタンスに配信される受信パケットに対して、次の帯域幅制限を適用します。ロード バランシングが伴う場合、帯域幅の上限は受信側インスタンスのそれぞれに個別に適用されます。
複数の物理 NIC をサポートしていないマシンシリーズの場合、該当するインバウンド帯域幅の制限は、すべての仮想ネットワーク インターフェース（VNIC）での合計として適用されます。トラフィック量は次のいずれかのレート（最初に到達した方）で制限されます。
- 1 秒あたり 1,800,000 パケット
- 30 Gbps
複数の物理 NIC（A3 など）をサポートするマシンシリーズの場合、該当するインバウンド帯域幅の制限は、各物理 NIC に個別に適用されます。トラフィック量は次のいずれかのレート（最初に到達した方）で制限されます。
- 物理 NIC あたり 1,800,000 パケット/秒
- 物理 NIC あたり 30 Gbps
VPC ネットワーク外のルートを使用してルーティングされるパケットの宛先は次のとおりです。
- 受信側インスタンスのネットワーク インターフェース（NIC）のいずれかに対して 1 対 1 の NAT アクセス構成で割り当てられている外部 IPv4 アドレス。
- 受信側インスタンスの VPC ネットワーク外のルートを使用して受信パケットがルーティングされる場合、デュアルスタックの受信インスタンスの vNIC に割り当てられた
/96IPv6 アドレス範囲に含まれる外部 IPv6 アドレス。 - 受信側インスタンスまたは受信側インスタンスがバックエンドとなっている外部パススルー ネットワーク ロードバランサへの外部プロトコル転送で使用される転送ルールの外部 IPv4 アドレス。
- 受信側インスタンスまたは外部パススルー ネットワーク ロードバランサへの外部プロトコル転送で使用される転送ルールの
/96IPv6 範囲に含まれる外部 IPv6 アドレス。VPC ネットワーク外のルートを使用して受信パケットがルーティングされる場合、受信側インスタンスがロードバランサのバックエンドであることが要件となります。 - Cloud NAT によって処理される確立済みのインバウンド レスポンス。
ジャンボ フレーム
ジャンボ フレームを送受信するには、コンピューティング インスタンスで使用する VPC ネットワークを構成する必要があります。この場合、最大伝送単位（MTU）をより大きい値（最大 8,896）に設定します。
MTU 値を大きくすると、パケットサイズが大きくなり、パケット ヘッダーのオーバーヘッドが減少するため、ペイロードのデータ スループットが向上します。
VM インスタンスでは gVNIC ドライバ バージョン 1.3 以降で、ベアメタル インスタンスでは IDPF ドライバで、ジャンボ フレームを使用できます。すべての Google Cloud 公開イメージに、これらのドライバが含まれているわけではありません。ジャンボ フレームのオペレーティング システムのサポートについて詳しくは、オペレーティング システムの詳細ページの [ネットワーク機能] タブをご覧ください。
ジャンボ フレームを完全にサポートしていない OS イメージを使用している場合は、gVNIC ドライバ バージョン v1.3.0 以降を手動でインストールできます。追加の機能とバグ修正を利用するには、Latest とマークされた gVNIC ドライバのバージョンをインストールすることをおすすめします。gVNIC ドライバは GitHub からダウンロードできます。
ゲスト OS で gVNIC ドライバのバージョンを手動で更新する方法については、サポートされていないオペレーティング システムでの使用をご覧ください。
受信キューと送信キュー
コンピューティング インスタンスの NIC または vNIC ごとに、ネットワークからのパケットを処理するための複数の受信キューと送信キューが割り当てられます。
- 受信キュー（RX）: パケットを受信するキュー。NIC は、ネットワークからパケットを受信すると、受信パケットの記述子をキューから選択して処理し、割り込みにより、vCPU コアに接続されたパケットキューを介してゲスト OS にパケットを渡します。RX キューがいっぱいで、パケットを入れるバッファもない場合、パケットは破棄されます。これは通常、選択したパケットキューに接続されている vCPU コアをアプリケーションが過剰に使用している場合に発生することがあります。
- 送信キュー（TX）: パケットを送信するためのキュー。ゲスト OS がパケットを送信すると、記述子が割り当てられて TX キューに配置されます。NIC は記述子を処理し、パケットを送信します。
デフォルト キューの割り当て
明示的に NIC のキュー数を割り当てていない限り、NIC ごとに固定数の RX キューと TX キューを割り当てる Google Cloud のアルゴリズムをモデル化できます。
- ベアメタル インスタンス
- ベアメタル インスタンスの場合、NIC は 1 つしかないため、キューの最大数は 16 になります。
- gVNIC ネットワーク インターフェースを使用する VM インスタンス
C4 インスタンスの場合、パフォーマンスを向上させるため、次の構成では固定数のキューを使用します。
- 2 つの vCPU を使用する Linux インスタンスの場合、キューの数は 1 です。
- 4 つの vCPU を持つ Linux インスタンスの場合、キュー数は 2 です。
他のマシンシリーズの場合、キュー数は、マシンシリーズが Titanium を使用するかどうかによって異なります。
Titanium を使用する第 3 世代（M3 を除く）以降のインスタンスの場合:
vCPU の数を vNIC の数（
num_vcpus/num_vnics）で割り、余りを破棄します。Titanium を使用しない第 1 世代と第 2 世代の VM の場合:
vCPU の数を NIC の数で割り、その結果を 2 で割ります（
num_vcpus/num_vnics/2）。余りを破棄します。
デフォルトのキュー数の計算を完了するには:
結果の数値が 1 未満の場合は、それぞれの vNIC に 1 個のキューが割り当てられます。
結果の数値が vNIC あたりの最大キュー数（
16）より大きいかどうかを確認します。16より大きい場合、計算結果は無視され、それぞれの vNIC に 16 個のキューが割り当てられます。
- VirtIO ネットワーク インターフェースまたはカスタム ドライバを使用する VM インスタンス
vCPU の数を NIC の数で割り、余りを破棄します（
[number of vCPUs/number of vNICs]）。結果の数値が 1 未満の場合は、それぞれの vNIC に 1 個のキューが割り当てられます。
結果の数値が vNIC あたりの最大キュー数（
32）より大きいかどうかを確認します。計算された数値が32より大きい場合、計算結果は無視され、それぞれの vNIC に 32 個のキューが割り当てられます。
例
次の例は、VM インスタンスのデフォルトのキュー数を計算する方法を示しています。
VM インスタンスが VirtIO を使用していて、16 個の vCPU と 4 個の vNIC がある場合、算出される数値は
[16/4] = 4になります。Google Cloud は、各 vNIC に 4 つのキューを割り当てます。VM インスタンスが gVNIC を使用していて、128 個の vCPU と 2 個の vNIC がある場合、算出される数値は
[128/2/2] = 32になります。Google Cloud は、各 vNIC に、最大限可能な vNIC あたりのキュー数を割り当てます。つまり、Google Cloud は vNIC ごとに16個のキューを割り当てます。
Linux システムでは、ethtool を使用して、Google Cloud によって vNIC ごとに割り当てられるキューの数より少ない vNIC を構成できます。
VM インスタンスのカスタムキューの割り当て
デフォルトのキュー割り当てを使用する代わりに、新しいコンピューティング インスタンスの作成時に各 vNIC にカスタムのキュー数（RX と TX の合計）を割り当てるには、Compute Engine API を使用します。
指定するカスタムのキュー数は、次のルールに従っている必要があります。
vNIC ごとに割り当て可能な最小キュー数は 1 です。
VM インスタンスの vNIC ごとに割り当て可能な最大キュー数は、ドライバの種類に応じて、vCPU 数または vNIC ごとの最大キュー数のうち少ない方になります。
- virtIO またはカスタム ドライバを使用する場合、最大キュー数は
32です。 - gVNIC を使用する場合、最大キュー数は
16です。ただし、最大キュー数が 32 の次の場合は例外です。- A2 インスタンスまたは G2 インスタンス
- TPU インスタンス
- Tier_1 ネットワーキングが有効になっている C2、C2D、N2、または N2D インスタンス
次の Confidential VM 構成の場合、最大キュー数は
8です。- C2D マシンタイプと N2D マシンタイプの AMD SEV
- N2D マシンタイプでの AMD SEV-SNP
- virtIO またはカスタム ドライバを使用する場合、最大キュー数は
コンピューティング インスタンスのすべての NIC にカスタムのキュー数を割り当てる場合、キュー数の割り当て合計は、インスタンスに割り当てられた vCPU の数以下にする必要があります。
vNIC のカスタムのキュー数はオーバーサブスクライブできます。つまり、VM インスタンスのすべての NIC に割り当てられたキュー数の合計は、インスタンスの vCPU 数を上回っていてもかまいません。カスタムのキュー数をオーバーサブスクライブするには、VM インスタンスが次の条件を満たしている必要があります。
- インスタンスで構成されているすべての NIC の vNIC タイプとして、gVNIC を使用していること。
- Tier_1 ネットワーキングをサポートするマシンタイプを使用していること。
- Tier_1 ネットワーキングが有効にされていること。
- インスタンスで構成されているすべての NIC に対してカスタムのキュー数を指定していること。
キューのオーバーサブスクリプションにより、VM インスタンスの最大キュー数は NIC 数の 16 倍になります。つまり、30 個の vCPU を使用するインスタンスに 6 個の NIC が構成されている場合、そのインスタンスには最大 96（16 * 6）個のカスタムキューを構成できます。
例
VM インスタンスに 8 個の vCPU と 3 個の vNIC がある場合、インスタンスの最大キュー数は vCPU の数、つまり 8 になります。たとえば、
nic0に 1 つのキュー、nic1に 4 つのキュー、nic2に 3 つのキューを割り当てたとします。この場合、他の 2 つの vNIC キューの割り当てを維持しながら、その後でnic2に 4 つのキューを割り当てることはできません。割り当てられたキューの合計が vCPU の数を超えることはできないためです。96 個の vCPU と 2 つの vNIC を備えた N2 VM がある場合、virtIO ドライバを使用すると、両方の vNIC に最大 32 個のキューを割り当てることができます。また、gVNIC ドライバを使用する場合は、それぞれに最大 16 個のキューを割り当てることができます。N2 VM の Tier_1 ネットワーキングを有効にすると、各 vNIC に最大 32 個のキューを割り当てることができます。この例では、割り当てられたキューの合計は常に vCPU の数以下になります。
また、一部の NIC にのみカスタムキュー数を割り当てて、Google Cloud が残りの NIC にキューを割り当てることもできます。vNIC ごとに割り当て可能なキューの数には、引き続き前述のルールが適用されます。構成の実現可能性をモデル化できます。構成が可能な場合は、このプロセスで Google Cloud が残りの vNIC に割り当てるキューの数も設定できます。
カスタムのキュー割り当てを使用して、vNIC のキューの合計を計算します。20 個の vCPU と 6 個の vNIC を持つ VM の例では、
nic0に 5 つのキュー、nic1に 6 つのキュー、nic2に 4 つのキューを割り当て、Google Cloud でnic3、nic4、nic5のキューを割り当てるとします。この例では、カスタム割り当てキューの合計は5+6+4 = 15になります。vCPU の数からカスタム割り当てキューの合計を引きます。この差が、Google Cloud がキューを割り当てる残りの vNIC の数より小さい場合、各 vNIC に 1 つ以上のキューが必要になるため、Google Cloud はエラーを返します。
20 個の vCPU と合計
15のカスタム割り当てキューを持つ VM の例では、Google Cloud が残りの vNIC（nic3、nic4、nic5）に割り当てることができるキューは残り20-15 = 5個となります。前の手順との整合性を取るため、この差を前の手順で残った vNIC の数で割り、余りの
⌊(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)⌋を破棄します。この計算の結果は常に小数ではなく、整数になります。Google Cloud は、計算した数が vNIC あたりの最大キュー数を超えない限り、計算した数に一致する数を残りの vNIC に割り当てます。vNIC の最大キュー数はドライバの種類によって異なります。
- virtIO またはカスタム ドライバを使用している場合、残りの vNIC について算出された vNIC あたりのキュー数が
32より大きければ、Google Cloud は残りの vNIC のそれぞれに32個のキューを割り当てます。 - gVNIC を使用して、残りの vNIC ごとに計算されたキューの数が
16または32の制限（VM 構成に応じて異なる）を超える場合、Google Cloud は残りの vNIC のそれぞれに16キューを割り当てます。
カスタムキュー数を構成する
1 つ以上の NIC または vNIC にカスタムのキュー数を使用するコンピューティング インスタンスを作成するには、次の手順を実施します。
次のコードサンプルでは、ネットワーク インターフェース タイプが GVNIC に設定され、VM ごとの Tier_1 ネットワーキング パフォーマンスが有効な状態で VM が作成されます。これらのコード例を使用すると、サポートされているマシンタイプで使用可能な最大キュー数とキューのオーバーサブスクリプションを指定できます。
gcloud
- 構成する vNIC インターフェースごとに 1 つのサブネットを使用できる VPC ネットワークがまだない場合は、作成します。
gcloud compute instances createコマンドを使用して、コンピューティング インスタンスを作成します。インスタンスに構成する vNIC ごとに--network-interfaceフラグを繰り返し、queue-countオプションを含めます。
gcloud compute instances create INSTANCE_NAME \
--zone=ZONE \
--machine-type=MACHINE_TYPE \
--network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
--network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
--network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2
次のように置き換えます。
INSTANCE_NAME: 新しいコンピューティング インスタンスの名前ZONE: インスタンスの作成先とするゾーン。MACHINE_TYPE: インスタンスのマシンタイプ。キュー数をオーバーサブスクライブするには、指定するマシンタイプが gVNIC と Tier_1 ネットワーキングをサポートしている必要があります。NETWORK_NAME: 以前に作成したネットワークの名前SUBNET_*: 以前に作成したサブネットのいずれかの名前QUEUE_SIZE: カスタムキューの割り当てで説明されているルールに従う vNIC のキュー数
Terraform
- 構成する vNIC インターフェースごとに 1 つのサブネットを使用できる VPC ネットワークがまだない場合は、作成します。
google_compute_instanceリソースを使用して、vNIC の特定のキュー数を指定したコンピューティング インスタンスを作成します。コンピューティング インスタンスに構成する vNIC ごとに--network-interfaceパラメータを繰り返し、queue-countパラメータを含めます。# Queue oversubscription instance resource "google_compute_instance" "VM_NAME" { project = "PROJECT_ID" boot_disk { auto_delete = true device_name = "DEVICE_NAME" initialize_params { image="IMAGE_NAME" size = DISK_SIZE type = "DISK_TYPE" } } machine_type = "MACHINE_TYPE" name = "VM_NAME" zone = "ZONE" network_performance_config { total_egress_bandwidth_tier = "TIER_1" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_1 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_1" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_2 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_2" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_3 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_3"" } network_interface { nic_type = "GVNIC" queue_count = QUEUE_COUNT_4 subnetwork_project = "PROJECT_ID" subnetwork = "SUBNET_4"" } }
次のように置き換えます。
VM_NAME: 新しいコンピューティング インスタンスの名前PROJECT_ID: インスタンスの作成先とするプロジェクトの ID。共有 VPC ネットワークを使用している場合を除き、指定するプロジェクトは、すべてのサブネットとネットワークが作成されたプロジェクトと同じでなければなりません。DEVICE_NAME: ゲスト OS のブートディスクに関連付ける名前IMAGE_NAME: イメージの名前（例:"projects/debian-cloud/global/images/debian-11-bullseye-v20231010"）DISK_SIZE: ブートディスクのサイズ（GiB）DISK_TYPE: ブートディスクに使用するディスクのタイプ（例:pd-standard）MACHINE_TYPE: インスタンスのマシンタイプ。キュー数をオーバーサブスクライブするには、指定するマシンタイプが gVNIC と Tier_1 ネットワーキングをサポートしている必要があります。ZONE: インスタンスの作成先とするゾーン。QUEUE_COUNT: カスタムのキュー割り当てで説明されているルールに従った、vNIC のキュー数SUBNET_*: ネットワーク インターフェースが接続するサブネットの名前
REST
- 構成する vNIC インターフェースごとに 1 つのサブネットを使用できる VPC ネットワークがまだない場合は、作成します。
instances.insertメソッドを使用して、NIC の特定のキュー数を指定したコンピューティング インスタンスを作成します。複数のネットワーク インターフェースを構成するには、networkInterfacesプロパティを繰り返します。POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances { "name": "VM_NAME", "machineType": "machineTypes/MACHINE_TYPE", "networkPerformanceConfig": { "totalEgressBandwidthTier": TIER_1 }, "networkInterfaces": [ { "nicType": gVNIC, "subnetwork":"regions/region/subnetworks/SUBNET_1", "queueCount": "QUEUE_COUNT_1" } ], "networkInterfaces": [ { "nicType": gVNIC, "subnetwork":"regions/region/subnetworks/SUBNET_2", "queueCount": "QUEUE_COUNT_2" } ], }次のように置き換えます。
PROJECT_ID: コンピューティング インスタンスの作成先とするプロジェクトの IDZONE: コンピューティング インスタンスの作成先とするゾーンVM_NAME: 新しいコンピューティング インスタンスの名前MACHINE_TYPE: 新しいコンピューティング インスタンスのマシンタイプ（事前定義またはカスタム）。キュー数をオーバーサブスクライブするには、指定するマシンタイプが gVNIC と Tier_1 ネットワーキングをサポートしている必要があります。SUBNET_*: ネットワーク インターフェースが接続するサブネットの名前QUEUE_COUNT: カスタムキューの割り当てで説明されているルールに従う vNIC のキュー数
キューの割り当てとマシンタイプの変更
作成されるコンピューティング インスタンスには、デフォルトのキュー割り当てが設定されます。または、Compute Engine API を使用して、新しい Compute インスタンスの作成時に各仮想ネットワーク インターフェース カード（vNIC）にカスタムのキュー数を割り当てることもできます。デフォルトまたはカスタムの vNIC キュー割り当てが設定されるのは、コンピューティング インスタンスの作成時のみです。インスタンスの vNIC でデフォルトのキュー数が使用されている場合、インスタンスのマシンタイプを変更できます。変更先のマシンタイプの vCPU 数が異なる場合は、インスタンスのデフォルトのキュー数が新しいマシンタイプに基づいて再計算されます。
VM にデフォルト以外のカスタムキュー数を使用する vNIC がある場合は、Google Cloud CLI または Compute Engine API を使用して、インスタンス プロパティを更新してマシンタイプを変更できます。結果として作成された VM が元のインスタンスと同じ vNIC ごとのキュー数をサポートしている場合、変換は成功します。VirtIO-Net インターフェースを使用し、vNIC ごとに 16 を超えるカスタムキュー数を持つ VM の場合、マシンタイプを gVNIC のみを使用する第 3 世代以降のマシンタイプに変更することはできません。代わりに、ワークロードを新しいコンピューティング インスタンスに移動するの手順に沿って、VM を第 3 世代以降のマシンタイプに移行できます。
次のステップ
- マシンタイプの詳細を確認する。
- 仮想マシン インスタンスの詳細を確認する。
- VM インスタンスの作成と開始
- コンピューティング インスタンスの VM ごとの Tier_1 ネットワーキング パフォーマンスを構成する。
- クイックスタート チュートリアル「Compute Engine で Linux VM インスタンスを作成する」を完了する。
- クイックスタート チュートリアル「Compute Engine で Windows Server VM インスタンスを作成する」を完了する。