[Google Cloud]Always Freeプロダクトだけで作った基盤が課金されていた
Zennに偽りのブログを書いてしまった、、ごめんなさい
下記のブログにて、偽りのコメントを書きました。このブログでは、Google CloudのAlways FreeプロダクトだけでMLBデータを分析する基盤を作り上げた！とのことを書きました。
しかし、5月のコストレポートを見ると、ちゃっかりと課金されているではありませんか！
5円/月のコストのうち、3円はAlways Freeの範囲としてディスカウントが効いていますが、残る2円は、無料トライアルでもらえるクレジットから払われていました。Always Freeとして扱われていないリソース利用が行われている様です。
最も不要なコストは、、Cloud Storage！お前だぁー！
いや、不要では無いのですが、、とりあえず、2円の発生源はCloud Storageでした。
Google Cloudのコンソール画面から「お支払い」をクリック、その中の「価格表」から見ると、ヒットしたのは、マルチリージョンで組んでいるCloud Storageでした。
あれ、Cloud Storageのバケットをマルチリージョンで立ち上げたっけな、、と見ると、たしかにデータ基盤として必要なストレージは単一リージョンで作っていました。
一方で、良く分からないマルチリージョンのバケットが、しかも3個も作られていることも発覚しました。
${プロジェクト名}.appspot.comstaging.${プロジェクト名}.appspot.com${リージョン名}.artifacts.${プロジェクト名}.appspot.com
マルチリージョンのCloud Storageとなると、原因は彼らにありそうです。
それ以上近付かないで頂きたい、、貴方からは腐ったDockerイメージの匂いがする
ストレージが近付くことは無いので、ご安心下さい。しかも、私の分析基盤のリージョンはアメリカです。
良く分からないバケット3個の中身を見ると、${リージョン名}.artifacts.${プロジェクト名}.appspot.com がパンパンです。container/images/ の下に、たくさんファイルが置かれています。ディレクトリからしても、Dockerイメージなのはハッキリしています。何だこれは、、
どうやら、Cloud Buildでビルドされたコンテナのイメージが全部投入されている様です。今回のMLBデータ分析基盤では、Cloud Functionsを回してデータ連携を走らせているため、その際にCloud Run、さらに依存してCloud Buildも回っている、との具合です。
腐った、と言っているのは、もう利用しないであろう、過去のイメージもストレージにしっかり残っているからですね。このあたりはマネージドサービスが上手い具合にストレージにやさしい処理をして頂きたいのですが、どうやらやってくれないと、、
お前はストレージの面汚しだ、、出ていけ、、出ていけぇー！
消されるのみです。
このままでは延々とストレージを圧迫しかねないので、Cloud Storageのライフサイクルルールを設けることにしました。${リージョン名}.artifacts.${プロジェクト名}.appspot.com に対して、ライフスタイルのタブを押下して、キャプチャな具合で設定しました。
2日経ったイメージを削除する様ににしました。
今回のケースでは、これでもきちんとCloud Functionsが動くか、2円の課金が無くなるかは分からないので、しばらくは静観ですね、、とりあえず、分かる範囲でやれることは全てやりきってみました。
これにて、おしまいです。
サマリ
- Cloud Functionsを実行すると、Cloud Buildが走って、その時に必要になるランタイムとなるDockerコンテナのイメージファイルがCloud Storageに貯まります
- しれーっとストレージを圧迫しかねない要因になるので、ライフライクルを入れてコンスタントに整理を入れてみました
Discussion
課金が無くなりました！共有まで、、