Cloud Storage — オブジェクトストレージ設計

バケット・オブジェクト・ロケーション

Cloud Storage は、任意の形式のファイルをオブジェクトとして、バケットという入れ物に保存するマネージドなオブジェクトストレージです。第 4 章の永続ディスク（ブロックストレージ）と違い、ファイルシステムとしてマウントして使うのではなく、HTTP(S) API で読み書きします。1 バケットに保存できるオブジェクト数は実質無制限で、すべてのストレージクラスが年間 99.999999999%（イレブンナイン）の耐久性を目標に設計されています（2026-08 時点の公式ドキュメント記載値）。

• バケット名はグローバルに一意です。全世界の全プロジェクトで重複できないため、本書のハンズオンでは PROJECT_ID を接頭辞にして衝突を避けます
• オブジェクトは不変（immutable）です。「編集」はできず、同名でアップロードすると丸ごと置き換わります。この性質が後述のバージョニングやバケットロックの土台になります
• バケットはプロジェクトに属します。課金・IAM・組織ポリシーは第 2 章のリソース階層に沿って継承されます

ロケーションタイプ — どこに、何重に置くか

バケット作成時に決めるロケーションは、可用性・レイテンシ・料金のすべてに効く、この章で最初の設計判断です。作成後に変更するには専用のバケット再配置（bucket relocation）手続きが必要で気軽には変えられないため、最初に正しく選びます。

ストレージクラスと Autoclass

4 つのストレージクラス

ストレージクラスは「保存料金」と「アクセス時のコスト・拘束」のトレードオフです。重要なのは、どのクラスも耐久性は同じイレブンナインで、Archive でもミリ秒で取り出せること。テープのような「取り出しに数時間待つ」制約はなく、違いは純粋に料金構造です。コールドなクラスほど保存単価が下がる代わりに、最小保存期間（早く消すと早期削除料金）と取り出し料金（読むたびに GiB 単価）が課されます。

保存単価の目安として、東京リージョンの Standard は $0.023 / GiB・月、Nearline は $0.016 / GiB・月です（2026-08 時点）。このほか 2026-08 時点では、AI / ML などの I/O 集約ワークロード向けにゾーンバケット専用の Rapid Storage クラスも提供されていますが、本章では上記 4 クラスと Autoclass に集中します。

Autoclass — アクセスパターンに追随する自動クラス管理

「このデータが将来どれくらい読まれるか」を事前に断言できないなら、Autoclass をバケットで有効化する手があります。オブジェクトごとのアクセス実績に基づいて、クラスを自動で上下させる機能です。

Autoclass の要点は 3 つです。第一に、取り出し料金と早期削除料金が課されないため、「Nearline に置いたら想定外に読まれて高くついた」という事故が構造的に起きません。代わりに管理手数料（と有効化時の一時課金）がかかります。第二に、ライフサイクル管理の SetStorageClass / matchesStorageClass ルールとは併用できません。アクセスパターンが読めるならライフサイクル、読めないなら Autoclass、と使い分けます。第三に、既存バケットにも有効化できます（全オブジェクトがいったん Standard 扱いになります）。

データ保護 — バージョニング・ライフサイクル・バケットロック

オブジェクトバージョニング

バージョニングを有効にすると、オブジェクトの置き換えや削除のたびに、直前の状態が非現行（noncurrent）バージョンとして保持されます。各バージョンは世代番号（generation number）で一意に識別され、オブジェクト名#世代番号 の形で取得・復元・完全削除できます。誤削除・誤上書きへの第一の防御線です。

注意すべきはコストで、非現行バージョンにもライブ時と同じ保存料金がかかり続けます。バージョン数に上限はないため、後述のライフサイクルルール（numNewerVersions や daysSinceNoncurrentTime）で古い世代を自動削除する構成が公式の推奨です。なお、バージョニングとは別にソフト削除という保護層もあり、削除されたオブジェクトは既定で 7 日間復元可能です（2026-08 時点）。

ライフサイクル管理 — クラス移行と削除の自動化

ライフサイクル管理は、バケットに JSON で宣言したルールに従って、オブジェクトへ自動でアクションを適用する仕組みです。

