レポート

「Hadoop/Spark Conference Japan 2016」で小沢健史PMCが語った“YARNのいま”

この記事を読むのに必要な時間:およそ 3.5 分

YARN上の新たな分散処理基盤 ─DAG

冒頭でも触れたとおり,YARNが実装されたことにより,TezやSpark,FlinkなどMapReduce以外の並列分散処理基盤がいくつも登場してきました。小沢氏はこれらのミドルウェアの特徴として「MapReduceより汎用的で記述性が高い」ことを挙げています。そしてこれらの分散処理基盤でキーワードとなるのが「DAG(Directed Acyclic Graph: 非循環有向グラフ⁠⁠」です。これはMapReduceのかつてのライバルだったMicrosoftの「Dryad」が採用していたアーキテクチャでもあります。

MapReduceでは,Map - Shuffle - Reduceといった一連の操作においてひとつの処理が終わるまで次の処理を始めることができません。Shuffleが終わるまでReduceは実行できず,Reduceが終わるまでは次のジョブは開始できません。またHDFSに絶対に書き込むことが求められます。これは並列処理という面では非常にマイナスです。

DAGの概要

DAGの概要

一方,DAGではMap - Map - Reduceのような,以前であれば複数のMapReduceジョブで表現していた処理を単一のクエリで表現することができます。そしてSparkのような「モダンな並列分散処理基盤」は基本的にDAGを用いたジョブの記述が可能で,その上でそれぞれにプラスアルファの特徴があります。

Tez
DAG+ディスク最適化+低レイテンシ用最適化機構+インタフェースはHive/Pig/Spark/Flinkなどを想定
Spark
DAG+低レイテンシ実現のためのインメモリ計算機構+関数型言語ライクなインタフェース
Flink
DAG+独自のシャッフル機構+ストリーミング処理とバッチ処理等価なインタフェース

しかし,これらの並列分散処理基盤をYARNで実装する上ではもちろん課題もあります。小沢氏は,ジョブの立ち上げに時間がかかること,そしてウォーミングアップに時間がかかることを挙げており,⁠Tez,Spark,FlinkはJVMで動作するため,この問題が起こりやすい」と指摘します。

ではこれらの課題に対し,どういった工夫がなされているのか。小沢氏はTezとSparkについてそれぞれ説明しています。

まずTezについて。Hiveなど高級言語によるインタフェースでのバッチ処理を前提に設計されたTezは,もともと遅延よりも処理スループットを重視していました。そのため,コンテナは処理が終われば手放すように設計されていたのですが,コンテナの再利用を図ることで,ひとつのコンテナでMapもReduceも実行できるようなしくみが追加されました。ジョブ実行時,可能な限り計算リソースを手放さずに再利用し,ジョブが完了してもセッションが切れない限りリソースを確保できています。またセッションとは関係なく「デーモンとしてすべてのマシンに立ち上げっぱなし」⁠小沢氏)のHive用コンテナを利用する「Long Lived and Process」というしくみにより,ウォームアップ済みのJVMやファイルキャッシュが利用できるので,高速処理が可能になっています。

Sparkにおいては,現在YARNにおける動作モードとして

yarn-clusterモード
ジョブを投入する:YARNコンテナ上でSparkドライバを起動
yarn-clientモード
対話式の実行形態を想定:クライアント側でSparkドライバ

の2つが存在します。とくにSparkは対話式プログラミングに強いため,Tezのコンテナ再利用レベルの機能はすでに導入済みとのこと。しかしインメモリ型の処理機構であるSparkは「コンテナを終了できない(インメモリが消えてしまう⁠⁠」という事情があるため,計算リソースを使っていなくても手放すことができないという状態に陥ることになり,結果としてリソース利用率の低下を招きます。

yarn-clusterモードとyarn-clientモード

yarn-clusterモード

yarn-clientモード

この対策としてSpark 1.2からワークロードに応じてコンテナを動的に確保/削除する方法が取られています。タスクが残っている状態で一定時間以上経過したら,アイドル状態のコンテナを開放するというしくみですが,中間データはNodeManagerのシャッフルサービスで永続化するため,インメモリのメリットは薄くなるという欠点もあります。

Sparkの動的リソース管理

Sparkの動的リソース管理

TezもSparkも互いに最適化することで,低レイテンシと高スループットの両立を目指しており,開発がすすむにつれ,幅広いニーズに応えられる処理系に成長することが期待されています。


HadoopのリソースマネージャとしてはYARNのほかにもうひとつ,Apache Mesosが存在します。講演終了後,YARNとMesosの関係に小沢氏に伺ったところ「両方ともHadoopのリソースマネージャとして,統合する動きも一部あるが,現在は棲み分けられている状態。TezやSparkなどHadoop系の処理基盤との連携が多いのはYARN。MesosはPaas基盤,そしてSpark Streamingでの事例が増えている」とのこと。両者ともに究極的なゴールはデータセンターにおけるリソース管理を行うというものですが,そのプロセスはそれぞれに異なっているようです。

"Yet Another"という言葉通り,つねにひとつ先の未来を志向しているYARN。小沢氏をはじめとするコミッタ/PMCと多くの開発たちの手によって,YARNリソース管理基盤からデータセンターOSへと確実に進化の階段を上っているようです。

著者プロフィール

五味明子(ごみあきこ)

IT系の出版社で編集者としてキャリアを積んだ後,2011年からフリーランスライターに。フィールドワークはオープンソースやクラウドコンピューティング,データアナリティクスなどエンタープライズITが中心。海外カンファレンス取材多め。Blog 「G3 Enterprise」やTwitter(@g3akk),Facebookで日々IT情報を発信中。

北海道札幌市出身/東京都立大学経済学部卒。