8月4日、六本木ミッドタウンのヤフー株式会社にて、今回で2回目となるHadoopをテーマにしたイベント「Hadoop Hack Night Vol.2」が開催された。

Hadoop（ハドゥープ）は、いま注目のクラウドコンピューティングなどに利用されているMapReduce技術が使えるオープンソースソフトウェア。大規模なデータの解析処理などに分散システムを利用したい場合に大きな力を発揮する。

このように注目を集めているHadoopだが、実際に数テラバイト以上といった大容量のデータを処理しなければならないケースはまだそれほど多くない。大きな期待を集めながら「生きた実例」に乏しいのもHadoopをめぐる1つの状況だろう。そこで、今回の「Hadoop Hack Night Vol.2」は「ケーススタディで知るHadoopの可能性」と題して、実際に導入実績をもつベンダの技術者に導入事例を元にしたHadoopのメリットや現状の課題を語るセッションとなった。

オープニングセッション：Yahoo! JAPANにおけるHadoop利用について

最初のセッションは、Hadoop開発のお膝元。Yahoo! Japanの技術者による発表。第1回に続いて登場のヤフー（⁠株⁠）R&D統轄本部の吉田一星氏が、まずYahoo! JapanでのHadoopの利用方法について簡単に紹介を行った。

Yahoo検索サービスでは、検索ログプラットフォームにHadoopが利用されている。検索ログから各種サービスに関連するデータを取り出す際に使われるもので、Hiveを改造したソフトウェアを使ってデータを取り出しているという。この検索ログプラットフォームを使い、たとえば検索サービスの関連検索ワード、「⁠急上昇ワードランキング」の計算や、都道府県別、世代別の検索ランキングの抽出などが行われている。レコメンデーションプラットフォームにもHadoopを使い、YBBポータルサイトなどで利用されている。こうした仕組みはオークション、ショッピングにも展開予定とのこと。

またモバイル検索では、検索データを溜めるストレージとしてHadoopが使われ、検索ランキングの計算などに利用されている。さらに、地図検索では、検索結果の住所の中でどれを一番上表示させるかといった処理や、同じ店舗やビルの一意性を保つための処理にもHadoopが使われるという。

Hadoopを使った開発

次に、これらのシステムの開発の流れについて説明があった。

「ABYSS」というのが、ヤフー社内の検索サービスをホスティングするプラットフォームで、このシステム内の検索データのストレージとしてHadoopが使われ、解析などにMapReduceを使っている。Hadoopはクライアント／サーバ型で運用することで、他のサーバにあるHadoopクラスタのファイルへのアクセスやジョブの実行が簡単に行えるという。Hadoop Serverは開発用、検証用、本番用クラスタが用意され、それぞれHadoop Clientを使って別サーバからJobの実行やファイルの転送を行う。ファイルの転送にはHTTPのGETなどの機能を使う場合もある。

開発はJavaのみで行われており、開発環境はEclipseにHadoop Clientが入った状態になるEclipse Pluginを組み込んで使用する。この環境から開発用のHadoopクラスタにジョブを実行させる。またVMwareを使って仮想サーバ上にHadoopクラスタを立ち上げる場合もあるとのこと。

こうした構造で利用する場合、Hadoop ServerへのアカウントがなくてもHadoop Clientを使ってどこからでもデータにアクセスすることができ、セキュリティ上の問題が発生してくる。これについては、現在はネットワークポートのアクセス制限や、利用者に誓約書を書いてもらうなど、外部の手段を使って対応している。

これに関連して、Hadoopの実行ユーザ、グループアカウントが基本的にUNIXなどのログインアカウントが使われている点、Hadoop Clientの設定でこれとは別に任意のユーザアカウントを設定することもできる点などが指摘された。

Hadoop with Security＋Oozie

セキュリティの話題を受け、スピーカを同社R&D統轄本部の古宮陽明氏にバトンタッチして、Hadoopのセキュリティ機能の現状とYahoo! Japanにおける対応が紹介された。

