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

1. ROMA
アーキテクチャと社内事例
Rakuten. Inc,2012/03/18
H i r o k i M a t s u e 1

2. Introduction
• 松江 宏樹 （まつえ ひろき）
–楽天株式会社 (2011~)
•開発アーキテクチャ部
•ROMA開発担当
–好きなROMAコマンド
•balse
–気になっているサービス
•楽天オーネット
2

3. Agenda
• ROMA 開発の背景
• ROMA の特徴
• ROMA アーキテクチャ
• 社内事例
• まとめ
3

4. • ROMA 開発の背景
• ROMA の特徴
• ROMA アーキテクチャ
• 社内事例
• まとめ
4

5. Rakuten Services
• インターネットショッピングモール
– 会員数：7300万人以上（2011/12月）
– 出店数：3万7000店以上
– 商品数：9000万点以上
5

6. サービスへのリクエスト増加
• 早く処理しないと・・
– Amazon : 0.1 秒の遅延 -> 1% の売り上げ低
下
– Google : 0.5 秒の遅延 -> 20% のアクセス数
低下
– 一般的に １ 秒遅延すると
• PV ： 11% 低下
• コンバージョン ： 7% 低下
• 顧客満足度 ： 16% 低下
– 楽天 : 24時間で130億円
• 遅延・停止は避けたい
6

7. 速度、継続のための取り組み
• 高速化の工夫
– HTML, Javascript の軽量化
– SSD > HDD
– GPGPU
• 継続のために
– 電源
– ネットワーク
– ロードバランサー
– RAID
– バックアップ
– オペレータ
• Business Continuity Plan
– 災害リスクへの対策
7

8. 様々なサービスでのニーズ
• 高速な処理への対応
• 高い継続性の実現
• 増大するデータへの対応
8

9. 研究の一環として開発
• 楽天技術研究所
– 2007年 ROMA開発開始 (with Matz)
– 2009年 オープンソースとして公開
• http://github.com/roma/roma/
9

10. • ROMA 開発の背景
• ROMA の特徴
• ROMA アーキテクチャ
• 社内事例
• まとめ
10

11. NoSQLにおけるROMA
• スケーラビリティ
• 柔軟な機能拡張
• No SPoF
• 導入が容易
• Ruby
11

12. ROMAの特徴
• Pure P2Pアーキテクチャ
• memcached 互換プロトコル
• データレプリケーション
• メタプログラミングによるサポート
12

13. • ROMA 開発の背景
• ROMA の特徴
• ROMA アーキテクチャ
• 社内事例
• まとめ
13

14. アーキテクチャの概要
• ４つのモジュール
Network IO module
Command Execution
Routing module
module
Storage module
• Network
• Command
• Routing
• Storage 14

15. データの配置
E.g. ROMA consists of three nodes
ROMA
仮想ノード 仮想ノード 仮想ノード
バケット バケット バケット バケット
15

16. ルーティング
• 各ノードがデータ配置情報を保持
– ルーティングテーブル: 各ホストの担当
するハッシュ値
– 差分があった場合は情報を更新
– 論理クロック
• 全ノード間で情報共有
ROMA
16

17. データへのアクセス
• アクセスステップ
1.ユーザがROMAノードへアクセス
2.ROMAがデータ格納ノードを確認
3.格納ノードからデータ取得
4.取得したデータをユーザへ返す
①
E.g. ROMA consists of three nodes
④ ②
ROMA
③
17

18. ROMAクライアントを用いた場合
• 直接各ノードへアクセス
– クライアントはルーティングテーブルを保持
– 更新がないか一定間隔毎に確認
• アクセスステップ
1. クライアントでデータ格納ノードを確認
2. 格納ノードからデータを取得
① ROMA
②
18

19. データレプリケーション
• レプリケーション
– 書き込み後、自動で実施
– 通常レプリケーションまで一つの処理とし
て扱う
– 失敗した場合も非同期キューからリトライ
を行う
ROMA
19

20. 高速化のための工夫
• Eventmachineを使用
–イベント駆動で処理
–IO待ち中は別の処理ができる
request response request response
処理１ 処理２ 処理３ 処理４ 処理５
20

21. 高速化のための工夫
• Fiber
– 処理の状態を保持したまま任意に中断
ファイバー１ １ ２ ３
ファイバー２ １ ２ ３
ファイバー３ １ ２ ３
１ １ １ ２ ２ ２ ３ ３ ３
直列化
21

