Firebaseを活用したPUSH通知基盤構築

Firebaseを活用したPush通知基盤構築

danno氏（以下、danno）：こんにちは。テレビ東京コミュニケーションズのdannoと申します。

いつもFirebase User Groupには参加させていただいてて、フィードバックしないとなというところで、実は第3回目にお話しようかなと思ってたんですけど、抽選から外れてしまったので、自分のなかでは少し古い話なんですけど。

あと、共有できる内容が自分の知見、ナレッジとかなので、すごい最先端の話をしているわけではないので、“Firebaser”には物足りないかもしれないですけど、お付き合いください。

簡単にプロフィールを紹介すると、テレビ東京に入って、SEやって、カメラマンやって、いまは動画配信系のサービスに携ってます。

テレビ東京コミュニケーションズってたぶんあんまり名前を聞いたことないと思いますが、テレビ東京の番組を使って、いろんな事業、クロスメディア企画とか、配信とか、オウンドメディアとか。あとはぜんぜん関係ありませんが、IPビジネスなんか、スヌーピーとかやっています。

あと、動画配信サービスとして、卓球に力を入れていて、卓球や柔道のライブ配信をやっています。

今回お話するのが、自分が一番コミットしている事業の動画配信サービスで、こんな感じです。

これは自分のなかの自慢なんですけど、いろんなVOD（ビデオオンデマンド）サービスがあるんですが、実は民放のなかで一番良い評価をいただいてて、これは自分のなかでモチベーションになってるので、いろんな改善をしています。

この事業のなかで、Firebaseを使ったときのお話をしようと思ってます。

リニューアルの背景

背景は、そもそも昔作ったやつがすごい残念なアプリだったのでリニューアルしようということと。

あと、Push通知でいうと、たぶんみなさん知ってる人いると思うんですけど、Parseというのが昔あって、これ使ってたんですけど、いきなりサービス終了って言われてしまって「これ、どうしよう……」ということと。あと、他の事業で、自分は直接関わってないんですけど、VODサービスが入ってきました。

実はVODサービスは同じなのに、サービスの指標が違かったので、ちょうど（Firebaseが）出たてぐらいだったと思うんですけど、「Firebaseで共通化しましょう」みたいな話をしていて。

実際にFirebase Analyticsを使うために使ってたんですけど、「Push通知もやっぱり使いたいよね」となってNotificationsをやったんですけど、かなり運用負荷が高いし、ぜんぜん柔軟性がないから、「困ったもんだ」と。みんなたぶん一度は陥るところかなと思います。

例えばうちでいうと、前回の『ゴッドタン』の先週の分を観てくれたけど今週観てない人に対して、「今週上がったよ」みたいな通知をするのに、「ユーザーリストを使ったほうがいいんだろうな」と思いつつ、ユーザーリストってすごい柔軟性が低くて。「先週観た人のなかから今週観た人を抜いて……」みたいな変なターゲティングをしていて、これはかなり運用負荷が高いですし。

あと、新規の番組を観てもらうために、ドラマに興味ある人に送りたいとか、あと、休眠ユーザーの掘り起こし施策とかをやろうかなと思ったら、このあたりの定義はどうすりゃいいんだっけ？　ということに陥って、「もうちょっと別の仕組みでやろうかな」というところを考えました。

Push通知の要件としてはおそらくあまり変わりませんが、いろいろとあって。ただ、個人的に「なんでもかんでもSDKを入れたらいいよ」という話じゃなくて、あまり依存関係を増やしたくないので、Firebaseを使ってるので、なるべくPush通知はこれでやろうかなと思っています。

こんな感じで、お気に入り番組機能を追加して、（お気に入りに）追加してくれた人には新着通知をするみたいなところは一番オーソドックスに考えられたので、こんな感じでできるかなというところを考えてました。

つまづきそうな制約

実際にさっきのイメージで作り始めると、いろんなところでつまずき要素がありました。例えばFirebase Notification、まずやり方としてtopicかFCMかという2つあって。

だいたい公式サイトだと、ニュースなどは「topicでやりましょう」みたいなのが書いてあるんですけど、実際に届いたかどうか、ちゃんと遅延なくなるべく早く出すというところをやろうとすると、「topicじゃないよね」というところにいきついたり。

topicはレイテンシじゃなくてスループットに最適化されてるので、FCMを使わざるをえなかったり。

あと、実装してる最中に、いきなり以前のAPIに落ちちゃってて。それで、新しいAPIを使おうと思ったら、registration_idsというFCMに一括送信する機能がなくなってたりとかして、「これ、どうしたもんか……」って悩んだんですけど、とりあえず要件を満たすためには、古いAPIをいまだに怖々使ってる感じです。

