Apache Hadoop は、ビッグ・データを処理するのに最もよく使われているツールの 1 つです。ここ数年の間、多くの企業が本番環境に Hadoop をデプロイして功を奏してきました。Hadoop は信頼性、スケーラビリティー、コスト効果に優れたソリューションであると見なされていますが、大規模な開発者コミュニティーによって常に改善が続けられています。その結果、Apache Hadoop 2.0 には YARN (Yet Another Resource Negotiator)、HDFS 統合、可用性に優れた NameNode などの革新的な機能が用意されています。これらの機能により、Hadoop クラスターの効率性、処理能力、信頼性には、これまで以上に大幅な改善がもたらされます。この記事では、以前のバージョンの Hadoop 分散処理層に勝る、YARN の利点を説明します。

Adam Kawa, Hadoop Developer, Administrator, and Instructor, Spotify and GetInData

Adam KawaAdam Kawa は Spotify でデータ・エンジニアとして働いています。彼の主な業務は、ヨーロッパで最大の Hadoop-YARN クラスターの 1 つを保守することです。時折彼は、MapReduce、Hive、Tez、Pig といったアプリケーションの実装とトラブルシューティングを行っています。Adam は GetInData で Hadoop のインストラクターとしても働いており、Hadoop カンファレンスや Hadoop ユーザー・グループの会合で頻繁に講演をしています。彼は、ストックホルムとワルシャワで Hadoop ユーザー・グループの会合を共催しています。Adam は定期的に HakunaMapData.com で Hadoop エコシステムについてのブログを書いています。



2014年 6月 26日

はじめに

Apache Hadoop 2.0 には、リソース管理と処理コンポーネントを切り離す YARN が組み込まれています。YARN ベースのアーキテクチャーは、MapReduce だけに限られているわけではありません。この記事では、YARN の概要と、Hadoop の以前の分散処理層に勝るその利点を説明します。YARN のスケーラビリティー、効率性、柔軟性を利用してクラスターを機能強化する方法を学んでください。


Apache Hadoop の概要

Apache Hadoop は、一般商品化されたマシンのクラスターにインストールして、これらのマシン同士が通信および連動して高度に分散化された方法で大量のデータを保管、処理できるようにする、オープンソースのソフトウェア・フレームワークです。Hadoop は当初、2 つのメイン・コンポーネントで構成されていました。その 1 つは HDFS (Hadoop Distributed File System)、もう 1 つは、プログラムを MapReduce ジョブとして実装して実行できるようにする分散コンピューティング・エンジンです。

MapReduce とは、Google によって広められた単純なプログラミング・モデルであり、高度に並列化されたスケーラブルな方法で大規模なデータ・セットを処理するのに役立ちます。MapReduce を発想するもととなったのは、ユーザーが実行する計算を map 関数と reduce 関数として表現し、これらの関数によってキーと値のペアとしてデータを処理する関数型プログラミングです。Hadoop は、さまざまな言語でカスタムの map 関数と reduce 関数を実装するための上位レベルの API を提供します。

Hadoop は、MapReduce ジョブを一連の map および reduce タスクとして実行するソフトウェア・インフラストラクチャーも提供します。map タスクは、入力データのサブセットに対して map 関数を呼び出します。これらの関数が完了すると、reduce タスクが map 関数によって生成された中間データで reduce 関数の呼び出しを開始して、最終的な出力を生成します。map タスクと reduce タスクは互いに独立して実行されるため、耐障害性のある並列計算を行うことができます。

とりわけ重要な点は、分散処理の複雑な側面のすべて (並列化、スケジューリング、リソース管理、マシン間通信、ソフトウェアおよびハードウェアの障害に対する処理など) に Hadoop インフラストラクチャーが対処することです。この簡潔な抽象化のおかげで、数百台 (あるいは数千台でも) のマシンでテラバイト単位のデータを処理する分散アプリケーションを、かつてないほどに簡単に実装できるようになっています。分散システムの経験がない開発者でさえも、そのような分散アプリケーションを実装できるほどです。


Hadoop の黄金期

MapReduce モデルのオープンソース実装は、いくつか種類があるにもかかわらず、Hadoop MapReduce は瞬く間に最もよく使用される実装になりました。Hadoop は地球上で最もエキサイティングなオープンソース・プロジェクトの 1 つでもあります。その理由となっているのは、上位レベルの API、ほぼ線形のスケーラビリティー、オープンソース・ライセンス、一般商品化されたハードウェアで実行できること、そして耐障害性などの卓越した機能の数々です。数百 (おそらく数千) の企業でデプロイされて功を奏している Hadoop は、現在の大規模分散ストレージおよび大規模分散処理の標準となっています。

