Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PyVortex

1,729 views

Published on

PyCon JP 2012 での発表スライドです。
PythonのTornadoを使って分散KVSのフレームワークとして仕上げてみました。

  • Be the first to comment

  • Be the first to like this

PyVortex

  1. 1. PyCon20 12Tornado で分散 KVS フレームワーク 【ダウンロード URL 】 https://github.com/kishim otosc/vortex
  2. 2. 誰?■ 株式会社エスキュービズム    岸本 康二■ 大学の研究室時代に Python1 系に出会う■WEB サービスの構築案件から  大規模系の技術開発、  センサーデータの取得・解析など  普段から Python を使っています。
  3. 3. 本日のメニューTornado の分散 KVS  フレームワーク風 Vortex   
  4. 4. 結果から ノード 1 台辺り約 1,000 write/sec複数台なら基本的に掛け算
  5. 5. 開発経緯Apache Cassandra を使用した案件 約 3,500 write/sec (分間 20 万書き込み)
  6. 6. 開発経緯■ クラウド環境の抱える問題  ・大規模 HD 障害  ・大規模電源障害→ 単一系統 /DC 構成は厳しい
  7. 7. 開発経緯■Cassandra を使ってみて    ※それでも Cassandra 自体は素晴らしいです  ・動作と構造が複雑で見えにくい  ・ Thrift(RPC) は美しいが面倒  ・タイムスタンプの扱いに難あり  ・各ノード上で計算できない  ・ LB 等を通せない
  8. 8. 設計方針■Vortex で目指したもの  ・分散 KVS フレームワークの構築  ・ HTTP ベースの IF  ・シンプルな設計(容易な変更)  ・操作関数の導入  ・マルチ DC を想定( LB 経由可能)  ・バージョンによる一貫性管理  ・エラーの検知
  9. 9. 分散 KVS フレームワーク Python 製 WEB フレームワークNon-Blocking でマルチコアを活かしやすい シンプルかつ速い! → 分散 KVS ロジックを Tornado で実装
  10. 10. HTTP ベースの IF ベースが Tornado という WEB フレームワーク ↓HTTP ( S )で簡単に通信できる また、データは JSON 形式 → ブラウザ上の JavaScript から  分散 KVS を操作できたり・・・
  11. 11. シンプルな設計 基本的に データ受信 / 転送 書き込み / 読み込み の 2 系統に収めた ↓主要ロジック部分は 300 行程度
  12. 12. 操作関数の導入 × データを送って書き込む ↓○ パラメータを送って関数を実行し、 その結果を書き込む (ストアドプロシージャ的な) ↓
  13. 13. 操作関数の導入 ↓現在書き込まれている値とパラメータを使って 書き込む値を決定できる。 ↓ データの読み出しが減り、高速化可能。 パラメータとして関数表現を送り、 動的に実行させることも 簡単なカスタマイズで可能
  14. 14. マルチ DC を想定 ノードに直接転送せずに LB 等の後ろにいることを想定 ↓ HTTP(S) での接続なので、 LB によるラウンドロビンやポート変換、 SSL アクセラレータ、振り分けなどの 恩恵をそのまま受けられる。 ↓マルチ DC でのレプリケーションを簡単に安く!
  15. 15. バージョンによる一貫性管理 ×Cassandra では異なるデータでも 同じバージョン指定だと何度でも 上書きができてしまう。 ↓ ○ あるバージョンで一度書き込むとそれより大きなバージョン指定でないと 上書きできない。 ↓
  16. 16. バージョンによる一貫性管理 ↓ データのロックや CAS 操作などの 機能開発に向いている ↓ 従来、分散 KVS が苦手とされた 強い一貫性の維持に使えるCAP 定理で言えば、 A と P を選択しつつ、C はバージョンを意識することで克服する形
  17. 17. エラーの検知 データ一貫性のある操作ができたかどうか +どの DC のどのノードに書き込めなかったのか 戻り値として返してくる。 ↓ 瞬間的なノードの性能低下なのか、 DC 内での障害なのかは DB を利用する側が「外部」から判断して個別処理するポリシー例) DC 間の分断ではお互いを障害中と「勝手に」判断してしまう
  18. 18. データの流れ 自分?転送? Node1 ラウンドロビン 転送LB Node2 書き込み
  19. 19. 分散保存
  20. 20. まとめ ①サーバやレプリケーション方法に依るが   毎秒約 1,000 書き込み / 読み込み   が 1 ノード当たりで捌ける目安 ノードを増やせばさらに性能も向上主にファイルシステムとネットワークが 速度を決める重要な部分
  21. 21. まとめ ②マルチ DC なので、 fsync を外せる (?)→ 高速化 また、 DC1 つが丸ごと障害でも 書き込みも含めてサービス継続が可能 (もちろん、シングル DC でも動作します)
  22. 22. まとめ ③ 何より作りがシンプルなので簡単にオリジナル分散 KVS を作れます! 独自アルゴリズムや 新しい一貫性確保の仕組み、 データストアと解析の同時実装などちょっとしたアイディアをすぐに試せます。
  23. 23. まとめ github に公開しています ↓https://github.com/kishimotosc/vortex 優秀な Pythonista を求めています! ぜひ一度お声がけください。

×