[developers summit 2015 講演資料] リクルートテクノロジーズ...

株式会社リクルートテクノロジーズ ITマネジメント統括部

ITマネジメント1部スマートデバイスグループ

樋口勝彦

14,000件/秒の配信を実現したリクルートのモバイルアプリを支えるプッシュ通知基盤～AWS上での開発・運用の中で見えてきた課題と解～

2015/2/20

2

ひぐちかつひこ樋口勝彦

株式会社リクルートテクノロジーズ ITマネジメント統括部 ITマネジメント1部スマートデバイスグループ

自己紹介

3年間SIer 2年間決済系システム開発

リクルート 2013/5～

Tizen アプリ開発

Pusna開発（プッシュ通知基盤）

FirefoxOS アプリ開発

幻の

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

R-Tech スマートデバイスGはリクルートグループのネイティブアプリ領域における

開発/ビジネスを牽引する横断組織

プラットフォーマーとの密なリレーション構築・情報収集

アプリ戦略の実現

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

リクルートテクノロジーズのアプリ開発

R-tech スマートデバイスG


話すこと

ここ3年半のモバイル領域の急激な変化と

共に歩んできたあるプッシュ通知基盤システム

の変化/進化について


目次

リクルートとプッシュ通知との歩み

第1章旧システムの限界に直面

第2章スケーラビリティを求めての再構築

第3章運用を通して顕在化した課題

第4章まとめ


目次





第4章まとめ

7

Push通知とは？



Push!

APNs Apple Push Notification Service

スマートデバイスの待ち受け画面に送る通知 (アプリ起動しなくても表示される)

プッシュ通知とは？

Push!

GCM Google Cloud Messaging

アプリチーム


メルマガに比べて開封率が高く、リアルタイム性があり効果的な販促ツールとして認知されている

プッシュ通知の特徴

ユーザのアクティブ率向上に効果的：

• リアルタイム性を考慮した情報推薦

• 休眠ユーザの再起

アプリでの利用例:

新鮮度がある/話題になるニュースをお届け！

登録条件に合致する新着物件をお知らせ！

自分に好意を持った人をお知らせ！

10

リクルートのプッシュ通知への取り組みは2011年6月から


11

プッシュ通知対応の工数削減を目的にプッシュ通知基盤を

フィジビリ・サービスとして各アプリに展開


12

プッシュ通知対応の工数削減を目的にプッシュ通知基盤を

フィジビリ・サービスとして各アプリに展開

Pusna Push Notification Aggregator

プッシュ通知基盤

13

当時のシステム構成

開発言語 Ruby 1.8系

FW Rails 2.3系

DB MySQL 5.4系

APNs

デバイス登録

プッシュ依頼

Pusna

GCM

14

デバイス登録数の遷移

11年6月

プッシュ通知基盤 Pusna フィジビリ・サービス化

時間

登録デバイス数

2011.06

15


11年6月時間

登録デバイス数

プッシュ通知基盤 Pusna フィジビリ・サービス化

2011.06

16


X,000,000

11年6月 13年5月 13年7月 12年8月時間

17


X,000,000

11年6月 13年5月 13年7月 12年8月

X00万デバイス越

時間

2012.08

18


X5,000,000

11年6月 13年5月時間

19


X5,000,000

11年6月 13年5月時間

樋口リクルートテクノロジーズ入社

2013.05

20


X5,000,000

11年6月 13年5月

2013.05 樋口入社

この頃樋口は、

21


X5,000,000

11年6月 13年5月

2013.05 樋口入社

(幻の)

アプリ開発に。

22


X5,000,000

11年6月 13年5月

2013.05 樋口入社

(幻の)

アプリ開発に。


２ヶ月後

24


X0,000,000

11年6月 13年7月

25


X0,000,000

11年6月 13年7月

樋口 Pusna のチームリーダーに。

2013.07

26


X0,000,000

11年6月 13年7月


2013.07

当時システムは既に限界を迎えていた

27


X0,000,000

11年6月 13年7月


2013.07

(システム構成図)

デバイス登録

APNs

Pusna

GCM

プッシュ依頼

28


X0,000,000

11年6月 12年8月 13年5月 13年7月

2013.07 樋口チームリーダー抜擢

デバイス数急増

APNs

Pusna

GCM

プッシュ依頼

デバイス登録

