ずばり動く！kumofs と ずばり動かないケース

分散Key-valueストア

hbstudy#10

筑波大学 システム情報工学研究科

古橋 貞之#kumofs　@frsyuki

http://d.hatena.ne.jp/viver/

kumofs

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

高速シリアライズライブラリ

MessagePack

並列イベント駆動I/Oフレームワーク

mpio多人数音声チャットシステム

ペアプログラミング支援システム

未踏ソフトウェア創造事業統合ディスクレスネットワーク基盤システム

並列イベント駆動I/Oフレームワーク

mpio

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

kumofsが解決する問題

• サーバが１台停止しても、システム全体は動き続けて欲しい。

• データや負荷の増加に合わせて、柔軟に性能を向上させていきたい。

• 上記のようなシステムを高度なノウハウを必要とせずに低コストで構築したい。

• 上記のようなシステムの運用を簡略化し、操作ミスを低減したい。

ご一緒にkumofsも

• kumofsが得意とするデータ> key-value> 総量の増加が事前に予測できない> 数が膨大> ランダムアクセスが多い

• データの一部をRDBMSからkumofsに移す> RDBMSとも併用> システム全体としてスケーラビリティを向上

コンテンツデータ

コンテンツメタデータ（検索用）

コンテンツメタデータ（key-value）

セッションデータ

解析用の時系列データ

> 文章や画像

> 日付やタグ

> 名前やコメント

> ログイン情報など

> アクセスログなど

body=”....”

update=2010-04-24

user=”viver”

lastlogin=2010-04-23

{date: 1271866094, item: 3, num: 1}

コンテンツデータ

コンテンツメタデータ（検索用）

コンテンツメタデータ（key-value）

セッションデータ

解析用の時系列データ

> 文章や画像

> 日付やタグ

> 名前やコメント

> ログイン情報など

> アクセスログなど

RDBMS

従来の問題

• RDBMS をスケールアップして負荷の増大に対応• スケーラビリティが低い> 速度・容量・可用性・価格・運用> 規模透過性が低い 大規模化が難しい

「利用者や仕事の増大に適応できる能力」

“the ability of a system to accommodate an increasing number of elements or objects,to process growing volumes of work gracefully, and/or to be susceptible to enlargement”

André B. Bondi, 'Characteristics of scalability and their impact on performance',Proceedings of the 2nd international workshop on Software and performance,Ottawa, Ontario, Canada, 2000, pp.195 - 203

スケーラビリティとは

「拡張性」

負荷増大→サーバを置き換える

スケール・アップ

価格

性能

> 指数関数的に価格が増大> 性能向上に限界> 拡張時に高コスト> 負荷の見積もりが必須

サーバ置き換えサーバ置き換え

負荷増大→サーバの数を増やす

スケール・アウト サーバ追加

価格

性能

> 負荷に見合った価格> 性能向上はソフトに依存> 最小限のコストで拡張> 負荷が増えたら拡張

サーバ追加サーバ追加

0%

1%

10%

100%

1 2 4 8 16 32 64 128 256 512

稼働率 99% のサーバ (1年間で 3.65日 停止)

85% (1年間で 55日 停止)

28% (1年間で 262日 停止)

台数

0%

1%

10%

100%

1 2 4 8 16 32 64 128 256 512

99.8% (1年間で 0.73日 停止)

95.0% (1年間で 18日 停止)

98.7% (1年間で 4.7日 停止)

台数

それぞれを二重化

人

サーバ

管理

人

・操作ミス・稼働率低下　…

企業IT動向調査2008http://itpro.nikkeibp.co.jp/article/Research/20080716/310976/

コンテンツデータ

コンテンツメタデータ（検索用）

コンテンツメタデータ（key-value）

セッションデータ

解析用の時系列データ

> 文章や画像

> 日付やタグ

> 名前やコメント

> ログイン情報など

> アクセスログなど

RDBMS

コンテンツデータ

コンテンツメタデータ（検索用）

コンテンツメタデータ（key-value）

セッションデータ

解析用の時系列データ

> 文章や画像

> 日付やタグ

> 名前やコメント

> ログイン情報など

> アクセスログなど

コンテンツデータ

コンテンツメタデータ（検索用）

コンテンツメタデータ（key-value）

セッションデータ

解析用の時系列データ

> 文章や画像

> 日付やタグ

> 名前やコメント

> ログイン情報など

> アクセスログなど

RDBMS

MogileFS

kumofs

hBase (Hadoop)

kumofs

解決方法

