AWS Summit 2014 Tokyo「AWSビッグデータサービス Deep Dive」レポート

虎塚

2014.09.12

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

こんにちは、虎塚です。

AWSサミットのセッション「AWSビッグデータサービス Deep Dive」をタイムシフト聴講したので、レポートします。

講師は、HBaseのコントリビュータ、書籍の著者でもある蒋逸峰さん（アマゾンデータサービスジャパン）です。

テーマは、EMRを中心とするAWSのさまざまなビッグデータサービスを効率使うために、押さえておきたいポイントの紹介とのことです。

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クリックでインストールするか、あるいはブートストラップアクションという仕組みを利用できる。ブートストラップアクションを使うと、スクリプトを利用して各ノードにツールを自動的にダウンロードできる。

（参考）awslabs/emr-bootstrap-actions

また、ビッグデータシステムでは、異なるコンポーネント間でデータを移動するシナリオが多い。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との大きな違い