💬

FCM運用のベストプラクティス

2024/12/05に公開

こんにちは、アドベントカレンダー(物理) を買うか悩んで結局今年も買っていない Cloud Support の Rnrn です。皆さんのおすすめがあったら来年こそ参考にするのでぜひ教えてください😀
5 日目 の今日はサポートでも時々お問い合わせいただく Firebase Cloud Messaging (FCM) について、運用時どういったことに気をつけると良いかがテーマです。FCM の問題の調査に時間がかかったり、調査が難航する原因の大部分は情報不足です。いざ問題が起きて調べるぞ!となったときに必要な情報が取得できていなかったということのないように、トラブル発生時に向けた備えを中心にご紹介します。

送信結果の収集

シンプルに FCM 送信時のレスポンスは大切です。思った通りにメッセージが届かないという事象があったとします。そういう時にはまず Send リクエスト自体は問題なく通っていたのか、それとも Send リクエスト自体が失敗していたのかというところから問題を切り分けていく必要があります。

失敗していたとして、具体的にどんなリクエストに対してどんなエラーがどのくらいの数出ていたのかという情報は普段からお手元で適切にリクエスト・レスポンス・エラーメッセージのロギングが行われていなければわからなくなってしまいます。一般的なロギングと同様にステータスコード・エラーメッセージ・送信日時が大切なほか、FCM 固有の情報としては Registration Token (もしくはトピック) とメッセージ ID が調査の上で重要になります。

なにを当たり前のことをと思われるかもしれませんが、具体的にどんなエラーが出ているかわからないというケースは意外と少なくありません。既にしっかりと情報をキャプチャしている皆様は素晴らしいので過去の自分を褒めておきましょう👏 実はできていなかったかも…という皆様はぜひこの機会にご検討いただければと思います。

配信レポートのチェック

配信状況の確認で一番利用されているのは、コンソール上のメッセージ配信レポートではないでしょうか。事前の設定などは不要で、FCM を利用していれば自動的にデータが集計・表示されます。

レポートは直感的なグラフで、特に難しいことはありません。送信数や受信数などの推移が確認できるようになっていますが、それ以上に詳しい情報はないため、トラブルシューティングツールというよりは問題に気づくきっかけとしての役割が大きいと言えそうです。ちなみに、サポートではお客様の配信レポートを見ることはできないため、ケースでお問い合わせいただく際はスクリーンショットを添えていただけるとスムーズです。

Data API (集計済配信データ) の活用

Data API はプロジェクト内のデータ収集が可能なすべての Android デバイスから集計したデータを提供します。Android アプリをご利用の場合は大まかにどの程度のメッセージがどんな理由でドロップされたか、どんな理由で遅延したかなどの傾向を掴むことができるので、配信数や配信時間の問題があったときに役立ちます。

