Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à RDBからの脱却： 新ERP"HUE"におけるCassandra
Similaire à RDBからの脱却： 新ERP"HUE"におけるCassandra (20)
RDBからの脱却： 新ERP"HUE"におけるCassandra
- 1. 1 RDBからの脱却： 新ERP"HUE"におけるCassandra 株式会社ワークスアプリケーションズ 堤 勇人 HUE BT Back-end team Cassandra Summit Tokyo 2015 2015/04/21
- 2. 2 前置き
- 3. 3 堤 勇人 ＠2t3 2010年からエンタープライズ向けメーラー WebmailにてCassandraを使い始める。 現在はHUE BT Back-end teamにて 裏側全般を見ています。 自己紹介
- 4. 4 Webmail ➢ エンタープライズ向けメールサービス ➢ 2010年から5年間、開発・運用している ➢ Cassandraで動く ➢ 毎分2000通のメールを処理する 自己紹介2
- 6. 6 ➢ 大企業向けのシステム ➢ 様々な状況に効率的に対応するため、 複雑な業務が行われる。 ➢ それら複雑な業務のための、 多くの機能、細かい機能が求められる。 エンタープライズとは何か？
- 7. 7 ➢ コストパフォーマンスが悪い？ ➢ 開発が大変な割に、単純なことしかできない ➢ 必須機能が無い？ ➢ トランザクション、join、index、etc... ➢ 結果整合性なんていらない？ ➢ 厳密なデータが必須 ➢ gmailで件数がmanyと出るのは良いが、 給料がmanyと書かれていたら怒る 何故エンタープライズ分野では Cassandraが使われて来なかったのか？
- 9. 9 ➢ High Usability ➢ 100msの応答性能 ➢ 脱RDB 「HUE」
- 10. 10 ➢ どのようなレベルか ➢ Googleトップページが100ms ➢ 検索結果になると300～400ms ➢ 単に早くレスポンスするというだけではない ➢ トライアンドエラーを可能にすることで、 新しい価値を提供できる 100msの応答性能
- 13. 13 何故Cassandraか？
- 14. 14 ➢ 100msの要求性能 ➢ DBの許容時間は20ms ➢ 20msを普通のRDBで出すには ➢ 非正規化する ➢ joinしない ➢ ソート済みデータを用意する しかない ✗ もしくは高いサーバにメモリを積む 何故Cassandraか？
- 15. 15 ➢ 設定 ➢ CPU 1処理 約0.3[ns] ➢ CPUキャッシュアクセス速度 0.5～5[ns] ➢ メモリアクセス速度 10～数10[ns] ➢ 処理1ループを、100[ns]とする ➢ 10万件ソートすると N logN = 1,600,000 試算(実行時ソート)
- 16. 16 ➢ 1,600,000 * 100[ns] = 160[ms] ➢ 遅い ➢ メモリに全部データが載っているとしても なかなか大変な計算 ➢ コア数にも限界がある 試算(実行時ソート)
- 17. 17 ➢ スループットが簡単にスケールすることも重要 ➢ バッチ処理の時間はスループットに依存する ➢ 8時間かかっていたバッチが20分になれば ➢ より詳細なデータを提供できる ➢ 他の業務をやる時間ができる ➢ 働き方自体が変わる 何故Cassandraか？2
- 18. 18 試算2
- 19. 19 試算2
- 20. 20 ➢ 可用性 ➢ スケールする ➢ 3台から1000台レベルのクラスタまで 同様にスケールする ➢ むしろ台数が増えると安定する ➢ マスター無し ➢ 小さなダウンタイムも無い ➢ 実はマスタースレイブ切り替えの際に ダウンタイムがあるシステムは多い Cassandraの有用性
- 21. 21 ➢ 可用性 ➢ スケールする ➢ マスター無し これらが簡単に行えることが重要 Cassandraの有用性2
- 22. 22 ➢ 100msのような高速域では RDBの良さは失われる。 ➢ Cassandraではスループットを コストパフォーマンス良く上げることができる ➢ 簡単に分散システムの恩恵を受けられる 何故Cassandraか？まとめ
- 24. 24 HUE全体のアーキテクチャ JJUG CCC 2015 Spring 「社長が脱RDBと言い出して困りましたが、開き直って楽しんでいる話」より
- 25. 25 Cassandra周りのフレームワーク ➢ Key Value Access Library ➢ いわゆるObject Mapper ➢ POJOの形でCassandraとやり取り ➢ 様々な属性はannotationで管理 ➢ CQLAPIを隠蔽 ➢ 格好いい名前を考えろと言われている
- 26. 26 Cassandra周りのフレームワーク2 ➢ Index creation framework ➢ Index、非正規化データを自動メンテナンス ➢ Elasticsearch等へも同期可能 ➢ Key Value Accessへの入力を取得 ➢ Kafkaでキューイングし、非同期に実行
- 27. 27 Cassandra周りのフレームワーク3 ➢ EDP2 ➢ Enterprise Distributed Processing Platform ➢ 分散処理に関わるリソースを自動的に管理する ➢ バッチの予定終了時刻に合わせて、 Sparkのworkerを追加したり、 Cassandra自体をスケールさせたりする。
- 28. 28 Cassandra周りのフレームワーク4 ➢ DBTool ➢ Cassandraのデータをgrid形式で表示する ➢ データのexport / importも可能 ➢ 要するにDatastaxのDevCenter
- 30. 30 開発中に出てきた問題 ➢ トランザクション ➢ N+1問題 ➢ 多テーブル問題 ➢ 逆に意外と何とかなる問題 ➢ 複雑なクエリ ➢ join ➢ index ➢ validation
- 32. 32 ➢ これまでトランザクションを利用していた 処理の99.9%は対応不要か、 Lightweight Transactionで対応可能。 ➢ 残りの0.1%、特にisolationが必要な場合には 特別な仕組みが必要となってくる。 トランザクション
- 33. 33 JJUG CCC 2015 Spring 「社長が脱RDBと言い出して困りましたが、開き直って楽しんでいる話」より
- 34. 34 JJUG CCC 2015 Spring 「社長が脱RDBと言い出して困りましたが、開き直って楽しんでいる話」よりJJUG CCC 2015 Spring 「社長が脱RDBと言い出して困りましたが、開き直って楽しんでいる話」より
- 35. 35 ➢ 例えば別順でソートさせたい時 indexテーブルからソート済みIDをロード ➔ 実テーブルにそのIDでアクセス ➢ joinもinも使えないため、 対象者数回+1のアクセスが発生する。 ➔全て並列で取得している。(力技) 接続先が分散されるので、 パフォーマンス的問題は起こっていない。 N+1問題
- 36. 36 ➢ 多数のテーブルを作るとCassandraが 重くなり、やがては起動しなくなる ➢ Cassandraは1テーブル辺り約1MBの メモリオーバーヘッドが全ノードにかかる ➢ HBaseでも似たような問題がある ➢ Elasticsearchでも似たような問題がある ➢ マルチテナンシを考慮するとさらに倍率がかかる ➢ そしてERPは扱うデータの種類が極めて多い ➢ 弊社人事給与で3,000テーブル、 会計となると単独でそれ以上の数になる 多テーブル問題
- 38. 38 create table generic_table { table_name text, joined_pk blob, ck1 blob, ck2 blob, ck3 blob, ck4 blob, ck5 blob, column_name text, value blob, primary key ((table_name, joined_pk), ck1, ck2, ck3, ck4, ck5, column_name) } 多テーブル問題3
- 39. 39 ➢ 弊害と恩恵 ➢ かなり独自のテーブルにしてしまった結果、 DevCenterのようなツールが使えなくなった。 ➔ DBToolを作成 ➢ 想定される種類のテーブル構造が 予め定義されていることにより、 遅い定義が行われる余地が無くなった。 ➢ thriftのダイナミックカラムが再び利用可能に 多テーブル問題4
- 40. 40 まとめ
- 44. 44 ERPにおけるデータパターン 究極的にはこの2個しかない ➢ event ➢ 不変の事実 ➢ これが蓄積されていく ➢ e.g. 申請書、取引、発令、etc... ➢ changeset ➢ eventが蓄積された結果を示す歴史 ➢ e.g. 人事異動履歴、組織、会社 データデザインパターン
- 45. 45 その応用 ➢ Tree ➢ Relation ➢ Group ➢ Analyze ➢ Header-Body ➢ etc... データデザインパターン2
- 48. 48 ➢ Replica:3, R/W=QUORUM ➢ 王道 ➢ メモリ設定はそのまま、newgenを増やす ➢ 遅くなる兆候、遅いテーブルは、 cfhistogramsをJMXで監視する Cassandraの設定
- 52. 52 データの移行が必要かつ、 移行中に入力されたデータの移行も必要な場合 バージョンアップ戦略3 ➢ まず移行スクリプトを当てる ➢ その後、移行後データが無い場合はその場で 移行する”lazy migration”バージョンを作る ➢ 新データに移行を行う ➢ ”lazy migration”処理を外し バージョンアップを行う
- 53. 53 データの移行が必要かつ、 移行中に入力されたデータの移行も必要で、 処理を遅くできない場合 バージョンアップ戦略4 ➢ 移行先のテーブル or カラムを別途作る ➢ 結果を移行元と移行先両方に書き込む バージョンへアップデートする ➢ 移行スクリプトを当てる ➢ 読み込み先を移行先に変更する ➢ 移行先にのみ読み書きするバージョンにアップ デートする