Hadoop のスケジューリング機能

プラガブル・スケジューラー・フレームワークの紹介

Hadoop は、ジョブにリソースを割り当てるプラガブルなスケジューラーを実装することができます。しかし従来のスケジューリング機能からもわかるように、スケジューリングのアルゴリズムはすべてが同じわけではなく、効率は負荷とクラスターに依存します。この記事では、Hadoop のスケジューリング機能について説明し、今日利用できる 2 つのアルゴリズム、フェア・スケジューリングとキャパシティー・スケジューリングについて詳しく探ります。また、これらのアルゴリズムの調整方法と、これらのアルゴリズムがどのようなシナリオに適しているのかについても説明します。

M. Tim Jones, Consultant Engineer, 独立作家

M. Tim JonesM. Tim Jones は組み込みソフトウェアのエンジニアであり、『Artificial Intelligence: A Systems Approach』、『GNU/Linux Application Programming』(現在、第 2 版です) や『AI Application Programming』(こちらも現在、第 2 版です)、それに『BSD Sockets Programming from a Multilanguage Perspective』などの著者でもあります。技術的な経歴は静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで、広範にわたっています。彼はコロラド州ロングモン在住で、Intel に勤務するプラットフォーム・アーキテクトであり、執筆活動も行っています。



2012年 1月 20日

Hadoop は、一連の分散ノードにわたるデータを処理するハイパフォーマンスの汎用システムですが、この定義には、Hadoop がマルチタスク・システムであり、複数のユーザーによって開始された複数のジョブ用の各種データ・セットを同時に処理できる、という事実が含まれています。このように多重処理ができるということは、Hadoop はリソースの使い方を最適化するような方法で、リソースに対するジョブのより最適なマッピングができるということです。

Hadoop は 2008年まで、JobTracker ロジックが混在する 1 つのスケジューラーしかサポートしていませんでした。この実装は Hadoopで従来のバッチ・ジョブ (ログのマイニングや Web インデクシングなど) を実行する場合には完璧でしたが、柔軟性に欠け、カスタマイズが不可能でした。しかも Hadoop はバッチ・モードで動作するため、ジョブはキューに送信され、Hadoop のインフラストラクチャーは単に受信した順にジョブを実行していました。

幸いなことに、バグ・レポート (HADOOP-3412) が提出され、JobTracker とは切り離された単独のスケジューラーが実装されました。さらに重要なことに、この新しいスケジューラーはプラガブルであるため、ある具体的な特性を持つジョブを最適化するための新しいスケジューリング・アルゴリズムを使用することができます。この新しいスケジューラーへの変更によって、スケジューラーについて理解しやすくなるというメリットももたらされたため、従来よりもさまざまなことを試せるようになり、増え続ける Hadoop のアプリケーションに特化したスケジューラーを次々と作成できる可能性が広がりました。

この変更により、Hadoop は今や、さまざまなタイプのジョブを処理することが可能なマルチユーザーのデータ・ウェアハウスとなり、プラガブル・スケジューラー・フレームワークのおかげで非常に柔軟な制御が可能になっています。このフレームワークでは、多種多様な負荷 (小規模なジョブから大規模なジョブに至るあらゆる種類のジョブ) に最適な形で Hadoop クラスターを使用することができます。(送信された順でジョブを重要と判断する) FIFO スケジューリングから離れ、別のスケジューリング方式を使用することで、Hadoop クラスターは優先度やパフォーマンスの制約が異なる多様な負荷をサポートすることができます。

注: この記事は Hadoop をある程度理解していることを前提としています。Hadoop のアーキテクチャーを紹介した記事や、Hadoop を実際にインストール、構成し、最後に Hadoop アプリケーションを作成する方法を説明した連載記事へのリンクを「参考文献」に挙げてあります。

Hadoop のコア・アーキテクチャー

Hadoop クラスターはマスターとスレーブという比較的単純なアーキテクチャーで構成されています (図 1 を参照。訳注: 図 1 の左下の Master nodes は Slave nodes の誤りのようです)。NameNode は Hadoop クラスター全体のマスターとして、ファイルシステムの名前空間を管理し、クライアントに対してアクセス制御を行います。JobTracker はジョブ待ちのノードにジョブを分配します。この 2 つのエンティティー (NameNode と JobTracker) が Hadoop アーキテクチャーのマスターです。スレーブは TaskTracker で構成され、TaskTracker はジョブの実行 (ジョブの起動と監視、ジョブ出力の取得、JobTracker へのジョブ完了の通知など) を管理します。DataNode は Hadoop クラスターのストレージ・ノードであり、分散型ファイルシステムを (または、少なくともその一部を複数の DataNode で) 表現します。TaskTrackerと DataNode は Hadoop クラスターの中ではスレーブです。

図 1. Hadoop クラスターの構成要素
Hadoop クラスターを構成するすべての要素を示した図

