Google Cloud Assosiate Cloud Engineer
第4章　ストレージとデータ移行

コンテンツ

4.1 Cloud Storage
4.2 ブロック・ファイルストレージ（Persistent Disk / Filestore）
4.3 データ移行・整合性

4.1 Cloud Storage

この節では、ACE 試験で必須となる Cloud Storage の基礎を整理します。
特に次の 3 点が重要です。

ストレージクラスとユースケース
料金体系と「最低保存期間」の意味
IAM と ACL の違い・試験で選ぶべきアクセス制御モデル

4.1.1 Cloud Storage の役割と基本概念

Cloud Storage は、Google Cloud が提供するオブジェクトストレージサービスです。

任意のバイナリデータ（オブジェクト）を「バケット」に保存
利用側が OS やファイルシステムを管理する必要はなく、HTTP(S) API やライブラリでアクセス
耐久性 99.999999999%（いわゆる 11 ナイン）レベルでデータを保持
バケットはリージョン / デュアルリージョン / マルチリージョンを選択可能

ACE 試験では、「どのストレージクラスを使うか」「費用の見積もり」「アクセス制御」の観点で問われます。

4.1.2 ストレージクラスとユースケース

Cloud Storage の代表的なストレージクラスと最低保存期間は、公式ドキュメントで次のように定義されています。

クラス	API 名	最低保存期間	典型的な用途の目安	取得料金
Standard	`STANDARD`	なし	頻繁にアクセスするデータ、短期保存	なし
Nearline	`NEARLINE`	30 日	月 1 回未満のアクセス	あり
Coldline	`COLDLINE`	90 日	四半期に 1 回未満のアクセス	あり
Archive	`ARCHIVE`	365 日	1 年に 1 回未満のアクセス（アーカイブ用途）	あり

※「取得料金あり」は、そのクラスからデータを読み出したり、クラス間コピーを行う際に追加料金が発生することを意味します。

それぞれのクラスの特徴をもう少し具体的に見ていきます。

Standard ストレージ

最低保存期間なし
取得料金なし
可用性が最も高く、頻繁アクセス向け
Web サイトの静的コンテンツ、ログの短期保管、分析用のホットデータなどに適する

ポイント
「いつ削除しても最低保存期間ペナルティがない」「読み出すたびの追加料金もない」ため、デフォルトの選択肢になります。

Nearline ストレージ

最低保存期間: 30 日
取得料金あり
多くても月 1 回程度アクセスするデータ向け
バックアップの世代管理、月次レポートの原データなど

注意点

保存開始から 30 日以内に削除すると、その残り期間分の料金が請求される（早期削除ペナルティ）。

Coldline ストレージ

最低保存期間: 90 日
取得料金あり
四半期に 1 回未満のアクセスを想定
災害復旧用バックアップ、監査対応用ログなど

注意点

Nearline より保存単価は安いが、取得料金・操作料金は高くなる
「ほとんど読まないが、いざというときには必要」なデータ向け

Archive ストレージ

最低保存期間: 365 日
取得料金あり
1 年に 1 回未満しかアクセスしないデータ向け
法令や規制で長期保管が必要なデータ、長期アーカイブ

他クラウドと異なり、Archive でも「取得に数時間かかる」といったことはなく、ミリ秒〜秒オーダーでアクセス可能と説明されています。

4.1.3 料金の考え方と試験での押さえどころ

Cloud Storage の料金は、主に次の要素で構成されます。

保存料金（Storage）
- ストレージクラス・リージョンごとの「GB / 月」単価
- 一般に Standard → Nearline → Coldline → Archive の順に安くなる
ネットワーク料金（Network）
- インターネットへのアウトバウンド（エグレス）
- 他リージョンへのコピーなど
操作料金（Operations）
- Class A / Class B 操作（PUT / LIST / GET など）の回数課金
取得料金・早期削除料金（Nearline / Coldline / Archive）
- 対象クラスからデータを取得した際の「GB ごとの取得料金」
- 最低保存期間前に削除した場合の「残り期間分の保存料金」