早くから Hadoop を採用した Yahoo! や Facebook などの一部の企業は、増加の一途を辿る各種のデータ処理のニーズに対応するために、4,000 ノードにもおよぶ大規模クラスターを構築しました。しかしその一方で、これらの企業ではクラスターが構築された後に、Hadoop MapReduce フレームワークの制約が明るみになってきました。


従来の MapReduce に伴う制約

従来の MapReduce に伴う最も重大な制約は、主にスケーラビリティー、リソース使用量、そして MapReduce 以外のワークロードのサポートに関係します。MapReduce フレームワーク内でジョブの実行を制御するプロセスには、次の 2 つのタイプがあります。

  • JobTracker と呼ばれる単一のマスター・プロセス。このプロセスが、クラスターで実行されているすべてのジョブを調整し、TaskTracker 上で実行される map タスクと reduce タスクを割り当てます。
  • TaskTracker と呼ばれる数々の従属プロセス。割り当てられたタスクを実行し、その進行状態を定期的に JobTracker にレポートします。
従来のバージョンの Apache Hadoop (MRv1)
従来のバージョンの Apache Hadoop (MRv1) を示す図

大規模な Hadoop クラスターでは、スケーラビリティーのボトルネックを伴う制約があることが、明らかになってきました。その原因は、単一の JobTracker を使用することにあります。Yahoo! によると、このような設計による実際的な限界には、5,000 のノードからなるクラスターで 40,000 のタスクを同時に実行したときに達したということです。この制約が理由で、規模を小さくした処理能力に劣るクラスターを作成して保守しなければなりませんでした。

さらに、規模を小さくしても大きくしても、Hadoop クラスターによる計算リソースの使用効率が最大限に達した試しはありませんでした。Hadoop MapReduce では、クラスター管理者が各スレーブ・ノードの計算リソースを一定数の map スロットおよび reduce スロットに分割します。map スロットと reduce スロットを交換することは不可能です。map スロットと reduce スロットの数は設定されていて、ノードは map スロット数より多くの map タスクを実行することができません。これは、reduce タスクが実行されていない場合でも同じです。reduce スロットが使用可能であっても、すべての map スロットが占有されていると (必要な map スロットが足りない場合でも)、reduce スロットを使用することはできません (その逆も当てはまります)。これが、クラスター使用率に悪影響をもたらす原因です。

最後に同じく重要な点として、Hadoop が設計されたとき、その実行対象となっていたのは MapReduce ジョブだけです。他のプログラミング・モデル (Apache Giraph が提供するグラフ処理など) が登場するにつれ、MapReduce 以外のプログラミング・パラダイムもサポートして、それらを同じクラスター上で実行し、効率かつ公平にリソースを共有できるようにする必要性が高くなってきました。

2010年には Yahoo! のエンジニアたちが、以上のすべての制約とその他複数の機能に対処する、まったく新しい Hadoop のアーキテクチャーへの取り組みを開始しました。


スケーラビリティーの問題への対処

Hadoop MapReduce では、JobTracker に次の 2 つの異なる責任が課せられます。

  • クラスターでの計算リソースの管理。これには、ライブ・ノードのリストの維持、使用可能な map スロットと reduce スロットのリスト、および占有されている map スロットと reduce スロットのリストの維持、そして使用可能なスロットを、選択されたスケジューリング・ポリシーに応じて適切なジョブとタスクに割り当てる作業が伴います。
  • クラスター上で実行されるすべてのタスクの調整。これには、TaskTracker に対する map および reduce タスクの開始指示、タスクの実行のモニター、失敗したタスクの再開、処理時間のかかるタスクの投機的実行、ジョブ・カウンターの合計値の計算などが伴います。

このように単一のプロセスに多数の責任が課せられることで、スケーラビリティーに関する重大な問題が発生しました。この問題は、JobTracker が常に数千の TaskTracker、数百のジョブ、そして何万もの map タスクと reduce タスクを追跡しなければならない大規模なクラスターとなると、さらに深刻化します。以下に、この問題を図解します。これとは対照的に、TaskTracker が通常実行するのは、働き者の JobTracker によって割り当てられた数十のタスクだけです。

