ドライアド 分散コンピューティングフレームワーク

次の統計情報*を使用して、 分散アプリケーションを実行するための一般的なフレームワークを想像してください。


* 2011年の統計データ。

これがHadoopではないことを想像してください。

それがどのようなフレームワークであるか、その基礎に据えられたアイデアと概念、およびこのフレームワークがHadoopよりもさらに革新的（主観的）である理由については、以下で説明します。

1.ドライアド。 一般的な情報

Dryadは、分散アプリケーションを実行するための汎用ソフトウェアフレームワークです 。 Dryadは、 Microsoft Researchのプロジェクトです。 Dryadプロジェクトの中心概念は、各分散タスクの有向非循環グラフ （DAG）の構築です。 グラフの頂点は データ （実際にはプログラム） に対する操作で あり、グラフのエッジはデータが送信されるチャネルです。

有向非巡回グラフのモデルに基づく抽象化により、多数の並列アルゴリズム 、 反復アルゴリズム 、 機械学習アルゴリズムの実行計画を効果的に実装できます。 したがって、Hadoop **で実装されている（ YARNの前の） map / reduceプログラミングモデルは、基本的にDryadが提供する分散コンピューティングモデルの特別な場合にすぎません。

Dryadは、中規模または大規模のコンピューティングクラスター（100〜10Kのコンピューティングノード）で実行するように最適化されており、主に頻繁な対話を必要としない長期バッチジョブを対象としています。

2004 ... 2008

Dryadの過去、現在、未来に対処する試みは、かなり限られた数の記事につながりました。著者は、元の情報源ではなく、次のように主張しています。

• このようなシステムを構築するというアイデアは、2004年に生まれました（Google MapReduceとの類推）。MichaelIsard（後に彼はマイクロソフトの研究者になりました）。
  
• 2006年、ビルゲイツ自身がコンピューターサイエンス会議でドライアド自身を発表しました。
  
• Dryadは、Bing、Microsoft AdCenter、 Kinect 、Windows HPC Server 2008 R2（後者、信頼性の高いものとして知られています）で使用されています。
  

2008 ... 2009

Dryadで具体化された概念を説明する基本文書の1つは、 OSDI'08 （USENIX Symposium on Operating Systems Design and Implementation）で「 Best Paper 」を受賞しました。

2009年11月、Dryadはアカデミックライセンスの下で利用可能になりました。

2010 ... 2011

2011年に、Windows HPCチームは 、対応するWindowsオペレーティングシステムラインの「LINQ to HPC」 （Windows HPCサーバー用のDryad） のベータ版を発表しました 。 同じ年に、 LINQ to HPCはプレビューバージョンから「終了しない」ことが発表されました（つまり、実際にはサポートの終了について）。

2012 ... 2013 / UPD /

Windows HPCチームが、Dryadプロジェクトのサポート/開発について何も言わなかった（そして原則的に言えなかった）ことは注目に値します。 ドライアドのさらなる支援、または反対に、明確な支援拒否に関するその他の声明は、過去（2012年）および今年に気づかれていません。

2.ドライアドエコシステム

Dryadプロジェクトは、3つの主要なコンポーネントで構成されています。

• Dryad-分散アプリケーションのランタイム（以下、あいまいさを避けるために、このコンポーネントをDryad Runtimeと呼びます）;
  
• DryadLINQは、.NET言語統合プログラミングモデルに基づいた高レベルのクエリ言語です。
  クエリ（LINQ）;
  
• 分散ストレージカタログ （DSC）は、構成可能な冗長性を備えた分散ファイルシステムです。
  

以下に、Dryadエコシステムの要素であるDryadランタイムランタイムとDryadLINQクエリ言語を詳しく見ていきます。

3.ドライアドランタイム

Dryadランタイムは、Hadoopなどの分散アプリケーションのランタイムであり 、次のような機能を取ります。

