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

概要
料金
用語
ロケーション（リージョン）
ライフサイクルマネジメント
Autoclass
オブジェクトの保護
静的ウェブサイトホスティング
セキュリティ
パフォーマンスと整合性
- オブジェクトの命名
- 整合性
データレイク
- データレイクとしての Cloud Storage
- BigQuery や他サービス連携
データの転送
- Storage Transfer Service
- クロスバケットレプリケーション
他サービスとの連携
- イベントドリブン・アーキテクチャ
- VM や Cloud Run からのマウント

概要

Cloud Storage とは

Cloud Storage は、Google Cloud（旧称 GCP）の容量無制限・低価格・堅牢なオブジェクトストレージサービスです。Google Cloud Storage を略して GCS とも呼称される場合があります。

データは少なくとも 2 つ以上のゾーン（ゾーンは1つ以上のデータセンターで構成）にわたって冗長化されており、99.999999999%（イレブンナイン） の堅牢性を保つよう設計されています。

Cloud Storage では、ストレージクラスと呼ばれる価格帯の違う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 よりも処理が高速とされています。

参考 : Introducing gcloud storage: up to 94% faster data transfers for Cloud Storage

一方の gsutil は、gcloud コマンドが Cloud Storage に対応する以前からあったコマンドラインツールです。過去には Cloud Storage を操作するための唯一の CLI ツールでした。今後は、gsutil で利用できるすべての機能が gcloud コマンドに移行され、gcloud が推奨となります。

gcloud コマンドラインの利用方法は、以下の記事も参照してください。

blog.g-gen.co.jp

ユースケース

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

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

なお Cloud Storage は、限定的な用途であれば、サーバー等からマウントして擬似的なファイルシステムとして読み書きすることが可能です。「VM や Cloud Run からのマウント」の項を参照してください。

料金

Cloud Storage の料金の概要

Cloud Storage の特徴は、安価であることです。東京リージョンの Standard Storage のデータ保管料金は2024年9月現在で、$0.023（GB/月）です。概ね、1TB で3,500円程度と認識すれば良いでしょう。

最新の料金は、公式の料金ページを参照したり、公式の Google Cloud 料金試算ツールをご利用ください。

参考 : Cloud Storage の料金
参考 : Google Cloud's pricing calculator

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

また Cloud Storage の料金にはストレージクラスという重要な考慮事項があり、選択するクラスによって料金単価が異なります。

料金体系

Cloud Storage では、保管するデータのサイズに加えて、複数の軸で従量課金が発生します。

保管するデータのサイズ（GB/月）
書き込みオペレーション回数
読み取りオペレーション回数
ネットワーク利用 (ダウンロード方向のみ、 GB)
取り出し料金 (GB)

これらの料金単価は、後述のストレージクラスごとに異なります。

ストレージクラス

Cloud Storage には、Standard / Nearline / Coldline / Archive という4つのストレージクラスが存在します。右に行くほど長期保存、かつ取り出し頻度が少ないデータに適しています。

参考 : ストレージクラス

右のストレージクラスほど GB あたりのデータ保管料金が安くなりますが、オペレーション回数あたりの料金や取り出し GB あたりの料金が高くなります。料金単価は以下のとおりです（2024年9月現在、東京リージョン）。