まずHadoopの現状として、ユーザ、ノードレベルでの認証がなく、ファイルシステムであるHDFSのパーミッションのみ。ただしこれも認証の必要はないのでなりすましが可能である。サービスレベルのアクセス制御も不完全で、こちらもなりすましが可能とのこと。ホストやネットワークレベルのセキュリティ対策はこれに関係なく必要である。

Hadoop with Securityは、Hadoopに認証、認可、監査の機能が追加されたYahoo!によるセキュリティ強化版のHadpoopである。現在はまだベータ版で動作が不安定なため、セキュリティ機能はオプションとなっており、有効にしなければ使えない。仕様もこれから変更される可能性があるとのこと。

Oozie（ウージー：ビルマ語で「象使い」の意）は、Yahoo!開発によるHadoopのアクションフローを管理できるワークフローエンジン。今後Hadoop with Securityと連動予定のバージョンがApacheに移管される予定となっている。

これらを組み合わせることにより、Hadoopへのアプリケーションのアップロード、ジョブの発行などの操作で、OozieをHadoopのProxyとしてふるまわせることができ、プロセスユーザの変更、Kerberosによるプロセスの相互認証、Token認証などをきめ細かく制御できるようになるという。

さらに、これらを導入した全社規模の「Yahoo! Japan Hadoopクラスタ」を構築する予定があるとのこと。現行Hadoopを使っている機能別クラスタを超えた規模のもので、2011年4月に運用開始を目標としている。

メインセッション：新たな情報インフラとしてのHadoopの活用

続いてのセッションは、Hadoopを実際に導入した事例を数多く手がけている（⁠株⁠）リッテル 上席研究員で東京大学情報基盤センターで助教を務める清田陽司氏が登壇。Hadoopを効果的に活用するために押さえておきたい知識を、実際に導入した際の経験を元にわかりやすく紹介した。

同社は日本でも多くのHadoop導入経験を持つが、RDBMSとの違いがわからないといったHadoopへの認識の低さや誤解がHadoop導入の「壁」になっていると指摘する。清田氏は、Hadoopはインフラとして理解するのがポイントだと言う。インフラは、外から見えるインターフェースは単純だが、中身は複雑なことを行っている。例として水道を挙げ、UIとしては蛇口のコックをひねって水が出るだけだが、裏では河川などから水を取り、浄水場などを経て配水管理などを行うといったシステムが動いている。同じようにHadoopもインターフェースとしてはファイルの読み書き／管理とバッチ処理の管理だけしか見えないが、裏では各種のプロセスやデーモンが複雑に絡み合って動いていると紹介した。この裏の部分はブラックボックスとして捉え、ファイルシステム（HDFS）とジョブ管理（MapReduce）を理解するだけで良いという。

一方これとは別に、Hadpoopがなぜ必要なのかを理解することも大きなポイントだ。データ量が飛躍的に増大する中、データ処理も定型から非定型に移りつつあり、システムのスケールアウトも必然的に起こってくる。こうした処理は従来のRDBでは賄いきれず、Hadoopのように大量データバッチ処理の高速化に特化し、組織内システム（インハウス）利用を想定したシステムが必要になるのだ。

このように目的がはっきりしているぶん、ある程度の割り切りをもった設計も必要で、優先順位が低い機能は切り捨てられている。ブリュワーの「CAP定理」はC＝Consistency（一貫性、トランザクション⁠）⁠、A＝Availability（可用性、耐障害性⁠）⁠、P＝Partition Tolerance（分割耐性、スケールアウト性能）の3つを同時に満たすことは不可能であるとしているが、これに当てはめて考えると、HadoopはAとPを満たすがCを満たさない、RDBMSはCとAを満たすがPを満たさないと言える。こうした特性を見ると、Hadoopが既存のインフラとは目的が異なっていることがわかるだろう。既存のインフラをそのまま置き換えるものではないのだ。清田氏はこれを「高速道路は一般道路の代わりにはならない」と例えた。