• 分散タスクのスケジューリングと管理。
• リソース管理。
• 耐障害性;
• 監視

Dryadランタイムのタスクは、 頂点がプログラムであり、グラフのエッジがデータチャネルである有向非循環グラフです。 この論理グラフは、実行可能環境によってクラスター内の物理リソースにマップされます。 一般に、グラフ内の頂点の数は、クラスター内の物理コンピューティングノードの数を超えます。

3.1。 データチャネル

データチャネルと頂点は抽象化であり、次のように表されます。

• 共有メモリFIFO （マシン内）：操作（グラフの頂点）間でデータを交換する最速の方法ですが、操作は単一のコンピューティングノード内で実行する必要があります。
  
• TCPパイプ （マシン間）：ディスクへのアクセスを必要としないチャネル（ディスクからのデータの書き込み/読み取りに関連するオーバーヘッドを回避します）; チャネルは、送信時にデータを送信する操作が利用可能な場合にのみ使用できます。
  
• SMB / NTFSファイル （一時ファイル）：チャネル経由で送信された出力が記録されます
  ディスクに入力データが読み込まれます。 デフォルトのチャンネル。
  

分散タスクを最も効率的に実行するためにクラスターの物理リソースに関する情報を開示する必要があるため、チャネルの抽象化は一見すると「クリーン」ではありません。 それにもかかわらず、分散アプリケーションの開発者は、「チャネル」抽象化の違反を「認識しません」。 彼女は他のレベル（タスクマネージャー）の下に隠れます。これについては以下で説明します。

3.2。 データモデル

Dryadデータモデルは、 シェアードナッシングアーキテクチャです。 そのようなアーキテクチャの利点は伝統的にスケーラビリティ 、 変更追跡をサポートする必要性の不在、 複雑なトランザクションの実装、および同期プリミティブの使用です。 Dryadプラットフォームは、大量の静的データに適していますが、頻繁にデータを変更またはストリーミングするのには適していません。

Dryadは、 不変で有限量の入力データを受け取ることを期待しています。 分散プログラムの実行結果は、すべてのルーチンが実行されるまで利用できません。 ストリーミングデータを使用するタスクは、Dryadでは基本的に不可能であると想定するのは論理的です。

3.3。 ジョブマネージャー

Dryadジョブは、 ジョブマネージャー （JM）によって調整されます。 Job Managerには、タスクを計算するためのグラフを作成するためのアプリケーション固有のコードが含まれています。

ジョブマネージャーは以下を担当します。

1. 計算グラフの初期化 。
   
2. これらの頂点に関連付けられた物理ハードウェアが、これらの頂点によって処理されるデータにトポロジー的に可能な限り近くなるように、 操作 （頂点、以下、頂点操作と呼びます）を計画します。
   
3. 耐障害性 ;
   
4. パフォーマンスの監視と統計の収集 。
   
5. 既存のポリシーに従ったグラフの動的な変換 。
   

アプリケーションデータは、頂点操作から頂点操作に直接送信されます。 Job Managerは、分散タスクの実行の初期化、スケジューリング、および監視のみを行います。 したがって、 JMはパフォーマンスのボトルネックではありません 。 さらに、転送中に、頂点操作コードは、Job Managerまたは同様の頂点操作が実行される最も近いコンピューティングノードから転送できます。

3.4。 ネームサーバー。 デーモン

ネームサーバーネームサーバーは、使用可能な計算ノードとクラスター内のトポロジの場所に関する情報の開示を担当します。

デーモンプロセスは各コンピューティングノードで起動されます。その主な目的は、ジョブマネージャーによって送信された頂点操作を起動することです。 デーモンはプロキシオブジェクトとして機能するため、ジョブマネージャーは、リモートデーモンによって起動された頂点操作のステータスとステージを見つけることができます。

Dryadアーキテクチャと、 ジョブマネージャ 、 ネームサーバー （NS）、およびデーモン （PD）のこのアーキテクチャ内の場所を以下に示します。


