Elastic MapReduce - Amazonが提供するHadoopサービス -

Amazon Data Service Japan

Shinpei Ohtani

自己紹介

大谷 晋平(おおたに しんぺい)

アマゾンデータサービスジャパン株式会社所属

ソリューションアーキテクト

ソーシャルネットワーク

Twitter: @shot6

Facebook: facebook.com/shot6

Mail: ohtani@amazon.co.jp

Hadoopユーザグループの末席におります

アジェンダ

Amazon Web Services(AWS)とは

Big Dataが抱える課題

Hadoopとは

Amazon Elastic MapReduce(EMR)

EMR機能

EMR利用事例

まとめ

アマゾンの3つのビジネス

一般消費者様向けサービス

セラー様向け サービス

開発者様& IT プロ様向け サービス

Eコマース （Amazon.co.jp）

マーケットプレイス 物流サービス提供 （Amazon Services）

クラウド コンピューティング

（Amazon Web Services）

Amazon Web Services(AWS)とは

ミッションステートメント

あらゆるビジネスが必要とするスケーラブルで、高度なアプリケーションを作るための プラットフォームの提供

• 現在クラウドコンピューティングと呼ばれる

10年以上にわたるAmazonのプラットフォーム構築・運用のノウハウを結集させ、汎用的にサービスとしてご提供

The “Living” AWS Cloud

Low-level

building blocks

High-level

building blocks

Tools to access

services

Cross Service

features

何故Big dataがそんなに大変なのか？

以下の組み合わせによる困難さ: • 桁違いのデータ量を扱わなくてはいけない

• 複数のデータソースと複数のフォーマット

• 様々なデータ構造

• 即時性が求められる

現状のシステムではスケールしない (意図されていない) • インフラの調達だけで非常に時間がかかる

• 特殊なデータベースの専門家が必要

• 非常に高価で伸縮性のないソリューション

Big Dataを扱うためのソリューションが必要

あるインターネット小売でのデータウェアハウスの要求

今までの要求 – うまく定義されたスキーマ 売り上げレコード、顧客レコード、商品レコード

新しい要求 – 半構造データ/スキーマなし、継続的に進化

クリックストリームログ、エラーログ、検索ログ – 顧客動向を探る手がかり

レビュー結果、like/don’t like、レーティング、フィード – 顧客の心象を探る手がかり

ソーシャルコミュニケーション – ソーシャルな中への広がり

既存データに加えて、新しいデータは半構造で

とめどなく膨張しており、かつ有効なデータ

Hadoopとは？

Big Dataを扱うためには下記の2つが必要： – スケーラブルな分散ストレージ

– 低価格で柔軟に行うことが出来る分析

Apache Hadoop とは上記を満たすオープンソースのフレームワーク

– HDFSは耐障害性のある分散ファイルシステムでコモディティサーバ用に特化

– MapReduceプログラムによって、巨大なデータに対しての網羅的な分析を実施

顧客が受けるメリット – 誰でも入手可能 – Cost / TB is a fraction of traditional options

– スケーラブル – PBオーダまではリニアにスケール可能で既に実績多数。

– 柔軟性 – データはスキーマのある/なしで両方保存可能

Amazon Elastic MapReduce(EMR)

Amazon Elastic MapReduceとは

大規模データ処理基盤をあらゆる開発者に！ Hadoopクラスタをオンデマンドで好きなだけ実行可能

• 数ノードから数千ノードまで

• AWSのスケーラブルなインフラストラクチャの上で実行

分析・解析アプリケーションに集中できる オンプレミスから修正なしにMapReduceアプリケーションを持込可能

複数のバージョンから選択可能で、AWSがパッチ適用とテストを行い、クラウドに最適化したHadoopが利用可能

S3による入力・出力データを保護 インプットデータ及びアウトプットデータは非常に高い堅牢性を誇る

S3に保存するのでデータを欠損する事がない

Amazon Elastic MapReduceとは(2)

