Firebase realtime databaseの課金が増えた問題 – 開発日記(91) - アイディア・レーン開発ブログ (Flutter Web)

2024/04/26

このところDBの利用データ量がどんどんデータが増えている。

現時点では自分しか使っていない（ユーザ１名）し、データとしてはテキストしか入れていないのに、ついに1日で200MBのダウンロード量に達した。

どうも直感と合わない。可能性としては下記だろうか

Firebaseの管理コンソールのアクセスが影響している？
- FirebaseのRealtimeDBの管理コンソールを開いたまま作業したりドキュメントが更新されると結構データを食うのかも！？
データ数の多いキャンバスが影響している？
- 一番アイディアが多いキャンバスはアイディア数265。ダウンロードすると51KBのJSONになった。
- しかしこれを100回読んだとしても5MBだ。ダウンロードしたJSONファイルはスペースも多数含むので、DB上でのやりとりのデータ量は実際はもっと小さいはず。
気づかないうちにプログラム内で何かを読み込んでいる？

いくつか可能性を考えてみたものの、どれが原因かの特定が難しい。
ソフトの操作をしながらリアルタイムでDBの使用量が分かれば特定しやすいのだが……そういうことはできないようだ。

Firebase上のタイムゾーンはGMT-7と書かれており、日本はGMT+9。
マイナス16時間ということは、Firebaseの4/25 0:00 は日本の4/25 16:00か。
毎日16:00が切り替えと思えば良いだろう。

ただ１日の切り替え基準が分かったところで、データ量の表示がリアルタイムに反映されるわけでは無く、切り分けが難しい。

さらに調べると、Google Cloud Monitoring ならもう少し情報が見られることがわかった。

早速設定してみる。しかしこれ18個ある指標をウィジェットで一つずつちまちま追加するしか無いのだろうか？テンプレートを用意して欲しい。面倒……。

このグラフを見ていると、課金対象のグラフと、DBのupdateのグラフの形が同じに見える。listenはほとんど無いし、getの形とも違う。ということは、realtime DBのupdateも課金に入ってしまうのだろうか？無料だと思っていたが違うのか？

使用量の多かった時間を拡大してみる。左下のグラフと右上のグラフがポイント。左下のグラフは、右上のget(緑)とは必ずしも一致しておらず、むしろupdate(薄紫)が近い。getとupdateの合成に見える。

このグラフはDBアクセスから2～3分くらいで反映されるので、まあこれならなんとか仮説・トライ・検証ができそうだ。

それで試したところ下記が分かった。

この調査で気になる事があった。アイディアが多いキャンバスで、アイディアの位置を動かした（内部的にはインデックス値を変更した）だけで3KB！？どうしてだろう

試しに188個アイディアがあるレーンの一番上に、別レーンからアイディアを移動。インデックスの変更が189回かかるはずだがどうなるか。（操作としては下記の「テスト」を追加しただけ）

なんと65KB！これでUndo/Redoなどしていたらすぐに650KBなどになってしまう。
とはいえ、逆に言えばその程度。100回やっても6MB程度のはず。

よく見ると65KB”/s” となっている。秒間？？？実際の転送量とは違うのだろうか。謎が深まるばかり。

しかたなく、Realtime Database billing helpに問い合わせをした。
英語での問い合わせだし、スクショを貼ったりして、これまた時間を使う。
直接の開発以外で時間取られることがとても多い。

課金問題以外では、細かな改善をいくつか

※開発日記は当時の記録をもとに作成し、必要に応じて加筆・補足しています

この記事はアイディア整理ソフト「idea Lane」の開発記録です

↓どなたでも、ユーザ登録だけで無料ですぐに使えます↓
テキストベースの思考整理ツール「idea Lane」