システム高速化フォーラム向けプッシュ通知基盤のアーキテクチャ

リクルートテクノロジーズ宮川

大規模プッシュ通知基盤を実現したアーキテクチャ〜1000万人に15分でプッシュ通知

2

宮川典久

株式会社リクルートテクノロジーズITマネジメント統括部APソリューショングループ

自己紹介

Twitter @m_nori

出身地東京

趣味ロードバイクゲーム（最近はMH4G）折り紙

3(C) Recruit Technologies Co.,Ltd. All rights reserved.

アジェンダ

1. はじめに

2. PUSH通知に対する取り組み

3. 高速化のためのアーキテクチャ

• 全体構成

• 機能間の非同期化

• DynamoDBによるI/Oの高速化

• ノンブロッキングI/Oの活用

• elasticsearchによる条件指定配信

• その他高速化の取り組み

4. まとめ

１．はじめに

4

旅行

IT/トレンド

生活/地域情報

グルメ・美容

ライフスタイル領域ライフイベント領域

進学

就職

結婚

転職

住宅購入

車購入

出産/育児

「選択・意思決定」を支援する情報サービスの提供

→「まだ、ここにない、出会い。」の実現へ

リクルートとは

5

リクルートキャリア

リクルートジョブズ

リクルートスタッフィング

リクルート住まいカンパニー

リクルートライフスタイル

リクルートマーケティングパートナーズ

スタッフサービス・ホールディングス

リクルートアドミニストレーション

リクルートコミュニケーションズ

事業会社

機能会社インフラ部門

大規模プロジェクト推進部門

UI設計/SEO部門

ビッグデータ機能部門

テクノロジーR&D部門

事業・社内IT推進部門

リクルートホールディングス

リクルートとは、主要７事業会社＋３機能会社で構成されるグループ企業群

6

リクルートテクノロジーズとは

リクルートテクノロジーズの役割


開拓

実装、展開運用テクノロジーライフサイクル

≪テクノロジーへの考え方≫

「開拓」「実装・展開」を経た「運用」でリクルートへの利益貢献を行う。

リクルートテクノロジーズの役割


広範囲のビジネスに装着し、効果を最大化させるための改善を行い、事業貢献利益を追究

Rグループのビジネスに短・中期的に実活用の可能性がある技術をリサーチ対象技術における事業化への検証を行い、評価・選定する

開拓（実活用研究）

実際に事業へ適用し、より広範囲に利用するための型化やスキームを構築

実装・展開運用

実施内容

リクルートテクノロジーズ（短・中期的視野）

利益を目的としない中長期的な視点に立ち、新技術や新手法の研究/発明を行い、論文発表することを目指す

要素基礎技術の研究

社外（中・長期的視野）

技術数の推移イメージ

年間約200の技術をリサーチし、約30の技術を評価・選定

年間数個〜10個の技術を展開

運用フェーズまで移行された技術が蓄積

無数の新技術を研究/発明

ASGとは


リクルート共通インフラ

アプリケーション基盤

各サイト各サイト各サイト各サイト

NETWORKOSH/W

M/W framework 共通コンポーネント

開発・運用

アーキテクト支援

先端技術の適用

ASGとは


技術数の推移イメージ

ATL ASG

開拓（実活用研究）実装・展開運用

2．PUSH通知に対する取り組み

11

PUSH通知へとは


Push!

Push!

APNsApple Push Notification Service

ユーザがアプリを起動していなくても待ち受け画面に通知を送ることが出来る

GCMGoogle Cloud Messaging

PUSH通知の効果


メリット

• 休眠ユーザの再起

• ユーザのアクティブ率向上

• リアルタイムな情報配信

デメリット

• 実装の工数がかかる

• 過剰なプッシュによるユーザ離れのリスク

ここに対する取り組みとして2011年にPUSH通知基盤を開発

プッシュ通知は開封率が高いため、メルマガに変わる販促ツールとして注目されている

PUSH通知への取り組み


サービス開始

• 2011年

インフラ

• AWS

開発言語

• Ruby

フレームワーク

• Ruby On Rails

DB

• MySQL

APNs

Pusna

Pusna

構成図構成

GCM

Pusnaの課題


0

5000000

10000000

15000000

20000000

25000000

20120209 20120807 20130203 20130802

2012/12ペースUP

100

120

140

