Amazon EMR をプロダクション環境で運用してみた話
Posted on
- #aws
この記事は、AWS Advent Calendar 2014 の 13 日目の記事です。
AWS のサービスの中でもあまり事例を聞かない Amazon EMR の話を書きます。 Amazon EMR と言っても分析や解析の用途ではなく、HBase をインストールして分散データベースとして使っています。ログ解析やバッチ処理の話はいっさい出てきませんのであしからず。
Amazon EMR になる前
自分が担当しているプロダクトについては、JAWS-UG 三都物語 2014 で話したスライドを見ていただくとわかりやすいです。
Amazon EMR に移行する前は、オンプレミスの物理サーバに CDH 3 系をインストールしていました。オンプレミスでスケールさせるのがあまりにも手間なので、HBase も含め全面的に AWS に移行することにしました。
Amazon EMR のメリット
Hadoop を安定運用するのは、それなりの経験が必要で何より大変です。 Hadoop だけならまだしも、その上に HBase が載っているのでさらにややこしい。 Amazon EMR を使うと、運用の面倒なところをほとんどやってくれます。
- HBase のバックアップが簡単。フルバックアップと差分バックアップも組み合わせられる。詳しくは「HBase on Amazon EMR の詳細なバックアップを設定する」
- データノードのスケールアウトがボタン 1 つ。これによって HBase のサイジングが不要に
- データノードが 4 台以上であれば他のデータノードにレプリカがあるので、どこかのデータノードが落ちても Auto Scaling のように勝手に復旧してくれる
- バックアップデータが S3 上にあるので、いざというときも他のリージョンで復旧させられる（オンプレミスだとデータが大きすぎて移動できない）
プロダクション環境で半年ほど運用しましたが、非常に安定しておりトラブルは一度も起きていません。日々の運用も運用チームに任せる必要がなくなり、運用コストもグッと減りました。
Amazon EMR のデメリット
導入をためらうほどではありませんが、当然デメリットもあります。
- CloudFormation がまだサポートしていないので、Amazon EMR だけ別の手段で上げる必要がある
- AZ をまたがった構成が組めない。 EC2 や RDS は Multi-AZ 構成でも Amazon EMR が単一障害点になりうる
- リザーブドインスタンスを使っても、データベースとしてはコスト高
2 つ目に関しては、もし AZ が丸ごとダウンするような事態になったら、開発者がもう片方の AZ にフェイルオーバーさせる手順を確立しています。 Hadoop はノード間のトラフィック量が多く、レイテンシにも厳しいので仕方ないと思いますが、自動的にフェイルオーバーする機能はぜひ実現してほしいですね。
3 つ目のコストについては、HBase は 24 時間 365 日止められないので、ホストしている EC2 のコストがバカになりません（毎月のコストの約 4 割が HBase にかかってる）。これは Amazon EMR の欠点というより、自分たちの選択ミスです…。
ぶっちゃっけ NoSQL の分散データベースなら DynamoDB のほうがいいと思います。チーム内でも HBase をやめて DynamoDB に移行しようという話が出ています。
まとめ
オンプレミスで Hadoop を運用している人にとって、Amazon EMR はとても魅力的な選択になると思います。ログ解析やバッチ処理ならスポットインスタンスも組み合わせられるので、オンプレミスとは比べものにならない低コストで実現できます。データ分析に携わる人なら Amazon EMR は強力な武器になるはずです！
ただ、Amazon EMR 上で HBase を使う場合は、ほかにもっと良い選択がないか検討するのをおすすめします :-)