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

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% のアクセス数低下

–一般的に １ 秒遅延すると • 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

アーキテクチャの概要

•４つのモジュール

• 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待ち中は別の処理ができる

処理１ 処理２ 処理３ 処理４ 処理５

request response request response

21

高速化のための工夫

• Fiber

–処理の状態を保持したまま任意に中断

１ ２ ３

１ １ １ ２ ２ ２ ３ ３ ３

ファイバー１

ファイバー２

ファイバー３

１ ２ ３

１ ２ ３

直列化

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

活用事例

•楽天トラベル

–ページ閲覧履歴（リスト情報）

•その他

–２０箇所以上のセッション等の機能

29

シンプルなKVSでリスト扱う場合

• memcached で扱う場合

1.キーを基にデータ取得

2.デシリアライズ

3.データの修正

4.シリアライズ

5.データを保存

１ ２ ３ ４

５

¥x04¥b[¥ti¥x06i¥a

１ ２ ３ ４

¥x04¥b[¥ni¥x06i¥n

30

ROMAでリスト扱う場合

•リストプラグインを使用した場合

–データを渡すのみ “delete 2nd elm into list” req

put data

ROMA cluster

１ ２ ３ ４

５

31

トラベルにおけるリスト情報

•ROMAでリストを処理するメリット

–アプリケーションの単純化

–処理の分散

–永続化も選択可能

１ ２ ３ １ ２ ３ ４ １ ２

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上での結果１

•サーバ：４台

•クライアント：１台

qps

0

2,000

4,000

6,000

8,000

10,000

12,000

Read9:Write1 Read5:Write5 Read1:Write9

40

AWS上での結果2

•サーバ：４台

•クライアント：２～７台

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