22. 高速化のための並列化
• I/O における待ち時間を削減
• 高負荷時のパフォーマンス低下を回避
• データアクセス衝突の回避
• 理解しやすい記述
22

23. スケールアウト
• join コマンド
• ルーティング情報の更新
• 新規ノードへデータを移動
• 速度は動的に変更可能
23

24. 障害時の復旧
• フェイルオーバー
– 対象ノードへのアクセス停止
• recover
– routingの自動修正
ハッシュ値
ハッシュ値 ハッシュ値
host1 host2 host2 host3
24

25. その他の機能
• write_behind ログ（redo ログ）
• ストレージの選択
– Ruby Hash
– Tokyo Cabinet
– Sqlite3
– DBM
– (LevelDB)
– (Kyoto Cabinet)
• 対話型インタフェースによる config 設定
25

26. 機能の背景
• write_behind ログ（redo ログ）
– トランザクション
• ストレージの選択
– 柔軟な特性の選択
• 対話型インタフェースによる config
設定
– 設定に起因するエラー
26

27. • ROMA 開発の背景
• ROMA の特徴
• ROMA アーキテクチャ
• 社内事例
• まとめ
27

28. 活用事例
• 楽天トラベル
– ページ閲覧履歴（リスト情報）
• その他
– ２０箇所以上のセッション等の機能
28

29. シンプルなKVSでリスト扱う場合
• memcached で扱う場合
1.キーを基にデータ取得
2.デシリアライズ
3.データの修正
4.シリアライズ
¥x04¥b[¥ti¥x06i¥a
5.データを保存
１ ２ ３ ４
５
１ ２ ３ ４
¥x04¥b[¥ni¥x06i¥n
29

30. ROMAでリスト扱う場合
• リストプラグインを使用した場合
–データを渡すのみ
“delete 2nd elm into list” req
put data
ROMA cluster
５
１ ２ ３ ４
30

31. トラベルにおけるリスト情報
• ROMAでリストを処理するメリット
–アプリケーションの単純化
–処理の分散
–永続化も選択可能
１ ２ ３ １ ２ ３ ４ １ ２
31

32. マッププラグイン
• マッププラグイン
–ひとつのキーに対して、連想配列
データを保持
• マップカウントプラグイン
–上記の連想配列に対して、インクリ
メント処理を行う a = 2, b = 1, …
“a” plus 1
ROMA cluster
32

33. マップカウントプラグイン
• マップカウントの処理
countup 0 5
a,b,c
=>
{“a”=>1, “b”=1, “c”=1}2, b = 1, …
a=
“a” plus 1
ROMA cluster
33

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. DSLのサポート
• DSLによるメリット
– 少量の記述による機能追加
– レプリケーション処理の自動化
– 内部カウント処理の簡略化
map_set ｛
（格納サーバの割り当て処理）
（valueの生成方法）
（データ格納処理）
（レプリケーション処理）
｝
35

36. 事例から見たユースケース
• キャッシュ層
–手軽なHA構成
–データ永続化
• クラウド環境との相性
–必要な時にスケールできる
• Rubyとの利用
–Rails ＋ ROMA
36

37. こちらからどうぞ…
• Githubから落とす
• gemでインストール
$ gem install roma
• AWSのAMIを使う
37

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. AWS上での結果１
• サーバ：４台
• クライアント：１台
12,000
10,000
8,000
6,000
qps
4,000
2,000
0
Read9:Write1 Read5:Write5 Read1:Write9
39

40. AWS上での結果2
• サーバ：４台
• クライアント：２～７台
18,000
16,000
14,000
12,000
10,000 Read9:Write1
Read5:Write5
8,000 Read1:Write9
qps
6,000
4,000
2,000
0
2 3 4 5 6 7
clients 40

41. • ROMA 開発の背景
• ROMA の特徴
• ROMA アーキテクチャ
• 社内事例
• まとめ
41

42. まとめ
• Ruby製 分散KVS
• OSS
• スケーラビリティ
• 柔軟な拡張性
• 可用性
• 容易な導入・利用
42

43. お知らせ
私たちと一緒に働きませんか？
あなたのその技術を活かせる
ポジションがきっとあります！
日本語 ：http://www.rakuten.co.jp/recruit/
English：http://global.rakuten.com/careers/
43

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