Hadoop が柔軟であり、単一ノード・クラスター (すべてのエンティティーが 1 つのノード上に存在) も、マルチノード・クラスター (JobTracker と NameNodes が何千ものノードに分散) もサポートしていることに注意してください。実在する大規模な本番環境に関する情報はほとんどありませんが、既知の Hadoop クラスターで最大のものは 4000 ノードで構成されている Facebook です。これらのノードはいくつかのサイズに分割されています (半数のノードは 8 コアまたは 16 コアの CPU を持っています)。また Facebook クラスターは多くの DataNode に分散された 21PB のストレージをサポートしています。リソースの数が大量であり、無数のユーザーから多数のジョブが送信される可能性があるため、スケジューリングは最適化を行う上で重要な要素になります。


Hadoop のスケジューラー

Hadoop にはプラガブルなスケジューラーが実装されたため、それに伴っていくつかのスケジューラー・アルゴリズムが開発されました。以下のセクションでは、Hadoop で使用できるスケジューラー・アルゴリズムを詳しく探り、どのアルゴリズムをどのような場合に使用するのが適しているのかを説明します。

FIFO スケジューラー

JobTracker に統合されている元々のスケジューリング・アルゴリズムには FIFO スケジューリングという名前が付けられています。FIFO スケジューリングでは JobTracker がワーク・キューからジョブを取得し、最も古いジョブを最初に取得します。このスケジューラーにはジョブの優先度やサイズの概念はありませんが、実装が容易で効率的なスケジューラーです。

フェア・スケジューラー

フェア・シェア・スケジューラーのコアとなる概念は、ジョブにリソースを割り当てる場合、時間的に平均すると、各ジョブが等しい割合でリソースを使用するように割り当てる、というものです。その結果、あまり時間を必要としないジョブが CPU を使用してジョブを完了すると、そのジョブの残りの時間は、多くの時間を必要とするジョブが実行され、CPU が使用されます。この動作では、Hadoop のジョブ同士で多少のやり取りを行えるようにすることで、さまざまなタイプのジョブが送信されても Hadoop クラスターの応答性を良くすることができます。フェア・スケジューラーは Facebook によって開発されました。

Hadoop の実装では、ジョブを配置する一連のプールを作成し、スケジューラーがそれらのジョブを選択します。各プールには、プール内のジョブのリソースがどれも同じになるように一連のシェアが割り当てられます (シェアが大きければジョブの実行に使用可能なリソースも大きくなります)。デフォルトで、すべてのプールのシェアは同じですが、構成を変更することで、ジョブのタイプに応じてシェアの量を増減することができます。必要な場合には、同時にアクティブとなるジョブの数を制限して混雑を最小限にすることで、ジョブを希望通りの時間で完了させることもできます。

公平性を確保するために、各ユーザーには 1 つのプールが割り当てられます。こうすることで、ある 1 人のユーザーが多くのジョブを送信した場合でも、そのユーザーには他のすべてのユーザーと同じ割合のクラスター・リソースのシェアが割り当てられます (送信したジョブの量とは無関係です)。プールに割り当てられるシェアにかかわらず、システムの負荷が軽い場合には、ジョブは負荷が重ければ使用できなかったはずのシェアが割り当てられます (ジョブの間でシェアが分割されます)。

スケジューラーの実装はシステム内の各ジョブの CPU 使用時間を追跡します。スケジューラーは定期的にジョブを検証し、ジョブに割り当てられた CPU 使用時間と、理想的なスケジューラーであったら割り当てられたはずの CPU 使用時間との差を計算します。その結果により、タスクにとっての不足時間を判断します。そしてスケジューラーは最も不足時間の多いタスクを次回にスケジューリングします。

フェア・シェアの構成は mapred-site.xml ファイルで行います。このファイルで定義されるプロパティー全体によってフェア・シェア・スケジューラーの動作が制御されます。mapred.fairscheduler.allocation.file というプロパティーで参照される XML ファイルは、各プールへのシェアの割り当てを定義します。ジョブのサイズを最適化するためには、mapread.fairscheduler.sizebasedweight を設定し、ジョブ・サイズの関数としてジョブにシェアを割り当てます。同じようなプロパティーにより、5 分後にジョブの重みを調整し、より小さなジョブをより速く完了することができます (mapred.fairscheduler.weightadjuster)。他にも非常に多くのプロパティーがあり、それらを使用することで、ノードの負荷 (指定された TaskTracker が処理できる Map と Reduce の数など) を調整したり、プリエンプションを実行するかどうかを定義したりすることができます。構成可能なプロパティーの完全な一覧については「参考文献」のリンクを参照してください。

キャパシティー・スケジューラー

