このページでは、Cloud Storage の割り当てとリクエストの制限について説明します。
バケット
バケットの作成と削除は、プロジェクトごとに 2 秒あたり約 1 回のレート制限があるので、ほとんどの場合、より少ないバケットでより多くのオブジェクトを使用するように計画します。たとえば、一般的な設計では、プロジェクトのユーザーごとに 1 つのバケットを使用します。ただし、1 秒間に多数のユーザーを追加したり、ロボット認証情報を使用してオブジェクトを作成したりするシステムを設計している場合は、1 つのバケットを多数のユーザーで使用するように設計し（適切な権限を使用します）、バケット作成レート制限がボトルネックにならないようにします。
可用性の高いアプリケーションを作成する場合には、アプリケーションのクリティカル パスでバケットの作成または削除に依存しないでください。バケット名は、一元化されたグローバル名前空間の一部になっています。この名前空間に依存すると、アプリケーションで単一障害点が生じます。この問題と前述の 2 秒に 1 回のレート制限があるため、Cloud Storage で可用性の高いサービスを作成する場合には、必要なバケットをすべて事前に作成してください。
各バケットには、1 秒間に 1 回という更新制限があるため、1 つのバケットを頻繁に更新（たとえば、CORS 構成の変更など）するとスケーラブルではなくなります。
以前の IAM の役割を保持するメンバーはバケットごとに 100 人に制限されています。
オブジェクト
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 に制限されています。
-
1 回の作成リクエストで最大 32 個のオブジェクトを作成できます。
複合オブジェクトを構成するコンポーネントの数に制限はありませんが、複合オブジェクトに関連付けられる
componentCountメタデータは 2,147,483,647 個が上限となります。複合オブジェクトには、Cloud Storage に格納されたオブジェクトに対する合計 5 TB のサイズ制限が適用されます。
XML API リクエスト
- XML API を使用してリクエストを送信する場合は、リクエスト URL と HTTP ヘッダーの合計サイズが 16 KB に制限されます。
