Cloud Storage

解決する課題

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

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

主要概念と用語

• バケット: オブジェクトを入れる入れ物。名前はグローバルで一意。作成時にロケーション（地域）と既定のストレージクラスを決める
• オブジェクト: 保存する実体（データ＋メタデータ）。最大 5TiB
• オブジェクト名（キー）: バケット内でオブジェクトを一意に指す「パス文字列」。gs://バケット名/パス で参照
• ロケーションタイプ: リージョン（単一地域）／デュアルリージョン（2 地域）／マルチリージョン（大陸単位の複数地域）の 3 種
• ストレージクラス: アクセス頻度に応じたコスト/最低保存期間の区分（Standard / Nearline / Coldline / Archive）
• オブジェクトのバージョニング: 上書き/削除しても過去版（noncurrent version）を保持
• 均一なバケットレベルのアクセス（Uniform bucket-level access）: オブジェクト単位 ACL を無効化し、IAM に一本化するモード

仕様・制限・クォータ

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

内部の仕組み

Cloud Storage はオブジェクト名（文字列）から実体を引く分散オブジェクトストアです。データは選んだロケーションタイプに応じて自動冗長化され、これがイレブンナインの耐久性の源です。「フォルダ」は見かけ上の表現で、実体は images/2026/cat.png のようなフラットな名前空間。スラッシュは区切り文字として扱われ、プレフィックス指定で擬似的に階層を一覧できます。

• リージョンバケットは単一地域内の複数ゾーンに冗長化（低レイテンシ・データ所在を限定）
• デュアル/マルチリージョンバケットは地理的に離れた複数地域へ複製し、地域災害に耐える高可用性を提供

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

• 静的サイト/メディア配信: Cloud Storage をオリジンにし、Cloud CDN + 外部 HTTP(S) ロードバランサで配信（AWS の S3 + CloudFront 構成に相当）
• データレイク: 生データを 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