Google Cloud Professional Data Engineer試験を勉強していると、Google Cloud Storage（GCS）の整合性やメタデータの扱いに戸惑うことがあります。ファイルシステムのように属性や権限を細かく管理できると思い込み、「結局どの情報が保持されて、どの情報が消えてしまうのか？」という点で混乱しました。私自身も学習中にこの違いに引っかかり、本番試験で選択肢を迷う要因になりました。本記事では、GCSのメタデータ管理の特徴と、失われやすい情報への対処法を整理します。

なぜメタデータで混乱するのか

  • オブジェクトストレージとファイルシステムを同一視してしまう
  • POSIX的なパーミッションやタイムスタンプを期待してしまう
  • GCSに保存した時点で一部の情報が保持されないことに気づきにくい

試験では「ファイル属性が保持されるかどうか」を問う問題が出るため、誤解しないことが重要です。

GCSで保持されるメタデータ

システム定義メタデータ

GCSが自動的に付与するメタデータとして、オブジェクト名、サイズ、Content-Type、作成日時、更新日時、ストレージクラス、リージョン、暗号化情報（CMEKなど）が保持されます。

ユーザー定義メタデータ

ユーザーはオブジェクトごとに任意のキーと値を付与できます。アプリケーション固有の属性やラベルはここで管理します。

一次情報：
https://cloud.google.com/storage/docs/metadata

GCSで失われやすい情報

POSIX的ファイル属性

パーミッション（chmodで設定するようなモード）、所有者、グループ、ハードリンク情報などは保持されません。これらはGCSにアップロードした時点で失われます。

一部のタイムスタンプ

アクセス時刻（atime）のような属性は保持されません。ファイルシステムから移行するときに見落としがちな点です。

ディレクトリ構造

GCSには「ディレクトリ」は存在せず、オブジェクト名に含まれる「/」を区切り文字として階層風に見せているだけです。そのためフォルダ属性や階層の所有権は存在しません。

対処法と設計上の工夫

追加メタデータの付与

失われる属性はユーザー定義メタデータとして明示的に保持する必要があります。例えば、ファイルのオリジナル所有者や権限情報をカスタムメタデータに保存することで、後から参照可能にできます。

外部システムでの管理

監査や権限管理を厳密に行う必要がある場合は、GCSとは別にBigQueryやDatastoreにメタ情報を保持し、オブジェクトIDと紐付けて運用するパターンが一般的です。

移行時のチェックリスト

オンプレのファイルサーバーからGCSに移行する場合は「保持される情報」「失われる情報」を事前に棚卸しておくことが必須です。試験対策では「保持されない属性がある」点を意識しておけば正解にたどり着けます。

試験での判断基準

  • 保持される → オブジェクト名、サイズ、Content-Type、更新日時、暗号化情報
  • 保持されない → POSIX属性、所有者、アクセス時刻、ディレクトリの概念
  • 設計対応 → ユーザー定義メタデータ、外部システム管理

実務と試験での整理の違い

実務では「メタデータをどこまでGCSに任せるか」と「どこからアプリケーション側で補うか」の線引きが重要です。試験ではそこまで深く問われませんが、「ファイル属性は保持されない」という前提を知っているかが合否を分けます。

まとめ

Google Cloud Storage（GCS）はオブジェクトストレージであり、ファイルシステム的な属性は保持しません。保持されるのはシステム定義メタデータとユーザー定義メタデータに限られます。PDE試験では「失われる情報をどう扱うか」を問われるため、誤解しないことが大切です。読了後は公式ドキュメントのメタデータ仕様を確認し、ファイル移行時にどの情報が落ちるのかシミュレーションしてみると理解が定着します。