NoSQLを知る～ kumofs から学ぶ Not only SQL の技術 ～

筑波大学 第三学群情報学類

古橋 貞之@frsyukihttp://d.hatena.ne.jp/viver/

NoSQLを知る～ kumofs から学ぶ Not only SQL の技術 ～

【18-E-5】

自己紹介

• 古橋 貞之（ふるはし さだゆき）• 筑波大学 第三学群 情報学類 4年• 「未来を予測する最善の方法は、それを発明することだ」（アラン・ケイ）

• IPA未踏ユース「統合ディスクレスネットワーク基盤システム VIVER」

自己紹介：VIVER

• 統合ディスクレスネットワーク基盤システム> 「ネットワークをインストール」> システム一式をパッケージ化 → 自律動作 高可用・負荷分散クラスタ 自律分散システム

VIVER CORE

CD/HDD/USBメモリ...

OS（Linux）アプリケーションetc...

圧縮ディスクイメージ

VIVER CORE

CD/HDD/USBメモリ...

OS（Linux）アプリケーションetc...

圧縮ディスクイメージ

ネットワークブート

VIVER CORE

VIVER COREブートメディアを取り替える

システム全体を入れ替え

VIVER CORE

すべて同じ設定

VIVER CORE

すべて同じ設定

VIVER CORE

すべて同じ設定再起動で元通り

RUNES

プラグイン(サービス)

ロールグループ化

割り当て

FileServer WebServer

Role-based Unified Network Extension System

V-FIELDデータ

分散ディスク共有システム

V-FIELD分散ディスク共有システム

V-FIELD

0500

1,0001,5002,0002,5003,0003,500

クライアント30台 クライアント50台

3,076

2,053

922901

NBD（クライアント/サーバ転送）V-FIELD（P2P転送）

1Gbps

(Mbps)

分散ディスク共有システム

締め切り効果

0

5,000

10,000

15,000

7 8 9 10 11 12 1 2

VIVER RUNES V-FIELD(行)

自己紹介（現在）

• 分散Key-valueストア「kumofs」の開発> えとらぼ• Preferred Infrastructure（PFI）

ペアプログラミング支援システム 多人数音声チャットシステム

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

Appサーバ DBサーバWebサーバ

3層モデル

DBサーバ

スケールアウト

キャッシュロードバランサ

Appサーバ DBキャッシュ

DB sharding

ストレージ

『4Gbpsを超えるWebサービス構築術』

分割

○ 負荷分散× JOIN× Atomicな更新

RDBMS(MySQLなど)

DB sharding

DBキャッシュ

DB sharding

RDB + SQL + ACID が快適なところ

データストア

RDBMS + SQL + ACID が不快なところ（非リレーショナル, スケールアウト, ...）

RDB + SQL + ACID が快適なところ

データストア

RDBMS + SQL + ACID が不快なところ（非リレーショナル, スケールアウト, ...）

Key-value StoreColumn-oriented Storeドキュメント指向DBグラフDBキュー

kumofsDynamoROMABigtableCassandraCouchDBMongoDBNeo4JGremlinRedisTokyo Tyrant…

kumofsDynamoROMABigtableCassandraCouchDBMongoDBNeo4JGremlinRedisTokyo Tyrant…

NoSQLスケーラビリティスキーマレスデータモデル...

kumofsDynamoROMABigtableCassandraCouchDBMongoDBNeo4JGremlinRedisTokyo Tyrant…

NoSQLスケーラビリティスキーマレスデータモデル...

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

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

“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

スケーラビリティとは

「拡張性」

ユーザーが増えると…データが増えると…サーバの台数が増えると…

…サーバが落ちる…運用コストが増大する…可用性が下がる

後から拡張が難しい負荷の見積もりに失敗できない

ユーザーが増えても…データが増えても…サーバの台数が増えても…

…拡張して適応できる…運用コストが増大しない…可用性を維持する

後から拡張できる負荷が増えてきたら拡張

ユーザーが増えても…データが増えても…

…拡張して適応できる

スケール・アウトスケール・アップ ×

ユーザーが増えても…データが増えても…

…拡張して適応できる

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

スケール・アップ サーバAサーバB

サーバC

価格

性能

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

スケール・アップ サーバAサーバB

サーバC

価格

性能

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

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

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

価格

性能サーバ追加

サーバ追加

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

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

価格

性能

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

サーバ追加サーバ追加

ユーザーが増えても…データが増えても…サーバの台数が増えても…

…拡張して適応できる…運用コストが増大しない…可用性を維持する

後から拡張できる負荷が増えてきたら拡張