ACE 試験では、具体的な単価（$/GB）まで暗記する必要はありませんが、「どの項目に対して料金がかかるか」「低頻度アクセス用クラスでは取得と早期削除に追加料金がある」ことは理解しておくべきです。

代表的な出題パターンとしては次のようなものがあります。

「年に 1 回だけ参照するが、10 年間は保持が必要で、コストを最小化したい」
→ Archive（最低保存期間 365 日、取得料金あり）
「月次バッチでしか読まないログだが、30 日以内に削除することはない」
→ Nearline（30 日最低保存期間）
「短期間（数日〜数週間）だけ大量データを保持し、その後削除」
→ Standard（最低保存期間がない）、Nearline / Coldline / Archive を選ぶと早期削除料金が無駄になる

4.1.4 IAM と ACL：2 つのアクセス制御モデル

Cloud Storage のアクセス制御は、IAM と ACL の 2 系統があります。

IAM（Identity and Access Management）
- Google Cloud 全体で利用されるアクセス制御仕組み
- プロジェクト / バケット / （マネージドフォルダ）単位でロールを付与
- roles/storage.objectViewer などのロールで権限を管理
ACL（Access Control List）
- Cloud Storage 専用のアクセス制御
- オブジェクト単位 / バケット単位で個別に権限を設定
- READER / WRITER などのよりシンプルな権限モデル

公式ドキュメントでは、一般的には IAM を推奨しており、「複数オブジェクトに共通する権限は IAM で付与せよ」と明記されています。

4.1.5 Uniform bucket-level access（均一なバケットレベルアクセス）

IAM と ACL が両方存在すると混乱のもとになるため、Cloud Storage には
Uniform bucket-level access（均一なバケットレベルアクセス） という機能があります。

有効化すると、そのバケット配下では ACL が無効化 され、IAM のみでアクセス制御が行われる
バケット内のすべてのオブジェクトに、バケットレベルの IAM ポリシーが一貫して適用される
マネージドフォルダや IAM Conditions、Workforce Identity Federation など、IAM 特有の機能を活用しやすい

Google Cloud 自身も、原則として Uniform bucket-level access（現行の UI では “Uniform” アクセス）を推奨しており、ACL はレガシー／特定用途向けと考えるのが妥当です。

ACE 試験での典型的な判断ポイントは次のとおりです。

「組織全体で一貫した権限管理を行いたい」
→ Uniform bucket-level access を有効化し、IAM のみで管理
「オブジェクトごとに個別の公開／非公開を設定しているレガシー環境」
→ ACL が残っている可能性はあるが、新規設計では推奨されない

4.1.6 ACE 試験で押さえるべき Cloud Storage のポイント

最後に、ACE 向けに Cloud Storage で確実に押さえておきたい項目をまとめます。

ストレージクラスと最低保存期間
- Standard: 最低保存期間なし、頻繁アクセス
- Nearline: 30 日、月 1 回未満アクセス
- Coldline: 90 日、四半期に 1 回未満
- Archive: 365 日、年 1 回未満
料金の構成要素
- 保存料金（GB / 月）
- ネットワーク料金（エグレス）
- 操作料金（Class A / B）
- Nearline / Coldline / Archive の取得料金 & 早期削除料金
IAM と ACL の違い
- IAM: プロジェクト / バケット単位でロールを付与する、Google Cloud 共通の仕組み
- ACL: Cloud Storage 専用、オブジェクト単位のきめ細かい制御が可能だが、管理が複雑になりがち
Uniform bucket-level access の意味
- 有効にすると ACL を無効化し、IAM のみで一貫したアクセス制御を行う
- 新規設計では基本的にこちらが推奨される
ユースケースに合わせたクラス選択
- 「頻繁アクセス」「削除時期未定」 → Standard
- 「定期バックアップ（月次）」「30 日以上保持」 → Nearline
- 「長期保管・滅多に読まない」 → Coldline / Archive