• アクション: Delete（削除）、SetStorageClass（クラス移行）、AbortIncompleteMultipartUpload（未完了マルチパートアップロードの破棄）の 3 種
• 条件: age（経過日数）、createdBefore、matchesStorageClass、matchesPrefix / matchesSuffix、バージョニング連動の isLive / numNewerVersions / daysSinceNoncurrentTime など
• 評価規則: 1 つのルール内の条件は AND、同じアクションを持つ複数ルールは OR で評価。Delete と SetStorageClass が競合したら Delete が優先されます

設計上おいしいのは、ライフサイクルの SetStorageClass はオブジェクトを書き直さないため、クラス移行に取り出し料金も早期削除料金もリージョン間複製料金もかからないことです。「Standard で 30 日 → Nearline → 1 年後に削除」のような設計を、追加コストなしの自動処理にできます。

保持ポリシーとバケットロック（WORM）

保持ポリシー（--retention-period）をバケットに設定すると、各オブジェクトは指定期間（最長 100 年）が経過するまで削除も置き換えもできなくなり、違反操作は 403 retentionPolicyNotMet で拒否されます。さらにポリシーをロック（--lock-retention-period）すると、ポリシーの削除も期間短縮も永久に不可能になります（延長のみ可）。これが Write-Once-Read-Many（WORM）ストレージで、FINRA・SEC・CFTC のような金融規制や医療系の保存義務に対応する手段として公式に位置づけられています。ロック済みバケットは全オブジェクトが保持期間を満了するまで削除できず、プロジェクト自体にもリーエン（削除保護）がかかります。規制対応の全体像は第 14 章で扱います。

アクセス制御とデータ転送

均一なバケットレベルアクセス

Cloud Storage には歴史的に IAM と ACL（オブジェクト単位のアクセス制御リスト）の 2 系統の権限機構がありますが、現在の推奨は均一なバケットレベルアクセス（uniform bucket-level access）を有効化して ACL を無効にし、IAM に一本化することです。権限の見通しが良くなり、ACL の設定ミスによる意図しない公開を構造的に防げます。有効化して 90 日間が経過すると無効化できなくなる点だけ覚えておいてください。本書のハンズオンでは全バケットで有効化します。

署名付き URL — 時限つきの限定公開

「Google アカウントを持たない相手に、このファイルだけ 10 分間ダウンロードさせたい」。IAM はプリンシパル（アカウント）が前提なので、この要件には署名付き URL を使います。サービスアカウントの権限で URL に署名し、URL を知っていれば誰でも、有効期限内に限り、署名された操作（GET / PUT など）だけを実行できます。有効期限は最長 604,800 秒 = 7 日間です（V4 署名。鍵ファイルを使わず署名する場合は最長 12 時間）。典型用途はエンドユーザーからの直接アップロード / ダウンロードで、アプリサーバーがファイル本体を中継しなくて済みます。

データ転送の 3 つの選択肢

既存データを Cloud Storage へ運ぶ手段は、データ量と回線帯域で選びます。公式ドキュメントの目安は「オンプレミスから 1 TB 未満なら gcloud storage、1 TB 以上なら Storage Transfer Service か Transfer Appliance」です。

• gcloud storage（旧称 gsutil の後継 CLI）: 手元やオンプレのファイルを直接コピー。小規模・単発ならこれで十分
• Storage Transfer Service: Amazon S3・Azure Blob Storage・HDFS・URL リスト・オンプレのファイルシステム・別の Cloud Storage バケットを送信元にできるマネージド転送サービス。1 TB 超の転送に最適化されており、スケジュール実行や差分同期もできる。オンプレ / HDFS からの転送は転送元にエージェントを立てる方式
• Transfer Appliance: Google から借りた物理アプライアンスにデータをコピーして返送する。回線が細い・そもそも接続がない拠点向け

gcloud config get-value project   # ここで表示された値が PROJECT_ID

gcloud storage buckets create gs://PROJECT_ID-ch08-basic \
    --location=asia-northeast1 \
    --default-storage-class=STANDARD \
    --uniform-bucket-level-access

echo "Hello, Cloud Storage!" > hello.txt
gcloud storage cp hello.txt gs://PROJECT_ID-ch08-basic/
gcloud storage ls --long gs://PROJECT_ID-ch08-basic/
gcloud storage cp gs://PROJECT_ID-ch08-basic/hello.txt ./hello-dl.txt
cat hello-dl.txt

