知っておきたいFirebase の色んな上限について
•
1 like•2,297 views
2020/11/21 Android Bazaar and Conference Diverse 2020 Autumn https://sites.google.com/view/abcd2020a/ GDG Shikoku / Sansan, Inc. Kenichi Tatsuhama
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 知っておきたいFirebase の色んな上限について
Similar to 知っておきたいFirebase の色んな上限について (20)
More from 健一 辰濱
More from 健一 辰濱 (20)
知っておきたいFirebase の色んな上限について
- 1. 知っておきたい Firebase の⾊んな上限について 2020/11/21 Android Bazaar and Conference Diverse 2020 Autumn GDG Shikoku / Sansan, Inc. Kenichi Tatsuhama
- 2. About me ⾠濱健⼀（Kenichi Tatsuhama） • @tatsuhama50 • Sansan, Inc. Android developer • GDG Shikoku Organizer • 徳島県神⼭町在住
- 3. Firebase Summit 2019 @ Madrid Firebase Summit 2019 in Madrid に参加してきました。 https://buildersbox.corp-sansan.com/entry/2019/10/04/110000
- 4. Firebase Summit 2020 @ Online 先⽇ 10/27, 28 に開催されました。 セッション別動画も上がって きているので要チェック！
- 5. Firebase ハンズオンを開催 • 2019/04 愛媛⼤学 • 2019/12 Google 東京オフィス • 2020/02 ⾹川 • 2020/03 徳島（オンライン） GDG Shikoku を Check !!
- 6. Firebase とは？ • Google が提供する、優れたアプリを開発し、ユーザーベース を拡⼤し、収益を⾼めるためのツール。 • インフラ構築に⼿間取ることなくビジネスを収益化し、ユー ザーにとっての利便性に集中できます。
- 10. 余談 • JSTQB というテスト技術者資格を 持ってます。 • そんなわけで、 Firebase の境界値テスト！
- 11. 本セッションのゴール • Firebase の各種上限を知る • 上限を超えるとどうなるのか知る（※） • 上限を回避する⽅法を知る ※2020年夏頃の調査です。変更になっている可能性があります。 （特にドキュメントに書かれていない挙動）
- 13. プロジェクト数 • プロジェクトとは、1アカウントが持てる Firebase の最上位の エンティティ • プロジェクトには、iOS アプリ、Android アプリ、Web アプリ や、それぞれの本番、ステージングなどのアプリも含む事がで きます。 プロジェクト
- 16. プロジェクト数 • 対策 • 不要なプロジェクトは削除しよう（物理削除は30⽇後） • 必要ならば、上限緩和申請をしよう
- 17. イベント数
- 18. イベント数 • 600件送ってみた • 実⾏時エラーにはならない • 遅延送信されるし、⾃分の端末が送っていないイベントは把握不能 • Logcat にもエラーは出ていない
- 19. イベント数 • Firebase dashboard 上 • 推奨イベント（プリセット）x3 • ユーザ定義イベント x500
- 20. イベント数 • BigQuery 上のイベントのユニーク数を出してみた ← BigQuery 上には記録されてる？ と思ったら、600 個もなかった。。。
- 22. イベント数 • event_name = “error” is 何？ ← ！？ イベントプロパティに firebase_error : 8
- 23. イベント数 • BigQuery 上では エラーが記録され ていた！ • （クライアント上 で上限に達してる かは即時判断でき ない。 ） https://firebase.google.com/docs/an alytics/errors?hl=ja
- 24. イベント数 • 対策 • ある程度イベントを丸めてプロパティで区別する • 課⾦しても変わらない • 例） open_xxx_screen, open_yyy_screen という2つの別のイベント • open_screen ( screenName : xxx) • open_screen ( screenName : yyy) のように screenName というプロパティで区別する • 超過してたら、どうすることもできない…？（未調査） • 最悪の場合、プロジェクト再作成！？（ガクブル）
- 26. ユーザプロパティ • 100 件付けてみた • 実⾏時エラーにはならない • Logcat にもエラーは出ていない
- 27. ユーザプロパティ • 超過分はエラーではなく、 無視される • BigQuery を⾒てみた • プリセット x 3 • カスタム x 25 しか記録されてない • さきほどの firebase_error は記録されてなかった 繰り返し要素 （REPEATED） …
- 28. ユーザプロパティ • 対策 • 欲張らない • 課⾦しても変わらない • 感想 • イベント数超過はエラーとして記録されるのに、ユーザプロパティ数の超過 はエラーじゃないんですねw • 補⾜ • イベント実⾏時のユーザプロパティであり、最新のユーザプロパティではな い • 参照ではなく、イベントごとにそのときのユーザプロパティのコピーが保持 されている
- 29. ホスティング
- 30. ホスティング
- 31. ホスティング • 上限：10G まで（のはず） • 振る舞いは 1G？ • 1G を超えてデプロイできた • アップグレードの警告が出る
- 33. ホスティング • 対策 • 課⾦する • ⼤きなリソースファイルは、Storage に配置 • 数回分の履歴も含めた容量なので、実質 100 MB 程度を上限とみてお いた⽅が良い • 履歴削除ツールがあるみたい • https://gist.github.com/mbleigh/5be2e807746cdd9549d0c33260871d21
- 34. ストレージ
- 35. ストレージ • 上限：5GB • Extension 等 の容量も加算 される • でもデプロイ できたw • アップグレー ドを推してく る
- 36. ストレージ • 対策 • 課⾦する • 画像の場合、リサイズして保存すれば容量の節約になる • Firebase Extensions の Resize Images が便利 • https://firebase.google.com/products/extensions/storage-resize-images
- 37. FCM のスケジューリング
- 38. FCM のスケジューリング • Firebase Cloud Messaging（プッシュ通知）の定期送信スケ ジュールは 10 件まで
- 39. FCM のスケジューリング • 対策 • iOS / Android で分けてしまうと数を⾷うので、⽂⾔を揃える事ができ るなら揃えて、数を節約する • 同じ OS でも体験版 / 有償版など複数のアプリがある場合も同様 • ⾔語ごとに1つの定義を消費してしまうのが難点… （Firebase In-App Messaging はローカライズ機能を持っている） • ※課⾦しても増えない
- 40. Remote Config
- 41. Remote Config • サーバ上に変数を定義 • クライアントの振る舞いをリリースなしに変更できる • 全ユーザに同じ値を割り当てるだけではなく、割合や属性を指 定して異なる値を割り当てることもできる • ユースケース • A/B テスト • メンテナンスモードのフラグ • パーセンテージロールアウト （機能の段階的公開）
- 42. Remote Config • fetch 間隔 • Firebase 上の定義値を読みに⾏く間隔 • デフォルトでは 12h • 変更できるが、端末ごとの 1h 以内の呼び出し回数制限がある → DB のように、更新頻度が⾼く即時性が⾼い場合には不向き • でも、リアルタイムで伝播させる⽅法もある （更新頻度が低い場合に限る）
- 43. Remote Config • 更新をリアルタイムで伝播する（β） • https://firebase.google.com/docs/remote-config/propagate- updates-realtime FCM との合わせ技で、 ⼀時的に fetch 間隔を 0 にする
- 44. Remote Config • 他にも… ホスティングを使って json をデプロイするという⽅法もアリ かも知れない ※但し、全ユーザ同じ値になる （or クライアントサイドで乱数で json の参照先を振り分け）
- 45. Firestore • いわゆる DB • NoSQL でスキーマレス • リアルタイム更新が売り • Document / Collection / Data という構造を持つ
- 46. Firestore の無償枠 • https://firebase.google.com/docs/firestore/quotas • DAU が数千だと、無償では運⽤しきれないかも？
- 47. Firestore Document への書き込み たったの 1回/s！！ ← Bluk も 500件 なのは少々⾟い…？
- 48. Firestore Document への書き込み • カウンターのアンチパターン • 投稿の「いいね」数をドキュメントのフィー ルドに持ち、Transaction 内で値を読み込ん でインクリメントして保存 ←1秒間に1回しか更新できない！ ↑例
- 49. Firestore Document への書き込み • 対応 • カウンタをサブコレクションに分散する（sharding） • ランダムに shared を選んでインクリメント • 読み取り時は shard 数の合計を出す ======= shard
- 50. Firestore Document への書き込み 分散カウンタの制限事項 • Shard 数が少ない • 失敗＆再試⾏でパフォーマンス劣化 • Shard 数が多い • 読み取り時のパフォーマンス劣化 • 読み取りコスト（費⽤）の増加
- 51. Firestore Document への書き込み 分散カウンタの制限事項 • Shard 数が少ない • 失敗＆再試⾏でパフォーマンス劣化 • Shard 数が多い • 読み取り時のパフォーマンス劣化 • 読み取りコスト（費⽤）の増加 Firebase Extensions の Distributed Counter を使えば、サクッと実現できる https://firebase.google.com/products/extensions/firestore-counter
- 52. Firestore Document への書き込み • array のアンチパターン • 例）投稿へのコメント ←1秒間に1回しか 更新できない！
- 53. Firestore Document への書き込み • 対策 • Document 内のコレクション（≠プロパティ）に保持する 更新：1回/s 更新：500回/s
- 54. Firestore まわり • 上限を意識したデータ設計が必要 • 転送量や参照回数を減らすデータ構造 • データの持ち⽅など、RDB にはないノウハウが必要になる • 課⾦しても変わらない
- 55. 余談：CAP 定理 • ブリュワーの定理とも呼ばれ、分散コンピュータシステム（ク ラウドシステム）のマシン間の情報複製に関する定理。 CAP のうち、3つを同時に満たすことはできない。 • C：⼀貫性 (Consistency) • A：可⽤性 (Availability) • P：分断耐性 (Partition-tolerance) • Firebase では、A（可⽤性）, P（分断体制） がサポートされ ているので、C（⼀貫性）は妥協する必要がある https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
- 56. まとめ • Firebase には、さまざまな上限が存在する • 課⾦すればひき上がるモノもあるし、そうでないものもある • 要件によっては、上限を⾒据えた設計が必要 • 上限と上⼿くつきあう必要がある • 場合によっては、上限を突破しても使えそう • 意外と無料/有料の境界もザル • （性善説運⽤かな？ゴメンナサイ…確認できたので消します。） • 最悪の場合、プロジェクトを作り直し？
- 57. Letʼs enjoy Firebase !!