Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Realtime Messaging with Firebase #phpcon2017
Search
Sota Sugiura
October 08, 2017
Technology
6
12k
Realtime Messaging with Firebase #phpcon2017
PHP Conference Tokyo 2017で発表しました。
Sota Sugiura
October 08, 2017
Tweet
Share
More Decks by Sota Sugiura
See All by Sota Sugiura
20220926_セキュリティチームの今_for_Drs._Prime_公開用.pdf
sota1235
0
42
再発防止策を考える技術 / #phpconsen
sota1235
10
3.5k
How to choose the best npm module for your team?
sota1235
9
450
Realtime Database for high traffic production application
sota1235
7
3.7k
Road to migrate JP Web as a microservice
sota1235
4
1.4k
インターフェース再入門 / Think Interface again
sota1235
6
10k
再発防止策を考える技術 #phpconfuk_rej
sota1235
1
1k
Update around Firebase #io18
sota1235
3
4.1k
Introduction for sonarwhal
sota1235
0
470
Other Decks in Technology
See All in Technology
オブジェクト指向CSSが叶えたかったことと、CSSのいま / The aims of Object-oriented CSS and the current state of CSS usage
shinkufencer
11
3.6k
AMLD 2024 - Build Your Own GPT
donlelef
1
260
「XX試験の環境作ってよ」と言われた時によく使うAWSのソリューションについて
bun913
0
120
KubeCon EU: Unlocking new Platform Experiences with Open Interfaces
salaboy
1
370
.NETの非同期戦略とUnityとの相互運用
neuecc
2
2.4k
Tohoku.Tech #1 「EC-CUBE/AWSの構築をChatGPTに相談してみました」by テンダ
jun2882
0
140
戦略的DDDを実践するための跳躍力 / OOC 2024
pictiny
6
4k
Azureコストは水道代/The_47th_Tokyo_Jazug
aeonpeople
3
360
家族アルバム みてねで直面してきた技術的負債 / MIXI KAG 2024
isaoshimizu
17
7.7k
バッチ処理のSLOをどう設計するか
rynsuke
7
560
期待しすぎずに取り組む両面 TypeScript
shozawa
2
300
任意コード実行の原理
ffri
0
170
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
13
3.7k
Unsuck your backbone
ammeep
661
56k
How To Stay Up To Date on Web Technology
chriscoyier
781
250k
A Modern Web Designer's Workflow
chriscoyier
689
190k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
111
35k
What's new in Ruby 2.0
geeforr
335
31k
Design by the Numbers
sachag
274
18k
Reflections from 52 weeks, 52 projects
jeffersonlam
343
19k
Art, The Web, and Tiny UX
lynnandtonic
288
19k
WebSockets: Embracing the real-time Web
robhawkes
59
6.9k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
58
14k
Embracing the Ebb and Flow
colly
78
4.1k
Transcript
Realtime Messaging with Firebase PHP Conference Tokyo 2017 @sota1235
悲報
Cloud Firestore launched! https://firebase.googleblog.com/2017/10/introducing-cloud-firestore.html
要約 Realtime Databaseの 次世代版が出たよ
今⽇日 10/8 ブログポスト 10/3
But Realtime Database is not dead https://firebase.googleblog.com/2017/10/introducing-cloud-firestore.html
But Realtime Database is not dead https://firebase.googleblog.com/2017/10/introducing-cloud-firestore.html
今⽇日の⽅方向性 • Cloud FirestoreとRealtime Databaseの違いを 最後に話します • Cloud Firestoreを使うとしても役に⽴立つ知⾒見見 に寄せました
Realtime Messaging with Firebase PHP Conference Tokyo 2017 @sota1235
About me • Sota Sugiura • @sota1235 • Mercari, Inc.
突然ですが…
こんな画⾯面 ⾒見見たことある⼈人
メルカリチャンネル • 今年年7⽉月にローンチした Liveコマース機能 • メルカリの⼀一機能 • 動画で売れる/買える https://www.mercari.com/jp/mercari-channel/
気になる⼈人はggってください 今⽇日は宣伝に来たわけではないので…
4⽉月下旬のこと P 「Liveコマース出したいんだよね」 ⋵
4⽉月下旬のこと P 「Liveコマース出したいんだよね」 ⋵ 「なるほど」
4⽉月下旬のこと P 「Liveコマース出したいんだよね」 ⋵ 「なるほど」 P 「7⽉月にリリースしたいんだよね」
4⽉月下旬のこと P 「Liveコマース出したいんだよね」 ⋵ 「なるほど」 P 「7⽉月にリリースしたいんだよね」 ⋵ 「なるほど???」
サービスとして求められていたこと w ڝ߹ΑΓૣ͘ग़͢ w ཁ݅ఆٛɺ։ൃɺ2"ɺϦϦʔε ·ͰΛϲ݄Ͱ࣮ݱ͢Δ ① 7⽉月上旬のリリース w ੈք؍Λ࣮ݱ͢ΔΪϦΪϦΛ
w ·ͣಈ͘ͷΛੈʹग़͢ ② 最⼩小機能で動くものを
サービスとして求められていたこと w ڝ߹ΑΓૣ͘ग़͢ w ཁ݅ఆٛɺ։ൃɺ2"ɺϦϦʔε ·ͰΛϲ݄Ͱ࣮ݱ͢Δ ① 7⽉月上旬のリリース w ੈք؍Λ࣮ݱ͢ΔΪϦΪϦΛ
w ·ͣಈ͘ͷΛੈʹग़͢ ② 最⼩小機能で動くものを ʢສμϯϩʔυɺҰ ສग़͞ΕΔτϥϑΟοΫ ͷΞϓϦͰͳ͘ʣ
技術的に求められていたこと ಈը৴ࢹௌػೳ αʔϏεͷ৺ଁͱ ݴ͑Δػೳ
技術的に求められていたこと ಈը৴ࢹௌػೳ ϦΞϧλΠϜ௨৴ ϥΠϒײΛ͓٬͞·ʹ ͓ಧ͚͢Δ
技術的に求められていたこと ಈը৴ࢹௌػೳ ϦΞϧλΠϜ௨৴ ߴෛՙ αʔϏεͷεέʔϧͱ Մ༻ੑΛݟਾ͑Δ
ロードマップ ཁ݅ఆٛ ݟੵΓείʔϓܾΊ 5⽉月 5⽉月中旬 7⽉月 ։ൃ ಈըपΓϦΞϧλΠϜ௨৴ 2"
ϦϦʔε
ロードマップ ཁ݅ఆٛ ݟੵΓείʔϓܾΊ 5⽉月 5⽉月中旬 7⽉月 ։ൃ ಈըपΓ1VTI௨৴ 2"
ϦϦʔε スケジュールがかなりタイト
締切 vs ⼯工数 • チームにはAPIエンジニア2⼈人、iOS/Android1⼈人 ずつ • 動画基盤やサーバPush基盤のノウハウは0 • 1から全部完成させようと思ったらとても2ヶ⽉月で
は厳しい • しかしこのサービスは早く出すことに何よりの意 味があった
どう実現するか
なるべく作らない • 使えるもの(クラウドサービス)を使い倒す • Microserviceとして作らない • 既に持っている資産を再利利⽤用する • スコープを削れるだけ削る •
サービスコンセプトを追求する
利利⽤用したクラウドサービス ಈը৴ࢹௌػೳ ϦΞϧλΠϜ௨৴ ߴෛՙ ċ 㡿ކ
利利⽤用したクラウドサービス ಈը৴ࢹௌػೳ ϦΞϧλΠϜ௨৴ ߴෛՙ ċ 㡿ކ 今⽇日のお話
About Firebase Realtime Database
Firebaseとは • Googleの提供するBaaS • モバイルに⾮非常に特化している https://firebase.google.com/?hl=ja
Firebase Realtime Database • Firebaseの機能の1つ • JSON形式のデータの永続化 • ClientからリアルタイムにデータをSubscribeできる •
⼤大量量のClientにも対応 • 10万接続 / 秒間1000回の書き込み
Subscribe Data { "messages": { "1": { "text": "hello, firebsae",
"user": "sota1235" } } }
Subscribe Data Subscribe /messages { "messages": { "1": { "text":
"hello, firebsae", "user": "sota1235" } } }
Subscribe Data { "messages": { "1": { "text": "hello, firebase",
"user": "sota1235" }, "2": { "text": "hello, phpcon", "user": "phper" } } } Subscribe /messages New data
Subscribe Data { "messages": { "1": { "text": "hello, firebase",
"user": "sota1235" }, "2": { "text": "hello, phpcon", "user": "phper" } } } Subscribe /messages New data New data
Even if many clients { "messages": { "1": { "text":
"hello, firebase", "user": "sota1235" }, "2": { "text": "hello, phpcon", "user": "phper" } } }
Not Only Database feature • 認証機能 • Facebook, Twitter, Custom
Auth, etc… • Rule for each tree • Permission • Validation
Rule • JSON形式で定義できる • JSON treeに対して細やかな制御ができる • Read/Write Permission •
Validation • Adminユーザは全Ruleを無視できるので注意
{ "rooms": { "1": { "messages": { "1": { "text":
"hello, php", "user": "sota1235" } } } } } 例例えばこんなJSON
{ "rooms": { "1": { "messages": { "1": { "text":
"hello, php", "user": "sota1235" } } } } } 例例えばこんなJSON νϟοτϧʔϜΛදݱ
{ "rooms": { "1": { "messages": { "1": { "text":
"hello, php", "user": "sota1235" } } } } } 例例えばこんなJSON ෦͝ͱͷVOJRVFͳ*%
{ "rooms": { "1": { "messages": { "1": { "text":
"hello, php", "user": "sota1235" } } } } } 例例えばこんなJSON νϟοτϧʔϜͷ ίϝϯτҰཡ
Ruleを設定してみる
{ "rules": { ".write": true, ".read": true, ".validate": "validation rule"
} } Ruleの基本⽂文法
{ "rules": { ".write": true, ".read": true, ".validate": "validation rule"
} } Ruleの基本⽂文法 ① おまじない
{ "rules": { ".write": true, ".read": true, ".validate": "validation rule"
} } Ruleの基本⽂文法 ① おまじない ② Read/Write 権限
{ "rules": { ".write": true, ".read": true, ".validate": "validation rule"
} } Ruleの基本⽂文法 ① おまじない ② Read/Write 権限 ③ Validationルール
例例. 意図しないKeyの追加 { "rooms": { "1": { "messages": { "1":
{ "text": "hello, php", "user": "sota1235" } } } } } • 意図しないJSON key を追加させたくない • rootにはroomsだけ⽣生 えてて欲しい
例例. 意図しないKeyの追加 { "rooms": { "1": { "messages": { "1":
{ "text": "hello, php", "user": "sota1235" } } } }, "extra": { "msg": "pwned" } } • 意図しないJSON key を追加させたくない • rootにはroomsだけ⽣生 えてて欲しい • こういうのを追加させ ない
{ "rules": { ".write": false, "rooms": { ".write": true, ".read":
true } } } 例例. 意図しないKeyの追加
{ "rules": { ".write": false, "rooms": { ".write": true, ".read":
true } } } 例例. 意図しないKeyの追加 Tree最上部への書き込みを 許容しない
{ "rules": { ".write": false, "rooms": { ".write": true, ".read":
true } } } 例例. 意図しないKeyの追加 Tree最上部への書き込みを 許容しない “rooms”配下への あらゆる書き込みを許可する
{ "rules": { ".write": false, "rooms": { ".write": true, ".read":
true } } } 例例. 意図しないKeyの追加 Tree最上部への書き込みを 許容しない “rooms”配下への あらゆる書き込みを許可する ͷ3VMFΑΓ5SFFͷ3VMF༏ઌ͢Δ
Ruleの活⽤用例例 • 全Treeへの読み書き制御 • Validation処理理 • 認証/認可の制御 • 認証を管理理するTreeを⽤用意し、そこに存在し ないuser_idの書き込みを弾く、なんてこと
もできる
Ruleの適⽤用 • GUI or REST APIで⾏行行う • REST APIでの管理理がおすすめ
Realtime Databaseを どこで使うか
サーバPush⽅方式のデータ全て
サーバPush⽅方式のデータ全て ↓ ライブ感を演出するもの全て
ライブ感を演出するもの ↓ 即反映されて欲しい情報
ライブ感を演出する要素 • コメント • いいね • 視聴者数の変動 • 商品周りのメッセージ
ライブ感を演出する要素 視聴者数 コメント いいね 商品リスト 更更新
ユーザに⾒見見せないもの • ライブ終了了通知 • 商品リスト更更新通知 • その他メタ情報
Architecture
アーキテクチャ
アーキテクチャ 順番に解説していきます
Step to use Realtime Database
Step 1. スキーマ設計 2. Rule設計 3. Read/Write実装 4. スケーリング
1. スキーマ設計
とにもかくにもスキーマ設計
スキーマ定義のコツ • Subscribe側を意識する • ⾮非正規化したほうが場⾯面もある • 後⽅方互換性を意識する • バージョンアップした時に困らない構成を
{ "lives": { "1": { "messages": { "1": { "user":
"sota1235", "image": "hoge.png", "text": "hello" } }, "notifications": { "buy_item": { "text": “sota1235さんが商品を購⼊入したぞい" } } } }, "alive_lives": { "1": true, "2": false } } メルカリチャンネルの例例(⼀一部略略)
あれ?配列列がないけど… • Realtime DatabaseのJSONで配列列は扱えない • 特定のnodeにaddすると⾃自動でunique IDが振 られる messagesにaddして ⾃自動で振られたID
Q. スキーマレスだけど、 どうやってスキーマ縛るの? Aを Q&A
Q. スキーマレスだけど、 どうやってスキーマ縛るの? A. Ruleを使います Q&A
2. Rule設計
Ruleによるスキーマ定義 • Realtime Databaseにスキーマという概念はない • データは⼀一枚岩のJSON • ドキュメント等にスキーマを記録し、書き込み/ 読み込み時の実装を⾏行行う •
スキーマの整合性はRuleで担保する
{ "lives": { "1": { "messages": { "1": { "user":
"sota1235", "image": "hoge.png", "text": "hello" } }, "notifications": { "buy_item": { "text": “sota1235さんが商品を購⼊入したぞい" } } } }, "alive_lives": { "1": true, "2": false } } メルカリチャンネルスキーマ(再掲)
まずは追加できるkeyを縛る • あらかじめ決めたスキーマのkeyのみ書き込み を許可する • それ以外は許可しない • コメント等、データを丸ごと追加するものは それに含むkeyに対してvalidationをかける
{ "rules": { ".write": false, "lives": { "$live_id": { "messages":
{ "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule
{ "rules": { ".write": false, "lives": { "$live_id": { "messages":
{ "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule +40/SPPUʹॻ͖ࠐΈΛڐՄ͠ͳ͍
{ "rules": { ".write": false, "lives": { "$live_id": { "messages":
{ "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule NFTTBHFTԼͷ৽σʔλʹ VTFS JNBHF UFYULFZΛڧ੍͢Δ
{ "rules": { ".write": false, "lives": { "$live_id": { "messages":
{ "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule ʁʁʁ
データ読み込みの動的制御 • ライブ放送中はデータ読み取りを許可する • 放送後はデータを読み込ませない
データ読み込みの動的制御 • ライブ放送中はデータ読み取りを許可する • 放送後はデータを読み込ませない • 特定のライブIDが放送中かどうかのフラグを 管理理し、動的に変更更する
{ "rules": { ".write": false, "lives": { "$live_id": { "messages":
{ "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule ͜ΕΛ͏
{ "rules": { ".write": false, "lives": { "$live_id": { "messages":
{ "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule "alive_lives": { ".write": false, ".read": false } ΫϥΠΞϯτ͔Β ಡΈॻ͖ΛҰͤ͞ͳ͍
{ "rules": { ".write": false, "lives": { "$live_id": { ".read":
"root.child('alive_lives').child($live_id).val() === true", "messages": { "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule
".read": "root.child('alive_lives').child($live_id).val() === true", Rule
".read": "root.child('alive_lives').child($live_id).val() === true", Rule JSONのrootから alive_channels.$live_idの値を 参照する
".read": "root.child('alive_lives').child($live_id).val() === true", Rule 該当のIDの値が alive_lives配下でtrueの時のみ 読み取り可
{ "lives": { "1": { ... }, "2": { ...
} }, "alive_lives": { "1": true, "2": false } } つまり alive_lives[“1”]がtrueなので 読み取り可能
{ "lives": { "1": { ... }, "2": { ...
} }, "alive_lives": { "1": true, "2": false } } つまり alive_lives[“2”]がfalseなので 読み取り不不可
{ "lives": { "1": { ... }, "2": { ...
} }, "alive_lives": { "1": true, "2": false } } つまり ライブ放送開始/終了了時に ここのフラグを編集する
ちなみに • メルカリチャンネルではクライアントからの 書き込みを⼀一切許容していない • ⼯工数節約のため • APIの負担を減らすなら必ずやるべき • その際はより細やかなRule設定が重要
3. Read/Write実装
アーキテクチャ(再掲)
アーキテクチャ(再掲) Read Write
How to write data? Read Write
Write戦略略 • データの書き込みをメルカリ側のAPIか らのみ⾏行行う • データの書き込みは複雑なロジックが多 い • 認証/NG判定/攻撃検知 •
こういった処理理をAPI側で担う • 認証はFirebase側でも可能 • それ以上はCloud Functionで Write
{ "rules": { ".write": false, "lives": { "$live_id": { ".read":
"root.child('alive_lives').child($live_id).val() === true", "messages": { "$message_id": { ".validate": "newData.hasChildren(['user', 'image', 'text'])" } }, "notifications": { "buy_item": { ".validate": "newData.hasChildren(['text'])" } } } }, "alive_lives": { ".write": false, ".read": false } } } Rule(再掲) Adminユーザ以外に ⼀一切の書き込みを許容しない
書き込み処理理の流れ
書き込み処理理の流れ ① APIでリクエストを受ける ② Firebaseへのリクエストを Enqueue ③ Worker processでJobを
Dequeue, Firebaseへ書き込み
書き込み処理理の流れ ② Firebaseへのリクエストを Enqueue ③ Worker processでJobを Dequeue,
Firebaseへ書き込み
① APIでリクエストを受ける • クライアントからデータを 受け取る • 認証、DB保存、NG判定等 • Firebaseにデータを送る場 合はリクエストJobを
Enqueueする
全てのDataをFirebaseに送る? • 送らない • 多すぎる書き込みはパフォーマンス低下を招く • ユーザ体験を損なわないものは間引く • いいね数は0.1秒に⼀一度しか送信しない •
間引くものと間引かないものを分ける
書き込み回数の計算 • 秒間あたりFirebaseに1000回まで許容する • いいね数を0.1秒に1回、視聴者数1秒に1回 • するとコメント他メッセージは秒間989回ま で送れる
② FirebaseへのリクエストをEnqueue • Firebaseへのリクエストは APIでやらない • Don’t trust each other
• FirebaseをSPOFにしない
• メルカリAPIで利利⽤用しているqueueシステム • MySQLで動いている • 詳しくは[検索] [Q4M] Q4M Enqueue Dequeue
③ Firebaseへリクエスト • WorkerからFirebaseへリ クエスト • Firebase REST APIを叩く •
kreait/firebase-phpを利利⽤用 • 公式で紹介されてる2つ のうち、こちらのほうが 質がいい
クライアントからFirebaseまで
クライアントからFirebaseまで ①データを送信
クライアントからFirebaseまで ͜͜Ͱ'JSFCBTFʹૹΔ͔ Ͳ͏͔அ͢Δ ①データを送信
クライアントからFirebaseまで ①データを送信 ②Queueを通じて リクエストJobを渡す
クライアントからFirebaseまで ①データを送信 ②Queueを通じて リクエストJobを渡す ③REST APIを叩く
How to read data? Read Write
Read戦略略 • クライアントは受け取った データを表示するだけ • 細かい制御はしない • 終了了済みのLiveデータは読 み取れなくする
Firebase接続の流れ GET channel Connect information Connect to Firebase Data publish
クライアント実装 • 公式SDKを利利⽤用する • iOS/Android/JavaScript • 普通に使う分には特に難しいポイントはない
Subscribe data • SDKのInterfaceはQuery形式で書けない • dataをsubscribeすると接続時点の過去のデータも取得される • 「視聴した瞬間からのコメントのみ取得」といったInterfaceは SDKにはない firebase.database()
.ref(‘live/1235/messages') .on('child_added', (snapshot) => { console.log(snapshot.val()); });
Timestamp • データにtimestampを付与し ておく • このtimestampと現在時刻を ⽐比較して表示するかどうか判 定する { "text":
“old", "timestamp": 1507226243 } { "text": “still old", "timestamp": 1507226300 } { "text": “new", "timestamp": 1507228000 } 視聴開始
Switch Firebase Instance • 複数のFirebase Realtime Databaseをつなぎ かえる場合はSDKのインスタンスを使いまわ せない •
⼀一意なkeyと⼀一緒にインスタンス⽣生成する必要 がある • 複数インスタンスの運⽤用については次から
4. スケーリング
スケールアップしない問題 • Realtime Databaseはスケールアップできない • ⾃自動でスケールアウトすることもない • 事前に負荷を計算し、場合によってはシャー ディング構成を取る必要がある
Single instance subscribe live ID
インスタンスを複数台⽴立てる • ある程度のtrafficに耐えるため • 負荷の低いインスタンスに順番に配信IDを 振っていく • 垂直分割しても⼤大丈夫なスキーマにしておく
計算する • Realtime Databaseの⼀一台のスペック • 同時接続10万 / 秒間書き込み1000回 • 実際の負荷がこの30%程度に留留まるよう台数
を検討する
Sharding subscribe live ID
イレギュラーを考える • メルカリチャンネルは最初の⼀一ヶ⽉月間、芸能 ⼈人やインフルエンサーの放送があった • 局所的にFirebaseへのアクセスが跳ねること が予想できた 通常のお客さまがその影響を受けないよう 常⽤用インスタンスと⾼高Traffic専⽤用インスタンスを分けた
⾼高traffic⽤用インスタンス
⾼高traffic⽤用インスタンス 通常インスタンス ⾼高traffic⽤用 インスタンス
⾼高traffic⽤用インスタンス 通常インスタンス ⾼高traffic⽤用 インスタンス live
ID
⾼高traffic⽤用インスタンス live ID
⾼高traffic⽤用インスタンス live ID
⾼高traffic⽤用インスタンス live ID
⾼高traffic⽤用インスタンス live ID
⾼高traffic⽤用インスタンス live ID
料料⾦金金体系 • Firebase Realtime Databaseは従量量課⾦金金 • 何台インスタンスを追加してもTrafficが無けれ ばタダ
インスタンス管理理 • Firebase ProjectとGCP Projectは必ず1対1 • ただしGCP ProjectをGUI以外で作る⽅方法がな い… •
Project作成、Rule設定、Auth情報ダウンロー ド等全てマニュアルでやらなければいけない
Realtime Databaseを 導⼊入してみて
リリース後の様⼦子 • キャンペーン期間の芸能⼈人による配信の際にも問題な く稼働した • Latencyが少ない • ⼈人の感覚ではほぼ同時 • 相当なコメント量量も問題なく捌いている
• ボタン1つで10万接続耐えるインスタンスが作れるの は便便利利
課題点 • スケールアウトがめんどくさい • GUI以外でのFirebaseプロジェクトの追加⽅方法 が無い • 現状スケールアウト = マニュアル操作
• 10万を越える接続に対応できない • 本番QAが⾯面倒くさい
余談: Cloud Firestore
Cloud Firestoreで変わった点 • ⾃自動スケールアウトするようになった • SDKのI/Fがよくなった • いわゆるQueryが使える • Latencyが伸びる可能性がある
• 肌感覚的には誤差とのこと(要検証)
Realtime Database vs Cloud Firestore • 新規プロダクトは基本Cloud Firestoreでよい • Cloud
FirestoreはRealtime Databaseの課題 を解決する形で実装されている
Realtime Database vs Cloud Firestore • ただし以下の場合はRealtime Databaseを検討 すべし •
Read/Writeオペレーションが⼤大量量に発⽣生する • 10milli sec単位でもLatencyを速くしたい
Firebase Dev Summit • オランダで開催されるFirebaseのカンファレ ンス • Cloud Firestoreに関する発表が聞けそう
最後に
何がよかったか • 守りたいものを守りながら実装をできたこと • ライブ感というユーザ体験 • シンプルなアーキテクチャ • これらを捨てずに短期開発リリースを実現
Thank you