このドキュメントでは、Media CDN に適用される割り当てとシステム上限の一覧を示します。
- 割り当てにはデフォルト値がありますが、通常は調整をリクエストできます。
- システムの上限は固定値で、変更できません。
Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、 Google Cloud プロジェクトで使用できるGoogle Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。
Cloud Quotas システムは次のことを行います。
- Google Cloud のプロダクトとサービスの消費量をモニタリングする
- これらのリソースの消費量を制限する
- 割り当て値の変更をリクエストし、割り当ての調整を自動化する手段を提供する
ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。
割り当ては通常、 Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。 Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。
詳細については、Cloud Quotas の概要をご覧ください。
Media CDN リソースにはシステムの上限もあります。システムの上限は変更できません。
割り当て
次の割り当てが Media CDN に適用されます。割り当てを増やす必要がある場合は、 Google Cloud セールスチームにお問い合わせのうえ、調整をご依頼ください。詳細については、割り当ての調整をリクエストするをご覧ください。
構成
| 項目 | デフォルトの割り当て |
|---|---|
プロジェクトあたりの EdgeCacheService リソースの最大数 |
20 |
プロジェクトあたりの EdgeCacheOrigin リソースの最大数 |
30 |
プロジェクトあたりの EdgeCacheKeyset リソースの最大数 |
10 |
システム制限
Media CDN には次の上限が適用されます。
構成
| 項目 | 上限 | メモ |
|---|---|---|
EdgeCacheService あたりの RouteRules リソースの最大数 |
200 | 各 |
EdgeCacheService あたりの PathMatchers リソースの最大数 |
50 | 各 |
| サービスあたりの SSL 証明書の最大数 | 5 | SSL 証明書については、プロジェクトごとの割り当てをご覧ください。 |
EdgeCacheKeyset あたりの公開鍵の最大数 |
3 | 鍵セット内の複数の鍵により、鍵のローテーションが可能になります。未使用のキーは時間の経過とともに削除されます。 |
EdgeCacheKeyset あたりの検証共有鍵の最大数 |
3 | 鍵セット内の複数の鍵は、鍵のローテーションを有効にするように設計されています。時間の経過とともに、古い鍵と未使用の鍵を削除する必要があります。 |
HTTP ヘッダー、リクエスト、ステータス コード
| 項目 | 上限 | メモ |
|---|---|---|
| リクエスト パスを含むリクエスト ヘッダーの最大サイズ | 16 KiB | この上限を引き上げることはできません。
基盤となるプロトコルに応じて、レスポンス コードが書き込まれずにリクエスト接続が閉じられるか、HTTP
ロギングが有効になっている場合、これらのリクエストは |
| リクエスト本文の最大サイズ | 16 KiB | この上限を引き上げることはできません。 この上限を超える本文のリクエストは、HTTP |
| レスポンス ヘッダーの最大サイズ | 約 128 KiB |
この上限を超えるヘッダーを含むオリジン レスポンスは、クライアントに HTTP |
| キャッシュ可能なオブジェクトの最大サイズ | 100 GiB |
これは、Media CDN がキャッシュに保存できる送信元のオブジェクトの最大サイズです。これのサイズが大きいオブジェクトは、キャッシュ不可として扱われます。 |
| キャッシュに保存不可のレスポンスの最大サイズ | 500 MiB |
これは、オブジェクトがキャッシュに保存できない場合に、Media CDN がプロキシするレスポンス本文の最大バイト数です。 キャッシュできないレスポンスは、上限に達すると切り捨てられます。 |
| ヘッダーの小文字変換 | Media CDN の場合は常に | Media CDN は、リクエスト ヘッダーとレスポンス ヘッダーの大文字と小文字について、HTTP/2 の規則に従います。 使用されるプロトコルに関係なく、すべてのヘッダーは小文字に変換されます。
たとえば、 ヘッダー値の大文字と小文字は変更されません。 |
API リクエスト率の上限
API リクエストのレート制限を引き上げる必要がある場合は、現在の使用状況を確認して、引き上げをリクエストできます。
| 項目 | 上限 |
|---|---|
EdgeCacheService あたりの無効化数 |
1 分あたり 10 |
プロジェクトごとの networkservices 名前空間にない呼び出しのすべて |
1 分あたり 1,200 回の呼び出し |
読み取り専用: プロジェクトごとに GetEdgeCache*、ListEdgeCache* |
100/分 |
読み取り/書き込み: プロジェクトごとに読み取り専用としてマークされていない networkservices 名前空間内のすべてのリソース |
100/分 |
create、patch、delete などの更新リクエストは、一度に 1 つずつ送信することをおすすめします。API は複数の同時リクエストをキューに登録しますが、これらのリクエストを同時に送信すると、システムが各アイテムをシリアルに処理するため、レイテンシが大幅に増加し、処理時間が長くなる可能性があります。
クライアントのタイムアウト
| タイムアウト | 最大期間 | ステータス コード | 説明 |
|---|---|---|---|
| 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 タイムアウトは 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 コンソールを使用します。詳細については、割り当ての調整をリクエストするをご覧ください。
リソースの可用性
各割り当て量は、リソースが利用可能な場合に作成できる特定のリソースタイプの最大数を表します。割り当て量によってリソースの可用性が保証されるわけではありません。この点は注意が必要です。割り当て量が使用可能でも、新しいリソースを使用できなければ、そのリソースを作成することはできません。
たとえば、特定のリージョンで新しいリージョンの外部 IP アドレスを作成するための割り当て量が十分にあっても、そのリージョンに使用可能な外部 IP アドレスがない場合、外部 IP アドレスは作成できません。ゾーンリソースの可用性は、新しいリソースを作成できるかにも影響を及ぼす可能性があります。
リージョン全体でリソースを使用できない状況はまれです。ただし、ゾーン内のリソースが使い果たされることはあります。通常、そのリソースタイプのサービスレベル契約（SLA）に影響はありません。詳細については、リソースに関連する SLA をご覧ください。