• データの一部を新しい種類のデータストアに移す> RDBMSも使い続ける> 分散に適したデータだけ移す 分散に適したデータモデルを採用する 既存の制約に縛られずに設計・実装> システム全体としてはスケーラビリティが向上> 透過的に分散する> 運用タスクは自動化する

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

Manager

Gateway

Server群を管理

kumofsの構成

実際にデータを保存

アプリケーションからの要求を中継

Server

Application

ServerManager

Gateway

Manager

冗長構成

Server

Server

Server

Server

Server

Application

GatewayApplication

Gateway

レプリケーション

Tokyo Cabinet

Server

Server

Server

Server

Server

Server

サーバ A

サーバ B

サーバ C

サーバ D

Consistent Hashing

hash(サーバA.id)

hash(サーバB.id)

hash(サーバC.id)

hash(サーバD.id)

hash(key1)

サーバ A

サーバ B

サーバ C

サーバ D

Consistent Hashing

サーバ A

サーバ B

サーバ C

サーバ D

サーバBの担当範囲

サーバ A

サーバ B

サーバ C

サーバ D

サーバBの担当範囲

サーバCの担当範囲サーバD

の担当範囲

サーバAの担当範囲

サーバ A

サーバ B

サーバ C

サーバ D

set

レプリケーション

保存とレプリケーション

サーバ A

サーバ B

サーバ C

サーバ D

get取得と耐障害性

サーバ A

サーバ C

サーバ D

get取得と耐障害性

サーバ A

サーバ C

サーバ D

get取得と耐障害性

サーバ A

サーバ B

サーバ C

サーバ D

サーバBの担当範囲

サーバCの担当範囲サーバD

の担当範囲

サーバAの担当範囲

ノードの追加

サーバ A

サーバ B

サーバ C

サーバ D

サーバBの担当範囲

サーバCの担当範囲

サーバAの担当範囲

サーバ E

データを移動

ノードの追加

サーバ A

サーバ B

サーバ C

サーバ D

サーバBの担当範囲

サーバCの担当範囲サーバD

の担当範囲

サーバAの担当範囲

ノードの追加

サーバ A

サーバ B

サーバ C

サーバ D

サーバBの担当範囲

サーバCの担当範囲

サーバAの担当範囲

サーバ E

データを移動

ノードの追加

サーバ A

サーバ B

サーバ C

サーバ D

サーバ E

データを移動中...

ノードの追加

サーバ A

サーバ B

サーバ C

サーバ D

サーバ E

setget

ノードの追加

サーバ A

サーバ B

サーバ C

サーバ D

サーバ E

setget

ノードの追加

サーバ A

サーバ B

サーバ C

サーバ D

サーバ E

setget

ノードの追加

getset

get用ルーティング表 set用ルーティング表

kumofsのノード追加アルゴリズム（double-hash-space）

Application

ServerManager

Gateway

Manager

冗長構成

Server

Server

Server

Server

Server

Application

GatewayApplication

Gateway

Managerの役割

Manager

Manager

冗長構成

Server

Server

Server

ServerServer

Managerの役割

死活監視

Application

Gateway

Manager

Manager

冗長構成

Server

Server

Server

ServerServer

Managerの役割

死活監視

Application

Gateway Consistent Hashing表を更新他のノードに通知

ノードの障害を検出

Manager

Manager

冗長構成

Server

Server

Server

Server

Server

Server

Managerの役割

死活監視

Consistent Hashing表を更新他のノードに通知Application

Gateway

ノードの追加を承認

Application

Gateway

Gateway

Application

Server Server Server

memcachedプロトコル

MessagePack-RPC

・サーバーの構成を隠蔽　いつでもlocalhostで動作する　memcachedサーバーに見える

・高速RPCライブラリ・多言語対応・非同期/並列処理

localhost:11211

管理ツール

Rubyで実装

> 実装が容易親切なコマンドライン分かりやすい表示

> 拡張が容易

> 管理タスクを自動化

kumoctlkumostatkumotop

MessagePack-RPC

MessagePack-RPC

Server Server Server

管理ツール

人

Manager

ノード一覧を問い合わせ

Manager

svr001

Server

Manager

svr002

Server

最初は少ない台数で運用

Manager

svr001

Server

Manager

svr002

Server

svr003

Server

負荷が増えたらサーバーを足す負荷に合わせて柔軟に拡張可能

最初は少ない台数で運用

Manager

svr001

Server

Manager

svr002

Server

svr003

Server

svr005

Server 負荷が増えたらサーバーを足す負荷に合わせて柔軟に拡張可能

最初は少ない台数で運用

Manager

svr001

Manager

svr002 svr003

Server

svr005

Server

svr006

Server

svr007

Server

0

