The Overall Architecture of ROMA

ROMA R akuten O n- M emory A rchitecture 楽天株式会社楽天技術研究所西澤無我| 2009年2月20日

ROMA について
複数マシンから構成される P2P を利用した
Ruby 実装の key-value store
ROMA (key-value store)

ROMA の特徴 ROMA
社内クラウド
高負荷な状況であっても、十分高速なデータアクセス
部分障害が起きても、データを喪失しづらい
エンドユーザ Web ( アプリケーション ) サーバ GET GET PUT

Consistent Hashing
Pure P2P で自律的にノードを管理
環状 (Consistent Hashing)
各ノードはユニークなハッシュ値 (SHA-1) をもつ
その範囲は 0 ～ 2^64 の整数
ROMA

Zero-hop でのデータ探索 (1/2)
各ノードが環全体のノード情報を保持
1,000 台程度のノード情報であるため
クライアントが環情報を保持することも可能
ROMA に初めてアクセスした際、クライアントは環情報を取得
ROMA 担当ノード ① データを GET/PUT ③ 担当ノードから値を GET/PUT ② 担当ノードを計算コーディネータクライアント

Zero-hop でのデータ探索 (2/2)
各ノードが環全体のノード情報を保持
1,000 台程度のノード情報であるため
クライアントが環情報を保持することも可能
ROMA に初めてアクセスした際、クライアントは環情報を取得
ROMA 担当ノード ③ 担当ノードから値を GET/PUT ② 担当ノードを計算 ① データを GET/PUT クライアント

ROMA Client
クライアントと ROMA 間は独自プロトコルを用意
現在、 Ruby, Java によるクライアント実装
開発者に分散を意識させない
どのマシンにデータが格納されているのか、開発者は意識する必要なし
#!/usr/local/bin/ruby require ‘RClient’ rc = ROMA::Client.new rc.open(“roma0”, 3300) # 任意の ROMA プロセスを指定 rc[“muga”] = “data” # ROMA にデータを PUT data = rc[“muga”] # ROMA からデータを GET rc[“muga”] = nil # ROMA からデータを DELETE ※ Ruby 実装のクライアント API の例

Replication (1/2)
データが PUT されたとき、担当ノードはその左右のノードにレプリカを PUT
プライマリが左右にデータのバックアップを配置
ROMA が自動的に行う
デフォルトでデータの冗長度 ( 多重度 ) は 3
ROMA 担当ノード ① 担当ノードに値が PUT ② 左右のノードにレプリカを PUT

Replication (2/2)
基本的に、単一の担当ノードが PUT/GET を引き受ける
※ 左右のノードに PUT/GET があると、それは別の意味になる（後述）
左右のノードにデータが PUT されるまで、クライアントは待つ
プライマリによるロック
レプリカの一貫性を保ちやすい（アプリ開発者が楽になる）
プライマリのノードが性能のボトルネック

Replica Synchronization (1/2)
障害時でなくとも、 replication に失敗するケース
例：忙しすぎて左隣のノードはレスポンスを返せない
担当ノードは replication に失敗しても、自身さえ更新できれば成功のレスポンスを返す
ただし、担当ノードのそのデータにダーティフラグが立つ
本当はデータの PUT 失敗

Replica Synchronization (2/2)
ダーティーフラグはいずれ解消される
そのデータは非同期に synchronization
担当ノードは、ダーティーフラグが立っているデータを検索
左右のノードから、異なる値を持つデータを更新
シンクロ前にマスター、右ノードが停止してしまうと一貫性は保たれない
マスターのみ停止したら、キーの更新の時刻を比較

ノードの Join (1/3)
新規のノードの ROMA への参加
起動直後、自分のノードのハッシュ値を計算
ネットワーク上の全てのマシンに対し、そのハッシュ値をブロードキャスト
ROMA のノードが応答
その隣に新規ノードは入る
ROMA 新規ノード ① ブロードキャスト ② ROMA ノードが応答

各ノードのデータ領域 LS P RS LS P RS LS P RS LS P RS
各ノードは 3 つのデータ領域をもつ
P: 自分が担当しているデータを格納する領域
LS: 左のノードが担当しているデータの複製を格納する領域
RS: 右のノードが担当しているデータの複製を格納する領域
冗長度 3 冗長度 3 ROMA

ノードの Join (2/3)
新規ノードに、左右のノードからデータがコピーされる
LS P RS LS P RS LS P RS LS P RS LS P RS ROMA

ノードの Join (3/3) LS P
リハッシュ後に、新規ノードはサービス開始
LS P RS LS P RS P RS LS P RS LS RS ROMA

環情報の更新 ROMA
ノード参加の事実を ROMA 全体に通知
新しく参加したノードが主導で、環情報を更新
環全体にじわじわと情報が伝わっていく

障害ノードの切り離し
どのようにノードの障害を検知するか？
ノード障害が検知できれば、そのノードを切り離して環情報の更新をすればよい
ROMA 障害ノード

ノードの障害検知 (1/2)
ハートビートを左右のノードに飛ばして、生存確認
( デフォルトで ) 3 秒間隔
左右のノードのみ
左右のノードとは、コネクションを張りっぱなし
左右が障害と判断したら、真ん中のノードは障害ノード
現在、ノードの負荷状況によっては誤検知がある
例 : GC が動作しており、定期的なハートビートが送れない
ROMA

ノードの障害検知 (2/2)
左右のノードへのデータの PUT/GET による障害検知
① ダウンした担当ノードにデータの PUT を依頼
② データの PUT に失敗
③ 右隣がマスターとなっていると考え、右隣にデータに PUT を依頼
しかし、右隣のノードがセカンダリーのままだと、
④ 右セカンダリーはクライアントにダーティフラグ付きのデータを返し、ダウン検知開始
セカンダリー担当ノードセカンダリー ① ② ③

障害ノードの切り離し
切り離しを行った後は、データの冗長度 2
LS P LS P RS LS P RS P RS LS P RS LS RS 離脱ノード離脱ノード冗長度 2 冗長度 2 ROMA

永続化
デフォルトでは、 redo log と snapshot の構成
クエリを redo log ファイルに書き込む
定期的に redo log を snapshot へ
Tokyo Cabinet に格納できたら
Tokyo Cabinet は速いから
ROMA (key-value store) データデータデータデータデータデータ

まとめ
ROMA
複数マシンから構成されるオンメモリストレージ
P2P を利用した key-value store の Ruby 実装
アーキテクチャ
P2P の環状モデル
レプリカの一貫性をある程度意識したモデル
今後の展開
拡張ライブラリによるパフォーマンス・チューニング
モデルを改変しやすくできるフレームワーク化

The Overall Architecture of ROMA

by Muga Nishizawa on Aug 30, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 15

Statistics

The Overall Architecture of ROMA — Presentation Transcript