アイレット株式会社 Advent Calendar 2025

アイレット株式会社

【Google Cloud入門】オブジェクトストレージサービスーCloud Storage

Last updated at 2025-12-14Posted at 2025-12-14

皆様、こんにちは！
アイレット株式会社 DX開発事業部の楊林と申します。

前回の投稿では、Google Cloud の負荷分散についてまとめました。

今回は Google Cloud のオブジェクトストレージサービスである Cloud Storage について整理していきます。

Cloud Storage

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

オブジェクトストレージは、従来のファイルシステムのように階層構造を持つわけではなく、データを「オブジェクト」として扱う点が特徴です。オブジェクトはバイナリデータ本体に加えて、作成日時・作成者・Content-Type・権限などのメタデータを併せて持ち、世界で一意の URL によってアクセスできます。

Cloud Storage では、オブジェクトはバケットに保存されます。
バケット名はグローバルで一意である必要があります。また、Cloud Console 上に疑似的なディレクトリを作れますが、実際にはオブジェクト名にプレフィックスを付けているだけで、ファイルシステムのフォルダとは異なります。

用途としては、以下のような典型例があります。

ウェブサイトのコンテンツ配信
アーカイブや障害復旧用データの保存
直接ダウンロードによる大規模なデータオブジェクトの配布
処理ワークフローにおける中間結果の保存

Google Cloud のインフラを基盤とした高耐久性、高可用性、エクサバイト級のスケーラビリティを持ち、すべてのストレージクラスに対して統一APIが提供されている点も特徴です。

ストレージクラス

Cloud Storage には 4 種類のストレージクラスがあり、アクセス頻度に応じて選択します。

Archive Storage：読み取り頻度が年に1回未満の場合に最適
Coldline Storage：読み取り頻度が90日間に1回未満の場合に最適
Nearline Storage：読み取り頻度が30日間に1回未満の場合に最適
Standard Storage：頻繁にアクセスされるホットデータや、短時間だけ保存されるデータに最適

アクセス頻度が低いほど保存コストは下がりますが、データ取得には追加費用がかかるようになります。

さらに、各ストレージクラスには以下のロケーションタイプを組み合わせられます。

リージョン：東京みたいな特定の地理的な場所
デュアルリージョン：フィンランドとオランダみたいに、リージョンの特定のペア
マルチリージョン：米国みたいに、2つ以上の地理的な場所を含み、広い地理的なエリア

ロケーションタイプの組み合わせは自由ではなく Google が提供するプリセットから選択する方式です。

また、バケットに設定したストレージクラスはデフォルトとして機能し、オブジェクトに別クラスを指定しない限りそれを継承します。バケットのロケーションタイプは作成後に変更できませんが、既存オブジェクトのストレージクラスは後から変更できます。

アクセス頻度が読めない場合は Autoclass を有効化すると、自動的に最適クラスへ移動され、コスト最適化が容易になります。

アクセス制御

Cloud Storage のアクセス制御には複数の方法があります。

IAM

プロジェクト・バケット・オブジェクトに対して権限を管理する最も一般的な方法です。
ロールは階層的に継承されるため、ほとんどの用途は IAM だけで完結します。

アクセス制御リスト（ACL）

より細かいオブジェクト単位の権限指定が必要な場合に利用します。
ただし Google は IAM の利用を推奨しており、ACL は特殊用途向けです。

署名付きURL

期限付きで読み取りまたは書き込みの権限を外部ユーザーに与えるための仕組みです。
署名の作成にはサービスアカウントの秘密鍵を使用します。

バージョニング

Cloud Storage のオブジェクトは本来「不変」です。しかし、意図せず上書き・削除してしまうこともあります。
そのため Cloud Storage にはバージョニングが用意されています。

バケットでバージョニングを有効にすると、上書きされたオブジェクトや削除されたオブジェクトについて「アーカイブバージョン」が自動的に保持されます。
世代番号 (generation) によって過去バージョンを参照したり復元したりできます。

ライフサイクル管理

オブジェクトのアーカイブ、削除、ストレージクラスの変更などを自動化したい場合はライフサイクル管理を利用します。

バケットに JSON 形式でルールを設定し、条件を満たしたオブジェクトに対して Cloud Storage が自動で操作を行います。
変更反映には最大 24 時間かかる点は注意が必要です。

データインポートサービス

バケットにアップロードするデータが膨大な場合に使います。

Storage Transfer Service

まず、比較的扱いやすいのが Storage Transfer Service です。少量のデータだけであれば CLI やコンソールから直接アップロードしてもいいのですが、「スケジュールを決めて定期的にデータを取り込みたい」「別クラウドや別バケットから同期したい」といった場合には、このサービスがもっとも簡単です。

Storage Transfer Service は、Amazon S3 など他クラウドのバケット、オンプレミスのファイルシステム、HTTP/HTTPS、そして Cloud Storage 同士といった多様なソースからデータを移動できます。分析ワークフローの一部として毎日あるいは毎時データを同期したり、1 回限りの大規模転送を行ったり、転送元と転送先の差分を取りながら同期する、といった運用にも向いています。

作成日やファイル名、更新タイミングなどの細かな条件でフィルタし、対象データだけを転送することも可能です。さらに転送後に元データを削除したり、転送先に不要なファイルが残っている場合にクリーンアップする設定もできます。

Storage Transfer Service for on-premises data

扱うデータ量が大きくなり、しかもオンプレミスから直接 Cloud Storage へアップロードしたい場合には、同じ Storage Transfer Service のオンプレミス版を利用します。
こちらは「大規模アップロードを高速に、しかも確実に行う」ための仕組みが用意されており、データ検証・暗号化・エラー再試行・フォールトトレランスなどが標準で組み込まれています。

オンプレミス側には Google 提供のソフトウェアをインストールし、Docker コンテナとしてエージェントを動かします。複数のエージェントが並列でデータを送り出すため、数十億ファイルや数百 TB といった規模までスケールできる点が大きな特徴です。
コンソール上で転送ジョブを作成・管理し、詳細なログや進捗も確認できます。

利用にはいくつか条件があり、POSIX 準拠のソース、300Mbps 以上のネットワーク帯域、Docker 対応の Linux サーバー、そして外向きの 80 / 443 の通信が必要です。とはいえ、巨大なオンプレミス環境を Google Cloud に繋ぎ込む手段としては、もっとも実務的で扱いやすいサービスです。

Transfer Appliance

さらにデータ量が桁違いに多い場合、ネットワーク経由で送るよりも「物理的に送ったほうが早い」ということが起こります。
そのために用意されているのが Transfer Appliance です。これはデータセンターに設置して使う大容量のストレージサーバーで、1台で数十 TB〜数百 TB のデータを収納でき、オンライン転送よりはるかに速い帯域を実現します。

使い方としては、まずアプライアンスをリクエストし、封印された専用ケースで届いた機器にデータを転送します。データは保存時点で AES-256 方式により暗号化され、鍵は自分たちで管理します。データの書き込みが終わったらアプライアンスを返送し、Google が Cloud Storage への取り込みを行います。

取り込みが完了すると通知が届き、アプライアンス内のデータは NIST SP 800-88 標準に沿って完全に消去されます。データの安全性が非常に高いため、セキュリティ要件が厳しい企業でも利用されています。

最後に

今回は Google Cloud のオブジェクトストレージサービスである Cloud Storage について、その構造からストレージクラス、アクセス制御、データ移行まで一通り整理しました。

次回は Google Cloud の構造化データを保存するストレージサービスについて紹介していきます。
続けて読んでいただけると嬉しいです！

以前の投稿

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up