この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、虎塚です。
AWSサミットのセッション「AWSビッグデータサービス Deep Dive」をタイムシフト聴講したので、レポートします。
講師は、HBaseのコントリビュータ、書籍の著者でもある蒋逸峰さん（アマゾン データ サービス ジャパン）です。
テーマは、EMRを中心とするAWSのさまざまなビッグデータサービスを効率使うために、押さえておきたいポイントの紹介とのことです。
- AWS Summit Tokyo 2014 開催レポート動画・資料一覧 | アマゾン ウェブ サービス（AWS 日本語）
- AWSビッグデータサービス Deep Dive（AWS Summit Tokyo 2014 | TA-01）
Amazon Elastic MapReduce (EMR) のご紹介
What is EMR?
EMARとは、マネージド型のHadoopサービス。オンプレミスのHadoopの導入や運用では、大量のサーバを扱うことが大変だったり、キャパシティプランニングが難しかったりする。EMRは、そのハードルを下げて、Hadoopをすぐに簡単に利用できるようにした。
2009年にサービスを開始して以来、世界中で550万以上のクラスタがローンチされている。
EMRは、Apache HadoopのMapReduceエンジンを中心として、他のビッグデータツールや、AWSの他のサービスとも連携しやすいのが特徴だ。
ビッグデータサービス・技術群との連携
中心になるのは、MapReduceエンジンと、データを格納するためのHDFSとの連携。それ以外にも様々な周辺サービス・技術と連携できる。
- AWSの他のサービスであるAmazon Kinesis, S3, DynamoDBとのデータ連携
- Hadoopエコシステムと呼ばれるOSSツールのHBase, Flume, Spark
- ハイレベルで処理するクエリを書くためのHive, pig
- データ分析ツールであるmahout
- RDBSとのデータ連携、インポート/エクスポートにAmazon RDS, sqoop
このようなツールを使う上で、ユーザが手作業でインストールする必要はない。Management Consoleから1クリックでインストールするか、あるいはブートストラップアクションという仕組みを利用できる。ブートストラップアクションを使うと、スクリプトを利用して各ノードにツールを自動的にダウンロードできる。
また、ビッグデータシステムでは、異なるコンポーネント間でデータを移動するシナリオが多い。AWS DataPipelineを使うと、データ変換や移動のロジックをJSONで定義できる。リソースのプロビジョンや委譲の処理もできる。
Amazon EMRのご紹介
- コンソールから画面をクリックするだけで、たった数分でクラスタが作れる
- クラスタが1台でも数千台でも、規模を問わず、同様の使い方ができる
- ユーザがワークロードに合わせたインスタンスサイズを選ぶ
- オンプレミスのHadoopクラスタと比べるとリードタイムが短い
- キャパシティプランニングやハードウェアの購入など、時間のかかる作業が不要
- 起動も終了も簡単なので、使いながら最適なものを選べばよい
- ハードウェア運用から解放されて、運用コストの削減につながる
- オンプレミスで数百台のクラスタを運用すると、毎日のようにHDDが壊れてもおかしくない
- アプリケーションに合わせて、異なるサイズ、スペック、ノードタイプのクラスタを起動する
- オンプレミス: 大きな1つの共有クラスタ上に、多くのアプリケーションを載せる。アプリをクラスタに合わせてチューニングしたり設計したりする必要がある
- AWS: 様々なタイプやサイズのクラスタを選んで、アプリのワークロードに合わせる
Amazon EMRデザインパターン
今回のセッションでは2つのパターンを紹介する。
- Pattern #1: 一時的なクラスタの活用
- Pattern #2: タスクノードの活用
Pattern #1: 一時的クラスタ
- 一時的クラスタとは
- ジョブの実行中だけ立ち上げるクラスタ。ジョブが終わるとシャットダウンする
- 常時稼働するクラスタは、永続的クラスタと呼ぶ
処理が終わったらシャットダウンするので、クラスタが保持するデータをどこかに永続化する必要がある。それにはS3を利用するのがお勧め。
一時的クラスタのメリット
- コストメリット
- 終わったらシャットダウンするのでコストを削減できる
- クラスタ運用の手間を最小限にできる
- シャットダウンしてしまえば、運用作業は発生しない
- クラウドならではのやり方ができる
- 使った分だけ払う
- データ処理をワークフローとして扱う
Amazon S3をHDFSとして利用するメリット
- クラスタをシャットダウンできる
- コストが低くなる
- データをS3に安全に退避してクラスタを落とすことが可能
- 複数クラスタ間でデータ共有できる
- オンプレミスのHadoopクラスタなら、別のチームがデータを使いたい時、データをコピーするか、アクセス権を渡す必要がある
- これにはデメリットがある。ビッグデータなのでコピーには時間がかかるし、ストレージにコストがかかる。アクセス権を変えると、元のチームの環境が影響を受ける
- S3なら、保存したデータに複数のクラスタから同時にアクセスできる
- S3にデータを置くと、S3サービスの恩恵を自然に受けられる
- 99.999999999%の堅牢性
- スケールの能力
- S3の機能を活かせる
- サーバサイド暗号化
- Amazon Glacierとの連携
- バージョニングを使ったオペレーションミスの予防
これらはいずれも、オンプレミスでは得難いメリットだ。
いつ一時的クラスタを使うか？
- (データのロード時間 + 処理時間) * ジョブ数 < 24時間のとき
- 上記に収まるジョブならば、一時的クラスタを利用するとコストメリットが大きい
- （例）(20分のデータロード + 1時間の処理) * 10ジョブ = 13時間 < 24時間
（参考）永続的クラスタ
永続的クラスタを利用する場合も、バックアップとしてデータをS3に置いて欲しい。マスタノードが落ちたり、クラッシュしたり、運用のオペレーションミスが発生したりして、数十TBのデータが一瞬で消えてしまうことが起こりうるため。
（永続的クラスタのメリットや、いつ永続的クラスタを使うかについては、発表スライドを参照ください）
Pattern #2: タスクノードの活用
EMRアーキテクチャ
EMRには、3つのノードタイプが存在する
- マスターノード: Hadoopのマスター機能。HDFSのネームノードやMapReduceのジョブトラッカーが動く
- コアノード（後述）
- タスクノード（後述）
Amazon EMRコアノード
- TaskTrackerとDataNodeが実行される
- MapReduceジョブを実行しながら、HDFSにデータを保存する
- Hadoopのスレーブノードに似ている
- ジョブ実行中でも、ノードを後から追加できる
- ノードを追加することで、HDFS容量、CPU/RAMが増える
- 追加したコアノードを削除はできないことに注意
- ノードが持つHDFSが失われる＝データを失ってしまうため
Amazon EMRタスクノード
- TaskTrackerだけを実行する。HDFSは実行しない
- ノード上で実行するMapReduceのタスクのために、データを取ってこなければならない
- Amazon S3から取得
- 同じクラスタのコアノードのHDFSから取得
- ノードを常時追加できる
- 処理が遅くなりそうであれば追加する
- ノードの削除も常時できる
- HDFSが動いていない（データを持っていない）ので、ノードの削除がクラスタにほぼ影響しない
タスクノードのユースケース #1
スポットインスタンスを活用して、安いコストでジョブを高速化させる。タスクノードをスポットインスタンスの上で動かす。タスクノードはいつでも削除できるため、スポットインスタンスとよくフィットする。
万が一、市場価格がスポットインスタンスの入札額を上回った場合、スポットインスタンスは強制的にシャットダウンされるが、タスクノードはデータを持たない（いつでも削除できる）ので大丈夫。
タスクノードのユースケース #2
S3から大量のデータをHDFSにコピーするとき、大量のタスクノードをスポットインスタンスとして起動して、データを一斉に取ってくる。これでロード時間を短縮できる。データのコピーが終わったら、スポットインスタンスを削除すれば、課金が停まる。
タスクノードのユースケース例
- （例）2つのノードで構成するクラスタ。1ノード48TB。2つのノードしかないので、S3からデータをロードするのに時間がかかる。
- ノードの前段でスポットインスタンスを起動して、タスクノードを追加し、S3からデータをロードする
- データロードが終わったら、ノードを削除する
一時的に大量のパワーが必要なときはタスクノードを追加する、といった柔軟な使い方ができる。
Amazon EMRベストプラクティス
Amazon EMRノードタイプとサイズ
常に現世代のインスタンスタイプを使うことが重要（セッション時点では、M3, C3, R3, I2, HS1インスタンス）。現世代のインスタンスは、旧世代インスタンスに比べて、コストパフォーマンスが優れているため。
また、インスタンスサイズは用途に合わせることが重要。開発は小さめ、本番は大きめ（M3.xlarge以上）など。
- M3: 一般的な用途に。何を選んでよいかよくわからないときはこれを使う
- R3: メモリを大量に必要とするジョブに適する
- C3: CPUパワーを大量に使うジョブに適する。画像処理、機械学習など
- HS1: HDFSを大量に使う場合に適する
- I2 and HS1: ディスクI/Oの多いジョブに適する
大きめのノードで構成された、小さい（数が少ない）クラスタが効率的。とはいえ、一概には言えず例外もある。EMRはクラスタの起動もシャットダウンも簡単なので、上手く利用して試行錯誤しながら、常に最新のインスタンスで最適なインスタンスを選んでいくのがよい。
最適なファイルサイズ
- Hadoopは小さいファイルが苦手なので、100MB以下のファイルを処理させることは避ける
- Hadoopを利用する場合のS3の最適なファイルサイズは約1〜2GB
- 1 mapperからS3のデータ取得速度は10〜15MB/sec
- Map処理は60秒以上であるべき
- 60sec * 15MB = 約1GBなので、それ以上のサイズがよい
小さいファイルの扱い
小さいファイルがすでにたくさんある場合はどうするか。
- S3DistCpを使って小さいファイルを結合する
- Hadoopの分散コピーツールDistCpをS3対応したもの
- ファイル名の入力パターンをみて、小さいファイルをパターンでグルーピングし、大きなファイルに結合してくれる
- （参考）S3DistCp を使用した分散コピー
たとえば、S3バケットに格納された大量の小さいファイルを、S3DistCpによって、ファイル名を正規表現でグループ化し、1GB単位で出力する、といったことができる。
（ツールに渡すオプションは、発表スライドを参照ください）
パフォーマンス・チューニング
EMRに限らず、Hadoopのチューニングには2つのステージがある。
チューニング ステージ #1
まず、パラメータやコンフィギュレーションを調整する前に、データを効率よく保持することが重要になる。たとえば日付単位でファイルをパーティショニングすると、Hadoopに処理をさせやすい。このようにしておけば、前日ログを処理するケースなどで、前のデータを処理しなくてよくなるので、速度が上がる。
次に、ツールを使い分けすることが大事。
- Hadoopそのものはバッチ向け
- オンライン処理やインタラクティブ処理には向いていない
- 1処理は、1時間以上〜数日のオーダーを想定
- もっと短い時間のジョブには、他の技術がフィットする可能性が高い
その上で、ノードの追加が最強のチューニングである（※ネタではありません、とのことw）。特に、小さいクラスタの場合は、がんばってチューニングしても10%くらいしか効果が出ない。チューニングするよりも、EMRでは簡単にノードを追加削除できるので、まずはノードを追加して処理速度を上げることが大事。
Hadoopのチューニングや管理が本質ではなく、Hadoopを使って分析を行い、ビジネス上の価値を生み出すことが本質なので、ノードの追加は選択肢の一つだ。
チューニング ステージ #2
チューニングのためにはリソースのモニタリングが必要である。
Gangliaでクラスタをモニタリングするとよい。EMRで使う場合は、画面から1クリックでインストールできる。とても簡単なので、特に本番環境では使わない手はない。
チューニングの手順は次のとおり。
- まず、モニタリングを行いボトルネックを特定する
- メモリ
- CPU
- ディスクI/O
- ネットワークI/O
- 次に、目標を決めてチューニングする
ネットワーク I/O
ネットワークI/Oは最も重要なメトリックになる。特に、S3をストレージとして使う場合。
- チューニングの目標
- 1つのインスタンスからなるべく多くのネットワークI/Oを引き出すこと
- 手段
- インスタンス上で動くMapReduceのマップの数を調整する
（例）Gangliaのグラフで、ネットワークのスループットをチェックする。ネットワークI/Oの値が低い部分は、インスタンス上のMap数を追加することで、まだまだ性能を引き出せると考えられる。（グラフのサンプルは、発表スライドを参照ください）
プラットフォームとしてのAmazon EMR
EMRは様々なツールと連携しやすくできている。HadoopといえばMapReduceというイメージが強いが、EMRは他のツールとも繋ぎやすい。EMRで周辺ツールを使う場合の特徴や、ユースケースを紹介する。
HBase on Amazon EMR
Apache HBaseは、Hadoop上のNoSQLデータベース。
HBaseのユースケースとしては、Hadoopエコシステムの内部でデータ処理をしたい場合に使う。書き込みの多いワークロードにフィットする。
EMRで使う場合は、1クリックでインストールできる。
OpenTSDB（Time Series Database）
- 大規模システムのモニタリング用
- 秒間数百万のデータ書き込みが可能
- EMRで使う場合は、ブートストラップアクションでインストールできる
- https://github.com/uprush/emr-bootstrap-actions/blob/master/opentsdb/install-opentsdb.sh
HBaseバックアップ＆リストア
- HBaseのデータをコマンド1つで自動/手動でS3にバックアップできる
- フルバックアップ, 増分バックアップ
- 指定したバージョンに簡単にリストアできる
- クラスタを新しく立ち上げて、リストアする
Impala on Amazon EMR
Impalaは、SQLのような言語を使って、Hadoopのデータをインメモリで処理する。インメモリなので高速に動作する。
Imparaユースケースとしては、メモリ上で処理可能なデータセットであれば使うことができる。アドホック、インタラクティブなクエリを使うとよい。Hiveと互換性が良いので、Hiveを使う場面で代わりに使う(ETLなど)と、処理が速くなることがある。
- EMRで使う場合は、1クリックでインストールできる
- アクセスできるデータストアは、EMRクラスタのHDFS、またはその上で動くHBase
- セッションの時点ではS3に非対応
- ImpalaからS3のデータにアクセスしたい場合は、S3からローカルのHDFSに一旦データをコピーする必要がある
Presto on Amazon EMR
Prestoは、SQL on Hadoopのもう1つのツール。Prestoの利用目的とユースケースはImpalaと似ている。
- EMRで使う場合は、ブートストラップアクションでインストールできる
- https://github.com/awslabs/emr-bootstrap-actions/blob/master/presto/install
- HDFS、HBase、S3からデータを取得できる
- S3からデータを直接インポートできる点は、（セッション時点では）Impalaとの大きな違い
Spark on Amazon EMR
Apache Sparkは、最近注目度が高いインメモリ分散処理エンジン。非常に高速。Sparkで処理できるデータセットを使った場合の比較では、Hadoopよりも処理速度が速いケースもある。
Sparkでは、MapReduce以外に4つの処理モデルがあり（SQL、ストリーミング、機械学習、グラフなど）同じエンジンを使って様々な処理ができることが特長である。
- EMRで使う場合は、ブートストラップアクションでインストールできる
- Spark 0.8をサポートしている（間もなく1.0をサポート予定）
Spark on Amazon EMRのメリット
コストメリットが大きい。Sparkはメモリを大量に使うので、いかに安くメモリの大きなインスタンスを大量に調達するかが課題。
- R3インスタンスを使う
- タスクノードにスポットインスタンスを活用する
- 処理が終わったらタスクノードをシャットダウンする
Spark Metrics and CloudWatch
Sparkのメトリクスをモニタリングできる。たとえば、JVMの最大ヒープサイズ、利用ヒープサイズなどを見て、あるサイズを超えたらアラートを送り、自動対応することなどができる。
Spark Streaming and Amazon Kinesis
Amazon Kinesisとの連携。Sparkのストリーミング機能を使って、Kinesisのレシーバを実装した。Kinesisのストリーミングの中のデータを、Sparkでリアルタイムに分散処理できる。
まとめ
- Amazon EMRデザインパターン
- 一時的なクラスタの活用
- タスクノードの活用
- Amazon EMRベストプラクティス
- 最適なインスタンスを選ぶ
- 小さいファイルの扱い
- パフォーマンス・チューニング
- 最適なデータ・パーティションやツールの利用
- ノード追加
- モニタリングやチューニング
- プラットフォームとしてのAmazon EMR
- MapReduce以外の使い方
EMRは簡単に利用できるので、ワークロードに合わせて最適なソリューションを選んで、EMRのクラウドならではの特徴を上手く利用し、ビッグデータを安く効率よく処理してください。
感想
ビッグデータというタイトルからどんな内容だろうと思いましたが、EMRの利用メリットや運用管理についての非常に具体的なお話でした。
オンプレミスでのHadoop運用と比較して解説してくださったので、EMRの利用がいかにラクなのかがよく分かりました。EMRを使う時には、今回学んだポイントを押さえておこうと思います。
それでは、また。
1
