Cloud Storage を効果的に使用するには、サービスの基礎となるコンセプトをいくつか理解する必要があります。このページでは、Cloud Storage の主な用語とコンセプトについて説明します。
Cloud Storage の使用方法については、Cloud Storage とはをご覧ください。
プロジェクト
Cloud Storage 内のデータはすべてプロジェクト内に属します。一連のユーザー、一連の API、これらの API の請求、認証、モニタリングの設定で構成されます。1 つまたは複数のプロジェクトを保持できます。
バケット
バケットは、データを格納する基本的なコンテナです。Cloud Storage 内に保存するデータはすべてバケットに格納する必要があります。バケットは、データの整理やアクセス制御に使用できますが、ディレクトリやフォルダと異なり、入れ子構造にすることはできません。バケットの作成と削除には制限があるため、オブジェクト オペレーションを集中的に行ってバケット オペレーションを比較的少なくするようにストレージ アプリケーションを設計することをおすすめします。
バケットを作成するときに、グローバルに一意の名前、バケットとそのコンテンツを保存する地理的なロケーション、デフォルトのストレージ クラスを指定します。選択したデフォルトのストレージ クラスは、ストレージ クラスが明示的に指定されていないバケットに追加されたオブジェクトに適用されます。
バケットを作成した後も、デフォルトのストレージ クラスをバケットのロケーションでサポートされる任意のクラスに変更できます。ただし、バケット名とロケーションを変更するには、バケットを削除して再度作成する必要があります。
バケット名
すべてのバケットは Cloud Storage の 1 つの名前空間内に格納されるため、バケット名にはオブジェクト名よりも厳しい制約があり、グローバルに一意である必要があります。詳しくは、バケットの命名ガイドラインをご覧ください。
バケットラベル
バケットラベルは、仮想マシン インスタンスや永続ディスクなどの他の Google Cloud リソースとともにバケットをグループ化できる Key-Value のメタデータペアです。たとえば、ラベルを使用して alpha、beta、delta の値を持つ team キーを作成し、team:alpha、team:beta、team:delta ラベルを異なるバケットに割り当てて、どのチームがそれらのバケットに関連付けられているかを示すことができます。
各バケットに複数のラベルを適用できます。バケットごとに最大 64 個のラベルを付けることができます。
- キーと値は、それぞれ 63 文字以下にする必要があります。
- キーと値に使用できるのは、小文字、数字、アンダースコア、ダッシュだけです。国際文字も使用可能。
- ラベルのキーは小文字で始める必要があります。国際文字は使用できます。
- ラベルのキーは空にできません。
- 一般的にはバケット メタデータの場合と同様に、バケットラベルは個々のオブジェクトやオブジェクト メタデータには関連付けられません。
請求でリソースの整理にラベルを使用する一般的な例については、BigQuery クエリへの請求のエクスポート例をご覧ください。
オブジェクト
オブジェクトとは、Cloud Storage 内に保存する個々のデータのことです。バケットで作成できるオブジェクトの数に上限はありません。
オブジェクトは、オブジェクト データとオブジェクト メタデータという 2 つのコンポーネントで構成されます。オブジェクト データは通常、Cloud Storage に保存するファイルです。オブジェクト メタデータは、オブジェクトのさまざまな性質を記述した名前と値のペアの集合です。
オブジェクト名
オブジェクト名は、Cloud Storage のオブジェクト メタデータとして扱われます。オブジェクト名には任意の Unicode 文字（エンコーディングは UTF-8）を組み合わせて使用できます。オブジェクト名の長さは 1,024 バイト未満にして、バケット内で一意である必要があります。
Cloud Storage ではフラット名前空間を使用してオブジェクトを保存します。つまり、Cloud Storage では特定のバケット内のすべてのオブジェクトを階層関係なしで独立して認識します。便宜上、Google Cloud Console や gsutil などのツールでは、スラッシュ（/）文字を使用して、オブジェクトを仮想階層に保存されているかのように操作します。
たとえば、あるオブジェクトの名前を /europe/france/paris.jpg とし、別のオブジェクトの名前を /europe/france/cannes.jpg にできます。Cloud Console を使用すると、こうしたオブジェクトに、フォルダ europe と france の下にある階層ディレクトリ構造のように移動できます。
オブジェクトの名前変更などの詳細については、オブジェクトの命名ガイドラインをご覧ください。
オブジェクトのバージョンと世代番号
Cloud Storage のオブジェクトは複数のバージョンを持つことができます。デフォルトでは、オブジェクトを上書きすると、Cloud Storage は古いバージョンを削除して新しいバージョンに置き換えます。バケットでオブジェクトのバージョニングを有効にすると、上書きまたは削除が行われても古いバージョンがバケットに残ります。
オブジェクトの各バージョンは、オブジェクトのメタデータに含まれる世代番号によって一意に識別されます。オブジェクトのバージョニングによって古いバージョンのオブジェクトが作成されている場合は、世代番号を使用して古いバージョンを参照できます。そのため、バケット内の上書きされたオブジェクトを復元することも、不要になった古いオブジェクトのバージョンを完全に削除することもできます。世代番号は、リクエストに前提条件を含めるときにも使用されます。
リソース
リソースとは、Google Cloud 内のエンティティです。Compute Engine インスタンスと同様に、Google Cloud のそれぞれのプロジェクト、バケット、オブジェクトがリソースになります。
リソース名
各リソースには、ファイル名のような固有の名前が付いています。バケットのリソース名の形式は projects/_/buckets/BUCKET_NAME です。ここで、BUCKET_NAME はバケットの ID です。オブジェクトのリソース名の形式は projects/_/buckets/BUCKET_NAME/objects/OBJECT_NAME です。ここで、OBJECT_NAME はオブジェクトの ID です。
リソース名の末尾に付加される #NUMBER は、オブジェクトの特定の世代を示します。#0 は、オブジェクトの最新バージョンを示す特別な識別子です。#0 を追加することは、そのようにしないとオブジェクト名の最後の文字列が世代番号として解釈される場合に役立ちます。
地域的な冗長性
地理的に冗長なデータは、少なくとも 100 マイル離れている 2 つ以上の場所に保存されています。マルチリージョンとデュアルリージョンに保存されているオブジェクトは、そのストレージ クラスに関係なく地理的に冗長です。
地理的な冗長性は非同期的に発生しますが、どの Cloud Storage も、アップロードの直後に少なくとも 1 つの地理的な場所内で冗長性を維持します。
地理的な冗長性により、天災などの大規模な災害が発生した場合でも、データの可用性が最大限確保されます。デュアルリージョンの場合、2 つの地理的な場所を使用することで地理的な冗長性を実現します。マルチリージョンの場合は、特定のマルチリージョン内のデータセンターを組み合わせることで地理的な冗長性を実現します。利用できるリージョンとして明示的に一覧表示されていないデータセンターも使用できます。
データの不透明性
オブジェクトのデータ コンポーネントは、Cloud Storage に対して完全に不透明となります。つまり、データ コンポーネントは Cloud Storage には単なるデータのかたまりとしてしか認識されません。
オブジェクトの不変性
オブジェクトは不変です。具体的には、アップロードされたオブジェクトは、その保存期間が終わるまで変わることはありません。オブジェクトの保存期間とは、オブジェクトが作成（アップロード）された時点から、オブジェクトが削除された時点までを指します。つまり、後からオブジェクトに付加や切り捨てなどのオペレーションで部分的な変更を加えることはできません。ただし、Google Cloud Storage に保存されているオブジェクトを上書きすることは可能で、この上書きはアトミックに行われます。新しいアップロードが完了するまではオブジェクトの古いバージョンがリーダーに配信され、アップロードが完了すると、オブジェクトの新しいバージョンがリーダーに配信されます。したがって、上書きオペレーションを 1 回行うと、1 つの不変オブジェクトの保存期間が終了し、別の新たな不変オブジェクトの保存期間が開始することになります。
バケット内のさまざまなオブジェクトを作成または更新できる頻度に上限はありません。ただし、同じオブジェクトの更新または上書きは、1 秒あたり 1 回しか実行できません。たとえば、バケット foo 内にオブジェクト bar がある場合、foo/bar の新しいコピーのアップロードは 1 秒あたり 1 回しか行えません。同じオブジェクトを 1 秒に 1 回よりも頻繁に更新すると、429 Too Many Requests エラーが発生します。
失敗したリクエストは、切り捨て型指数バックオフを使用して再試行してください。