イラストのソース[3]

（ 図の説明 ：JMはNSから受信した使用可能なノードとその場所のデータに基づいて実行グラフを初期化します。JMはグラフの実行を監視し、PDからステータスを受け取ります。現在実行中の操作を示します。）

3.5。 動的なグラフ変更

ジョブマネージャーは、HadoopのJobTrackerと同様に、 静的なパフォーマンスの最適化を提供します 。 ただし、Hadoopとは異なり、Dryadにはパフォーマンスを動的に最適化する機能があります。

有向非巡回グラフの Dryadの中心概念とコールバックメカニズムのサポート（コールバックは頂点操作の実行フェーズの変更についてJMに通知します）のおかげで、実行グラフはランタイム中に変更できます。 動的な変更により、次の問題を非常にエレガントに解決できます。

• 複数のノードが別のノードの入力にデータを転送する必要がある場合のネットワーク帯域幅の低下 （Hadoopでは、CombineステージとReduceステージ間でデータを転送するときにこのような低下が観察されます）;
  
  
  
• 「遅い」操作の完了を待つための単純なコンピューティングノード （Hadoopでは、すべてのマップタスクが完了するまで畳み込みを開始できないため、単純なマップスロットが発生し、プログラムの最適な実行時間が「最も遅い」マップの実行時間と等しくなります。タスク）。
  
  
  

さらに、実行時のグラフの動的な変更と特定のデータ転送方法からの「チャネル」の概念の抽象化により、データが物理的に格納されているノードからだけでなく、データが頂点に到達できることが重要です（つまり、実装されていない場合は実装することが可能です）しかしまた：

• 1つのデーモンは、中間データを含む一時ファイルを頂点操作に対してローカルなラックに保存できます。この操作では、このデータが入力として受け入れられます。
  
• 1つのデーモンは、このデータを入力として受け入れる頂点操作が同じ計算ノードで実行されている場合、ホストのRAMにデータを保存できます。
  

3.6。 弾力性

前述のように、デーモンはプロキシであるため、ジョブマネージャーはリモートデーモンによって起動された頂点操作のステータスとステージを見つけることができます。 デーモンが「クラッシュ」した場合、ジョブマネージャーはそれを認識します。

• デーモンが自身のプロセスを閉じる前にJMに送信したエラーメッセージ
  
• デーモンを閉じるときにJMに診断イベントが送信されなかった場合に備えて、ハートビートメッセージの有効期限まで。
  

PDの障害を診断した後、PDで実行された操作は別のデーモンで再実行されます。



ネームサーバーがクラッシュした場合に何が起こるかについて、Dryadのドキュメントには情報が見つかりませんでした。 NSプロセスからのハートビートがない場合、Job Managerは別のノードでNSを再起動すると想定するのが妥当です。 NSが責任を負う情報を開示するための、クラスターの計算能力の一部であるネームサーバーのダウンタイム中に、単に「フォールアウト」します。

また、Job Managerが単一障害点にならないようにするためにどのような対策が講じられたかは、ドキュメントから明らかになりませんでした。 各分散アプリケーションに独自のジョブマネージャーがある場合、ジョブマネージャーを停止しても、Name Nodeが失敗した場合のHadoopの場合のように、クラスター全体のダウンタイムは発生しません。

ただし、分散アプリケーションごとに個別のJMプロセスが存在すると、すぐに2つの問題が発生します。

• Job Managerの初期化にかかった時間
• リソース共有の問題、Job Managerは空きリソース（CPU、RAM、帯域幅）の量を「適切に」推定できません。 この物理コンピューティングノードが処理しているJMプロセスがさらにいくつあるかはわかりません。
  

4.練習

ドライアドはアカデミックライセンスの下で無料で入手できます[4]。 フレームワークを開始するには、Microsoft HPC Pack 2008 SP1、4 Gb RAM、1 Gb Ethernet、およびクラスターの各ノードに200 Gbの空き容量があるWindows HPCクラスターが必要です[1]。