160

180

200

220

2011年 2012年 2013年 2014年10月

アプリ数の遷移

Androidアプリ iOSアプリ

デバイス登録数の遷移

アプリ数の増加に伴いプッシュ数も急増。プッシュ通知の重要性上昇に伴い、求められるSLAも高まる。

Pusnaの課題


Pusna

APNs

Pusna

デバイス数増化に対応するスケーラビリティリアルタイムな情報配信

GCM

Pusnaの課題


アプリの特性に応じてターゲットとなる時間内に送りきれないと効果が激減する

6時 9時 12時 15時 18時 21時 24時

通勤時間昼休み帰宅後帰宅直前

情報発信購買行動の催促仕事後の行動催促

時間内に遅れない場合日を分割する送る運用対処を実施1000万件のPUSHに一週間かかる状況

Pusnaの課題


メリット

• 休眠ユーザの再起

• ユーザのアクティブ率向上


デメリット

• 実装の工数がかかる

• 過剰なプッシュによるユーザ離れのリスク

普及に伴い求められる要件も増加

課題に対する打ち手


課題・要望

• アクティブ率向上への施策

• 求められる高いSLA

• デバイス数の急増


打ち手

AWSの有効活用

アーキテクチャの抜本的変更

ビックデータ基盤との連携• 休眠ユーザの再起

PusnaRSとして再構築することを決断

現行課題

新たな要望

3．高速化を実現したアーキテクチャ

開発概要


開発期間

• 2013年9月～2013年12月

サービス開始

• 2013年12月末

開発体制

• APソリューショングループ：5人

•スマートデバイスグループ：3名

PusnaRS

インフラ

• AWS

開発言語

• Node.js v0.8.26

フレームワーク

• express

DB

• DynamoDB

検索エンジン

• elasticsearch

システム構成開発体制

全体構成

全体構成


DynamoDB

elasticsearch

クラスタ

デバイス登録リクエスト

APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker

システム管理・操作用Web UI

管理API

データ参照

事業サーバ配信担当者

全体構成～デバイス登録


DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

データ参照

スマホアプリ内のPusnaRS用SDK経由で登録APIにデバイス情報を送信


全体構成～デバイス登録


DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

データ参照

デバイス情報をDynamoDBとElasticsearchに登録


全体構成～配信


DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

配信者又は事業サーバからPUSH配信をリクエスト




DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

配信要求を元に対象デバイスを抽出


配信タイプに応じてDynamoDB又はelasticsearchからデバイス情報を抽出



DynamoDB

Elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

抽出したデバイス情報をAPNs又はGCMへ送信


Pusna高速化のポイント


システム面

運用面

範囲

• I/Oの高速化

• 各機能の高速化

• 運用の最適化

ポイント

• elasticsearchによる条件指定配信- 配信条件の指定を実現することにより、配信作業を高速化

• 無停止リリース- システム停止無しでのリリースによりエンハンスを高速化

• 機能間の非同期化- SQSを活用して非同期化し、各処理を単純化

• DynamoDBによるI/Oの高速化- DynamoDBを活用することでI/Oのスピードを高速化

• ノンブロッキングI/Oの活用- ノンブロッキングI/Oの活用によりI/Oの活用効率を最適化

機能間の非同期化



DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

データ参照




登録API 登録Workerデバイス登録キューELB

DynamoDB

elasticsearch

デバイス登録

各機能間の連携をSQSで行うことで、一つ一つの処理を単純化



登録APIの性能登録API

デバイス登録

リクエストの受付

パラメーターチェック

キューへの登録

登録Worker

キューからの受け取り

永続化

キューからの削除

m1.small:60request per second

CPU使用率

Latency

SQSとは


• Amazon Simple Queue Service（SQS）はAWSが提供する分

散キューサービス。

• 高速で信頼性・スケーラビリティに優れ、低コストに使うことが

出来る。

SQSによるメリット


高速化

メリット

•スケーラビリティの確保

•機能分割による機能の単純化

• SNS連携によるシステム拡張性

スケーラビリティ

機能

•リトライ処理の簡易化

観点

SQSによるメリット～スケーラビリティの確保


Auto scaling GroupAuto scaling Group

CloudWatch CloudWatch

デバイス登録キューELB

DynamoDB

elasticsearch

デバイス登録

キューの数によってオートスケール

