割り当てと上限

このページでは、Cloud Storage の割り当てとリクエストの上限について説明します。

バケット

• バケットの作成と削除は、プロジェクトごとに 2 秒あたり約 1 回のレート上限があるので、ほとんどの場合、より少ないバケットでより多くのオブジェクトを使用するように計画します。たとえば、一般的な設計では、プロジェクトのユーザーごとに 1 つのバケットを使用します。ただし、1 秒間に多数のユーザーを追加する場合は、1 つのバケットを多数のユーザーで使用するように設計し（適切な権限を使用します）、バケット作成レート上限がボトルネックにならないようにします。

• 可用性の高いアプリケーションを作成する場合には、アプリケーションのクリティカル パスでバケットの作成または削除に依存しないでください。バケット名は、一元化されたグローバル名前空間の一部になっています。この名前空間に依存すると、アプリケーションで単一障害点が生じます。この問題と前述の 2 秒に 1 回のレート上限があるため、Cloud Storage で可用性の高いサービスを作成する場合には、必要なバケットをすべて事前に作成してください。

• 各バケットには、1 秒間に 1 回という更新上限があるため、1 つのバケットを頻繁に更新（たとえば、CORS 構成の変更など）するとスケーラブルではなくなります。

• 以前の IAM の役割を保持するメンバーはバケットごとに 100 人に制限されています。メンバーの例としては、個々のユーザー、グループ、ドメインが挙げられます。IAM の ID をご覧ください。

オブジェクト

• Cloud Storage に保存されているオブジェクトごとに 5 TB の最大サイズ上限があります。

• 各オブジェクトには、1 秒間に 1 回という更新上限があるため、1 つのオブジェクトに頻繁に書き込むとスケーラブルではなくなります。詳細については、「主な用語」のオブジェクトの不変性をご覧ください。

• オブジェクトのアップロード、更新、削除を含め、複数のオブジェクトへの書き込みには上限がありません。バケットは最初 1 秒あたり約 1,000 回の書き込みをサポートし、その後必要に応じてスケーリングします。

• オブジェクトの読み取りに上限はありません。バケットは最初 1 秒あたり約 5,000 回の読み取りをサポートし、その後必要に応じてスケーリングします。

• 公開キャッシュ可能なオブジェクトではパフォーマンスがはるかに向上します。多くのクライアントを制御するためにオブジェクトを使用している場合に、キャッシュを無効にして最新のデータを提供する手順は次のとおりです。

  • オブジェクトの Cache-Control メタデータを public に設定し、max-age を 15～60 秒に設定することを検討してください。ほとんどのアプリケーションでは 1 分間の間隔を許容でき、キャッシュのヒット率によりパフォーマンスが劇的に向上します。

  • バケットと同じロケーションにある Google App Engine アプリケーションを通じて、データ転送をプロキシ処理します。

  • エッジ キャッシュにおいて後続のリクエストでオブジェクトをキャッシュに入れてはならないことを指示するには、そのオブジェクトについて Cache-Control: no-cache を使用します。

  Cache-Control ディレクティブの詳細については、RFC 7234: Cache-Control をご覧ください。

• オブジェクトごとのアクセス制御リスト（ACL）のエントリ数の上限は 100 です。メンバーは個々のユーザー、グループ、ドメインのいずれでもかまいません。ACL スコープをご覧ください。

• オブジェクトの作成:

  • 1 回の作成リクエストで最大 32 個のオブジェクトからなる複合オブジェクトを作成できます。

  • 複合オブジェクトを構成するコンポーネントの数に上限はありませんが、複合オブジェクトに関連付けられる componentCount メタデータは 2,147,483,647 個が上限となります。

  • 複合オブジェクトには、Cloud Storage に格納されたオブジェクトに対する合計 5 TB のサイズ上限が適用されます。

XML API リクエスト

• XML API を使用してリクエストを送信する場合、リクエスト URL と HTTP ヘッダーの合計サイズ上限は 16 KB です。

サービス アカウントの HMAC キー

• HMAC キーはサービス アカウントごとに 5 つに制限されています。削除されたキーはこの上限にカウントされません。