大規模な Apache Hadoop クラスターでの多忙な JobTracker (MRv1)
大規模な Apache Hadoop クラスターでの多忙な JobTracker (MRv1) を示す図

スケーラビリティーの問題に対処するために、単純ながらも素晴らしいアイデアが提案されました。それは、単一の JobTracker の仕事をどうにかして減らし、クラスター内に数多く存在する TaskTracker にその仕事の一部を委任するというものです。この考えは、JobTracker に課せられた 2 つの責任 (クラスター・リソースの管理とタスクの調整) を 2 つの別々のプロセスに切り分けるという方法で、新しい設計に反映されました。

新しい手法では、単一の JobTracker を使用するのではなく、クラスター・マネージャーを導入します。クラスター・マネージャーの唯一の役割は、クラスター内のライブ・ノードと使用可能なリソースを追跡して、タスクに割り当てることです。クラスターに対して実行依頼されたジョブごとに、短時間だけ存続する専用の JobTracker が開始されます。この専用 JobTracker は、そのジョブの範囲内でのみタスクの実行を制御します。面白いことに、短時間存続する JobTracker は、スレーブ・ノード上で実行される TaskTracker によって開始されます。従って、ジョブのライフサイクルの調整は、クラスター内で使用可能なすべてのマシンに分散されます。この動作により、さらに多くのジョブを並列に実行できるため、スケーラビリティーが劇的に向上することになります。


YARN: 次世代の Hadoop 計算プラットフォーム

まず、これまでに使用した用語を少し変更させてください。次のように呼び名を変更することで、YARN の設計に対する理解が少しは深まるはずです。

  • クラスター・マネージャーではなく、ResourceManager と呼びます。
  • 短時間存続する専用の JobTracker は、ApplicationMaster と呼びます。
  • TaskTracker ではなく、NodeManager と呼びます。
  • MapReduce ジョブではなく、分散アプリケーションと呼びます。

YARN は、以下の図に示す次世代の Hadoop 計算プラットフォームです。

YARN のアーキテクチャー
YARN のアーキテクチャーを示す図

YARN のアーキテクチャーでは、グローバル ResourceManager が通常は専用マシン上でマスター・デーモンとして実行されます。このマスター・デーモンは、使用可能なクラスター・リソースを各種の競合するアプリケーションの間で調停します。ResourceManager は、クラスター上で使用可能なライブ・ノードの数とリソースを追跡して、ユーザーが実行依頼したアプリケーションのうち、どのアプリケーションにどのタイミングでリソースを割り当てるかを調整します。ResourceManager は、この情報を保有する唯一のプロセスであるため、リソースの割り当て (むしろ、スケジューリング) を、共有されたセキュアなマルチテナント方式で決定することができます (例えば、アプリケーションの優先順位、キューの容量、ACL、データの局所性などに従って決定することができます)。

ユーザーがアプリケーションを実行依頼すると、そのアプリケーション内のすべてのタスクの実行を調整する ApplicationMaster と呼ばれる軽量のプロセスのインスタンスが開始されます。このプロセスの役割には、タスクのモニター、失敗したタスクの再開、処理時間のかかるタスクの投機的実行、アプリケーション・カウンターの合計値の計算が含まれます。これらの処理は、以前はすべてのジョブに関して単一の JobTracker に割り当てられていました。ApplicationMaster とそのアプリケーションに属するタスクは、NodeManager が制御するリソース・コンテナー内で実行されます。

NodeManager は、TaskTracker をより汎用的かつ効率的にしたバージョンです。NodeManager は一定数の map スロットと reduce スロットを使用するのではなく、動的に作成される多数のリソース・コンテナーを使用します。コンテナーのサイズは、そこに含めるリソース (メモリー、CPU、ディスク、ネットワーク I/O など) の量によって決まります。現在サポートされているのは、メモリーと CPU (YARN-3) のみですが、将来は cgroups を使用してディスクやネットワーク I/O を制御する可能性が考えられます。ノード上のコンテナーの数は、構成パラメーターと、スレーブ・デーモンと OS の専用リソースを除くノード・リソースの合計量 (CPU の合計とメモリーの合計など) の積です。