CPU状況に応じてオートスケール

登録API 登録Worker

SQSによるメリット～リトライ処理の簡易化



DynamoDB

elasticsearch

処理成功時にメッセージを削除しているので処理失敗時は時間

を置いてまた処理される

デバイス登録


SQSのメリット～システム拡張性


Amazon Simple Notification Service（SNS）連携によるシステム拡張性

アプリケーション SNS

SQS

SQS

Eメール

HTTP

SNSを経由してSQSへキュー登録することで後々の拡張性を担保できる

SQSによるメリット～システム拡張性



DynamoDB

elasticsearch

デバイス登録

ビックデータ基盤

BD基盤用デバイス登録キュー

後で実施したビックデータ基盤との連携もシステム改修無しで実現


DynamoDBによるI/Oの高速化

DynamoDBの活用


DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

データ参照


DynamoDBとは


• Amazon DynamoDBはAWSにて提供される分散KVS。

• 複数のAZ（データセンター）にわたってレプリケーションされ

ることで高い信頼性が保証されている。

• SSDで動作しておりデータ量の変化に関係なく高速に動作する。

• スキーマレスにデータを扱える。

DynamoDBのメリット


高速化

メリット

•スループットの管理

•全件抽出の性能

機能 •スキーマレス

観点


DynamoDBのメリット～全件抽出の性能


DeviceInfoHotpepper

TokenToDeviceHotpepper

DeviceInfojalan

TokenToDevicejalan

・・・

・・・

DynamoDB

Elasticsearch登録Worker

device/hotpepper

device/jalan ・・・

配信Worker

単件

全件

検索

アプリごとの全件配信速度の向上が最大の狙い



セグメント1

セグメント2

セグメント3

セグメント4

配信Worker

DynamoDBはデータを物理ストレージにパーティションにデータを保存している。並列スキャンにて各セグメントを平行して抽出し、性能を向上が可能。

DeviceInfo

並列スキャン

DeviceInfo

DeviceInfo

DeviceInfo



並列数件/秒性能比

1 19830.2 1

5 42642.1 2.1

10 43996.6 2.2

リードスループット

• 1,000

1件あたりのデータサイズ

• 200バイト

総データ数

• 100万件

負荷掛け環境

• c1.medum

• node.jsで作ったデモアプリで検証

条件

並列スキャンの性能測定

結果

並列スキャンを行うことで倍以上の性能を出すことが出来る。

ただし、並列数を上げれば性能が上がるわけでもないので、チューニングが必要。

DynamoDBのメリット～スループットの管理


テーブル単位に読み込み性能・書き込み性能を設定可能

DynamoDBのメリット～スループットの管理


DeviceInfoHotpepperRead: 200Write: 100

TokenToDeviceHotpepperRead: 300Write: 100

DeviceInfoappA

Read: 3Write: 1

TokenToDeviceappA

Read: 3Write: 1

DynamoDB

アプリのデバイス数に応じてスループット設定を最適化。

・・・

・・・

Hotpepper appA

DynamoDBのメリット～スキーマレス


DeviceInfoアプリA

付加情報アプリA

ver1.0

年齢都道府県

アプリA

ver1.1付加情報

年齢都道府県性別

アプリのバージョンアップに伴い情報を追加

アプリから送られてくる付加情報をスキーマレスに管理

年齢都道府県

20 東京

年齢都道府県性別

30 神奈川男

ノンブロッキングI/Oの活用

ノンブロッキングI/Oの活用箇所


DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

データ参照


ノンブロッキングI/Oとは


DynamoDB読み込み

配信Wokrer

APNs/GCM送信

DynamoDB読み込み

配信Wokrer

APNs/GCM送信

ノンブロッキングI/OブロッキングI/O

データの送受信の完了を待たずに他の処理を開始する方式



require('fs');

console.log(‘start’);

var data1 = fs.readFileSync(‘hoge.txt’);

console.log(‘file1:’ + data1);

var data2 = fs.readFileSync(‘fuga.txt’);

console.log(‘file2:’ + data2);

console.log(‘end’);

同期IOの場合

start

file1: hoge

file2: fuge

end



require('fs');


fs.readFile(‘hoge.txt’, function(err, data) {

console.log(‘file1:’ + data);

});

fs.readFile(‘fuga.txt’, function(err, data) {

console.log(‘file2:’ + data);

});