Big Data処理のための煩雑な事を肩代わり Hadoopクラスタの適切なサイズ見積もりも、サーバ調達も難しい

Hadoopのチューニングは更に難しい

ネットワークを最適化するのは更に難しい

Hadoopクラスタのデバッグも難しい

AWSサービスとのインテグレーション パフォーマンスの最適化

クラウド環境下でのネットワークプロビジョニングと最適化

クラスタサイズの動的な拡張と伸縮

EMRがサポートするHadoopスタック

• Hadoop 0.20

• Pig 0.6

• Hive 0.5/0.7

• Cascading 1.1

• Hadoop 0.18

• Pig 0.3

• Hive 0.4

• Cascading 1.1

EMRアーキテクチャ

EMRを支えるAWSプラットフォーム

Amazon EC2

スケーラブルなコンピュートプラットフォーム

柔軟でスケールアップ、スケールアウト可能

EMRのMasterノード、Coreノード、タスクノードを展開

Amazon S3

スケーラブルなWebストレージサービス

99.999999999%の堅牢性、非常に安価

EMRのデータ及びアプリケーションのアップロード先

SimpleDB

Amazonの管理不要で可用性を重視したNoSQLサービス

カラム指向で簡易クエリも付属

EMRのジョブ状態情報を維持

Amazon Elastic MapReduce

Hadoop Cluster

HDFS

Task Node

Task Node

Core Node

Core Node

Input

Data Output

Data

Amazon S3

Metadata

Amazon SimpleDB

BI Apps

巨大なデータセットや、

膨大なログをアップロード データ

ソース

Code/

Scripts

Amazon S3

Service

Amazon Elastic

MapReduce

HiveQL

Pig Latin

Cascading

MapReduce

コード

複数のジョブフローのステップを実行

Master

Node

JDBC

ODBC

HiveQL

Pig Latin アドホック

クエリ

EMRを中心としたアーキテクチャ

• ジョブフローを起動して以下で管理可能

• AWS マネージメントコンソール

• コマンドライン

• REST API

EMR機能: 稼働中ジョブフローの拡張

利用シナリオ: ジョブフローの高速化

要件変更によるジョブフローの実行速度の向上

ジョブの再起動なしに、ジョブにかけるコストとパフォーマンス対比を変更できる

4ノード

起動 25ノードへ

更に拡張

9ノードへ

拡張

Job Flow

残り時間

残り時間 14 Hours

3 Hours

残り時間

Job Flow

Job Flow

7 Hours

EMR機能: 稼働中ジョブフローの拡張/伸縮

利用シナリオ: 柔軟なデータウェアハウスクラスター

クラスタサイズをリソースの必要性に応じて変更 (例：日中のクエリ実施 vs 夜間バッチ処理)

コスト削減とクラスタ利用シーンに応じた柔軟性の確保を両立

9ノード

起動

25ノードへ

拡張

9ノードへ

戻す

データウェアハウス

(通常時) データウェアハウス

(通常時)

データウェアハウス

(バッチ処理中)

EMR + Spotインスタンスの活用

EMRを活用し始めると、更にアドホックなクエリをどんどん実行したくなる

しかし、コスト的に抑えておきたい

EMRとSpotインスタンスのインテグレーション

Spotインスタンスって？？？

課金モデルのイノベーション

オンデマンドインスタンス

•従量課金制

•時間あたり $0.03開始

リザーブドインスタンス

•初期費用 + 従量課金

• 1年コミットで$56、時間当たり $0.01から開始

スポットインスタンス

•指定した価格で従量課金

•時間当たり$0.005という場合も

占有インスタンス

•マルチテナントを単一顧客が占有

• $10/リージョン、 時間あたり$0.105

スパイク対応 評価検証

本番利用 定常的な利用

アドホックな用途

規制や、コンプライアンス

対策

AWS EC2インフラストラクチャ

Spotインスタンスの詳細

