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

リクルートテクノロジーズ宮川
大規模プッシュ通知基盤を実現したアーキテクチャ
〜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. まとめ

旅行
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!
APNs
Apple Push Notification Service
ユーザがアプリを起動していなくても待ち受け画面に通知を送ることが出来る
GCM
Google 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
Web UI
管理API
データ参照
スマホアプリ内の
PusnaRS用SDK経由で
登録APIにデバイス情報を送信

全体構成～デバイス登録
DynamoDB
elasticsearch
クラスタ
デバイス登録
リクエスト
APNs/GCM
サーバ
登録API
データ登録
配信worker
SQS
SQS
登録worker
Web UI
管理API
データ参照
デバイス情報をDynamoDBと
Elasticsearchに登録

全体構成～配信
DynamoDB
elasticsearch
クラスタ
デバイス登録
リクエスト
APNs/GCM
サーバ
登録API
データ登録
配信worker
SQS
SQS
登録worker
Web UI
管理API
配信者又は事業サーバから
PUSH配信をリクエスト

DynamoDB
elasticsearch
クラスタ
デバイス登録
リクエスト
APNs/GCM
サーバ
登録API
データ登録
配信worker
SQS
SQS
登録worker
Web UI
管理API
配信要求を元に対象デバイ
スを抽出
配信タイプに応じて
DynamoDB又は
elasticsearchから
デバイス情報を抽出

DynamoDB
Elasticsearch
クラスタ
デバイス登録
リクエスト
APNs/GCM
サーバ
登録API
データ登録
配信worker
SQS
SQS
登録worker
Web UI
管理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
Web UI
管理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 Group
Auto scaling Group
CloudWatch CloudWatch
DynamoDB
elasticsearch
デバイス登録
キューの数によって
オートスケール
CPU状況に応じて
オートスケール

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
Web UI
管理API
データ参照

DynamoDBとは
• Amazon DynamoDBはAWSにて提供される分散KVS。
• 複数のAZ（データセンター）にわたってレプリケーションされ
ることで高い信頼性が保証されている。
• SSDで動作しておりデータ量の変化に関係なく高速に動作する。
• スキーマレスにデータを扱える。

DynamoDBのメリット
高速化
メリット
• スループットの管理
• 全件抽出の性能
機能 • スキーマレス
観点
スケーラビリ
ティ

DynamoDBのメリット～全件抽出の性能
DeviceInfo
Hotpepper
TokenToDevice
Hotpepper
DeviceInfo
jalan
TokenToDevice
jalan
・・・
・・・
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のメリット～スループットの管理
DeviceInfo
Hotpepper
Read: 200
Write: 100
TokenToDevice
Hotpepper
Read: 300
Write: 100
DeviceInfo
appA
Read: 3
Write: 1
TokenToDevice
appA
Read: 3
Write: 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
Web UI
管理API
データ参照

ノンブロッキングI/Oとは
DynamoD
B読み込み
配信
Wokrer
APNs/GCM
送信
DynamoD
B読み込み
配信
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 UI
Push配信条件を指定
✔ 対象アプリ:アプリB
✔ 起動回数: 10回以上
✔ 年齢: 18歳以上
デバイス登録API
B
{
“アプリ起動回数”: 120,
“好きなジャンル”: “お笑い”,
“年齢”:”18”
}
付加情報
！

elasticsearchとは
• オープンソースの全文検索エンジン
• Apache Luceneベース
• リアルタイム
• スキーマレス
• 分散環境
• RESTFul API
• 楽観的バージョン制御

elasticsearchのメリット
高速化
メリット
• クラスター構成
• 検索結果の全抽出
機能 • スキーマレス
観点
スケーラビリ
ティ

無停止リリース
インスタンス
削除
運用者
Auto scaling Group
Elastic
Beanstalk
インスタンス
作成Gitサーバ
Auto scaling Group
Elastic
Beanstalk
インスタンス
名変更
リリーススクリプト
upload
Gitリポジトリから最新の
ソースを取得し、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
Web UI
管理API
データ参照

HTML
ブラウザ
APIサーバ
Webサーバ
Java
Script
仕組み上どうしても初回の画面表示が遅くなる

• Backbone.jsをクライアントだけでなくサーバサイドでも動かす
ライブラリ
• 初回のレンダリングをサーバサイドで行うことで高速なレスポン
スを返すことが出来る

mng-view mng-api
SyncHTML
mng-view mng-api
Sync
HTML
ブラウザ
ブラウザ
初回アクセス時
2回目以降
ApiProxy

まとめ
Push通知への要望
5000万デバイス以上に耐えられ
るスケーラビリティ
ノンストップでのリリース
1000万件を15分で一括配信
ビックデータを活用したターゲ
ティングを実現
PusnaRS
Pusna
で
の
課
題
新
た
な
価
値
デバイス数の急増
高水準のSLA
リアルタイムな情報配信
アクティブ率向上への施策
休眠ユーザの再起
PUSH通知基盤としての価値

まとめ
シ
ス
テ
ム
面
運
用
面
処理の高速化
I/Oの高速化
要件の再確認
運用の高速化
使えそうな技術
• elasticsearch等の検索エンジン
• SQS等による非同期連携
• DynamoDB等のKVS
• ノンブロッキングI/O
• Hadoop等のビックデータ技術
• Rendr等のSPA高速化
• 無停止リリース
• リアルタイム・ログ可視化
観点
システムの高速化のポイント

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

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

More Related Content

What's hot

Viewers also liked

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

More from Recruit Technologies