G-genの杉村です。 Google Cloud (旧称 GCP) の容量無制限・低価格・堅牢なオブジェクトストレージサービスである Cloud Storage を解説します。

Cloud Storage の基本

Cloud Storage とは

Cloud Storage とは Google Cloud (旧称 GCP) の容量無制限・低価格・堅牢なオブジェクトストレージサービスです。略称として GCS とも呼称されます (Google Cloud Storage の略) 。

データは少なくとも 2 つ以上のゾーン (ゾーンは一つ以上のデータセンターで構成) にわたって冗長化され 99.999999999% (イレブンナイン) の堅牢性を誇ります (参考) 。

ストレージクラスと呼ばれる価格帯の違う4種類の保管タイプが利用でき、アクセス頻度によって使い分けます。

オブジェクトストレージとは

Cloud Storage は オブジェクトストレージ と呼ばれるタイプのストレージです。
代表的なオブジェクトストレージとしては他に Amazon S3 が挙げられます。

オブジェクトストレージはパソコンやサーバから使われるような、ファイルシステム経由で読み書きされるストレージとは異なります。
データは「オブジェクト」という単位で管理され、これが従来でいうファイルに相当します。

また Cluod Storage においては、オブジェクトは Web API 経由で読み書き されます。

使い方

利用者は以下のいずれかの方法で Cloud Storage を利用できます。

Google Cloud コンソール
CLI ツール (gcloud / gsutil)
Cloud SDK クライアントライブラリ

Google Cloud コンソールでは、Web ブラウザ上で容易に Cloud Storage の操作が可能です。

大量のオブジェクトの処理をしたり、自動化を行うには CLI ツールを利用すると便利です。CLI ツールには gcloud と gsutil の2種類があります。gcloud は他の Google Cloud サービス全般を操作することができるツールであり、後述の gsutil よりも処理が高速とされています。gsutil は、gcloud コマンドが Cloud Storage に対応する以前よりあったツールであり、過去には Cloud Storage を操作するための唯一の CLI ツールでした。今後は機能が gcloud コマンドに移行されていくと想定されます。

gcloud コマンドラインでの操作については、以下の記事もご参照ください。

blog.g-gen.co.jp

ユースケース

Cloud Storage は以下のような用途がユースケースとなります。

画像ファイル・動画ファイルなど、変更がなくサイズが大きいファイルの保存
頻繁にアクセスされないファイルのバックアップ
データレイク (非構造データ)
システム間のデータの受け渡し

なお Cloud Storage は、サーバーにマウントしてファイルシステムとして読み書きすることは原則的にできません (... が、これを可能にする離れ業もあります。後述) 。

料金 (基本)

Cloud Storage の特徴は、安価であることです。
東京リージョンの Standard Storage のデータ保管料金は 2022 年 3 月現在で $0.023 (GB/月) です。
ファイル保管料金は概ね、 1 TB で 3,000 円程度と認識すれば良いでしょう。
最新の料金は料金ページを参照したり試算ツールをご利用ください。

ただし Cloud Storage の料金はデータ保管のボリュームだけでなく、 API リクエストの回数など、複数の軸で課金されます。
これについては後述します。

またCloud Storage の料金には「 ストレージクラス 」という重要な考慮事項がありますので、これについても後述します。

用語

バケット

Cloud Storage における バケット とは、データを入れるための箱です。
バケットの単位でアクセス制御をしたり、どのリージョンに配置するかを決めることができます。バケットには全世界で一意の名前が付けられます。

なお bucket とは「バケツ」の意味です。

オブジェクト

オブジェクト とは、バケットに入れられた個々のファイルを指します。
Cloud Storage のようなオブジェクトストレージでは基本的に、オブジェクトを一度書き込むと 「変更」という概念はありません 。
削除するか同名のオブジェクトで上書きすることになります。既に存在するオブジェクトを開いて編集し、1行足す、といったことはできません。
これをやりたい場合、1行を足した新しいファイルで既存オブジェクトを上書きすることになります。

