Amazon Elastic MapReduce（EMR）の選択肢を考える：きょうから試せる Hadoop“スモールスタート”ガイド（5）（1/6 ページ）

実際にHadoopで処理を実装していきながら「Hadoopは、誰にだって扱える」を体感しましょう。今回は「Amazon Elastic MapReduce（EMR）の選択肢と活用方法」を解説します。

[佐々木達也，著]

連載目次

書籍の中から有用な技術情報をピックアップして紹介する本シリーズ。今回は、秀和システム発行の書籍『Hadoopファーストガイド（2012年9月20日発行）』からの抜粋です。

ご注意：本稿は、著者及び出版社の許可を得て、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

Amazon Elastic MapReduce（EMR）という選択肢

クックパッドでEMRを導入した理由

　筆者の所属^※するクックパッドでも、以前は少人数でCDH（Cloudera's Distribution including Apache Hadoop：Cloudera社が提供しているHadoopディストリビューション）を利用していたのですが、しばらく使っているといくつか問題が出てきました。

• 1：Hadoopクラスタの起動が不安定
• 2：バグに当たってしまった^※13

　※ 編注：本書執筆当時
　※13 [#HADOOP-6254] s3n fails with SocketTimeoutException - ASF JIRA

1：Hadoopクラスタの起動が不安定

　上記は2010年当時の話なので今は事情が変わっているとは思いますが、当時はHadoopクラスタを起動させようとしても、ときどき起動処理が終わらなかったり、起動に失敗したりすることがあり非常に困っていました。まとめて30台とか50台でHadoopクラスタを起動すると失敗してしまう確率が高かったので、最初は10台程度でHadoopクラスタを起動し、その後10台ずつそのクラスタにノードを追加していくようなバッドノウハウでこの問題を回避するようにしていました。

2：バグに当たってしまった

　こちらはもっと深刻でした。当時からログの置き場としてAWSのS3を利用していて、HadoopからはS3に対してデータの読み書きをしていたのですが、Mapperの処理のCPU負荷が高い場合にHadoop側でS3とのコネクションが終了したと判定してしまうバグがありました（Hadoop-6254）。そのため、S3とのコネクションが意図せず切られてしまい、次にアクセスしたときにはS3とのコネクションが存在せずSocketTimeoutExceptionが発生してしまう状態で、読み込みも書き出しもできず致命的でした。

　どちらも問題ではありましたが、特にバグの方は許容できるものではなく致命的だったため、何とかしてこの問題を解決する必要がありました。なお、当時はCDH1（Cloudera's Distribution including Apache Hadoopのバージョン1）を利用していたのですが^※14、CDH2も公開されていて、CDH2ではこの問題に対する修正は行われていました。

　※14 執筆時点での最新はCDH4です（編注：2017年2月現在の最新版はCDH5.9.1です）

CDH2のリリースノート

　また、当時公開されたばかりで日本ではまだあまり利用されていなかったと思うのですが、AWSが提供していたEMR（Amazon Elastic MapReduce）でもこの問題は修正済みのようでした。

EMRのフォーラムにて

　そのため、このバグを解決するための選択肢はCDH2かEMRかのどちらかでした^※15。そこで、CDH2にバージョンを上げる方が良いか、EMRを採用する方が良いか、いくつかの観点で比較してみました。

　※15 もちろん、素のHadoopを使って自分でパッチを当てる、なども考えられますが、前述したような理由から選択肢には入りませんでした