Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,997 views

Published on

Couchbase MeetUP Tokyo - #14での発表資料です。

Published in: Technology

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

  1. 1. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. Storm  ×  Couchbase  Serverで作る       リアルタイム解析基盤 NTTコミュニケーションズ株式会社 技術開発部  松⽥田徹也 2015年年6⽉月11⽇日
  2. 2. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. 今⽇日話すこと 2 n  Couchbase  Server概要(Couchbase  Japan  河村さん) n  リアルタイム解析について n  Couchbase  ServerとStormを使ってクラウド上で実装した事例例 •  アーキテクチャ •  苦労したこと、⼯工夫したこと n  Couchbase  Serverの気に⼊入ってる所、イマイチだと思った所
  3. 3. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ⾃自⼰己紹介 3 {        名前:松⽥田徹也(tetsuyam),        所属:              {会社:NTTコミュニケーションズ,                    部署:技術開発部,                    チーム:クラウドコア  テクニカルユニット},            twitter:@tetsuyam_̲twt,        興味:[クラウドデザイン,                            ⾃自動化,                            ストリーム処理理] }
  4. 4. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. データ解析 バッチ処理による解析 ストリーム処理による解析 ①  ログ解析によるサイトやサービスに対 するアクセス分析 ②  過去ログをベースに、レコメンドエン ジンを利利⽤用したサービス性向上 バッチ処理理で実現する領領域。 バッチ処理理を早く終わらせて、結 果を出すことが重要。 利利⽤用されるプロダクト例例:  Hadoop,  Spark,  BigQuery,  Redshift ①  不不正利利⽤用、不不正アクセス検知 ②  ⼤大量量のセンサーデータを利利⽤用した 交通状況や⾃自然状況の分析 ③  ユーザ動向のリアルタイム分析 即時性、リアルタイム性が 求められる領領域。 今起こっていることが分かることが 重要。 利利⽤用されるプロダクト例例:  Storm,  Norikra,  Dataflow
  5. 5. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. •  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
  6. 6. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. •  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
  7. 7. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. PUSH配信基盤 7 n  NTTコミュニケーションズが提供するPUSH配信技術 n  10秒以内に10万ユーザーへのPUSH配信を実現 n  TBS社のTBSぶぶたすのバックエンドとして利利⽤用 ・・・・・・ 10万ユーザー TBSぶぶたす ・100万DL突破 ・デジタルコンテンツオブジイヤー受賞 ・テレビ番組と連動し、         情報が⾃自動的に通知表⽰示される ・PUSH通知される情報の       ブックマークや懸賞参加ができる ぶぶたす管理理者 配信コマンド 配信 ここでのユーザー操作を リアルタイム集計・解析するのが 今回のテーマ
  8. 8. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. リアルタイム解析基盤 8 実現したかったこと n  ⾼高トラフィック •  最⼤大10万ユーザーが同時利利⽤用 n  ⾼高可⽤用性 •  番組中にリアルタイムに解析・可視化し続ける •  クラウド上で動作させ続ける n  スケーラビリティ •  解析量量が増えた場合の対応 •  今後のマルチテナント化を視野
  9. 9. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. リアルタイム処理理基盤  on  Cloud •  TBSぶぶたすの⾏行行動履履歴をリアルタイムで解析・可視化 •  Storm,  CouchbaseServerを中⼼心としたストリーム処理理基盤 •  NTTコミュニケーションズのパブリッククラウドcloud      上に基盤を構築 RabbitMQ Storm PUSH配信基盤 ・ ・ ・ 配信コマンド ログ n
  10. 10. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. データフロー ログを送信 ログを取得 処理理結果を保存 キューイング 処理理 パース、 ユーザー属性付加、 コンテンツ情報付加 userID  actionID  timestamp  contentsID XXXX1  3  1397239563377  YYYY1 XXXX2  5  1397240192325  YYYY2 1433151060:cid|gender|state 1433151060:cid|gender 1433151060:cidTimestamp:集計パターンに整形 処理理系 表⽰示系 キャッシュ PUSH配信基盤
  11. 11. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. Apache  Storm 11 n  分散ストリーム処理理フレームワーク n  ⽶米BackType社が開発し、Twitter社に買収された後にOSS化された n  SpoutとBoltと呼ばれるコンポーネントに分割され、データを処理理し続け る n  データを保存する機構が無いため、データストアは別途必要となる https://storm.apache.org/ Spout Tupleを⽣生成 bolt Tupleを処理理 Tuple データ
  12. 12. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. 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. 13. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. 全体構成 13 Push配信基盤 ZK ZK ZK Nim SV SV SV SV ZoneA ZoneB
  14. 14. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. 運⽤用中に起こった事件 14 n  ノード故障時に更更新が停⽌止 n  IO  Waitでサーバーがダウン
  15. 15. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 15 データのレプリカ設定・オートフェイルオーバー機能 ノード故障時も動き続けることを想定。
  16. 16. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 16 _人人人人人人人人_ > 書込出来ない <  ̄Y^Y^Y^Y^Y^Y^Y ̄ データのレプリカ設定・オートフェイルオーバー機能 ノード故障時も動き続けることを想定。
  17. 17. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 17 NODE1 NODE2 NODE3 1 2 3 1 23 Client  Library Cluster  Map APP
  18. 18. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 18 NODE1 NODE2 NODE3 1 2 3 1 23 Client  Library Cluster  Map APP
  19. 19. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 19 NODE1 NODE2 NODE3 1 2 3 1 23 Client  Library Cluster  Map APP 4 Write  Error
  20. 20. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 20 NODE1 NODE2 NODE3 1 2 3 1 23 Client  Library Cluster  Map APP 4 Write  Error クライアント側で、ノード決め打ちで保存しようとするため、 フェイルオーバーが起きない限り保存できない。
  21. 21. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 21 NODE1 NODE2 NODE3 1 2 3 1 23 Client  Library Cluster  Map APP 4 Write  Error クライアント側で、ノード決め打ちで保存しようとするため、 フェイルオーバーが起きない限り保存できない。 オートフェイルオーバーは、ノード故障検出後、 30秒以上で設定可能
  22. 22. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 22 NODE1 NODE2 NODE3 1 2 3 1 23 Client  Library Cluster  Map APP 4 Write  Error クライアント側で、ノード決め打ちで保存しようとするので、 フェイルオーバーが起きない限り保存できない。 オートフェイルオーバーは、ノード故障検出後、 30秒以上で設定可能 クライアント側で、ノード決め打ちで保存しようとするため、 フェイルオーバーが起きない限り保存できない。 フェイルオーバーは、 ノード故障検知後30秒以上で任意設定可能 30秒間の書き込み不不可な時間は避けられない
  23. 23. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 23 NODE1 NODE2 NODE3 1 2 3 1 23 Client  Library Cluster  Map APP 4 Write  Error クライアント側で、ノード決め打ちで保存しようとするので、 フェイルオーバーが起きない限り保存できない。 オートフェイルオーバーは、ノード故障検出後、 30秒以上で設定可能 XDCRでクラスタごと切切り替えで解決
  24. 24. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 24 Client  Library Cluster  Map APP ClusterA ClusterB XDCR NODE1 NODE2 NODE3 NODE1 NODE2 NODE3
  25. 25. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 25 Client  Library Cluster  Map APP ClusterA ClusterB XDCR NODE1 NODE2 NODE3 NODE1 NODE2 NODE3
  26. 26. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 26 Client  Library Cluster  Map APP ClusterA ClusterB XDCR NODE1 NODE2 NODE3 NODE1 NODE2 NODE3 Write  Error
  27. 27. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!? 27 Client  Library Cluster  Map APP ClusterA ClusterB XDCR NODE1 NODE2 NODE3 NODE1 NODE2 NODE3
  28. 28. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. ノード故障時に更更新が停⽌止!?  教訓 28 n  ノード故障時は、フェイルオーバー発⽣生まで書込できない   (読込はレプリカリードオプション有) n  オートフェイルオーバーは、故障検知後30秒より⼤大きな値しか設定でき ない n  故障時も書込を続けるための⼯工夫が必要 •  故障検知→⼿手動フェイルオーバーを⾃自前実装 •  XDCRで同期された別クラスタに切切り替え
  29. 29. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 29 全データセットがRAMに乗り切切るように設計。 ディスク性能に依存せず、⾼高速なアクセスができる事を想定。
  30. 30. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 30 全データセットがRAMに乗り切切るように設計。 ディスク性能に依存せず、⾼高速なアクセスができる事を想定。
  31. 31. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 31 全データセットがRAMに乗り切切るように設計。 ディスク性能に依存せず、⾼高速なアクセスができる事を想定。
  32. 32. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 32 全データセットがRAMに乗り切切るように設計。 ディスク性能に依存せず、⾼高速なアクセスができる事を想定。 Disk  write  queueが増え続ける IO  WaitでCPU使⽤用率率率が埋め尽くされる
  33. 33. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 33 全データセットがRAMに乗り切切るように設計。 ディスク性能に依存せず、⾼高速なアクセスができる事を想定。 Disk  write  queueが増え続ける IO  WaitでCPU使⽤用率率率が埋め尽くされる _人人人人人人_ > SVダウン<  ̄Y^Y^Y^Y^Y ̄
  34. 34. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 34 データはメモリ上に載ってるから⾼高速なのが売りと聞いた! じゃぁディスク性能が少々遅くても⼤大丈夫なはず。 Disk  write  queueが増え続ける IO  WaitでCPU使⽤用率率率が埋め尽くされる _人人人人人人_ > SVダウン<  ̄Y^Y^Y^Y^Y ̄ Couchbase  Serverは全てのデータを⾮非同期で永続化し、RAMよりも⼤大量量の データを保存することが可能です。Couchbaseは⾃自動的にRAMからディスクに データを移⾏行行し、オブジェクトレベルのキャッシュをワーキングセットで維持 します。 (Couchbaseの特徴より抜粋   http://www.couchbase.com/jp/couchbase-‐‑‒server/features)
  35. 35. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 35 全データセットがRAMに乗り切切るように設計。 ディスク性能に依存せず、⾼高速なアクセスができる事を想定。 ディスクへの永続化プロセスが⾛走るので ⾼高頻度度の更更新があればディスクアクセスは増える
  36. 36. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 36 全データセットがRAMに乗り切切るように設計。 ディスク性能に依存せず、⾼高速なアクセスができる事を想定。 ディスクへの永続化プロセスが⾛走るので ⾼高頻度度の更更新があればディスクアクセスは増える データ領領域のみtmpfsにして対応
  37. 37. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 37 tmpfsはUnix系OSにおける⼀一時ファイルのための仕組みの共通名。tmpfsは ファイルシステムにマウントされることを意図しており、これによりHDDをは じめとする永続性をもつ記憶装置の代わりに揮発性メモリに保存されるように できる (wikipediaより抜粋)
  38. 38. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 38 tmpfsはUnix系OSにおける⼀一時ファイルのための仕組みの共通名。tmpfsは ファイルシステムにマウントされることを意図しており、これによりHDDをは じめとする永続性をもつ記憶装置の代わりに揮発性メモリに保存されるように できる (wikipediaより抜粋) 揮発性メモリ
  39. 39. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 39 tmpfsはUnix系OSにおける⼀一時ファイルのための仕組みの共通名。tmpfsは ファイルシステムにマウントされることを意図しており、これによりHDDをは じめとする永続性をもつ記憶装置の代わりに揮発性メモリに保存されるように できる (wikipediaより抜粋) 揮発性メモリ ノードがダウンした時、ノード内データが⽋欠損する
  40. 40. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!? 40 Couchbase  Serverのレプリカ機能でカバー 別ノードのメモリ上にレプリカが保存されているため、 ディスクへの永続化に頼らない割り切切り Couchbase  クラスタ内の全てのサーバは同じ機能を 持っており、クラスタ管理理とデータ管理理の2つの役割を 担っています。 データマネージャはデータのストレージとアクセスの 役割を担っています。各ノードにはデータマネージャ が配置されており、各ドキュメントは最⼤大で3つまでレ プリカをクラスタ上に作成することが可能です。   (Couchbase  Serverのアーキテクチャより抜粋     http://www.couchbase.com/jp/couchbase-‐‑‒ server/architecture)
  41. 41. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. IO  Waitでサーバーダウン!?  教訓 41 n  Couchbase  Serverは、データアクセス⾼高速化のため、メモリを有効活⽤用 するアーキテクチャではあるが、完全インメモリDBではない n  全ドキュメントがメモリに載っている場合でも、データの永続化をする ためにディスクアクセスは発⽣生する n  ⾼高頻度度な書き込みがあるようなデータセットを扱う場合、ディスクへの 書き込み負荷が⼤大きくなる n  tmpfs,  SSDディスクを利利⽤用して実装することがオススメ
  42. 42. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. まとめ 42 n  個々のコンポーネントでは故障が起こっても、システム故障にならない ようなアーキテクチャ •  スピードレイヤはリアルタイムじゃないと意味が無い •  クラウドの特性を活かして運⽤用でカバー n  Couchbase  Serverは、⼀一貫性  >可⽤用性  モデル •  アクティブなドキュメントはクラスタ内で1ノードのみ存在 •  バタつきを防ぐため、フェイルオーバーは慎重に発動 •  レプリカリード機能を使えば、読込負荷分散は可能 n  Couchbase  Serverは、完全インメモリDBではない •  パフォーマンス向上のためにキャッシュを有効活⽤用 •  ⼤大量量データの保存を実現するため、全てのデータは⾮非同期でディスクに永続化 •  ⾼高頻度度な書込⽤用途で利利⽤用する場合、ディスク性能も考慮する必要
  43. 43. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. Couchbase  Serverのここが好き♡ 43 n  インストールが簡単 •  パッケージをDLして、インストールするだけ •  ノードを増やすときもラク n  クラスタ増減が簡単 •  仲間に⼊入れたいSVを指定するだけ •  カジュアルなローリングアップデート n  モニタリングが充実 •  標準機能で、充実したモニタリング n  ビューが使える •  単なるKVSではない •  JSONで⼊入れている意味を発揮
  44. 44. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. Couchbase  ServerのここがイマイチL 44 n  ディスク永続化が必須であること •  Redisのようにが永続化を無効にできるといいのに。。。。 •  TTLの利利⽤用・ハイメモリインスタンス利利⽤用などで、ディスク永続化せず にインメモリ運⽤用のユースケースへの対応に期待! n  バケットタイプでmemcachedにすると機能が⼤大きく制限されること •  完全インメモリで使おうとすると、Couchbase  Serverの素敵な機能が 使えなくなってしまう •  Memcachedバケットへの対応にも期待!
  45. 45. Copyright  ©  NTT  Communications  Corporation.  All  rights  reserved. 45 御清聴有難うございました

×