この節を理解しておけば、ACE 試験における Cloud Storage の問題（ストレージクラス選択、料金のざっくり見積もり、アクセス制御のベストプラクティス）は、ほとんど落とさずに解けるはずです。

4.2 ブロック・ファイルストレージ（Persistent Disk / Filestore）

この節では、Compute Engine や GKE でよく使う 2 種類のストレージ、

ブロックストレージ: Persistent Disk（PD）
ファイルストレージ: Filestore

を、用途と特徴の違いに焦点を当てて整理します。

ACE 試験では、

「どんなワークロードに PD を使うべきか」
「どんなときに Filestore を選ぶべきか」
「Cloud Storage との違い」

が選択問題で問われやすいため、「ストレージの種類 × 用途」をイメージできるようにしておくことが重要です。

4.2.1 ブロックストレージとファイルストレージの違い

まずは概念の整理から始めます。

ブロックストレージ（Persistent Disk / Hyperdisk）

VM（Compute Engine）からは ディスク（ブロックデバイス） として見える
OS 側でファイルシステム（ext4 など）を作成して利用
通常は 1 台の VM にアタッチして利用（特殊なマルチライター構成は ACE の範囲外）
例: OS ブートディスク、DB のデータディスク、アプリケーションのローカルデータ

ファイルストレージ（Filestore）

VM や GKE ノードからは NFS 共有ディレクトリ として見える
複数 VM / Pod から同じファイルシステムを同時にマウントして利用
POSIX 互換のファイルインターフェース（ファイルロックなど）を必要とするレガシーアプリに適合
例: 共有ホームディレクトリ、コンテンツ共有、アプリケーションの共有ストレージ

一言でまとめると、

PD:「1 台の VM のローカルディスクをクラウドで持つイメージ」
Filestore:「マネージド NFS ファイルサーバ」

と覚えておくとイメージしやすくなります。

4.2.2 Persistent Disk（PD）の基本と種類

公式ドキュメントでは、Persistent Disk（PD）と Hyperdisk が Google Cloud の代表的な耐久ブロックストレージとして説明されています。ACE では依然として PD がよく出題されるため、PD を中心に整理します。

特徴

耐久性のあるブロックストレージ
- VM を停止・削除しても、PD 自体は残る
- 耐久性・冗長性はプラットフォームが提供
インスタンスから独立したリソース
- 別の VM に付け替えることができる
- 実行中の VM に後からアタッチすることも可能
ゾーナル / リージョナル PD
- ゾーナル PD: 単一ゾーン内で冗長化
- リージョナル PD: 2 つのゾーンに同期複製され、ゾーン障害に対する耐性を向上
料金モデル
- 容量（GB）単位の月額課金
- 標準 PD（HDD）、バランス PD、SSD PD など、タイプによって単価と性能が異なる
- I/O は容量料金に含まれており、Cloud Storage のような「取得料金」はない

代表的なディスクタイプと用途

Persistent Disk には複数のタイプがあり、公式ドキュメントやチューニングガイドで次のように整理されています。

Standard Persistent Disk（pd-standard）
- HDD ベース
- 大容量の順次 I/O が中心のワークロード向け（ログ、DWH の一部など）
Balanced Persistent Disk（pd-balanced）
- SSD ベース
- コストと性能のバランスが良い、汎用用途向け（多くのアプリケーションの標準選択肢）
SSD Persistent Disk（pd-ssd）
- SSD ベース
- 低レイテンシ・高 IOPS を必要とする DB などに向く
（補足）Extreme PD / Hyperdisk
- より高い IOPS / スループットを必要とするエンタープライズ向け
- ACE では名前だけ知っていれば十分で、詳細な性能値までは不要

ACE 試験では、だいたい次のような選び方が問われます。

「コスト重視の大容量順次 I/O」 → Standard PD
「一般的なアプリケーションのデータディスク」 → Balanced PD
「高性能 DB など、IOPS 重視」 → SSD PD / Extreme / Hyperdisk

4.2.3 PD のユースケース（ACE 観点）