あと、FCMでやるんだったら、「FCMトークンってどうやって保持するんだっけ？」というので、ユーザープロパティは普通にAnalyticsにあるので「使えるかな」と思ったら、FCMトークンの長さにぜんぜん足りなくて、「Firestoreに保存しましょう」みたいな。保存するってなったら、さっきのコキチーズさんみたいにセキュリティの問題があるので、ここでは詳しく書いてないですけど、ルールをどうにかするという話とか。　

あと開封イベントも、普通デフォルトではnotification_openとかreceiveとか用意されてるんですけど、地味に独自実装だったら計測に使えなかったりとかして、わざわざ限りあるカスタムイベントを払い出して作らないといけなかったり。

あと、Firestoreで実際にお気に入りに追加してくれたかどうかという情報を、どうやって持とうかなと思っていて。いろんな登録をしてくれてるかどうかとか、どの番組を登録してくれてるかみたいな情報を2つ登録しようとすると、2つフィールドを持たないといけなくて。

そうなってくると、複合インデックスをやるのであれば、100万件とかに送ろうとすると、どうしてもパフォーマンスを出すために「インデックス貼ろう」という話が出てくると思うんですけど、複数のインデックスというのは明示的に自分で打たないと作ってくれなくて。1つだったらデフォルトで自動的にインデックスが貼られます。

なので、これが正しいやり方かわからないんですけど、お気に入り番組というところで、番組名ごとのキーに対してユーザーが登録してくれたタイムスタンプを押して。解除する時は0みたいなところをやって、0じゃないところを引っ張ってきて、ソートして、1,000件ずつ送るみたいなことをやってます。

あとフィールドパスの制約として、……ここ僕たちのCMSの制約なんですけど、番組名のフィールドにどうしてもハイフンとか入ってくるんで。ハイフンって、これ、FirestoreというかFCMの制約だったりするんですけど、そのまま引っ張ってこれなかったりするんで、バックコードで回避しましたとか、けっこうトラブルがありながら、なんとか3ヶ月ぐらいでこれを作りました

アーキテクチャの実装

アーキテクチャ実装としては、下側がメインで、アプリからFirestoreに保存しています。

これ、アプリケーションサーバーでApp Engineを使っていて。普通に1,000件送るときもあれば、100万件送るところもあって、なるべくアプリケーションの管理画面が必要でということをいろいろ考えていくと、App Engineが一番お買い得かなというところでこういう仕組みにしてて。

大前提としてテレ東はお金あんまりないので、なるべくお金を安くするというところで作ってます。

実際にFCMを送って、通知がアプリのAnalyticsに上がって。これはBigQueryを直接は叩いてなくて、ここも直接叩くと怖いので。裏側にTreasure DataとかRedshiftあるので、そこに突っ込んで、いくらでもゴリゴリできるようにしている感じです。

実際の内容はこんな感じで、お気に入りのボタンがあって。FCMの階層としてはこんな感じで、app_instance_idごとにこういう情報を持たせてます。

管理画面こんな感じで、お気に入り番組登録数もかなり伸びて。Push開封率も上がって、運用負荷も下がって、良いことだらけです。あと、柔軟なセグメントも、たまっているデータからFCMトークンを抽出して送るようなこともできるようになったし。他の事業にも展開中です。

あと、ぜんぜんこれはFirebaseと関係ないんですが、GAEでちゃんとスケールアウトしてくれて。これ、怖かったんで、100万件は同じタイミングでは送ってないんですけど。アーキテクチャ的には（こんな感じです）。

今後について

今後の話として、FCMでやりたいこととしては、Web Pushってまだできてないんで早くやりたいなってところと。あと、レコメンドと連携したPush通知というのをやろうかなと思って、ここのアーキテクチャを考えるのがけっこう楽しかったりします。

あとは、メディアとして緊急速報とか地震速報とか、やっぱり報道機関としてやらないといけないところで、そこをどうやってやろうかなというところを、いま考えているところです。「Firestoreかな？」という。

あと、いろいろとあるんですけど、スポーツのライブ配信をやっています。下にスコアが出ているのをよく見ると思うんですけど、ここをリアルタイムにずっと出したいなと思ってて、そこにFirestoreが使えるんじゃないかなと思って、いま追加しています。

あと、やっぱりコメントがあったほうが、ユーザー同士で盛り上がりの可視化にもなるし、実際に番組制作にユーザーのコメントとしてフィードバックできますそういうユーザーとのコミュニケーションを図るうえでの機能を、いろいろと実装していきたいなと思ってます。以上です。ありがとうございました。

（会場拍手）