ストレージクラス	保管料金 (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）が各ストレージクラスごとに定められており、保管したオブジェクトがこの日数以内に削除・置換・移動された場合、この日数分の保管料金が発生してしまいます（削除できない訳ではありません）。

ストレージクラスはバケット作成時にデフォルトストレージクラスとして指定できます。バケットにオブジェクトが作成されるとデフォルトストレージクラスに従ってストレージクラスが設定されますが、オブジェクトごとに個別にクラスを指定することもできますし、後から変更も可能です。また、後述の Autoclass 機能により、利用状況にあわせて自動でクラスが移行されていくように設定することもできます。

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

用語

バケット

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

バケットには全世界で一意の名前が付けられます。

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

参考 : バケット

オブジェクト

オブジェクトとは、バケットに入れられた個々のファイルを指します。

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

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

参考 : オブジェクト

メタデータ

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

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

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

参考 : オブジェクトのメタデータ

パス

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

gs://my-bucket/my-folder/myobject のように表されます。

先頭の gs:// は Cloud Storage のオブジェクトのパスであることを示す接頭辞です。

参考 : オブジェクトの名前空間

フォルダ

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

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

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

参考 : オブジェクトの名前空間

なお、後述のマネージドフォルダ機能を使うと、通常のフォルダとは異なり、より細かい権限管理を行うことができます。マネージドフォルダに対して、通常のフォルダのことをシミュレートされたフォルダ（Simulated folders）と呼びます。

ロケーション（リージョン）

概要

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

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

例として単一リージョンには「asia-northeast1（東京）」や「asia-northeast2（大阪）」が、デュアルリージョンには「asia1（東京・大阪）」が、マルチリージョンには「asia（アジア圏複数リージョン）」が存在します。

参考 : バケットのロケーション

選択基準

たとえ単一リージョンを選んだ場合でも、リージョン内の複数のゾーンにデータは冗長化されており、99.999999999%（イレブンナイン）の年間耐久性を実現します。しかしデュアルリージョンまたはマルチリージョンを選ぶことで、リージョンレベルの障害、災害、事故、政変などのリスクにも対応し、可用性と冗長性を向上させることができます。ロケーションは、以下のような基準で選ぶと良いでしょう。

コスト効率と低いレイテンシを求める場合は単一リージョン
レイテンシを抑えつつ、単一リージョンより高い地理的冗長性と可用性）が必要な場合はデュアルリージョン
複数地域からのアクセスが想定されるか、複数リージョンでの冗長性を確保したい場合はマルチリージョン

デュアルリージョンは、マルチリージョンよりもストレージ料金が高いですが、より広い帯域幅（リージョンごと 200 Gbps）を確保できることに加え、同一リージョンからのダウンロードにはアウトバウンド料金が発生しません。マルチリージョンはその反対に、保管料金が安い代わりに帯域幅がより狭く（リージョンごと 50 Gbps）、データ読み取りには必ずアウトバウンド料金が発生します。このようなトレードオフを理解して選択します。詳細は以下のドキュメントを参照してください。

参考 : ロケーションに関する留意事項

ターボレプリケーション

デュアルリージョンやマルチリージョンバケットにおいて、リージョン間のレプリケーションは、オブジェクトの書き込みが完了してから非同期で行われます。同期には数分からそれ以上の時間がかかることがあります。デフォルトの非同期レプリケーションでは、1時間以内に99.9%のオブジェクトが複製され、12時間以内に100%に達します。これでは RPO（Recovery Point Objective）要件を満たせない場合、ターボレプリケーション（Turbo replication）を有効化することで、15分以内に100%のデータを複製できます。

ターボレプリケーションには追加料金が発生します。また、ターボレプリケーションはデュアルリージョンのバケットでのみ利用可能です。

参考 : データの可用性と耐久性
参考 : ターボレプリケーション

リージョンエンドポイント

リージョンエンドポイント（Regional endpoints）は、特定のリージョンにおける Cloud Storage バケット専用のエンドポイント URL です。リージョンエンドポイントを使うと、データが転送中と保管中の両方で、特定の地域内に留まることを保証でき、データレジデンシー（data residency）やデータ主権（data sovereignty）を担保することができます。

リージョンエンドポイントは https://storage.europe-west3.rep.googleapis.com のような形式です。この URL の場合、データが europe-west3 リージョン（ドイツのフランクフルトリージョン）を出ないことが保証されます。

このエンドポイントを使うと、読み書き等のオペレーション対象となるバケットが、対象リージョン外にある場合、オペレーションはエラーとなります。

利用するには、gcloud コマンドの場合は環境変数にエンドポイントを設定します。REST API の場合は、リクエスト先のエンドポイント URL をリージョナルエンドポイントにします。

参考 : Regional endpoints

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

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

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

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

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

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

参考 : オブジェクトのライフサイクル管理

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 の料金

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

オブジェクトの保護

Soft delete ポリシー

Soft delete ポリシーとは、削除された Cloud Storage オブジェクトが、削除後も一定の期間保持され、期間内であれば復元可能となる設定です。日本語コンソールや日本語ドキュメントでは「削除（復元可能）ポリシー」と表記されます。

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

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

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

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

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

参考 : Restore a soft-deleted object

バージョニング

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

バージョニングが有効化されている場合、オブジェクトを上書きすると、過去のバージョンとして指定した世代数だけ保管されます。削除も同様で、オブジェクトを削除しても、過去のバージョンとしてデータが残ります。最新のバージョンのオブジェクトは「現行のバージョン」、過去のバージョンは「非現行のバージョン」と呼ばれます。

非現行のバージョンは現行のバージョンと同様に課金されるので、注意が必要です。

参考 : オブジェクトのバージョニング

非現行のバージョンとなったオブジェクトを削除するには、先に記述したオブジェクトライフサイクル機能を使って「非現行バージョンになってから 14 日経過後に完全削除」のように設定します。そのようにバージョニングとライフサイクルを組み合わせて利用する方法については、以下の記事も参照してください。

blog.g-gen.co.jp

保持ポリシー（Bucket Lock）

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

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

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

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

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

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

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

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

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

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

参考 : Object retention configurations

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

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

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

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

詳細な手順は、以下の公式ドキュメントを参照してください。

参考 : 静的ウェブサイトをホストする

セキュリティ

アクセス制御（IAM と ACL）

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

参考 : アクセス制御の概要

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

きめ細かい管理（Fine-grained）は Amazon S3 との相互運用性のために用意された機能ですが、細かいオブジェクトごとの権限管理は煩雑であり、運用工数が高くなるおそれがあります。これが、前者の均一（Uniform）管理が推奨される理由です。

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

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 では、バケット単位でパブリック公開の禁止（public access prevention）を設定することができます。設定すると、オブジェクト個別の設定に関わらず、Google アカウントで認証されていないアクセスは拒否されます。

参考 : 公開アクセスを防止する

意図しないデータ漏洩を防ぐために、バケットの設定は以下のようにすることが望ましいといえます。

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

IP アドレス制限（VPC Service Controls と Bucket IP filtering）

基本的に、Cloud Storage をはじめとするパブリッククラウドサービスは、API エンドポイントがインターネットに公開されている状態であり、従来型の IP アドレス制御等（境界型セキュリティ）ではなく、IAM などの認証・認可の仕組みでセキュリティを担保するのが原則です。

しかしながら、Cloud Storage では以下の2つの方法のいずれかで、接続元 IP アドレス制限を実現できます。

VPC Service Controls
Bucket IP filtering

前者の VPC Service Controls は、Google Cloud API 全般に対して、接続元 IP アドレス、接続元 VPC やデバイスポリシーなどに基づいたアクセス制御を設定するための Google Cloud サービスです。詳細は以下の記事をご参照ください。

blog.g-gen.co.jp

後者の Bucket IP filtering は、Cloud Storage に備え付けの接続元 IP 制限の仕組みです。VPC Service Controls と同様に接続元 IP アドレスや接続元 VPC を制限できます。相違点は、バケット単位での設定が可能な点、またデバイスポリシーに基づいた制御機能は存在していない点です。当機能は2024年11月現在、Preview 状態であり、また東京・大阪リージョンには未対応です。

参考 : Bucket IP filtering

前述のとおり、パブリッククラウドサービスのセキュリティの原則は、境界型セキュリティの考え方にとらわれずに、適切な認証・認可を実装することにあります。接続元 IP アドレス制限を設定すると、運用の煩雑化やアクセス権限管理の軽視につながるおそれもあることから、本当に接続元 IP アドレス制限が必要かどうか慎重に検討することが推奨されます。

マネージドフォルダ

Cloud Storage バケットの内部にはフォルダを作成することができます。通常の手順でフォルダを作成すると、そのフォルダはシミュレートされたフォルダ（Simulated folders）という種類になります。シミュレートされたフォルダは、マネージドフォルダにアップデートすることが可能です。

マネージドフォルダでは、フォルダ単位での IAM 権限管理ができ、よりきめ細かい権限管理が可能です。より詳細な内容は、以下の記事をご参照ください。

blog.g-gen.co.jp

暗号化

Cloud Storage に保管されるデータは、デフォルトで、自動的に暗号化されます。

参考 : データ暗号化オプション

デフォルトの自動的な暗号化はストレージレベルの暗号化であり、利用者からは透過的に行われるため、意識されることはありません。

透過的な暗号化ですので、Google の内部犯行や物理的な盗難などに効果を発揮するものであり、不正アクセスに対抗できるものではないことに注意が必要です。

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

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

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

署名付き 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 アカウント等による認証が必要です。

参考 : 署名付き URL

組織のポリシー

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

例えば、パブリックアクセスを組織配下の全ての Cloud Storage バケットで禁止する、などの統制が可能です。

Cloud Storage に対して使える組織のポリシーは他にも複数あり、以下の公式ドキュメントにリストされています。

参考 : Cloud Storage の組織のポリシーに関する制約

組織のポリシー自体については、以下の記事も参照してください。

blog.g-gen.co.jp

パフォーマンスと整合性

オブジェクトの命名

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〜数分程度の時間がかかる場合があります。

参考 : 一貫性

データレイク

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

東京リージョンの BigQuery のストレージ料金は、Active ストレージが $0.023/GB 、Long-term ストレージが $0.016 です（2024年9月現在）。

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

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

これは AWS において「データレイクは Amazon S3 、データウェアハウスに Amazon Redshift」という使い方をするのとは少し異なっています。始めから構造化データをデータウェアハウスである BigQuery に入れておくことで、データの移送などの考慮が不要になります。

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 オブジェクトに対してクエリをかけることも可能です。

データの転送

Storage Transfer Service

Cloud Storage の関連サービスとして、Storage Transfer Service があります。Storage Transfer Service を使うと、Amazon S3 やファイルシステムなど様々なデータソースから、ファイルを Cloud Storage に対して転送できます。

ジョブを設定することで、ファイル数やデータ量が大量の場合に、効率的なデータ転送を行うことができます。

参考 : Storage Transfer Service とは

また Amazon S3 からの転送の際にオプションで Managed private network を有効化すると、AWS からのネットワーク転送料金がかからず、代わりに Google Cloud 側の料金が発生します。これにより、安価な転送料金で Amazon S3 から Cloud Storage へのデータ転送を実現できます。

参考 : Transfer from Amazon S3 to Cloud Storage

クロスバケットレプリケーション

クロスバケットレプリケーション（cross-bucket replication）機能を使うと、あるバケットに作成された新しいオブジェクトや更新されたオブジェクトを、非同期に別のバケットに複製できます。

この機能のバックエンドでは、Storage Transfer Service が使われています。

参考 : Use cross-bucket replication

他サービスとの連携

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

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

参考 : Cloud Storage の Pub/Sub 通知

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

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

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

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

VM や Cloud Run からのマウント

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

Cloud Storage は、本来は Web API で読み書きをする仕組みです。Cloud Storage FUSE は、OS からファイルシステムライクにバケットにアクセスできるよう、システムコールを Cloud Storage への API リクエストへ書き換えてリクエストします。よって Cloud Storage FUSE が適しているのは、レイテンシが比較的大きくても構わず、かつアクセス頻度が多すぎない、限定的な条件の場合のみであり、利用に当たっては十分な検証が必要です。