Firebase
ActionsSDK
GoogleHome
dialogflow

GoogleHomeアプリの無料運用のためのコスト計算とスケール感

こんにちは。

GoogleHomeアプリを公開したときに、無料で運用したいなーと思ってfirebaseやDialogflowのコストを計算をしました。
計算した結果、Dialogflowを利用するとユーザー数がかなり限られてしまいそうだと分かりました。
特に常用ユーザーに1日に何度もアクセスされるようなアプリにおいては、現実的ではない数字(🤯)が出てしまい非常に驚きました。

QiitaにGoogleHomeアプリのコスト情報があまりなかったので、今回の調査結果を自分のまとめがてら記事にしました。

Lv1.関連サービスの簡単なコスト感🤔

Dialogflow料金と制限

Dialogflow価格

  • 基本的に無料
    • ただしリクエスト量に制限あり

リクエスト量の制限について

  • ボトルネックとなりそうな制限
    • Audio requests per month:15,000
      • 1カ月30日運用として15000/30 = 500/day
      • 常用アプリでは500人が壁。スマフォのアプリと違って、無料運用では利用人数の最大値が決まってしまう。
      • 計算例)1日100人が利用するとして 500/100 = 5音声/人day

ActionsSDKは無料?

Actions on GoogleのAgentとして、Dialogflow以外にActionsSDKが利用できます。
こちらの制限と料金について調べたのですが、見つかりませんでした。

公式情報

  • priceについて記載なし。制限なし?
  • 複雑な対話が無いようなシンプルなアプリの場合は、ActionsSDKの利用を検討すると良いかもしれません。
    • 自分はwelcomeインテントだけのアプリでしたので、ActionsSDKに移行しました。

firebase functionsの料金と制限

Firebae Sparkプラン

  • ボトルネックとなりそうな制限

    • 呼び出し:12.5万/月
      • 1カ月30日運用として125000/30 ≒ 4166呼び出し/day
      • 後述しますが、cloud functions quotaでの表示上では 5000呼び出し/dayとなっています
      • 計算例) 1人が1アプリ1日10回呼び出しとすると、500人まで対応
    • 処理内容によっては処理時間のGB秒・GHz秒がボトルネックになり得ます
  • Firebase FunctionsでのCPU/memory設定

    • CPUは明確な記載箇所がない
    • MemoryはFirebase consoleのFunctions->ダッシュボードに表示されている関数のオプション->使用状況の詳細な統計情報のページにメモリが記載されています
      • メモリは256MBのようです。これが処理内容によって自動スケールされるかは不明です。
      • Cloud Functionsの料金表によると256MBとペアのCPU割り当ては400MHzとなっています

04.png

05.png

firebase Realtime Databaseの料金と制限

Firebae Sparkプラン

  • ボトルネックとなりそうな制限
    • GB ダウンロード済み:10 GB/月
      • 1カ月30日運用として10240(Mbyte)/30 ≒ 341(Mbyte)/day
      • 他に比べてある程度余裕がある。もちろんアプリ次第ではある。
      • 計算例)firebase function1回呼び出しに付き 10kByte Donloadが発生、1日10回呼び出される場合:3491人まで対応可能

Lv2.関連サービスの利用状況の確認方法😯

Dialogflowの利用状況

  • Dialogflowのconsole->Analyticsより利用状況を確認できる
    • 確認できるのはセッション数とセッションあたりのクエリ数のみ
      • ここでいうクエリはDialogflowの制限にある「Audio request」ととらえていいのか若干不安

06.png

firebase functionsの利用状況

  • firebaseのconsole->Functions->利用状況タブのView Quotaより詳細な利用状況を確認できる
    • View quotaが分かりにくい場所にある

07.png

  • Google Cloud Platformのダッシュボードが表示され、Google Cloud Functions APIの詳細な利用状況が表示される
    08.png

  • 影響がありそうな各種上限値

    • Read
      • Read requests per day : 10000
      • Read requests per 100 seconds per user : 500
      • Functions invocationsと同等。ただしコンソールでのログ表示等でもカウントが増えると思われる
    • Write
      • Write requests per day : 1000
      • Write requests per 100 seconds per user : 20
      • functionsの新規作成、修正時にカウントが増える。アプリ運用時はあまり気にしなくてよさそう。
    • Function invocations
      • Function invocations per day : 5000
      • Function invocations per 100 seconds : 50
      • 料金表にあった呼び出し上限値の日割り値がこれと思われる
    • CPU allocation in function invocations
      • CPU allocation in function invocations per day : 1,500,000
      • CPU allocation in function invocations per 100 seconds : 100,000
      • GHz秒?単位はmillisecondsと思われる
    • Incoming socket traffic
      • Incoming socket traffic per day : 1,073,741,824
      • Incoming socket traffic per 100 seconds : 20,971,520
      • 上り通信量。単位はbyteと思われる
    • Outgoing socket traffic
      • Outgoing socket traffic per day : 1,073,741,824
      • Outgoing socket traffic per 100 seconds : 20,971,520
      • 下り通信量。単位はbyteと思われる
    • Socket connections
      • Socket connections per day : 5000
      • Socket connections per 100 seconds : 50
      • 接続最大数。1接続時に1functionを実行するなら5000人が最大値。
    • DNS resolutions
      • DNS resolutions per day : 5000
      • DNS resolutions per 100 seconds : 5000
      • DNS解決。通常、1接続時に1カウントされる。しかし不自然に高いこともある。謎。
    • Functions build time in seconds
      • Functions build time in seconds per day
      • ビルド時間。アプリ運用時はあまり気にしなくてよさそう。

