Google Cloud Storageを徹底解説

記事タイトルとURLをコピーする

G-genの杉村です。 Google Cloud (旧称 GCP) の容量無制限・低価格・堅牢なオブジェクトストレージサービスである Cloud Storage を解説します。

Cloud Storage

Cloud Storage の基本

Cloud Storage とは

Cloud Storage とは Google Cloud (旧称 GCP) の容量無制限・低価格・堅牢なオブジェクトストレージサービスです。

データは少なくとも 2 つ以上のゾーン (ゾーンは一つ以上のデータセンターで構成) にわたって冗長化され 99.999999999% (イレブンナイン) の堅牢性を誇ります (参考) 。

ストレージクラスと呼ばれる価格帯の違う4種類の保管タイプが利用でき、アクセス頻度によって使い分けます。

オブジェクトストレージとは

Cloud Storage は オブジェクトストレージ と呼ばれるタイプのストレージです。
代表的なオブジェクトストレージとしては他に Amazon S3 が挙げられます。

オブジェクトストレージはパソコンやサーバから使われるような、ファイルシステム経由で読み書きされるストレージとは異なります。
データは「オブジェクト」という単位で管理され、これが従来でいうファイルに相当します。

また Cluod Storage においては、オブジェクトは Web API 経由で読み書き されます。

Cloud Storage API

利用者は Google Cloud コンソール画面や CLI ツール、あるいはプログラムから SDK 経由で Cloud Storage を使うことになります。
原則的に VM にマウントしてファイルシステムで読み書きすることはできません (... が、これを可能にする離れ業もあります。後述) 。

ユースケース

Cloud Storage は以下のような用途がユースケースとなります。

  • 画像ファイル・動画ファイルなど、変更がなくサイズが大きいファイルの保存
  • 頻繁にアクセスされないファイルのバックアップ
  • データレイク (非構造データ)
  • システム間のデータの受け渡し

料金 (基本)

Cloud Storage の特徴は、安価であることです。
東京リージョンの Standard Storage のデータ保管料金は 2022 年 3 月現在で $0.023 (GB/月) です。
ファイル保管料金は概ね、 1 TB で 3,000 円程度と認識すれば良いでしょう。
最新の料金は 料金ページ を参照したり 試算ツール をご利用ください。

ただし Cloud Storage の料金はデータ保管のボリュームだけでなく、 API リクエストの回数など、複数の軸で課金されます。
これについては後述します。

またCloud Storage の料金には「 ストレージクラス 」という重要な考慮事項がありますので、これについても後述します。

用語

バケット

Cloud Storage における バケット とは、データを入れるための箱です。
バケットの単位でアクセス制御をしたり、どのリージョンに配置するかを決めることができます。 バケットには全世界で一意の名前が付けられます。

なお bucket とは「バケツ」の意味です。

オブジェクト

オブジェクト とは、バケットに入れられた個々のファイルを指します。
Cloud Storage のようなオブジェクトストレージでは基本的に、オブジェクトを一度書き込むと 「変更」という概念はありません
削除するか同名のオブジェクトで上書きすることになります。既に存在するオブジェクトを開いて編集し、1行足す、といったことはできません。
これをやりたい場合、1行を足した新しいファイルで既存オブジェクトを上書きすることになります。

なお1つのオブジェクトの最大サイズは 5 TiB です。

メタデータ

オブジェクトには メタデータ という付加情報を付与できます。
メタデータはキー・バリューのペアで保存されます。

例としてオブジェクトに Cache-Control:no-store のようにメタデータを付与すれば、オブジェクトを一般公開した際に、 HTTP レスポンスヘッダーに Cache-Control:no-store が付与されキャッシュ可否をコントロールできます。
Content-Type なども同様の使い方ができます。

上記のような HTTP ヘッダーに関連するメタデータのみならず、ユーザーが任意のキー・バリューを設定することができます。

フォルダ

フォルダ とは、バケットの中を区切る箱です。パソコンのフォルダと同様です。

...普段は意識する必要はありませんが、実は Cloud Storage の内部的にはフォルダという概念は 存在しません
Cloud Storage は内部的にはいわゆるキー・バリュー・ストアであり、平坦な構成になっています。

