Firestoreの稟議を出したときに考えたこと
これはなに
あけましておめでとうございます。レバテック開発部のもりたです。
今回はFirestoreの稟議出しをしたときに考えたことを記事にしました。もりたの担当プロダクトではFirestoreを使っているのですが、先日、色々あって利用料の稟議をだし直しました。もりたはFirestoreについても稟議についてもな〜〜んも知らん状態だったので、Firestore×稟議初見勢として今後Firestoreの稟議を出すみなさんのために情報を残しておこうと思います。
もりたの考えたこと
稟議提出の作業内容
こんな流れで考えました。
(以降スラスラ書いてますが実際は上長にツッコミを入れられながら進めています)
アウトプットの定義と収集したい情報の整理
これは各社色々とやり方あると思いますが、最終的な稟議で必要なのは以下の2点です。
- 料金予測(年度内分など)
- その根拠
長期の料金予測については、過去の料金実績をベースに作成し、その根拠となる情報を添える感じになります。
というわけで「過去の料金実績」と「根拠」をとりにいきます。
情報を集める
では料金の情報と根拠を集めていきましょう。
まず過去の料金実績ですが、Firebaseの請求ページでプロジェクトごとの請求額がわかります。具体的には以下の箇所から。
サイドバーの設定歯車を押下 > 使用料と請求額 > 概要タブを押すと...
こんな感じのグラフが見れる
プロジェクトの費用がわかりやすくグラフで示されています。また、当月分であれば、Firestoreのどんな種類のクエリに対して請求が来ているのかも詳細にわかります。
次にその裏付けとなるデータを探します。
これはどういった用途でFirestoreを使っているか次第なのですが、読み取りなのか書き込みなのかなどのおおまかな原因は先ほどの請求の詳細ページで判断がつきます。今回はほぼ読み取りだったため、担当プロダクトのコードを読んでFirestore読み取りに関する処理を追いかけ、どんなどんな操作やデータを根拠に料金がかかっているのか把握しました。
提出する
最後に、月別の予測額にその根拠になるメッセージ通数を添えた表を作成し、提出しました。
必要な情報が手元になかったり、論理の飛躍があると、この情報を整理するところがやりにくくなります。今回も最初に手をつけたときは曖昧なまま提出資料を作ろうとして時間がかかり、上長にも違うそうじゃないと突っ込まれました。ただ、指摘を受けた後は必要な情報がクリアになり、すらすらと進めることができました。
混乱ポイント
続いて、作業をする中で戸惑った点をいくつか挙げます。
Firestore請求ページが分からない
請求ページの見方で戸惑いました。
請求ページは「プロジェクトの費用」セクションと「無料枠と使用量」セクションがあります。この「無料枠と使用量」セクションでは、使用量に対してどこまでが無料枠なのかが確認できるのですが、ここだけでは本当に無料枠が適用されているかどうかは判断できないようです。[1]
赤下線部分を見ると無料枠が適用されているように見えるが、実際は請求が来ている
なおこの無料枠の額と同じ額がGCPから請求されています。AppEngineという名目で請求が来ていますが、これはFirestoreがAppEngine上で動いているからのようです。
ドキュメント指向データベースが分からない
GCP公式に料金の試算ページがあるんですが、試してみると全然違う数字になってしまい困りました。
ここがわからなかった理由はシンプルにドキュメント指向データベースの知識が足りなかったためです。
GCP公式ドキュメントにある「Firestoreの料金」ページでは「読み取り、書き込み、削除を行うドキュメントの数」に対して課金されると記載があります。この文章を読んだとき、なんとなくクエリの発行回数か…? と考えてしまいました。
ただ、この「ドキュメント」というのはドキュメント指向データベースにおける用語で、RDBの文脈でいうならレコードのようなものを指しています[2]。
金額増加の理由が分からない
稟議出し直しってことはまあ要するに過去に申請した予算を超過したわけですが、その要因に心当たりがなく困りました。
結局は思わぬ機能で請求が来ており、それを見逃していました。この機能で請求くるかな…? と推測することも大切ですが、Firestoreには計測可能なログがあるため、それを根拠にすべきだなと考えています。(後述します)
こうしたい - 監査ログ入れて計測しよう
稟議を出すときの基本的な姿勢として、現状としてのおおまかな予測で出しつつ、それを上回る機能リリースがあるなら適宜出し直すというのがいいのかなと思います(本来は利用予測などの試算をした上で稟議を出すものらしい)。
そして、リリースした機能がどれくらいの料金的な影響を出すかというのは、監査ログによって確認可能です。監査ログについての記事はすでにインターネットにあるのでそちらをご参考いただきたいのですが、これで機能リリース前後の利用傾向を追いかけて、それを元に料金をだすのが良さそうかなと考えています。
おわりに
今回はFirestoreの稟議をあげてみました[3]。
着手時はFirestoreとFirebaseの違いも分かんなかったですし、FirebaseとCloudflareも混ざっていました。Firebase! あ〜hono作った人のいるところね!! って思ってました。
ただ、幸いにもFirestoreがドキュメント指向データベースだったおかげで興味を持って調べることができました。これを機にNoSQLをつかってなにか作りたいな〜〜と思っています。
参考情報
-
Firestoreの料金
- 公式の料金解説ページ。かわいい動画付き
- Firebaseを利用しているプロジェクトにてApp Engineで費用が発生している謎
- 全部見える!GCP ロギングで見るFirestoreのアクセス履歴
Discussion