アップグレードと異なるプログラミングパラダイムのためのHadoop再設計

作者 Ron Bodkin , 翻訳者 徳武 聡 投稿日 2011年2月23日

セクション

エンタープライズ・アーキテクチャ,

運用/インフラ,

プロセス/プラクティス,

設計/アーキテクチャ,

デベロップメント

トピック

Java ,

クラスタリング&キャッシング ,

言語 ,

データベース設計 ,

Architecture ,

プログラミング ,

データベース ,

パフォーマンス&スケーラビリティ ,

アナウンス ,

Yahoo! ,

グリッドコンピューティング ,

Hadoop

共有 |

原文(投稿日：2011/02/18)へのリンク

Yahoo! Hadoop Map-Reduce開発の指導者であるArun Murthy氏はHadoopのMap-Reduceのアーキテクチャの中核部分を再設計し、簡単に更新でき、より多くのクラスタで動作し、高速回復をサポートすることを発表した。また、Map-Reduce以外のプログラミングパラダイムもサポートする予定だ。再設計されることでMap-Reduceを制御するHadoopの中核部分はリソースマネージャに切り出される。このリソースマネージャがさまざまな分散処理のパラダイムをサポートする。また、Map-Reduceはユーザが利用できるライブラリになるので、同じクラスタで複数のバージョンのMap-Reduceコードを実行できるようになる。新しい設計はクラスタマネジメントプロジェクトであるオープンソースのMesosに似ている。Yahoo!とMesosは両者の違いと利用機会についてコメントした。

新しいアプローチの主な利点は、

• 拡張性: 16コアの6000のマシンクラスタと48GBのRAM、48TBのディスク、100000の同時実行タスク、10000の同時実行ジョブ。
• 可用性: 現時点ではJob Trackerが単一障害点になっている。また、更新するにはクラスタ全体を停めて更新しなければならない。
• s敏捷性: 新しい設計ではMap-Reduceをユーザライブラリとして利用できるので、異なるバージョンの処理が必要なジョブを同じクラスタで実行できる。
• 遅延の削減: 新しい設計では、とりわけ小さな規模のタスクの場合、より素早いレスポンスを返す必要がある。
• 利用性改善: リソースとスケジューリングのモデルをより精巧にすれば、競合なしでリソースの無駄を削減できる。
• プログラミングモデルの選択肢: YahooはMPIのような他のパラダイムへの対応を要求されている。

再設計で最も重要なのは処理の責務を、汎用的なクラスタリソース管理システムと、Map-Reduceや他のプログラミングモデルをサポートする独立したアプリケーションマスタのふたつに分割することだ。Job TrackerとTask Trackerはこのふたつに置き換えられる。リソース管理システムは下記のクラスタ全体を制御するコントローラから成る。

• クラスタ全体のメモリやCPU、ディスク、ネットワークなどのリソースをスケジューリングするリソースマネージャ。
• リソースマネージャにさまざまなポリシーを設定するためのスケジューラプラグイン(現在のスケジューラAPIと似ているが、インターフェイスが違うので利用するには新しく実装する必要がある)
• リソースを要求したり、進捗を追跡したり、エラーハンドルや処理状態を管理する、アプリケーション(Map-Reduceのプログラム programming)毎にひとつのアプリケーションマスタ

Yahooによる次世代MapReduceアーキテクチャ

ワーカーノードを超えて動作するのは、

• ノードのリソースにアクセス(例えば、認証されたリクエストでのアクセスやタスクを始めるためのアクセス)できる共有ノードマネージャ
• 処理を実施するためのローカルリソースを利用するアプリケーションごとのコンテナ

• 高可用性。クラスタの状態を保持するためにZooKeeperを使う。ZooKeeperを使うことで高速のフェイルオーバを実施してリソースマネージャをバックアップできる。アプリケーションマスタはHDFSに状態を保持することができる。例えば、Map-Reduceのアプリケーションマスタは状態を保存し、クラッシュしてしまった時は迅速に復旧できる。
• しっかりと定義されたワイヤプロトコルを使った後方互換。クラスタ内のリソースマネージャとノードマネージャを徐々に更新できる。また、同時にMap-Reduceや他のプログラミングパラダイムを使った異なるバージョンの処理を実行できる。氏によれば、Yahoo!の研究者はMPI、Master-Worker、繰り返しモデルのようなMap-Reduce以外のプログラミングモデルを実行している。このような取り組みがHadoop Online Prototypeのようなプログラミングモデルに革新をもたらすだろう。
• 利便性改善。CPUやディスクなど基本的なリソースを概念化したモデルに固定されたMapとReduceのスロットを置き換える。これによってリソースの無駄遣いや競合を避けられる。

