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

1,530
-1

Published on

キーバリューストアをこれから利用したい、利用したいけどもどのように
システムに組み込めばよいか悩んでいる。
こういった疑問に対して当日は、分散キーバリューストア「okuyama」の開発者が
キーバリューストアとは?からシステム組み込み時のモデルまで、okuyamaの
ご紹介を交えてご説明させていただきます。

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,530
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. 分散キーバリューストア okuyamaのご紹介と 利用時の設計モデルについて 株式会社 神戸デジタル・ラボ 岩瀬 高博 Mail: iwase@kdl.co.jp Twitter: @okuyamaoo http://d.hatena.ne.jp/okuyamaoo/
  2. 2. 自己紹介 ・株式会社 神戸デジタル・ラボ >神戸を基盤にICTソリューションを展開 ・岩瀬 高博 > Twitter: @okuyamaoo >活動 >kvs-ja (Googleユーザグループ) >OSS分散キーバリューストア okuyama を作成 http://sourceforge.jp/projects/okuyama/
  3. 3. アジェンダ 1.分散Key-Value Store? 2.システムに組み込む場合は? ~そしてokuyamaでは~
  4. 4. 分散Key-Value Storeって? 分散Key-Value Storeとは?
  5. 5. 分散Key-Value Storeって? 分散Key-Value Storeとは? >その前にまずKey-Value Storeから
  6. 6. Key-Value Storeって? 分散Key-Value Storeとは? >その前にまずKey-Value Storeから >KeyとValueの関係で値を保持できる仕組み
  7. 7. Key-Value Storeって? 分散Key-Value Storeとは? >その前にまずKey-Value Storeから >KeyとValueの関係で値を保持できる仕組み “Key-1”のValueを取得 Key-1 Value-1 “Value-1”が取得できる Key-1 Value-1 Key-2 Value-2 Key-3 Value-3
  8. 8. Key-Value Storeって? 分散Key-Value Storeとは? >その前にまずKey-Value Storeから >KeyとValueの関係で値を保持できる仕組み Key-1 Value-1 Key-2 Value-2 “Key-4”,“Value-4”を登録 Key-3 Value-3 Key-4 Value-4 Key-4 Value-4
  9. 9. Key-Value Storeって? 分散Key-Value Storeとは? >その前にまずKey-Value Storeから >KeyとValueの関係で値を保持できる仕組み >特徴 ・シンプルなデータモデル ・シンプルな操作方法 ・最小単位での一貫性
  10. 10. Key-Value Storeって? 分散Key-Value Storeとは? >その前にまずKey-Value Storeから >KeyとValueの関係で値を保持できる仕組み >特徴 ・シンプルなデータモデル ・シンプルな操作方法 ・最小単位での一貫性
  11. 11. 最小単位での一貫性? 1つのデータの更新が混在しないことのみ保障 >どんな利点が?
  12. 12. 最小単位での一貫性? 1つのデータの更新が混在しないことのみ保障 >どんな利点が? >データの整合性確保の範囲を限定できる “Key-1”を“Value-11”へ更新 2つのデータは 個々で更新される Key-1 Value-11 Key-1 Value-11 関係性を持たない Key-2 Value-2 “Key-4”を“Value-44”へ更新 Key-3 Value-3 Key-4 Value-44 Key-4 Value-44
  13. 13. 最小単位での一貫性? データの整合性確保の範囲を限定できる >ということは?
  14. 14. 最小単位での一貫性? データの整合性確保の範囲を限定できる >ということは? >分散して管理することが可能 “Key-1”を“Value-11”へ更新 Key-1 Value-11 Key-1 Value-11 Key-2 Value-22 “Key-4”を“Value-44”へ更新 Key-3 Value-3 Key-4 Value-44 Key-4 Value-44
  15. 15. 最小単位での一貫性? データの整合性確保の範囲を限定できる >ということは? >分散して管理することが可能 “Key-1”を“Value-11”へ更新 Key-1 Value-11 Key-1 Value-11 Key-2 Value-22 分散 Key-Value Store “Key-4”を“Value-44”へ更新 Key-3 Value-3 Key-4 Value-44 Key-4 Value-44
  16. 16. 分散Key-Value Storeの配置 システム稼働当初 利用者 アプリ データベース RDBMS
  17. 17. 分散Key-Value Storeの配置 利用者の増加 利用者 アプリ データベース RDBMS
  18. 18. 分散Key-Value Storeの配置 アプリケーションサーバを増設 利用者 アプリ データベース RDBMS
  19. 19. 分散Key-Value Storeの配置 データベースがボトルネックに 利用者 アプリ データベース RDBMS ボトルネック
  20. 20. システム構成 対応策 利用者 アプリ データベース ・スケールアップで対応 ・更新系と検索系を分割 検索ノード 更新ノード 検索ノード
  21. 21. システム構成 対応策 利用者 アプリ データベース ・スケールアップで対応 ・更新系と検索系を分割 検索ノード 更新ノード 検索ノード ・スケールアップの限界 ・更新系はボトルネック ・管理の煩雑化
  22. 22. 他の対応策は? 全てのデータを高度なデータモデルを 有するRDBMSに格納する必要はある? 利用状況に合わせて柔軟に対応できる モデルが今後は必要
  23. 23. 分散キーバリューストア 全てのデータを高度なデータモデルを 有するRDBMSに格納する必要はある? >キーとバリューの関係で成り立つデータ >複雑なトラントランザクションを必要としない 利用状況に合わせて柔軟に対応できる モデルが今後は必要 >スケールアウトによる性能向上 >高い対障害性
  24. 24. 分散Key-Value Storeという選択 アプリ 分散KVS RDBMS 検索ノード okuyama? 更新ノード 検索ノード
  25. 25. Javaで実装された分散KVS ・全体構成 メイン スレーブ データノード データノード スレーブ メイン スレーブ クライアント データノード データノード マスターノード クライアント メイン メイン スレーブ マスターノード データノード データノード クライアント メイン スレーブ データノード データノード ・クライアント → マスターノード → データノード
  26. 26. Javaで実装された分散KVS ・クライアント クライアント okuyamaへの問い合わせを実現 クライアント ・専用クライアントはJavaと、PHPが実装済み クライアント
  27. 27. Javaで実装された分散KVS ・マスターノード ・クライアントからのI/F ・データノード管理 ・サポートプロトコル >データ入出力 >オリジナル データ保存場所の決定は スレーブ >Memcached マスターノード 2つのアルゴリズムから選択 >HTTP 1. Mod メイン マスターノード 2. ConsistentHash >生存監視 起動時のデータリカバリ ・制限台数なしに冗長化可能
  28. 28. Javaで実装された分散KVS ・データノード ・データの保存を実現 メイン スレーブ スレーブ ・データ保存方式を選択可能 データノード データノード データノード ・最大3ノードにデータを保存 メイン スレーブ スレーブ ・アクセスバランシング データノード データノード データノード ・連鎖的ダウンの予防 メイン スレーブ スレーブ データノード データノード データノード メイン スレーブ スレーブ データノード データノード データノード
  29. 29. Javaで実装された分散KVS ・複数データノードでのデータ一貫性 メイン スレーブ サード データノード データノード データノード 1.弱一貫性 2.中一貫性 3.強一貫性
  30. 30. Javaで実装された分散KVS ・複数データノードでのデータ一貫性 メイン スレーブ サード データノード データノード データノード 1.弱一貫性 >メイン、スレーブ両データノードにランダムにアクセス 2.中一貫性 >常に最後に保存したデータノードからアクセス 3.強一貫性 >データノードの値を検証
  31. 31. 分散Key-Value Storeという選択 アプリ okuyama RDBMS 検索結果、参照回数の 多いデータを配置して RDBMSの負荷を分散 検索ノード 更新ノード 検索ノード
  32. 32. 分散Key-Value Storeという選択 アプリ okuyama RDBMS 検索結果、参照回数の 多いデータを配置して RDBMSの負荷を分散 検索ノード 更新ノード 検索ノード 更新処理の負荷は軽減 できない? 永続化層としての活用は できない?
  33. 33. 選べるデータ保存方式 ・データノードへの保存方式を選択可能 メイン 1.全てのデータをメモリに保存 データノード 2.データ操作履歴のみファイルに保存 3.データ本体をファイルに保存
  34. 34. 選べるデータ保存方式 ・データノードへの保存方式を選択可能 メイン 1.全てのデータをメモリに保存 データノード >非永続型 2.データ操作履歴のみファイルに保存 >永続型 3.データ本体をファイルに保存 >永続型
  35. 35. 選べるデータ保存方式 ・それぞれの特性 1.全てのデータをメモリに保存 ・仕組み Key値、Value値の両方をメモリ上で管理 ・特徴 最も高速に動く ノード停止でデータも消滅 保存出来るデータ量はメモリ量に依存
  36. 36. 選べるデータ保存方式 ・それぞれの特性 2.データ操作履歴のみファイルに保存 ・仕組み データへの操作を全てファイルに時系列に記録
  37. 37. 選べるデータ保存方式 ・データへの操作を全てファイルに時系列に記録 登録処理 Key5 = Value5 データノード [履歴記録ファイル] 登録,Key1,Value1 登録,Key2,Value2 登録,Key3,Value3 登録,Key4,Value4 登録,Key5,Value5 最後尾に追記
  38. 38. 選べるデータ保存方式 ・データへの操作を全てファイルに時系列に記録 登録処理 Key5 = Value5 データノード [履歴記録ファイル] 登録,Key1,Value1 登録,Key2,Value2 登録,Key3,Value3 登録,Key4,Value4 登録,Key5,Value5 最後尾に追記 [データノードのメモリ] Key5 = Value5 データノードのメモリに反映
  39. 39. 選べるデータ保存方式 ・データへの操作を全てファイルに時系列に記録 削除処理 Key5 データノード [履歴記録ファイル] 登録,Key2,Value2 登録,Key3,Value3 登録,Key4,Value4 登録,Key5,Value5 削除,Key5,Value5 最後尾に追記 [データノードのメモリ] Key5 データノードのメモリに反映
  40. 40. 選べるデータ保存方式 ・それぞれの特性 1.データ操作履歴のみファイルに保存 ・仕組み データへの操作を全てファイルに時系列に記録 記録ファイルからデータを復元
  41. 41. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み 登録,Key1,Value1 登録,Key2,Value2 登録,Key3,Value3 登録,Key4,Value4 登録,Key5,Value5 削除,Key5,Value5 [履歴記録ファイル]
  42. 42. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み ②メモリに反映 登録,Key1,Value1 Key1 = Value1 登録,Key2,Value2 登録,Key3,Value3 登録,Key4,Value4 登録,Key5,Value5 削除,Key5,Value5 [データノードのメモリ] [履歴記録ファイル]
  43. 43. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み ②メモリに反映 登録,Key1,Value1 Key1 = Value1 登録,Key2,Value2 Key2 = Value2 登録,Key3,Value3 登録,Key4,Value4 登録,Key5,Value5 削除,Key5,Value5 [データノードのメモリ] [履歴記録ファイル]
  44. 44. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み ②メモリに反映 登録,Key1,Value1 Key1 = Value1 登録,Key2,Value2 Key2 = Value2 登録,Key3,Value3 Key3 = Value3 登録,Key4,Value4 登録,Key5,Value5 削除,Key5,Value5 [データノードのメモリ] [履歴記録ファイル]
  45. 45. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み ②メモリに反映 登録,Key1,Value1 Key1 = Value1 登録,Key2,Value2 Key2 = Value2 登録,Key3,Value3 Key3 = Value3 登録,Key4,Value4 Key4 = Value4 登録,Key5,Value5 削除,Key5,Value5 [データノードのメモリ] [履歴記録ファイル]
  46. 46. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み ②メモリに反映 登録,Key1,Value1 Key1 = Value1 登録,Key2,Value2 Key2 = Value2 登録,Key3,Value3 Key3 = Value3 登録,Key4,Value4 Key4 = Value4 登録,Key5,Value5 Key5 = Value5 削除,Key5,Value5 [データノードのメモリ] [履歴記録ファイル]
  47. 47. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み ②メモリに反映 登録,Key1,Value1 Key1 = Value1 登録,Key2,Value2 Key2 = Value2 登録,Key3,Value3 Key3 = Value3 登録,Key4,Value4 Key4 = Value4 登録,Key5,Value5 Key5 = Value5 削除,Key5,Value5 [データノードのメモリ] [履歴記録ファイル]
  48. 48. 選べるデータ保存方式 ・記録ファイルからデータを復元 データノード ①記録ファイルから順次操作を読み込み ②メモリに反映 登録,Key1,Value1 Key1 = Value1 登録,Key2,Value2 Key2 = Value2 登録,Key3,Value3 Key3 = Value3 登録,Key4,Value4 Key4 = Value4 登録,Key5,Value5 削除,Key5,Value5 [データノードのメモリ] [履歴記録ファイル] 復元完了!!
  49. 49. 選べるデータ保存方式 ・それぞれの特性 2.データ操作履歴のみファイルに保存 ・仕組み データへの操作を全てファイルに時系列に記録 記録ファイルからデータを復元 ・特徴 データの永続化が可能で且つ、起動後は高速に動く 保存出来るデータ量はメモリに依存
  50. 50. 選べるデータ保存方式 ・それぞれの特性 3.データ本体をファイルに保存 ・仕組み データ永続化の仕組みは「2.」と同じ Key値のみメモリに保持し、Value値はファイルに保存
  51. 51. 選べるデータ保存方式 ・Key値とデータの場所をメモリに保持 登録処理 「2.」の仕組みを利用 Key5 = Value5 データノード [データノードのメモリ] Key5 = 5行目 [データファイル] Value1 Value2 データファイルにValue値を保存 Value3 メモリにKey値とValue値のファイル内での Value4 Value5 位置を保持
  52. 52. 選べるデータ保存方式 ・それぞれの特性 3.データ本体をファイルに保存 ・仕組み データ永続化の仕組みは「2.」と同じ Key値のみメモリに保持し、Value値はファイルに保存 ・特徴 データの永続化が可能 大量のデータを保存可能 データ操作時に常にファイルアクセスが頻発するため、 レスポンスに問題が出やすい
  53. 53. 分散Key-Value Storeという選択 アプリ okuyama RDBMS 検索結果、参照回数の 多いデータを配置して RDBの負荷を分散 検索ノード 更新ノード 更新回数の多い単純 検索ノード データを配置し、RDBの 負荷を軽減
  54. 54. 分散Key-Value Storeという選択 アプリ okuyama RDBMS システムの スループットが向上 検索ノード することによるさらな る負荷増加への 更新ノード 対応は? 検索ノード 対応中のシステム 停止は必要?
  55. 55. スケールアウトによる性能向上 ・マスターノード、データノード共に システム停止無しでスケールアウト可能 ・スケールアウト時のデータ移行などは 全て自動で行われる メイン データノード スレーブ データノード データ移行 メイン スレーブ データノード データノード メイン スレーブ ノード追加 データノード データノード 追加 メイン スレーブ メイン スレーブ データノード データノード データノード データノード メイン スレーブ データノード データノード
  56. 56. スケールアウトによる性能向上 ・マスターノード、データノード共に システム停止無しでスケールアウト可能 ・スケールアウト時のデータ移行などは 全て自動で行われる ミニマムスタートで後から性能向上も容易
  57. 57. 分散Key-Value Storeという選択 アプリ okuyama RDBMS ノード数を増やせば 故障率も増加 99.99%のサーバを1年運 用すると、53分停止する 検索ノード このサーバは10台並べる 更新ノード と、単純合計530分停止 検索ノード
  58. 58. 分散Key-Value Storeという選択 アプリ okuyama RDBMS ノード数を増やせば 故障率も増加 okuyamaクラスタの 検索ノード 障害発生時の対応 は? 更新ノード 対応中のシステム 検索ノード 停止は必要?
  59. 59. SPOFの存在しない構成 ・データの取得の流れ メイン スレーブ データノード データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ データノード データノード
  60. 60. SPOFの存在しない構成 ・データの取得の流れ ②データ保持 ノード割り出し メイン スレーブ データノード データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ データノード データノード
  61. 61. SPOFの存在しない構成 ・データの取得の流れ ③データ取得 ②データ保持 ノード割り出し メイン スレーブ データノード データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ データノード データノード
  62. 62. SPOFの存在しない構成 ・データノード障害発生 障害発生!! ②データ保持 ノード割り出し メイン スレーブ データノード データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ データノード データノード
  63. 63. SPOFの存在しない構成 ・データノード障害発生 もう一つのノードから取得 ②データ保持 ノード割り出し メイン スレーブ データノード データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ データノード データノード
  64. 64. SPOFの存在しない構成 ・マスターノード障害発生 メイン スレーブ データノード データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ データノード データノード
  65. 65. SPOFの存在しない構成 ・マスターノード障害発生 障害発生!! メイン データノード スレーブ データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ データノード データノード
  66. 66. SPOFの存在しない構成 ・マスターノード障害発生 メイン スレーブ データノード データノード ①データ取得 メイン スレーブ スレーブ クライアント データノード データノード マスターノード メイン メイン スレーブ マスターノード 別のマスター データノード データノード ノードに再接続 メイン スレーブ 処理続行 データノード データノード
  67. 67. SPOFの存在しない構成 ・自動データリカバリー機能 メイン スレーブ データノード データノード スレーブ メイン スレーブ マスターノード データノード データノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ ①各データノードを データノード データノード 定期的に監視
  68. 68. SPOFの存在しない構成 ・自動データリカバリー機能 ②障害発生を検知 メイン スレーブ データノード データノード スレーブ メイン スレーブ マスターノード データノード データノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ ①各データノードを データノード データノード 定期的に監視
  69. 69. SPOFの存在しない構成 ・自動データリカバリー機能 ②障害発生を検知 ③定期的に再起動していないか確認 メイン スレーブ データノード データノード スレーブ メイン スレーブ マスターノード データノード データノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ ①各データノードを データノード データノード 定期的に監視
  70. 70. SPOFの存在しない構成 ・自動データリカバリー機能 ②障害発生を検知 ③定期的に再起動していないか確認 再 ④再起動を検知 起 メイン 動 スレーブ ※別筐体で起動しても データノード データノード 問題ない スレーブ メイン スレーブ マスターノード データノード データノード メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ ①各データノードを データノード データノード 定期的に監視
  71. 71. SPOFの存在しない構成 ・自動データリカバリー機能 ②障害発生を検知 ③定期的に再起動していないか確認 ④再起動を検知 メイン スレーブ ※別筐体で起動しても データノード データノード 問題ない ⑤片側のノードから スレーブ メイン スレーブ データを復元 マスターノード データノード データノード 復元中もシステムは 停止しない メイン メイン スレーブ マスターノード データノード データノード メイン スレーブ ①各データノードを データノード データノード 定期的に監視
  72. 72. 分散Key-Value Storeという選択 アプリ okuyama RDBMS 故障を前提とした、 配置を行い、 自動復旧の強みを 最大限に利用する。 検索ノード メイン メイン メイン データノード データノード メイン 更新ノード データノード データノード メイン 検索ノード メイン マスターノード マスターノード メイン メイン メイン データノード データノード メイン データノード データノード
  73. 73. 分散Key-Value Storeという選択 アプリ okuyama RDBMS ノード数増加時の 管理コストは? 検索ノード メイン メイン メイン データノード データノード メイン 更新ノード データノード データノード メイン 検索ノード メイン マスターノード マスターノード メイン メイン メイン データノード データノード メイン データノード データノード
  74. 74. 一括管理機能 ・設定変更、現状確認 ・データノード状態確認
  75. 75. 一括管理機能 ・設定変更、現状確認 ・データノード状態確認 1ノードづつ管理するのは大変
  76. 76. 一括管理機能 ・設定変更、現状確認 ・データノード状態確認 1ノードづつ管理するのは大変 一括管理可能なWebコンソール
  77. 77. 一括管理機能
  78. 78. okuyamaならではの機能 ・Key-Valueの関係だけじゃない ・データロックでデータ整合性処理も ・JavaScriptで簡単フィルタリング
  79. 79. 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を まとめて取得できる データのグルーピングが可能
  80. 80. okuyamaならではの機能 ・データロック機構 >全データノードをまたいでロック可能 Lock実施 lockData (Key=“okuyama”, Lock維持時間=10, Lockリトライ時間=5); ※別クライアントから set (Key=“okuyama”, Value=“Ver1.0.0“); >Lockを実施したクライアントがLock解除するか、 Lock維持時間が経過するまで待たされる データ整合性を意識した処理が可能
  81. 81. okuyamaならではの機能 ・データノードでJavaScriptを実行 >任意のJavaScriptを取得データに実行可能 取得したいデータのKey値と、同時に実行したいJavaScriptを指定 getValueScript (Key=“okuyama”, Script=“var dataValue; var retValue = dataValue.replace(‟KVS„, ‟キーバリューストア‟); var execRet = '1'; ”); >取得結果 {“分散キーバリューストア”} 実行するJavaScriptのdataValueという変数にKey値から取得された 値が代入されて実行される。クライアントは変数retValueの値が返され 返却するかどうかは、変数execRetの値で決まる。 データのフィルタリングや、加工を データノードの資源を使って実行可能
  82. 82. 最後に ・okuyamaユーザグループ作成しました URL : http://groups.google.co.jp/group/kvs_okuyama MAIL: kvs_okuyama@googlegroup.com
  83. 83. ご清聴ありがとうございました。
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×