DroidKaigi 2019 - FCM を使った用途に合わせた Push 通知設計 / Koji Okada [JA] を視聴した

視聴元

Pushを使おうとするときの要件はたくさん

• 頻度
• 送信対象ユーザの規模
• 許容できる遅延
• メッセージの内容
• 開発体制
• リリースタイミング

FirebaseCloudMessaging

• 各プラットフォームにまとめて送信できる。便利。
• ただしFCMだからといって、すべてを解決できる方法はない。

設計するときのよりどころ

制約を満たすように設計を考えると、選択肢がほとんどなくなる

• FCMでできることは制約
• 実現する機能の要件も制約

FCMでできることは？

通知対象をサーバで把握

• サービスサーバが認識する手段
• デバイストークン
• トピックのサブスクライブ

通知送信のリクエスト

• サービスサーバからFCMサーバへのPush通知を送る手段。
• HTTP v1 API
• レガシー HTTPサーバ
• レガシー XMPPサーバ
• FirebaseAdminSDK

通知データを処理して送信

• 受け取った通知をユーザに表示する手段
• 渡されたものをそのまま出す
• アプリ側でハンドリングする

PixivのPush通知（ライブ開始通知）に関する事例

• 通知対象をサーバで把握：トピックのサブスクライブ
  • DBでデバイストークンを管理したくない
  • 自分専用のトピックを生成してそれをサブスクライブさせる
• 通知送信のリクエスト：レガシー XMPPサーバ
  • 既存基盤との兼ね合い
  • phpで実装されているためSDKを使えない
  • HTTP v1API以前に実装されたため レガシーのどちらか
    • できるだけ早くしたかったので XMPPサーバとした
• 通知の送信
  • 通知に乗ったタイトル・本文

制約に関する整理

• 頻度
  • 毎分数人程度を想定すると特になし
• 送信ユーザ規模
  • 最大クラスユーザだと数十万件
  • 最大クラスのユーザに配信開始から15分程度で送信完了させたい
  • 許容できる通知の限度に制約がある
• 送信メッセージ内容
  • これまでの同様の仕組みで問題なし
  • ただし未対応バージョンに影響あり。古いバージョンに対して問題が発生しないように送信する制約がある
• リリース
  • 長くても3か月程度でリリースしたい

制約に対する設計

• 通知の遅延限度
  • バッチの並列化（採用）
  • フォロワー向けトピックの用意（設計や改修規模に課題あり）
• 古いバージョンに通知を送らない
  • アプリバージョンをサービスサーバで管理（改修規模に課題あり）
  • ログベースで送信対象をフィルタリング（採用）
• リリース
  • 改修規模を加味して制約を整理