このドキュメントでは、Media CDN に適用される割り当てquotasと上限quotasの一覧を示します。
Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、独自の Google Cloud リソースの管理にも役立ちます。
Cloud Quotas システムは次の処理を行います。
- Google Cloud のプロダクトとサービスの消費量をモニタリングする
- これらのリソースの消費量を制限する
- 割り当て値の変更をリクエストする手段を提供する
ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。
割り当ては通常、Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。
Media CDN リソースには上限もあります。これらの上限は、割り当てシステムとは無関係です。上限は、特に明記されていない限り、変更できません。
上限
Media CDN には次の上限が適用されます。
構成
項目 | 上限 | メモ |
---|---|---|
EdgeCacheService の最大数 |
1 プロジェクトあたり 20 件 | この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
EdgeCacheOrigin の最大数 |
1 プロジェクトあたり 30 件 | この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
EdgeCacheKeyset の最大数 |
1 プロジェクトあたり 10 件 | この上限を引き上げる必要がある場合は、Google Cloud セールスチームにお問い合わせください。 |
EdgeCacheService あたりの RouteRules の最大数 |
2000 | 各 この上限を引き上げることはできません。 |
サービスあたりの最大 SSL 証明書数 | 5 | この上限を引き上げることはできません。SSL 証明書については、プロジェクトごとの割り当てもご覧ください。 |
EdgeCacheKeyset ごとの公開鍵の最大数 |
3 | この上限を引き上げることはできません。鍵セット内の複数の鍵は、鍵のローテーションを有効にするように設計されています。時間の経過とともに、古い鍵と未使用の鍵を削除する必要があります。 |
EdgeCacheKeyset ごとの検証共有鍵の最大数 |
3 | この上限を引き上げることはできません。鍵セット内の複数の鍵は、鍵のローテーションを有効にするように設計されています。時間の経過とともに、古い鍵と未使用の鍵を削除する必要があります。 |
HTTP ヘッダー、リクエスト、レスポンス
項目 | 上限 | メモ |
---|---|---|
リクエスト ヘッダーの最大サイズ | 約 11 KiB | この上限を引き上げることはできません。
リクエスト URL とリクエスト ヘッダーの合計サイズは 15 KiB に制限されています。 リクエストは、HTTP/1.1 接続に対して HTTP 431 レスポンスで拒否されます。 レスポンス コードが書き込まれずに、HTTP/2 接続が閉じられます。
ロギングが有効になっている場合、これらのリクエストは |
リクエスト本文の最大サイズ | 16 KiB | この上限を超える本文のリクエストは、HTTP 413 Content Too Large ステータス コードで拒否されます。 |
レスポンス ヘッダーの最大サイズ | 約 128 KiB | この上限を引き上げることはできません。
この上限を超えるヘッダーを含む送信元のレスポンスでは、HTTP 502 がクライアントに送信されます。ロギングが有効になっている場合、これらは |
キャッシュ可能なオブジェクトの最大サイズ | 100 GiB | この上限を引き上げることはできません。
これは、Media CDN がキャッシュに保存できる送信元にあるオブジェクトの最大サイズです。これのサイズが大きいオブジェクトは、キャッシュ不可として扱われます。 |
キャッシュ不可のレスポンスの最大サイズ | 500 MiB | この上限を引き上げることはできません。
これは、オブジェクトがキャッシュに保存できない場合に、Media CDN がプロキシするレスポンス本文の最大バイト数です。 キャッシュできないレスポンスは、上限に達すると切り捨てられます。 |
ヘッダーの小文字変換 | 常にメディア CDN を使用 | Media CDN は、リクエスト ヘッダーとレスポンス ヘッダーの大文字と小文字について、HTTP/2 の規則に従います。 使用されるプロトコルに関係なく、すべてのヘッダーは小文字に変換されます。
たとえば、 ヘッダー値の大文字と小文字は変更されません。 |
API リクエスト率の上限
API リクエストのより高いレート制限が必要な場合は、現在の使用状況を確認して、増加をリクエストできます。
項目 | 上限 |
---|---|
無効化 | EdgeCacheService あたり 1 分あたり 10 |
networkservices 名前空間にない呼び出しのすべて |
プロジェクトごとに 1 分あたり 1,200 回の呼び出し |
読み取りのみ: GetEdgeCache* 、ListEdgeCache* |
1 プロジェクトあたり毎分 100 回 |
読み取り/書き込み: networkservices 名前空間内のすべてのリソースが読み取り専用としてマークされていない |
1 プロジェクトあたり毎分 100 回 |
クライアントのタイムアウト
タイムアウト | 最大期間 | レスポンス コード | 説明 |
---|---|---|---|
Maximum request duration | 5 分 | HTTP 408 (Request Timeout) | 1 回のリクエスト/レスポンスの最大期間。 |
Header timeout | 10 秒 | HTTP 408 (Request Timeout) | クライアントがリクエスト ヘッダー一式を送信する必要がある時間。 |
送信元のタイムアウト
connectTimeout
とmaxAttemptsTimeout
は、Media CDN が使用可能なレスポンスを検出するまでの時間を制限します。どちらのタイムアウトにも、送信元がヘッダーを返すのと、フェイルオーバーとリダイレクトのどちらを使用するかを決定するのにかかった時間が含まれます。
connectTimeout
は、送信元の試行ごとに独立して適用されますが、maxAttemptsTimeout
には、フェイルオーバーとリダイレクトを含むすべての送信元の試行に接続するために必要な時間が含まれます。リダイレクトに続くと、送信元への接続の試行が新たにカウントされ、構成された送信元に設定されているmaxAttempts
にカウントされます。Media CDN がリダイレクト以外のレスポンス(リダイレクトやフェイルオーバー送信元からなど)を受信すると、
readTimeout
とresponseTimeout
の値が適用されます。リダイレクトされた送信元では、リダイレクトに遭遇したEdgeCacheOrigin
に構成されたconnectTimeout
、readTimeout
、responseTimeout
の値が使用されます。responseTimeout
とreadTimeout
は、ストリーミングされたレスポンスにかかる時間を制御します。Media CDN がアップストリーム レスポンスを使用すると判断した後は、connectTimeout
とmaxAttemptsTimeout
のいずれも関係ありません。この時点で、readTimeout
とresponseTimeout
が有効になります。
Media CDN は、各 EdgeCacheOrigin
によって設定された maxAttempts
に関係なく、すべての送信元について最大 4 回の送信元試行を行います。Media CDN は、プライマリ EdgeCacheOrigin
の maxAttemptsTimeout
値を使用します。試行ごとのタイムアウト値(connectTimeout
、readTimeout
、responseTimeout
)は、各試行の EdgeCacheOrigin
に構成されます。
次の表に、タイムアウト フィールドを示します。
フィールド | デフォルト | 説明 |
---|---|---|
connectTimeout | 5 秒 | Media CDN がリクエストを開始してから送信元が使用可能になるまでの最大時間。この時間が経過するとMedia CDN はレスポンスが使用可能かどうかを判断します。実際には、 タイムアウトは 1 秒~ 15 秒の値にする必要があります。 |
maxAttemptsTimeout | 15 秒 | 送信元に対するすべての接続試行の最大時間。この時間を超えるとクライアントにエラーを返します。これにはフェイルオーバー送信元に対する接続も含まれます。レスポンスが返される前にタイムアウトに達すると、HTTP 504 が返されます。 タイムアウトは 1 秒~ 30 秒の値にする必要があります。 この設定は、すべての送信元の接続試行(フェイルオーバー送信元を含む)の合計時間を定義します。これは、クライアントがコンテンツのストリーミング開始を待機する合計時間の上限を設定するためです。最初の |
readTimeout | 15 秒 | 1 回の HTTP レスポンスの読み取り間の最大待機時間。 |
responseTimeout | 30 秒 | レスポンスが完了するまでに許容される最大時間。 タイムアウトは 1 秒~ 120 秒の値にする必要があります。 この期間は、最初のボディバイトが受信された時点から測定されます。レスポンスが完了する前にこのタイムアウトに達すると、レスポンスは切り捨てられ、ログに記録されます。 |
割り当てを管理する
Media CDN では、さまざまな理由から、使用できるリソースの割り当て量に上限が設けられています。たとえば、割り当て量の上限を設定して予期しない使用量の急増を防ぐことで、 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 ステータス コード 413 Request Entity Too Large
を返します。
追加の割り当てをリクエスト
ほどんどの場合、割り当ての増減を行うには Google Cloud コンソールを使用します。詳細については、割り当ての増加をリクエストするをご覧ください。
コンソール
- Google Cloud コンソールで [割り当て] ページに移動します。
- [割り当て] ページで、変更する割り当てを選択します。
- ページの上部にある [割り当てを編集] をクリックします。
- [名前] に氏名を入力します。
- 省略可: [電話番号] に有効な電話番号を入力します。
- リクエストを送信します。割り当てのリクエストが処理されるまでに、24~48 時間かかります。
リソースの可用性
各割り当て量は、リソースが利用可能な場合に作成できる特定のリソースタイプの最大数を表します。割り当て量によってリソースの可用性が保証されるわけではありません。この点は注意が必要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。
たとえば、us-central1
リージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスは作成できません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。
リージョン全体でリソースを使用できない状況はまれです。ただし、ゾーン内のリソースが使い果たされることはあります。通常、そのリソースタイプのサービスレベル契約(SLA)に影響はありません。詳細については、リソースに関連する SLA をご覧ください。