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

テレビ東京の見逃し動画配信サービス「ネットもテレ東」事業にて、Firebaseの各種機能を利用してPUSH通知基盤システムを構築した知見を紹介。

Transcript

1. Firebaseを活用したPUSH通知基盤構築のよもやま話
   TV Tokyo Communications
   Yuichiro Danno
   Firebase Meetup #4
   事業視点での実装例
   Special thanks
   

   View Slide

2. PROFILE
   －2007年
   　テレビ東京入社
   　情報システム局システム部 SE
   －2012年
   　技術局制作技術部 カメラマン
   －2015年
   　テレビ東京コミュニケーションズ
   　動画配信サービスの技術・システム担当
   　　・WEB、アプリ
   　　・CMS
   　　・分析基盤（DHW、DMP）
   　　・PUSH通知基盤
   　　・ライブ配信
   　　・R&D
   株式会社テレビ東京コミュニケーションズ
   動画ビジネス部　テックリード
   段野　祐一郎
   [興味関心ワード]
   フロント ：　TypeScript, vue.js
   サーバー ：　Java, PHP(Laravel)
   DB ：　MySQL, Redshift, Treasure Data, BigQuery
   クラウド ：　AWS, GCP
   その他 ：　Firebase, Docker, redash, Talend, Tableau, 機械学習
   

   View Slide

3. 放送と配信を融合させた展開
   テレビ番組の同時配信、ライブ配信など様々なトライアルを他局に先行して実施。
   Brightcove社のビデオアワードを
   過去に2度受賞（2015年、2017年）
   本編と広告をシームレスにつなぐSSAI技術を先行
   導入した事例、地上波視聴率も13.0%を記録。 3
   青春高校３年C組
   マルチプラットフォームライブ展開
   テレビ東京コミュニケーションズの事業
   

   View Slide

4. 広告付き動画配信サービス
   ・テレビ東京のテレビ番組を放送終了後に
   　インターネットで無料で視聴できる見逃し配信サービス
   ・若年層を中心としたテレビ離れや
   　テレビ番組の違法アップロード視聴への対策
   ・2015年4月にサービス開始
   　PCブラウザとスマホアプリを提供
   ・民放5社で協働し、2015年10月にはTVerも立ち上げた
   

   View Slide

5. ・　背景
   ・　要件
   ・　制約
   ・　結果
   ・　今後
   アジェンダ
   Firebaseを活用したPUSH通知基盤構築のよもやま話
   

   View Slide

6. ・　「ネットもテレ東」アプリのリニューアル検討開始
   ・　PUSH通知に使っていたモバイルBaaSのParseが2017/01/28にサービス終了
   ・　アニメ見放題サービス「あにてれ」が2017/04/01にサービスイン予定
   背景
   - 2017 1Q -
   テレビ東京の他サービスのモバイルアプリにおける
   BaaS及び指標共通化を目的に、Firebase(Aalytics)を導入
   

   View Slide

7. アプリのリニューアルの結果は好調
   PUSH通知としてFirebase Notificationsを利用
   ただし、Firebase Notificationsでは、以下の問題が発生。
   　・　Firebase Notificationsの運用負荷が大きい
   　・　Firebase Notificationsでは満たせない要件が増えてきた
   背景
   - 2017 3Q -
   

   View Slide

8. 【Firebase Notificationsの運用負荷が大きい】
   例）先週の放送回の動画を見たが、今週まだ見ていないユーザーへの通知
   背景
   　放送開始時にユーザーリストを作成する運用は負荷が高く、ミスも発生しがち
   　（設定が技術寄りすぎて、マーケチームが作成できない）
   ユーザーリスト
   Firebase Notificationでのターゲティング
   

   View Slide

9. 背景
   別のPUSH通知の仕組みを使うことを本格検討
   - 2017 3Q -
   【Firebase Notificationsでは満たせない要件】
   柔軟な通知要件
   例１）ドラマの新番組の告知通知を、ドラマ関心層に送りたい　など
   　→セグメントが多数必要だが、ユーザーリストの上限は５０個．．．
   例２）プッシュ通知を使った休眠ユーザーの掘り起こし施策
   　→休眠ユーザーの定義を、ユーザープロパティ・ユーザーリストでできない
   

   View Slide

10. ・柔軟なターゲティング設定
    ・お気に入り登録した番組の新着通知（CMS連携）
    ・A/Bテスト
    ・通知結果の取得
    ・開封ログと分析ツールとの連携
    ・100万件に通知
    ・低コスト（無料）
    ・他サービスへの展開の容易さ
    ・サポート（継続的な機能追加）
    要件
    Firebase Cloud Messaging＋α で実現できそう！
    （あまりSDKを増やしたくない）
    

    View Slide

11. Firebase
    が
    頑張る
    イメージ
    アプリ
    App
    Engine
    ①お気に入り番組登録
    ③送信
    ②抽出
    ④開封
    ③送信
    柔軟なセグメント作成は
    Analyticsとかのデータを分析し
    セグメント作って手動登録
    ④開封
    

    View Slide

