こんにちは、MA基盤チームの田島です。ZOZOTOWNでは、ユーザコミュニケーションの手段としてLINE、MAIL、アプリへのPUSH通知を利用しユーザへのお知らせを実現しています。
その中でも、現在ユーザへのコミュニケーション強化の一環としてアプリPUSH通知（以降、PUSH通知）の強化をしようと考えています。ZOZOTOWNのPUSH通知は今まで、とある外部SaaS（本記事で出てくるSaaSはすべてこの外部SaaSを表します）を利用していました。しかし、PUSH通知チャネルの強化をする上で、利用していたSaaSでは要件を満たせない部分がありました。そこでPUSH通知のためのツールとしてFirebase Cloud Messaging（FCM）に移行しました。
本記事ではPUSH配信基盤の紹介並びに、移行時に行ったことを紹介します。PUSH配信基盤の構成や、PUSH配信ツール移行時の参考にしていただければ幸いです。
目次
FCM移行前のPUSH配信システム
はじめに、FCM移行前のPUSH配信システムがどのようになっていたかを紹介します。配信は以下のような流れで行われます。
- 初回アプリ起動時にiOSでAPNsトークンをAndoridではFCMトークンを取得
- APNs/FCMトークンをPUSH配信用SaaSに連携し、SaaSのPUSH配信用のトークンを取得
- 取得したPUSH配信用トークンをZOZOTOWNのAPIに連携しユーザと紐付けた形で保存
- 保存したトークンを定期的にIIASというMA用のDWHに連携
- IIASで配信対象ユーザを抽出
- アプリケーションからPUSH配信用SaaSに配信を依頼
- PUSH配信用SaaSがAPNs/FCMへ配信リクエストしユーザにPUSH通知が届く
この流れについてそれぞれ詳しく説明します。
1. 初回アプリ起動時にiOSでAPNsトークンをAndoridではFCMトークンを取得
ユーザがiOS/Androidアプリをインストールし最初にアプリケーションを起動するとiOSはAPNsトークンを、AndroidはFCMトークンを取得します。iOSに関して詳細には、アプリを起動し通知許諾ダイアログからユーザが許諾をしたタイミングでAPNsへデバイスを登録しAPNsトークンを取得します。PUSH配信用のSaaSは配信にAPNs/FCMを利用しており、それぞれのトークン連携が必要となります。
2. APNs/FCMトークンをPUSH配信用SaaSに連携し、SaaSのPUSH配信用のトークンを取得
続いて取得したAPNs/FCMトークンをPUSH配信用SaaSへ連携します。APNs/FCMトークンを連携するとそのトークンに対応するPUSH配信用SaaSでの配信用のトークンが取得できます。
最終的にはこの配信用トークンを利用しPUSH配信用SaaSへPUSH配信のリクエストをすることで、ユーザへPUSH配信を送ることができます。
3. 取得したPUSH配信用トークンをZOZOTOWNのAPIに連携しユーザと紐付けた形で保存
続いて取得したPUSH配信用SaaSのPUSH配信用トークンを保存します。ZOZOTOWNのAPIを経由しDBに保存されます。このとき、どのユーザのトークンであるかがわかるようにユーザIDと紐付けた形でトークンを保存します。
4. 保存したトークンを定期的にIIASというMA用のDWHに連携
ZOZOTOWNの全ユーザおよびセグメント（一部の配信対象）向け配信をする際には、IIASを利用して配信用トークンを含めた配信対象ユーザを一括抽出します。そのため、保存した配信用トークンをIIASへ連携する必要があります。
5. IIASで配信対象ユーザを抽出
前述の通り、データ連携が完了し配信のタイミングになると配信対象ユーザをセグメントとして抽出します。セグメントごとに配信文言や、通知タップ時の遷移先URL、それらに紐付いたトークンのリストなどを抽出します。
6. アプリケーションからSaaSに配信を依頼
続いて先程作成したリストを元に、PUSH配信用SaaSに対し配信依頼をします。このとき、配信文言やPUSH通知タップ時の遷移先URLなどと共に、トークンのリストを渡すことでまとめて配信依頼ができます。
7. PUSH配信用SaaSがAPNs/FCMへ配信リクエストしユーザにPUSH通知が届く
最後に配信依頼を受けたPUSH配信用SaaSがAPNs/FCMに配信リクエストすることで、実際にユーザへPUSH通知が届きます。
移行のきっかけ
上記のような仕組みでZOZOTOWNのPUSH配信は送られていました。冒頭で触れたように今回PUSH配信チャネルの強化をする上で利用していたSaaSの利用を諦める必要がありました。そのきっかけについて紹介します。
2つの配信基盤
きっかけを説明する上でZOZOTOWNの配信基盤についての前提知識が必要になります。ZOZOTOWNには配信の仕組みとして、大きく分けて2つの基盤が存在します。1つ目がバッチ配信基盤で、もう1つがリアルタイム配信基盤です。
バッチ配信基盤
バッチ配信基盤は先程の「FCM移行前のPUSH配信システム」で紹介したようにIIASから定期的にセグメント抽出し、抽出されたユーザに対して配信を送るといった仕組みです。バッチ配信での対象チャネルとしてはMAIL・LINE・PUSH通知・サイト内お知らせの4つの配信チャネルがあります。
リアルタイム配信基盤
リアルタイム配信基盤はその名の通りリアルタイムに配信をするための基盤です。何がリアルタイムかというと、ユーザ行動や商品情報などの変更イベントが発生するとそれを起点としてリアルタイムにユーザへの配信します。
例えばある商品の価格が下がったとします。その際にその商品をお気に入り登録しているユーザに対し、リアルタイムに「あなたのお気に入り商品が値下がりしました」といった通知をします。またリアルタイムに配信するだけでなく、ユーザごとに時間最適化を行い、ユーザがよく参照する時間に配信するといったこともしています。このリアルタイム配信基盤の配信チャネルは現状MAIL・LINEの2つです。
リアルタイム配信基盤についてより詳しく知りたい場合は以下の記事をご参照ください。
リアルタイム配信基盤でのPUSH通知
前述の通り、リアルタイム配信基盤ではPUSH通知での配信はされていません。今回PUSH通知チャネルの強化としてリアルタイム配信基盤でのPUSH通知を追加することになりました。しかしリアルタイム配信の特性上、既存のPUSH配信用SaaSでは実現できないことがありました。
移行前に利用していたPUSH配信用SaaSの特徴
移行前に利用していたPUSH配信用SaaSは同一内容の大量配信を得意としており、一括で同じメッセージをたくさんのユーザに送ることが簡単にできるようになっていました。その理由としては以下の特性が挙げられます。
100,000ユーザに対して同一メッセージを送りたい場合1回のAPIリクエストで配信が可能
よって、例えば1,000,000人に同じメッセージの配信をしたい場合はたったの10回APIリクエストをするだけで配信が可能となっており、アプリケーションの実装がかなり楽にできるようになっていました。
しかし、今回やりたいリアルタイム配信ではユーザごとにパーソナライズされたメッセージを送る必要があります。そのため例えば1,000,000人に対してPUSH通知を送る場合、最大1,000,000回APIリクエストする必要があります。現状のリアルタイム配信基盤で配信している秒間リクエスト数を考えると、これまで利用していたPUSH配信用SaaSではそのリクエストをさばき切れないことがわかりました。そこで、既存のPUSH配信用SaaSの利用を諦め別のツールを利用することを決心しました。
また、これまで利用していたPUSH配信用SaaSではただPUSH通知を配信するだけではなく、PUSH配信周辺のマーケティングのためのサービスも充実していました。しかし、ZOZOTOWNのマーケティングのビジネスロジックは内製しているため、有効活用できていませんでした。
移行先の選定
移行後はFirebase Cloud Messaging（FCM）を利用することにしました。移行先をFCMにした理由としては以下の特徴が挙げられます。
- 大量リクエストに対応できる
- iOS/Androidにおいて統一したインタフェースで配信が可能
- 最新機能への追従が早い
- iOS/Androidへの依存ライブラリが少ない
- 配信結果をBigQueryにエクスポートが可能
以上について1つずつ説明します。
大量リクエストに対応できる
今回の移行の最大の目的としてリアルタイム配信基盤からのPUSH配信の実現があります。そのため、リアルタイム配信基盤からの配信リクエストを十分にさばけないといけません。具体的な数値は明示できませんが、リアルタイム配信基盤からの現状のリクエスト数に対し、その数倍のリクエストが発生してもFCMでは問題ないことがわかりました。
iOS/Androidにおいて統一したインタフェースで配信が可能
PUSH配信を実装しようと思った際には、iOSは直接APNsを利用し、AndroidはFCMを利用するということが考えられるでしょう。しかしiOS/Androidそれぞれで配信の仕組みを変えた場合、複雑さが増すのと同時に実装すべきものが2種類に増えて実装コストが膨らみ、ユーザへの価値提供のタイミングが遅れると判断しました。そこで統一したインタフェースで配信可能なFCMを採用しました。
最新機能への追従が早い
iOS/AndroidのOSにてPUSH通知関連の新機能が実装された場合、活用できそうな機能であればいち早くサービスに利用したいです。そのためPUSH配信に利用するツール側がその機能に早急に追従してくれるものを選ぶ必要があります。AndroidにおいてはFCMがもともと配信ツールとして推奨されています。また、iOSに関してもオプションで直接APNsのパラメータを渡すことができるため問題ないと判断しました。
iOS/Androidへの依存ライブラリが少ない
もともとiOS/AndroidではFirebaseを利用していました。そのため、依存ライブラリやそのバージョン等の問題で導入できないという障壁がありませんでした。
配信結果をBigQueryにエクスポートが可能
弊社では全社のデータ分析基盤として、BigQueryを利用しています。そして、FCMでは配信実績をBigQeuryに直接エクスポートが可能です。そのため、最終的な配信実績を集計する場合わざわざ外部からBigQueryへデータ連携をし直すという手間が省けます。FCMからBigQueryへのエクスポート手順に関しては以下の記事をご参照ください。
以上のことからFCMが最も移行先として相応しいと判断しました。
Firebase移行後の構成
最終的にはリアルタイム配信基盤でPUSH通知を送るという目的があります。ただし既存のバッチ配信の仕組みが存在するため、まずはバッチ配信の処理をFCMへ移行しました。
移行手順の紹介の前にまずは、移行後の最終的な構成について紹介します。現状としてはあくまで第一段階として、配信ツールをFCMへの移行をしただけなので課題は様々残っています。それら課題に関しては後ほど今後の展望として紹介します。以下が移行後の配信の流れです。
- 初回アプリ起動時にiOS/AndroidそれぞれがFirebaseからFCMトークンを取得
- 取得したFCMトークンをZOZOTOWNのAPIに連携しユーザと紐付けた形で保存
- 保存したFCMトークンを定期的にIIASに連携
- IIASでセグメントを抽出し配信対象を作成
- 抽出したセグメントを配信情報と一緒にBigQueryへ連携
- アプリケーションからFCMへ配信リクエストしユーザにPUSH通知が届く
以上の流れについてそれぞれ詳しく説明します。
1. 初回アプリ起動時にiOS/AndroidそれぞれがFirebaseからFCMトークンを取得
ユーザがiOS/Androidアプリをインストールし最初にアプリケーションを起動するとFirebaseからFCMトークンを取得します。iOSに関して詳細には、アプリを起動し通知許諾ダイアログからユーザが許諾をしたタイミングでAPNsへデバイスを登録しAPNsトークンを取得します。そして取得したAPNsトークンをFCMに渡すことでFCMトークンを取得します。
2. 取得したFCMトークンをZOZOTOWNのAPIに連携しユーザと紐付けた形で保存
移行前はPUSH配信用SaaSの配信用トークンをZOZOTOWNのAPIに連携し保存していました。移行後は直接FCMを利用するためFCMトークンをユーザと紐付けた形でDBへ保存します。
3. 保存したFCMトークンを定期的にIIASに連携
次にPUSH配信用SaaSの配信用トークンをIIASへ連携していたように、FCMトークンをIIASへ連携します。
4. IIASでセグメントを抽出し配信対象を作成
移行前と同じようにIIASで配信対象ユーザを抽出します。このときFCMトークンを含んだリストを抽出します。
5. 抽出したセグメントを配信情報と一緒にBigQueryへ連携
次にIIASで抽出したトークンリストを配信文言等の情報と一緒にBigQueryへ連携します。BigQueryへわざわざ連携する理由としてはいくつかあります。ZOZOTOWNではDWHとしてBigQueryを利用しています。しかしMAでは以前から分析基盤としてオンプレミス環境でIIAS（正確には前世代機であるNetezzaおよびPureDataのリプレイスを重ねてきた）を利用していました。この環境を今後BigQueryへ移行する計画があり、その際にアプリケーションのロジックを変えないために今からBigQueryを中心とした配信アプリケーションを作成しました。
また、移行先の選定理由で紹介したようにFCMでの配信実績はBigQueryに直接エクスポートが可能です。そのためBigQueryに配信のための情報が溜まっているとあとから解析しやすいという理由もあります。
今の段階でIIASでのセグメント抽出を廃止しなかった理由としては、変更すべき範囲が大きすぎてしまい移行期間がかなり伸びてしまうため、IIASの利用廃止は後回しにしました。
6. アプリケーションからFCMへ配信リクエストしユーザにPUSH通知が届く
最後にBigQueryのデータを利用しアプリケーションからFCMへ直接リクエストすることでユーザへPUSH通知が届きます。このときPUSH配信用SaaS利用時は同一メッセージについて同時にリクエストできるユーザ数が100,000件でした。それに対し、FCMでは1,000件ずつしか配信できないため、高速に配信するためには工夫が必要となりました。それについては機会があれば別の記事で紹介いたします。
移行手順
続いてどのように配信ツールを移行したかについて紹介します。
移行の要件
移行に際して、以下の要件を満たす必要がありました。
- 既存のPUSH通知を止めることなくシームレスに移行する
- FCMで利用するFirebaseプロジェクトをiOS/Androidで統一する
それぞれについて紹介します。
既存のPUSH通知を止めることなくシームレスに移行する
ツールの移行に伴って、移行を理由にPUSH通知での配信を止めることはユーザへの価値提供の機会を損なうことになってしまいます。そのため、ツールの移行を今まで通りの配信が担保された状態で行う必要がありました。
FCMで利用するFirebaseプロジェクトをiOS/Androidで統一する
移行前の仕組みでも紹介した通り、外部のPUSH配信用SaaSではAndroidの配信でFCMを間接的に利用していました。Androidにおいては基本的にはiOSと同じ共通のFirebaseプロジェクトを利用していましたが、PUSH配信用SaaSで利用するFCMのみ別のプロジェクトを利用していました。これは以前よりAndroidの実装を複雑にする要因となっていました。今回FCMへ移行するに当たり、Firebaseプロジェクトを統一することで配信処理がシンプルになるなど、バックエンドの構成的にも統一することによるメリットがありました。
移行手順
配信の移行は以下の3つの手順に分けました。
- iOSからPUSH配信用SaaSでの配信、並びにFCM両方で配信
- iOS/AndroidでFCMのみ配信できるようにしバージョンアップ済みユーザ全員へFCMで配信
- FCMのみで配信
1. iOSからPUSH配信用SaaSでの配信、並びにFCM両方で配信
はじめに今まで利用していたPUSH配信用SaaSとFCMで同時並行に配信できる仕組みを実現します。これにより、iOS/Androidの実装と配信側の実装をぞれぞれのタイミングで進めることが可能となります。また、FCMでの配信になにか問題が発生した場合、既存のPUSH配信用SaaSでの配信に戻せばいいため安全に移行できます。アプリと配信側の実装や切り替えを一斉に行うと、すべてのキャンペーン配信を同時に移行しなければなりません。しかし今回実施するようにどちらからも配信できるような環境を用意することで、一部の配信のみをFCM側で配信し、徐々にFCMでの配信に移行していくことができます。
この段階では、iOSのみ既存のPUSH配信用SaaSとFCMどちらでも配信可能な状態にしました。Androidではこのフェーズを挟みませんでした。それはFCMのGCPプロジェクトの移行が関係しています。前述の通り、Androidでは既存のPUSH配信用SaaSで利用するFCMのためだけに専用のGCPプロジェクトを利用していました。そして今回の移行段階で、FCMにおいてもiOSと共通のGCPプロジェクトに移行させます。そのため既存のPUSH配信用SaaSとFCMでの配信をどちらも行おうとすると、2つのGCPプロジェクトのFCMを利用するため実装がかなり複雑になってしまいます。
2. iOS/AndroidでFCMのみ配信できるようにしバージョンアップ済みユーザ全員へFCMで配信
最初のフェーズで、すべてのキャンペーン配信がFCM経由で成功したことを確認できたら次のフェーズに移ります。
続いてiOS/AndroidでFCMからの配信しか受け取らないバージョンをリリースします。このタイミングでは、バージョンアップ済みのユーザにはFCMで、バージョンアップ前のユーザには既存のPUSH配信用SaaSで配信します。
3. FCMのみで配信
最後にほとんどのユーザがFCM対応バージョンに移行しきったタイミングで既存のPUSH配信用SaaSからの配信を止めます。これによってFCMでの配信に100％切り替わります。このとき、事前にバージョンアップしないとPUSH通知が停止する旨をアプリ上にてお知らせすることでユーザにバージョンアップを促すことができました。
以上のように既存のPUSH配信用SaaSからFCMへシームレスに移行できました。全体として2,3か月をかけての移行となりました。
今後の展望
移行後の構成を再掲します。
以上の構成では、FCMへの移行は完了していますが、課題がいくつか残っています。ここでは、それらについて説明し、最終的な構想を紹介します。
既存の課題
- トークンの連携
- 2つのDWH
- 2つのワークフローエンジン
トークンの連携
前述の通り、PUSH配信用のFCMトークンは最初にZOZOTOWNのDBに保存され定期的に配信用のDWHに連携されています。これは、MAというマーケティング向けのシステムがZOZOTOWNと切り離されているためです。これにより、データ連携という工程が発生し、リアルタイムな配信を難しくしています。しかしFCMトークンはMAでのみ利用するもののため、ZOZOTOWNのDBに保存するメリットはほとんどありません。
2つのDWH
ZOZOTOWNのDWHとしてはBigQuery、配信用のDWHとしてはIIASを利用していると紹介しました。そして最終的にはBigQueryにDWHを統一させたいため、IIASで行っている処理をBigQueryに移管します。またそのために必要なデータもすべてBigQueryに移行する必要があります。
2つのワークフローエンジン
最終的にPUSH配信はアプリケーションからFCMにリクエストすることで行われます。また、元々の配信もアプリケーションからPUSH配信用SaaSにリクエストすることで行われていました。そして、それらはワークフローツールを介して起動しています。元々、PUSH配信用SaaSで配信していたアプリケーションはJP1というワークフローツールから起動し、オンプレミス環境で動作しています。また、JP1ではスケジューリングの機能を利用し定期的にバッチ配信をしています。新しく作成したFCMで配信するアプリケーションはDigdagというワークフローツールから起動されAWS上で動作しています。そして現状では、Digdagではスケジューリングの機能を使わずJP1からキックする形で利用しています。以下がアプリケーションの流れです。
- 移行前
- 移行後
Digdagから直接アプリケーションを起動しない理由としては、セグメントの抽出処理はまだJP1側のアプリケーションで行っているからです。今回そこもスコープが大きくなるため移行を後回しにしました。そのため最終的には以下のようなDigdagを中心としたアプリケーションにすることを目指しています。
構想
以上の課題をなくし、最終的には以下のようなシステムを構想しています。
まず、前述の課題を解決しDWHをBigQuery、ワークフローツールをDigdagにします。そして、トークンの取得をZOZOTOWNのDBから切り離し、MAとして管理しているDBに直接保存して利用します。それに加えてリアルタイム配信ができるように、専用のAPIを用意しリアルタイム配信が可能となるような状態を目指します。
まとめ
今回、外部のPUSH配信用SaaSからFCMへ配信ツールを移行した流れを紹介しながら、ZOZOTOWNでのPUSH配信基盤について紹介しました。移行において、PUSH通知を止めないよう安全に移行できました。この移行事例や配信基盤が事例として少しでもお役に立てれば幸いです。
終わりに
本記事で紹介したようにZOZOTOWNでは、多くのユーザへ高速かつ正確にコンテンツを配信するための基盤を開発運用しています。まだまだ発展の途中ですので、ご興味のある方は以下のリンクからご応募ください。
