gumistudy#1 キーバリューストアのご紹介と利用時の設計モデルについて

分散キーバリューストア

okuyamaのご紹介と

利用時の設計モデルについて

株式会社神戸デジタル・ラボ

岩瀬高博

Mail: [email protected]

Twitter: @okuyamaoo

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

自己紹介・株式会社神戸デジタル・ラボ

>神戸を基盤にＩＣＴソリューションを展開

・岩瀬高博

> Twitter: @okuyamaoo

>活動

>kvs-ja (Googleユーザグループ)

>OSS分散キーバリューストア okuyama を作成

http://sourceforge.jp/projects/okuyama/

1.分散Key-Value Store？

2.システムに組み込む場合は?

～そしてokuyamaでは～

アジェンダ

分散Key-Value Storeって？

分散Key-Value Storeとは?

分散Key-Value Storeって？


>その前にまずKey-Value Storeから

Key-Value Storeって？



>KeyとValueの関係で値を保持できる仕組み





Key-1

Key-2

Key-3

Value-1

Value-2

Value-3

“Key-1”のValueを取得Key-1 Value-1

“Value-1”が取得できる





Key-1

Key-2

Key-3

Value-1

Value-2

Value-3“Key-4”,“Value-4”を登録

Key-4 Value-4

Key-4 Value-4





>特徴

・シンプルなデータモデル

・シンプルな操作方法

・最小単位での一貫性

最小単位での一貫性？

1つのデータの更新が混在しないことのみ保障

>どんな利点が?


1つのデータの更新が混在しないことのみ保障

>どんな利点が?

>データの整合性確保の範囲を限定できる

2つのデータは個々で更新される

関係性を持たないKey-1

Key-2

Value-11

Value-2

“Key-1”を“Value-11”へ更新

Key-1 Value-11

Key-3 Value-3

Key-4 Value-44


Key-4 Value-44


データの整合性確保の範囲を限定できる

>ということは？




>分散して管理することが可能

Key-1

Key-2

Value-11

Value-22


Key-1 Value-11

Key-3 Value-3

Key-4 Value-44


Key-4 Value-44




>分散して管理することが可能

Key-1

Key-2

Value-11

Value-22


Key-1 Value-11

Key-3 Value-3

Key-4 Value-44


Key-4 Value-44

分散Key-Value Store

分散Key-Value Storeの配置システム稼働当初

利用者データベースアプリ

RDBMS

分散Key-Value Storeの配置

利用者データベース

利用者の増加

アプリ

RDBMS


RDBMS

利用者アプリデータベース

アプリケーションサーバを増設



ボトルネック

データベースがボトルネックに

RDBMS

システム構成


・スケールアップで対応

・更新系と検索系を分割

検索ノード

検索ノード

更新ノード

対応策

検索ノード

システム構成


・スケールアップで対応

・更新系と検索系を分割

・スケールアップの限界

・更新系はボトルネック

・管理の煩雑化

検索ノード

更新ノード

対応策

全てのデータを高度なデータモデルを

有するRDBMSに格納する必要はある？

利用状況に合わせて柔軟に対応できるモデルが今後は必要

他の対応策は？

分散キーバリューストア全てのデータを高度なデータモデルを

有するRDBMSに格納する必要はある？

>キーとバリューの関係で成り立つデータ

>複雑なトラントランザクションを必要としない

利用状況に合わせて柔軟に対応できるモデルが今後は必要

>スケールアウトによる性能向上

>高い対障害性

検索ノード

分散Key-Value Storeという選択

アプリ RDBMS

検索ノード

更新ノード

分散KVS

okuyama?

Javaで実装された分散KVS・全体構成

・クライアント→ マスターノード→ データノード

メインマスターノード

メインデータノード

スレーブデータノード







クライアント

クライアント

スレーブマスターノードクライアント

Javaで実装された分散KVS・クライアント

クライアント

クライアント

クライアントokuyamaへの問い合わせを実現

・専用クライアントはJavaと、PHPが実装済み

Javaで実装された分散KVS・マスターノード


スレーブマスターノード

・クライアントからのI/F

・サポートプロトコル

>オリジナル

>Memcached

>HTTP

