分散Key-valueストア

～ kumofsの思想と設計 ～

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

古橋 貞之#kumofs　@frsyuki

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

kumofs

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

MessagePack

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

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

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

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

http://msgpack.sourceforge.net/doc:poweredby

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

kumofsとは？

• 拡張性の高い分散KVS> アプリケーションに影響せずに動的に拡張できる> レプリケーション機能を備える> サーバが故障しても止まらない・復旧も無停止> 一括管理ツール> システムを拡張する作業が自動化されている> memcachedプロトコルをサポート

kumofsが解決する問題

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

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

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

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

問題の例

• Webアプリケーション• すべてのデータをRDBMSに格納> RDBMSがボトルネックになりがち> RDBMSの性能がシステム全体の性能を制約

• 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/

問題の例（再掲）

• すべてのデータをRDBMSに格納> RDBMSがボトルネックになりがち> RDBMSの性能がシステム全体の性能を制約

• RDBMSのスケーラビリティが低い> 速度・容量・可用性・価格・運用の面で> システム全体のスケーラビリティが低くなる> 大規模化が困難

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

従来の解決方法

• RDBMSをスケール･アウトさせる• 複数のRDBMSにデータを分割して保存して高速化> 垂直分散> 水平分散

• 複数のRDBMSに同じデータを保存して高可用化> レプリケーション

RDBMS

アプリケーション

プレゼンテーション

アプリケーション

RDBMS

アプリケーション

プレゼンテーション

RDBMS

アプリケーション

RDBMS

アプリケーション

プレゼンテーション

アプリケーション

RDBMS

アプリケーション

プレゼンテーション RDBMS

アプリケーション

システムの拡張：

・サーバの追加で対応可能・アプリケーションの書き換えが必要・データの移動が必要 > システムが一時的に停止 > 操作ミスの危険性

従来の解決方法

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

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

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

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

理想的な解決方法

• RDBMSが勝手に（透過的に）分散してくれる> 実装が難しい フルセットのSQLの実装は非常に難しい> データモデルが分散に適さない スケーラブルな範囲検索 スケーラブルなJOIN トランザクション

提案する解決方法

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

kumofsとは？（再掲）

• 拡張性の高い分散KVS> アプリケーションに影響せずに動的に拡張できる> レプリケーション機能を備える> サーバが故障しても止まらない・復旧も無停止> 一括管理ツール> システムを拡張する作業が自動化されている> memcachedプロトコルをサポート

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

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

サーバ 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）

Manager

Gateway

Server

Managerの役割

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を取得するのにかかった時間を計測した平均値からスループットを算出。

超高速

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

背景

従来手法

提案手法

> スケール･アップシステムの問題

> 運用によるスケール･アウト> 従来手法の課題

> double-hash-space> 異種言語間RPCと管理タスクの自動化

kumofsとは？

デモ

設計と実装

Demo