12. お気に入り機能実装時につまづきそうな制約一覧
    Firebase Notification
    ・topic配信 or FCM配信　　　（「レイテンシ」「送信結果」問題）
    ・送信APIいつの間にかLegacy（推奨APIで１件ずつ送信 or Legacy APIで一括送信）
    Firebase Analytics
    ・User Property（FCMトークンを保存できない）
    ・開封イベント （既存イベント名は使えない）
    Firestore
    ・インデックス （複合インデックスの運用問題）
    ・フィールドパス（key名に注意）
    

    View Slide

13. お気に入り機能実装時につまづきそうな制約一覧
    Firebase Notification
    ・topic配信 or FCM配信　　　（「レイテンシ」「送信結果」問題）
    topic配信は一件ごとの送信可否の内訳が取得できない。
    遅延が大きい[レイテンシではなくスループットに対して最適化]
    → 送信対象はtopicではなく、FCMトークン宛てに送信するようにする
    ・送信APIいつの間にかLegacy（推奨APIで１件ずつ送信 or Legacy APIで一括送信）
    プロジェクト途中でAPIが、いつの間にかLegacyに（新API移行推奨）。
    新APIは、複数宛先一括送信（registration_ids）がない！
    → いつまで使えるかわからないが、パフォーマンスを重視し、Legacyを使用
    

    View Slide

14. お気に入り機能実装時につまづきそうな制約一覧
    Firebase Analytics
    ・User Property（FCMトークンを保存できない）
    Firebase AnalyticsでUser PropertyとしてFCMトークンを出力できない
    （ユーザープロパティの上限は100文字まで[FCMトークンは150文字]）
    FCMトークンをどうやって保存するか
    → Firestoreに送信対象のFCMトークンを保存して、そこから取得する
    ・開封イベント （既存イベント名は使えない）
    自動的に収集されるイベント notification_* は独自FCM実装では計測に使用できない
    → push_open などのカスタムイベントを作成
    

    View Slide

15. お気に入り機能実装時につまづきそうな制約一覧
    Firestore
    ・インデックス （複合インデックスの運用問題）
    お気に入り登録内容（どの番組）と通知許諾（登録状況）を管理したい
    →お気に入り番組名とその登録状況を別フィールドに分けると、新規番組追加時に
    　毎回複合インデックスを貼る必要が出てくる。煩雑でミス防止のため避けたい。
    →番組フィールドに、以下（右図）のように持たす
    　　登録　： タイムスタンプ（milli sec）
    　　解除　： ０
    ・フィールドパス（key名に注意）
    Firestoreには、お気に入り番組のID（godやchogokin-a）を登録していたが、
    　 keyにハイフン（-）が入っている場合、プッシュ送信が失敗する
    →Firestoreの制約。バッククォートで回避
    特定の１つのフィールドには
    自動的にインデックスが張られる
    

    View Slide

16. 実装内容
    

    View Slide

17. 実装内容
    左図：アプリの動画視聴画面に、「お気に入り」ボタン追加
    下図：Firestoreの構造
    devices -> app_instance_id -> device_typeやfcm_token
    

    View Slide

18. 結果
    日次
    累計
    お気に入り番組登録数推移
    お気に入り
    登録数
    日
    　・PUSH通知開封率　　↗
    　・PUSH通知運用負荷　↘
    　・Firebase Analyticsから抽出した特定のセグメントへのPUSH通知が可能
    　・現在、自分の担当外の他VOD事業に実装中
    PUSH基盤管理画面
    

    View Slide

19. 結果
    GAE
    約100万件を20万件ずつ30分に一回送信するように修正（ちょっと怖かったので）
    →最大８個まで自動スケールを確認できた
    

    View Slide

20. 今後
    FCMでやりたいこと
    ・WEBプッシュ
    ・レコメンドと連携したPUSH通知
    ・放送緊急速報や地震速報 通知
    テレビ東京のサービス（HPやアプリなど）の利用者（大規模）に対して、
    遅延なく、放送緊急速報や地震速報連携を行う。
    報道機関として、正しい重要な情報を遅延なく広く届けることが
    非常に重要
    （Firestore?）
    

    View Slide

21. 今後
    Firestoreでやりたいこと①
    スポーツの速報スコアとして活用
    （ページリロードなしで更新可能）
    管理画面
    

    View Slide

22. 今後
    Firestoreでやりたいこと②
    コメント機能
    （再生数だけではなく、ユーザーのコメントを番組制作にフィードバックできる）
    張本がんばれ
    張本、あと一本だ！！！
    マッチポイント！！！
    がんばれーーー！！
    ぜったいいける！
    サービスエースだっ！
    

    View Slide

23. W
    anted
    !!
    色々やりたいことあるものの・・・
    エンジニアが全然足りていません！
    ・無類のテレ東好き
    ・テレビ局はもっとITを頑張るべきだと思う方
    ・テレ東をハックしたいテックギーク
    ・Firebaseを使ったサービスをドンドン作りたい方
    ぜひ、一緒に働きましょう！
    応 募
    

    View Slide

24. Special thanks
    ＆
    ＆
    PUSH基盤開発
    アジャイルコーチング
    アプリ開発
    

    View Slide