Cloud Functions for Firebaseを使用した時に、Cloud Storageのストレージ容量が圧迫される問題について調べた

Firebaseのいくつかのサービスを使用していたときに、ふと見に覚えのないCloud Storageのストレージ容量があることに気付きました。ちょっとくらいなら良いと思っていましたが、使用容量を見てみると10GB近くになっており、無料枠を超えてしまっていました。

適切なサービスの利用に関しては対価が支払われるべきと考えているため、無料枠を超えること自体は問題はなかったのですが、まったく見に覚えのない状態だったため、原因を把握すべく調査した結果と解決方法を紹介します。

Cloud Storageが圧迫されてしまう原因

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

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

Cloud Functionsのしくみ的に最新バージョンのイメージレイヤだけを残して、使用していないイメージレイヤは自動で削除してほしいものですが、執筆現在はそのような機能はありません。

調べてみたところ、Cloud Storageのライフサイクル機能を使用することで、Cloud Storageの圧迫を解消できることがわかりました。¹

FirebaseにアサインされているGoogleアカウントでGCP Consoleにログインします。
Firebaseのプロジェクトと同じ名前のプロジェクトが存在するので、対象のプロジェクトを開きます。
メニューからCloud Storageのページに遷移します。
リージョン.artifacts.プロジェクト名.appspot.comのバケットの詳細画面に遷移します。
- 複数リージョンにまたがってCloud Functionsをホスティングしている場合は、リージョン数分バケットが用意されています。
[ライフサイクル]タブから、[ルールを追加]を選択します。
アクションとして[オブジェクトを削除]を選択します。
オブジェクト条件として[年齢]を選択し、3日とします。
- ここでは3日としていますが、ご自身の都合に合わせて日付を変更してください。
[作成]ボタンを押したら完了です。

ただ、注意点として、この方法はDockerの各レイヤのライフサイクルがデプロイの頻度や内容によって変わってくるため、デプロイ時にレイヤが見つからなくなりデプロイに失敗することがあります。

その場合は、仕方ないのでリージョン.artifacts.プロジェクト名.appspot.comのバケットを削除します。 Cloud Functionsのデプロイを実行することで、バケットが再作成されます。

Cloud Functionsの利用に関して運営は今後のロードマップを公開しました。²

Cloud FunctionsのNode.js 8系のランタイムが非推奨となる
- 2021年2月15日以降はデプロイできなくなる
- すでにデプロイ済みの場合は、2021年3月15日以降にFunctionが実行されなくなる
Cloud FunctionsのNode.js 10系以上のランタイムを使用する場合はBlaza（従量課金）プランでのみ使用可能となる
- 2020年6月22日までにBlazaプランに変更する必要があった

おそらくですが、Cloud Storageはもともと課金プランでないと使用できない制約があったため、Cloud Storageを使用するようになったCloud Functionsにも課金プランが必要になったのかと思います。

Firebase Consoleを見ても、この原因にたどり着くことはできないのがやっかいでした。本来必要なくなったDockerイメージのレイヤデータは、Cloud Functions側でよしなに削除されてほしいですが、機能として提供されていないため、一工夫必要な状態です。

もし同じような状態で困っている方の参考になれば幸いです。