start

end

file1: hoge

file2: fuga

非同期IOの場合

コールバック関数を渡し、ファイル読み込み完了のイベントが発生したタイミン

グで処理を行う

ノンブロッキングI/Oのメリット・デメリット


メリット

• 同じ時間の処理量が多い

• I/Oの多重化が容易

デメリット

• 分岐や合流を意識する必要があり、処理が複雑化する

• 流量制御を行わないとOutOfMemoryが発生することが有り、制御が困難

StreamAPIの活用

StreamAPIとは


Node.jsのコアライブラリで、データの流れを操作するためのAPI

I/O結果に対する処理を「一括」ではなく「破片単位」で扱う

読み込み可能、書き込み可能、読み書き可能なStreamを定義

Stream間をパイプで繋げていく

StreamAPIの活用


require('fs');


data = fs.readFile(‘hoge.txt’,

function(err, data) {

console.log(data);

});


var readableStream =

fs.createReadStream(‘hoge.txt‘,

{bufferSize: 1});

readableStream.on('data',

function(data) {

console.log(data);

});

readableStream.on('end',

function() {

console.log('end');

});

一括ファイル読み込みの場合 StreamAPIの場合

データを破片単位に読み込み、非同期に処理を行う

StreamAPIの活用


readStream

• Readable

transformStream

• Readable/Writable

transformStream


writeStream

• Writable

pipe() pipe() pipe()

各処理をパイプで繋げていくことで非同期I/Oを有効活用する

データ1

データ1

データ1

データ1

データ2

データ2データ3

データ4 データ3 データ2

時間

複数のデータを並行処理

StreamAPIの活用


readStream

• Readable

transformStream


transformStream


writeStream

• Writable


全ての処理速度が同じならば問題無し

処理速度

100 100 100 100

StreamAPIの活用


readStream

• Readable

transformStream


transformStream


writeStream

• Writable


後続が遅い場合はあまりをバッファに格納していく

処理速度

100 100 100 50

50

StreamAPIの活用


readStream

• Readable

transformStream


transformStream


writeStream

• Writable


後続が遅い場合はあまりをバッファに格納していく

処理速度

100 100 100 50

500このままではバッファを溢れてしまう…

StreamAPIの活用


readStream

• Readable

transformStream


transformStream


writeStream

• Writable


後続処理は待って欲しい要求を出す

処理速度

100 100 100 50

500

pause()

StreamAPIの活用


readStream

• Readable

transformStream


transformStream


writeStream

• Writable


読み込み処理を停止させる

処理速度

100 100 100 50

500

pause()pause()pause()pause()

StreamAPIの活用


readStream

• Readable

transformStream


transformStream


writeStream

• Writable


バッファを先に処理する

処理速度

100 100 100 50

500

StreamAPIの活用


readStream

• Readable

transformStream


transformStream


writeStream

• Writable


バッファをある程度捌いたら処理を再開させる

処理速度

100 100 100 50

50

resume()resume()resume() resume()

配信処理の構成


DynamoDB

Elasticsearch

APNs

GCM

ConnectionPool

KeepAlive

データ抽出

データ形

式変換

一定件数単位に

送信

処理結果

保存

配信キュー

アプリID:xxx配信タイプ:* 全デバイス* デバイスID指定

* デバイスIDリスト* 検索条件指定

* 検索条件

search

scan

get

配信処理の構成


// データ抽出streamを作成var searchStream = new SearchStream(query);

// データ抽出Streamに各Streamを連結させる

searchStream.pipe(transferStream) //データ変換用stream.pipe(pushStream) //Push配信stream.pipe(resultStream); //結果格納用のstream

配信処理は全てをStreamにて実装

配信処理の性能


総データ数

• 1000万件

リードスループット

• 100

対象デバイス

• iOS

負荷掛け環境

• c1.medum

条件

性能測定

結果

配信時間

12分

秒間配信件数

14000

配信処理の性能


Auto scaling Group

CloudWatch

配信キュー

配信Worker

配信Worker

配信Worker

同時に複数の大量配信要求が来ても対応可能

APNs

GCM

自身の処理状況に応じてキューを取得するか判断する。

elasticsearchによる条件指定配信

運用レベルでの課題


デバイスリストCSVによる運用

現行Pusnaの配信運用