29


X0,000,000

11年6月 12年8月 13年5月 13年7月



APNs

Pusna

GCM

プッシュ依頼

デバイス登録

30


X0,000,000

11年6月 12年8月 13年5月 13年7月



APNs

Pusna

GCM

プッシュ依頼

デバイス登録


当時のシステムで発生していた問題

問題1:

「配信スピードが遅く、

届けたいタイミングでメッセージが送れない。」

└1000万件の配信に1週間を要した。

問題2:

「高負荷にシステムが耐えられないため、

各アプリが好きな時間にプッシュ依頼できない。」

└各アプリ担当者のプッシュ時間を調整する必要あった。



問題1:




問題2:






問題1:




問題2:




配信

処理開始

配信

処理終了

問題1 特定時間帯を狙った訴求ができない (例: 昼休み)

昼休み

終了

効果的効果が期待できない



問題1:




問題2:






問題1:




問題2:




当時、樋口の仕事

問題2 好きな時間にプッシュ依頼ができない。



問題1:



各アプリ担当者のプッシュ時間を調整する必要あった。

問題2:


カスタマーに届けたいメッセージが送れない。」

1000万件の配信に1週間を要した。


システム担当者

今日のプッシュスケジュール教えてください



問題1:




問題2:





Aアプリ担当

12時からプッシュする予定です。





問題1:




問題2:





Aアプリ担当




Bアプリ担当




問題1:




問題2:





Aアプリ担当




Bアプリ担当


Cアプリ担当

12時からプッシュしたいです。



問題1:




問題2:





Aアプリ担当


Bアプリ担当


Cアプリ担当


システム担当者の頭の中

3アプリ同時は無理。。 Aアプリの規模は大きいから時間かかるし、Bはニュースアプリだから後回しできない。

Cは…(略)。 B->A->Cで調整してみよう。



問題1:




問題2:





Bアプリ担当


Cアプリ担当



>Aさんプッシュ依頼時刻ですが、14時からに変更できないでしょうか？？ >Cさんお昼はシステムが混み合っておりまして、夕方頃プッシュが可能になる見込みです。追って、ご案内させてください。大変申し訳ございません。



問題1:




問題2:







Cアプリ担当



問題1:




問題2:





システム担当者樋口


Cアプリ担当


本当に申し訳ございません。。



問題1:




問題2:





システム担当者樋口


Cアプリ担当


本当に申し訳ございません。。


プッシュ配信の交通整備人

俺・・・何してんだろう



問題1:




問題2:




キャパシティ限界を迎えていた


目次





第4章まとめ


プッシュ配信基盤の再構築

2013年夏 Pusnaの再構築が決定！


再構築の背景

Pusnaの再構築が決定！ 2013.夏

論点

・外部ASPの利用も考慮に入れ検討。 └各アプリチームの要望に迅速対応できる内製化に。

アプリチームの要望例

・既存システムとの連携・レコメンドプッシュ・セキュリティ観点 (事業会社間でのアクセス制限など)


再構築で解決する課題

課題1:

届けたいタイミングでメッセージが送りきれない

└Realtime 課題2:

各アプリ担当が好きな時間にプッシュ依頼できない

└ Scalable

キャパシティ問題の解決が最優先

50

Realtime &

Scalable

再構築のコンセプト

51

Realtime &

Scalable 数千万台デバイスのアクセスに耐える

1000万人に15分以内に配信できる

再構築のコンセプト

52

Pusna Push Notification Aggregator

旧プッシュ通知基盤

53

Pusna Realtime

Scalable

54

Pusna-RS Push Notification Aggregator

Realtime & Scalable

新プッシュ通知基盤


Realtime & Scalable 実現のため

基本アイディア Scalable └単純化と分散

Realtime └高速化 └各機能の高速化 └IOの高速化

機能間の非同期連携



基本アイディア

利用ツール

Scalable └単純化と分散


DynamoDBによる I/Oの高速化

非同期I/Oの活用 I/Oの最適化





利用ツール




非同期I/Oの活用 I/Oの最適化 APNs

旧Pusna

GCM

デバイス登録

プッシュ依頼

改善ポイント①





利用ツール





旧Pusna

GCM

デバイス登録

プッシュ依頼






利用ツール





旧Pusna

GCM

デバイス登録

プッシュ依頼