そして、Hadoopの利用が効果的な例として、大量のテキストデータを継続的に解析する、たとえばブログ検索の急上昇ワードの抽出や、「⁠時空間上のバスケット解析」と呼ばれる2次元上のデータと時間軸のデータを混ぜ合わせた解析を挙げた。時空間上のバスケット解析は、たとえば「あるキーワードで検索してから10分以内に訪れたURLを抽出する」といった分析を指す。

まとめとして、Hadoopは新しいインフラなので、仕組みを伝えようとしてもなかなか難しい。ならば、効果的な利用方法を伝えた方が良いことを強調。また、何にでも使える技術ではなく、得意不得意があるのでそれをきちんと区別することも重要だ。そしてHadoopを単独で使うのではなく、既存の手法と組み合わせることで問題が解決することもある。そして最も重要なのが、こうしてHadoopの特長を伝えていくことで、まだ埋もれているニーズがたくさん掘り出していけるところであると結んだ。

トークセッション：実例で知るHadoopのメリット・デメリット

休憩をはさんで、Hadoopをめぐる現状を語るトークセッションが始まった。パネリストは前のセッションで登壇した吉田一星氏、古宮陽明氏、清田陽司氏に加え、（⁠株）電通国際情報サービスの大谷晋平氏と（⁠株⁠）プリファードインフラストラクチャー CTOの太田一樹氏のお二人。モデレータは（⁠株⁠）技術評論社の馮富久が務めた。

セッションの最初に、来場者に向かって「Hadoopを実際に使ったことのある人は？」と質問をしたところ、約4割程度の挙手があった。前回の「Hadoop Hack Night」に続き今回の申し込みの応募も活発で、予定の募集期間を大幅に切り上げることとなったが、まずはこうしたHadoopをめぐる盛り上がりについて、清田氏はクラウドコンピューティングへの注目がベースにあり「クラウドの上で何を動かすか」に興味が進んでいるのではないかとコメント。吉田氏は「逆説的にいえば」とした上で、Hadoopの性能を十分に発揮できる大規模な事例がないので、少ない「生きた」情報に皆が飢えているのではないかと指摘。大谷氏はこれを受け、Javaエンジニアなどは、今やどんなWebアプリケーションを作る際にも固定したスタックを想定できるようになり、その面での発展はない。むしろバッチ側に発展の余地があると見ている、と解説した。

Hadoopへの具体的な期待として清田氏は、複雑なデータ分析を例に挙げ、「⁠大量にたまったログの解析など、これまで歯が立たなかったところに手が出せるようになった」と述べると、太田氏もこれに同意し「スーパーコンピュータが行っていたような処理がオープンソースでできるようになったのはすごいこと」と語った。大谷氏も「オープンソースでできるということは、これまでパッケージが得意としていた分野に自分が積み上げてきたノウハウが活かせる可能性が出てきた」と期待を口にした。

一方、Hadoopという名前だけが広まった結果、何でもHadoopで解決できるような誤解も生まれつつある。こうした「Hadoopバブル」的な状況については、清田氏が先のセッションでも指摘したようなRDBMSとの違いを指摘する例が各パネリストから紹介された。

また、当然だがHadoopを使うには新たな発想や知識が必要であることも指摘された。大谷氏はSIerが利用する場合は実案件の中でHadoopをどういう位置付けで使うかが重要と語る。ただのログ解析だけでなく並列処理で構造化されたXMLデータなどをどう処理できるか、さらにそれをどのようにサービス化するかまで考えなければならない。清田氏も、ディスクの挙動やジョブのスケジューリングなど、Hadoop以外のシステムでも言えるような話が多く、たとえばWebインターフェースでポーリングして解析するようなジョブだけRDBMSを併用するといった工夫も必要と語る。