1 デバイスリストCSVダウンロードを行う

2 デバイスリストCSVを編集

3 配信登録画面よりCSVアップロードし、登録

4 配信バッチにてプッシュ送信

CSV作成のコストは非常に高い。

数百万デバイスのCSVを作成するとシステム全体に大きな負荷がかかる。

デバイスリストCSVの編集に手作業が必要となるため運用コストが高い。

【課題】

• 一部サイトではダウンロードしたデバイスリストCSVにより、マスタデータ管理を行っているサイトもある状況

運用レベルでの課題


現行Pusnaの配信運用

1 デバイスリストCSVダウンロードを行う

2 デバイスリストCSVを編集

3 配信登録画面よりCSVアップロードし、登録

4 配信バッチにてプッシュ送信

デバイスリストCSVによる運用の変更

PusnaRSの配信方法

1 全デバイス配信

2 条件指定配信

3 デバイス指定配信

ビックデータ基盤との連携

条件指定配信


プッシュ配信API

管理用Web UIPush配信条件を指定✔ 対象アプリ:アプリB✔ 起動回数: 10回以上✔ 年齢: 18歳以上

デバイス登録API

B

{“アプリ起動回数”: 120,“好きなジャンル”: “お笑い”,“年齢”:”18”

}

付加情報

！

elasticsearchとは


• オープンソースの全文検索エンジン

• Apache Luceneベース• リアルタイム• スキーマレス• 分散環境• RESTFul API• 楽観的バージョン制御

elasticsearchのメリット


高速化

メリット

•クラスター構成

•検索結果の全抽出

機能 •スキーマレス

観点


その他の取り組み

無停止リリース

無停止リリース


インスタンス削除

運用者

Auto scaling Group

Elastic

Beanstalk

インスタンス作成Gitサーバ

Auto scaling Group

Elastic

Beanstalk

インスタンス名変更

リリーススクリプト

uploadGitリポジトリから最新のソースを取得し、Beanstalk環境を再作成する。

release動作中のBeanstalkと新規に作成したBeanstalkのインスタンス名を変更して、接続先を切り替える。

destroy旧環境を削除する。

リアルタイムでのログ可視化

リアルタイムでのログ可視化


td-agent

Access.log

Node.log

td-agent

Access.log

Node.log

td-agent

Access.log

Node.log

pub-que

reg-que

reg-api

Elasticsearchfluentd server

管理サーバ

Kibana

Kibana

Amazon S3

log

シングルページアプリケーションの高速化



DynamoDB

elasticsearch

クラスタ


APNs/GCMサーバ

登録API

データ登録

配信worker

SQS

SQS登録worker


管理API

データ参照




HTML

ブラウザ

APIサーバ

Webサーバ

JavaScript

仕組み上どうしても初回の画面表示が遅くなる



• Backbone.jsをクライアントだけでなくサーバサイドでも動かす

ライブラリ

• 初回のレンダリングをサーバサイドで行うことで高速なレスポン

スを返すことが出来る



mng-view mng-api

SyncHTML

mng-view mng-api

Sync

HTML

ブラウザ

ブラウザ

初回アクセス時

2回目以降

ApiProxy

4．まとめ

まとめ


Push通知への要望

5000万デバイス以上に耐えられるスケーラビリティ

ノンストップでのリリース

1000万件を15分で一括配信

ビックデータを活用したターゲティングを実現

PusnaRS

Pusn

a

での課題

新たな価値

デバイス数の急増

高水準のSLA

リアルタイムな情報配信

アクティブ率向上への施策

休眠ユーザの再起

PUSH通知基盤としての価値

まとめ


システム面

運用面

処理の高速化

I/Oの高速化

要件の再確認

運用の高速化

使えそうな技術

• elasticsearch等の検索エンジン

• SQS等による非同期連携

• DynamoDB等のKVS

• ノンブロッキングI/O

• Hadoop等のビックデータ技術

• Rendr等のSPA高速化

• 無停止リリース

• リアルタイム・ログ可視化

観点

システムの高速化のポイント

まとめ

リクルートテクノロジーズではPusnaRS以外も様々な先端技術にてリクルートのビジネスに貢献しています！



Software

システム高速化フォーラム向け プッシュ通知基盤のアーキテクチャ

システム高速化フォーラム向けプッシュ通知基盤のアーキテクチャ