Dryadアプリケーションは、C ++とC＃の両方で作成できます（CLS互換言語が適切であると想定するのは合理的です）。

Dryadの操作の分散実行の命令は次のとおりです（InitialReduce、Combine、Initialize、Iterate、Mergeは、分散実行の対応するステージを担当する関数の名前です。リストの例では算術平均を考慮しています）。

///<summary>For iterator-based implementation</summary> [AssociativeDecomposable("InitialReduce", "Combine")] public static TOutput H(IEnumerable<TInput> source) { … } 

 ///<summary>For accumulator-based implementation</summary> [AssociativeDecomposable("Initialize", "Iterate", "Merge")] public static TOutput H(IEnumerable<TInput> source) { … } 

DryadLINQクエリ言語はコードの複雑さをカプセル化するため、一般に、アプリケーション開発者はリストにリストされているデザインを書く必要はありません。 DryadLINQについては、このシリーズの次の記事で説明します。

5.制限と欠点

結論として、Dryadの制限と、このクラスのソフトウェアの目的の誤解に主に関連する「誤った」期待を簡単に確認します。

Dryadの主な制限の1つは、 リアルタイムモードでの動作に適応することの難しさと、おそらくストリーミングデータでの動作の根本的な不可能性です 。 また、Dryadフレームワークはバッチタスクに対して優れた効率を発揮しますが、Draydの使用はランダムアクセス操作では正当化されないことも追加する必要があります。 さらに、ジョブマネージャーがジョブマネージャーを「クラッシュ」させると、（アプリケーションレベルで） 単一障害点の潜在的な問題に注意します（このような障害点はないかもしれませんが、ドキュメントからこの問題の解決方法は明確ではありません）。

また、Dryadは分散コンピューティングフレームワークにすぎないことを理解する必要があります。したがって、Dryadに期待することはできません。

• RDBMSではないため、 トランザクションサポート 。
  
• Dryadは根本的に異なるツールで根本的に幅広い問題を解決するため、 GPUコンピューティングに匹敵するパフォーマンス 。
  
• オープンソースライセンスだから マイクロソフト もともとは異なるタイプの製品（ただし、アカデミックライセンスでは引き続き無料でアクセスできます）。
  
• マップのフレームワーク内で動作する分散アプリケーションの迅速な開発 /パラダイムの削減。DryadはHadoopではないためです。マップ/削減モデルは、Dryadの特殊なケースにすぎませんが、Hadoopの場合は唯一の実行モデルです。
  

おわりに

Dryadの残りの部分は、分散アプリケーション開発者向けの強力で柔軟な抽象化です。 プラットフォームは、並列ソフトウェアの開発に関する最新の概念とアイデアの極めて有機的な共生であり、使い慣れた言語ツールと、分散コンピューティングフレームワークがしばしば直面する（そしてめったに解決されない）問題を解決するエレガントな方法を提供します 。

ソースのリスト

[1] ドライアドプロジェクト 。 Microsoft Research。
[2] Y. Yu、PK Gunda、M。Isard。 データ並列コンピューティングの分散集約：インターフェイスと実装 、2009年。
[3] M.アイサード、M。ブディウ、Y。ユー、A。ビレル、およびD.フェッターリー。 Dryad：シーケンシャルビルディングブロックからの分散データ並列プログラム 。
コンピュータシステムに関する欧州会議（EuroSys）の議事録、2007年。
[4] DryadおよびDryadLINQアカデミックリリース 。 Microsoft Research。

*アルファベット順にソートされています。
**この記事の比較は、Hadoopプラットフォームの最初のバージョン（つまり、YARNなし）でのみ行われます。 DryadとDBMS、GPUコンピューティング、Hadoopフレームワークの詳細な比較は、Dryad シリーズの最終記事で行われます。