太田氏は、Hadoopを構成するクラスタ上のネットワークがボトルネックになったことがあると語る。MapとReduceの間にMapの出力をソートしてReduceに渡す「Shuffle」という処理があるが、このフェーズでネットワークが飽和してしまうことがあり、スイッチなどの調整が必要な可能性が出てくるとのこと。大谷氏がこれを受け、3台～5台といった構成から本番のシステムに移すと特性がまったく変わってしまうので、その検証が重要と指摘。「⁠JavaはJava屋、ネットはネット屋といった垣根を超え、トータルで押さえる知識が必要」と語った。このあたりのハードルの高さも、Hadoopを使う難しさの一因となっているのだろう。

さらに実際に大規模な運用を行うと、予想のつかない問題も出てくる。古宮氏は、これまで各サービスごとに専用クラスタを用意していたが、これからはすべてをまとめた大規模クラスタを組む必要が出てきたため着手をはじめたが、ある程度の大きさを超えるとどうなるのか、米国での例（4000ノード規模）を元に検討中だが、いまだに答えが出せていないという。

この後会場からの質問コーナーとなった。

Hadoopを使うとコモディディ化できて安いサーバを並べて安上がりで済むと思っている客がいるが、こうした誤解を解くには？ という質問に清田氏は、数万円のサーバを使うと消費電力や故障マシンの交換オペレーションによるコストが増え、かえって損になると指摘。「⁠20万円程度のサーバで構成するのがちょうどいいと思う」と述べた。大谷氏も「コモディティ＝安いハード ではない」とし、メモリ、HDD、ネットワークを安くすることはできないとしながらも「どこでも買えるというのは重要、最初は数台のスモールスタートができる」と述べた。

これに関連して、構成ハードの均一化はどの程度必要かについては、太田氏がジョブ自体に並列性あれば、1つのノードが遅くてもバックアップのジョブが代わりに処理してくれると説明し、ノード数とジョブの関係の吸収可能性を紹介した。もっとも、メモリの搭載量は多めに揃えた方が良いようだ。

最初のセッションでも取り上げられたHadoopのセキュリティについても質問があり、バックエンドで使うシステムにセキュリティが必要なのか？ との問いには、吉田氏が「4000ノードを100ユーザが使うような場合にはセキュリティ／ジョブ管理がインパクトとなる」とその必要性を説いた。これによってユーザに対して課金することも可能になると言う。古宮氏も、認証機能によって多くのユーザが使いながらジョブを立ち上げたままにできる点を指摘し、データを投げる入り口で認証をかけるため、共有使用時にだれかがオペレーションミスをしてもその影響で全体のデータが壊れることがないというメリットを挙げた。一方暗号化が考慮されていない点については、扱うデータが大規模な点を挙げ、処理速度を考えると難しいと述べた。

また、認証システムにKerberosという古い仕組みを採用してもいいのか？ との質問があり、これに対して太田氏は、セキュリティ的には問題があるとしながらも、RPC単位での認証処理の重さを挙げ、現時点での実装コスト、処理の重さを考えるとベストであるとコメント。また清田氏はHadoopは「あるべき論」で作られているわけではなく、設計思想に現実的な割り切りがあるとし、その意味ではKerberos採用は自然な選択と述べた。またセキュリティの強化には、Hadoopクラスタ自体を別のレイヤに載せるなど、違う解決方法もあるとした。

Yahooの古宮氏、吉田氏は開発側からのコメントとして、Kerberosに完全に決定したわけではなくあくまで検討中とし、別の認証方式を採用する可能性についても含みを持たせた。また大谷氏は「自分とYahoo!のHadoopの利用想定はかなり違う」とし、そのうえで「実装方法や設計方法、どうしてKerberosを選んだのかを考えることがシステムを作っていく際に非常に役に立つ」と、もっと柔軟な視点で捉えることを提案した。