Google Cloud Storage（GCS）入門

Google Cloud Storageの役割は、バイナリデータをひとまとまりの単位として保存・取得することです。手元のコンピュータ上にあればファイルと呼ぶデータも、GCSに保存されるとオブジェクトと呼ばれます。コンピュータ上のファイルとは違い、GCSのオブジェクトはイミュータブル（不変）であり、内容を後から書き換えることはできません。

GCSのオブジェクトは削除や置き換えはできますが、変更はできません。この特性は、クラウド規模のさまざまなアーキテクチャ設計で活かせます。

GCSのオブジェクトはまた不透明（opaque）です。GCSはオブジェクトを単なるバイナリデータの並びとして扱うため、その内部構造には踏み込みません。代わりに、作成日時、MIMEタイプ、サイズといった情報を関連メタデータとして保持し、管理しています。

GCSのオブジェクトは耐久性に優れています。Googleはさまざまな技術を組み合わせてオブジェクトを保存し、リージョン内で年間少なくとも11個の「9」、すなわち99.999999999%の耐久性を確保しています。（自然・人為を問わず特定地域での災害による損失に備え、複数リージョン、さらには複数クラウドにまたがってデータを保存することも可能です。）11個の9とは、10億個のオブジェクトを100年間保存しても失われるのは最大1個、という水準を意味します。

GCSのオブジェクトは可用性も備えています。可用性とは、リクエストに応じてオブジェクトを提供できることを指します。GCSは月間可用性として99.95%、99.9%、99.0%という複数のSLAオプションを用意しています。時間に換算すると、それぞれ月間で22分、44分、7時間18分の利用不可時間に相当します。

GCSのオブジェクトは、GCPプロジェクト内のバケットに格納されます。バケットはオブジェクトに対して、識別子、ホスティングプロジェクト（セキュリティと請求アカウントに紐づく）、地理的ロケーション、各種ポリシーといったストレージのコンテキストを提供します。

GCSバケットはグローバルに一意な識別子を持ち、URIとして表現されます。GCSのバケットおよびオブジェクトには、URIスキーム gs: が用いられます。

URIの構文は次のとおりです：gs:///

例えば gs://doit-intl-storage/logo.png は、グローバルに一意なURIです。

GCSは多くのクラウドシステムのアーキテクチャ設計で重要な役割を担います。一般に、GCSは情報を保存する手段として最も安価な選択肢です。ただし、コスト効率を保つには、レイテンシ、帯域、そして従来のアーキテクチャ上の制約に目を配る必要があります。

忘れてはならないのは、GCSがあくまで「サービス」だという点です。アクセスにはREST APIを用い、それをラップする形で多数の言語向けクライアントライブラリ、CLI、サードパーティツールが提供されています。GCSはブロックストレージではないため、仮想マシンやコンテナのファイルシステムとして直接利用することはできません。

Google Cloud Storageの利用コストには、いくつかの要素が影響します。特に押さえておきたいのは次の項目です：

• オブジェクトのサイズ
• 保存期間
• バケットの特性：ロケーション、冗長性、ストレージクラス
• オブジェクトおよびそのメタデータの読み書きなどのアクティビティ
• オブジェクト転送時にネットワーク上を流れるバイト数

コストは2つの観点から捉えるとわかりやすくなります。1つ目は、オブジェクトに対して何もしない場合の保存コスト――一度書き込まれた後、読み取りも削除も行われないケースで、これが純粋なストレージコストです。2つ目は、読み取り、転送、削除、クエリなどのアクティビティに応じて発生するコストです。

具体的な数字で見てみましょう。純粋なストレージコストの例として、1 GiBのオブジェクトを1つ、1年間保存した場合を考えます。（1 GiB = 1073741824バイト（= 10243 B = 230 B）です。）

標準ストレージで最も高いのはブラジルの0.42ドルで、多くの地域では0.24ドルまで下がります。標準ストレージは頻繁にアクセスするオブジェクトに最適です。一方、アクセス頻度の低いオブジェクト向けのアーカイブクラスは大幅に安く、ブラジルで0.036ドル、その他の地域では0.0144ドルです。

アクティビティに伴うコストは、新規ユーザーにとって意外な落とし穴になりがちです。ストレージへの書き込み、読み取り、オブジェクトのリスト取得、長期保存対象オブジェクトの早期削除には、それぞれ料金が発生します。これらはクラウド規模システムのエンジニアリング、さらにはアーキテクチャ設計にまで影響を及ぼし得ます。

例えば、衛星画像を扱うある企業のコンサルティングを担当したときのことです。同社のオンプレミス環境では、小さな画像タイルを多数保存していました。これをGCSへ移行したところ、小さなタイルを読み込んで大きな画像を組み立てるという設計が、読み取りアクティビティのために極めて高コストになることが判明しました。

そこで同社は、より少数で大きな画像として保存し、読み取り後にメモリ上で分割する方式へとシステムを再設計しました。直感に反するアプローチですが、これがGCSにおける現実なのです。

クラウドセキュリティ全般については別の記事で取り上げる予定です。GCSのセキュリティはIAMで管理します。かつては、ストレージバケットに対してパブリックアクセスをうっかり許可してしまうケースが多発し、深刻な情報漏洩につながった事例もありました。現在ではGoogleがこの点を改善し、各所に警告が組み込まれています。

最新情報は DoiT Engineering Blog、DoiT LinkedInチャンネル、DoiT Twitterチャンネルでお届けしています。ぜひフォローしてください。採用情報は https://careers.doit-intl.com をご覧ください。