キャパシティー・スケジューラーは、基本的性質の一部がフェア・スケジューラーと同様ですが、明確に異なる点もあります。第 1 に、キャパシティー・スケジューリングは、独立したコンシューマーやターゲット・アプリケーションが複数ある大規模なクラスターに対して定義されます。そのため、キャパシティー・スケジューリングでは詳細な制御が可能なだけではなく、最小限の容量を保証したり、余分な容量をユーザー間で共有したりすることができます。キャパシティー・スケジューラーは Yahoo! によって開発されました。

キャパシティー・スケジューリングでは、プールの代わりにいくつかのキューが作成され、各キューには Map スロットと Reduce スロットがあり、これらのスロット数を調整することができます。また各キューには保証された容量が割り当てられます (クラスター全体としての容量は各キューの容量の合計です)。

キューはモニタリングされ、あるキューがその割り当てられた容量を使用していない場合には、この余分な容量を他のキューに一時的に割り当てることができます。キューは人や大規模な組織を表すため、利用可能な容量は他のユーザーが使用できるように再配分されます。

フェア・スケジューリングとのもう 1 つの違いは、キャパシティー・スケジューリングではキューのジョブに優先順位をつけられることです。一般的に、優先度の高いジョブは優先度の低いジョブよりも早くリソースにアクセスすることができます。Hadoop のロードマップには、プリエンプション (優先度の低いジョブを優先度の高いジョブと一時的に交換し、優先度の高いジョブを実行する機能) のサポートという願望が含まれていますが、この機能はまだ実装されていません。

もう 1 つの違いはキューに対するアクセス制御が厳格なことです (これはキューが人や組織に結びついているためです)。これらのアクセス制御はキューごとに定義されます。アクセス制御により、キューへのジョブ送信機能や、キューのジョブの表示機能、変更機能を制限します。

キャパシティー・スケジューラーの構成は、Hadoop の複数の構成ファイル内で行います。キューの定義は hadoop-site.xml で行い、キューの構成は capacity-scheduler.xml で設定します。ACL の構成は mapred-queue-acls.xml で行います。個々のキューのプロパティーに含まれるものには、容量の割合 (クラスター内のすべてのキューの容量は 100 パーセント以下です)、最大容量 (キューが使用できる余分な容量を制限します)、そのキューが優先順位をサポートするかどうか、などがあります。最も重要な点として、これらのキューのプロパティーを実行時に操作することができます。そのため、プロパティーを変更することで、クラスターを使用する上での障害発生を防ぐことができます。

その他のスケジューリング手法

スケジューラーそのものではありませんが、Hadoop は大規模な物理クラスター内部から仮想クラスターをプロビジョニングする HOD (Hadoop On Demand) という概念もサポートしています。HOD の手法では、Torque リソース・マネージャーを使用して仮想クラスターのニーズを基にノードを割り当てます。ノードが割り当てられると、HOD システムは自動的に構成ファイルを準備し、仮想クラスター内のノードを基にシステムを初期化します。HOD システムがいったん初期化されると、比較的独立した形で HOD 仮想クラスターを使用することができます。

また HOD は負荷が変化すると縮小することができるという点で、適応型でもあります。HOD は指定期間内に何もジョブが実行されていないと判断すると、仮想クラスターから自動的にノードの割り当てを解除します。この動作により、物理クラスター全体としてのアセットを最も効率的に使用することができます。

クラウド・インフラストラクチャー内に Hadoop クラスターをデプロイする上で、HOD は興味深いモデルです。HOD の別の利点として、共有されるノードが少なくなるためセキュリティーが高まり、場合によると、複数ユーザーのジョブを実行することで発生するノード内の競合もなくなるため、パフォーマンスを高めることもできます


どのスケジューラーをどのような場合に使用するか

上記の説明から、これらのスケジューリング・アルゴリズムが何をターゲットとしているかを理解できることと思います。多数のクライアントが存在し、ジョブのタイプや優先度が多様な大規模 Hadoop クラスターを実行している場合には、キャパシティー・スケジューラーが適切な選択肢です。キャパシティー・スケジューラーには、使用されていない容量を再利用したり、キューのジョブに優先度をつけたりすることができる可能性があり、リソースを使用できることが保証されます。

フェア・スケジューラーは、キャパシティー・スケジューラーほど複雑なことはできませんが、限られた負荷を持つ組織が大規模なクラスターと小規模なクラスターの両方を使用している場合に適しています。フェア・スケジューリングにも、(ジョブの) プールに容量を不均一に分散する機能がありますが、その機能は単純で、構成も柔軟ではありません。フェア・スケジューラーは小規模なジョブと大規模なジョブとが混在する場合に小規模なジョブの応答が速くなるため (より対話型の使用モデルをサポートしているため)、多種多様なジョブが存在する場合に有効です。


Hadoop のスケジューリング機能の今後の展開

