🍛
Cloud Runの継続的デプロイ構築後、なぜかFirebase Storageの使用量が増え続けた
発生した事象
- FirebaseでStorageは使った記憶がないのに、使用量がどんどん増えいていく。
- Storageを見てもファイルがない。
ググったらFirebaseやGCPではあるあるの事象のようです。対処方法が書かれた記事もいくつか見つかった為、改めて記事にしなくても良いかと思いましたが、Cloud Runがキッカケで発症した日本語記事は見つからなかったので一応記録として残しておきます（誰か既に書いてたらゴメン）
発生タイミング
下記に書いたCloud Runを構築して、数日後に気づいた。
原因と対処(概略)
原因
- Firebaseではなく、GCP側のCloud Storageの容量が増えている
- GCPとFirebaseでストレージが連動しているみたいです
- Cloud Runは、Cloud Buildでコンテナイメージ作ってデプロイするようにしたが、このコンテナイメージが原因
- Cloud Buildがビルドする度に、何故かコンテナイメージがCloud Storageに保存されるため、Storageの使用量が増え続けた
対処方法
GCPのCloud Storageの該当バケットにライフサイクルを設定し、コンテナイメージを自動で削除する
対処方法の詳細
方針
Cloud Storageに勝手に作られるコンテナイメージが増え続けないように、自動で削除されるように設定する。
設定方法
GCPのコンソールにログインして、該当のCloud Storageバケットに行く
-
GCP->Cloud Storage->asia.artifacts.*******.appspot.com- *******の部分はたぶんプロジェクト名
ライフサイクルを設定する
-
ライフサイクルのタブを選択
-
ルールを追加 -> オブフェクトを削除する -> 次へ
-
接頭語(prefix)でパスを指定。
containers/images/sha256:
- 最初はバケット名含めてでprefixを設定していたんだけど、バケット名は入れないのが正解みたい。
-
Set Conditionで、
年齢。この翻訳はどうなのかと思いつつ、3日後に削除する設定にしておく。
設定したら1日待つ
反映されるまで最大24時間とのことなのでおとなしく待つ
結果
容量が一気に減った！！
OK
感想
- 無料の範囲内に収まっているうちに気づけてよかった
- 初めて使うサービスは思わぬところで急な課金が発生する可能性があるので怖い
- GCPとFirebaseの関係が結局よく分からない
- 統合されている部分と統合されていない部分をまとめた資料は無いのだろうか？
- なんでコンテナイメージを、Container RegistryじゃなくてStorageに置くんだ？
- もしかしてGPCにContainer Registryってないのか？と思ったけど、あった
- Container Registryにもコンテナイメージが置かれてた
- Storageに置く意味あるの？
参考させていただいた記事
Discussion