EC2インスタンスを購入の際の購入オプションの一つ

コスト削減効果が非常に高い

使用していないEC2キャパシティに指値

よりコストコントロールが効く

EMRでのアドホックな追加クエリ、実験的なクエリに最適

オンデマンドやリザーブドインスタンスとは異なる挙動

入札した価格に見合う間だけ利用可能

AWSのリザーブド・オンデマンドの余剰リソースを低価格で貸し出し

リージョン毎・ゾーン毎に指定可能に

M1.XLARGEインスタンスの価格履歴

Amazon EC2 オンデマンド(東京リージョン)の価格は$0.60

EMR機能: Spotインスタンスの活用

スポットインスタンス=利用者が指値を入れるインスタンス

利用シナリオ: ジョブフローのランニングコストを抑えたい

オンデマンドのm2.xlarge 4ノードで開始

処理の高速化のためスポットインスタンスで5ノード追加

4ノードで

起動

Spot

5ノード

追加

Job Flow

残り時間 14時間

残り時間

Job Flow

7時間

スポットなしのコスト 4 instances *14 hrs * $0.50 = $28

スポットありのコスト 4 instances *7 hrs * $0.50 = $13 +

5 instances * 7 hrs * $0.25 = $8.75

Total = $21.75

時間の削減効果: 50%

コスト削減効果: ~22%

その他の機能 クラスタインスタンスタイプのサポート

US東海岸のみ

通常のインスタンスと比較して速度が大幅に向上するケースも

AWS固有設定を施したワークフロー

メモリインテンシブ設定など

ブートストラップアクション

起動時にユーザがHadoop及び周辺をカスタマイズできる

Hive 0.7

HAVING句、IN句の導入

ローカルモードクエリのパフォーマンス向上、カラム圧縮効率の向上、動的パーティショニング

S3 マルチパートアップロードによるアップロード時間の短縮

EMRが有効な領域例

データマイニング/BI

ログ解析、クリックストリーム分析、近似分析

データウェアハウスアプリケーション

大量ファイル処理・変換

バイオインフォマティクス(遺伝子解析)

金融シミュレーション(モンテカルロ計算等)

Webインデックス構築

EMRの利用事例

クリックストリーム分析 – Razorfish

Razorfishが巨大小売店向けに開発

一日35億レコード, 7100万ユニーククッキー, 170万広告

ターゲット広告

ユーザは最近ホームシアターシステムを購入し、ビデオゲームを見ている

(一日170万)

• EMRとS3を利用

– オンデマンドで100ノードクラスタを実行

– 処理時間が2日間から8時間へ減尐

Razorfishの事例 –その効果-

顧客のEMR導入前

SANストレージ/30サーバ/ハイエンドのSQLサーバ3台

初期費用：40,000,000円

運営費も甚大なコスト

調達にかかった時間：2か月

処理にかかる時間：48時間

EMR導入後の費用対効果

EMR/S3/オープンソースのCascadingを利用

初期費用：0円

運営費：約100万円(コスト↓)

調達にかかった時間：0(ただし評価検証に6週間)

処理にかかる時間：8時間

ROAS(広告費用対効果)を500%改善

Data Sources

Talend Data Flow Manager

Elastic MapReduce

Web Application Layer

Presentation Layer

Internet

Direct Analytics

Processing via

EMR

File Export

Cloud Storage S3

Aggregate

Ad Serving

data

Log

Files APIs

Cache Edge

Provisioning

DB

OLAP

Client

Provided

Data

HBase/SDB

ODBC

Razorfishの事例 –アーキテクチャ-

Sonetの事例

広告配信ログの分析

1日平均10GB、年間3.65TB

1年分5TBデータをS3にアップロードしてからEMRを利用

オンプレミスでの試算：初期費用だけで数千万円単位

EMR+S3での実際：毎月50万円(年間600万円)

• 20分の1以下の支出で実現

スポットインスタンスを活用して、アドホック分析

•コストを50%削減