gs://my-bucket/my-folder/my-object というオブジェクトがあるとすると my-folder には実はフォルダという実体はなく、単に my-object というオブジェクトの名前の一部なのです。
Web コンソールや CLI ツールで空のフォルダを作ることができますが、これは実は 0 バイトのオブジェクトが作成される、という動きをしています (参考) 。

フォルダ分けされているように見えるが実際にはフラットな構成

パス

パス とは特定のオブジェクトを指し示す文字列です。見た目は Linux のパスと似ています。

gs://my-bucket/my-folder/myobject のように表されます。
先頭の gs:// は Cloud Storage のオブジェクトのパスであることを示す接頭辞です。

Cloud Storage の詳細

料金 (詳細)

料金体系を詳しく解説します。
Cloud Storage では以下の軸ごとに従量課金が発生します。

  • データ保存ボリューム (GB/月)
  • 書き込みオペレーション回数
  • 読み取りオペレーション回数
  • ネットワーク利用 (ダウンロード方向のみ、 GB)
  • 取り出し料金 (GB)

後述の「ストレージクラス」ごとに料金は異なります。

これらの料金の試算には 料金 ページを見て手計算するほか無料の 試算ツール が使えます。
(ネットワーク利用料金だけ Networking Egress という別アイコンであることにご注意ください)

ストレージクラス

Cloud Storage には 4 つの ストレージクラス が存在します。

Standard / Nearline / Coldline / Archive です。右に行くほど長期保存で取り出し頻度が少ないデータに適しています。
先の料金の項にあったように Cloud Storage にはいくつかの料金軸があります。右のストレージクラスほど GB あたりのデータ保管料金が安いが、オペレーション回数あたりの料金や取り出し GB あたりの料金が高くなる仕組みになっています。

例えば以下のようです (2022 年 3 月現在、東京リージョン) 。

ストレージクラス 保管料金 (GB/月) 書き込みオペレーション (10,000回あたり) 読み取りオペレーション (10,000回あたり) データ取り出し量 (GB) 最低保管期間
Standard Storage $0.023 $0.05 $0.004 $0 なし
Nearline Storage $0.016 $0.10 $0.01 $0.01 30 日
Coldline Storage $0.006 $0.10 $0.05 $0.02 90 日
Archive Storage $0.0025 $0.50 $0.50 $0.05 365 日

長期保管用のストレージクラスほど、データサイズあたりの料金は安いが、取り出しにお金がかかることが分かると思います。

最低保管期間 (Minimum storage duration) が各ストレージクラスごとに定められており、保管したオブジェクトがこの日数以内に削除・置換・移動された場合、この日数分の保管料金が発生してしまいます (削除できない訳ではありません) 。

ストレージクラスはバケット作成時に デフォルトストレージクラス として指定できる他、オブジェクトごとに指定することもできます。

バケットにオブジェクトが作成されるとデフォルトストレージクラスに従ってストレージクラスが設定されますが、オブジェクトごとに個別に指定できますし、後から変更も可能です。

ライフサイクルマネジメント

ライフサイクルマネジメント 機能は、オブジェクト作成後の経過日数などに従い自動的にストレージクラスを変更したり、削除したりできる機能です。バケットごとに設定できます。

例えば「デフォルトストレージクラスは Standard Storage だが、 120 日経過したオブジェクトは自動的に Coldline Storage に移動する。360 日経過したオブジェクトは削除する」といった指定が可能です。

ルール条件として「オブジェクト作成後の経過日数 (Age)」「絶対日時以前に作成されたオブジェクト (CreatedBefore)」「バージョニングで過去版になってからの日数 (DaysSinceNoncurrentTime)」など様々な 条件 が選べます。

この機能を賢く使うことで、料金を節約することができます。

バージョニング

オブジェクトには バージョニング を設定可能です。バケットごとに有効化できます。

バージョニングが有効化されると、オブジェクトを上書きすると、過去のバージョンとして指定した世代数だけ保管されます。
削除も同様で、オブジェクトを削除しても「過去のバージョン」として裏では残っている動きになります。