機能分割





利用ツール






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

分散キューサービス。

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

使うことが出来る。

SQSとは





利用ツール





改善ポイント②

APNs

旧Pusna

GCM





利用ツール






APNs

旧Pusna

GCM





利用ツール






I/Oの高速化

APNs

旧Pusna

GCM





利用ツール






DynamoDBとは

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

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

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

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

高速に動作する。

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





利用ツール









利用ツール





「高速化」＆「単純化と分割」で Realtime & Scalable を実現


積極的に最新技術を採用

AWSの機能をふんだんに利用


積極的に最新技術を採用

AWSの機能をふんだんに利用

リクルート内サービスで運用実績のないソフトウェアも積極採用 ※2013年秋頃当時

72

Pusna-RS Push Notification Aggregator

Realtime & Scalable

アーキテクチャについて


DynamoDB

elasticsearch クラスタ

デバイス登録リクエスト

APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker

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

管理API

データ参照

事業サーバ配信担当者

全体構成

SQS


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

登録worker

管理API

データ参照


全体構成


SQS

SQS

SQSを利用した機能間の非同期連携

を実現


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

登録worker

管理API

データ参照


全体構成


SQS

SQS

I/Oの高速化


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照


全体構成

①デバイス登録

SQS


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照


全体構成

SQS

②配信登録


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照


全体構成

SQS

③配信依頼


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照


デバイス登録処理


SQS

80

DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照




SQS

スマホアプリ内の PusnaRS用SDK経由で

登録APIにデバイス情報を送信



DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照



SQS

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



DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照


配信登録

SQS

②配信登録


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API


配信登録

SQS

②配信登録

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


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API

データ参照


配信依頼処理

SQS

③配信依頼


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API


配信依頼処理

SQS

③配信依頼

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

配信タイプに応じて DynamoDB または elasticsearchから

デバイス情報を抽出


DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

SQS 登録worker


管理API


配信依頼処理

SQS

③配信依頼

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

87

[PR]詳細については@IT連載記事を参照

http://www.atmarkit.co.jp/ait/articles/1412/18/news022.html


http://www.atmarkit.co.jp/ait/articles/1412/18/news022.html

88

結果

89

再構築 BEFORE / AFTER

✔ □ Realtime 配信スピード:

(旧) 秒間最大41件 (新) 秒間最大 14,000件

1000万台配信実績:

(旧) 1週間 ※(分割配信) (新) 12分

90


✔

✔

□ Realtime 配信スピード:



(旧) 1週間 ※(分割配信) (新) 12分

□ Scalable 登録デバイス数が数千万を超えた現在も

リリースから1年以上、完全無停止で安定稼働中

91


✔

✔

□ Realtime 配信スピード:



(旧) 1週間 ※(分割配信) (新) 12分

□ Scalable 登録デバイス数が数千万を超えた現在も

リリースから1年以上、完全無停止で安定稼働中

92

そのシステムがスマートデバイスの急速な普及により大変な状況に！

そして平穏な日々を手に入れた


目次





第4章まとめ

95


平穏な日々を手に入れた

96


平穏な日々を手に入れた

はずだった・・・

97

ある日の定時後。。完璧に作りきった

Pusna-RS だったが、本格運用中に発覚した

事例を3つ紹介

この章で話すこと


98

事例①


99

ある日の定時後アラートメールを受信

100


デバイス登録キューが詰まっている (閾値1,000)

※ 稀に発生していた


101



※ 稀に発生していた

説明


102

デバイス登録のキュー詰まりについて

登録 API

登録Worker

キューの処理スピード

≦

登録キュー

エンキュー処理デバイス登録API

リクエスト

デキュー処理 DynamoDBへの

書込み


103


登録 API

登録Worker


≦

登録キュー

エンキュー処理デバイス登録API

リクエスト


書込み

DynamoDBで書込みエラーが発生しないためキュー詰まりは発生しない


104



＞エンキュー処理デバイス登録API

リクエスト


書込み

登録API 登録Worker 登録キュー


105




リクエスト


書込み

スループットエラーが発生


リトライ処理開始


106




リクエスト


書込み



107




リクエスト


書込み

DynamoDBで書込みエラーが発生し処理が止まるため、キューが詰まりが発生する。



登録キュー登録Worker

108


登録API

キュー詰まり対策