続いてArun Murthy氏は、この仕組みはリソースの限度を強制するコンテナとしてLinuxは使わないと言った。テストした結果、オーバヘッドが多発してしまったからだ。しかし、サンドボックスではLinux cgroupsを利用するつもりだ。コンテナプロセスが必要最小限のリソースのみ利用するようにするためだ。こうすることで局所的で繊細なリクエスト(例えば、マシン上やラック上のタスクを実行する)が行える。また、Map-Reduceの局所性も保持できる。これはMap-Reduce以外のプログラミングパラダイムでも必要だ。Map-Reduceのシャッフル段階を支援するため、ノードマネージャはリモートタスクがディスク上のローカルデータを読むためのリモートリクエストを発行できるようにする。初期段階ではMap-ReduceのReduceコンテナは単一のノードマネージャから分離されなければならない。そのノード上で実行される各Mapタスクのためだ。こうすることで処理がより効率的になる。将来的には、シャッフルの効率をさらに良くするために、ひとつのノードやラックにあるMapタスクのデータをすべてまとめてソートする合体処理を実現したいと氏は言う。

氏によれば、この技術はまだプロトタイプ段階だ。Yahoo!は今年、この技術を展開してより多くのクラスタを配置したいと思っているが、スケジュールは内部のコードリリースとApache Hadoopのリリースとの調整に依存する。氏がこの技術をFebruary Bay Area Hadoop User Groupで発表すると、MapR TechnolgiesのTed Dunning氏が、Mesosはすでにこれらの特徴を実現しているのではないか、と質問した。Murthy氏はこの質問に答えて、MesosはMap-Reduceを実行するのにJobTrackerもTaskTrackerも必要だが、発表した新しい技術はJobTrackerとTaskTrackerを不要なものにする、と説明した。この件に関して、InfoQはMesosチームにコメントを求めた。

このMapReduceのリファクタリングの最大限利用するには複数のリソースマネージャが新しいMapRedceをサポートする必要があると思います。これはMesosのためだけではありません。Hadoopの利用者はSun Grid Engine、LSF、Condorなどの上でHaddopを実行させたがるのが普通だからです。一般的なアプリケーション向けのリソーススケジューリングはMapReduceを実装するより難しいです。実現するには多くの実験とさまざまなシステムが必要でしょう。Yahooのこの取り組みはHadoopをMesos上で動かすのを簡単にしてくれるかもしれません。... いずれにせよ、私たちはHadoopの支援を続けます。

...私たちは引き続きMesosを強力なシステムに育てていくつもりです。この点で私たちが有利なのは、Mesosを隅から隅までビルドし続けているということでしょう。単なるデータ処理以上のアプリケーションを実行するためです。Twitterでは私たちはもっと一般的な目的の"サーバ"を毎日、アプリケーションのように実行しています。

このYahooが提案するHadoopアーキテクチャとMesosの違いについて尋ねたところ、Zaharia曰く、

...大きな違いのひとつはMesosマスタ内の状態管理ですね。Mesosではアプリケーションに自分のスケジューリングをさせ、マスタは現在動いているアプリケーションと実行中のタスクの状態を保持するように設計しました。マスタはまだ起動されていないアプリケーションのペンディングになっているタスクを感知する必要はありません。... 私が理解した限りではYahooの次世代Hadoopの設計では、マスタはZooKeeperを使ってペンディングになっているすべてのタスクの一覧を保持するようです。さらにZooKeeperを使うことで管理しなければならない状態が増えます。また、違いは技術的なこと以外でもあります。Mesosは最初からMapReduce以外のフレームワークをサポートしていて、MPIや長期間実行するサービス、Sparkという名のインメモリ並列処理システムのために使っています。最後の違いは実践的なものです。すなわち、MesosはHadoop 0.20(パッチを含む)で利用できます。新しいHadoopのリリースを待つ必要はありません。

InfoQはEric Baldeschwieler氏に話を聞いた。氏はYahoo!でHadoop開発のVPを務めている。このプロジェクトの由来とMesosとの違いについてより詳しく聞くためだ。クラスタスケジューリング機能を提供するプロジェクトは数多くあり、その中にMesosも含まれているが、既存の選択肢は Yahoo!が指摘したMap-Reduceの問題点を解決できないと思っている、と氏は言う。他の選択肢は新しすぎたり、まだ未熟であったり、成熟していても肝心な機能が無かったりする。次世代Map-Reduceの設計は世界最大の Hadoop環境 を運用していた数年の経験を盛り込まれる。また、Yahoo!のMap-Reduceの日々の改善の結果でもある。

Mesosは素晴らしい仕事だが、と氏は言う。Yahoo!が欲しかったのはメタレイヤではなくてHadoopに統合されたコンポーネントだ。もちろん、次世代MapRedeceの設計は数年に渡って行われ、Yahoo!チームはMesosチームと協力している。MesosチームのHadoopに対する貢献は大歓迎であり、MesosのHadoopとのよりしっかりとした統合を支援できればうれしい、と氏は言う。Yahoo!は過去、外部で開発されたHadoop技術を取り入れた。そしてこの技術はHBaseやHiveのようなコミュニティが生まれるほど価値のあるものだった。

Hadoopのエコシステムが複数のプログラミングパラダイムをサポートし、拡張性、信頼性、効率性を実現したときの動きを見るのは興味深いことになるだろう。