Secrets of Izna

1,135 views

Published on

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,135
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Secrets of Izna

  1. 1. IznaStor のひみつ 上野康平 @nyaxt
  2. 2. 自己紹介 <ul><li>未踏で3DCGレンダラを書いていました </li></ul>nytr
  3. 3. 分散レンダリング <ul><li>計算量多い </li></ul><ul><li>->  一台じゃやってられない -> 分散ジョブスケジューラとか RPC とか作る </li></ul><ul><li>データも多い -> テクスチャ一枚数 GB とか -> 中間データもデカイ    (photon map, irradiance cache, etc.) </li></ul>
  4. 4. Cagra <ul><li>大容量value可な分散KVS </li></ul><ul><ul><li>Consistent Hashingベースの1 hop DHT </li></ul></ul><ul><ul><li>レンダリングのテンポラリデータの格納とかに使いたかった </li></ul></ul>
  5. 5. IznaStor <ul><li>商用分散ファイルシステム </li></ul><ul><li>特徴: </li></ul><ul><ul><li>メタデータサーバなし </li></ul></ul><ul><ul><li>動的ノード追加削除 </li></ul></ul><ul><ul><li>Read早い </li></ul></ul>
  6. 6. 仕様 <ul><li>基本は Key + Value(w/metadata) Store </li></ul><ul><ul><li>数十ノードまでスケールさせることを前提 </li></ul></ul><ul><ul><li>FUSE で mount 可能 </li></ul></ul><ul><ul><li>directory, uid/gid, permission, etc. の保持が必要 </li></ul></ul><ul><ul><li>Value は 4KB~ 数 GB 想定 </li></ul></ul><ul><ul><li>Eventual consistency は導入しない </li></ul></ul><ul><ul><li>冗長性はレプリケーションで </li></ul></ul>
  7. 7. メタデータ <ul><li>{ key, valsize, dataholders, POSIXfs properties }の集合 </li></ul><ul><li>前提: </li></ul><ul><ul><li>ホップ数をなるべく減らす </li></ul></ul><ul><ul><li>Value が大きい -> KV pair 数は多くない </li></ul></ul><ul><li>実装:メタデータは全ノードが保持 </li></ul><ul><li>新期ノード -> 既存ノードからコピー </li></ul><ul><li>参照 -> ローカルの DB を参照 </li></ul><ul><li>追加削除 ->  two phase commit </li></ul>
  8. 8. Get <ul><li>キャッシュあるかチェック </li></ul><ul><li>ローカルのメタデータからデータ保持ノード選定 </li></ul><ul><li>リクエスト回送しキャッシュしつつvalue送信 </li></ul>Client Gateway DataHolder USER_GET_DATA GET_DATA storage cache
  9. 9. Put <ul><li>適切なノードを選びデータ保存 </li></ul><ul><li>Two phase commitでメタデータ更新 </li></ul>Client Gateway DataHolder USER_PUT_DATA PUT_DATA storage All Nodes All Nodes All Nodes MetaDB 2PC
  10. 10. 今後 <ul><li>メタデータ更新2PC止めたい </li></ul><ul><ul><li>「分散」メタデータデータベース </li></ul></ul><ul><ul><li>MVCC? </li></ul></ul><ul><li>もっとスケールさせよう </li></ul><ul><ul><li>ネットワークの階層化, etc. </li></ul></ul>
  11. 11. アルゴリズムの話おわり
  12. 12. IznaStor をどう実装したか <ul><li>商用化にあたりフルスクラッチ </li></ul><ul><ul><li>C++ 20万行ぐらい? </li></ul></ul><ul><ul><li>AS3でビジュアライザ </li></ul></ul><ul><ul><li>ruby/bash/common lisp他によるスクリプト類 </li></ul></ul>
  13. 13. Cagra商用化にあたっての壁 <ul><li>よーし商用化でいっぱい機能追加しちゃうぞ! </li></ul><ul><li>と思ったものの… </li></ul><ul><li>Cagra コードの問題点: </li></ul><ul><li>マルチ CPU 活かせない </li></ul><ul><li>使いにくい RPC </li></ul><ul><li>デバッグしづらい </li></ul>
  14. 14. 壁1: マルチCPU活かせない <ul><li>Cagra の I/O 戦略 </li></ul><ul><ul><li>シングルスレッド+コルーチン </li></ul></ul><ul><ul><li>C++ でコルーチンを無理やり実装 </li></ul></ul><ul><ul><li>I/O 待ちで別コルーチンに yield </li></ul></ul><ul><li>問題点: </li></ul><ul><ul><li>1 CPU しか使えない </li></ul></ul><ul><ul><li>aio 対応がむずかしい </li></ul></ul>
  15. 15. 壁2: 使いにくいRPC <ul><li>C++ テンプレートで実装 </li></ul><ul><ul><li>だれもこんなの読めません </li></ul></ul><ul><li>冗長な RPC 記述 </li></ul><ul><ul><li>{メッセージ ID 、メッセージ構造体定義  成功時の処理、失敗時の処理} </li></ul></ul><ul><ul><li>以上をばらばらに記述 </li></ul></ul><ul><li>問題点: </li></ul><ul><li>保守性最悪 </li></ul><ul><ul><li>1 メッセージ定義を追加するのに 1 時間仕事 </li></ul></ul><ul><li>非透過的 </li></ul><ul><ul><li>通常の関数コールに比べて「かなり」記述が重い </li></ul></ul><ul><ul><li>通信部 / ロジックがほぼ一体 </li></ul></ul><ul><ul><ul><li>TCP/IP を常に意識する必要あり </li></ul></ul></ul>
  16. 16. 壁3: デバッグしづらい <ul><li>並行 msg では新規コルーチンを生成する </li></ul><ul><ul><li>Ex. トポロジー変化 broadcast / トランザクション etc. </li></ul></ul><ul><ul><li>エラー発生時どういう経路でたどり着いたのかわからなくなる </li></ul></ul><ul><li>コルーチンは userlevel thread </li></ul><ul><ul><li>Gdb から追えない (プラグインか何か書かないとだめ) </li></ul></ul><ul><li>ノードをまたぐとトレースできない </li></ul><ul><ul><li>ProxyGet -> Find -> GetVal </li></ul></ul>ERR!
  17. 17. Izna アーキテクチャ <ul><li>マルチCPU活かせない </li></ul><ul><li>使いにくいRPC </li></ul><ul><li>デバッグしづらい </li></ul><ul><li>->以上の問題を解決したアーキテクチャを設計 </li></ul>
  18. 18. Izna のアーキテクチャ <ul><li>複数のステージとステージ間キュー (ISE: InterStageQueue) で構成 </li></ul>Inlet Outlet Logic Storage
  19. 19. Izna のアーキテクチャ <ul><li>複数のステージとステージ間キュー (ISE: InterStageQueue) で構成 </li></ul>Inlet Outlet Logic Storage ステージ
  20. 20. Izna のアーキテクチャ <ul><li>複数のステージとステージ間キュー (ISQ: InterStageQueue) で構成 </li></ul>Inlet Outlet Logic Storage ISQ ISQ ISQ
  21. 21. Izna のアーキテクチャ <ul><li>複数のステージとステージ間キュー (ISQ: InterStageQueue) で構成 </li></ul>Inlet Outlet Logic Storage TCP Protocol parser
  22. 22. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Izna Inlet: {srcaddr, socket} Inlet: {srcaddr, socket} Logic: GET {key} struct Izna { GUID, Vector<{StageID, MsgType, *args}> } をパイプライン的に処理するアーキテクチャ
  23. 23. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key}
  24. 24. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler
  25. 25. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file}
  26. 26. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file}
  27. 27. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file} GETFILE handler
  28. 28. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file} GETFILE handler RESULT: {filehandle}
  29. 29. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file} GETFILE handler RESULT: {filehandle}
  30. 30. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file} GETFILE handler RESULT: {filehandle}
  31. 31. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file} GETFILE handler RESULT: {filehandle} RESULT: {filehandle} Outlet: {dstaddr}
  32. 32. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file} GETFILE handler RESULT: {filehandle} RESULT: {filehandle} Outlet: {dstaddr}
  33. 33. Izna のアーキテクチャ Inlet Outlet Logic Storage TCP Protocol parser Inlet: {srcaddr, socket} Logic: GET {key} GET handler Storage: GETFILE {file} GETFILE handler RESULT: {filehandle} RESULT: {filehandle} Protocol serializer Outlet: {dstaddr} TCP リモート参照可能な GUID
  34. 34. Izna を使った Get Client Gateway DataHolder USER_GET_DATA GET_DATA storage cache USER_GET_DATA{key}
  35. 35. Izna を使った Get Client Gateway DataHolder USER_GET_DATA GET_DATA storage cache USER_GET_DATA{key} GET_DATA{key}
  36. 36. Izna を使った Get Client Gateway DataHolder USER_GET_DATA GET_DATA storage cache USER_GET_DATA{key} GET_DATA{key} REPLY{val}
  37. 37. Izna を使った Get Client Gateway DataHolder USER_GET_DATA GET_DATA storage cache USER_GET_DATA{key} GET_DATA{key} REPLY{val} REPLY{val}
  38. 38. Izna を使った Get Client Gateway DataHolder USER_GET_DATA GET_DATA storage cache USER_GET_DATA{key} GET_DATA{key} REPLY{val} REPLY{val}
  39. 39. なにが嬉しいのか <ul><li>マルチCPU活かせない  </li></ul><ul><li>使いにくいRPC </li></ul><ul><li>デバッグしづらい </li></ul>
  40. 40. なにが嬉しいのか <ul><li>マルチCPU活かせない </li></ul><ul><li>  ->ステージごと別スレッド  </li></ul><ul><li>使いにくいRPC </li></ul><ul><li>  </li></ul><ul><li>デバッグしづらい </li></ul>
  41. 41. なにが嬉しいのか <ul><li>マルチCPU活かせない </li></ul><ul><li>  ->ステージごと別スレッド  </li></ul><ul><li>使いにくいRPC </li></ul><ul><li>  ->透過的なRPC </li></ul><ul><li>   通信コードとロジックの分離 </li></ul><ul><li>デバッグしづらい </li></ul>
  42. 42. なにが嬉しいのか <ul><li>マルチCPU活かせない </li></ul><ul><li>  ->ステージごと別スレッド  </li></ul><ul><li>使いにくいRPC </li></ul><ul><li>  ->透過的なRPC </li></ul><ul><li>   通信コードとロジックの分離 </li></ul><ul><li>デバッグしづらい </li></ul><ul><li>  ->ノード越しトレース! </li></ul>
  43. 43. 懸念 <ul><li>キュー通すと遅くね? </li></ul><ul><ul><li>ローカルだと 1000kqps 余裕 </li></ul></ul><ul><ul><li>I/O のがよっぽど遅い(がんばっても 100kqps) </li></ul></ul><ul><li>コード書くの大変じゃね? </li></ul><ul><ul><li>aburage: 専用言語あります </li></ul></ul><ul><ul><li>メッセージフロー+ロジック記述 </li></ul></ul><ul><ul><li> ->  C++ コードにコンパイル </li></ul></ul><ul><ul><li>IDL の一種とも言える </li></ul></ul>
  44. 44. Related Work <ul><li>SEDA : An Architecture for Highly Concurrent Server Applications </li></ul><ul><ul><li>Matt Welsh , Harvard University </li></ul></ul><ul><li>何を渡すのかは Event としてしか書かれていない </li></ul><ul><li>Izna の Stage とは違い単機能 </li></ul>
  45. 45. さいごに
  46. 46. 大規模分散用プラットフォーム
  47. 47. IznaStor で学んだこと <ul><li>メッセージフローだけでアプリケーションは 記述できる! </li></ul>
  48. 48. IznaStor で学んだこと <ul><li>メッセージフローだけでアプリケーションは 記述できる! </li></ul><ul><li>もうアプリケーション全部そう書いたら いいんじゃね </li></ul>
  49. 49. Izna =コールスタック? <ul><li>Izna とは何か </li></ul><ul><ul><li>メッセージ履歴の単方向リスト </li></ul></ul><ul><li>これはコールスタックそのものではないか </li></ul>
  50. 50. ステートレス <ul><li>Izna はステートを全部載せた RPC </li></ul><ul><li>何ノード通っても良い、落ちてもテキトーな別のノードに頼めば良い </li></ul>
  51. 51. Izna 上でのプログラム実行 <ul><li>スタック ->  Izna </li></ul><ul><li>ヒープ -> ??? </li></ul>
  52. 52. Izna 上でのプログラム実行 <ul><li>スタック ->  Izna </li></ul><ul><li>ヒープ ->  KVS </li></ul>
  53. 53. Related Work <ul><li>Erlang / BEAM </li></ul><ul><ul><li>超軽量プロセスを売りにした言語 / 処理系 </li></ul></ul><ul><ul><li>プロセスは物理マシンを飛び越えて通信可能 </li></ul></ul><ul><ul><li>Izna との違い: </li></ul></ul><ul><ul><ul><li>履歴を持たない </li></ul></ul></ul><ul><ul><ul><li>Erlang プロセスは状態を持つことができ、メッセージのみで完結はしない(副作用発生可) </li></ul></ul></ul><ul><ul><ul><li> -> Izna のようにシステムレベルでフェイルオーバー機構を </li></ul></ul></ul><ul><ul><ul><li>  備えていない </li></ul></ul></ul>

×