Hadoop のスケジューラーはプラガブルであるため、特殊なクラスターのデプロイメント用に開発された新しいスケジューラーを期待することができます。(Hadoop が解決すべき問題のリストを見ると) 開発中の 2 つのスケジューラーとして、適応型スケジューラー (adaptive scheduler) と学習スケジューラー (learning scheduler) があります。学習スケジューラー (MAPREDUCE-1349) は多様な負荷がある場合にそれぞれの負荷が一定のリソース使用率を維持するように設計されています。このスケジューラーの実装は現在、CPU 負荷の平均化に焦点を絞っていますが、ネットワークやディスク I/O の使用率についても対処する予定です。適応型スケジューラー (MAPREDUCE-1380) は、スケジューラーのパフォーマンスとユーザー定義のビジネス目標とを基に、指定ジョブに対するリソースを適応型で調整する方法に焦点を絞っています。


まとめ

プラガブル・スケジューラーの導入は Hadoop によるクラスター・コンピューティングの新たな進化です。プラガブル・スケジューラーにより、特定の負荷やアプリケーションに最適化されたスケジューラーを使用 (そして開発) することができます。また新しいスケジューラーにより、Hadoop のインフラストラクチャー全体を複数のユーザーや組織が共有できるようになり、Hadoop によるマルチユーザーのデータ・ウェアハウスも作成できるようになりました。

Hadoop の使用モデルが進化するにつれて Hadoop も進化しており、今や新しいタイプの負荷や使用シナリオをサポートするようになっています (マルチユーザーまたは複数組織による巨大なデータ・ウェアハウスなど)。このように Hadoop が柔軟になったことは、大規模なデータ分析においてクラスター・リソースをより最適な形で使用する上での大きな前進です。

参考文献

学ぶために

  • Apache Hadoop の Web サイトはドキュメントの入手やメーリング・リストへの参加、そして Hadoop について学ぶために最適の場所です。このサイトには Hadoop のインストール方法や構成方法についても解説されています。
  • それぞれのスケジューラーには構成可能で多種多様なプロパティーがあります。Apache のサイトにはフェア・スケジューラーキャパシティー・スケジューラーのプロパティーが解説されています。
  • Linux と Hadoop による分散コンピューティング」(Ken Mann と M. Tim Jones との共著、developerWorks、2008年12月) は、大量のデータの分散処理に対する MapReduce の基本的な仕組みを含め、Hadoop のアーキテクチャーを紹介しています。
  • HADOOP-3412 はスケジューラーの問題を指摘し、JobTracker の外でスケジューラーをリファクタリングするようにしています。Hadoop の最初の実装では JobTracker ノード内にスケジューラー・アルゴリズムが混在していました。2008年に提出されたこの問題により、それまで一体化されていたスケジューラーが削除され、プラガブルなスケジューラーが追加されたことで、Hadoop は多様な負荷に柔軟に対応できるようになりました。
  • Hadoop の実践的な紹介記事として、M. Tim Jones による developerWorks の連載「Hadoop による分散データ処理」があります。「第 1 回 導入編」(2010年5月) は単一ノードの Hadoop クラスターのセットアップ方法と使用方法を紹介しています。「第 2 回 拡張編」(2010年6月) ではマルチノード・クラスターのセットアップ方法と使用方法を学びます。最後に、「第 3 回 アプリケーション開発」(2010年7月) では Hadoop 環境で MapReduce アプリケーションを作成する方法を学びます。
  • Linux でのスケジューリングは興味深いトピックであり、Hadoop のジョブのスケジューリングと Linux のスレッドのスケジューリングとが似ていることがわかります。Linux のスケジューリングについて学ぶための記事として、「Linux スケジューラーの内側」(M. Tim Jones 著、developerWorks、2006年6月)、「Linux カーネル 2.6 Completely Fair Scheduler の内側」(M. Tim Jones 著、developerWorks、2009年12月)、「Linux スケジューラーのシミュレーション」(M. Tim Jones 著、developerWorks、2011年2月) があります。
  • developerWorks の Open source ゾーンには、オープンソース・ツールの情報やオープンソース技術の使い方に関する情報が豊富に用意されています。
  • Twitter で developerWorks をフォローしてください。この記事の著者も M. Tim Jones から Twitter でフォローすることもできます。
  • developerWorks On demand demos をご覧ください。初心者のための製品インストール方法やセットアップのデモから、上級開発者のための高度な機能に至るまで、多様な話題が解説されています。

製品や技術を入手するために

  • 皆さんの目的に最適な方法で IBM 製品を評価してください: 製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

議論するために

  • My developerWorks コミュニティーに加わってください。開発者向けのブログ、フォーラム、グループ、ウィキなど利用しながら、他の developerWorks ユーザーとやり取りしてください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Linux
ArticleID=785463
ArticleTitle=Hadoop のスケジューリング機能
publish-date=01202012