過去版となったオブジェクトを真に削除するには、先に記述したオブジェクトライフサイクル機能を使って「過去版になってから 14 日経過後に完全削除」のように設定します。

過去のバージョンは 普通に存在するのと同様に課金される ので、注意が必要です。

バケットのリージョン (ロケーション)

バケット作成時に ロケーション を選択します。
データは物理的に、選択したロケーションに保管されます。

ロケーションは「 単一リージョン 」「 デュアルリージョン 」「 マルチリージョン 」のタイプがあり、それぞれのタイプでリージョンを選択可能です。

日本に近いところで例を挙げると、単一リージョンとしては「 asia-northeast1 (東京) 」や「 asia-northeast2 (大阪) 」が、デュアルリージョンとしては「 asia1 (東京・大阪)」が、マルチリージョンとしては「asia (アジア圏複数リージョン) 」が選べます。

たとえ単一リージョンを選んだ場合でも、リージョン内の複数のゾーンにデータは冗長化されるため、堅牢性は高いといえます。
しかしデュアル / マルチリージョンを選ぶことで、リージョンレベルの災害、事故、政変などでもデータを維持することができます。
以下のような基準で選ぶと良いでしょう。

  • コスト効率と低いレイテンシを求める場合は 単一リージョン
  • レイテンシを抑えつつ、単一リージョンより高い地理的冗長性が欲しい場合は デュアルリージョン
  • さらに高い地理的冗長性が欲しい場合や、近隣諸国からのアクセスも想定される場合は マルチリージョン

なおリージョン間のレプリケーションは書き込み完了から 非同期 で行われます。
同期には数分からそれ以上の時間がかかることがあります。
RTO を短くする目的で ターボレプリケーション を有効化すると、遅延を 15 分以内に抑えられますが 追加料金 が発生します。

セキュリティ

アクセス制御

IAM と ACL

Cloud Storage のセキュリティは アクセス制御 の仕組みを理解することで担保します。

アクセス制御には「均一 (Uniform)」と「きめ細かい管理 (Fine-grained)」があり、可能な限り前者のみを利用することが推奨されています。
前者はバケットレベルで IAM を使って制御します。
後者はオブジェクトごとに ACL を使って制御します。

後者は Amazon S3 との相互運用性のために用意された機能ですが、細かいオブジェクトごとの権限管理は煩雑であり、運用が崩壊するおそれがあります。これが前者が推奨される理由です。

バケットは可能な限り、アクセス権限のユースケースごとに分け、バケットごとに権限管理をするのが望ましいといえます。

Google Cloud の IAM については以下の記事で詳細に解説していますので、ご参照ください。

blog.g-gen.co.jp

パブリック公開

Cloud Storage のオブジェクトは、パブリック公開設定にすることでインターネットのどこからでもアクセスできるように設定できます。

パブリック公開されたデータへアクセスする方法は以下のようなものがあります。

  • API Link: https://storage.googleapis.com/(BUCKET_NAME)/(OBJECT_NAME)
  • Google Cloud コンソール
  • Google Cloud CLI (gsutil / gcloud)

パブリック公開の禁止

当然のことながら、意図しないオブジェクトに誤ってパブリック公開設定をしないように最新の注意が必要です。

バケット単位で パブリック公開の禁止 設定をすることができます。
これを有効化すると、オブジェクトの設定に関わらず、認証無しのアクセスは弾かれます。

意図しないデータ漏洩を防ぐため、以下のように設定するべきです。

  • インターネット公開しうるオブジェクトと、公開してはいけないオブジェクトは同じバケットに混在させない
  • インターネット公開の可能性がないバケットではパブリック公開の禁止設定を有効化する

暗号化

Cloud Storage に保管されるデータは 自動的に暗号化 されます。

これはストレージレベルの暗号化であり、我々利用者からは透過的に行われるため、意識することはありません。
透過的な暗号化ですので、 Google の内部犯行や物理的な盗難などに効果を発揮するものであり、 不正アクセスに対抗できるものではない ことに注意が必要です。

この暗号化は Google が管理する鍵で行われますが、各種規定や監査への対応のため必要であれば利用者側の提供する鍵で暗号化をすることもできます。

