割り当てと上限

このドキュメントでは、Cloud DNS に適用される割り当てとシステムの上限を示します。

• 割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、Cloud DNS などの Google Cloud サービスによって定義されます。
• システムの上限は固定値で、変更できません。

Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。

Cloud Quotas システムは次のことを行います。

• Google Cloud のプロダクトとサービスの消費量をモニタリングする
• これらのリソースの消費量を制限する
• 割り当て値の変更をリクエストする方法を提供する

ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。

割り当ては通常、Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。

Cloud DNS リソースにはシステムの上限もあります。システムの上限は変更できません。

割り当て

割り当てを変更するには、追加の割り当てをリクエストするをご覧ください。

次の表は、各プロジェクトの Cloud DNS リソースで重要なグローバル割り当てを示しています。その他の割り当てについては、Google Cloud コンソールの [割り当て] ページをご覧ください。

上限

割り当ては追加をリクエストできますが、上限の引き上げについては、特に明記のない限りできないのが一般的です。

API の使用

1 日あたりの API リクエスト（クエリ）数は、プロジェクト レベルで管理されます。Google Cloud CLI と Google Cloud Console を通じて作成したリクエストを含むすべての API リクエストの数は、この上限の計算対象となります。

リソースの上限

ネームサーバーの上限

Cloud DNS では、各一般公開マネージド ゾーンを 5 つのネームサーバー シャードのいずれかに割り当てます。シャードとは、権威ネームサーバー名の中で番号の前に記述されている文字です。たとえば、ns-cloud-e1 から ns-cloud-e4 は E シャードです。

以下のいずれかが同じシャードにすでに存在する場合、ドメインの新しいマネージド ゾーン（domain.example.tld など）は、シャードに割り当てられません。

• 同じ DNS 名（domain.example.tld など）のマネージド ゾーン
• DNS 名のサブドメイン（sub.domain.example.tld など）
• DNS 名の親ドメイン（example.tld など）

これらの制限があるため、一般公開マネージド ゾーンには次の制限が適用されます。

• まったく同じ DNS 名のゾーンを最大で 5 つ作成できます。
• 親ドメインの場合、最大 5 つのサブドメインを作成できます。

この上限は、Google Cloud のすべてのプロジェクトとユーザーに適用されます。委任されていないサブドメインと、他の DNS サービス上でホストされている委任は、この上限の計算対象には含まれません。Cloud DNS で同じ DNS 名の 5 つ目のゾーンが作成されると、他の誰もその DNS 名を使用できなくなります。そのため、5 番目のゾーンを作成しようとすると、ドメインの所有権を TXT レコードで確認するよう求められます。

同じ親ドメインの複数のサブドメイン（domain.example.tld や otherdomain.example.tld など）を、同じシャードに割り当てることができます。ただし、Cloud DNS は、制限を考慮した後、使用可能なシャードを選択する場合があります。各シャードにこのようなサブドメインを作成する場合、親ドメイン example.tld のゾーンは作成できません。

この問題を回避するには、サブドメインにゾーンを作成する前に、必ずその親ドメインにマネージド ゾーンを作成します。

子ドメインがすでにすべてのシャードをブロックしている場合は、次の手順に沿って、親ドメインのシャードを解放します。

1. 各サブドメインのゾーンのネームサーバーを確認して、そのゾーンのシャードを特定します。
2. マネージド ゾーンが最も少ない（重要度が最も低い）シャード（X）を探します。
3. シャード X にあるゾーンを他の DNS サービスにエクスポートします（さらに、そのゾーンの委任を変更します）。
4. 元の委任の TTL が経過した後、シャード X のサブドメインのマネージド ゾーンを削除します。
5. 親ドメインのマネージド ゾーンを作成すると、そのゾーンがシャード X に割り当てられます。
6. サブドメインの削除したマネージド ゾーンを復元します。その場合、サブドメインを復元してから、そのサブサブドメインを復元します。これらは新しいシャードに存在することになるので、そのすべてで更新した委任が必要です。

上限を確認する

次のコマンドを実行して、プロジェクトでの上限を検索できます。次の例では、my-project プロジェクト内の各種オブジェクトの合計の上限を示しています。totalRrdataSizePerChange 割り当てはバイト単位で測定され、変更の追加と削除の両方を合計したものです。

gcloud dns project-info describe my-project

これらは上限ですが、Google Cloud は内部で割り当てとして追跡するため、出力では割り当てとしてラベル付けされます。

id: my-project,
kind: "dns#project",
number: "123456789012",
quota:
    kind: dns#quota,
    managedZones: 10000,
    resourceRecordsPerRrset: 10000,
    rrsetAdditionsPerChange: 3000,
    rrsetDeletionsPerChange: 3000,
    rrsetsPerManagedZone: 10000,
    totalRrdataSizePerChange: 100000,
    labelSets: 1000

デフォルトのプロジェクトとその他のプロジェクトの名前は、Google Cloud Console の [ホーム] ページの上部で確認できます。

割り当てを管理

Cloud DNS では、さまざまな理由から、使用できるリソースの割り当て量に上限が設けられています。たとえば、割り当て量の上限を設定して予期しない使用量の急増を防ぐことで、 Google Cloud ユーザーのコミュニティを保護しています。割り当て量は、無料枠で Google Cloud を試しているユーザーをトライアルに留めておくのにも役立ちます。

すべてのプロジェクトは同じ割り当て量で開始しますが、追加の割り当て量をリクエストすることで変更できます。割り当てによっては、プロダクトの使用状況に応じて自動的に増加される場合もあります。

権限

Identity and Access Management（IAM）のプリンシパルが割り当ての表示や、割り当ての増加のリクエストをするには、以下のいずれかのロールが必要です。

割り当て量を確認する

    gcloud dns project-info describe PROJECT_ID
    

割り当て量を超えたときのエラー

gcloud コマンドで割り当て量を超えた場合、gcloud は quota exceeded エラー メッセージを出力し、終了コード 1 を返します。

API リクエストで割り当て量を超えた場合、Google Cloud は HTTP ステータス コード 413 Request Entity Too Large を返します。

追加の割り当てをリクエスト

通常、割り当てを調整するには、Google Cloud コンソールを使用します。詳細については、割り当ての調整をリクエストするをご覧ください。

リソースの可用性

各割り当て量は、リソースが利用可能な場合に作成できる特定のリソースタイプの最大数を表します。割り当て量によって、リソースの可用性が保証されるわけではない点に注意することが重要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。

たとえば、us-central1 リージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスは作成できません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。

リージョン全体でリソースを使用できない状況はまれです。ただし、ゾーン内のリソースが使い果たされることはあります。通常、そのリソースタイプのサービスレベル契約（SLA）に影響はありません。詳細については、リソースに関連する SLA をご覧ください。