なお1つのオブジェクトの最大サイズは 5 TiB です。

メタデータ

オブジェクトには メタデータ という付加情報を付与できます。
メタデータはキー・バリューのペアで保存されます。

例としてオブジェクトに Cache-Control:no-store のようにメタデータを付与すれば、オブジェクトを一般公開した際に、 HTTP レスポンスヘッダーに Cache-Control:no-store が付与されキャッシュ可否をコントロールできます。
Content-Type なども同様の使い方ができます。

上記のような HTTP ヘッダーに関連するメタデータのみならず、ユーザーが任意のキー・バリューを設定することができます。

フォルダ

フォルダ とは、バケットの中を区切る箱です。パソコンのフォルダと同様です。

...普段は意識する必要はありませんが、実は Cloud Storage の内部的にはフォルダという概念は 存在しません 。
Cloud Storage は内部的にはいわゆるキー・バリュー・ストアであり、平坦な構成になっています。

gs://my-bucket/my-folder/my-object というオブジェクトがあるとすると my-folder には実はフォルダという実体はなく、単に my-object というオブジェクトの名前の一部なのです。
Web コンソールや CLI ツールで空のフォルダを作ることができますが、これは実は 0 バイトのオブジェクトが作成される、という動きをしています (参考) 。

パス

パスとは特定のオブジェクトを指し示す文字列です。見た目は Linux のパスと似ています。

gs://my-bucket/my-folder/myobject のように表されます。
先頭の gs:// は Cloud Storage のオブジェクトのパスであることを示す接頭辞です。

Cloud Storage の詳細

料金 (詳細)

料金体系を詳しく解説します。
Cloud Storage では以下の軸ごとに従量課金が発生します。

データ保存ボリューム (GB/月)
書き込みオペレーション回数
読み取りオペレーション回数
ネットワーク利用 (ダウンロード方向のみ、 GB)
取り出し料金 (GB)

後述の「ストレージクラス」ごとに料金は異なります。

これらの料金の試算には料金ページを見て手計算するほか無料の試算ツールが使えます。
(ネットワーク利用料金だけ Networking Egress という別アイコンであることにご注意ください)

ストレージクラス

Cloud Storage には 4 つの ストレージクラス が存在します。

Standard / Nearline / Coldline / Archive です。右に行くほど長期保存で取り出し頻度が少ないデータに適しています。
先の料金の項にあったように Cloud Storage にはいくつかの料金軸があります。右のストレージクラスほど GB あたりのデータ保管料金が安いが、オペレーション回数あたりの料金や取り出し GB あたりの料金が高くなる仕組みになっています。

例えば以下のようです (2022 年 3 月現在、東京リージョン) 。

ストレージクラス	保管料金 (GB/月)	書き込みオペレーション (10,000回あたり)	読み取りオペレーション (10,000回あたり)	データ取り出し量 (GB)	最低保管期間
Standard Storage	$0.023	$0.05	$0.004	$0	なし
Nearline Storage	$0.016	$0.10	$0.01	$0.01	30 日
Coldline Storage	$0.006	$0.10	$0.05	$0.02	90 日
Archive Storage	$0.0025	$0.50	$0.50	$0.05	365 日

長期保管用のストレージクラスほど、データサイズあたりの料金は安いが、取り出しにお金がかかることが分かると思います。

最低保管期間 (Minimum storage duration) が各ストレージクラスごとに定められており、保管したオブジェクトがこの日数以内に削除・置換・移動された場合、この日数分の保管料金が発生してしまいます (削除できない訳ではありません) 。

ストレージクラスはバケット作成時に デフォルトストレージクラス として指定できる他、オブジェクトごとに指定することもできます。

バケットにオブジェクトが作成されるとデフォルトストレージクラスに従ってストレージクラスが設定されますが、オブジェクトごとに個別に指定できますし、後から変更も可能です。