・データノード管理

>データ入出力

データ保存場所の決定は

2つのアルゴリズムから選択

1. Mod

2. ConsistentHash

>生存監視

起動時のデータリカバリ

・制限台数なしに冗長化可能

Javaで実装された分散KVS・データノード









・データの保存を実現

・データ保存方式を選択可能

・最大3ノードにデータを保存

・アクセスバランシング

・連鎖的ダウンの予防





・複数データノードでのデータ一貫性

Javaで実装された分散KVS



サードデータノード

1.弱一貫性

２.中一貫性

3.強一貫性

1.弱一貫性

>メイン、スレーブ両データノードにランダムにアクセス

２.中一貫性

>常に最後に保存したデータノードからアクセス

3.強一貫性

>データノードの値を検証

Javaで実装された分散KVS・複数データノードでのデータ一貫性



サードデータノード

検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama

検索結果、参照回数の多いデータを配置してRDBMSの負荷を分散

検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama

更新処理の負荷は軽減できない？

永続化層としての活用はできない？

検索結果、参照回数の多いデータを配置してRDBMSの負荷を分散

選べるデータ保存方式・データノードへの保存方式を選択可能


1.全てのデータをメモリに保存

２.データ操作履歴のみファイルに保存

3.データ本体をファイルに保存

・データノードへの保存方式を選択可能



>非永続型

２.データ操作履歴のみファイルに保存

>永続型


>永続型

選べるデータ保存方式

・それぞれの特性


・仕組み

Key値、Value値の両方をメモリ上で管理

・特徴

最も高速に動く

ノード停止でデータも消滅

保存出来るデータ量はメモリ量に依存



2.データ操作履歴のみファイルに保存

・仕組み

データへの操作を全てファイルに時系列に記録


・データへの操作を全てファイルに時系列に記録

Key5 = Value5登録処理

[履歴記録ファイル]

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

データノード

最後尾に追記



Key5 = Value5


登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

データノード

最後尾に追記

Key5 = Value5

データノードのメモリに反映

[データノードのメモリ]


登録処理


Key5削除処理

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5

データノード

最後尾に追記

Key5

データノードのメモリに反映






・仕組み


記録ファイルからデータを復元


・記録ファイルからデータを復元

データノード

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5


①記録ファイルから順次操作を読み込み



Key1 = Value1

②メモリに反映


データノード

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5





Key1 = Value1

Key2 = Value2



データノード

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5





Key1 = Value1

Key2 = Value2

Key3 = Value3



データノード

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5





Key1 = Value1

Key2 = Value2

Key3 = Value3

Key4 = Value4



データノード

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5





Key1 = Value1

Key2 = Value2

Key3 = Value3

Key4 = Value4

Key5 = Value5



データノード

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5





Key1 = Value1

Key2 = Value2

Key3 = Value3

Key4 = Value4



データノード

登録,Key1,Value1

登録,Key2,Value2

登録,Key3,Value3

登録,Key4,Value4

登録,Key5,Value5

削除,Key5,Value5



復元完了!!




・仕組み


記録ファイルからデータを復元

・特徴

データの永続化が可能で且つ、起動後は高速に動く

保存出来るデータ量はメモリに依存




・仕組み

データ永続化の仕組みは「2.」と同じ

Key値のみメモリに保持し、Value値はファイルに保存


・Key値とデータの場所をメモリに保持

Key5 = Value5

データノード

「2.」の仕組みを利用

[データファイル]

Value1

Value2

Value3

Value4

Value5


Key5 = 5行目

データファイルにValue値を保存

メモリにKey値とValue値のファイル内での位置を保持


登録処理



・仕組み

データ永続化の仕組みは「2.」と同じ

Key値のみメモリに保持し、Value値はファイルに保存

・特徴

データの永続化が可能

大量のデータを保存可能

データ操作時に常にファイルアクセスが頻発するため、

レスポンスに問題が出やすい


検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama

検索結果、参照回数の多いデータを配置してRDBの負荷を分散

更新回数の多い単純データを配置し、RDBの負荷を軽減

検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama

システムのスループットが向上することによるさらなる負荷増加への対応は？

対応中のシステム停止は必要？