その場合 Cloud KSM を用いて鍵を管理する Customer-managed encryption key という方法のほか、 Cloud Storage API へのリクエストの度に鍵を指定する Customer-supplied encryption key の方法があります。
いずれも利用者側で 暗号化鍵を運用するという負荷 がありますので、本当に必要なときにのみ検討するべきです。

保持ポリシー

各種規制やコンプライアンス要件への対応のため 保持ポリシー とそのロックを設定することができます。

「保持ポリシー」をバケットに設定すると、設定した期間中、オブジェクトを削除したり置換したり できなく なります。
これによりログデータ等の改ざん・消去が不可能になります。

また「保持ポリシーのロック」を設定するとバケットに 永久に 保持ポリシーを設定し、解除できなくすることができます。
これを行うと、保持期間の 延長はできます が、逆に期間を短縮したり、ポリシーを削除できなくなります。

各種規制で保管が義務付けられているログデータ等の保管に役立つ一方、保持期間がすぎるまでオブジェクトの削除は 一切できなくなります ので十分ご注意ください。

応用技

署名付き URL

署名付き URL (signed URL) 機能を使うことで、英数字の署名トークン付きの URL を知っている人がアクセスできる、時間制限付きの URL を発行することができます。

クエリ文字列内に認証情報が入っているため、 制限時間内であれば URL を知っている誰もが アクセスでき、認証は必要ありません。
何らかの理由で Google アカウントやサービスアカウントによる認証が使えない場面で、限定的なアクセス (オブジェクトのアップロードやダウンロード) を提供したいときに利用します。

署名付き URL は以下のようになります。

https://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6 (中略) c56c5ca81ff3447032ea7abedc098d2eb14a7

署名付き URL は gsutil コマンド や各プログラミング言語の Google authentication library などを用いて生成することができます (もちろん生成する側は Google アカウント等による認証が必要です) 。

組織のポリシー

組織のポリシー 機能を使うことで、同じ 組織 (Organization) に所属している全てのプロジェクト (Project) で Cloud Storage の設定を強制することができます。

例えば、前述の パブリックアクセスを組織配下の全ての Cloud Storage バケットで禁止 してしまうことなどが可能です。

Cloud Storage に対して使える組織のポリシーは他にも複数あり、 ドキュメント にまとまっています。

静的ウェブサイトホスティング

Cloud Storage に配置した HTML ファイル等をインターネット公開することで、ウェブサイトのホスティングをすることができます。

HTML ファイルを配置し、先に記述したパブリック公開にすることで https://storage.googleapis.com/(BUCKET_NAME)/(OBJECT_NAME) という URL が払い出されます。

また Cloud Load Balancing外部 HTTP(S) ロードバランサー と組み合わせることで、カスタムドメイン名 + TLS 証明書でサイトを公開することが可能です。

詳細な手順は ドキュメント に記載されています。

静的ウェブサイトホスティング

イベントドリブン・アーキテクチャ

新しいオブジェクトが作成されたときや削除されたときなど 対応イベント が発生した場合に Pub/Sub に通知したり Cloud Functions を起動することができます。

これにより、例えば以下のような処理が可能になります。

  1. ユーザーがアプリを通じて画像を Cloud Storage にアップロード (= オブジェクト作成)
  2. オブジェクト作成をトリガーに Pub/Sub にメッセージが入る
  3. Cloud Run が Pub/Sub メッセージを読み取り、画像をサムネ化して別の Cloud Storage バケットに配置

このように、オブジェクトの作成など何らかのイベントをトリガに処理が走る構成を イベントドリブン・アーキテクチャ と呼びます。

サーバーレス・従量課金・疎結合がフル活用できるこのイベントドリブンという考え方は、クラウドのメリットを最大限活用できる方法の一つです。

イベントドリブンな処理

オブジェクトの命名

Cloud Storage は分散アーキテクチャであり、バックエンドには複数のサーバーがあります。
またオブジェクト名などを管理するインデックスは辞書順に並び替えられており、やはり分散しています。
このインデックスの読み書き時の負荷分散には、オブジェクト名 (パス) が使われます。

