割り当てと上限
このドキュメントでは、Cloud Router に適用される割り当てと上限について説明します。
割り当てを変更するには、追加の割り当てをリクエストするをご覧ください。
割り当ては、Google Cloud プロジェクトで使用できる共有 Google Cloud リソース（ハードウェア、ソフトウェア、ネットワーク コンポーネントなど）の量を制限します。つまり、割り当てはシステムの一部で、次の機能があります。
- Google Cloud のプロダクトとサービスの使用量や消費量をモニタリングする。
- 公平性の確保や使用量急増の抑制などのため、これらのリソースの消費量を制限する。
- 規定の制限を自動的に適用する構成を維持する。
- 割り当てをリクエストまたは変更する手段を提供する。
ほとんどの場合、割り当てを超過すると、システムは関連する Google リソースへのアクセスをすぐにブロックするため、ユーザーが試行しているタスクは失敗します。ほとんどの場合、割り当ては各 Google Cloud プロジェクトに適用され、その Google Cloud プロジェクトを使用するすべてのアプリケーションと IP アドレスで共有されます。
Cloud Router リソースにも上限があります。これらの上限は、割り当てシステムとは無関係です。上限は、特に明記されていない限り、変更できません。
割り当て
次の表は、プロジェクト単位の重要な割り当てをまとめたものです。他の割り当てについては、Google Cloud コンソールの [割り当て] ページをご覧ください。
| 項目 | 割り当て | 注 |
|---|---|---|
| プロジェクトあたりの Cloud Router の数 | 割り当て | 割り当てにかかわらず、各ネットワークではリージョンあたりの Could Router の数が 5 つに制限されています。上限をご覧ください。 |
上限
Virtual Private Cloud（VPC）ネットワークには次の Cloud Router の上限が適用されます。特に明記されていない限り、これらの上限を引き上げることはできません。
| 項目 | 上限 | 注 |
|---|---|---|
| VPC ネットワークとリージョンの各組み合わせにおける Cloud Router の最大数 | 5 | プロジェクトの割り当てが十分な場合は、特定の VPC ネットワークとリージョンで最大 5 つの Cloud Router を作成できます。 |
| VPC ネットワークとリージョンの各 Cloud Router における BGP ピアの最大数 | 128 | BGP ピアは動的ルーティング VLAN を使用する Cloud VPN トンネル、または Dedicated Interconnect 用か Partner Interconnect 用のアタッチメントとして使用できます。 |
| 特定の Cloud Router での、BGP セッションあたりのサブネット ルート アドバタイズの最大数 | 制限なし | Cloud Router では、アドバタイズできるサブネット ルートの数に上限はありません。サブネット ルートの数は、VPC ネットワークの割り当てと上限で制御されるサブネット数に基づいて決まります。 |
| 特定の Cloud Router での、BGP セッションあたりのカスタム アドバタイズ ルートの最大数 | 200 | Cloud Router のすべての BGP セッションでカスタム アドバタイズ ルートが同一である場合、この上限は、Cloud Router の一意の IPv4 および IPv6 のカスタム アドバタイズ ルートの総数を表します。その場合、各セッションは同一のカスタム アドバタイズ ルートのセットを受け取ります。 |
| 特定リージョン内で、すべての Cloud Router が学習し、同じリージョン内のサブネットに適用できるルートの保証された一意の宛先の最大数。この上限は、リージョンの from-own-region の上限と呼ばれます。 | 250 |
学習したルートの一意の宛先の保証された最大数上限の両方に到達します。 IPv4 と IPv6 の両方の接頭辞が各上限にカウントされます。 カスタム学習ルートや BGP ピアから学習したルートなど、学習したすべてのルートがこの上限にカウントされます。 ルートは一意の宛先ごとにグループ化されます。宛先が同じでネクストホップが異なるルートは、ただ 1 つの宛先としてカウントされます。また、宛先とネクストホップの両方が同じであるルートも、ただ 1 つの宛先としてカウントされます。 グローバル動的ルーティング モードのネットワークでは、一意の宛先の最大数上限のうち 1 つに到達し、もう 1 つの上限には到達しないことがあります。いずれかの上限に到達すると、ルートが削除された場合に断続的に接続の問題が発生する可能性があります。詳細については、学習したルートの例をご覧ください。 現在の上限と使用量を把握するために使用できる指標など、これらの上限の詳細については、トラブルシューティングの割り当てと上限の確認をご覧ください。 この上限を引き上げる必要がある場合は、サポートケースを登録してください。 |
グローバル動的ルーティング モードの VPC ネットワークにのみ適用されます。 異なるリージョン内の Cloud Router によって特定のリージョンのサブネットに適用できる、学習したルートの保証された一意の宛先の最大数。この上限は、リージョンの from-other-regions の上限と呼ばれます。 |
250 | |
| 特定の BGP セッションでのカスタム学習ルートの最大数 | 10 |
この機能の詳細については、カスタム学習ルートをご覧ください。 |
VPC ネットワーク内の特定のリージョンに対する、カスタム学習ルートとして構成できる一意の IP 接頭辞の最大数。この上限により、複数のピアで同じ範囲を使用できます。 |
10 |
学習したルートの例
次の例では、from-own-region の上限または from-other-regions の上限を超えた場合に発生する可能性があるルートドロップ動作を示します。
Cloud Router が us-east1 リージョンにあり、同じ VPC ネットワークの us-west1 リージョンにも Cloud Router がある場合に、グローバル動的ルーティングが有効になっているとします。各リージョンの Cloud Router は、それぞれ 250 個の一意の宛先を学習します。この図は説明を目的としたもので、各リージョンの Cloud Router はそれぞれ同じ宛先を学習しません。
各リージョンの Cloud Router は 250 個の一意の宛先のうち 250 個を学習するため、各リージョンのルートをどの Cloud Router が学習しても、各リージョンの from-own-region の上限に達します。各 Cloud Router は他のリージョンから 250 個の一意の宛先をインポートするため、両方のリージョンの from-other-regions の上限にも到達します。サンプルの VPC ネットワークでリージョン動的ルーティングを使用した場合、リージョン動的ルーティング モードは、ルートのネクストホップに一致するリージョン内にのみ動的ルートを作成するように VPC ネットワークに対して指示するため、各リージョンの from-other-regions の上限は適用されません。
リージョンの from-own-region の上限を超えた場合
us-west1 の Cloud Router に接続されているオンプレミス ルーターが 251 番目の宛先をアドバタイズするとします。us-west1 リージョンの Cloud Router は、決定論的なルート順序に従って、251 個の一意の宛先から 250 個を選択します。これらのルーターは、250 個の一意の宛先を VPC ネットワークに送信し、us-west1 リージョンに 250 個の動的ルートを作成します。
VPC ネットワークはグローバル動的ルーティング モードを使用するため、他のリージョンの一意の宛先の from-other-regions の上限に従って、他のすべてのリージョンに 250 以下の動的ルートも作成します。次のセクションでは、他のリージョンで行われる処理について詳しく説明します。
リージョンの from-other-regions の上限を超えた場合
us-west1 リージョンの Cloud Router が 251 個の一意の宛先を学習すると、us-east1 リージョンのリソースに対して、us-west1 を起点とする 251 個の一意の宛先のうち 250 個の宛先へのルートが利用可能になります。これは us-east1 リージョンの from-other-regions の上限で許容できる一意の宛先が 250 個に制限されるためです。
同じ VPC ネットワーク内の 3 番目のリージョン us-central1 に Cloud Router を作成するとします。また、新しい Cloud Router が BGP ピアから 10 個の一意の宛先を学習するものとします。us-central1 リージョンの from-own-region の上限は超過していませんが、他の 2 つのリージョンから合計 500 個の一意の宛先（us-east1 では 250、us-west1 では 250）が提供されているため、us-central1 リージョンの一意の宛先の from-other-regions の上限を超えています。
リージョンごとに、次の表に示すように、他のリージョンからのルートは、各リージョンで一意の宛先が 250 個を超えないよう、決定論的なルート順序で選択されます。
| リージョン |
リージョン固有の一意の宛先 （リージョンの from-own-region の上限の使用） |
他のリージョンからの一意の宛先 （リージョンの from-other-regions の上限の使用） |
|---|---|---|
| us-west1 |
251 個を受信。251 個のうち 250 個が選択され、251 個のうちの 1 個が決定論的なルート順序によって破棄されます。 選択された 250 個の接頭辞は、他のリージョンと共有されます。 |
260 個を受信（
|
| us-east1 |
250 個を受信。250 個すべてが決定論的なルート順序によって選択されます。 選択された 250 個の接頭辞は、すべて他のリージョンと共有されます。 |
260 個を受信（
|
| us-central1 |
10 個を受信。10 個すべてが決定論的なルート順序によって選択されます。 選択された 10 個の接頭辞は、すべて他のリージョンと共有されます。 |
500 個を受信（
|
us-central1 リージョンの他リージョンからの上限を超えていますが、from-own-region の上限では、ネクストホップが us-central1 リージョンに存在する宛先を受け入れることができます。
決定論的なルートドロップ動作
Cloud Router は、受信した各接頭辞のサブネット マスク長と辞書的特性に基づいて、決定論的なルートドロップ動作を実装します。各リージョン内では、次のプロセスが from-own-region の宛先リストと from-other-regions の一意の宛先リストに独立して適用されます。
リストは、サブネット マスクの長さが最短のものから最長のものの順に並べられ、次に辞書順に並べ替えられます。たとえば、
10.0.0.0/8、10.2.1.0/24、10.99.1.0/24はこの順序で並べられます。リストにある最初の 250 件のエントリは保持されます。他はすべて破棄されます。
リージョンの from-other-regions の上限を超えた場合に示すように、決定論的ドロップ動作は、各リージョンの from-own-region の上限と各リージョンの from-other-regions の上限に対して独立して適用されます。
決定論的なルートドロップ動作の結果は、次のとおりです。
IPv4 と IPv6 の両方のプレフィックスを受信し、一意の宛先の上限を超えると、通常 Cloud Router は IPv6 プレフィックスを先に破棄します。これは、IPv6 の最も一般的な最小のサブネット マスク長（
/48）が、IPv4 の最長のサブネット マスク長（/32）よりも長くなるためです。各リージョンで学習したプレフィックスのセットが一定に保たれている場合は、VPC ネットワークの動的ルーティング モードに従って、すべてのリージョンで一貫したローカル動的ルートセットが Google Cloud によってプログラムされます。この一貫性は、Cloud Router によって破棄されるルートを含め、Cloud Router タスクを再起動しても保持されます。
ルートドロップの回避
ルートドロップの動作中は、ドロップされるプレフィックスの接続が失われます。ルートドロップを回避するには、Cloud Monitoring または Cloud Logging を使用して、各リージョンの from-own-region のプレフィックスの使用状況と from-other-region のプレフィックスの使用状況をモニタリングし、一意の宛先をそれぞれの上限を超えてアドバタイズしないようにします。
一意の宛先の数を減らすために、プレフィックスを集約する（たとえば、プレフィックスを長さの短いプレフィックスに変換するなど）ことを検討してください。接頭辞の集約ができない場合は、Google Cloud のセールスチームに連絡して、別の選択肢を確認してください。
割り当てを管理する
Cloud Router では、さまざまな理由から、使用できるリソースの割り当て量に上限が設けられています。たとえば、割り当て量の上限を設定して予期しない使用量の急増を防ぐことで、Google Cloud ユーザーのコミュニティを保護しています。割り当て量は、無料枠で Google Cloud を試しているユーザーをトライアルに留めておくのにも役立ちます。
すべてのプロジェクトは同じ割り当て量で開始しますが、追加の割り当て量をリクエストすることで変更できます。一部の割り当て量は、プロダクトの使用状況に応じて自動的に増える場合があります。
権限
Identity and Access Management（IAM）のプリンシパルが割り当ての表示や、割り当ての増加のリクエストをするには、以下のいずれかのロールが必要です。
| タスク | 必要なロール |
|---|---|
| プロジェクトの割り当て量をチェックする | 次のいずれかが必要です。 |
| 割り当て量の変更、割り当て量の追加のリクエストを行う | 次のいずれかが必要です。 |
割り当て量を確認する
コンソール
- 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 ステータス コード HTTP 413 Request Entity Too Large を返します。
追加の割り当てをリクエストする
ほどんどの場合、割り当ての増減を行うには Google Cloud コンソールを使用します。詳細については、割り当ての増加をリクエストするをご覧ください。
コンソール
- Google Cloud コンソールで [割り当て] ページに移動します。
- [割り当て] ページで、変更する割り当てを選択します。
- ページの上部にある [割り当てを編集] をクリックします。
- 名前、メールアドレス、電話番号を入力して、[次へ] をクリックします。
- 割り当てリクエストを入力して、[完了] をクリックします。
- リクエストを送信します。割り当てのリクエストが処理されるまでに、24～48 時間かかります。
リソースの可用性
各割り当て量は、リソースが利用可能な場合に作成できる特定のリソースタイプの最大数を表します。割り当て量によってリソースの可用性が保証されるわけではありません。この点は注意が必要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。
たとえば、us-central1 リージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスは作成できません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。
リージョン全体でリソースを使用できない状況はまれです。ただし、ゾーン内のリソースが使い果たされることはあります。通常、そのリソースタイプのサービスレベル契約（SLA）に影響はありません。詳細については、リソースに関連する SLA をご覧ください。