PD は、Compute Engine や GKE のワークロードで次のような用途に使われます。

OS ブートディスク
- すべての Compute Engine VM はブートディスクとして PD または Hyperdisk を利用
アプリケーション / データディスク
- Web サーバのログ、アプリケーションの一時ファイル、アップロードデータなど
データベースストレージ
- RDBMS（MySQL / PostgreSQL 等）を自前運用する場合のデータファイル格納先
GKE の PersistentVolume バックエンド
- Kubernetes の PersistentVolume として PD をマッピングして利用

ACE の出題イメージとしては、

「Compute Engine 上の DB のストレージとして何を使うか」 → PD（SSD / Balanced）
「VM を削除してもデータは残したい」 → Persistent Disk
「スナップショットを取り、別リージョンに復元したい」 → PD のスナップショット機能

といった形で登場します。

4.2.4 Filestore の基本とサービスティア

Filestore は、Google Cloud が提供するマネージド NFS ファイルストレージです。複数の VM や GKE クラスタから共有ファイルシステムとしてマウントでき、オンプレミスの NAS に近い役割を担います。

特徴

NFS ベースの共有ファイルシステム
- VM や GKE ノードから NFSv3 でマウント
- ファイルロックやディレクトリ構造など、POSIX に近いファイル操作が可能
複数クライアントからの共有アクセス
- 同じ Filestore インスタンスを複数の VM / Pod から同時利用可能
- 共有ホームディレクトリや共有ワークスペースとして利用しやすい
マネージドサービス
- 容量拡張・スナップショット・バックアップ機能が提供される
- データは暗号化されて保存され、SLA に基づいた可用性が保証される

サービスティアと用途

公式ドキュメントでは、Filestore には複数のサービスティアがあり、それぞれ用途が定義されています。

代表的なティア:

Basic ティア（Basic HDD / Basic SSD など）
- ファイル共有、開発環境、Web ホスティング、基本的な AI など
- 比較的低コストで、一般的なファイルサーバ用途
Zonal / High Scale ティア
- HPC、バッチ計算、EDA、メディアレンダリング、分析など
- 高スループット・高 IOPS が必要な大規模ワークロード向け
Regional / Enterprise ティア
- SAP やミッションクリティカルなエンタープライズワークロード向け
- リージョンレベルの可用性（複数ゾーンに冗長化）を提供

Filestore の容量は一般に 1〜100 TiB といったレンジでプロビジョニングされます（マルチシェア構成では 10 GiB 単位の小さい共有も可能）。

料金モデルのイメージ

容量（TiB）とサービスティアに応じて時間単位で課金される
操作回数や I/O 単価ではなく、「プロビジョニングした容量 × ティア」ベースが中心

正確な単価は試験では問われませんが、「高性能ティアほど単価が高い」「PD より最小容量が大きく、高価になりやすい」程度は理解しておきましょう。

4.2.5 Persistent Disk と Filestore の比較

ここまでの内容を、ACE での構成判断に必要な観点に絞って比較します。

用途・アクセスパターンの違い

観点	Persistent Disk（PD）	Filestore
ストレージ種別	ブロックストレージ	ファイルストレージ（NFS）
主な接続先	1 台の VM（または GKE ノード）	複数 VM / Pod から同時マウント
代表的用途	OS ブート、DB データ、アプリのローカルディスク	共有ホーム、共有コンテンツ、レガシーアプリの共有ストレージ
インターフェース	OS がマウントするブロックデバイス（/dev/sdX など）	NFS マウントポイント（例: `/mnt/filestore`）
最小容量の目安	数十 GB から（細かく増減可能）	一般に 1 TiB 以上（ティアにより異なる）
料金イメージ	容量（GB）単価。I/O は料金に含まれる	容量（TiB）× ティア単価。高性能ティアは高価

どちらを選ぶべきか（ACE 的判断）

Persistent Disk を選ぶケース