スループットエラー発生中


109


登録API

該当アプリのDynamoDB スループット値(Write)を上げる



スループットエラー発生中


110


登録API



アプリC

アプリB

アプリA



111


登録API



アプリC

アプリB

アプリA

スループット値を上げる



112


登録API



アプリC

アプリB

アプリA

スループットエラー発生中スループットエラー緩和される



113


登録API





114


登録API




詰まり解消

115



[再掲]


116



[再掲] (型化されている運用通り) 該当アプリのDynamoDB

スループット値(write)を上げた。

対応

117





想定

対応

118





閾値

t

キューの深さ

Writeスループット向上想定

対応

119





実際

対応

120





実際

対応

閾値 (1,000)

t

キューの深さ

Writeスループット向上

121





実際

対応キューの深さ

140万件まで膨れ上がる

(ﾟ∀ﾟ；)ﾔ・・・ｬﾊﾞ.

閾値 (1,000)

t

キューの深さ

Writeスループット向上

122

該当アプリ以外の処理も遅延することに

デバイス登録処理遅れています

123

起きていた現象

スマホアプリの実装ミスデバイス登録完了のコールバックで再度デバイス登録をする実装に。

原因



リクエスト

124


レスポンス


原因

デバイス登録の無限ループが起きていた



125



原因



徐々にループする端末も増える

126


登録API


原因




127


登録API


原因


ループ端末も増え続ける



128


登録API


原因


キュー詰まり発生ループ端末も増え続ける



129


登録API 登録キュー登録Worker


誤った打ち手1

130




DynamoDBスループット値を上げる

誤った打ち手1

131




スループット値を上げる


誤った打ち手1

132




デバイス登録リクエストのループは継続するためキュー詰まりは解消しない


誤った打ち手1

133




134





135





負荷が高まる

136




誤った打ち手2

137




登録APIサーバーのスケールアウト(2台->10台)

誤った打ち手2

138





誤った打ち手2

139





誤った打ち手2

さらに無限ループが加速

140


登録キュー (詰まり中)


誤った打ち手2


141


登録キュー (詰まり中)


誤った打ち手2


無限ループの影響で他アプリのデバイス登録の遅延が発生した

142

単体のスマホアプリのミスによる影響が他アプリにも生じてしまうアーキテクチャであること

着目した問題点

スマホアプリの修正版を緊急リリース

暫定対応

デバイス登録キューをアプリ毎に分割

打ち手

事象「無限デバイス登録」のまとめ



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

DynamoDB

elasticsearch

デバイス登録

アプリA

アプリA

アプリB

アプリB

アプリC

全てのアプリのデバイス登録処理を一つのキュー(SQS)で管理

BEFORE

アプリAから大量のアクセスでアプリB,Cの登録処理が遅延しまった


登録API 登録Worker

アプリA登録キュー

ELB

DynamoDB

elasticsearch

デバイス登録

アプリA

アプリA

アプリB

アプリB

アプリC

一つのキューから大量に取得しないように取得数を制御している

アプリB登録キュー

アプリC登録キュー

アプリ毎にキュー(SQS)を分割することで遅延リスクを最小限に

AFTER

145

事例からの学び

プラットフォームとして

単体アプリの影響が全体におよぶ構成にしてはならない

146

事例②


147

ある日の午後あるサービス担当者からの訴え


148

ある日の午後あるサービス担当者からの訴え

プッシュ後サービス側のサーバに

アクセス集中して耐えられません！何とかして！


149


APNs/GCM Pusna-RS

プッシュ依頼


150


APNs/GCM Pusna-RS

配信


151


APNs/GCM Pusna-RS


152


APNs/GCM Pusna-RS


153


APNs/GCM


プッシュ後アプリ起動時に発生する

デバイス登録の一斉リクエスト問題なく捌けていた

Pusna-RS

154


APNs/GCM Pusna-RS


一方でサービス側のサーバは

悲鳴を挙げていた

しかし

サービス

156


APNs/GCM Pusna-RS

サービスに対するリクエスト


157


APNs/GCM Pusna-RS



158


APNs/GCM Pusna-RS


サービス

例えば、500万デバイスにプッシュする場合

7分弱※1の間に

アプリのアクティブユーザが

50万※2増えることになる

※1 配信スピード: 秒間14,000件換算 ※2 プッシュ通知の開封率: 10% 換算

