このドキュメントでは、Cloud DNS に適用される割り当てと上限を示します。
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 コンソールの [割り当て] ページをご覧ください。
項目 | 説明 |
---|---|
リージョンにおける 1 分の読み取り上限 | 100 秒間に IAM ユーザーが Cloud DNS API に発行できる API リクエストの最大数。この割り当ては API 呼び出しにのみ適用されます。DNS クエリを処理する際に、割り当ては適用されません。 |
マネージド ゾーンあたりの DNSSEC 鍵 | マネージド ゾーンあたりの DNSSEC 鍵の最大数。 |
プロジェクトあたりのマネージド ゾーン | プロジェクト内の管理対象ゾーンの最大許容数。 |
VPC ネットワークあたりのマネージド ゾーン | VPC ネットワークに接続できるマネージド ゾーンの最大数。 |
プロジェクトあたりのポリシー リソース | プロジェクトごとの DNS サーバー ポリシーの最大数。 |
レスポンス ポリシーあたりのネットワーク数 | レスポンス ポリシーごとの VPC ネットワークの最大数。 |
ルーティング ポリシーあたりのアイテム数 | ルーティング ポリシーごとに許可されるアイテムの最大数。 |
マネージド ゾーンあたりの GKE クラスタ数 | 限定公開スコープのゾーンを接続できる Google Kubernetes Engine(GKE)クラスタの最大数。 |
ポリシーあたりの GKE クラスタ | ポリシーごとの GKE クラスタの最大数。 |
GKE クラスタあたりのマネージド ゾーン | GKE クラスタに接続できるマネージド ゾーンの最大数。 |
変更あたりのリソース レコードの追加 | ChangesCreateRequest あたりに追加できる ResourceRecordSets の最大数。 |
変更あたりのリソース レコードの削除数 | ChangesCreateRequest ごとに削除できる ResourceRecordSets の最大数。 |
マネージド ゾーンあたりのリソース レコードセット | プロジェクトのゾーンあたりの ResourceRecordSets の最大許容数。 |
リソース レコードセットあたりのリソース レコード数 | ResourceRecordSet あたりの ResourceRecords の最大許容数。各委任(種類 NS のリソース レコードのセット)には最大 8 個のネームサーバーを含めることができます。 |
プロジェクトあたりのレスポンス ポリシー | プロジェクトごとに許可されるレスポンス ポリシーの最大数。 |
リージョンにおける 1 分間のレスポンス ポリシー ルールの書き込み上限 | 1 つのリージョンで 1 分あたりに書き込めるレスポンス ポリシー ルールの最大数。 |
バッチ アクションあたりのレスポンス ポリシー ルール数 | 1 分あたりのバッチあたりのレスポンス ポリシー管理アクションの最大数。 |
ポリシーごとのレスポンス ポリシー ルール | ポリシーに対して作成できるレスポンス ポリシー ルールの最大数。 |
転送ポリシーあたりのターゲット ネームサーバー数 | 転送ポリシーごとに許可される転送先ネームサーバーの最大数。 |
マネージド ゾーンあたりのターゲット ネームサーバー数 | マネージド転送ゾーンあたりの許容される転送先ネームサーバーの最大数。 |
変更あたりのリソース レコードセット データの合計サイズ(バイト単位) | 1 つの ChangesCreateRequest の合計 rrdata の最大許容サイズ(バイト単位)。 |
マネージド ゾーンあたりの VPC ネットワーク数 | 限定公開スコープのゾーンを接続できる VPC ネットワークの最大数。 |
ポリシーあたりの VPC ネットワーク数 | Cloud DNS サーバー ポリシーごとに許可される VPC ネットワークの最大数。 |
リージョンでの 1 分間の書き込み上限 | 1 リージョン、1 分あたりの DNS 書き込みの最大数。この割り当ては、DNS レコードの作成、変更、削除を行う書き込みオペレーションに使用されます。 |
上限
割り当ては追加をリクエストできますが、上限の引き上げについては、特に明記のない限りできないのが一般的です。
API の使用
1 日あたりの API リクエスト(クエリ)数は、プロジェクト レベルで管理されます。Google Cloud CLI と Google Cloud Console を通じて作成したリクエストを含むすべての API リクエストの数は、この上限の計算対象となります。
リソースの上限
項目 | 上限 |
---|---|
これらの上限の更新をリクエストするには、Cloud カスタマーケアにお問い合わせください。 | |
ネットワークあたりのピアリング ゾーンの数 | 1,000 |
委任あたりのネームサーバー数 | 8 |
変更あたりの追加 | 1,000 |
変更あたりの削除 | 1,000 |
変更あたりのリソース レコード データ サイズ | 100,000 バイト |
ラベルの組み合わせの数 | 1,000 |
レスポンス ポリシーごとのルール数 | 10,000 |
ルーティング ポリシーあたりのアイテム数 | 100 |
VPC ネットワークにバインドされるマネージド ゾーン数 | 10,000 |
DNS レスポンスの最大サイズ(UDP) | 1,440 バイト |
DNS レスポンスの最大サイズ(TCP) | 65,533 バイト |
この上限を引き上げることはできません。 | |
VPC ネットワーク、ゾーンあたりの最大クエリレート | Google Cloud ゾーンで 10 秒間(10s)の間に 100,000 件のクエリ(例: us-central1-a ) |
VPC ネットワークあたりのレスポンス ポリシーの数 | 1 |
マネージド ゾーンあたりのラベル数 | キーまたは値あたりラベル 64 個および 128 バイト |
転送ゾーン内の転送ターゲット数 | 50 |
代替ネームサーバー内の転送ターゲット数 | 50 |
ネームサーバーの上限
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
のゾーンは作成できません。
この問題を回避するには、サブドメインにゾーンを作成する前に、必ずその親ドメインにマネージド ゾーンを作成します。
子ドメインがすでにすべてのシャードをブロックしている場合は、次の手順に沿って、親ドメインのシャードを解放します。
- 各サブドメインのゾーンのネームサーバーを確認して、そのゾーンのシャードを特定します。
- マネージド ゾーンが最も少ない(重要度が最も低い)シャード(XX)を探します。
- シャード XX にあるゾーンを他の DNS サービスにエクスポートします(さらに、そのゾーンの委任を変更します)。
- 元の委任の TTL が経過した後、シャード X のサブドメインのマネージド ゾーンを削除します。
- 親ドメインのマネージド ゾーンを作成すると、そのゾーンがシャード XX に割り当てられます。
- サブドメインの削除したマネージド ゾーンを復元します。その場合、サブドメインを復元してから、そのサブサブドメインを復元します。これらは新しいシャードに存在することになるので、そのすべてで更新した委任が必要です。
上限を確認する
次のコマンドを実行して、プロジェクトでの上限を検索できます。次の例では、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)のプリンシパルが割り当ての表示や、割り当ての増加のリクエストをするには、以下のいずれかのロールが必要です。
タスク | 必要なロール |
---|---|
プロジェクトの割り当て量をチェックする | 次のいずれかが必要です。 |
割り当て量の変更、割り当て量の追加のリクエストを行う | 次のいずれかが必要です。 |
割り当て量を確認する
Console
- Google Cloud コンソールで、[割り当て] ページに移動します。
- 更新する割り当てを検索するには、[表をフィルタリング] を使用します。割り当ての名前がわからない場合は、このページにあるリンクを使用します。
gcloud
Google Cloud CLI で次のコマンドを実行して、割り当てを確認します。
PROJECT_ID
は、実際のプロジェクト ID に置き換えます。
gcloud dns project-info describe PROJECT_ID
割り当て量を超えたときのエラー
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 をご覧ください。