Data API のレスポンスサンプル
 {
  "appId": "1:23456789:android:a93a5mb1234efe56",
  "date": {
    "year": 2021,
    "month": 1,
    "day": 1
  },
  "analyticsLabel": "foo",
  "data": {
    "countMessagesAccepted": "314159",
    "messageOutcomePercents": {
      "delivered": 71,
      "pending": 15
    },
   "deliveryPerformancePercents": {
      "deliveredNoDelay": 45,
      "delayedDeviceOffline": 11
    }
  }

この API も事前の設定などは必要なく利用できますが、過去 7 日間のデータを返却するように設計されているため、関心のある期間がそれより前の場合には有用な情報が得られません。なにか調査したい問題が出てきたときは一旦 DataAPI のレスポンスを取得しておき、データをどこかに保存しておくと安心です。継続的にモニタリングして活用する方法についても以前弊社エンジニアがコミュニティブログで紹介しているのでぜひご覧ください。

データのグループ分けはアプリケーション、日付、アナリティクスラベルごとになります。そのため、同一アプリケーションから同じ日に複数回配信を行っており、配信ごとの集計が見たい場合には配信時にアナリティクスラベルをつけておくことをおすすめします。返却されたデータの解釈についてはこちらのドキュメントをご参照ください。なお、後述する BigQuery Export とは確認できるデータの種類が少し違うので、どちらかを選択して使うだけではなく、併用するとより詳しい情報が得られるようになっています。

BigQuery Export の設定

BigQuery Export は Android・iOS・Web の 3 プラットフォームを対象に一番細かな情報を取得できる強力な機能です。ただし、利用にはプロジェクトレベルの設定と、アプリケーション側での有効化が必要です。FCM からのエクスポートを利用するには Firebase の Blaze Plan に加入している必要がありますが、FCM からのエクスポートそのものは無料で、通常の BigQuery の利用にかかる料金だけが発生します。BigQuery には無料枠があるので、この範囲に収まるうちはこちらについても無料となります。

どんな使い方ができるかについてはサンプルクエリを見てみるとわかりやすいです。特定のトピックまたはキャンペーンのファンアウト期間を計算したり、指定されたメッセージ ID とインスタンス ID のレイテンシを計算したりなど 配信レポートや DataAPI と比べてより細かなデータが取得できることがわかります。まだセットアップされていない方はぜひこの機会にご検討ください。

送信されたメッセージ数をアプリごとにカウントするクエリサンプル
SELECT app_name, COUNT(1)
FROM project_ID.firebase_messaging.data
WHERE
  _PARTITIONTIME = TIMESTAMP('date as YYYY-MM-DD')
  AND event = 'MESSAGE_ACCEPTED'
  AND message_id != ''
GROUP BY 1;

BQ Export は日次のジョブになりますが、初回のデータの書き込みはセットアップ後最大で 48 時間かかるので最初は少しゆったり待っていていただければと思います🍵なお、配信レポート同様にサポートはこのログの内容にはアクセスできませんが、ご覧の通りトラブルシューティングには大いに役立つデータなので、FCM の配信や遅延の問題でお問い合わせいただく際はクエリと結果をご共有いただけると調査がスムーズになります。

トラフィックの平滑化とリトライ

主に大規模に FCM を送信している人向けに、FCM はトラフィックの平滑化とリトライを促すベストプラクティスを公開しています。詳しい内容はドキュメントに記載があるので、ここでは細かな内容には注目しませんが、代わりにこのベストプラクティスが実践されていないとどういう良くないことがあるかを簡単にまとめておきたいと思います。

はじめに、トラフィックが平滑化されていないとクォータを有効活用することができなくなります。クォータの制限にひっかかってエラーが発生し送信が失敗し始めてしまったというケースのほとんどが瞬間的なトラフィックの増加によるものですが、この状態だとクォータの引き上げは認められません。平滑化することにより既存のクォータで対処できると考えられるためです。いざエラーが発生してから平滑化を急いで実装するのは大変ですし、エラーが不必要に発生してしまうことになるので普段から気を配っておくのが理想的です。

つぎに、ベストプラクティスに沿ったリトライがされていないと一時的なインフラ側の問題への耐久性が下がります。FCM は SLA は提供していないながらも高可用性を維持するよう努めていますが、クラウドサービスという性質上一時的なエラーが発生することは避けられません。そういった時、理想的ではないリトライの仕方をしていると結果的にリカバリが遅れることになりかねず、また反対にリトライ自体されていないと本来配信できるはずだったメッセージが配信されないことにつながってしまうため望ましくありません。

クライアント上の情報の収集

FCM のトラブルシューティングの難しいところは、クライアントデバイスの状態が送信状況を左右することがよくある一方で、クライアントの状態をサービス提供側から知ることが困難なところにあります。少しでも詳しい情報を得るためにできることとしては、Bug Report の取得 (Android のみ) や同ページで紹介されている Google Play Console や Firebase Crashlystics の活用があげられます。

最後に

今回は FCM 運用時に普段から気をつけておくといいことをご紹介しました。トラブルシューティングステップまで含めると長くなってしまうのでそれはまた今後の機会にとっておきますが、1 つ簡単に紹介できる指針として最後に Firebase トラブルシューターのリンクだけ貼ってお別れしたいと思います。
もう 2024 年が終わるまで 1 ヶ月もないなんて信じられないですよね…余談ですが、私は最近腰を痛めかけたので椅子を変えてみたり 1 時間おきに座る -> 立つを切り替えるなど気を使うようになりました。みなさんも姿勢と健康には気を付けて良い年末年始をお過ごしください🎄

Google Cloud Japan

Discussion