SonetのEMR利用アーキテクチャ

エコシステム、サードパーティツール

EMRはサードパーティのGUI製品とも連携出来ます:

BI製品

MicroStrategy, Pentaho

分析

Datameer, Karmasphere, Quest

オープンソース

Beeswax

EMRに関連する都市伝説

Q.オンプレミスHadoopの方が早い

物理ハードウェア vs 仮想化

確かに物理ハードウェアの方が早い場合が多い

大事な点はEMRのもたらす柔軟性・拡張性

EMR=スケーラブルなインフラ(EC2/S3)＋スケーラブルなフレームワーク(Hadoop)

特にHadoop固有の性質としてスケールアウトが非常に有効

Q.オンプレミスHadoopの方が安い

物理ハードウェアは最近本当に安い

Hadoopであれば高価なハードウェアは要らない

HDFSによるレプリケーション

調達の時間的コストは別

ハードウェア調達して、インストール・設定するコストは無駄

膨大に増え続けるデータ量に比例してハードウェアを買い続けるのも非効率

ハードウェアを購入すると、分析・解析が制限されてしまう

HDFSの堅牢性(HDFSだけで本当に大丈夫か)

バックアップの取得、またはマスタからロードしたくなる

• そこまで含めてコスト・運用効率があるか

EMRであれば、S3の堅牢性で全て解決

S3のスケール

Q4 2006 Q4 2007 Q4 2008 Q4 2009 Q4 2010 Q2 2011

Peak Requests: 290,000+ per second

Total Number of Objects Stored in Amazon S3

2.9 Billion 14 Billion

40 Billion

102 Billion

449 Billion

262 Billion

Q.Hadoopの面倒は見てくれないのでは？

EMRのHadoopは深刻な問題に対してはパッチを適用

Hadoopの深刻なバグを低コストで回避可能

定期的にメンテナンス、バージョンアップに対応

現状は0.18.3/0.20.2

ユーザの方でBootstrapAction時に差し替えも可能

ただしEMR側での最適化が効かなくなるデメリットも

ご利用は計画的に！

Q.AWSもサーバが足りなくなるのでは？

アマゾン ドット コムが2000年当時年商27.6億ドルの企業で

あった時に必要なキャパシティと同等のものをAWSは毎日

追加しています。

EMRでも多くのお客様から多数の台数を頂いています

20台を超える場合の緩和申請

• http://aws.amazon.com/jp/contact-us/ec2-request/

Beyond Hadoop

Hadoopだけが問題なのではない

HadoopへのIN/OUT含めて、システム全体が

• スケーラブルであること

• フレキシビリティの確保

• コスト/機能が選択可能で、基本的に低コスト

Hadoopは非常に重要なコンポーネント

ただし近視眼的になってはいけない

• データをロストしない

• 運用をやりやすくする

• Hadoopのスケーラビリティに追従可能な仕組み

AWSが提供するBig Data Enterprise Stack

データ保存 並列分析

処理

データの生成・保存、インデクシング、アグリゲーショ

ン

Batch Tier Speed Tier

(ニア)

リアルタイム

分析

構造化データ

半構造化データ

クラウド上での大量データ処理の概要モデル

HBase

SimpleDB

Cassandra

MongoDB

RDBMS

Hadoop S3 EMR

まとめ

大量データ処理及びバッチ高速化のニーズは大きい

Hadoopはその突破口となる大きな可能性を持つ

EMRはHadoopの煩雑さを取り除くAWSサービス

大量データのバッチ処理を柔軟に高い費用対効果で実現

開発者は本来やるべき業務(例：分析)に極力集中

• ≠Hadoopクラスタ構築や管理

データはS3で堅牢性を維持し、クラウドのスケーラビリティのメリットを徹底的に活用

• クラスタサイズの動的変更

• ノードのサイズの変更

• スポットインスタンスによるノード追加

お問い合わせは・・・

http://aws.amazon.com/jp/