Compute Engine VM の OS / データディスク
RDBMS などのブロックデバイス前提ワークロード
単一 VM（または冗長構成の少数 VM）がデータを扱う構成
GKE の PersistentVolume をシンプルに構成したい場合（PD ベース）

Filestore を選ぶケース

複数 VM / Pod から 同じディレクトリ階層 を共有したい
NFS / POSIX ファイルシステムが前提のレガシーアプリをクラウドに移行したい
メディアレンダリングや HPC ジョブなど、共有ファイルへの高スループットアクセスが必要

Cloud Storage と比較すると

Cloud Storage はオブジェクトストレージであり、POSIX ファイルシステムや NFS マウントをそのまま置き換えるものではない
「アプリから普通に open() して読み書きしたい」「NFS が前提」といった場合は、Filestore or PD を検討するのが自然

4.2.6 ACE 試験でのチェックポイント

最後に、PD / Filestore について ACE で押さえるべきポイントをまとめます。

ストレージの種類の違いを説明できること
- PD: VM のローカルディスクとして扱うブロックストレージ
- Filestore: NFS 共有として扱うマネージドファイルストレージ
PD の代表的なタイプと用途を理解していること
- Standard / Balanced / SSD、耐久ブロックストレージとして DB やアプリケーションディスクに使う
Filestore のユースケースとティアのイメージが持てること
- 共有ホーム、ファイル共有、HPC・メディア処理など
- Basic / Zonal / Regional / Enterprise / High Scale のようなティアがあり、用途に合わせて選ぶ
料金・最小容量のざっくりした違いを理解していること
- PD: 小さい単位から柔軟にプロビジョニング可能、GB 単位課金
- Filestore: TiB 単位でのプロビジョニングが基本、サービスティアにより単価が変わる
代表シナリオで正しく選べること
- 単一 VM 上の DB → PD（SSD / Balanced）
- 複数 VM から参照する共有ディレクトリ → Filestore
- HTTP 静的コンテンツ配信やアーカイブ → Cloud Storage（第 4.1 節）

このレベルまで整理できていれば、「ブロックストレージ / ファイルストレージをどのように選択するか」という ACE の出題領域は十分カバーできていると考えてよいでしょう。

4.3 データ移行・整合性

この節では、Cloud Storage へのデータ移行と、移行後の「データの整合性・保護」を扱います。
ACE レベルでは次の 3 点が押さえどころです。

gsutil rsync（および後継の gcloud storage rsync）による同期
オブジェクトバージョニングと削除保護の仕組み
Cloud Storage の整合性モデル（strong global consistency）と完全性検証

4.3.1 Cloud Storage へのデータ移行の全体像

Cloud Storage へのデータ移行・同期で、実務と試験の両方で頻出なのが次のパターンです。

オンプレミス / ローカルディレクトリ → Cloud Storage バケット
バケット ↔ バケット（環境別やリージョン別の複製）
一度に大量のファイルをアップロードする際の性能チューニング

公式では、Cloud Storage の CLI として gcloud storage が推奨されていますが、gsutil も依然として広く使われており、ドキュメントにも詳細な説明が残っています。

ACE 試験では具体的なコマンドオプションまで問われることは多くありませんが、「何を使えば何ができるか」というレベルでイメージを持っておくことが重要です。

4.3.2 gsutil rsync による同期

gsutil rsync は、ローカルディレクトリやバケットの内容を差分同期するためのコマンドです。

“gsutil rsync は、src_url の内容と同じになるように dst_url を同期する。足りないファイルをコピーし、-d 指定時には余分なファイルを削除する”

基本構文

代表的な使用例は次のとおりです。

ローカル → バケット

# ディレクトリ data/ の内容をバケットに同期
gsutil rsync -r ./data gs://my-bucket/data

バケット → ローカル

gsutil rsync -r gs://my-bucket/data ./data

バケット ↔ バケット

gsutil rsync -r gs://src-bucket/data gs://dst-bucket/data

-r を付けるとディレクトリ・プレフィックスを再帰的に処理します。

主なオプション（実務でよく使うもの）