スピード違反

スピード違反ではなく

考慮不足

161

対応

配信Worker 配信キュー APNs/GCM

READ

配信ごとに大まかな秒間配信数を指定できるように修正

打ち手

修正内容

プログラム内でデータソースへのScan間隔を制御することで配信速度をコントロール

一定間隔を置いてアクセス


データソース

162


サービス全体のユースケースを考慮したアーキテクチャにすべき

163

事例③


164

今取り組んでいる話

当初想定していた2倍のスピードで登録デバイス数が

想定のX千万に到達！


165

想定Doc数 5,000万

シャード 4

レプリカ数 3

ノード数 6

Elasticsearchの構成

クラスター情報

想定Doc数を超え 1シャード当たり 1000万を超える

データ量


166


シャード 4

レプリカ数 3

ノード数 6




データ量

当然、1回1回の検索時間も長くなり、負荷が高まる

167


シャード 4

レプリカ数 3

ノード数 6




データ量

セグメンテーションプッシュの

利用頻度も上がり、

高負荷な状態は慢性化していた

さらに

168


シャード 4

レプリカ数 3

ノード数 6




データ量

OutOfMemoryが発生！

そんな時

169


シャード 4

レプリカ数 3

ノード数 6




データ量

OutOfMemoryが発生！

一部のプッシュが遅延した。

そんな時

170

打ち手

1シャード当たりのドキュメント数が多く検索負荷が高い

問題

事象「Elasticsearch高負荷」のまとめ

シャード

想定Doc数

Doc数/シャード

4

5,000万

現

1,250万


171

シャード数を増やした構成に再構築する

打ち手


問題


シャード

想定Doc数

Doc数/シャード

4

5,000万

現

1,250万


172


打ち手


問題


シャード 10↑

- 想定Doc数

変更後すぐ

500万↓ Doc数/シャード

4

5,000万

現

1,250万


173


打ち手


問題


シャード 10↑

- 想定Doc数

変更後すぐ

500万↓ Doc数/シャード

未来

10

1億

1,000万

4

5,000万

現

1,250万


174


シャード 4

レプリカ数 3

ノード数 6




データ量

シャード数の変更は

オンラインではできない。

しかし

175


シャード 4

レプリカ数 3

ノード数 6




データ量

シャード数の変更は

オンラインではできない。

しかし

176

オンラインでのESシャード数変更

デバイス登録ワーカーを止め、更新処理を遅らせている間にESクラスターを再構成

登録 API

登録キュー

登録Worker

旧ES


177



登録 API

登録キュー

登録Worker

旧ES

新ES

新しいESクラスターを用意


178



登録 API

登録キュー

登録Worker

旧ES

新ES

登録Workerを停止


179



登録 API

登録キュー

登録Worker

旧ES

新ES

データ移行開始


180



登録 API

登録キュー

登録Worker

旧ES

新ES

データ移行開始データ移行完了！


181



登録 API

登録キュー

登録Worker

旧ES

新ES

登録Workerを再起動


182


継続的にシステムをモニタリングし再度未来を見立て

常にアーキテクチャを最適な状態に変化させていくべき


目次





第4章まとめ

184

エンジニアは

新技術に挑戦すべき

伝えたいこと


185

楽しい

186

可能性

187

新技術に挑戦すべき理由

リスク

188


見えない

189


リスクを見立てる

190


前進

191


行き止まり

192

行き止まりリリース

193


運用

194


想定外

195


リスク顕在化

196


リスクと向き合う

197


向き合う

198


向き合い続ける

199


チームが強くなる

200


貢献

201

伝えたいこと(再掲)

エンジニアは新技術に挑戦すべき

伝えたいこと




Pusna-RS アーキテクチャのポイント


利用ツール







Pusna-RS アーキテクチャのポイント


利用ツール





DynamoDB



APNs/GCM サーバ

登録API

データ登録

配信worker

登録worker

管理API

データ参照



SQS

SQS

SQSを利用した機能間の非同期連携

を実現

I/Oの高速化

205

リクルートテクノロジーズでは新技術に挑戦したくてウズウズしてる

一緒に働く仲間を募集中です！！


206

ご清聴ありがとうございました！


[developers summit 2015 講演資料] リクルートテクノロジーズ...

Mobile