割り当て
このドキュメントでは、Cloud Service Mesh のコンテンツに関する現在の上限とリクエストの割り当てについて説明します。
割り当ては、Google Cloud プロジェクトで使用できる共有 Google Cloud リソース（ハードウェア、ソフトウェア、ネットワーク コンポーネントなど）の量を制限します。つまり、割り当てはシステムの一部で、次の機能があります。
- Google Cloud のプロダクトとサービスの使用量や消費量をモニタリングする。
- 公平性の確保や使用量急増の抑制などのため、これらのリソースの消費量を制限する。
- 規定の制限を自動的に適用する構成を維持する。
- 割り当てをリクエストまたは変更する手段を提供する。
ほとんどの場合、割り当てを超過すると、システムは関連する Google リソースへのアクセスをすぐにブロックするため、ユーザーが試行しているタスクは失敗します。ほとんどの場合、割り当ては各 Google Cloud プロジェクトに適用され、その Google Cloud プロジェクトを使用するすべてのアプリケーションと IP アドレスで共有されます。
Cloud Service Mesh のリソースにも上限があります。これらの上限は、割り当てシステムとは無関係です。上限は、特に明記されていない限り、変更できません。
Istio リソースは Traffic Director のリソースに変換され、後続の割り当てにカウントされます。
上限
Cloud Service Mesh では、Google Cloud プロジェクトごとの秒間クエリ数（QPS）が 100 に制限されます。
プロジェクトごとの既存のすべての転送ルール、バックエンド サービス、およびその他の負荷分散の上限と割り当てが、Google Cloud ロード バランシングとサービス ルーティング API に基づく Cloud Service Mesh のデプロイに適用されます。
URL マップの上限
ロード バランシング API を使用する Cloud Service Mesh の URL マップには、プロジェクトごとの次の上限が適用されます。
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| URL マップ | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
| パスルールのパス | 50 | この上限を引き上げることはできません。 |
| ルートルールの一致ルール | 50 | この上限を引き上げることはできません。 |
| URL マップごとのホストルール数 | 2,500 | この上限を引き上げることはできません。 |
| URL マップごとのパスマッチャー数 | 2,500 | この上限を引き上げることはできません。 |
| パスマッチャーごとのパスルール数 | 500 | この上限を引き上げることはできません。 |
| 1 パスマッチャーあたりのルートルール数 | 500 | この上限を引き上げることはできません。 |
| 1 マッチング ルールあたりのヘッダーの一致数 | 50 | この上限を引き上げることはできません。 |
| 1 マッチング ルールあたりのクエリ パラメータの一致数 | 50 | この上限を引き上げることはできません。 |
| 一致ルールあたりのメタデータ フィルタ数 | 5 | この上限を引き上げることはできません。 |
| メタデータ フィルタあたりのフィルタラベル数 | 64 | この上限を引き上げることはできません。 |
| ホストルールあたりのホスト数 | 100 | この上限を引き上げることはできません。 |
| URL マップあたりのテスト数 | 100 | この上限を引き上げることはできません。 |
| URL マップのサイズ | 524 KB | この上限を引き上げることはできません。 |
| ルート アクションあたりの重み付けされたバックエンド サービス数 | 10 | この上限を引き上げることはできません。 |
この表のいずれかの上限を超えると、次のようなエラーが表示されます。
Value for field 'resource.hostRules[0].hosts' is too large: maximum size 100 element(s);actual size 107.
サービス ルーティング API の上限
| 項目 | メモ |
|---|---|
| Meshes | この割り当ては 1 プロジェクトあたりの値です。 |
| Gateways | この割り当ては 1 プロジェクトあたりの値です。 |
| GrpcRoutes | この割り当ては 1 プロジェクトあたりの値です。 |
| HttpRoutes | この割り当ては 1 プロジェクトあたりの値です。 |
| TcpRoutes | この割り当ては 1 プロジェクトあたりの値です。 |
| TlsRoutes | この割り当ては 1 プロジェクトあたりの値です。 |
ネットワーク セキュリティ API の上限
| 項目 | 割り当てと上限 | メモ |
|---|---|---|
| clientTlsPolicy | 500 | この割り当ては 1 プロジェクトあたりの値です。 |
| serverTlsPolicy | 500 | この割り当ては 1 プロジェクトあたりの値です。 |
| AuthorizationPolicy | 500 | この割り当ては 1 プロジェクトあたりの値です。 |
| EndpointPolicy | 750 | この割り当ては 1 プロジェクトあたりの値です。 |
サービス ロード バランシング ポリシー
| 項目 | 割り当てと上限 | 注 |
|---|---|---|
| ServiceLbPolicies | 割り当て | この割り当ては 1 プロジェクトあたりの値です。 |
ほどんどの場合、割り当ての増減を行うには Google Cloud コンソールを使用します。詳細については、割り当ての増加をリクエストするをご覧ください。
割り当てを管理する
Cloud Service Mesh では、さまざまな理由から、使用できるリソースの割り当て量に上限が設けられています。たとえば、割り当て量の上限を設定して予期しない使用量の急増を防ぐことで、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 をご覧ください。