なお全てのストレージクラスで、データ取り出し時のレイテンシは「最初のバイト転送開始まで数十ミリ秒程度」とされています。AWS の Amazon S3 等ではアーカイブレベルのストレージの取り出しには時間がかかる場合がありますが、Cloud Storage においてはどのストレージクラスでも迅速にデータを取り出すことができます。

Soft delete ポリシー

Soft delete ポリシー（日本語コンソールでは「削除（復元可能）ポリシー」と表記）は、有効にすると、削除されたオブジェクトが削除後も一定の期間保持され、復元可能になる設定です。

バケット単位で設定でき、デフォルトでは7日間になっています。この期間のうちは、オブジェクトを誤って削除しても復旧可能です。最長90日間、最短は0日間（オフ）です。

当機能は、2024年3月に導入されました。その時点で存在しているバケットの Soft delete ポリシーは、デフォルトの７日間に設定されます。

なお、Soft delete ポリシーの期間中の削除済みオブジェクトは、削除前と同じ単価で引き続き課金されます。ただし、当機能が導入初期の2024-03-01から2024-05-31までの間はプロモーション期間として、7日分は料金が発生せず、2024-06-01から課金が開始されます。

参考 : Introducing Cloud Storage soft delete
参考 : Soft Delete

Soft delete されたオブジェクトを復旧するには、gcloud storage restore コマンドを使うか、Google Cloud コンソールを使ってリストア操作を行います。

参考 : Restore a soft-deleted object

ライフサイクルマネジメント

ライフサイクルマネジメント 機能は、オブジェクト作成後の経過日数などに従い自動的にストレージクラスを変更したり、削除したりできる機能です。

例えば「デフォルトストレージクラスは Standard Storage だが、 120 日経過したオブジェクトは自動的に Coldline Storage に移動する。360 日経過したオブジェクトは削除する」といった指定が可能です。

ルールを設定するだけで自動適用されるため、ハウスキーピングのためのプログラムを書く必要がありません。この機能を賢く使うことで、料金を節約することにも繋がります。

ルールを適用する条件として「オブジェクト作成後の経過日数 (Age)」「絶対日時以前に作成されたオブジェクト (CreatedBefore)」「バージョニングで過去版になってからの日数 (DaysSinceNoncurrentTime)」「特定の接頭辞/接尾辞を持つオブジェクト ( MatchesPrefix / MatchesSuffix )」など様々な条件が選べます。

ライフサイクルルールはバケット単位で作成します。ルールはバケット内の全てのオブジェクトに適用されますが MatchesPrefix / MatchesSuffix ルールと組み合わせることで「特定のフォルダ配下のみ」「特定の拡張子のオブジェクトのみ」に適用することなども可能です。

ライフサイクルの設定手順は以下のドキュメントをご参照ください。

オブジェクトライフサイクルを管理する

バージョニング

オブジェクトには バージョニング を設定可能です。バケットごとに有効化できます。

バージョニングが有効化されると、オブジェクトを上書きすると、過去のバージョンとして指定した世代数だけ保管されます。
削除も同様で、オブジェクトを削除しても「過去のバージョン」として裏では残っている動きになります。

過去版となったオブジェクトを真に削除するには、先に記述したオブジェクトライフサイクル機能を使って「過去版になってから 14 日経過後に完全削除」のように設定します。

過去のバージョンは 普通に存在するのと同様に課金される ので、注意が必要です。

バケットのリージョン (ロケーション)

バケット作成時に ロケーション を選択します。
データは物理的に、選択したロケーションに保管されます。

ロケーションは「 単一リージョン 」「 デュアルリージョン 」「 マルチリージョン 」のタイプがあり、それぞれのタイプでリージョンを選択可能です。

日本に近いところで例を挙げると、単一リージョンとしては「 asia-northeast1 (東京) 」や「 asia-northeast2 (大阪) 」が、デュアルリージョンとしては「 asia1 (東京・大阪)」が、マルチリージョンとしては「asia (アジア圏複数リージョン) 」が選べます。