スケールアウトによる性能向上・マスターノード、データノード共に

システム停止無しでスケールアウト可能

・スケールアウト時のデータ移行などは

全て自動で行われる













ノード追加

データ移行

追加

スケールアウトによる性能向上・マスターノード、データノード共に

システム停止無しでスケールアウト可能

・スケールアウト時のデータ移行などは

全て自動で行われる

ミニマムスタートで後から性能向上も容易

検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama

ノード数を増やせば故障率も増加

99.99%のサーバを1年運用すると、53分停止する

このサーバは10台並べると、単純合計530分停止

検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama

okuyamaクラスタの障害発生時の対応は？

対応中のシステム停止は必要？

ノード数を増やせば故障率も増加

SPOFの存在しない構成・データの取得の流れ








クライアントスレーブ

マスターノード

①データ取得













①データ取得

②データ保持ノード割り出しメイン

データノードスレーブデータノード











①データ取得



③データ取得

②データ保持ノード割り出し

SPOFの存在しない構成・データノード障害発生










①データ取得



障害発生!!


SPOFの存在しない構成・データノード障害発生










①データ取得



もう一つのノードから取得


SPOFの存在しない構成・マスターノード障害発生









①データ取得













①データ取得



障害発生!!











①データ取得



別のマスターノードに再接続処理続行


SPOFの存在しない構成・自動データリカバリー機能











①各データノードを定期的に監視












②障害発生を検知





③定期的に再起動していないか確認




























再起動

④再起動を検知

※別筐体で起動しても問題ない

















⑤片側のノードからデータを復元

復元中もシステムは停止しない




④再起動を検知

※別筐体で起動しても問題ない

検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama故障を前提とした、配置を行い、自動復旧の強みを最大限に利用する。





メインマスターノードメインマスターノード





検索ノード


アプリ RDBMS

検索ノード

更新ノード

okuyama

ノード数増加時の管理コストは？





メインマスターノードメインマスターノード





一括管理機能・設定変更、現状確認

・データノード状態確認



1ノードづつ管理するのは大変



1ノードづつ管理するのは大変

一括管理可能なWebコンソール

一括管理機能

okuyamaならではの機能・Key-Valueの関係だけじゃない

・データロックでデータ整合性処理も

・JavaScriptで簡単フィルタリング

okuyamaならではの機能・Key-Valueの関係だけじゃない

>Tagを登録することができるset (Key=“okuyama”, Tag={“oss”, ”kvs”}, Value=“分散KVS”);

set (Key=“httpd”, Tag={“oss”, ”webserver”}, Value=“代表的WebSV”);

getTagKeys(“oss”);

>取得結果 {“okuyama”, ”httpd”}

タグを登録すると同じタグで登録されているデータのKeyをまとめて取得できる

データのグルーピングが可能

okuyamaならではの機能・データロック機構

>全データノードをまたいでロック可能Lock実施

lockData (Key=“okuyama”, Lock維持時間=10, Lockリトライ時間=5);

※別クライアントから

set (Key=“okuyama”, Value=“Ver1.0.0“);

>Lockを実施したクライアントがLock解除するか、

Lock維持時間が経過するまで待たされる

データ整合性を意識した処理が可能

okuyamaならではの機能・データノードでJavaScriptを実行

>任意のJavaScriptを取得データに実行可能取得したいデータのKey値と、同時に実行したいJavaScriptを指定

getValueScript (Key=“okuyama”, Script=“var dataValue; var retValue =

dataValue.replace(‟KVS„, ‟キーバリューストア‟); var execRet = '1'; ”);

>取得結果 {“分散キーバリューストア”}

実行するJavaScriptのdataValueという変数にKey値から取得された

値が代入されて実行される。クライアントは変数retValueの値が返され

返却するかどうかは、変数execRetの値で決まる。

データのフィルタリングや、加工をデータノードの資源を使って実行可能

最後に・okuyamaユーザグループ作成しました

URL : http://groups.google.co.jp/group/kvs_okuyama

MAIL: [email protected]

ご清聴ありがとうございました。

gumistudy#1 キーバリューストアのご紹介と利用時の設計モデルについて

Technology