【セッションレポート】『Best Practices of Running Hadoop on EC2 vol.2』 #cmdevio2015E

Developers.IO 2015

#Amazon EBS

#イベントレポート

#Hadoop

#AWS

渡辺修司

2015.04.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Eトラック最後のセッションは、Hortonworksの蒋逸峰様による「Best Practices of Running Hadoop on EC2 vol.2」です。中国出身の蒋（ショウ）さんは、日本に来て11年目とのこと。日本語で自然に話すことは勿論ですが、花粉症に悩まされるくらい日本に順応されているようです。

今回のセッションでは、Hadoop関連と言うことで、先日のJaws Days 2015でのセッション（Hadoop Trends and Best Practices of Running Hadoop on EC2）で話さなかったコアな部分をお話いただきました。

Hadoopの最新状況

はじめに、Jaws Days 2015でのセッションと同様に、Hadoop界隈での動向などを軽く話していただきました。

Hadoop Trends & Hadoop on EC2 from Yifeng Jiang

最近のHadoop界隈の動向を一言で表すならば、『ここ1−2年はコミュニティも活発化しており、かつて「Hadoopのコレがダメだ」と言われていた様々な問題も概ね解決してきている』とのことです。また、ショウさんが現在所属しているHortonworks社は、アメリカYahooのHadoopエンジニアが中心となって設立した会社です。 Hortonworks社には、Hadoopにコミットしているエンジニアが現時点で165名在籍しているとのこと。ノウハウの蓄積というのは、特にピーキーなプロダクトや複雑なアーキテクチャのプロダクトでは非常に大切です。 AWSのノウハウがクラスメソッドに集積しているように、Hortonworks社には多くのノウハウが蓄積されており、Hadoopで解決したい問題があればHortonworks社にお任せすれば安心という状況なのでしょう。

次世代モダン・データアーキテクチャ（MDA）

現在のHadoopはエコシステムとなっています。その基盤となっているのがHDFS（分散ファイルシステム）です。

そして、HDFSの上でビッグデータを処理するのはYARNです。 Map/ReduceはYARNのひとつであり、当然ながらHadoopの活用方法のひとつです。しかし、どうしてもMap/Reduceはバッチに向いている処理であり、例えばクエリーの実行などには相性が良くありません。データをどう加工したいかによって、Pig, Hive, HBase, Storm, Solr, SparkなどYARNに対応した処理系（フレームワーク）を選択するのが現在のHadoop Platformということになります。

かつては、「HadoopといえばMap/Reduce」というのが常識でした（自分もそう思っていました）。しかし、現在では「Map/ReduceはひとつのYARN処理系でしかない」とのことです。ビッグデータは、とりあえずHDFSに保存しておき、活用法によって適切な処理系（YARN）を選ぶのが現在のHadoopの活用方法なんですね。

自分も、かつて、読書会で象本を読みながらHadoopを勉強したことがあります。しかし、実業務で使うこともなく、知識も古いままです。今回のセッションを聞いて、Hadoopの進化に驚いています。ビッグデータの加工方法を色々選択できるあたり、様々なAWSのサービスを活用する場面と似ているかも知れません。

HDFS Deep Dive

簡単にHadoopの最新状況を解説された後は、本日のメインとなるHDFSのガチ話でした。この辺りはコアすぎるので前回のJAWS-UGでは話されていなかったとこのことです。まあ、弊社が講演依頼をするときに、デープな話をオファーしたとのですが（笑）

スライドはこちらです。

HDFS Deep Dive from Yifeng Jiang

HDFSの特徴

HDFS（Hadoop Distributed File System）はビッグデータのための分散ファイルシステムです。通常のファイルシステムとは用途が異なるため、設計思想が全く異なるため、頭をHadoop脳に切り替えなければなりません。

分散ファイルシステム

HDFSは複数のノードにファイルを分散して保存することを想定しています。ファイルは幾つかのブロックに分割され、複数個所に分散して保存されます。