たとえ単一リージョンを選んだ場合でも、リージョン内の複数のゾーンにデータは冗長化されるため、堅牢性は高いといえます。
しかしデュアル / マルチリージョンを選ぶことで、リージョンレベルの災害、事故、政変などでもデータを維持することができます。
以下のような基準で選ぶと良いでしょう。

コスト効率と低いレイテンシを求める場合は 単一リージョン
レイテンシを抑えつつ、単一リージョンより高い地理的冗長性が欲しい場合は デュアルリージョン
さらに高い地理的冗長性が欲しい場合や、近隣諸国からのアクセスも想定される場合は マルチリージョン

なおリージョン間のレプリケーションは書き込み完了から 非同期 で行われます。同期には数分からそれ以上の時間がかかることがあります。

RTO を短くする目的で ターボレプリケーション (turbo replication) を有効化すると、遅延を 15 分以内に抑えられますが追加料金が発生します。ターボレプリケーションはデュアルリージョンのバケットでのみ利用可能です。

セキュリティ

アクセス制御

IAM と ACL

Cloud Storage のセキュリティはアクセス制御の仕組みを理解することで担保します。

アクセス制御には「均一 (Uniform)」と「きめ細かい管理 (Fine-grained)」があり、可能な限り前者のみを利用することが推奨されています。
前者はバケットレベルで IAM を使って制御します。
後者はオブジェクトごとに ACL を使って制御します。

後者は Amazon S3 との相互運用性のために用意された機能ですが、細かいオブジェクトごとの権限管理は煩雑であり、運用が崩壊するおそれがあります。これが前者が推奨される理由です。

バケットは可能な限り、アクセス権限のユースケースごとに分け、バケットごとに権限管理をするのが望ましいといえます。

Google Cloud の IAM については以下の記事で詳細に解説していますので、ご参照ください。

blog.g-gen.co.jp

パブリック公開

Cloud Storage のオブジェクトは、パブリック公開設定にすることでインターネットのどこからでもアクセスできるように設定できます。

パブリック公開されたデータへアクセスする方法は以下のようなものがあります。

API Link: https://storage.googleapis.com/(BUCKET_NAME)/(OBJECT_NAME)
Google Cloud コンソール
Google Cloud CLI (gsutil / gcloud)

パブリック公開の禁止

当然のことながら、意図しないオブジェクトに誤ってパブリック公開設定をしないように最新の注意が必要です。

バケット単位でパブリック公開の禁止設定をすることができます。
これを有効化すると、オブジェクトの設定に関わらず、認証無しのアクセスは弾かれます。

意図しないデータ漏洩を防ぐため、以下のように設定するべきです。

インターネット公開しうるオブジェクトと、公開してはいけないオブジェクトは同じバケットに混在させない
インターネット公開の可能性がないバケットではパブリック公開の禁止設定を有効化する

暗号化

Cloud Storage に保管されるデータは自動的に暗号化されます。

これはストレージレベルの暗号化であり、我々利用者からは透過的に行われるため、意識することはありません。
透過的な暗号化ですので、 Google の内部犯行や物理的な盗難などに効果を発揮するものであり、 不正アクセスに対抗できるものではない ことに注意が必要です。

この暗号化は Google が管理する鍵で行われますが、各種規定や監査への対応のため必要であれば利用者側の提供する鍵で暗号化をすることもできます。

その場合 Cloud KMS を用いて鍵を管理する Customer-managed encryption key という方法のほか、 Cloud Storage API へのリクエストの度に鍵を指定する Customer-supplied encryption key の方法があります。

いずれも利用者側で 暗号化鍵を運用するという負荷 がありますので、本当に必要なときにのみ検討するべきです。

保持ポリシー（Bucket Lock）

各種規制やコンプライアンス要件への対応のため保持ポリシー（別名 Bucket Lock）を設定することができます。

