2013年10月にHadoop 2.2が正式リリースされて以来，Hadoopの世界は大きく変わりました。それまでの概念である「Hadoop＝ HDFS＋MapReduce」が刷新され，MapReduceが受け持っていたMapデータ処理とクラスタリソース管理が分離できるようになりました。これにより，SparkなどMapReduce以外のデータ処理エンジンがHadoop上で利用可能になりました。

そしてHadoopのクラスタリソース管理を行うミドルウェアとして，新たなデファクトスタンダードの地位を確立しようとしているのが「Apache Hadoop YARN（Yet Another Resource Negotiator： YARN⁠）⁠」です。YARNの登場は並列分散処理にどんな変化をもたらすのでしょうか。本稿では2月8日に行われた「Hadoop Spark Conference Japan 2016」での小沢健史氏（Hadoopコミッタ／PMC，NTTソフトウェア イノベーションセンタ）によるセッション「YARN： 分析プラットフォームのためのリソース管理基盤」の内容をもとに，YARNがナビゲートしようとしている世界を覗いてみたいと思います。

データ分析基盤の分離とスケーラビリティ確保のために

前述したようにYARNとは，Hadoopクラスタを構成するリソースの管理を行うミドルウェアであり，Hadoopを構成するコンポーネントのひとつです。小沢氏はYARNが提供する機能として，以下の3つを挙げています。

1. 計算機クラスタ内におけるリソース管理
2. YARNアプリケーションの実行履歴の表示
3. YARN上で動作中のサービスの場所を知るためのしくみ（サービスレジストリ）

YARNが登場してきた背景には，バッチ処理やマシンラーニングなど，データ分析の目的ごとにデータの処理基盤を切り替えて使い分けたいというニーズがありました。小沢氏は例としてGoogleの事例を紹介，「⁠Googleでは，バッチ処理にTenzingやMapReduceを，SQLにはBigQueryを，マシンラーニングにはTensorFlowを利用している」と説明しています。

こうしたデータ分析基盤を使い分けたいというニーズに対し，「⁠処理基盤ごとにクラスタを分ける」と「処理基盤を（1つのクラスタ内に）同居させる」という2つの方法を取ることが考えられます。前者の場合はリソースの分離を簡単に行うことができますが，クラスタ間でデータを同期させる必要が生じます。後者は逆にデータの同期は不要ですが，今度はリソースの分離が難しくなります。

ではYARNは設計方針としてどちらの手法をとっているのでしょうか。小沢氏は「Hadoopは巨大なデータを処理するためにスケーラビリティ重視で設計された。したがってHadoopのコンポーネントであるYARNもHadoopと同様，スケーラビリティを重視している。そのためデータは動かさず，複数のデータ処理基盤を1つのクラスタ内に同居させる選択をしている」と，Hadoopのスケーラビリティ重視という特徴に沿っていることを強調しています。

もともと，YARNはHadoop開発の中心企業でもあるYahoo!の「MapReduceでは大規模処理（4000台級）に対応しきれず，スケールしない。処理系のマスタをジョブごとに立ち上げたい」という要望から生まれました。Yahoo!では3万6000台を超えるマシンで構成されたHadoopクラスタが稼働していましたが，この規模になるとマスタ（JobTracker）の仕事量が多くなりすぎて，スケーラビリティに深刻な問題が生じます。マスタの仕事を減らし，クラスタ内の個々のスレーブ（TaskTracker）に割り振ることで，ジョブの並列実行を増やし，スケーラビリティを向上させる ─YARNの設計思想の中心にあるのはHadoopと同様，「⁠スケーラビリティ」であることがわかります。

YARNを支える3つの機能，今とこれから

YARNのリソース管理

YARNではマスタとしてResourceManagerがクラスタ全体のリソースを管理し，スレーブであるNodeMangerが計算機ごとのコンテナを管理します。アプリケーションの実行依頼があると，ResourceManagerがNodeManager上にコンテナを確保し，アプリケーションの要求に応じてリソースを割り当て，NodeManagerがそのアプリケーションのライフサイクルを管理します。MapReduceもYARN上では分散アプリケーションのひとつとして，スレーブ内のコンテナ上で実行されることになります。

小沢氏はここで，YARNにおけるリソース管理の課題として「割り当てられたコンテナのリソースがすべて使いきれているとは限らない」を挙げています。YARNでは，アプリケーションの実行依頼ごとにジョブがキックされますが，その際，実行環境としてジョブがResourceManagerに要求するリソースは「全部使い切るとは限らない，最大値の要求であるため，すこしずつリソースが余る」（⁠小沢氏）ことになりやすいのです。小沢氏は「過剰なリソースの割当は個人的にとても課題意識をもっている部分。たとえば割り当て済みのCPUリソースを見て，意図しないで暴走するタスクがあらわれるかもしれない」として，その解決策としてYARNコミュニティにおいて「割り当て済みのコンテナをすべてモニタリングし，リソースが空いているようならコンテナ容量を超過してコンテナを動作させる」という提案がなされていると紹介しています。リソースの適切な割り当ては，今後のYARN開発にとって引き続き重要なテーマだといえます。

バージョン2で変わる！ 履歴管理

YARNの2つめの機能である履歴管理として，Timeline Serverの説明がありました。Timeline ServerはYARN上で実行中，もしくは実行完了したアプリケーションの情報を保存／閲覧するサーバです。アプリケーションの履歴を参照することで，パフォーマンスチューニングやデバッグに活用することが可能になります。履歴として保存されるデータは

1. YARNアプリケーションすべてに共通な情報 … 割り当てられたコンテナ数，キューの名前など
2. 各YARNアプリケーション固有の情報 … MapReduceならMapper/Reducerのカウンタ数やシャッフル量など

の2種類がありますが，YARNのパッケージに含まれるTimeline Serverで閲覧できるのは1．の汎用的な情報だけです。小沢氏はTezに含まれる，きめ細やかな表示が可能なTez-UIを使うことで「たとえばMapタスクがどのくらい利用されているのかなどを詳細にチェックするといったリッチな性能解析が可能になる」と紹介しています。

現在のTimeline Serverは「アプリケーションの数が増えても問題なく動作すること，ビューワが作成しやすいようにRESTful APIをもつこと」（⁠小沢氏）を前提に設計されています。「⁠バージョン1（V1）ではバックエンドストレージはプラガブル（デフォルトはLevelDB）でWriterとReaderはすべてTimeline Serverが代わりに行っている。一方，開発中のバージョン2（V2）では，バックエンドストレージにスケーラブルなKVSを想定しており，HBaseを主眼に置いて開発されている。WriterとReaderも異なり，分散書き込み／読み込みに対応する。またAPIの劇的な変更もあり，複数のジョブをまたがったプロファイリングや情報の保存／取得が可能になる」（⁠小沢氏⁠）⁠。

なお，Yahoo!ではすでに「バックエンドでHBaseを運用しており，彼ら専用にチューニングしたTimeline Serverが開発中」（⁠小沢氏）とのこと。それらの成果もV2移行で取り入れられることもありそうです。

サービスレジストリ

3つめの機能であるサービスレジストリですが，この機能があることで，クライアントは簡単にデプロイ済みのアプリケーションに接続することが可能になります。「⁠アプリケーションがどのポートで動いているか，ResourceManagerがZooKeeperに登録し，クライアントはZooKeeperに問い合わせることで書き込み先を把握，ダイレクトにアプリケーションに接続できる」と小沢氏。どちらかというと開発者のための機能であり，YARN上でHBaseを使うケースなどで威力を発揮します。