![](https://images.logmi.jp/media/article/331354/images/main_image_e24ef777e157e313fcf000c9aa77f0dec552a821.jpg?w=600)
2025.02.05
能登半島地震の被災者と支援者が語る「理想の災害DX」 自治体にも企業にも本当に必要な備えとは
Firebaseを活用したPush通知基盤構築のよもやま話(全1記事)
リンクをコピー
記事をブックマーク
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が使えるんじゃないかなと思って、いま追加しています。
あと、やっぱりコメントがあったほうが、ユーザー同士で盛り上がりの可視化にもなるし、実際に番組制作にユーザーのコメントとしてフィードバックできますそういうユーザーとのコミュニケーションを図るうえでの機能を、いろいろと実装していきたいなと思ってます。以上です。ありがとうございました。
(会場拍手)
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07