「保持ポリシー」をバケットに設定すると、設定した期間中、オブジェクトを削除したり更新できなくなります。これによりログデータ等の改ざん・消去が不可能になります。このように「書き込み（新規追加）はできるが削除したり改ざんできない」「読み取りは可能」という状態を write once, read many (WORM) と呼び、監査ログ等の保持施策の原則です。

また「保持ポリシーのロック」を設定すると保持ポリシーを 永久に 解除できなくすることができます。ロックすると保持期間の 延長はできます が、逆に期間を短縮したり、ポリシーを削除できなくなります。

法的規制で保管が義務付けられているログデータ等の保管に役立つ一方、保持期間がすぎるまでオブジェクトの削除は一切できなくなりますので十分ご注意ください。

参考 : 保持ポリシーと保持ポリシーのロック

オブジェクト保持（Object Lock）

前述の保持ポリシーがバケット単位での設定であるのに対し、オブジェクト単位での設定であるオブジェクト保持（別名 Object Lock）を設定することも可能です。

「オブジェクト保持」をオブジェクトに対してに設定すると、設定した期間まで、オブジェクトを削除したり更新できなくなります。保持ポリシーより細かい粒度でログデータ等の改ざん・消去を防ぎ、法的規制への対応を可能にします。

さらに設定したオブジェクト保持期間に対する変更を防ぐためロック状態 (Locked) にすることも可能です。ロック状態にすると、保持期間を延長することはできますが、設定を削除したり短縮することは二度とできなくなります。

バケット単位の保持ポリシーとの併用が可能で、併用する場合は両方の期限が満了するまでオブジェクトが保持されます。

参考 : Object retention configurations

Autoclass

Autoclass とは

Autoclass 機能を有効化すると、過去のオブジェクトのアクセスパターンに応じて、ストレージクラスを自動で振り分けてくれます。AWS の Amazon S3 における「Intelligent-Tiering」と類似する機能といえます。

Autoclass はバケット単位で有効化します。Autoclass が有効化されたバケットでは以下の挙動になります。

書き込まれたオブジェクト (上書き含む) は Standard storage として書き込まれる
30 日間アクセスがないオブジェクトは Nearline storage に変更される
90 日間アクセスがないオブジェクトは Coldline storage に変更される
365 日間アクセスがないオブジェクトは Archive storage に変更される
一度でもアクセスがされたオブジェクトは Standard storage に変更される

つまり、アクセスが少ないファイルほど、より安いストレージに自動的に以降してくれます。Autoclass 有効化時はデフォルトだと Nearline への移行を行ってくれる設定になっており、Coldline/Archive への自動移行は明示的に有効化する必要があります。

バケット作成後の有効化

かつては制約として、バケット作成時にのみ Autoclass を有効化でき、バケット作成後の有効化はできませんでしたが、2023/11/03のアップデートで可能になりました。

ただし有効化時に料金が発生することにご注意ください。Autoclass 有効化時に Standard 以外のストレージに入っているオブジェクトには「早期削除料金」「最低保管料金」がかかるほか、全オブジェクトに対して Class A オペレーションの API コール料金が発生しますので、十分ご注意ください。

参考 : Cloud Storage pricing - Autoclass charges

制約

Autoclass 機能には、2023/03/06 から以下の制約が適用されています。

128 KB未満の小さいファイルにはストレージクラス変更がされず Standard のまま
ただし 128 KB未満の小さいファイルには管理費用 (後述) が適用されない

なお機能リリース時にはこの制約はありませんでした。この制約の適用前に配置され Nearline storage 等に移行された小サイズファイルは、2023/03/06 以降に自動的に Standard storage に移行されます (その際には取り出し費用やオペレーション費用は発生しません)。

ユースケース

あるバケットでアクセス頻度がオブジェクトによりまちまちで予測が付きづらい場合であり、かつサイズが 128KB 以上のファイルが多い場合には、Autoclass が適しておりコスト最適化に役立つはずです。

逆に、オブジェクトのアクセス頻度がある程度予測しやすかったり、平均的なファイルサイズが 128 KB 以下なのであれば、無効化のままのほうがコスト効率が良い可能性があります。

