アプリプッシュ通知の配信基盤

高度化する業務要件を満たすために

Firebaseを活用したアプリプッシュ通知の配信基盤

こんにちは。Lignumの開発を担当している明智と浅井です。
Lignumは今回紹介する配信基盤の名前です。

先日開催されたGoogle I/Oでも多くの新機能が発表されたFirebaseですが、弊社では昨年度からFirebaseを活用した機能開発に取り組んでいます。
今回は、その中でも『Firebaseを活用したアプリプッシュ通知の配信基盤の構築』について紹介したいと思います。

「アプリプッシュ通知の配信基盤」構築の背景

見えてきていた課題

弊社ではこれまで、リクルートグループ横断で利用できる独自開発された配信基盤を利用していました。
しかし、施策が高度化するにつれて

  • 実施できる施策の制限
  • 配信の見立て/結果の振り返りに利用したいデータが不足

といった「弊社独自の業務要件に追いつかなくなってきている」という課題が見えてきていました。
そこで、PDCAサイクルの回せる新たな配信基盤が必要だと考え、検討が始まりました。

アプリプッシュ通知を配信するためのツールは世の中に数多くありますが、以下の観点から「Firebase」を利用することにしました。

  • GCMベースで実装されており、GCM・Firebaseともに世界的に大量データの処理実績がある
  • 分析ツール(Firebase Analytics)との連携が可能
  • ツールの機能改善頻度が高く、今後さらなる発展が期待できる
  • Googleに弊社からの問い合わせに対応してくれる窓口がある

Firebaseをそのまま使うだけでは、業務要件を満たせなかった

Firebaseには、プッシュ通知を行うためのサービスが2種類あります。

  • Webコンソールから簡単にできるFirebase Notifications
  • APIで汎用的な通知ができるFirebase Cloud Messaging(FCM)

弊社の業務要件を満たそうと考えた場合、「FCMをベースにしつつ、業務要件を満たすために基盤を独自構築」が妥当であると判断しました。
以下が、業務要件とツールの比較表になります。

FCMをベースにした配信基盤

実際に配信を行う部分はFCMに任せて、ユーザリストの登録から配信までGUI上で簡単に操作可能な独自基盤を構築することにしました。

得られたことサマリ

実現するための方針や技術詳細については後述しますが、Firebaseを活用した配信基盤を構築することで得られた効果を先に伝えたいと思います。

1. 取得可能なデータ種類の増加

従来の配信基盤では取得できなかった通知関連のデータが取得できるようになり、より効果的な配信見立て/振り返りの実施が可能になりました。

2. 事業会社として注力したいポイントにパワーを割くための基盤再構築

注力するポイントを絞ることで、開発的にやれることが増え、配信運用業務を含めた最適な基盤の再構築に乗り出せることになりました。

技術詳細

ここから、FCMをベースにした配信基盤をどう構築したかについて説明していきます。

配信を実現するために実施した内容を全て載せてしまうと情報量が多すぎてしまうため、 今回は「基盤構築」にスコープを絞りたいと思います。

  • FCMへの配信に必要なデータをFirebaseから取得するための設計
  • 社内の横断データとFirebasから取得したユーザーデータ(BigQueryに連携)を結合するための設計
  • ユーザー指定で配信を可能にする配信基盤の設計 with FCM ★ 今回のスコープはココ
  • 分析要件のためのデータ設計

システム構成

  1. 配信内容を登録する
  2. 登録された情報を格納する(BigQueryにはFCMに必要なデータを、RDSにはその他表示に必要なデータを格納する)
  3. 配信の有無をポーリング
  4. ユーザー情報をFCMに必要なトークンに変換する(Firebase AnalyticsのデータとBigQueryをリンクさせている)
  5. 配信を分割する
  6. 分割数を格納する
  7. メッセージを取り出す
  8. FCMに必要なデータを取得する
  9. FCM APIをコールする
  10. 配信結果を格納する(振り返り用)
  11. 分割数をデクリメント(0になれば配信完了)

フロントエンド(1~2)

PDCAサイクルを回していくうちに、配信基盤への要望が出てくることは容易に想像できます。 その要望にスピーディーに応えていかなければ、せっかく構築しても意味がなくなってしまうので、社内でもノウハウが多く開発スピードが出やすいRailsを採用しました。

バックエンド(3~11)

FCMは1配信にAPIを1コールする必要があるため、大量に配信する場合はその分APIコールが発生します。 これを逐次処理で行うと配信完了まで時間が掛かるため、並列処理が得意な言語を採用する必要がありました。 並列処理が得意なNode.jsとGoが候補に挙がりましたが、社内で採用例が多くなってきているGoを採用することにしました。

高スケーラビリティの実現

いくら並列処理が得意な言語を採用したとしてもサーバー以上の性能を出すことはできないので、スケールアウト可能な構成にする必要があります。 バックエンドを2層に分け、その間にメッセージキューを入れることにより、複数のサーバーでプッシュ通知が行えるような構成にしました。

メッセージキューとしてAmazon SQSを使用すると、同じメッセージを重複して取得する可能性という問題がありました。 メッセージを重複して取得してしまうと同じ内容を複数回配信を行ってしまうので、配信基盤では許されない動きです。 そこで、Amazon SQSの標準キューではなくFIFOキューの方を選択しました。
FIFOキューは追加実装なしで重複取得を防ぐことができますが、スループットが1秒あたり300件のトランザクションに制限されてしまいます。(標準キューは無制限) 1メッセージ1配信にするのではなく、1メッセージに分割した件数を入れることにより、1秒あたりの配信数がある程度まで多くなるように工夫しました。(1000件ごとに分割すると1秒あたり30万件配信できる)
完全な高スケーラビリティを実現できてはいませんが、重複チェックをアプリケーションで持たなくて良いというメリットがあります。

おわりに

実際にプッシュ通知基盤が使われ始めて数ヶ月が経ちました。 システム構成的には大きな問題なく、改善の要望にもスピーディーに応えられています。

今までであれば、業務要件と配信の両方を運用する必要があり、配信基盤を構築するハードルは高かったように思います。 しかしながら、Firebaseの登場によって配信の部分を面倒見なくてよくなり、業務要件だけに注力することができる良い時代になりました。
今一度システムを見直して、Firebaseが使えないか検討してみるのもありだと思います。

最後に、リクルートライフスタイルでは新しい価値をどんどん取り込んでいく仲間を募集しています。

Lignum開発チーム

(ディベロップメンドデザインユニット)

Lignumという独自配信基盤の開発と運用をおこなっています。高速開発と価値検証ができる基盤構築に向けて奮闘しています。

NEXT