オブジェクト名がもし以下のように連続的だと、負荷分散がされずに同一のインデックスレンジが更新され続けてしまい、負荷分散ができないため、 同時大量リクエストの際にパフォーマンスが低下 します。

/2022-03-18-19-24-00/access_log.txt
/2022-03-18-19-24-01/access_log.txt
/2022-03-18-19-24-02/access_log.txt

同時大量リクエストがありえる場合は、代わりに以下のように オブジェクト名の最初にランダムな文字列を付与 することでパフォーマンスを向上できます。
MD5 でもともとのオブジェクト名をハッシュ化して最初の6文字を取る方法などが ドキュメント では紹介されています。

/q84ic3-f2022-03-18-19-24-00/access_log.txt
/zbfg9t-2022-03-18-19-24-01/access_log.txt
/2w99uk-2022-03-18-19-24-02/access_log.txt

整合性

整合性 とはストレージやデータベースにおいて、書き込み処理が完了をした後に読み取りをした場合に、いつの時点のデータが読み取られるかを示す概念です。

分散アーキテクチャのストレージでは、書き込みオペレーションが完了した後でも、その書き込み内容が全ての分散ノードに複製されるまでの間、書き込みオペレーション実行前の古い情報が読み取られる可能性があり、一定の時間が経ってから整合性が取られる可能性があります。これは 結果整合性 と呼ばれます。

一方で、ある書き込みオペレーションが完了した後に読み取りオペレーションを実行した場合に、その書き込み内容が必ず読み取られる場合は 強整合性 といいます。

Cloud Storage は分散アーキテクチャのストレージですが、書き込みや削除の後の読み取りオペレーションは 強整合性 で実現されています。

ただし、アクセス制御設定の変更だけは結果整合性です。設定変更後、適用されるまで 1 〜数分程度の時間がかかる場合があります。

詳細は 整合性 のドキュメントにまとめられています。

BigQuery やデータ系サービスからの利用

Cloud Storage は BigQuery との連携の面でも優れています。

Cloud Storage オブジェクトとして配置した CSV, JSON, Avro, ORC, Parque 等のファイルを、 BigQuery のテーブルにロード (読み込み) することができます。
例として以下のような方法があります。

  • BigQuery の既存テーブルに Cloud Storage オブジェクトをロード
  • BigQuery のテーブル作成時に元ファイルとして Cloud Storage オブジェクトを指定
  • BigQuery Data Transfer Service で自動ジョブを作成

また BigQuery から 外部テーブル定義 を行うことで、直接 Cloud Storage オブジェクトに対してクエリをかけることも可能です。

データレイクとしての Cloud Storage

東京リージョンの BigQuery の ストレージ料金 は Active ストレージが $0.023/GB 、Long-term ストレージが $0.016 です。
これは東京リージョンの Cloud Storage の ストレージ価格 が Standard が $0.023 、 Nearline が $0.016 であるのと一致しています。

このことから Google Cloud では データレイク用のストレージ として (半) 構造化データは BigQuery に保管非構造化データは Cloud Storage に保管 、という使い分けをすることが多いです。

(非構造化データとは、画像、動画、音声のように構造化されていないデータを指します。)

これは AWS において「データレイクは Amazon S3 、データウェアハウスに Amazon Redshift 」という使い方をするのとは少し異なっています。

始めから構造化データをデータウェアハウスである BigQuery に入れておくことで、データの移送などの考慮が不要になります。

VM へのマウント

Cloud Storage バケットは原則的に VM 等へはマウントできない、と前述しましたが、方法が無いわけではありません。

Cloud Storage FUSE を使うと Linux または macOS へバケットをマウントすることができます。

しかしこの方法は、本来 API で読み書きをするべきオブジェクトストレージに、ファイルシステムライクにアクセスできるようにドライバーを噛ましているような状態です。
「大量の静的ファイル」「レイテンシが大きくても良い」「クリティカルなワークロードでない」など限定的な条件の場合のみ、利用を検討するべきだといえます。

杉村 勇馬 (記事一覧) (Facebook)

クラウドソリューション部 部長

元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格10冠。

2022年5月現在、ハマっているものはモンスターエナジーウルトラ。