GCSのバケット費用を十分の一に削減

はじめに

先週、費用削減のために GCS (Google Cloud Storage) のバケットの整理を行いました。

これまでは gsutilコマンドで GCSにデータをアップロードしたり、バケット間でデータを移動させたりなど、簡単な操作しかしたことがありませんでした。今回はストレージクラスやバケットのライフサイクル機能など学ぶことが多かったのでまとめます。

技術的なトピックは以下の通りです。

  • gsutilコマンドの (ちょっとした)罠
  • Cloud Monitoringによるバケットサイズの確認
  • ストレージクラス Archiveについて
  • バケットのライフサイクル機能

目次

経緯

毎月の GCP (Google Cloud Platform) の費用がプロジェクトの予算をオーバーしているため、費用削減のために GCSの整理をすることにしました。

その際に、用途不明のバケット (以降、”unknownバケット”と呼びます )が見つかりました。数年前に使用されていたようなのですが、当時の管理者は不在で、用途が不明のまま放置されていたようです。運良く、関係者を見つけて情報を得ることができました。

unknownバケットについて

  • サービスから参照されることはない
  • 過去の作業で使用されたデータのバックアップとして存在している
  • 5TB以上あるかもしれない
  • 今後も残しておきたい

現在は使用されていないものの、今後もバケット内のデータは残しておきたいとのことでした。 したがって、できる限り費用を抑えてバケットを管理していく ことにしました。

今回は以下の流れで対応していきました。

  • unknownバケットのサイズを確認
  • かかっている費用を算出
  • 適切なストレージクラスを調査
  • 料金の比較
  • 適切なストレージクラスに移行

unknownバケットのサイズを確認

gsutilの duコマンドでバケットのサイズを計測しようとするとエラーが発生しました。どうやらフォルダ名にスペースが入っていることが原因のようです。

$ gsutil -m du -sh gs://unknown/space folder
CommandException: "du" command does not support "file://" URLs. Did you mean to use a gs:// URL?


スペースの入ったフォルダ名の部分をダブルクォーテーションで囲えばエラーを回避することができるのですが、バケットの中にそのようなフォルダがたくさんあり、かつ階層的に存在していたためかなり手間暇がかかりそうでした (フォルダ名にスペースを入れるないでほしい...)。

$ gsutil -m du -sh gs://unknown/"space folder"


諦めてスクリプトを書くしかないのかなと悩んでいたときに、Cloud Monitoringでバケットのサイズを見れることを知りました。

GCPのメニューから オペレーション > Monitoring > ダッシュボード > Cloud Storage で GCSのメトリクスを確認することができ、バケットのサイズ (Object Size)を見ることできます。とても便利ですね!

f:id:yd0:20200628154420p:plain

バケットの中のフォルダ単位ではサイズが見れないようなので、そこは gsutilコマンドで確認するしかないんですかね。

ということで、unknownバケットのサイズは約 5TBということがわかりました。

(本記事では正確なサイズではなく、きりがよい 5TBで話をしていきます)

かかっている費用を算出

unknownバケットの詳細は以下の通りです。

  • サイズ - 約 5TB
  • ストレージクラス - Standard
  • リージョン - asia-northeast1 (東京)

Cloud Storage の料金 によると、unknownバケットには毎月約 1万2,600円 の費用がかかっていることがわかりました。‬年間にすると15万円以上ですから、サービスから参照されないただのバックアップにしては費用がかかりすぎです。

f:id:yd0:20200628154730p:plain

適切なストレージクラスを調査

unknownバケットの利用状況は以下の通りでしたから、ストレージクラスは Archive が適切だと判断しました。

  • サービスから参照されることはない
  • 過去のとある作業で使用されたデータのバックアップとして存在している


Archiveクラスの特徴としては以下の通りです。

  • 1年に1回未満しかアクセスしないデータに最適
  • 最小保存期間が 365日
  • データアクセスと操作に関する料金が、ストレージクラスの中で最も高い
  • 可用性の SLA (Service Lavel Agreement) がない
  • 全ストレージクラスで最安値

サービスから参照されずバックアップとして存在している unknownバケットなので、アクセス頻度や最小保存期間、アクセス/操作料金の高さ、可用性 SLAが無いことは問題ないでしょう (ちなみに、可用性は Nearlineと Coldlineと同じ 99.9%です)。そして何より、全ストレージクラスの中で最安値ですから、できるだけ費用を抑えたい今回のケースにおいては最も適切なストレージクラスといえます。

料金の比較

Archiveクラスに変更した場合、unknownバケットの毎月の費用は約 1,400円 です。現在の Standardでは約 1万2,600円なので、ほぼ十分の一まで費用を削減することが可能です!

適切なストレージクラスに移行

費用をほぼ十分の一に抑えられることを関係者にアピールし、ストレージクラスの変更許可をいただきました。さっそく実施します。

ストレージクラスを変更する方法は2つあります。

今回はライフサイクル機能を使用することにしました。理由としては、unknownバケットのスペースが入っているフォルダでエラーが起きるかもしれないということと、今後ストレージの管理をしていく際に、自動でストレージクラスを変更してくれるライフサイクルは必須になると思ったので、試してみたかったからです。

ライフサイクル機能を使用する

今回のライフサイクルのルール設定は以下の通りです。

  • トリガーは年齢とし、1日以上経過されたオブジェクトが対象
  • アクションはストレージクラスを Archiveに変更

f:id:yd0:20200628024040p:plain


unknownバケットにおける既存のオブジェクトをすべて Archiveクラスに変更できればいいので、トリガーはてきとうに年齢、設定値は1日としました。今思いましたが、ストレージクラスをトリガーにした方が良かったかもしれませんね。まあ結果としては変わりません。

オペレーション費用について

ちなみに、ストレージクラスを変更するのに料金が発生します。 各クラスへのオペレーションの分類 によると、ライフサイクルでのストレージクラスの変更はクラスAオペレーションに該当します。また ライフサイクルの操作 によれば、Archiveクラスへの変更は、ArchiveクラスのクラスAオペレーションの料金で計算されます。

Archiveクラスへのアクセス/操作については料金が高いので注意しなければいけません。またオペレーションの料金はオブジェクト数で決まるので、サイズと同様に Cloud Monitoringで確認が必要です。

バケットのストレージクラスの変更

ライフサイクル機能はオブジェクトに対しての操作なので、unknownバケットのストレージクラスは Standardのままです。今後、新規にデータが追加されることはないのですが、いちおうバケットのストレージクラスも Archiveに変更しておきました。

f:id:yd0:20200628160547p:plain

以上で、ストレージクラスの移行は完了です。

さいごに

費用削減のため GCSのバケットの整理を行いました。適切にストレージ管理を行うにはストレージの知識だけでなく、扱うデータの用途や特徴を理解するべきですね。

ストレージのデータ量は日々増えています。今のままでは時間の経過とともに費用は高くなっていくので、今回学んだことを活かして上手く管理していければと思います。

クラウドストレージっておもしろい。