料金

Autoclass を有効化すると、管理費用として 1,000 オブジェクトごとに月あたり $0.0025 の費用が発生します。

ただし特筆すべき点として、Autoclass を有効化したバケットでは Nearline 以下のストレージでオブジェクトを削除しても最低保管期間 (Minimum storage duration) 料金が発生しませんし、データ取り出し費用も発生しません。

また Autoclass により自動的に行われる、より cold なストレージクラスの移動には、オペレーション料金が発生しません。逆に hot なストレージへの移動は、Nearline -> Standard では発生しませんが、Coldline -> Standard や Archive -> Standard では Class A オペレーションとしての課金が発生します (ただし単価は Standard のもの)。

参考 : Autoclass - Pricing
参考 : Cloud Storage pricing - Autoclass charges

2023/10/16 以前には、オペレーション課金周りで現在と違う課金体系でした。詳細は以下を参考にしてください。

参考 : Cloud Storage release notes - July 17, 2023

応用技

署名付き URL

署名付き URL (signed URL) 機能を使うことで、英数字の署名トークン付きの URL を知っている人がアクセスできる、時間制限付きの URL を発行することができます。

クエリ文字列内に認証情報が入っているため、 制限時間内であれば URL を知っている誰もが アクセスでき、認証は必要ありません。
何らかの理由で Google アカウントやサービスアカウントによる認証が使えない場面で、限定的なアクセス (オブジェクトのアップロードやダウンロード) を提供したいときに利用します。

署名付き URL は以下のようになります。

https://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6 (中略) c56c5ca81ff3447032ea7abedc098d2eb14a7

署名付き URL は gsutil コマンド や各プログラミング言語の Google authentication library などを用いて生成することができます (もちろん生成する側は Google アカウント等による認証が必要です) 。

組織のポリシー

組織のポリシー 機能を使うことで、同じ組織 (Organization) に所属している全てのプロジェクト (Project) で Cloud Storage の設定を強制することができます。

例えば、前述の パブリックアクセスを組織配下の全ての Cloud Storage バケットで禁止 してしまうことなどが可能です。

Cloud Storage に対して使える組織のポリシーは他にも複数あり、ドキュメントにまとまっています。

静的ウェブサイトホスティング

Cloud Storage に配置した HTML ファイル等をインターネット公開することで、ウェブサイトのホスティングをすることができます。

HTML ファイルを配置し、先に記述したパブリック公開にすることで https://storage.googleapis.com/(BUCKET_NAME)/(OBJECT_NAME) という URL が払い出されます。

また Cloud Load Balancing の 外部 HTTP(S) ロードバランサー と組み合わせることで、カスタムドメイン名 + TLS 証明書でサイトを公開することが可能です。

詳細な手順はドキュメントに記載されています。

イベントドリブン・アーキテクチャ

新しいオブジェクトが作成されたときや削除されたときなど対応イベントが発生した場合に Pub/Sub に通知したり Cloud Functions を起動することができます。

これにより、例えば以下のような処理が可能になります。

ユーザーがアプリを通じて画像を Cloud Storage にアップロード (= オブジェクト作成)
オブジェクト作成をトリガーに Pub/Sub にメッセージが入る
Cloud Run が Pub/Sub メッセージを読み取り、画像をサムネ化して別の Cloud Storage バケットに配置

このように、オブジェクトの作成など何らかのイベントをトリガに処理が走る構成を イベントドリブン・アーキテクチャ と呼びます。

サーバーレス・従量課金・疎結合がフル活用できるこのイベントドリブンという考え方は、クラウドのメリットを最大限活用できる方法の一つです。

オブジェクトの命名

Cloud Storage は分散アーキテクチャであり、バックエンドには複数のサーバーがあります。
またオブジェクト名などを管理するインデックスは辞書順に並び替えられており、やはり分散しています。
このインデックスの読み書き時の負荷分散には、オブジェクト名 (パス) が使われます。

