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.

ROMA のアーキテクチャと社内事例

5,097 views

Published on

松江 宏樹、楽天株式会社
ROMAは、楽天が開発したオープンソースの分散Key-Value Storeである。ROMA は「楽天市場」「楽天トラベル」など、楽天の多様なサービスで発生する大量のユーザアクセスを高速に処理するため開発され、利用されている。ROMA の特徴である、必要に応じて動的なスケールアウトを実現する技術や、 Ruby で記述で記述したプラグインにより利用用途に応じた機能を追加できる拡張性について解説する。また、社内での具体的な利用例を取り上げ紹介すると共に、機能改善の取り組みについて紹介する。
Infotalkで利用した発表用資料。
http://pk.aiit.ac.jp/index.php?InfoTalk%2F20120318

  • Be the first to comment

ROMA のアーキテクチャと社内事例

  1. 1. ROMAアーキテクチャと社内事例Rakuten. Inc,2012/03/18H i r o k i M a t s u e 1
  2. 2. Introduction• 松江 宏樹 (まつえ ひろき) –楽天株式会社 (2011~) •開発アーキテクチャ部 •ROMA開発担当 –好きなROMAコマンド •balse –気になっているサービス •楽天オーネット 2
  3. 3. Agenda• ROMA 開発の背景• ROMA の特徴• ROMA アーキテクチャ• 社内事例• まとめ 3
  4. 4. • ROMA 開発の背景• ROMA の特徴• ROMA アーキテクチャ• 社内事例• まとめ 4
  5. 5. Rakuten Services• インターネットショッピングモール – 会員数:7300万人以上(2011/12月) – 出店数:3万7000店以上 – 商品数:9000万点以上 5
  6. 6. サービスへのリクエスト増加• 早く処理しないと・・ – Amazon : 0.1 秒の遅延 -> 1% の売り上げ低 下 – Google : 0.5 秒の遅延 -> 20% のアクセス数 低下 – 一般的に 1 秒遅延すると • PV : 11% 低下 • コンバージョン : 7% 低下 • 顧客満足度 : 16% 低下 – 楽天 : 24時間で130億円• 遅延・停止は避けたい 6
  7. 7. 速度、継続のための取り組み• 高速化の工夫 – HTML, Javascript の軽量化 – SSD > HDD – GPGPU• 継続のために – 電源 – ネットワーク – ロードバランサー – RAID – バックアップ – オペレータ• Business Continuity Plan – 災害リスクへの対策 7
  8. 8. 様々なサービスでのニーズ• 高速な処理への対応• 高い継続性の実現• 増大するデータへの対応 8
  9. 9. 研究の一環として開発• 楽天技術研究所 – 2007年 ROMA開発開始 (with Matz) – 2009年 オープンソースとして公開 • http://github.com/roma/roma/ 9
  10. 10. • ROMA 開発の背景• ROMA の特徴• ROMA アーキテクチャ• 社内事例• まとめ 10
  11. 11. NoSQLにおけるROMA• スケーラビリティ• 柔軟な機能拡張• No SPoF• 導入が容易• Ruby 11
  12. 12. ROMAの特徴• Pure P2Pアーキテクチャ• memcached 互換プロトコル• データレプリケーション• メタプログラミングによるサポート 12
  13. 13. • ROMA 開発の背景• ROMA の特徴• ROMA アーキテクチャ• 社内事例• まとめ 13
  14. 14. アーキテクチャの概要• 4つのモジュール Network IO module Command Execution Routing module module Storage module• Network• Command• Routing• Storage 14
  15. 15. データの配置 E.g. ROMA consists of three nodes ROMA 仮想ノード 仮想ノード 仮想ノードバケット バケット バケット バケット 15
  16. 16. ルーティング• 各ノードがデータ配置情報を保持 – ルーティングテーブル: 各ホストの担当 するハッシュ値 – 差分があった場合は情報を更新 – 論理クロック• 全ノード間で情報共有 ROMA 16
  17. 17. データへのアクセス• アクセスステップ 1.ユーザがROMAノードへアクセス 2.ROMAがデータ格納ノードを確認 3.格納ノードからデータ取得 4.取得したデータをユーザへ返す ①E.g. ROMA consists of three nodes ④ ② ROMA ③ 17
  18. 18. ROMAクライアントを用いた場合• 直接各ノードへアクセス – クライアントはルーティングテーブルを保持 – 更新がないか一定間隔毎に確認• アクセスステップ 1. クライアントでデータ格納ノードを確認 2. 格納ノードからデータを取得 ① ROMA ② 18
  19. 19. データレプリケーション• レプリケーション – 書き込み後、自動で実施 – 通常レプリケーションまで一つの処理とし て扱う – 失敗した場合も非同期キューからリトライ を行う ROMA 19
  20. 20. 高速化のための工夫• Eventmachineを使用 –イベント駆動で処理 –IO待ち中は別の処理ができる request response request response処理1 処理2 処理3 処理4 処理5 20
  21. 21. 高速化のための工夫• Fiber – 処理の状態を保持したまま任意に中断 ファイバー1 1 2 3 ファイバー2 1 2 3 ファイバー3 1 2 3 1 1 1 2 2 2 3 3 3 直列化 21
  22. 22. 高速化のための並列化• I/O における待ち時間を削減• 高負荷時のパフォーマンス低下を回避• データアクセス衝突の回避• 理解しやすい記述 22
  23. 23. スケールアウト• join コマンド• ルーティング情報の更新• 新規ノードへデータを移動• 速度は動的に変更可能 23
  24. 24. 障害時の復旧• フェイルオーバー – 対象ノードへのアクセス停止• recover – routingの自動修正 ハッシュ値 ハッシュ値 ハッシュ値 host1 host2 host2 host3 24
  25. 25. その他の機能• write_behind ログ(redo ログ)• ストレージの選択 – Ruby Hash – Tokyo Cabinet – Sqlite3 – DBM – (LevelDB) – (Kyoto Cabinet)• 対話型インタフェースによる config 設定 25
  26. 26. 機能の背景• write_behind ログ(redo ログ) – トランザクション• ストレージの選択 – 柔軟な特性の選択• 対話型インタフェースによる config 設定 – 設定に起因するエラー 26
  27. 27. • ROMA 開発の背景• ROMA の特徴• ROMA アーキテクチャ• 社内事例• まとめ 27
  28. 28. 活用事例• 楽天トラベル – ページ閲覧履歴(リスト情報)• その他 – 20箇所以上のセッション等の機能 28
  29. 29. シンプルなKVSでリスト扱う場合• memcached で扱う場合 1.キーを基にデータ取得 2.デシリアライズ 3.データの修正 4.シリアライズ ¥x04¥b[¥ti¥x06i¥a 5.データを保存 1 2 3 4 5 1 2 3 4 ¥x04¥b[¥ni¥x06i¥n 29
  30. 30. ROMAでリスト扱う場合 • リストプラグインを使用した場合 –データを渡すのみ“delete 2nd elm into list” req put data ROMA cluster 5 1 2 3 4 30
  31. 31. トラベルにおけるリスト情報• ROMAでリストを処理するメリット –アプリケーションの単純化 –処理の分散 –永続化も選択可能1 2 3 1 2 3 4 1 2 31
  32. 32. マッププラグイン• マッププラグイン –ひとつのキーに対して、連想配列 データを保持• マップカウントプラグイン –上記の連想配列に対して、インクリ メント処理を行う a = 2, b = 1, … “a” plus 1 ROMA cluster 32
  33. 33. マップカウントプラグイン• マップカウントの処理countup 0 5a,b,c=>{“a”=>1, “b”=1, “c”=1}2, b = 1, … a= “a” plus 1 ROMA cluster 33
  34. 34. プラグインの作成 • map_set コマンド – コマンド名、バリュー等を指定して保存def_write_command_with_key_value :map_set, 5 do |ctx| コマンド名(valueの生成方法) 保存するvalue[0, expt, Marshal.dump(v), :write,STORED]end 34
  35. 35. DSLのサポート• DSLによるメリット – 少量の記述による機能追加 – レプリケーション処理の自動化 – 内部カウント処理の簡略化map_set { (格納サーバの割り当て処理) (valueの生成方法) (データ格納処理) (レプリケーション処理)} 35
  36. 36. 事例から見たユースケース• キャッシュ層 –手軽なHA構成 –データ永続化• クラウド環境との相性 –必要な時にスケールできる• Rubyとの利用 –Rails + ROMA 36
  37. 37. こちらからどうぞ…• Githubから落とす• gemでインストール $ gem install roma• AWSのAMIを使う 37
  38. 38. AWSにおけるパフォーマンス• ROMA設定について – ストレージ:Tokyo Cabinet – データ数:500万件 – サーバ:AWSのlargeインスタンス APP APP APP Client 1 Client 2 Client N ROMA1 ROMA2 ROMA N ROMA Circle 38
  39. 39. AWS上での結果1• サーバ:4台• クライアント:1台 12,000 10,000 8,000 6,000qps 4,000 2,000 0 Read9:Write1 Read5:Write5 Read1:Write9 39
  40. 40. AWS上での結果2 • サーバ:4台 • クライアント:2~7台 18,000 16,000 14,000 12,000 10,000 Read9:Write1 Read5:Write5 8,000 Read1:Write9qps 6,000 4,000 2,000 0 2 3 4 5 6 7 clients 40
  41. 41. • ROMA 開発の背景• ROMA の特徴• ROMA アーキテクチャ• 社内事例• まとめ 41
  42. 42. まとめ• Ruby製 分散KVS• OSS• スケーラビリティ• 柔軟な拡張性• 可用性• 容易な導入・利用 42
  43. 43. お知らせ私たちと一緒に働きませんか? あなたのその技術を活かせる ポジションがきっとあります!日本語 :http://www.rakuten.co.jp/recruit/English:http://global.rakuten.com/careers/ 43
  44. 44. • ドキュメント – http://code.google.com/p/roma-prj/• プラグイン追加 – https://github.com/roma/roma/• Ruby gem – http://rubygems.org/gems/roma• AWSのAMI – AMI ID : ami-c2aa1bc3 – Region : Tokyo – roma-0.8.10-ruby1.9.2-linux-x64-ubuntu-10.04 44

×