Storm×couchbase serverで作るリアルタイム解析基盤

Copyright © NTT Communications Corporation. All rights reserved.
Storm × Couchbase Serverで作る
　　　リアルタイム解析基盤
NTTコミュニケーションズ株式会社
技術開発部　松⽥田徹也
2015年年6⽉月11⽇日

今⽇日話すこと
2
n  Couchbase Server概要（Couchbase Japan 河村さん）
n  リアルタイム解析について
n  Couchbase ServerとStormを使ってクラウド上で実装した事例例
•  アーキテクチャ
•  苦労したこと、⼯工夫したこと
n  Couchbase Serverの気に⼊入ってる所、イマイチだと思った所

⾃自⼰己紹介
3
{
名前：松⽥田徹也（tetsuyam）,
所属：
｛会社：NTTコミュニケーションズ,
部署：技術開発部,
チーム：クラウドコアテクニカルユニット}, 　　
twitter：@tetsuyam_̲twt,
興味：[クラウドデザイン,
⾃自動化,
ストリーム処理理]
｝

データ解析
バッチ処理による解析
ストリーム処理による解析
①  ログ解析によるサイトやサービスに対
するアクセス分析
②  過去ログをベースに、レコメンドエン
ジンを利利⽤用したサービス性向上
バッチ処理理で実現する領領域。
バッチ処理理を早く終わらせて、結
果を出すことが重要。
利利⽤用されるプロダクト例例：
Hadoop, Spark, BigQuery, Redshift
①  不不正利利⽤用、不不正アクセス検知
②  ⼤大量量のセンサーデータを利利⽤用した
交通状況や⾃自然状況の分析
③  ユーザ動向のリアルタイム分析
即時性、リアルタイム性が
求められる領領域。
今起こっていることが分かることが
重要。
利利⽤用されるプロダクト例例：
Storm, Norikra, Dataﬂow

•  Nathan Marz⽒氏が提唱したアーキテクチャ
•  3つのレイヤーから構成
–  Batch Layer：データの管理理、バッチ処理理。
–  Speed Layer：ストリーム処理理、処理理結果の提供。
–  Serving Layer：バッチレイヤーの集計結果の提供。
Lambda Architecture
Raw
Data
Raw
Data
Raw
Data
Batch Layer
Speed Layer
Serving
Layer
Lambda Architecture

PUSH配信基盤
7
n  NTTコミュニケーションズが提供するPUSH配信技術
n  10秒以内に10万ユーザーへのPUSH配信を実現
n  TBS社のTBSぶぶたすのバックエンドとして利利⽤用
・・・・・・
10万ユーザー
TBSぶぶたす
・100万DL突破
・デジタルコンテンツオブジイヤー受賞
・テレビ番組と連動し、
　　　　情報が⾃自動的に通知表⽰示される
・PUSH通知される情報の
　　　ブックマークや懸賞参加ができる
ぶぶたす管理理者
配信コマンド
配信
ここでのユーザー操作を
リアルタイム集計・解析するのが
今回のテーマ

リアルタイム解析基盤
8
実現したかったこと
n  ⾼高トラフィック
•  最⼤大10万ユーザーが同時利利⽤用
n  ⾼高可⽤用性
•  番組中にリアルタイムに解析・可視化し続ける
•  クラウド上で動作させ続ける
n  スケーラビリティ
•  解析量量が増えた場合の対応
•  今後のマルチテナント化を視野

リアルタイム処理理基盤 on Cloud
•  TBSぶぶたすの⾏行行動履履歴をリアルタイムで解析・可視化
•  Storm, CouchbaseServerを中⼼心としたストリーム処理理基盤
•  NTTコミュニケーションズのパブリッククラウドcloud 上に基盤を構築
RabbitMQ
Storm
PUSH配信基盤
・
・
・
配信コマンド
ログ
n

データフロー
ログを送信ログを取得処理理結果を保存
キューイング
処理理
パース、
ユーザー属性付加、
コンテンツ情報付加
userID 　actionID 　timestamp 　contentsID
XXXX1 　3 　1397239563377 　YYYY1
XXXX2 　5 　1397240192325 　YYYY2
1433151060:cid|gender|state
1433151060:cid|gender
1433151060:cidTimestamp:集計パターンに整形
処理理系
表⽰示系
キャッシュ
PUSH配信基盤