オブジェクト名がもし以下のように連続的だと、負荷分散がされずに同一のインデックスレンジが更新され続けてしまい、負荷分散ができないため、 同時大量リクエストの際にパフォーマンスが低下 します。

/2022-03-18-19-24-00/access_log.txt
/2022-03-18-19-24-01/access_log.txt
/2022-03-18-19-24-02/access_log.txt

同時大量リクエストがありえる場合は、代わりに以下のように オブジェクト名の最初にランダムな文字列を付与 することでパフォーマンスを向上できます。
MD5 でもともとのオブジェクト名をハッシュ化して最初の6文字を取る方法などがドキュメントでは紹介されています。

/q84ic3-f2022-03-18-19-24-00/access_log.txt
/zbfg9t-2022-03-18-19-24-01/access_log.txt
/2w99uk-2022-03-18-19-24-02/access_log.txt

整合性

整合性 とはストレージやデータベースにおいて、書き込み処理が完了をした後に読み取りをした場合に、いつの時点のデータが読み取られるかを示す概念です。

分散アーキテクチャのストレージでは、書き込みオペレーションが完了した後でも、その書き込み内容が全ての分散ノードに複製されるまでの間、書き込みオペレーション実行前の古い情報が読み取られる可能性があり、一定の時間が経ってから整合性が取られる可能性があります。これは 結果整合性 と呼ばれます。

一方で、ある書き込みオペレーションが完了した後に読み取りオペレーションを実行した場合に、その書き込み内容が必ず読み取られる場合は 強整合性 といいます。

Cloud Storage は分散アーキテクチャのストレージですが、書き込みや削除の後の読み取りオペレーションは 強整合性 で実現されています。

ただし、アクセス制御設定の変更だけは結果整合性です。設定変更後、適用されるまで 1 〜数分程度の時間がかかる場合があります。

詳細は整合性のドキュメントにまとめられています。

BigQuery やデータ系サービスからの利用

Cloud Storage は BigQuery との連携の面でも優れています。

Cloud Storage オブジェクトとして配置した CSV, JSON, Avro, ORC, Parque 等のファイルを、 BigQuery のテーブルにロード (読み込み) することができます。
例として以下のような方法があります。

BigQuery の既存テーブルに Cloud Storage オブジェクトをロード
BigQuery のテーブル作成時に元ファイルとして Cloud Storage オブジェクトを指定
BigQuery Data Transfer Service で自動ジョブを作成

また BigQuery から 外部テーブル定義 を行うことで、直接 Cloud Storage オブジェクトに対してクエリをかけることも可能です。

データレイクとしての Cloud Storage

東京リージョンの BigQuery のストレージ料金は Active ストレージが $0.023/GB 、Long-term ストレージが $0.016 です。
これは東京リージョンの Cloud Storage のストレージ価格が Standard が $0.023 、 Nearline が $0.016 であるのと一致しています。

このことから Google Cloud では データレイク用のストレージ として (半) 構造化データは BigQuery に保管 、非構造化データは Cloud Storage に保管 、という使い分けをすることが多いです。

(非構造化データとは、画像、動画、音声のように構造化されていないデータを指します。)

これは AWS において「データレイクは Amazon S3 、データウェアハウスに Amazon Redshift 」という使い方をするのとは少し異なっています。

始めから構造化データをデータウェアハウスである BigQuery に入れておくことで、データの移送などの考慮が不要になります。

VM へのマウント

Cloud Storage バケットは原則的に VM 等へはマウントできない、と前述しましたが、方法が無いわけではありません。

Cloud Storage FUSE を使うと Linux または macOS へバケットをマウントすることができます。

しかしこの方法は、本来 API で読み書きをするべきオブジェクトストレージに、ファイルシステムライクにアクセスできるようにドライバーを噛ましているような状態です。
「大量の静的ファイル」「レイテンシが大きくても良い」「クリティカルなワークロードでない」など限定的な条件の場合のみ、利用を検討するべきだといえます。