gumistudy#1 キーバリューストアのご紹介と利用時の設計モデルについて
DESCRIPTION
キーバリューストアをこれから利用したい、利用したいけどもどのように システムに組み込めばよいか悩んでいる。 こういった疑問に対して当日は、分散キーバリューストア「okuyama」の開発者が キーバリューストアとは?からシステム組み込み時のモデルまで、okuyamaの ご紹介を交えてご説明させていただきます。TRANSCRIPT
分散キーバリューストア
okuyamaのご紹介と
利用時の設計モデルについて
株式会社神戸デジタル・ラボ
岩瀬高博
Mail: [email protected]
Twitter: @okuyamaoo
http://d.hatena.ne.jp/okuyamaoo/
自己紹介・株式会社神戸デジタル・ラボ
>神戸を基盤にICTソリューションを展開
・岩瀬高博
> 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 Storeって?
分散Key-Value Storeとは?
>その前にまずKey-Value Storeから
>KeyとValueの関係で値を保持できる仕組み
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-Value Storeって?
分散Key-Value Storeとは?
>その前にまずKey-Value Storeから
>KeyとValueの関係で値を保持できる仕組み
Key-1
Key-2
Key-3
Value-1
Value-2
Value-3“Key-4”,“Value-4”を登録
Key-4 Value-4
Key-4 Value-4
Key-Value Storeって?
分散Key-Value Storeとは?
>その前にまずKey-Value Storeから
>KeyとValueの関係で値を保持できる仕組み
>特徴
・シンプルなデータモデル
・シンプルな操作方法
・最小単位での一貫性
Key-Value Storeって?
分散Key-Value Storeとは?
>その前にまずKey-Value Storeから
>KeyとValueの関係で値を保持できる仕組み
>特徴
・シンプルなデータモデル
・シンプルな操作方法
・最小単位での一貫性
最小単位での一貫性?
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-4 Value-44
最小単位での一貫性?
データの整合性確保の範囲を限定できる
>ということは?
最小単位での一貫性?
データの整合性確保の範囲を限定できる
>ということは?
>分散して管理することが可能
Key-1
Key-2
Value-11
Value-22
“Key-1”を“Value-11”へ更新
Key-1 Value-11
Key-3 Value-3
Key-4 Value-44
“Key-4”を“Value-44”へ更新
Key-4 Value-44
最小単位での一貫性?
データの整合性確保の範囲を限定できる
>ということは?
>分散して管理することが可能
Key-1
Key-2
Value-11
Value-22
“Key-1”を“Value-11”へ更新
Key-1 Value-11
Key-3 Value-3
Key-4 Value-44
“Key-4”を“Value-44”へ更新
Key-4 Value-44
分散Key-Value Store
分散Key-Value Storeの配置システム稼働当初
利用者 データベースアプリ
RDBMS
分散Key-Value Storeの配置
利用者 データベース
利用者の増加
アプリ
RDBMS
分散Key-Value Storeの配置
RDBMS
利用者 アプリ データベース
アプリケーションサーバを増設
分散Key-Value Storeの配置
利用者 アプリ データベース
ボトルネック
データベースがボトルネックに
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.弱一貫性
2.中一貫性
3.強一貫性
1.弱一貫性
>メイン、スレーブ両データノードにランダムにアクセス
2.中一貫性
>常に最後に保存したデータノードからアクセス
3.強一貫性
>データノードの値を検証
Javaで実装された分散KVS・複数データノードでのデータ一貫性
メインデータノード
スレーブデータノード
サードデータノード
検索ノード
分散Key-Value Storeという選択
アプリ RDBMS
検索ノード
更新ノード
okuyama
検索結果、参照回数の多いデータを配置してRDBMSの負荷を分散
検索ノード
分散Key-Value Storeという選択
アプリ RDBMS
検索ノード
更新ノード
okuyama
更新処理の負荷は軽減できない?
永続化層としての活用はできない?
検索結果、参照回数の多いデータを配置してRDBMSの負荷を分散
選べるデータ保存方式・データノードへの保存方式を選択可能
メインデータノード
1.全てのデータをメモリに保存
2.データ操作履歴のみファイルに保存
3.データ本体をファイルに保存
・データノードへの保存方式を選択可能
メインデータノード
1.全てのデータをメモリに保存
>非永続型
2.データ操作履歴のみファイルに保存
>永続型
3.データ本体をファイルに保存
>永続型
選べるデータ保存方式
・それぞれの特性
1.全てのデータをメモリに保存
・仕組み
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
データノードのメモリに反映
[履歴記録ファイル]
[データノードのメモリ]
選べるデータ保存方式
・それぞれの特性
1.データ操作履歴のみファイルに保存
・仕組み
データへの操作を全てファイルに時系列に記録
記録ファイルからデータを復元
選べるデータ保存方式
・記録ファイルからデータを復元
データノード
登録,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
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.データ操作履歴のみファイルに保存
・仕組み
データへの操作を全てファイルに時系列に記録
記録ファイルからデータを復元
・特徴
データの永続化が可能で且つ、起動後は高速に動く
保存出来るデータ量はメモリに依存
選べるデータ保存方式
・それぞれの特性
3.データ本体をファイルに保存
・仕組み
データ永続化の仕組みは「2.」と同じ
Key値のみメモリに保持し、Value値はファイルに保存
選べるデータ保存方式
・Key値とデータの場所をメモリに保持
Key5 = Value5
データノード
「2.」の仕組みを利用
[データファイル]
Value1
Value2
Value3
Value4
Value5
[データノードのメモリ]
Key5 = 5行目
データファイルにValue値を保存
メモリにKey値とValue値のファイル内での位置を保持
選べるデータ保存方式
登録処理
・それぞれの特性
3.データ本体をファイルに保存
・仕組み
データ永続化の仕組みは「2.」と同じ
Key値のみメモリに保持し、Value値はファイルに保存
・特徴
データの永続化が可能
大量のデータを保存可能
データ操作時に常にファイルアクセスが頻発するため、
レスポンスに問題が出やすい
選べるデータ保存方式
検索ノード
分散Key-Value Storeという選択
アプリ RDBMS
検索ノード
更新ノード
okuyama
検索結果、参照回数の多いデータを配置してRDBの負荷を分散
更新回数の多い単純データを配置し、RDBの負荷を軽減
検索ノード
分散Key-Value Storeという選択
アプリ RDBMS
検索ノード
更新ノード
okuyama
システムのスループットが向上することによるさらなる負荷増加への対応は?
対応中のシステム停止は必要?
スケールアウトによる性能向上・マスターノード、データノード共に
システム停止無しでスケールアウト可能
・スケールアウト時のデータ移行などは
全て自動で行われる
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
ノード追加
データ移行
追加
スケールアウトによる性能向上・マスターノード、データノード共に
システム停止無しでスケールアウト可能
・スケールアウト時のデータ移行などは
全て自動で行われる
ミニマムスタートで後から性能向上も容易
検索ノード
分散Key-Value Storeという選択
アプリ RDBMS
検索ノード
更新ノード
okuyama
ノード数を増やせば故障率も増加
99.99%のサーバを1年運用すると、53分停止する
このサーバは10台並べると、単純合計530分停止
検索ノード
分散Key-Value Storeという選択
アプリ RDBMS
検索ノード
更新ノード
okuyama
okuyamaクラスタの障害発生時の対応は?
対応中のシステム停止は必要?
ノード数を増やせば故障率も増加
SPOFの存在しない構成・データの取得の流れ
メインマスターノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
メインデータノード
スレーブデータノード
SPOFの存在しない構成・データの取得の流れ
メインマスターノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
②データ保持ノード割り出し メイン
データノードスレーブデータノード
SPOFの存在しない構成・データの取得の流れ
メインマスターノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
メインデータノード
スレーブデータノード
③データ取得
②データ保持ノード割り出し
SPOFの存在しない構成・データノード障害発生
メインマスターノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
メインデータノード
スレーブデータノード
障害発生!!
②データ保持ノード割り出し
SPOFの存在しない構成・データノード障害発生
メインマスターノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
メインデータノード
スレーブデータノード
もう一つのノードから取得
②データ保持ノード割り出し
SPOFの存在しない構成・マスターノード障害発生
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
メインデータノード
スレーブデータノード
メインマスターノード
SPOFの存在しない構成・マスターノード障害発生
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
メインデータノード
スレーブデータノード
障害発生!!
メインマスターノード
SPOFの存在しない構成・マスターノード障害発生
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
クライアントスレーブ
マスターノード
①データ取得
メインデータノード
スレーブデータノード
別のマスターノードに再接続処理続行
メインマスターノード
SPOFの存在しない構成・自動データリカバリー機能
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインマスターノード
スレーブマスターノード
①各データノードを定期的に監視
SPOFの存在しない構成・自動データリカバリー機能
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインマスターノード
スレーブマスターノード
②障害発生を検知
メインマスターノード
スレーブマスターノード
①各データノードを定期的に監視
SPOFの存在しない構成・自動データリカバリー機能
③定期的に再起動していないか確認
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインマスターノード
スレーブマスターノード
②障害発生を検知
メインマスターノード
スレーブマスターノード
①各データノードを定期的に監視
SPOFの存在しない構成・自動データリカバリー機能
③定期的に再起動していないか確認
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインマスターノード
スレーブマスターノード
②障害発生を検知
再起動
④再起動を検知
※別筐体で起動しても問題ない
メインマスターノード
スレーブマスターノード
①各データノードを定期的に監視
SPOFの存在しない構成・自動データリカバリー機能
③定期的に再起動していないか確認
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインデータノード
スレーブデータノード
メインマスターノード
スレーブマスターノード
②障害発生を検知
⑤片側のノードからデータを復元
復元中もシステムは停止しない
メインマスターノード
スレーブマスターノード
①各データノードを定期的に監視
④再起動を検知
※別筐体で起動しても問題ない
検索ノード
分散Key-Value Storeという選択
アプリ RDBMS
検索ノード
更新ノード
okuyama故障を前提とした、配置を行い、自動復旧の強みを最大限に利用する。
メインデータノード
メインデータノード
メインデータノード
メインデータノード
メインマスターノードメインマスターノード
メインデータノード
メインデータノード
メインデータノード
メインデータノード
検索ノード
分散Key-Value Storeという選択
アプリ 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の値で決まる。
データのフィルタリングや、加工をデータノードの資源を使って実行可能
ご清聴ありがとうございました。