Apache Storm
11
n  分散ストリーム処理理フレームワーク
n  ⽶米BackType社が開発し、Twitter社に買収された後にOSS化された
n  SpoutとBoltと呼ばれるコンポーネントに分割され、データを処理理し続け
る
n  データを保存する機構が無いため、データストアは別途必要となる
https://storm.apache.org/
Spout
Tupleを⽣生成
bolt
Tupleを処理理
Tuple
データ

Apache Storm
12
n  SPOFが存在しないアーキテクチャであり、可⽤用性は⾮非常に⾼高い
n  スケールアウト型となっており、クラウドとの相性が良良い
Nimbus
ZooKeeper
Supervisor
Master Node
Cluster
Coordinator
Worker
processes
ZooKeeper
ZooKeeper
Supervisor
Supervisor
Worker
Process
Worker
Process
Worker
Process
＊Nimbusダウン時も処理理は継続される
（プロセス再配置のみストップ）

全体構成
13
Push配信基盤
ZK
ZK
ZK
Nim
SV
SV
SV
SV
ZoneA
ZoneB

運⽤用中に起こった事件
14
n  ノード故障時に更更新が停⽌止
n  IO Waitでサーバーがダウン

ノード故障時に更更新が停⽌止！？
15
データのレプリカ設定・オートフェイルオーバー機能
ノード故障時も動き続けることを想定。

16
＿人人人人人人人人＿
＞　書込出来ない　＜
￣Y^Y^Y^Y^Y^Y^Y￣
データのレプリカ設定・オートフェイルオーバー機能
ノード故障時も動き続けることを想定。

17
NODE1 NODE2 NODE3
1 2 3
1 23
Client Library
Cluster Map
APP

18
NODE1 NODE2 NODE3
1 2 3
1 23
Client Library
Cluster Map
APP

19
NODE1 NODE2 NODE3
1 2 3
1 23
Client Library
Cluster Map
APP
4 Write Error

20
NODE1 NODE2 NODE3
1 2 3
1 23
Client Library
Cluster Map
APP
4
Write Error
クライアント側で、ノード決め打ちで保存しようとするため、
フェイルオーバーが起きない限り保存できない。

21
NODE1 NODE2 NODE3
1 2 3
1 23
Client Library
Cluster Map
APP
4
Write Error
オートフェイルオーバーは、ノード故障検出後、
30秒以上で設定可能

22
NODE1 NODE2 NODE3
1 2 3
1 23
Client Library
Cluster Map
APP
4
Write Error
クライアント側で、ノード決め打ちで保存しようとするので、
フェイルオーバーは、
ノード故障検知後30秒以上で任意設定可能
30秒間の書き込み不不可な時間は避けられない

23
NODE1 NODE2 NODE3
1 2 3
1 23
Client Library
Cluster Map
APP
4
Write Error
クライアント側で、ノード決め打ちで保存しようとするので、
XDCRでクラスタごと切切り替えで解決

24
Client Library
Cluster Map
APP
ClusterA ClusterB
XDCR
NODE1
NODE２ NODE３
NODE1
NODE２ NODE３

25
Client Library
Cluster Map
APP
ClusterA ClusterB
XDCR
NODE1
NODE２ NODE３
NODE1
NODE２ NODE３

26
Client Library
Cluster Map
APP
ClusterA ClusterB
XDCR
NODE1
NODE２ NODE３
NODE1
NODE２ NODE３
Write Error

27
Client Library
Cluster Map
APP
ClusterA ClusterB
XDCR
NODE1
NODE２ NODE３
NODE1
NODE２ NODE３

ノード故障時に更更新が停⽌止！？　教訓
28
n  ノード故障時は、フェイルオーバー発⽣生まで書込できない
　（読込はレプリカリードオプション有）
n  オートフェイルオーバーは、故障検知後30秒より⼤大きな値しか設定でき
ない
n  故障時も書込を続けるための⼯工夫が必要
•  故障検知→⼿手動フェイルオーバーを⾃自前実装
•  XDCRで同期された別クラスタに切切り替え

IO Waitでサーバーダウン！？
29
全データセットがRAMに乗り切切るように設計。
ディスク性能に依存せず、⾼高速なアクセスができる事を想定。

30

31

32
Disk write queueが増え続ける IO WaitでCPU使⽤用率率率が埋め尽くされる

33
＿人人人人人人＿
＞　SVダウン＜
￣Y^Y^Y^Y^Y￣

