2015-03-01

#devsumiC 「14,000 件 /sec の配信を実現したリクルートのモバイル・アプリを支えるプッシュ通知基盤」のメモ

遅ればせながらせっかくなので devsumi2015 で参加してきたセッションのメモを公開していきます。

まずは、「20-C-2 14,000 件 /sec の配信を実現したリクルートのモバイル・アプリを支えるプッシュ通知基盤」から。ひと言で言ってしまうと AWS （ DynamoDB とSQS ) と Elasticsearch の活用事例といったところだったかな、と。

では以降、メモです。

20-C-2 14,000 件 /sec の配信を実現したリクルートのモバイル・アプリを支えるプッシュ通知基盤

R-tech スマートデバイスグループ
- グループ横断的なスマートフォンアプリ開発
Pusna 開発 (プッシュ通知基盤) の進化と変化
Push 通知の特徴
- メルマガに比べて開封率が高く、リアルタイム性も高い -> 効果的な販促ツール
  - 情報レコメンド
  - 休眠ユーザの再起
Recruit の取り組みは 201106 から
- 当初のシステム構成
  - FW: Rails 2.3
  - DB: MySQL
  - デバイス登録数が増えて限界に
    - 処理スピードが遅い
      - 特定時間を狙った訴求ができない
    - 高負荷に耐えられない
      - 各アプリが好きな時間にプッシュ通知を設定できない
スケーラビリティーを求めて再構築
- 2013 Summer, Pusna の再構築
- 結果的に内製を決めた
  - セキュリティの観点も大きかった
- Realtime & Scalable をコンセプト
  - Realtime
    - 各機能の高速化
      - 機能分割
        
        AWS の SQS を利用
      - IO の高速化
        
        AWS DynamoDB を利用
        
        SSD
        
        Schema-less
        
        条件配信は elasticsearch を利用
      - 非同期 IO
        
        node.js
  - Scalability
    - 単純化と分散
- システム構成は資料公開を期待
- @IT に詳細説明の記事があるそう
運用を通じて得た知見
- 事例 (1) デバイス登録キューが詰まる (閾値 1,000)
  - エンキュー処理 < デキュー処理なら起きない
    - DynamoDB のスループットエラーが起こると逆になる
      - リトライ処理が起こると処理が遅延し、キュー詰まる
      - 該当アプリの DynamoDB のスループット値 (Write) を上げる
        
        スマホアプリの実装ミスもあって解決しなかった (無限ループ)
        
        スマホアプリの修正版を緊急リリース
      - 再現しないようにアプリごとにキューを用意するようにした
- 事例 (2) プッシュ後にサーバ側のサーバにアクセス集中
  - Pusna の捌きが後続に比べて速すぎた
- 事例 (3) 登録デバイス数が想定の 2 倍
  - Elasticsearch のキャパ不足が発生
    - シャード数を増やした構成に再構成しようと試みている (現在進行形)
    - シャード数の変更は Elasticsearch はできないが、 Pusna として考慮折込済み
      - デバイス登録ワーカーを止め、更新処理を遅らせている間に ES を再構成するようにしてある
まとめ
- エンジニアは最新技術に挑戦すべき
  - 楽しさ
  - 可能性
    - リスクの見立てて前進
- 運用には想定外があるし、みえなかったリスクが顕在化してくることがあるが、それを乗り越えることによってエンジニアとしてさらなる成長ができる