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