28,500

57,000

85,500

114,000

memcached kumofs

114,000 req/sec110,000 req/sec

サーバー　Linux 2.6.27.10 x86_64 AMD Athlon 64 X2 5000+

クライアント　Linux 2.6.27.19 x86_64 AMD Athlon 64 X2 4800+

１台のサーバーに対して３台のクライアントから同時に負荷を掛け、サーバー１台の最大スループットを計測。keyは32バイト、valueは1KB

で、8本のスレッドでそれぞれ32個のkeyを同時に取得。合計960,000個のkeyを取得するのにかかった時間を３回計測し、その平均値からスループットを算出。

超高速

0

800,000

1,600,000

2,400,000

3,200,000

10 20 30 40 50 60

(requests/sec)

台数(台)

kumofsサーバー　Linux 2.6.27.21 i686 Intel Pentium 4 3.20GHz

クライアント　Linux 2.6.27.21 x86_64 Intel QuadCore Xeon X3350

クライアントの台数を50台に固定し、サーバーの台数を10台から60台まで増やして計測。 keyは8バイト、valueは32バイトで、32本のスレッドでそれぞれ256個のkeyを同時に取得。合計51,200,000個のkeyを取得するのにかかった時間を計測した平均値からスループットを算出。

超高速

足せばいい世界

• 事前に性能の見積もりが不要> システムを止めずに性能を増強可能> 少ない台数でも高性能 ２台～の構成でも高速に動作

• サーバの数が増えても運用の手間が増えない> 高度なノウハウ無しに大規模化が可能

• 安い

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

他の分散データストアとの比較

• Column-oriented DB（列指向DB）> BigTable, hBase, HyperTable> Sybase IQ, Vertica など

• Eventually Consistent> Dynamo, Voldemort, Cassandra など

• 分散指向でない（書き込みのスケールアウト+ノードの動的な追加）> Tokyo Tyrant, redis など

列指向DBとの違い

• 列指向DB> バッチ処理重視> シーケンシャルアクセス> 高遅延

• kumofs> リアルタイム処理重視> ランダムアクセス> 低遅延

列指向データベースについて太田一樹氏(株式会社Preferred Infrastructure)楽天テクノロジーカンファレンス2009

Eventually Consistent との違い

• Eventually Consistent> ノード増減時は、さしあたり自分から見て担当ノードに見えるノードにデータを書き込む

> 値を読み出すときは、複数の値を読む 値が異なっていれば、マージして再書き込み Vector Clock を基準にしてマージする

• kumofs> double-hash-spaceアルゴリズム 担当ノードはkumo-managerが決定

サーバ C サーバ D

クライアント1 クライアント2

key1

key1=100 key1=200

key1=200

サーバ C サーバ D

クライアント1 クライアント2

Dynamo

key1=100

key1=100

クライアント1 クライアント2

Dynamo

key1=100 key1=200

key1=100 key1=200

・ノード追加時・ノード障害時・ネットワーク障害時

クライアント3

Dynamo

key1=100 key1=200

クライアント3

Dynamo

key1=150

key1=100 key1=200

クライアント3

Dynamo

key1=150

key1=150 key1=150

00:00.01 00:00.02 00:00.03

00:00.01

サーバ A

サーバ B

T1 T2 T3

T4

T1 < T2T2 < T3

T2 > T4 ???T3 > T4 ???

絶対時刻を使った方法

通信

[A=1, B=0] [A=2, B=0] [A=3, B=0]

[A=2, B=1][A=0, B=0]

サーバ A

サーバ B

T1 T2 T3

T4

T1 < T2T2 < T3

T2 < T4T3 || T4

Vector Clock[A=1, B=0]

[A=1]key1=0

[A=2]key1=50

[A=3]key1=100

[A=2, B=1]key1=200

[A=3, B=1]key1=150

→ A

→ A

→ B→ A

クライアント1 クライアント2

Dynamo

key1=100 key1=200

key1=100 key1=200

クライアント1 クライアント2

kumofs

key1=100 key1=200

key1=100

クライアント1 クライアント2

kumofs

key1=100 key1=200

key1=100managerが切り離し

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

Demo

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

ご一緒にkumofsもいかがですか。

足りなくなったら足せばいいので。

Eventually Consistent、ではない真実。

> 背景

> kumofsのアーキテクチャ

kumofsとは？

第二世代分散データストア構想

ずばり動く！ kumofs

> 他の分散データストアとの比較> 列指向DB と Eventually Consistent

第二世代分散データストア

• 第一世代> Bigtable, HBase, Hypertable> Dynamo, Kai> kumofs> ROMA> Flare> Voldemort

