[論文レビュー] Scalable, Fast Cloud Computing with Execution Templates

Omid Mashayekhi, Hang Qu+2 more|arXiv (Cornell University)|Jun 6, 2016

Cloud Computing and Resource Management参考文献 21被引用数 3

ひとこと要約

本論文では、クラウドコンピューティングにおける繰り返し発生するCPUバウンドなワークロードのスケジューリング意思決定をキャッシュする制御プレーンの抽象化である実行テンプレートを導入する。繰り返し計算ループを再利用可能なテンプレートとして扱うことで、スケジューリングのオーバーヘッドを低減し、Spark や Naiad よりも16〜43倍の高速化を実現。100ノード（800コア）にスケーリング可能であり、100μsの短いタスクに対しても対応可能である。

ABSTRACT

Large scale cloud data analytics applications are often CPU bound. Most of these cycles are wasted: benchmarks written in C++ run 10-51 times faster than frameworks such as Naiad and Spark. However, calling faster implementations from those frameworks only sees moderate (3-5x) speedups because their control planes cannot schedule work fast enough. This paper presents execution templates, a control plane abstraction for CPU-bound cloud applications, such as machine learning. Execution templates leverage highly repetitive control flow to cache scheduling decisions as {\it templates}. Rather than reschedule hundreds of thousands of tasks on every loop execution, nodes instantiate these templates. A controller's template specifies the execution across all worker nodes, which it partitions into per-worker templates. To ensure that templates execute correctly, controllers dynamically patch templates to match program control flow. We have implemented execution templates in Nimbus, a C++ cloud computing framework. Running in Nimbus, analytics benchmarks can run 16-43 times faster than in Naiad and Spark. Nimbus's control plane can scale out to run these faster benchmarks on up to 100 nodes (800 cores).

研究の動機と目的

• 高度に最適化されたCPUバウンドコードを実行する際、現代のクラウドアナリティクスフレームワークの制御プレーンが遅延するというパフォーマンスボトルネックを解消すること。
• Spark や Naiad などの既存フレームワークが、C++最適化カーネルを実行する際にコントローラーの飽和により20ノードを超えてスケーリングできないという制限を克服すること。
• 繰り返し発生する制御フローを再利用可能なスケジューリングテンプレートに抽象化することで、細粒度タスク（100μsまで）の大規模かつ高スルーレート実行をクラウド環境で可能にすること。
• 中央集権的なコントローラーが極めて高いタスクレート（従来のシステム比100倍速）を処理できる新しい制御プレーン抽象化を設計し、ボトルネックにならないようにすること。
• 高パフォーマンスシミュレーション（例：PhysBAM）を含む複雑な実世界ワークロードを、最小限のランタイムオーバーヘッドとネイティブ性能に近い性能でサポートすること。

提案手法

• CPUバウンドアプリケーションにおける繰り返し発生するループのスケジューリング意思決定をキャッシュする制御プレーン抽象化として実行テンプレートを導入する。
• ジョブの制御フローをコントローラーレベルのテンプレートとワーカーごとのテンプレートに分解し、ノード間で仕事を分割しながら依存関係を保持する。
• 動的プログラム解析を用いて、制御フローやデータフローの変化に対応するため、実行時にテンプレートを動的にパッチする。これにより、動的動作に対しても正しさを保証する。
• 可変データオブジェクトを活用してインプレース計算をサポートし、メモリオーバーヘッドを低減するC++ベースのアナリティクスフレームワークであるNimbusにこの抽象化を実装する。
• 1つのコントローラーが1つのメッセージで数千のタスクをテンプレート経由でインスタンス化することで、スケジューリング頻度とレイテンシを著しく低減する。
• 100μsまでのサブミリ秒タスクを最適化し、従来HPCやMPIでしか効率的に実行できなかったワークロードをクラウドで効率的に実行可能にする。

実験結果

リサーチクエスチョン

• RQ1 C++最適化カーネルを実行する際、Spark や Naiad がわずか3〜5倍の高速化しか達成できないのはなぜか？（カーネル自体は最大51倍速いが。）
• RQ2 既存のフレームワークで、多くのノードにわたってCPU最適化ワークロードをスケーリングする際、制御プレーンがボトルネックとなる原因は何か？
• RQ3 極めて高いタスクレート（例：1msあたり1000タスク）を処理できる制御プレーン抽象化を設計できるか？正しさやスケーラビリティを損なわず。
• RQ4 動的制御フローに耐えうるよう、ループの繰り返し実行においてスケジューリング意思決定をキャッシュ・再利用する方法は何か？正しさを保証しつつ。
• RQ5 このような抽象化を備えたクラウドフレームワークが、マイクロ秒レベルのタスクを伴う実世界の複雑なワークロード（例：高パフォーマンスシミュレーション）をどの程度効果的にサポートできるか？

主な発見

• 機械学習ベンチマークのC++実装は、Spark版と比較して最大51倍速く実行されるが、JNI経由で呼び出すと制御プレーンのボトルネックによりわずか3〜5倍の高速化にとどまる。
• Spark や Naiad の制御プレーンは、20ワーカーノードを超えてスケーリングすると飽和し、完了時間は減少せず増加する。これはスケジューリングのオーバーヘッドが原因。
• 実行テンプレートを用いることで、Nimbusは同じ最適化ベンチマークでSparkに対して16〜43倍、Naiadに対して16〜23倍の高速化を達成。100ノード（800コア）にスケーリング可能。
• 実行テンプレートにより、スケジューリング意思決定をキャッシュし、スケジューリング頻度を低減することで、100μsという100倍短いタスクを処理可能に。従来のシステムが対応できる時間より100倍短い。
• 元々MPI用に手動チューニングされたPhysBAMシミュレーションライブラリは、実行テンプレートを用いたNimbus上で、ネイティブMPI性能の15％以内で実行可能であり、実世界への適用可能性を示している。
• 実行時にテンプレートを動的にパッチすることで、制御フローやデータフローが変化しても正しさが保証され、多様で複雑なワークロードにわたる抽象化が性能を損なわず動作可能である。