Cloud Storage

解決する課題

サーバーのディスク容量や複製の仕組みを自前で用意せずに、データを安全に置ける場所が手に入ります。

• サーバーのディスクを事前確保せず、必要な量のファイルをオブジェクトとして保存
• 複数のゾーン／リージョンへ自動複製され、データがほぼ消えない
• HTTP(S) で直接アクセスでき、静的サイトやメディア配信にそのまま使える
• BigQuery・Dataflow・Vertex AI などの分析/ML サービスの入口（データレイク）になる

主要概念と用語

• バケット: オブジェクトを入れる入れ物。名前はグローバルで一意。作成時にロケーション（地域）と既定のストレージクラスを決める
• オブジェクト: 保存する実体（データ＋メタデータ）。最大 5TiB
• オブジェクト名（キー）: バケット内でオブジェクトを一意に指す「パス文字列」。gs://バケット名/パス で参照
• ロケーションタイプ: 通常のバケットはリージョン（単一地域）／デュアルリージョン（2 地域）／マルチリージョン（広域）の 3 種。低レイテンシ・高スループット用途には、ゾーン配置の Rapid Bucket もある
• ストレージクラス: アクセス頻度に応じたコスト/最低保存期間の区分（Standard / Nearline / Coldline / Archive）
• オブジェクトのバージョニング: 上書き/削除しても過去版（noncurrent version）を保持
• ソフトデリート: 削除・上書きされたオブジェクトを一定期間だけ復元可能な状態で保持。新規バケットは既定で 7 日
• 階層名前空間: 必要な場合に、フォルダを実体として扱う階層構造を有効化する機能。既定のフラット名前空間とは動作が異なる
• 均一なバケットレベルのアクセス（Uniform bucket-level access）: オブジェクト単位 ACL を無効化し、IAM に一本化するモード

仕様・制限・クォータ

• 1 オブジェクト最大 5TiB。単一リクエストのアップロード上限も 5TiB（大きいものは再開可能アップロードを利用）
• 強整合性（strong consistency）: 書き込み後の読み取り・上書き・削除・バケット内一覧が即時に反映される
• バケットは既定で非公開。allUsers / allAuthenticatedUsers を付与しない限り公開されない
• バケット名はグローバル一意。プロジェクトあたりのバケット数や、操作の QPS にも各種上限がある
• バケット名は変更不可。ロケーションは通常、新バケットへのコピーで移行する。Storage Intelligence を構成した環境では Bucket Relocation も利用できる

内部の仕組み

Cloud Storage はオブジェクト名から実体を引く分散オブジェクトストアです。データは選んだロケーションタイプに応じて冗長化され、これが高い耐久性の源です。既定は images/2026/cat.png のようなフラットな名前空間で、スラッシュを含むプレフィックスから擬似的な階層を表示します。ファイルシステムに近いフォルダ操作が必要なら、作成時に階層名前空間を有効化します。

• リージョンバケットは単一地域内の複数ゾーンに冗長化（低レイテンシ・データ所在を限定）
• デュアル/マルチリージョンバケットは地理的に離れた複数地域へ複製し、地域災害に耐える高可用性を提供
• Rapid Bucket はゾーンへ配置して計算資源と近接させる代わりに、ゾーン障害へ備えた別経路の複製や再生成を設計する

横にスクロール

設計パターン / ベストプラクティス

• 静的サイト/メディア配信: 公開コンテンツ専用バケットを Cloud Storage のオリジンにし、Cloud CDN + 外部 Application Load Balancerで配信。アクセス制限が必要なら Cloud CDN の署名付き URL/Cookie か、認証するアプリケーション経由に分ける
• データレイク: 生データを Cloud Storage に集約し、BigQuery（外部テーブル/ロード）・Dataflow・Dataproc で分析
• イベント駆動: オブジェクト作成をEventarc / Pub/Sub 通知でトリガーし、Cloud Run / Cloud Functions を起動（サムネ生成など）
• オブジェクトライフサイクル管理: 一定日数後に Standard → Nearline → Coldline → Archive へ自動でクラス変更/削除してコスト削減
• 大容量転送: オンプレや他クラウドからは Storage Transfer Service、ペタバイト級物理搬送は Transfer Appliance を利用

運用・監視

• Cloud Audit Logs（データアクセス監査ログ） と 使用状況/ストレージログでアクセスを監査
• Cloud Monitoring でバケットの容量・オブジェクト数・リクエスト数・エラー率を可視化
• Storage Insights（インベントリレポート / データセット） でバケット内オブジェクトの棚卸しとコスト分析
• 「403 / AccessDenied」は IAM ロール・バケットポリシー（IAM 条件）・公開設定・均一アクセスの ON/OFF の設定ミスが大半

コスト

「保存量」だけでなく「オペレーション（API 呼び出し）」「データ取得（retrieval）」「ネットワーク下り（egress）」にも課金されます。アクセス頻度と最低保存期間で使い分けます。

セキュリティ

• バケットは既定で非公開。均一なバケットレベルのアクセスを有効化し、ACL ではなく IAM に権限を一本化するのが推奨
• アクセス制御は Cloud IAM（プロジェクト/バケット/オブジェクト粒度のロール）。基本は最小権限
• 保存時暗号化は既定で有効（Google 管理鍵）。要件に応じて CMEK（Cloud KMS 管理鍵） や CSEK（顧客指定鍵） に切替。転送時は TLS
• 一時的な共有は署名付き URL（signed URL）、保持義務には バケットロック（リテンションポリシー） や オブジェクトホールド

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

Google Cloud CLI の gcloud storage（旧 gsutil の後継）コマンドで操作します。

# バケットを作成（東京リージョン・既定で非公開、均一アクセスを有効化）
gcloud storage buckets create gs://my-unique-bucket-2026 \
  --location=asia-northeast1 \
  --default-storage-class=STANDARD \
  --uniform-bucket-level-access

# ファイルをアップロード／ディレクトリを同期
gcloud storage cp ./index.html gs://my-unique-bucket-2026/
gcloud storage rsync ./out gs://my-unique-bucket-2026/ --recursive --delete-unmatched-destination-objects

# バケットの設定（暗号化・ロケーション・アクセス制御）を確認
gcloud storage buckets describe gs://my-unique-bucket-2026

# ライフサイクル: 30日経過で Nearline、365日経過で削除（JSON を適用）
gcloud storage buckets update gs://my-unique-bucket-2026 \
  --lifecycle-file=lifecycle.json