NoSQLを知る
-
Upload
sadayuki-furuhashi -
Category
Documents
-
view
7.395 -
download
0
Transcript of NoSQLを知る
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.”
「タイムアウト」
クライアント サーバ
不整合が起こりそうなら止める不整合が起こるのは仕様だ1台で動かす
: 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+
1台のサーバーに対して3台のクライアントから同時に負荷を掛け、サーバー1台の最大スループットを計測。keyは32バイト、valueは1KB
で、8本のスレッドでそれぞれ32個のkeyを同時に取得。合計960,000個のkeyを取得するのにかかった時間を3回計測し、その平均値からスループットを算出。
超高速
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