-r
ディレクトリ / プレフィックスを再帰的に同期。
-d
宛先にあって、送信元に存在しないオブジェクトを削除。
→「バックアップ先を完全にミラーにしたい」ときに使用。
-n
ドライラン（dry-run）。実際にはコピー・削除せず、「何が行われるか」を確認。
-m
複数スレッドで並列に実行し、パフォーマンスを向上。
-x
正規表現で除外パターンを指定（特定拡張子を除外など）。

実務的な注意点

-d を付けると宛先側の「余分なもの」は削除されるため、本当に「完全ミラー」が目的のときだけ使う。誤指定するとバックアップを消す事故につながる。
ファイル数が多い場合は -m を付けて並列化すると高速化できるが、API コール数も増えるため、制限や費用を考慮する。
gsutil rsync はワイルドカードを直接受け付けないため、必要に応じて -x を使う。

4.3.3 gcloud storage rsync との位置づけ

公式ドキュメントでは、Cloud Storage 用の推奨 CLI は gsutil ではなく gcloud storage になっています。

gcloud storage rsync は、基本的に gsutil rsync と同様に「送信元と宛先を同期する」コマンドであり、今後の標準的な選択肢です。

ACE では、具体的な CLI 名よりも「ディレクトリやバケットの同期には rsync 系のコマンドがある」という理解があれば十分です。ただし、実務で触るときは新しい gcloud storage 系に慣れておくとよいでしょう。

4.3.4 大容量データのアップロードと性能

大量・大容量オブジェクトのアップロードでは、速度と信頼性の両方を意識する必要があります。

並列コピー

gsutil cp / gcloud storage cp には -m オプションがあり、同時に複数オブジェクトをアップロードすることでスループットを向上できます。

gsutil -m cp -r ./files gs://my-bucket/files/

これだけで、単一プロセス・単一スレッドでのコピーより大きく時間を短縮できることが多いです。

並列複合アップロード（Parallel Composite Uploads）

非常に大きな単一ファイルを高速にアップロードしたい場合、gsutil には 並列複合アップロード という仕組みがあります。

仕組みの概要:

元ファイルを最大 32 チャンクに分割
それぞれを一時オブジェクトとして並列アップロード
サーバ側でそれらを結合して 1 つの複合オブジェクトにする
一時オブジェクトを削除

その代わり、最終オブジェクトは 複合オブジェクト となり、MD5 ハッシュが付かず、CRC32C のみが利用できる点が注意事項として明記されています。

並列複合アップロードを使用するのは、「アップロードされたオブジェクトに MD5 が不要」「ダウンロード側が CRC32C を検証できる」場合に限るべきとされています。

ACE 試験でここまで細かく聞かれる可能性は低いですが、「大容量ファイルの高速アップロードにこういった仕組みがある」「MD5 が付かないなどの制約がある」といったレベルで覚えておくと、シナリオ問題で選択肢を絞りやすくなります。

4.3.5 整合性：strong global consistency と完全性チェック

Cloud Storage は、全オペレーションに対して strong global consistency を提供します。

公式ドキュメントから要点を整理すると:

オブジェクトの 作成・更新後の読み取り（read-after-write, read-after-update）は即座に新しい内容を返す
オブジェクトの削除が成功した後の読み取りは、直後でも 404 Not Found となる（read-after-delete）
これらはメタデータ操作も含めて、グローバルに一貫した結果を返す

つまり、「アップロードのレスポンスが成功を返したら、世界中のどこから読んでもすぐにその内容が見える」というモデルです。これにより、バッチ処理やパイプラインで「アップロード直後に別ジョブが読み込む」ような構成でも、一貫性の心配をする必要がほとんどありません。

チェックサム（CRC32C / MD5）による完全性検証

Cloud Storage では、オブジェクトの完全性を検証するために、CRC32C と MD5 のチェックサムが管理されます。

