[レポート][Dev-05:Mobile] 900万ダウンロードアプリ『Gunosy』を支える大規模モバイルプッシュ通知基盤 #AWSSummit

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!おおはしりきたけです!
今回は、900万ダウンロードされているニュースアプリのGunosyさんがAmazonSNSを使ったモバイルプッシュの配信基盤のお話になります

セッション情報

  • セッション名:900万ダウンロードアプリ『Gunosy』を支える大規模モバイルプッシュ通知基盤
  • スピーカー:株式会社Gunosy 榎本敏丸氏

Gunosyのプッシュ基盤

Gunosyとプッシュ通知

  • モバイルプッシュ通知はDAUを支える重要要素
  • プッシュ通知はGunosyアプリを開くきかかけを与える →ユーザーリテンション
  • プッシュ通知結果がDAUを左右する
    • プッシュの内容により、DAUの増減がある

Pushは大きく2つ

1.定時プッシュ

  • 朝・昼・夕方・夜の決まった時間のプッシュ通知

2.速報プッシュ

  • 速報性のある即時送りたいプッシュ通知
  • 例:大きな地震、大きな事件

定時プッシュ

  • いつ?:ユーザーが設定した時間
  • 誰に?Push通知を設定したユーザーに
  • どれくらいで:負荷をかけずできるだけ短時間
  • 何を?適切なタイトル・内容でプッシュ通知を送る

定時プッシュはゆるやかに打つ

速報プッシュ

  • いつ?大きな事件・事故が起こった瞬間
  • 誰に?Push通知を設定したユーザー
  • どのくらい?できるだけ短時間
  • 何を?適切なタイトル・内容でプッシュ通知を送る

Gunosyプッシュ通知の歴史と変遷

  • 1期:ローカルプッシュ
  • 2期:リモートプッシュ
  • 3期:本格リモートプッシュ
  • 4期:パーソナライズドプッシュ

第1期:ローカルプッシュ時代

  • 設定された時間にニュースが届きましたという定型文

結果

  • プッシュ通知をキッカケにアプリを立ち上げるユーザーが増加
  • まずまずの開封率
    • 定型文ではニュースの内容がわかない
    • 毎日同じ時間に定型文が送られてくるので、ユーザーが飽きたのではないか?

第2期:リモートプッシュ時代

  • AmazonSNSの導入
  • ニュースが更新されました「ニュースタイトル」ほかという通知
  • ローカルプッシュ→リモートプッシュの移行

結果

  • プッシュの開封率は大幅アップ
  • プッシュ通知→DAU向上
  • 日によってDAUが爆発的に伸びた。
  • 現在では当たり前のリモートプッシュだけど当時は少なかった。

雑なプッシュ通知運用

  • ・開発者がサーバーにSSHログインしてプッシュのためのコマンドを打つ
  • ・プッシュ通知管理画面が不安定

第3期:本格リモートプッシュ時代

  • SNSを用いたリモートプッシュ通知の本格運用
  • 大規模プッシュに耐えるアーキテクチャをきちんとゼロから考える

定時プッシュ

dev04-1

  • モバイルエンドポイント取得
  • Redisにエンキュー
  • ワーカーにデキュー
  • SNSにPublish

1インスタンスあたりのPushは、1秒間に400Pushできる。インスタンスサイズはt2micro。インスタンスサイズが小さいので、1インスタンスあたりの価格が1時間0.02$と非常にお得

  • 時間帯で増減するインスタンス
  • OpsWorksで運用を行っている。

プッシュアーキテクチャ

  • Redisを用いたシンプルなpub/sub
  • スケーラブルなプッシュワーカー ワーカーをスケールさせれば早く打てる。
  • タイムベーズなインスタンスで低コスト運用

速報プッシュ

dev04-2

管理画面をRailsで作っている

プッシュ管理画面

  • プッシュ内容・タイトルを設定する管理画面
  • Rails +Sidekiq
  • Sidekiqワーカーがエンドポイント取得、Redisにエンキュー

モバイルエンドポイント取得SQLが遅かった。クエリだけで10分かかっており、高速化対策を行った。

高速化対策を行った速報プッシュのアーキテクチャ

dev04-3

DataPipelineで定期的にエンドポイントのデータを取得しS3に配置する構成。結果10分から15秒になった

第4期:パーソナライズドプッシュ時代

  • ユーザーの趣向に応じたプッシュ通知
  • 絶賛開発中!

パーソナライズドプッシュのアーキテクチャ構成

dev04-4

  • Djangoでプッシュリクエスト受け付け
  • Celeryでタスクキューイング
  • 疎結合なワーカー郡

GunosyでのAmazonSNS利用事例

SNS用語

  • Device Token:アプリケーションの識別子。各プラットフォームが発行
  • Endpoint Arn:Device Tokenから生成されるモバイルエンドポイント、SNSではこのモバイルポイントを使ってプッシュが送られる

SNSのメリット

APNS/GCMの各プラットフォームのAPIを抽象化、プラットフォームごとの違いを意識する必要がない

価格

  • 100万リクエスト/月無料
  • 超過する場合100万リクエスト毎に$0.5

デバイストークン管理の難しさ

1.デバイストークンが変わる(Android)

デバイストークンはどう変わる?

  • アプリを再インストール
  • データを削除された時
  • アプリをバージョンアップした時

デバイストークンは定期的に更新する必要がある。

ポイント
・デバイストークンを定期的に更新
・更新されたデバイストークンを元にバッチ側で再度モバイルエンドポイント生成

2.Enable/Disble制御

弊社のこの記事の紹介

SNSでは何度か通知に失敗した場合endpointがdisableになる一度disableになると以降PublishしてもAPNSが叩かれることはない
どうするか?
寝ているEndpontArnを起こす(Re-enable処理)

3.DisableなEndpointArnの削除

  • モバイルエンドポイントのムダなPublishはしたくない
  • SNSへのPublish時にdisableなEndpointArnは削除

#SNSベストプラクティス

  • デバイスごとにデバイストークンを管理
  • 定期的にデバイストークンをチェックして更新
  • モバイルエンドポイントのRe-enable処理
  • disableなEndpointArnは削除してムダなPublishは控える

感想

弊社でもSNSはよく利用しますが、大規模プッシュのインスタンスにt2microを利用しているというのは衝撃でした。t2microでもSNSへのPublishだけなので処理的には大きくないのと、スケーラブルにして配信管理をすることができるので、クラウドのメリットを非常に感じることができました。現在実装中のパーソナライズドプッシュもリリースされたらまたお話が聞きたいです!