安定性・可用性・スループットを重視

分散ファイルシステムも設計思想によって幾つかの傾向がありますが、HDFSでは安定性・可用性・スループットを重視しています。各ノードは障害が起きるという前提で、幾つかのノードに障害が発生してもデータを失うことなく、リカバリできるような設計となっています。

データローカリティ

HDFSでは多くのノードにファイルが分散配置されています。また、データをノードに保存するとき、ノードが配置されているラックも意識でき、１つのラックが障害発生してもデータが失いません。また、データの処理も、なるべくデータに近いノードで行うようになっています。

スケール

HDFSでは数千のノードで運用可能です。データがどれだけあってもノードを増やしてスケールできます。

NameNodeとDataNode

HDFSでは2種類のノードがあります。ファイルのディレクトリ構成や実際の配置場所を記録しHDFSの全体をコントロールするNameNode、実際のファイルが保存されるDataNodeです。 NameNodeはかつて単一障害点と言われていたようですが、近年はそんなこともないとのこと。

HDFSではファイルを複数のチャンク（塊）に分割して各ノードに分散配置します（デフォルトではチャンクは128MB）。チャンクはデフォルトで3つのDataNodeに配置されます。 NameNodeは各ファイルがどのDataNodeに分割配置されているのかを知っており、処理系からファイルを取得しようとした場合にはDataNodeの場所をクライアントに返すような仕組みになっています。また、ファイル操作のログもNameNodeに記録されています。 HDFSを少し学習した経験があったのでこの辺りは良い復習でした。

Block Report

この辺りからDeepな話に突入です。

Block Reportとは、NameNodeが持っているBlock情報と実際のblockを持っているDataNodeの突き合わせ機能です。デモで実際に利用しているノードの数などを見せて貰えましたが、数千のノードが稼動していると十数個のノードは死んでいます。元々、一定数のノードは死ぬという前提なので、システムとして死活監視と自動リカバリが大切なワケです。

死活監視では、定期的にDataNodeからNameNodeにheart beatが送られます。面白いのは、コマンドや状態の通知をheart beatのレスポンスに乗せるということです。例えば、HTTPアクセスやpingなどでEC2などのheart beatを行うのは簡単に実現出来るでしょう。しかし、パフォーマンスを詰めていくならば負荷を減らし、コマンドの実行とheart beatを同一の通信で行えるようなプロトコルにするのは理に適っています。

DataNodeは自身が持つデータ構成や容量などを定期的にNameNodeに送ります。 NameNodeでは自分が記録しているデータ構成や容量などと突き合わせを行い、問題がなければそれで終了です。しかし、なんらかの理由でデータ構成などに食い違いが発生した場合、リカバリに努めるわけです。構成に食い違いが発生することはないような気がしますが、分散でビッグデータを扱っている場合はそれほど不思議なことでもないんですよね。

HDFSこのように複雑なシステムとなっている分散ファイルシステムです。その上、例えば、ノード情報の突き合わせや書き込みなどにはロックが発生したりします。このため、理論的に理解したとしても、チューニングやトラブルシュートを行うとなれば、様々なノウハウが必要になってきそうです。

Erasure code in HDFS

HDFSでは3つのDataNodeにファイルを分散配置していますが、Erasure Codeという技術を使うことも可能です。

Erasure Codeはデータ欠損を復元するための技術であり、元データのちょっと長い（例えば1.5倍）のデータを保存しておけば、欠損があったとしても元データを復元できるそうです（自分も詳細なアルゴリズムまでは分かりませんでした）。これまではデータ欠損に備えて、3倍のストレージを必要としていたのに対し、最大で半分のストレージで済むというのが最大のメリットです。しかしながら、データを書き込む時とデータに欠損が生じた場合にデータを読み込む時にデータを変換する処理が必要になるため、パフォーマンス的には劣るとのこと。主に、あまり読み書きを頻繁にしなくなった古いビッグデータなどに利用すると良さそうです。