StreamCloud の System S 上での実現方法を石井君と議論を行ったので、そのメモを記す。現行の System S では、ホストの動的な削除は可能だが、ホストの動的な追加はできない（正確には、インスタンスへのホストの追加は streamtool addhost コマンドで可能だが、新たなホストには PE が割り当てられない）。この制限はクラウド環境を用いて、データが低レートの時は System S が稼動する VM をsuspend し, bursty な状況においては その VM をresume するようなシステムを構築する際に問題となる。
この問題を（比較的きれいに）解決するため、以下の図のように System S/SPADE の import/export 機能を用いた疎結合なアーキテクチャ構成を考える。
要はモノシリックな SPADE アプリケーションにしてしまうと、現行の System S の機能では新たに追加されたホストへのデータ供給が難しい。しかし、import/export を用いれば、データを受信しスケジューリングするコンポーネントと、計算側のコンポーネントを分離でき、必要なときにクラウド側の計算用 SPADE ジョブを立ち上げ、import 機能でデータを取り込むような構成にすれば上記の問題が解決される、というわけだ。但し、実装上、本当に可能かはより詳細な検討・検証が必要であろう。
Job Scheduler の役割と、ジョブが処理されるまでの流れは以下の通り。
- ホストとストリーム番号のマッピングテーブルの管理: UDOP の出力ストリームは物理ホストを指定することができないので、Job Scheduler (UDOP) では、内部で出力ストリーム番号（以下、ストリーム番号と省略する）とホスト名をマッピングするテーブルを持たせる。このテーブルには、その他にも、スケジューリングアルゴリズムのために必要な各ホストの属性情報（CPU,メモリ、OS,動的負荷情報、メモリ使用量, レイテンシの平均及び分散、クラウド環境のホストかどうか）を持たせる。
- バースト度合いの計算： Job Scheduler はデータ到着レートを見てバースト度合いを計算。LAN 内のクラスタで処理できる量かどうかを調べる。
- バーストでない場合： ２の計算にてバーストでないと判断された場合には、Cluster Load Management Component (Python などのスクリプト言語を用いた軽量実装） からストリームとして流れる各ホストのロード情報を用いて、データを投げるホストを決定。決定したホスト名に相当するストリーム番号を上記のテーブルから引いてきて、データとプロパティをセットし、ストリームをexport する。export のプロパティは、クラウド環境も含めた一意の ID とする。
- バーストな場合： ２の計算にてバーストと判断された場合に、Cloud Controller (こちらも 同じく Python などのスクリプト言語を用いた軽量実装とする）に指令を出す。Cloud Controller はあるポート番号にて Listen しており、Job Scheduler からの指令を待つ。クラウドに対する VMM の管理コマンドが Job Scheduler から発行された場合には、Amazon EC2 や Eucalyptus などのクラウド環境に対して REST API を用いてその管理コマンドを発行する。また、VM の resume 時には、その VM にて System S のジョブが実行されるように、ジョブをサブミットする。計算側でのジョブは、import でデータを取り込み、処理を開始する。VM の suspend の際にはジョブキャンセルを実行する。
ちなみに、Cluster Load Management や Job Scheduler の機能は、System S の管理デーモンである SRM (Streams Resource Manager) や SCH (Scheduler) と同等の役割を果たしており、それらのデーモンを改変、拡張すれば良いのではとの指摘を受けると思われるが、そのような指摘に対して事前に対応するため、素直に前提条件として、「管理デーモンを改変することができない」ことを述べた方が良いだろう。
ただし、クラウドを用いた Elastic なデータストリーム処理という考え方、及びそれらのスケジューリングポリシーを提案することが、本研究の Contribution であることを強調し、今回 SPADE 上でアプリケーションレベルで実装したのとは本質的な差はないことを述べれば良い。
0 件のコメント:
コメントを投稿