gcloud storage rm --recursive gs://PROJECT_ID-ch08-basic
rm hello.txt hello-dl.txt

gcloud storage buckets create gs://PROJECT_ID-ch08-lifecycle \
    --location=asia-northeast1 \
    --uniform-bucket-level-access
gcloud storage buckets update gs://PROJECT_ID-ch08-lifecycle --versioning

cat > lifecycle.json << 'EOF'
{
  "rule": [
    {
      "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
      "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"isLive": false, "numNewerVersions": 3}
    }
  ]
}
EOF

gcloud storage buckets update gs://PROJECT_ID-ch08-lifecycle \
    --lifecycle-file=lifecycle.json
gcloud storage buckets describe gs://PROJECT_ID-ch08-lifecycle \
    --format="default(lifecycle_config)"

echo "v1" > note.txt
gcloud storage cp note.txt gs://PROJECT_ID-ch08-lifecycle/
echo "v2" > note.txt
gcloud storage cp note.txt gs://PROJECT_ID-ch08-lifecycle/
gcloud storage ls --all-versions gs://PROJECT_ID-ch08-lifecycle/

gcloud storage rm --recursive gs://PROJECT_ID-ch08-lifecycle
rm lifecycle.json note.txt

# バケットとオブジェクト
gcloud storage buckets create gs://PROJECT_ID-ch08-signed \
    --location=asia-northeast1 --uniform-bucket-level-access
echo "limited-time report" > report.txt
gcloud storage cp report.txt gs://PROJECT_ID-ch08-signed/

# 署名用サービスアカウント（オブジェクト閲覧権限のみ）
gcloud iam service-accounts create ch08-signer
gcloud storage buckets add-iam-policy-binding gs://PROJECT_ID-ch08-signed \
    --member=serviceAccount:ch08-signer@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/storage.objectViewer

# 自分に SA の借用（impersonation）を許可
gcloud iam service-accounts add-iam-policy-binding \
    ch08-signer@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:YOUR_EMAIL \
    --role=roles/iam.serviceAccountTokenCreator

gcloud storage sign-url gs://PROJECT_ID-ch08-signed/report.txt \
    --duration=10m \
    --impersonate-service-account=ch08-signer@PROJECT_ID.iam.gserviceaccount.com

curl "signed_url の値をここに貼る"
# → limited-time report

gcloud storage rm --recursive gs://PROJECT_ID-ch08-signed
gcloud iam service-accounts delete \
    ch08-signer@PROJECT_ID.iam.gserviceaccount.com --quiet
rm report.txt

つまずきポイント

理解度チェック

まとめと次章へ

• バケットはロケーション（リージョン / デュアルリージョン / マルチリージョン）とストレージクラスの 2 軸で設計する。耐久性は全クラス共通のイレブンナイン、違いは料金構造
• コールドクラスは最小保存期間と取り出し料金とのトレードオフ。パターンが読めるならライフサイクル管理、読めないなら Autoclass
• 誤操作対策はバージョニング + 世代の自動削除ルール、規制対応の改ざん防止は保持ポリシー + バケットロック（不可逆）と使い分ける
• アクセス制御は均一なバケットレベルアクセスで IAM に一本化し、アカウントを持たない相手には署名付き URL（最長 7 日）で時限アクセスを渡す
• 転送手段はデータ量 ÷ 帯域で決める: 1 TB 未満は gcloud storage、以上は Storage Transfer Service、回線が細ければ Transfer Appliance

参考リンク（一次情報）:

• Cloud Storage プロダクト概要 / ストレージクラス / バケットのロケーション
• オブジェクトのライフサイクル管理 / Autoclass / オブジェクトのバージョニング
• 保持ポリシーとバケットロック / 均一なバケットレベルアクセス / 署名付き URL
• Storage Transfer Service / 転送オプションの比較 / 料金

オブジェクトストレージは「何でも置ける」万能選手ですが、トランザクションやクエリが必要な構造化データには不向きです。次の第 9 章では、リレーショナルデータベース 3 兄弟 — Cloud SQL・AlloyDB・Spanner — の使い分けを設計します。