興味深いことに、ApplicationMaster はコンテナー内であらゆるタイプのタスクを実行することができます。例えば、MapReduce ApplicationMaster はコンテナーに map タスクまたは reduce タスクの開始を要求する一方、Giraph ApplicationMaster はコンテナーに Giraph タスクの実行を要求します。特定のタスクを実行するカスタム ApplicationMaster を実装して、ビッグ・データの世界を変える、まったく新しい分散アプリケーション・フレームワークを生み出すことができます。ぜひ、YARN をベースに分散アプリケーションを簡単に作成できるようにすることを目的とした Apache Twill について読んでください。

YARN では、MapReduce の役割は単なる分散アプリケーションとなっていて (それでも、非常に評判の高い有用な分散アプリケーション)、MRv2 と呼ばれています。MRv2 は単に、従来の (現在は MRv1 と呼ばれるようになった) MapReduce エンジンを、YARN をベースに実行するように再実装したものです。


あらゆる分散アプリケーションを実行できる単一のクラスター

ResourceManager、NodeManager、およびコンテナーは、アプリケーションやタスクのタイプを問いません。アプリケーション・フレームワークに固有のコードはすべて ApplicationMaster に移されるだけなので、その分散フレームワークに適切な ApplicationMaster が実装されている限り、YARN ではあらゆる分散フレームワークをサポートすることができます。

この汎用の手法のおかげで、多種多様なワークロードを実行する Hadoop YARN クラスターの夢が実現します。想像してみてください。データ・センター内の単一の Hadoop クラスターで、MapReduce、Giraph、Storm、Spark、Tez/Impala、MPI などを実行できるとしたらどう思いますか?

単一クラスターの手法には、明らかに、以下をはじめとする数多くのメリットがあります。

  • あるフレームワークが使用していないリソースを別のフレームワークで使用できるため、クラスター使用率が高くなります。
  • 「すべてに万能」の 1 つのクラスターだけを管理して調整すればよいので、運用コストが低くなります。
  • Hadoop YARN と異なるマシンからなるクラスターで実行されているシステムとの間でデータを移動する必要がないため、データの移動が少なくなります。

単一のクラスターだけを管理する場合、より環境に優しいデータ処理ソリューションにもなります。同じ計算をより小規模な一方でより効率的な Hadoop クラスター上で実行するだけで、データ・センターの使用スペース、シリコンの無駄、電力消費量、二酸化炭素排出量が削減されます。


YARN でのアプリケーションの実行依頼

このセクションでは、アプリケーションが YARN クラスターに実行依頼されてから、ResourceManager、ApplicationMaster、NodeManager、およびコンテナーがどのように相互作用するかを説明します。以下の図に例を示します。

YARN でのアプリケーションの実行依頼
YARN でアプリケーションを実行依頼するときの様子を示した図

ユーザーが MRv1 での場合と同じように hadoop jar コマンドを入力して、ResourceManager にアプリケーションを実行依頼するとします。ResourceManager は、クラスター上で実行されているアプリケーションのリストと、ライブ NodeManager ごとの使用可能なリソースのリストを保持しています。ResourceManager に必要とされるのは、次にどのアプリケーションにクラスター・リソースの一部を割り当てるかを決定することです。この決定には、キューの容量、ACL、公平性など、多くの制約が適用されます。ResourceManager が使用するプラガブル・スケジューラーは、スケジューリングだけに対処します。つまり、どのアプリケーションにどのタイミングでクラスター・リソースを (コンテナーという形で) 割り当てるのかを管理しますが、アプリケーション内のタスクをモニターしないので、失敗したタスクの再開を試行することはありません。

ResourceManager が新しいアプリケーションの実行依頼を受け入れたときにスケジューラーが最初に行う決定の 1 つは、ApplicationMaster を実行するコンテナーの選択です。ApplicationMaster が開始されると、その ApplicationMaster が、このアプリケーションのライフサイクル全体の責任を負います。その責任として、何よりも先にリソース要求を ResourceManager に送信して、アプリケーションのタスクを実行するために必要なコンテナーを要求します。リソース要求とは、次のようなリソース要件を満たす数多くのコンテナーに対する単なる要求です。

  • リソースの量。最近は、メガバイト単位のメモリーと CPU の共有数として表現されます。
  • 優先ロケーション。ホスト名、ラック名、または「*」(優先ロケーションがないことを表しています) で指定されます。
  • このアプリケーション内での優先順位。複数のアプリケーションの間での優先順位ではありません。