第二世代分散データストア

• 第二世代> Cassandra <= Bigtable + Dynamo> 開発中 <= Cassandra + kumofs

ズバリ動かないケース

• kumofsの問題> データモデル（空間的局所性）> 更新の全順序保証> レプリケーション失敗時の挙動> DC間レプリケーション > 巨大データとデータの移動> 時系列データ

構想

• Key-Table Store• 更新の全順序保証と強い一貫性> 多数決に基づくメンバーシップ> 任期に基づく障害検出

• レプリケーションログ• 一貫性のレベルを選択可能なレプリケーション• 行指向と列指向の統合

Quorum Server (QS)

Data Server (DS)Data Server (DS)Gateway (GW)

Quorum Server (QS)

Data Server (DS)Data Server (DS)Gateway (GW)

Key-Table Store

• Partition => Row => Column• ひとつのPartitionは1台のノードに保存> hash(Partition) + Consistent Hashing

• ひとつのPartition内では複雑なクエリをサポート> 範囲検索, トランザクション> SQL？ 独自のクエリ言語？ DSに汎用的な言語処理系（JavaScript？） Stored Procedure, MapReduce（のMap）

更新の全順序保証

• kumofsの問題> ノード数が増減→再配置中にSetすると、Set先のノードには古いデータがまだ無い可能性がある 再配置中は append, incr, cas, ... ができない 再配置中は 順番に依存する更新 ができない> 衝突は検出もできない（Lamport Clock）

• Eventually Consistent でも同じ> 検出はできる（Vector Clock）

更新の全順序保証

• 解決策> 再配置中に受け取った順番に依存するSet要求は、注意深く扱う（簡単な実装方法を募集中） 再配置中か否か判別する方法> ある瞬間に、書き込みを担当可能なノードは必ず１台以下にする

多数決に基づくメンバーシップ

• Quorum Server (QS)> DSの死活監視を行う> 台数は固定（例：３台）

• Data Server (DS)> 実際にデータを保存する

• Gateway (GW)> アプリケーションからDSにクエリを中継する

• split-brainを防止する> QS-1：DS-1 は fault> QS-2：DS-1 は ready> QS-2：DS-1 は ready →DS-1 は ready

多数決に基づくメンバーシップ

QS-1 QS-2 QS-3

DS-1 DS-2

任期に基づく障害検出

• マズイ状況> DS-1：[DS-1, DS-2]> DS-2：[DS-2]> GW-1：[DS-1, DS-2]> GW-2：[DS-2]> [DS-1, DS-2]の場合：key1 は DS-1 に保存> [DS-2]の場合：key1 は DS-2 に保存 GW-1 は key1を DS-1 に保存 GW-2 は key1を DS-2 に保存

任期に基づく障害検出

• 問題ない状況> DS-1：[DS-1] ← [DS-1, DS-2] ではなく> DS-2：[DS-2]> GW-1：[DS-1, DS-2]> GW-2：[DS-2]> [DS-1, DS-2]の場合：key1 は DS-1 に保存> [DS-2]の場合：key1 は DS-2 に保存 GW-1 は key1を DS-1 に保存 ←DS-1は拒否！ GW-2 は key1を DS-2 に保存

任期に基づく障害検出

• DSが「自分は死んだ」と認識したことが保証されてから、ルーティング表を更新する

• DSは、N秒以上「任期」が更新されなかったら、「自分は死んだ」とする。任期はQSが更新する

• QSは、DSが死んだと思われたら、任期の更新を停止する

• QSは、任期の更新を停止してからN+M秒以上経過したら、ルーティング表からそのDSを取り除く

ノード増減時でも更新の全順序を保証

• 多数決に基づくメンバーシップ ＋ 任期に基づく障害検出> あるkeyを保存できるDSは、どの瞬間でも1台以下> 全順序を保証可能

• （ノードの増減時に）データの移動を注意深く行う> 4つのステージ join：ノードの参加処理が進行している途中ready：ノードの参加処理が終わった fault：ノードが落ちている leave：ノードの切り離し処理が進行している途中

一貫性のレベルを選択可能なレプリケーション

• Chain Replication with Apportioned Queries (CRAQ)> Jeff Terrace and Michael J. Freedman. Object Storage on CRAQ High-throughput chain replication for read-mostly workloads. In Proc. USENIX Annual Technical Conference, June 2009.

• Eventual Consistency と Strong Consistency を読み取り時に選択可能

• Lazyなレプリケーション

一貫性のレベルを選択可能なレプリケーション

列指向DBへ

• MapReduce> Hadoopと連携するインタフェース