Firebase Realtime Databaseの利用状況

  • FirebaseのコンソールからDatabase->使用状況のタブで表示できる
    • 上限値が料金表通りの内容で表示されている。日本語表記でかなり見やすい。 09.png

Lv3.アプリモデル毎のユーザー最大数の検討😧

アプリ利用シーンを仮定して無料運用内でのユーザー最大数を検討する

仮定するモデル

  • アプリモデルA

    • モデル例:一週間の予定追加アプリ等
      • 利用頻度:週に1度だけ起動する
      • 応答回数:1回のアプリ起動で10回ユーザーとの応答が行われる
      • 処理負荷:軽い処理(0.5sec程度)を9回、重い処理(1.5sec程度)を1回行う
      • アクセス集中:集中しにくい
      • 通信量:音声10回分(10kbyte)×10
      • DB使用量:10Kbyteのデータを365日分
      • DBの更新:10kbyte
  • アプリモデルB

    • モデル例:ゴミの集荷予定アプリ等
      • 利用頻度:毎日起動する
      • 応答回数:1回のアプリ起動で2回ユーザーとの応答が行われる
      • 処理負荷:軽い処理(0.5sec程度)
      • アクセス集中:やや集中する。2時間の範囲。
      • 通信量:音声2回分(10kbyte)×2
      • DB使用量:10Kbyteのデータ
      • DBの更新:10kbyte
  • アプリモデルC

    • モデル例:タスク処理アプリ等
      • 利用頻度:1時間に4度起動する
      • 応答回数:1回のアプリ起動で1回ユーザーとの応答が行われる
      • 処理負荷:軽い処理(0.5sec程度)
      • アクセス集中:集中しにくい
      • 通信量:音声1回分(10kbyte)
      • DB使用量:10Kbyteのデータ
      • DBの更新:10kbyte

ユーザー1人がモデルアプリにアクセスした場合の数値

No. 項目 単位 A B C 計算式等
[1] 時間あたりの利用回数 回/h 1 1 4
[2] 1日の稼働時間 h 1 1 8
[3] 1日の利用回数 回/日 1 1 32 [1]×[2]
[4] 1カ月の稼働日 4 30 30
[5] 1カ月の利用回数 回/月 4 30 960 [3]×[4]
[6] 1回の音声リクエスト 10 2 1
[7] 1日の音声リクエスト 10 2 32 [6]×[3]
[8] 1月の音声リクエスト 40 60 960 [7]×[4]
[9] 1回のwebhook処理 10 2 1
[10] 1日のwebhook処理 10 2 32 [9]×[3]
[11] 1回のfirebase処理時間 s 6 0.5 0.5
[12] 1日のfirebase処理時間 s 6 0.5 16 [11]×[3]
[14] 1回のGB秒 GB秒 1.5 0.125 0.125 256(MB)/1024×[11]
[16] 1回のGHz秒 GHz秒 2.4 0.2 0.2 400(MHz)/1000×[11]
[17] 1日のGHz秒 GHz秒 2.4 0.2 6.4 400(MHz)/1000×[12]
[18] 1回の通信量 Kbyte 100 20 10
[19] 1日の通信量 Kbyte 100 20 320 [18]×[3]
[20] DB使用量 Kbyte 3650 10 10
[21] 1回のDBdownload量 Kbyte 100 10 10
[23] 1月のDBdownload量 Kbyte 400 300 9600 [21]×[3]×[4]

各種制限値における最大ユーザー数

  • 代表的な項目のみ
  • ボトルネックを太字化
大項目 中項目 制限値 A(人) B(人) C(人) 計算式等
Dialogflow Audio requests per day 1000 100 500 31 1000/[7]
Dialogflow Audio requests per month 15000 375 250 15 15000/[8]
Firebase Functions Function invocations per day 5000 500 2500 156 5000/[10]
Firebase Functions CPU allocation in function invocations per day 1500000 625 7500 234 1500000/1000/[17]
Firebase Functions Outgoing socket traffic per day 1073741824 10485 52428 3276 1073741824/1024/[19]
Firebase Realtime Database GB保存済み 1Gbyte 287 104857 104857 1*1024*1024/[20]
Firebase Realtime Database GBダウンロード済み 10GB/月 26214 34952 1092 10*1024*1024/[23]

分かったこと

  • DialogflowのAudio requests per monthは大きなボトルネック
    • モデルCパターンではDialogflow使用はアプリ公開・実用に適さない可能性あり
    • ただし、「Audio requests」=「Dialogflowのクエリ」であるかどうかは未確認な点は注意
  • 毎日1回程度利用されるアプリでは、無料運用だと200人程度規模感
  • ユーザーデータが多いアプリの場合は、Firebase Functionsの制限よりもFirebase Realtime Databaseの制限が先に引っかかることも十分ありえる

調査できなかったこと

  • Lv4.アクセス集中時の検討🤒
    • 待ち行列計算など
    • ざっくりはやりましたが、上記ボトルネックが先に引っかかるので深く追求しませんでした。

終わりに

実際に動くものの開発と違って、調べれば調べるほど現実が見えてくるのでぜんぜん楽しくなかったです…😰
とはいえ、アプリ公開するには必要なことなので悲しみながらも計算頑張っていきましょう。

数字などの間違っている点見つけた方は指摘いただけるとありがたいです。
ではまた。