サーバの台数が増えても…

…可用性を維持する

サーバの台数が増えても…

…可用性を維持する

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日 停止)

台数

それぞれを二重化

ユーザーが増えても…データが増えても…サーバの台数が増えても…

…拡張して適応できる…運用コストが増大しない…可用性を維持する

後から拡張できる負荷が増えてきたら拡張

サーバの台数が増えても…

…運用コストが増大しない

後から拡張できる負荷が増えてきたら拡張

サーバの台数が増えても…

…運用コストが増大しない

後から拡張できる負荷が増えてきたら拡張

人

管理

サーバ

人

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

人

一括管理システム管理ツール

「スケーラブル」

スケールアウト耐障害性管理システム・ツール…

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

Consitency

Availability

PartitoningTolerance

http://www.julianbrowne.com/article/viewer/brewers-cap-theoremhttp://www.citeulike.org/user/HenryR/article/3123610

CAP定理

サービスが（快適に）利用できる

Availability

AmazonGoogle

：応答時間が 1/10 秒増加すると、1% の売り上げを逃す：応答時間が 1/2 秒増加すると、トラフィックが 1/5 下がる

http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-ithttp://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html

Consitency

A=100 B=200

Atomic Data Object

Atomicに書き換え可能 > どちらも変更された > どちらも変更されなかった

ネットワーク全体の故障を除くどんな故障が起こっても、間違った結果を返さない

PartitoningTolerance

“No set of failures less than total network failure is allowed to cause the system to respond incorrectly.”

「タイムアウト」

クライアント サーバ

不整合が起こりそうなら止める不整合が起こるのは仕様だ１台で動かす

： Availabilityを失う： Consistencyを失う： Partition Toleranceを失う

分断？

A=100 B=200

A=100 A’=100

Atomic Data Object

Atomic Data Object

A=100 B=200

Atomic Data Object

サーバ1 サーバ2

A=100 B=200

可用性が落ちる or 正しく動作しない

A=100 A’=100

Atomic Data Object

サーバ1 サーバ2

A=100 A’=100

可用性が落ちる or 正しく動作しない

Atomic Data Object Atomic Data Object

A’=100A=100

サーバ1 サーバ2

Eventually Consistentキュー

key

key

key

key

key

key

key

key

key

kumofs, Dynamo, ROMA, ...

RDB

MySQL, ...

レプリケーション

RDB

RDB RDB

RDB RDB

shardingMySQL, ...

Row[column, ...]

Bigtable, HBase, Cassandra, ...

Row[column, ...]

Row[column, ...]

Row[column, ...]

Row[column, ...]

Row[column, ...]

どのサーバに保存するか（分散アルゴリズム）

稼働中にサーバを故障したら稼働中にサーバを追加するには

key

key

key

key

key

key

Consistent Hashing

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

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

NoSQLを設計・実装できる

「未来を予測する最善の方法は、　　　　それを発明することだ」　　　　　　　（アラン・ケイ）

スケーラビリティとは？

NoSQLの技術

kumofs

> 高負荷に耐える> 柔軟な伸縮性> 耐障害性> 規模に比例しない運用コスト

> CAP定理とデータ集合の分割> 分散アルゴリズム

> アーキテクチャ> デモ

NoSQLとは？

kumofs

超高速耐障害性

動的な運用分散 key-value ストア

超高速耐障害性

動的な運用

単一障害点なしレプリケーション（3重化）

スケールアウトmemcachedに迫る性能

動作中にサーバを追加・離脱

Manager

Gateway

Server群を管理

kumofsの構成

実際にデータを保存

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

Server

Application

ServerManager

Gateway

Manager

冗長構成

Server

Server

Server

Server

Server

Application

GatewayApplication

Gateway

レプリケーション

Application

Manager

Gateway

Manager

Server

Server

Server

Server

Server

Application

GatewayApplication

Gateway

切り離し

Application

Manager

Gateway

Manager

Server

Server

Server

Server

Application

GatewayApplication

Gateway

切り離し

Application

Gateway

Manager

Server

Server

Server

Server

Application

GatewayApplication

Gateway

フェイルオーバー

切り離し

Application

Gateway

Gateway

Application

Server Server Server

memcachedプロトコル

MessagePack-RPC

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

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

localhost:11211

MessagePack-RPC

Server Server Server

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

MessagePack-RPC

Server Server Server

管理ツール

人

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

Manager

管理ツール

Rubyで実装

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

> 拡張が容易

kumoctlkumostatkumotop

MessagePack-RPC

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

超高速

Demo