34
データはメモリ上に載ってるから⾼高速なのが売りと聞いた！
じゃぁディスク性能が少々遅くても⼤大丈夫なはず。
＿人人人人人人＿
＞　SVダウン＜
￣Y^Y^Y^Y^Y￣
Couchbase Serverは全てのデータを⾮非同期で永続化し、RAMよりも⼤大量量の
データを保存することが可能です。Couchbaseは⾃自動的にRAMからディスクに
データを移⾏行行し、オブジェクトレベルのキャッシュをワーキングセットで維持
します。
(Couchbaseの特徴より抜粋
　http://www.couchbase.com/jp/couchbase-‐‑‒server/features）

35
ディスクへの永続化プロセスが⾛走るので
⾼高頻度度の更更新があればディスクアクセスは増える

36
ディスクへの永続化プロセスが⾛走るので
⾼高頻度度の更更新があればディスクアクセスは増える
データ領領域のみtmpfsにして対応

37
tmpfsはUnix系OSにおける⼀一時ファイルのための仕組みの共通名。tmpfsは
ファイルシステムにマウントされることを意図しており、これによりHDDをは
じめとする永続性をもつ記憶装置の代わりに揮発性メモリに保存されるように
できる
(wikipediaより抜粋）

38
できる
揮発性メモリ

39
できる
揮発性メモリ
ノードがダウンした時、ノード内データが⽋欠損する

40
Couchbase Serverのレプリカ機能でカバー
別ノードのメモリ上にレプリカが保存されているため、
ディスクへの永続化に頼らない割り切切り
Couchbase クラスタ内の全てのサーバは同じ機能を
持っており、クラスタ管理理とデータ管理理の2つの役割を
担っています。
データマネージャはデータのストレージとアクセスの
役割を担っています。各ノードにはデータマネージャ
が配置されており、各ドキュメントは最⼤大で3つまでレ
プリカをクラスタ上に作成することが可能です。
(Couchbase Serverのアーキテクチャより抜粋　　
http://www.couchbase.com/jp/couchbase-‐‑‒
server/architecture）

IO Waitでサーバーダウン！？　教訓
41
n  Couchbase Serverは、データアクセス⾼高速化のため、メモリを有効活⽤用
するアーキテクチャではあるが、完全インメモリDBではない
n  全ドキュメントがメモリに載っている場合でも、データの永続化をする
ためにディスクアクセスは発⽣生する
n  ⾼高頻度度な書き込みがあるようなデータセットを扱う場合、ディスクへの
書き込み負荷が⼤大きくなる
n  tmpfs, SSDディスクを利利⽤用して実装することがオススメ

まとめ
42
n  個々のコンポーネントでは故障が起こっても、システム故障にならない
ようなアーキテクチャ
•  スピードレイヤはリアルタイムじゃないと意味が無い
•  クラウドの特性を活かして運⽤用でカバー
n  Couchbase Serverは、⼀一貫性＞可⽤用性モデル
•  アクティブなドキュメントはクラスタ内で1ノードのみ存在
•  バタつきを防ぐため、フェイルオーバーは慎重に発動
•  レプリカリード機能を使えば、読込負荷分散は可能
n  Couchbase Serverは、完全インメモリDBではない
•  パフォーマンス向上のためにキャッシュを有効活⽤用
•  ⼤大量量データの保存を実現するため、全てのデータは⾮非同期でディスクに永続化
•  ⾼高頻度度な書込⽤用途で利利⽤用する場合、ディスク性能も考慮する必要

Couchbase Serverのここが好き♡
43
n  インストールが簡単
•  パッケージをDLして、インストールするだけ
•  ノードを増やすときもラク
n  クラスタ増減が簡単
•  仲間に⼊入れたいSVを指定するだけ
•  カジュアルなローリングアップデート
n  モニタリングが充実
•  標準機能で、充実したモニタリング
n  ビューが使える
•  単なるKVSではない
•  JSONで⼊入れている意味を発揮

Couchbase ServerのここがイマイチL
44
n  ディスク永続化が必須であること
•  Redisのようにが永続化を無効にできるといいのに。。。。
•  TTLの利利⽤用・ハイメモリインスタンス利利⽤用などで、ディスク永続化せず
にインメモリ運⽤用のユースケースへの対応に期待！
n  バケットタイプでmemcachedにすると機能が⼤大きく制限されること
•  完全インメモリで使おうとすると、Couchbase Serverの素敵な機能が
使えなくなってしまう
•  Memcachedバケットへの対応にも期待！

45
御清聴有難うございました

Storm×couchbase serverで作るリアルタイム解析基盤

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Storm×couchbase serverで作るリアルタイム解析基盤 (20)

More from NTT Communications Technology Development (20)

Storm×couchbase serverで作るリアルタイム解析基盤