このドキュメントでは、Cloud Load Balancing の割り当てとシステムの上限について説明します。
- 割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、Cloud Load Balancing などの Google Cloud サービスによって定義されます。
- システムの上限は固定値で、変更できません。
割り当てを変更するには、追加の割り当てをリクエストするをご覧ください。
Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。
Cloud Quotas システムは次のことを行います。
- Google Cloud のプロダクトとサービスの消費量をモニタリングする
- これらのリソースの消費量を制限する
- 割り当て値の変更をリクエストする方法を提供する
ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。
割り当ては通常、Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。
Cloud Load Balancing リソースにはシステムの上限もあります。システムの上限は変更できません。
バックエンド
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| インスタンス グループ | 割り当て | 割り当てはプロジェクトごと、およびリージョンごとです。割り当ての増加リクエストを行う場合は、インスタンス グループを含むリージョンを選択します。ゾーン インスタンス グループは、インスタンス グループのゾーンを含むリージョンに対して課金されます。 |
| プロジェクトあたりのゾーン NEG とリージョン NEG | 割り当て | 割り当てはプロジェクトごと、リージョンごとに行われ、グローバル インターネット NEG、Private Service Connect NEG、サーバーレス NEG を除くすべての種類の NEG に適用されます。 割り当ての増加リクエストを行う場合は、NEG を含むリージョンを選択します。ゾーン NEG は、NEG のゾーンを含むリージョンに課金されます。 |
| プロジェクトあたりのグローバル NEG | 割り当て | この割り当てはグローバルで、プロジェクトごと、かつグローバル インターネット NEG、Private Service Connect NEG、サーバーレス NEG に適用されます。 |
バックエンド サービスあたりのインスタンス グループ バックエンド、GCE_VM_IP_PORT NEG バックエンド、GCE_VM_IP NEG バックエンド、またはリージョン インターネット NEG バックエンドの最大数 |
50 |
この上限は構成できません。 ゾーン NEG バックエンドとインターネット NEG バックエンドのサポートはロード バランシング プロダクトによって異なります。 バックエンド サービスベースの外部パススルー ネットワーク ロードバランサのフェイルオーバーを構成しているか、内部パススルー ネットワーク ロードバランサのフェイルオーバーを構成している場合、バックエンド サービスごとに、最大 50 個のプライマリ インスタンス グループと 50 個のバックアップ インスタンス グループ、または 内部パススルー ネットワーク ロードバランサには、バックエンド サービスがパケットを配信できる個々の仮想マシン（VM）インスタンスまたはエンドポイントの数についても上限があります。詳しくは、バックエンド サービスの割り当てをご覧ください。 |
1 NEG あたりのエンドポイント数
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
GCE_VM_IP_PORT ゾーン NEG あたりのエンドポイント数 |
10,000 | この上限を引き上げることはできません。 |
GCE_VM_IP ゾーン NEG あたりのエンドポイント数 |
10,000 | この上限を引き上げることはできません。 |
ハイブリッド接続 NEG あたりのエンドポイント数（NON_GCP_PRIVATE_IP_PORT） |
10,000 | この上限を引き上げることはできません。 |
| グローバル インターネット NEG あたりのエンドポイント数 | 1 | この上限を引き上げることはできません。 |
| リージョン インターネット NEG あたりのエンドポイント数 | 256 | この上限を引き上げることはできません。 |
| 1 サーバーレス NEG あたりのエンドポイント数 | 1 | この上限を引き上げることはできません。 |
| Private Service Connect NEG あたりのエンドポイント数 | 1 | この上限を引き上げることはできません。 |
| ポート マッピング NEG あたりのエンドポイント数 | 1,000 | この上限を引き上げることはできません。 |
1 インスタンス グループあたりの VM の数
単一のロードバランサが処理できるバックエンド VM の数は、インスタンス グループがサポートできる VM の数より少なくなることがあります。インスタンス グループあたりのロードバランスされる VM の最大数は、インスタンス グループがエクスポートする各名前付きポートで指定されたポートの数によって異なります。
デフォルトでは、リージョン マネージド インスタンス グループ（MIG）の場合、1 つのインスタンス グループでロード バランスされる VM の上限は 2,000 を超えることはできません。ゾーン MIG の場合は 1,000 を超えることはできません。ゾーン非マネージド インスタンス グループの場合、グループあたりの VM の最大数は 2,000 です。2,000 を超える VM が必要な場合は、マネージド インスタンス グループのサイズ上限を増やすか、サポートにお問い合わせください。
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| パススルー ロードバランサのバックエンド サービスに接続されているリージョン マネージド インスタンス グループあたりの VM の最大数 | 2,000 通 | 内部パススルー ネットワーク ロードバランサには、バックエンド サービスがパケットを配信できる個々の VM インスタンスまたはエンドポイントの数についても上限があります。詳しくは、バックエンド サービスの割り当てをご覧ください。 |
| ゾーン マネージド インスタンス グループまたはゾーン非マネージド インスタンス グループごとの、パススルー ロードバランサのバックエンド サービスに接続する VM の最大数 | ゾーン マネージド インスタンス グループの最大数: 1,000 ゾーン非マネージド インスタンス グループの最大数: 2,000 |
内部パススルー ネットワーク ロードバランサには、バックエンド サービスがパケットを配信できる個々の VM インスタンスまたはエンドポイントの数についても上限があります。詳しくは、バックエンド サービスの割り当てをご覧ください。 |
| プロキシ ロードバランサのバックエンド サービスに接続されているリージョン マネージド インスタンス グループあたりの VM の最大数 | インスタンス グループの名前付きポートで指定されたポートの数によって異なる。次の 2 つのうち小さいほう: A: 2,000 B: 10,000 /（最大ポート番号を含む名前付きポートのポート数）† |
この上限を増やす必要がある場合は、サポートにお問い合わせください。 |
| プロキシ ロードバランサのバックエンド サービスに接続されているゾーン マネージド インスタンス グループあたりの VM の最大数 | インスタンス グループの名前付きポートで指定されたポートの数によって異なります。次の 2 つのうち小さいほう: A: 1,000 B: 10,000 /（最大ポート番号を含む名前付きポートのポート数）† |
この上限を増やす必要がある場合は、サポートにお問い合わせください。 |
| プロキシ ロードバランサのバックエンド サービスに接続されているゾーン非マネージド インスタンス グループあたりの VM の最大数 | インスタンス グループの名前付きポートで指定されたポートの数によって異なります。次の 2 つのうち小さいほう: A: 2,000 B: 10,000 /（最大ポート番号を含む名前付きポートのポート数）† |
この上限を増やす必要がある場合は、サポートにお問い合わせください。 |
† インスタンス グループ バックエンドのロードバランスされる VM の最大数を計算するには:
名前付きポートごとの最大ポート数を決めます。
たとえば、インスタンス グループに名前付きポート
http:80、api-gateway:8080、api-gateway:8090がある場合、http名に 1 つのポート番号と、api-gateway名に 2 つのポート番号があります。したがって、この例の名前付きポートごとの最大ポート数は 2 です。名前付きポートあたりの最大ポート数で 10,000 を割り、余りを破棄します。例:
10,000 / 2 = 5,000。前の手順で計算した数値を、インスタンス グループあたりの負荷分散 VM の上限数（リージョン グループの場合は 2,000、ゾーングループの場合は 1,000）と比較します。
前の手順で計算した数が上限を超えていない場合は、インスタンス グループごとの負荷分散 VM の最大数は前の手順で計算された値になります。それ以外の場合は、インスタンス グループあたりのロードバランスされた VM の最大数は上限（リージョン グループの場合は 2,000、ゾーングループの場合は 1,000）になります。
ターゲット プール
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| ターゲット プール | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
バックエンド バケット
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| バックエンド バケット | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
バックエンド サービス
Cloud Monitoring を使用してバックエンド サービスの割り当てをモニタリングするには、Consumer Quota リソースタイプで serviceruntime.googleapis.com/quota/allocation/usage 指標のモニタリングを設定します。割り当てタイプに到達するように、追加のラベルフィルタ（service、quota_metric）を設定します。割り当て使用量の指標をモニタリングする方法については、割り当て指標をグラフ化してモニタリングするをご覧ください。
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサ | ||
| 従来のアプリケーション ロードバランサと従来のプロキシ ネットワーク ロードバランサのバックエンド サービス | 割り当て | これはプロジェクトごとの割り当てで、従来のアプリケーション ロードバランサと従来のプロキシ ネットワーク ロードバランサのバックエンド サービスの最大数を定義します。 割り当て名: 利用可能な指標:
|
| グローバル外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサのバックエンド サービス | 割り当て | これはプロジェクトごとの割り当てで、グローバル外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサのバックエンド サービスの最大数を定義します。 割り当て名: 利用可能な指標:
|
リージョン外部アプリケーション ロードバランサとリージョン外部プロキシ ネットワーク ロードバランサのバックエンド サービス |
割り当て | これは、リージョンごと、プロジェクトごとの割り当てで、リージョン外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサのバックエンド サービスの最大数を定義します。 割り当て名: 利用可能な指標:
|
| クロスリージョン内部アプリケーション ロードバランサとクロスリージョン内部プロキシ ネットワーク ロードバランサのバックエンド サービス | 割り当て | これはリージョンごと、プロジェクトごとの割り当てで、クロスリージョン内部アプリケーション ロードバランサとクロスリージョン内部プロキシ ネットワーク ロードバランサのバックエンド サービスの最大数を定義します。 割り当て名: 利用可能な指標:
|
| リージョン内部アプリケーション ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサのバックエンド サービス | 割り当て | これはリージョンごと、プロジェクトごとの割り当てで、リージョン内部アプリケーション ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサのバックエンド サービスの最大数を定義します。 割り当て名: 利用可能な指標:
|
| アプリケーション ロードバランサあたりのバックエンド サービスの数 | URL マップの構成によって異なる | 詳細については、URL マップをご覧ください。 |
| プロキシ ネットワーク ロードバランサあたりのバックエンド サービスの数 | 1 | この上限を変更することはできません。 |
| アプリケーション ロードバランサまたはプロキシ ネットワーク ロードバランサのバックエンド サービスあたりの名前付きポートの数 | 1 | この上限を変更することはできません。名前付きポートは、インスタンス グループのバックエンドにのみ関連します。 |
| 特定のバックエンド サービスを参照できる URL マップを含む個別のプロジェクトの最大数（プロジェクト間サービス参照に関連する上限） | 10 | 最大 10 個の異なるプロジェクトの URL マップが、特定のバックエンド サービスを参照できます。この上限を引き上げることはできません。この上限は各バックエンド サービスに個別に適用されます。 |
| パススルー ネットワーク ロードバランサ | ||
| 外部パススルー ネットワーク ロードバランサのバックエンド サービス | 割り当て | これはリージョンごと、プロジェクトごとの割り当てで、外部パススルー ネットワーク ロードバランサのバックエンド サービスの最大数を定義します。 割り当て名: 利用可能な指標:
|
| 内部パススルー ネットワーク ロードバランサのバックエンド サービス | 割り当て | これはリージョンごと、プロジェクトごとの割り当てで、内部パススルー ネットワーク ロードバランサのバックエンド サービスの最大数を定義します。 割り当て名: 利用可能な指標:
|
| パススルー ネットワーク ロードバランサあたりのバックエンド サービスの数 | 1 | この上限を変更することはできません。 |
| パススルー ネットワーク ロードバランサのバックエンド サービスあたりの名前付きポートの数 | 0 | この上限を変更することはできません。バックエンド サービスの portName フィールドは、パススルー ネットワーク ロードバランサでは無視されます。 |
内部パススルー ネットワーク ロードバランサのバックエンド サービスの VM インスタンス（すべてのインスタンス グループ バックエンド内）またはエンドポイント（すべての GCE_VM_IP ネットワーク エンドポイント グループ内）の最大数 |
バックエンドのサブセット化が無効な場合: 250 バックエンド サブセット化が有効な場合: 2,000 |
この上限を引き上げることはできません。 フェイルオーバーが構成されている場合、VM インスタンスまたはエンドポイントの最大数がアクティブ プール内のインスタンスまたはエンドポイントに適用されます。 たとえば、バックエンド サービスに 5 つのインスタンス グループがあり、それぞれに 60 個の VM インスタンスがある場合、バックエンドのサブセット化が無効になっていると、ロードバランサは 300（5 × 60）個のインスタンスのうち 250 個のインスタンスにのみパケットを分散します。 これらの上限を超えてバックエンド VM を構成すると、トラフィックは許可されている最大数の VM またはエンドポイントにのみ転送されるため、パフォーマンスに悪影響が及ぶ可能性があります（詳細については、こちらをご覧ください）。 |
| Cloud Service Mesh | ||
| Cloud Service Mesh バックエンド サービス | 割り当て | Cloud Service Mesh のバックエンド サービス。 割り当て名: 利用可能な指標:
|
| Cloud Service Mesh バックエンド サービス | 割り当て | Cloud Service Mesh のバックエンド サービス。 割り当て名: 利用可能な指標:
|
転送ルール
Cloud Monitoring を使用して転送ルールの割り当てをモニタリングするには、Consumer Quota リソースタイプで指標 serviceruntime.googleapis.com/quota/allocation/usage のモニタリングを設定します。割り当てタイプに到達するように、追加のラベルフィルタ（service、quota_metric）を設定します。割り当て使用量の指標をモニタリングする方法については、割り当て指標をグラフ化してモニタリングするをご覧ください。
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| 外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサ | ||
| 従来のアプリケーション ロードバランサと従来のプロキシ ネットワーク ロードバランサの転送ルール | 割り当て | これはプロジェクトごとの割り当てで、従来のアプリケーション ロードバランサと従来のプロキシ ネットワーク ロードバランサの転送ルールの最大数を定義します。プロジェクトに Classic VPN ゲートウェイがある場合、それらのゲートウェイの転送ルールもこの割り当ての使用量に対してカウントされます。 割り当て名: 利用可能な指標:
|
| グローバル外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサの転送ルール | 割り当て | これはプロジェクトごとの割り当てで、グローバル外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサの転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
1 ネットワーク、1 リージョンあたりのリージョン外部アプリケーション ロードバランサとリージョン外部プロキシ ネットワーク ロードバランサの転送ルール この割り当ては、非推奨になったプロジェクトごとの |
割り当て | これはリージョンおよびネットワークごとの割り当てで、バックエンドが VPC ネットワークのリージョンに配置されているリージョン外部アプリケーション ロードバランサとグローバル外部プロキシ ネットワーク ロードバランサの転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| 内部アプリケーション ロードバランサと内部プロキシ ネットワーク ロードバランサ | ||
| 1 ネットワーク、1 リージョンあたりのクロスリージョン内部アプリケーション ロードバランサとクロスリージョン内部プロキシ ネットワーク ロードバランサの転送ルール | 割り当て | これはリージョンおよびネットワークごとの割り当てで、クロスリージョン内部アプリケーション ロードバランサとクロスリージョン内部プロキシ ネットワーク ロードバランサで VPC ネットワークのリージョン内に作成できる転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| 1 ネットワーク、1 リージョンあたりのリージョン内部アプリケーション ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサの転送ルール | 割り当て | これはリージョンおよびネットワークごとの割り当てで、リージョン内部アプリケーション ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサで VPC ネットワークのリージョン内に作成できる転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| ネットワークあたりのクロスリージョン内部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサの転送ルール | 割り当て | これはネットワークごとの割り当てで、クロスリージョン内部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサで VPC ネットワークのすべてのリージョンに集約して作成できる転送ルールの最大数を定義します。 この割り当ては廃止される予定です。 割り当て名: 利用可能な指標:
|
| ピアリング グループあたりのクロスリージョン内部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサの転送ルール | 割り当て | これは、ネットワークごとの割り当てで、ローカル VPC ネットワークのすべてのリージョンおよび直接接続されているすべてのピア VPC ネットワークのすべてのリージョンのクロスリージョン内部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、クロスリージョン内部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサの転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| パススルー ネットワーク ロードバランサ | ||
| 外部パススルー ネットワーク ロードバランサの転送ルール | 割り当て | これはリージョンごと、プロジェクトごとの割り当てで、外部パススルー ネットワーク ロードバランサ（バックエンド サービスとターゲット プール アーキテクチャの両方）の転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| ネットワークあたりの内部パススルー ネットワーク ロードバランサの転送ルール | 割り当て | これはネットワークごとの割り当てで、内部パススルー ネットワーク ロードバランサで VPC ネットワークのすべてのリージョンに集約して作成できる転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| ピアリング グループあたりの内部パススルー ネットワーク ロードバランサの転送ルール | 割り当て | これはネットワークごとの割り当てで、ローカル VPC ネットワークのすべてのリージョンおよび直接接続しているすべてのピアのすべての VPC ネットワークのリージョンの内部パススルー ネットワーク ロードバランサの転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| 内部パススルー ネットワーク ロードバランサとバックエンド サービスベースの外部パススルー ネットワーク ロードバランサの転送ルールごとのポート数 | 5 |
これは上限であり、変更できません。別のポート指定オプションも使用できます。
|
| パススルー ロードバランサの同じバックエンド サービスを参照できる転送ルールの数 | 個別の上限なし | 他の項目の割り当てや上限に応じて、複数の転送ルールで同じパススルー ロードバランサへのバックエンド サービスを参照できます。 |
| 1 つの転送ルールで参照可能なパススルー ロードバランサのバックエンド サービスの数 | 1 | パススルー ロードバランサの転送ルールは、1 つのバックエンド サービスのみを参照する必要があります。 |
| 1 つの内部 IP アドレスを共有できる内部転送ルールの最大数 | 10 | この上限は、内部パススルー ネットワーク ロードバランサと内部プロキシ ネットワーク ロードバランサにのみ適用されます。この上限を引き上げることはできません。 |
| ステアリング転送ルールあたりの送信元 IP アドレス範囲の最大数 | 64 | この上限は、外部パススルー ネットワーク ロードバランサにのみ適用されます。この上限を引き上げることはできません。 |
| プロトコル転送（ターゲット インスタンス） | ||
| 外部プロトコルの転送ルール | 割り当て | これはリージョンごと、プロジェクトごとの割り当てで、外部 プロトコル転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| ネットワークあたりの内部プロトコル転送ルール | 割り当て | これはネットワークごとの割り当てで、VPC ネットワークのすべてのリージョンに集約して作成できる内部プロトコル転送の転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| ピアグループあたりの内部転送ルール | 割り当て | これはネットワークごとの割り当てで、ローカル VPC ネットワークのすべてのリージョンおよび直接接続されているすべてのピア VPC のすべてのリージョンの内部プロトコル転送ルールの最大数を定義します。 割り当て名: 利用可能な指標:
|
| Cloud Service Mesh | ||
| Cloud Service Mesh 転送ルール | 割り当て | Cloud Service Mesh の転送ルール。 割り当て名: 利用可能な指標:
|
ターゲット プロキシ
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| ターゲット HTTP プロキシ | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
| ターゲット HTTPS プロキシ | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
| ターゲット SSL プロキシ | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
| ターゲット TCP プロキシ | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
| 1 ターゲット HTTPS プロキシまたは 1 ターゲット SSL プロキシあたりの SSL ポリシー数 | 1 | この上限を引き上げることはできません。 |
| 1 ターゲット HTTPS プロキシまたは 1 ターゲット SSL プロキシあたりの SSL 証明書数 | 15 | この上限を引き上げることはできません。ただし、一部のロードバランサは Certificate Manager をサポートしています。これを使用すると、ターゲット HTTPS プロキシまたはターゲット SSL プロキシで数千の SSL 証明書を使用できます。詳細については、SSL 証明書の概要で複数の SSL 証明書をご覧ください。 |
ヘルスチェック
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| ヘルスチェック | 割り当て | これは、すべてのヘルスチェック（グローバル、リージョン、レガシー）を対象とするプロジェクトごとの割り当てです。 |
URL マップ
ここに記載されている上限を引き上げることはできません。
| 項目 | 外部アプリケーション ロードバランサ | 内部アプリケーション ロードバランサ |
|---|---|---|
| URL マップ | 割り当て
この割り当ては 1 プロジェクトあたりの値です。 |
割り当て
この割り当ては 1 プロジェクトあたりの値です。 |
| ホストルール、URL マップごとのパスマッチャー | 上限: 1000 | 上限: 2000 |
| パスマッチャーごとのパスルールまたはルートルール | 上限: 1,000 | 上限: 1,000 |
| ホストルールあたりのホスト数 | 上限: 1000 | 上限: 1000 |
| パスマッチャーごとの述語 † | 上限: 1000 | 上限: 1,000 |
パスマッチャーごとのpathTemplateMatch述語 |
グローバル外部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサ: 上限: 100 従来のアプリケーション ロードバランサではサポートされていません |
上限: 100 |
| URL マップで参照できる個別のバックエンド サービスまたはバックエンド バケットの数 | 上限: 2,500 | 上限: 2,500 |
プロジェクト間サービス参照に関連するその他の制限:
|
||
| URL マップのサイズ | 上限: 64 KB | 上限: 128 KB |
| URL マップテストの数 | 従来のアプリケーション ロードバランサ: 上限: 10,000 |
該当なし 内部アプリケーション ロードバランサは、URL マップのテストをサポートしていません。 |
グローバル外部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサ: 上限: 100 |
||
† これは、パスマッチャー内のすべてのルールにわたる一致条件数の上限です。パスルールを使用するパスマッチャーの場合、すべてのパスルールにわたるパスの合計数です。ルートルールを使用するパスマッチャーの場合、接頭辞数は、以下を加算して計算されます。
- パスマッチ条件（prefixMatch または fullPathMatch のいずれか）に対して 1
- パスマッチャーのすべてのルートルールで一致するヘッダーの合計
- パスマッチャーのすべてのルートルールで一致するクエリ パラメータの合計
たとえば、次のルートルールを持つパスマッチャーの場合:
- ルートルール A には 1 つの prefixMatch と 3 つのヘッダー一致がある
- ルートルール B には 1 つの fullPathMatch と 2 つのクエリ パラメータの一致がある
このパスマッチャーの合計述語数は、7 になります。これは、「1（接頭辞一致）+ 3（ヘッダー一致の数）+ 1（フルパス一致）+ 2（クエリ パラメータの一致数）」で求められます。
アプリケーション ロードバランサのヘッダーサイズ
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| 外部アプリケーション ロードバランサのクライアント リクエスト ヘッダーの最大サイズ | 64 KB（キロバイト） | この上限を引き上げることはできません。 リクエスト URL とリクエスト ヘッダーの合計サイズは 64 KB 以下にする必要があります。 |
| 外部アプリケーション ロードバランサの最大バックエンド レスポンス ヘッダーサイズ | 約 128 KB（キロバイト） | この上限を引き上げることはできません。 |
| 内部アプリケーション ロードバランサのバックエンド リクエスト ヘッダーの最大サイズ | 60 KB（キロバイト） | この上限を引き上げることはできません。 |
| HTTP リクエスト ヘッダーと HTTP レスポンス ヘッダーの小文字変換 | HTTP/1.1 を使用する場合の従来のアプリケーション ロードバランサを除き、常に | たとえば、Host は host に、Keep-ALIVE は keep-alive になります。 |
| 各バックエンド サービスに構成されたカスタム リクエスト ヘッダーの最大数 | 16 | この上限を引き上げることはできません。 |
| 各バックエンド サービスに構成されたカスタム レスポンス ヘッダーの最大数 | 16 | この上限を引き上げることはできません。 |
| バックエンド サービスごとのすべてのカスタム リクエスト ヘッダーの合計サイズ（変数を展開する前の名前と値の組み合わせ） | 8 KB | この上限を引き上げることはできません。 |
| バックエンド サービスごとのすべてのカスタム レスポンス ヘッダーの合計サイズ（変数を展開する前の名前と値の組み合わせ） | 8 KB | この上限を引き上げることはできません。 |
アプリケーション ロードバランサの秒間クエリ数
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| グローバル外部アプリケーション ロードバランサのバックエンド インスタンス グループまたは NEG ごとの秒間クエリ数（QPS） | 分散モードに RATE を使用する場合に構成可能。 |
バックエンドによって制限されます。 |
| リージョン外部アプリケーション ロードバランサのリージョンごとの、ネットワークあたりの秒間クエリ数（QPS） | リージョン外部アプリケーション ロードバランサの場合、最大 QPS 負荷は、リクエストのサイズと構成の複雑さによって異なります。負荷が容量を超えると、レイテンシが増加しリクエストが破棄される可能性があります。 | バックエンドによって制限されます。* この上限を増やす必要がある場合は、サポートにお問い合わせください。 |
| 内部アプリケーション ロードバランサのリージョン、ネットワークあたりの秒間クエリ数（QPS） | 内部アプリケーション ロードバランサの場合、最大 QPS 負荷は、リクエストのサイズと構成の複雑さによって異なります。負荷が容量を超えると、レイテンシが増加しリクエストが破棄される可能性があります。 | バックエンドによって制限されます。* この上限を増やす必要がある場合は、サポートにお問い合わせください。 |
* サーバーレス NEG を使用しているプロジェクトの場合、リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサで構成されたサーバーレス NEG に送信されるトラフィックのプロジェクトあたりの上限は 5,000 クエリ/秒（QPS）です。この上限は、プロジェクトとリージョン内のすべてのリージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサにわたり集計されます。これはロードバランサごとの上限ではありません。
サービス ロード バランシング ポリシー
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| ServiceLbPolicies | 割り当て | この割り当てはプロジェクト単位で、従来のアプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサに適用されます。 |
SSL 証明書
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| SSL 証明書 | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
| サポートされている秘密鍵の長さ | 2,048 ビット RSA（RSA-2048） 256 ビット ECDSA（ECDSA P-256） |
この上限を引き上げることはできません。 |
| 1 Google マネージド SSL 証明書あたりの複数ドメイン | 100 | この上限を引き上げることはできません。 |
| Google マネージド証明書のドメイン名の長さ | 64 バイト | この上限を引き上げることはできません。 この長さの上限は、Google マネージド SSL 証明書にのみ適用されます。これらの証明書では、証明書の最初のドメインにのみ 64 バイトの上限が適用されます。証明書に含まれる他のドメインの長さの上限は 253 バイトです（これは、インターネットのあらゆるドメイン名に適用され、Google マネージド証明書にのみ適用される上限ではありません）。 |
SSL ポリシー
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| グローバル SSL ポリシー | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 この割り当ては、以下によって使用されます。
|
| リージョン SSL ポリシー | 割り当て | この割り当ては、プロジェクトごと、リージョンごとに適用されます。 この割り当ては、以下によって使用されます。
|
認可ポリシー
ここで説明する上限を引き上げることはできません。これは、アプリケーション ロードバランサに適用されます。
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| 認可ポリシーの数 | 上限: グローバル リソースの場合は 10、リージョン リソースの場合はリージョンごとに 10 | この割り当ては 1 プロジェクトあたりの値です。 |
| 認可ポリシーが参照できる転送ルールの数 | 上限: 100 | この割り当ては認可ポリシーごとに適用されます。 |
| 転送ルールあたりの認可ポリシーの数 | 上限: 5 | この割り当ては転送ルールごとに適用されます。 |
| 認可拡張リソースの数 | 上限: グローバル リソースの場合は 10、リージョン リソースの場合はリージョンごとに 10 | この割り当ては 1 プロジェクトあたりの値です。 |
サーバー TLS ポリシー
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| グローバル サーバー TLS ポリシー | 割り当て | この割り当てはプロジェクト単位で、従来のアプリケーション ロードバランサ、グローバル外部アプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサに適用されます。 |
| リージョン サーバー TLS ポリシー | 割り当て | この割り当てはプロジェクトごとのリージョンごとに適用され、リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサに適用されます。 |
信頼構成
ここで説明する上限を引き上げることはできません。これは、従来のアプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサに適用されます。
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| トラストストアの数 | 上限: 1 | これは TrustConfig リソースあたりの上限です。 |
| トラスト アンカーと中間証明書の合計数 | 上限: 200 | これは、トラストストアあたりの上限です。 |
| 中間証明書の数 | 上限: 100 | これは、トラストストアあたりの上限です。 |
| ルート証明書と中間証明書の検証中に許可される名前の制約の数 | 上限: 10 | |
| サブジェクトとサブジェクトの公開鍵情報を共有する中間証明書 | 上限: 10 | これは、トラストストアあたりの上限です。 |
| 証明書チェーンの深さ | 上限: 10 | ルート証明書とクライアント証明書を含む証明書チェーンの最大深度。 |
| 信頼チェーンを構築する際に中間証明書を評価できる回数 | 上限: 100 | |
| クライアントからアップロードまたは渡される証明書の鍵 | 上限: RSA 鍵の長さは 2,048～4,096 ビットにできます。 ECDSA 証明書には、P-256 または P-384 の楕円曲線暗号を使用する必要があります。 |
パブリック委任プレフィックスの上限
ここで説明する上限は、外部パススルー ネットワーク ロードバランサに適用されます。
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| 可変プレフィックス長のパブリック委任プレフィックス | 割り当て | この割り当ては 1 プロジェクトあたりの値です。これは、 お客様には、デフォルトで 40 の割り当てが与えられます。 |
割り当てを管理
Cloud Load Balancing では、さまざまな理由から、使用できるリソースの割り当て量に上限が設けられています。たとえば、割り当て量の上限を設定して予期しない使用量の急増を防ぐことで、 Google Cloud ユーザーのコミュニティを保護しています。割り当て量は、無料枠で Google Cloud を試しているユーザーをトライアルに留めておくのにも役立ちます。
すべてのプロジェクトは同じ割り当て量で開始しますが、追加の割り当て量をリクエストすることで変更できます。割り当てによっては、プロダクトの使用状況に応じて自動的に増加される場合もあります。
権限
Identity and Access Management（IAM）のプリンシパルが割り当ての表示や、割り当ての増加のリクエストをするには、以下のいずれかのロールが必要です。
| タスク | 必要なロール |
|---|---|
| プロジェクトの割り当て量をチェックする | 次のいずれかが必要です。 |
| 割り当て量の変更、割り当て量の追加のリクエストを行う | 次のいずれかが必要です。 |
割り当て量を確認する
Console
- Google Cloud コンソールで、[割り当て] ページに移動します。
- 更新する割り当てを検索するには、[表をフィルタリング] を使用します。割り当ての名前がわからない場合は、このページにあるリンクを使用します。
gcloud
Google Cloud CLI で次のコマンドを実行して、割り当てを確認します。PROJECT_ID は、実際のプロジェクト ID に置き換えます。
gcloud compute project-info describe --project PROJECT_IDある特定のリージョンで使用済みの割り当て量を確認するには、次のコマンドを実行します。
gcloud compute regions describe example-region
割り当て量を超えたときのエラー
gcloud コマンドで割り当て量を超えた場合、gcloud は quota exceeded エラー メッセージを出力し、終了コード 1 を返します。
API リクエストで割り当て量を超えた場合、Google Cloud は HTTP ステータス コード 413 Request Entity Too Large を返します。
追加の割り当てをリクエスト
通常、割り当てを調整するには、Google Cloud コンソールを使用します。詳細については、割り当ての調整をリクエストするをご覧ください。
Console
- Google Cloud コンソールで、[割り当て] ページに移動します。
- [割り当て] ページで、変更する割り当てを選択します。
- ページの上部にある [割り当てを編集] をクリックします。
- [名前] に氏名を入力します。
- 省略可: [電話番号] に有効な電話番号を入力します。
- リクエストを送信します。割り当てのリクエストが処理されるまで、24～48 時間かかります。
リソースの可用性
各割り当て量は、リソースが利用可能な場合に作成できる特定のリソースタイプの最大数を表します。割り当て量によってリソースの可用性が保証されるわけではありません。この点は注意が必要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。
たとえば、us-central1 リージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスは作成できません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。
リージョン全体でリソースを使用できない状況はまれです。ただし、ゾーン内のリソースが使い果たされることはあります。通常、そのリソースタイプのサービスレベル契約（SLA）に影響はありません。詳細については、リソースに関連する SLA をご覧ください。