通常のアップロード（非複合オブジェクト）の場合、MD5 と CRC32C 両方が利用可能
gsutil cp / rsync はアップロード時・ダウンロード時にこれらのチェックサムを比較し、破損があれば再試行する
並列複合アップロードを使った複合オブジェクトでは MD5 が付与されず、CRC32C のみが利用されるため、クライアント側でも CRC32C を検証できる環境が推奨される

ACE では「Cloud Storage は strong global consistency を提供し、チェックサムによりデータ完全性を検証できる」という整理ができていれば十分です。

4.3.6 オブジェクトバージョニングと削除保護

データ移行・運用で重要なのが、「誤削除や上書きからどう守るか」です。ここでは、Cloud Storage の オブジェクトバージョニング を中心に整理します。

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

公式ドキュメントでは、オブジェクトバージョニングは次のように説明されています。

バージョニングを有効にすると、オブジェクトが削除・上書きされた場合、
以前のバージョンは「非現行バージョン」として残る
ライブバージョン（現行）とは別に、世代（generation）番号付きで過去バージョンが保持される
バージョンにデフォルト上限はなく、非現行バージョンもライブバージョンと同じレートで課金される
古いバージョンを自動で削除したい場合は、オブジェクトライフサイクル管理を併用することが推奨されている

典型的な操作は次のとおりです。

有効化: バケットの設定で Versioning を有効にする
一覧表示: gsutil ls -a などで世代付きのオブジェクトを確認
復元: 特定の generation を指定してコピーし、現行バージョンとして戻す
不要バージョン削除: ライフサイクルポリシーで「古い非現行バージョンを削除」ルールを設定

Soft delete / 保持ポリシーとの関係

最近のドキュメントでは、Soft delete（削除の保留）や保持ポリシー（Retention policy） を使って削除保護を行うことも推奨されています。

Soft delete
- 削除されたオブジェクトを一定期間復元可能な状態で保持
- 誤削除や悪意ある削除からの保護に有効
保持ポリシー（Retention policy）
- オブジェクトに対して「最低保持期間」を設定し、その期間が経過するまでは削除不可にする

ACE 試験では、バージョニングと合わせて「削除保護の仕組みが複数ある」ことを把握しつつ、
「過去の状態に戻したい」→ バージョニング、「一定期間削除させたくない」→ 保持ポリシー／Soft delete
という整理ができていれば十分です。

4.3.7 ACE 試験向けチェックポイント

最後に、この節の内容を ACE の出題観点に沿ってまとめます。

データ同期ツールのイメージ
- gsutil rsync / gcloud storage rsync によって、ローカル → バケット、バケット ↔ バケットを差分同期できる
- -r（再帰）、-d（宛先の余分なオブジェクト削除）、-m（並列実行）といったオプションの役割を理解しておく
大容量ファイルの扱い
- -m による並列コピーでスループット向上
- 並列複合アップロード（Parallel composite uploads）は、巨大ファイルを分割・並列アップロードして性能を上げる仕組みだが、MD5 が付かず CRC32C のみになるなどの制約がある
Cloud Storage の整合性モデル
- Cloud Storage は strong global consistency を提供する
- 書き込み成功直後の読み取り・削除後の読み取りで、世界中どこからでも一貫した結果が得られる
完全性チェック
- オブジェクトには CRC32C / MD5 などのチェックサムが管理され、CLI からのアップロード・ダウンロード時に自動検証される
- 並列複合アップロードでは MD5 が使えず、CRC32C 検証が前提になる
バージョニングと削除保護
- オブジェクトバージョニングは、削除・上書きされた過去バージョンを非現行バージョンとして保存し、後から復元できる仕組み
- 非現行バージョンも課金対象であり、ライフサイクル管理と組み合わせて古いバージョンを自動削除するのが推奨される
- Soft delete や保持ポリシーによって「削除を一時的に禁止・保留」することもできる

これらを押さえておけば、Cloud Storage における「データ移行」「整合性」「削除保護」に関する ACE レベルの問題には十分対応できるはずです。

Google Cloud Assosiate Cloud Engineer第4章 ストレージとデータ移行