firebase storage のサイズが大きくなったのでオラったらやらかしちゃった話

2021/01/16 22:26 追記

-----

どうもこんにちは、ukisoft です。
この記事は、趣味で宇宙開発を行う団体「[リーマンサット・プロジェクト](https://www.rymansat.com/)」がお送りする[新春アドベントカレンダー](https://qiita.com/rsp-dgkz/items/a6ff573c07dbe2c6166f)の 1/15 分の投稿になります。
僕がリーマンサットで何しているかというと、RSP-01 という衛星で使う画像分類のツールを作ったり、運用のシステム開発を手伝ったりしてます。ほんの少しですけど。

今回は、他の人が宇宙に関する記事を投稿する中、空気を読まずに個人開発の話を書きます（つまり最近は幽霊部員）。

# firebase とは？

firebase は、google が提供する BaaS で、ios や android のアプリのバックエンドの他、web サービスのバックエンドとしても使えます。
機能は色々あるんですが、その中に functions（aws でいう lambda）と storage（aws でいう s3）があります。
今回はこの２つの機能でやらかしました。

# きっかけ

事の発端は、storage の使用量を確認したときでした。
firebase には無料枠があり、storage は 5gb まで無料なのですが、気づけば 4.4gb 使っていたのです。

![Screen Shot 2021-01-07 at 20.12.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39090/d22b5491-8f23-cf92-958e-553feeb66567.png)

個人開発では、未だ一錢も稼げていない身。
できれば無料枠の範囲で開発を続けたい・・・ていうか、storage そんな使ってないんだけど？

調べてみたところ、us.artifacts.hoge.appspot.com と asia.artifacts.hoge.appspot.com というバケットが妙に重い。
見てもよくわからなかったのでググってみたところ、「[Cloud Functions for Firebaseを使用した時に、Cloud Storageのストレージ容量が圧迫される問題について調べた](https://kenchan0130.github.io/post/2020-10-21-1)」にこう書かれてありました。

> Cloud FunctionsのNode.js 10系以上のランタイムを使用する場合、内部ではCloud Runが動いています。 Cloud RunにはDockerイメージが必要であり、このDockerイメージがCloud Storageに保存されていたのです。

> 最新バージョンのDockerイメージだけではなく、過去のイメージも消されずに残っていました。 そのため、Cloud Functionsのデプロイを行うたびにDockerイメージが作成されていました。

なるほど、画像ファイルなどのアップロード以外でも使われていたのか。
というわけで、嬉々として storage にファイル作成から３日後に削除されるようライフサイクルの設定をする私。
はい、フラグが立ちました。

# 何が起きたか

次の日、少しコードを修正したので functions を deploy しようとしたら・・・。

![Screen Shot 2021-01-08 at 22.55.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39090/768f743a-d234-1f90-2712-17223d3e0fb9.png)

ほわい？
log を確認した結果、コンテナイメージにアクセスしようとしたところ、404 が返ってきてエラーになっていることが原因の模様。

まぁどう考えても昨日のライフサイクルの設定だろと色々調べた結果、「[Cloud Functions イメージのビルド](https://cloud.google.com/functions/docs/building)」にこう書かれてました。

> 関数のソースコードを Cloud Functions にデプロイすると、そのソースは Cloud Storage バケットに保存されます。Cloud Build はコードを自動的にコンテナ イメージに構築し、そのイメージを Container Registry に push します。Cloud Functions は、関数を実行するためにコンテナを実行する必要がある場合に、このイメージにアクセスします。

**つまり、消すなってことですねわかります。**

**ていうか、「[Cloud Functions for Firebaseを使用した時に、Cloud Storageのストレージ容量が圧迫される問題について調べた](https://kenchan0130.github.io/post/2020-10-21-1)」にもちゃんと書かれてますけどね。**

# どうしたか

一度、firebase console から該当の functions を削除することで、再び deploy できるようになりました。
なお、ライフサイクルの設定は消しました・・・。
確認しなかったのですが、deploy 以外に functions そのものも動かなくなっていたのではないかと思います。
今回はその前に気づけたので大丈夫だったのかなと。

**まぁ利用者ほぼ０名のサービスなので、サービス影響なんてないんですけど。**

多分この経験は、そのうちどこかで活かされるはず・・・。
ちなみに storage の使用量は劇的に減りました😇

![Screen Shot 2021-01-08 at 23.24.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39090/6880abf0-5b72-a6b2-0a10-2e054f353611.png)

# 追記（2021/01/16 22:26）

@junpayment さん、@kiyoshiro さんからコメント頂きました。
ありがとうございます。

実際の functions で実行されるコンテナイメージは GCR にあるようで（そりゃそうですよね）、storage のデータが消えても functinos の実行には影響ないようです。
functions の deploy 時に、必ず現在実行されてる functions を削除した上で deploy するような script を書けばいいかなーと思ったんですけど、firebase の cli に削除のコマンドがないので、
修正あろうがなかろうが、storage のライフサイクルよりも短いサイクルで無駄に deploy し続ければ防げるのでは・・・？と思ったんですけど、deploy 時に storage を参照する条件も、storage が更新される条件も調べてないので、うまくいくかわかりません😇
そのうち調査する・・かも・・。

# 終わりに

次回は @lemonade787 さんの記事になります。
お楽しみに！