AWSチーム社内勉強会「EMRおじさんに聞いてみよう」レポート
弊社AWSチームでは最近「◯◯おじさんに聞いてみよう」というタイトルで各分野について詳しそうなメンバーを講師としてQA形式の社内勉強会を開催しています。今回はその中でもAmazon Elastic MapReduce（Amazon EMR）に関する勉強会のレポートになります。QA形式の勉強会ですので、どんな質問が出て、どんな回答があったかをお楽しみ頂ければと思います。なお、EMRということもあり、社内でも利用経験がないメンバーもいたため、まずはHadoopの概要から説明しつつ、オンプレHadoopとEMRの違いなどについて駆け足で説明する勉強会となりました。
Q. そもそもEMR（Hadoop）が分からない
かなり古いのですが、前述のスライドを元に以下の点について説明しました。
- Hadoopは並列分散処理基盤。スケールアウトする。
- バッチ処理用に開発された。とはいえ、最近は対話処理用に利用できるようなソフトウェアが開発されている。
- HDFSとMapReduceがコアとなるコンポーネント。とはいえ、MapReduceは残るか分からない。HDFSはHadoop2になっても変わっていないし、今後もHDFS自体は残ると思われる。
- エコシステムは2011年の頃と比べるとソフトウェアが倍以上になっているはず。
- HDFSは分散ファイルシステム。Master/Slave構成で、Hadoop2で高可用性が実装された。
- MapReduceは分散処理用のフレームワーク。MapとReduceに分けて処理を書けば、後はフレームワーク側で分散処理をよろしくやってくれる。ただし、MapとReduceに分けて処理を設計/実装するので面倒。
なお、前述のスライドは古いので最新のHadoopの概要と動向を知るなら以下のスライドなどが参考になると思います。
Q. EMRではS3を利用するという話だが、最初はS3にデータを上げるのか
EMRの話で言えば、基本的にはS3にデータを上げるケースが多いとは思います。ただし、最近はストリーミング処理をするようなケースであれば Kinesis -> EMR（Spark Streaming）というケースもあると思います。また、DynamoDB <-> EMRというケースもあると思います。
Q. EMRではHDFSを利用しているのか
利用しています。S3はあくまでも永続用で、ジョブ実行中の作業領域としてHDFSを利用します。S3に書き込むのはHDFSよりは低速になるので、S3に書き込む単位をどの程度の頻度で行うのかはDBでトランザクションのcommitタイミングをどうするのか考えるのと似ています。頻度を多くすればジョブに失敗した際のリランする範囲は狭くなりますが、全体のスループットは下がります。
なお、オンプレ環境では永続化と作業領域の両方としてHDFSを利用します。そのため、HDFSの場合はバックアップをどうするかという問題がありますが、EMRの場合はS3を使うのでその辺りの考慮は不要です。まぁ、AWS利用費は線形に高くなるので、データのサイズがある規模を超えるとインフラコストという観点では悩ましいですが。。
Q. EMRFSとは何なのか
HadoopはファイルシステムをDFSとして抽象化していて、実装を複数選ぶことが出来ます（参考：Amazon EMR と互換性のあるファイルシステム）。そのEMR版の実装をEMRFSと言います。要はS3を実体としたDFSの実装です。また、最近だとDynamoDBを利用した読み取り整合性についても実装されています。
Q. ノード障害時はどうなるのか
Hadoopの基本設計としてSlaveノードの障害に対応できるように実装されています。そのため、Slaveノードに障害が発生しても問題なく処理を継続することが可能です。また、最近だとHadoop本体はMasterノードの高可用性も実装されています。ただし、EMRの場合は基本的にバッチ用途を想定しているためか現時的でMasterノードの高可用性は実装されていません。
Q: クラスターのマスターノードが故障した場合、Amazon EMR はそれを回復させることができますか?
いいえ。マスターノードが故障すると、クラスターは終了し、ジョブは再実行する必要があります。Amazon EMR は現在、マスターノードまたはマスターノードの状態回復の自動フェイルオーバーをサポートしていません。マスターノードが故障すると、AWS マネジメントコンソールは、「マスターノードが終了しました」というメッセージを表示します。これはお客様が新しいクラスターを開始するためのインジケータです。お客様はクラスター内にチェックポイントを設定して、中間データ（まだ減少していないクラスターの途中で作成されたデータ）を Amazon S3 で保存できます。故障した場合は、これにより最終チェックポイントからクラスターを再開することができます
実際問題としてバッチ用途でEMRを利用する場合は、バッチ終了後はHadoopクラスタそのものを破棄するため、EMRでMasterノードの高可用性が実装されていないことは問題にならないという認識でいます。ただし、ストリーミング用途に利用する場合で高可用性が求められる場合は、現状ではHadoopクラスタを2つ立ち上げて冗長化する必要があると考えます。
Q. MapRはどうなんでしょうか
MapRはHadoopのディストリビューターで、そのMapRのHadoopをEMRで利用することが可能です。MapRはHDFSをC++で再実装してスループットを向上させています。そのため、AWS利用費を削減できるのではないかということで過去に検証したこともあります。
ただ、どうしても独自実装であるためか、コミュニティ側に運用ノウハウみたいなのが流れてくる印象がないので、正直良く分かりません（私が追えていないだけかもしれませんが）。Hadoop Timesとかでは色々見かけるので、利用されているところでは利用されていると思います。
Q. EMRとDynamoDBの使い分けは
EMRとDynamoDBは直接比較できないものです。片方は分散処理基盤で、片方はKVSなので。KVSという意味ではEMR上にHBaseを構築すれば比較できるとは思います。基本的にはマネージド・サービスであるDynamoDBを使った方がよいと考えます。HBase固有の機能を利用したいケースがあるなどなければ使わないで良いと考えます。
Q. EC2インスタンスを利用するのか
はい。EMRではEC2インスタンスなど複数のAWSのサービスを利用します。EC2インスタンスの一覧画面にもEMRで利用するEC2インスタンスが表示されますし、EC2インスタンスのlimitsもそのまま適用されます。そのため、上限緩和申請をしないとノードを増やせないというケースはありがちな話だと思います。
EMRはあくまでもAuto Scaling GroupやElastic BeanstalkのようにAWSの各種リソースを自動制御してHadoopクラスタを構築/運用してくれるサービスです。
Q. 処理の起点はどこになるのか
バッチ処理であれば、処理の起点はジョブスケジューラになるはずです。ジョブスケジューラでEMRのAPIを利用してHadoopクラスタを構築し、処理を実行し、処理が完了したらクラスタを破棄します。
Q. S3にファイルを置いたことを起点としたジョブの実行はどうか
S3にファイルが置かれたイベントを起点とするようなケースはLambdaを利用した方がよいと考えます。そもそもHadoopは大規模なファイルをバッチ処理することを基本としているので。もちろん、そのファイルがとても大きなファイルであればいいかもしれませんが、S3にファイルが置かれるたびにHadoopクラスタを構築するというのはコスト的に合わないと考えます。
Q. RedshiftとHadoopの使い分けは
Redshiftは構造化データ、Hadoopの場合は非構造化データという違いになります。Scheme on Read/Writeという考え方があり、要はスキーマの適用を読み取り時に適用するか書き込み時に適用するかの違いです。RedshiftなどのRDBMSは書き込み時にスキーマを適用して読み取り時に最適化した形で書き込みを行います。結果として読み取りが高速化されます。一方、Hadoopの場合はファイルを読み取る際にスキーマを適用するので、例えばログのフォーマットが変わったような場合でも読み取り時のスキーマ定義を変更すれば新しいログフォーマットと旧ログフォーマットの両方のデータを読み取ることが出来ます。
なお、Hadoopでも対話処理をしたいという要望に応える形で書き込み時にスキーマ適用を行うファイルフォーマットも存在します。その辺りの歴史的経緯やScheme on Read/WriteについてはApache Hadoop エコシステム を中心とした分散処理の今と未来（PDF）をご参照下さい。
まとめ
いかがでしたでしょうか。全体として眺めると他のAWSサービスとの使い分けなど色々な質問が出ていたかなと思います。みなさまのご参考になれば幸いです(^^)