可能な場合、ResourceManager は、リソース要求で ApplicationMaster が要求した要件を満たすコンテナー (コンテナー ID とホスト名で表されます) を割り当てます。コンテナーが割り当てられることにより、アプリケーションは指定された量のリソースを特定のホスト上で使用することができます。コンテナーが割り当てられた ApplicationMaster は、(そのコンテナーの割り当てが行われたホストを管理する) NodeManager に、これらのリソースを使用してアプリケーション固有のタスクを開始するように要求します。このタスクは、任意のフレームワーク内で作成された任意のプロセスにすることができます (例えば、MapReduce タスクや Giraph タスクなど)。NodeManager はタスクをモニターしません。NodeManager がモニターするのはコンテナー内のリソース使用量だけで、例えばコンテナーが最初に割り当てられた量を超えるメモリーを使用する場合、そのコンテナーを kill します。

ApplicationMaster はアプリケーションを完了する上で必要なすべてのタスクを開始するために、その存続期間全体をコンテナーのネゴシエーションに費やします。また、アプリケーションとそのタスクの進行状況をモニターし、失敗したタスクを新しく要求されたコンテナーの中で再開し、進行状況をそのアプリケーションを実行依頼したクライアントにレポートします。アプリケーションが完了すると、ApplicationMaster は自身をシャットダウンして、所有するコンテナーを解放します。

ResourceManager はアプリケーション内のタスクを一切モニターしませんが、ApplicationMaster の正常性はチェックします。失敗した ApplicationMaster は、ResourceManager によって新しいコンテナーの中で再開することができます。つまり、ResourceManager が ApplicationMaster を管理し、ApplicationMaster がタスクを管理すると言えます。


興味深い事実と機能

YARN には他にも素晴らしい機能があります。この記事では、そのすべてを説明することはしませんが、いくつか注目に値する機能を記載しておきます。

  • 「Uberization」は、ApplicationMaster の JVM に収まる大きさの MapReduce ジョブであれば、 JVM 内でそのジョブのすべてのタスクを実行することができます。この場合、ResourceManager にコンテナーを要求して、NodeManager に (おそらく小さい) タスクを開始するように要求するオーバーヘッドが回避されます。
  • MRv1 を対象に作成された MapReduce ジョブのバイナリーまたはソースとの互換性 (MAPREDUCE-5108)
  • ResourceManager の高可用性 (YARN-149)。この取り組みは進行中ですが、一部のベンダーではすでに完了しています。
  • ResourceManager 再開後のアプリケーションのリカバリー (YARN-128)。ResourceManager は、実行中のアプリケーションと完了したタスクに関する情報を HDFS に保管します。ResourceManager が再開された場合、ResourceManager はアプリケーションの状態を復元して、完了していないタスクだけを再実行します。この取り組みは、完成間近であり、コミュニティーによるテストが活発に行われています。一部のベンダーでは、この取り組みをすでに完了しました。
  • 単純化されたユーザー・ログ管理およびアクセス。アプリケーションによって生成されたログは、(MRv1 でのように) 個々のスレーブ・ノード上に残されませんが、HDFS などの中央ストレージに移動されます。そのため、後でログをデバッグや履歴分析のために使用して、パフォーマンス上の問題を見つけることができます。
  • Web インターフェースの新しいルック・アンド・フィール。

まとめ

YARN は、完全に作成し直された Hadoop クラスターのアーキテクチャーであり、一般商品化されたマシンのクラスターに分散アプリケーションを実装して実行する方法に大改革をもたらすアーキテクチャーとなりそうです。

最初の Hadoop バージョンでの従来の MapReduce エンジンに比べ、YARN にはスケーラビリティー、効率性、柔軟性という点で明らかに勝っています。Hadoop クラスターはその規模に関わらず、YARN から多大な恩恵を得ることができます。エンド・ユーザー (管理者ではなく開発者) には、YARN がもたらす変更は目につきません。それは、同じ MapReduce API および CLI を使用して、MapReduce ジョブを変更せずに実行できるためです。

MRv1 から YARN へ移行しない理由はありません。最大級の Hadoop ベンダー各社では、この点に同意して、Hadoop YARN の実行を広範にサポートしています。現在、YARN は、Yahoo!、eBay、Spotify、Xing、Allegro などの多数の企業で本番環境に使用されて功を奏しています。


謝辞

この記事のテクニカル・レビューで協力してくださった Piotr Krewski 氏と Fabian Alenius 氏に感謝いたします。

参考文献

学ぶために

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

議論するために

コメント

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=ビジネス・アナリティクス
ArticleID=974450
ArticleTitle=YARN の紹介
publish-date=06262014