20111130 10 aws-meister-emr_long-public

AWSマイスターシリーズ
～Amazon EMR～

2011年11月16日
大谷晋平（ @shot6）
ソリューションアーキテクト

アジェンダ
Hadoopとは
Amazon Elastic MapReduce(EMR)
EMR機能
EMR事例
まとめ

Apache Hadoopとは？
Big Dataを扱うために：
– スケーラブルな分散ストレージ
– 低価格で柔軟に行うことが出来る分析
Hadoop は上記を満たすオープンソース製品
– HDFS(Hadoop Distributed File System)
– 巨大なデータを扱えるバッチ処理用分散ファイル
システム。
– コモディティサーバに特化。
– MapReduce
– 分散処理である煩わしい点をカバーしてくれる

Apache Hadoopとは(2)

エンドユーザが受けるメリット
– 誰でも入手可能
– スケーラブル
– 柔軟性
– 実績も多く、PBオーダまでリニアにスケ
ール可能な、分析基盤が誰でも使える
–4000台までスケール

イメージで掴む
MapReduce

(map ‘( ))

( )

(reduce ‘( ))

大元の入力データ
チャンクに分解
Map処理の入力
(<a, > , <o, > , <p, > , …)

Map処理
Map処理の出力
(<a’, >, <o’, >, <p’, >, …)

(Shuffle処理)
Reduce処理の入力
(<a’, >, …)

Reduce処理
最終出力結果

RDBMSとHadoopの違い

RDBMS Hadoop
 事前定義したスキーマ  スキーマなし
 1台で稼働する事が前提  分散・協調して動く前提
 SQLによるアクセス  SQLでない複数言語サポート
 リニアにスケールしない  リニアにスケールする
 リアルタイム処理  バッチ処理
 小規模データ  大規模データ
 構造化データ  半構造化データ

Hadoopの課題
Hadoopのスケーラビリティを活かすには
大量のサーバが必要
購入してしまうと拡張するのも困難。
自由にノードを追加・縮小できない
データをHDFSだけに保存するのはリスク
 データ紛失のリスクがぬぐいきれない

Amazon Elastic MapReduceとは
Hadoopをオンデマンドにいつでも実行可能
• 使った分だけなので、低コスト
開発者は分析・解析アプリケーションに集中
• 結果を出すまでの最短パス
S3による入力・出力データを強力に保護
• データをロストしない仕組み

Amazon Elastic MapReduceとは(2)
Big Data処理のための煩雑な事を肩代わり
 サーバ調達、見積もり、チューニング・・・
解析をトライアンドエラー出来る
 ユーザ動向にあわせ、アドホックに解析可能
• 収集→保存→解析→アクションの
サイクルをもっと早く！
AWSの他サービスとのインテグレーション
 S3との連携機能
 JavaやRubyなどのSDKが利用可能

図で表すと・・・

OS
ラックへ電源とNW
HWの購入インス
設置を設定
トール

Hadoop Hadoop
Hadoop
基本設定インスクラスタ
稼働確認
トール構築

図で表すと・・・
EMRであれば・・・
OS
Hadoop
ラックへ電源とNW
HWの購入インス
設置を設定

Hadoop
トール

何ノードで
あげるか、
基本設定
Hadoop
インス
稼働確認
Hadoop
クラスタ
Hadoop

指定するトール構築
稼働確認

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

Hadoop 0.20 Hadoop 0.18
Hive 0.5/0.7 Hive 0.4
Pig 0.6 Pig 0.3
Cascading 1.1 Cascading 1.1

EMRの全体アーキテクチャ
Amazon S3
巨大なデータセットや、
膨大なログをアップロード
データ Input
ソース Amazon S3
Data

Output
Master Task
Amazon Elastic
Instance Instance
Data
MapReduce
Group Group
MapReduce Amazon SimpleDB
Code/ コード Master Task
Script Service Node
HiveQL Node
s
Pig Latin
Cascading
Task
Node
メタデータ
複数のジョブフローの
HiveQL
ステップを実行
Pig Latin
アドホック
Core クエリ
Instance
Group
Core BI
Node HDFS JDBC Apps
ODBC

Core
Node HDFS

EMR Hadoop Cluster

EMRのコンポーネント
インスタンスグループ
 Master, Core, Taskの3つ
Master
 ジョブ全体を管理。1台のみ起動。
Core Node
 HDFSのDataNodeを持つ。TaskTrackerも搭載
し、MapReduceも実行。複数台起動。
Task Node
 オプション。MapReduceのみを実行。複数起動

EMRを支えるAWSプラットフォーム
Amazon EC2
 スケーラブルなコンピュートリソース
 柔軟でスケールアップ、スケールアウト可能
Amazon S3
 スケーラブルなWebストレージサービス
 99.999999999%の堅牢性、セキュアで非常
に安価
 EMRのデータ及びアプリケーションのアップ
ロード先

EMRを支えるAWSプラットフォーム(2)
SimpleDB
 管理不要で可用性重視のAmazon独自
NoSQLサービス
 カラム指向で簡易クエリも付属
 EMRのジョブ状態情報を維持
IAM
 EMRのアクションを制限可能
• ジョブフローをTerminateできない等
 現状ではコマンドラインからのみ。

• ジョブフローを起動して以下で管理可能
• AWS マネージメントコンソール
• コマンドライン
• REST API

好きな言語で利用可能

Webブラウザ上の管理コンソール
APIおよびSDKからも利用可能
 PHP
 Ruby
 Java
 …

EMRでのアプリケーション開発
Hadoop Streaming
 Perl、PHPなどのstdin/stdoutで連携
 既存言語での利用が可能
Hive
 SQLライクにクエリが記述可能
 アドホックなクエリに最適
MapReduceアプリケーション
 Javaで記述する
 自由度も高いが、大変な面も。

elastic-mapreduce --create --name emrrun1
--stream --master-instance-type m1.small
--slave-instance-type m1.small
--num-instances 3 --mapper
s3://elasticmapreduce/samples/wordcount/wo
rdSplitter.py --input
s3://elasticmapreduce/samples/wordcount/inp
ut --output s3://ohtaniprotected/emrtest_1
--reducer aggregate --region ap-northeast-1

#!/usr/bin/python
import sys
import re
def main(argv):
line = sys.stdin.readline()
pattern = re.compile("[a-zA-Z][a-zA-Z0-9]*")
try:
while line:
for word in pattern.findall(line):
print "LongValueSum:" + word.lower() + "t" + "1"
line = sys.stdin.readline()
except "end of file":
return None
if __name__ == "__main__":
main(sys.argv)

Hadoopの
ノードを
動的に追加

elastic-mapreduce
--add-instance-group TASK
--instance-count 1
--instance-type m1.small --jobflow $JOBID$
--region ap-northeast-1

EMR機能: 稼働中ジョブフローの拡張
利用シナリオ: ジョブフローの高速化
 要件変更によるジョブフローの実行速度の向上
 ジョブの再起動なしに、ジョブにかけるコストとパフォーマン
ス対比を変更できる
Job Flow
Job Flow
Job Flow
4ノード 9ノードへ 25ノード
起動拡張へ
更に拡張

残り時間
残り時間
14 Hours
7 Hours
残り時間
3 Hours

EMR機能: 稼働中ジョブフローの拡張/伸縮
利用シナリオ: 柔軟なデータウェアハウスクラスタ
 クラスタサイズをリソースの必要性に応じて変更
(例：日中のクエリ実施 vs 夜間バッチ処理)
 コスト削減とクラスタ利用シーンに応じた柔軟性の確保を両立
データウェアハウス
(バッチ処理中)
データウェアハウスデータウェアハウス
(通常時) (通常時)

25ノード 9ノードへ
9ノード
へ戻す
起動
拡張

増減できるのはタスクノード
コアノードは増加のみ

EMR+Spotインスタンス”ランデヴー”

EMRを活用し始めると、更にアドホックなクエ
リをどんどん実行したくなる
 分析・解析を促進→サービスやアプリ改善
 しかし、コスト的に抑えておきたい
EMRとSpotインスタンスのインテグレーション
 Spotインスタンスって？？？

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

オンデマンドリザーブドスポット
占有インスタンス
インスタンスインスタンスインスタンス
•従量課金制 •初期費用 + 従量 •指定した価格で •マルチテナント
課金従量課金を単一顧客が占
•1年コミットで •時間当たり有
•時間あたり $56、時間当た $0.005という場 •$10/リージョン、
$0.03開始り $0.01から開合も時間あたり
始 $0.105

規制や、コン
スパイク対応本番利用アドホックな
プライアンス
評価検証定常的な利用用途
対策

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

Spotインスタンスの詳細
EC2インスタンス購入オプションの一つ
コスト削減効果が非常に高い
 使用していないEC2キャパシティに指値
 EMRでのアドホックな追加クエリに最適
オンデマンドやリザーブドと異なる挙動
 入札した価格に見合う間だけ利用可能
 AWSのリザーブド・オンデマンドの余剰リソ
ースを低価格で貸し出し
リージョン毎・ゾーン毎に指定可能に

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

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

EMR機能: Spotインスタンスの活用
Spotインスタンス=利用者が指値を入れるインスタンス
利用シナリオ: ジョブのランニングコストを抑えたい
 オンデマンドのm2.xlarge 4ノードで開始
 処理の高速化のためスポットインスタンスで5ノード追加

スポットなしのコスト
Job Flow
4 instances *14 hrs * $0.50 =
Job Flow
$28
4ノードで Spot
5ノード
起動
追加
スポットありのコスト
4 instances *7 hrs * $0.50 =
$13 +
残り時間 5 instances * 7 hrs * $0.25 =
残り時間 $8.75
14時間 Total = $21.75
7時間

時間の削減効果: 50%
コスト削減効果: ~22%

EMR+Spotの使いどころ
ユースケース Master Core Instance Task Instance
Instance Group Group
Group
長時間稼働のジョオンデマンドオンデマンド Spot
ブフローの高速化
低コストで実行し Spot Spot Spot
たいジョブ
クリティカルデーオンデマンドオンデマンド Spot
タを扱うジョブ
アプリケーション Spot Spot Spot
のテスト

コストを抑えつつ、利用目的にあわせて柔軟に変更可能

その他の機能
クラスタインスタンスタイプのサポート
 US東海岸のみ
 通常インスタンスと比較し速度が大幅に向上するケ
ース
AWS上での最適化設定を施したワークフロー
 メモリインテンシブ設定など
ブートストラップアクション
 起動時にユーザがHadoopをカスタマイズできる余地
Hive 0.7
 HAVING句、IN句の導入
 ローカルモードクエリのパフォーマンス向上、カラ
ム圧縮効率の向上、動的パーティショニング
S3 マルチパートアップロードによるアップロード時間

EMRが有効な領域例
データマイニング/BI
 ログ解析、クリックストリーム分析、近似分析
データウェアハウスアプリケーション
大量ファイル処理・変換
バイオインフォマティクス(遺伝子解析)
金融シミュレーション(モンテカルロ計算等)
Webインデックス構築

クリックストリーム分析 – 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%改善

Razorfishの事例 –アーキテクチャ
-
Aggregat
e Ad Log File Export
APIs
Serving Files
data

Internet
Client Data Sources
Provided
Data

Presentation Layer

Direct Analytics
Processing via
Web Application Layer
Talend Data Flow Manager EMR

Cache Edge
OLAP Provisionin
g DB
ODBC

Cloud Storage S3 Elastic MapReduce
HBase/SDB

Razorfish様事例より引用

Sonetの事例
広告配信ログの分析
 1日平均10GB、年間3.65TB
 1年分5TBをS3にアップロードしてEMRで解析
 オンプレミスでの試算：初期費用で数千万円単位
 EMR+S3+SQSの価格：毎月50万円(年間600万円)
• コストを大幅に削減
 スポットインスタンスを活用して、アドホック分析
• 更にコストを50%削減

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

Sonet様AWSアドバンテージセミナ資料より引用

Foursquareの事例

スマートフォンのチェックインデータ
 10M+ユーザ、15M+地域、1Bチェックイン
利用用途
 機械学習、データ分析、トレンド分析、
レポーティング
EMR平均40ノードクラスタを動的に起動
 RubyでHadoop Streaming
 地域の近似性や誰がチェックインしてるか

Foursquareの事例

ログ収集：Apache Flume
ログ保存：S3
ログ解析：EMR

オンデマンド
とSpotを併用

Etsy

年商$30M規模の巨大小売サイト
842,000,000PV
434GBのログ
ログ解析とリコメンデーションエンジンでEMR
を利用
 S3にHTTPログを時間ごとにアップロード
 EMRで解析

本日ご紹介できなかったEMRユーザ

EMRのロードマップ

より最新バージョンのHadoopサポート
“実験的な”最新版のHadoopサポート
And more to come…

EMRに関連する都市伝説

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

物理ハードウェア vs 仮想化
 確かに物理ハードウェアの方が早い場合が多い
大事な点はEMRのもたらす柔軟性・拡張性
 EMR=スケーラブルなインフラ(EC2/S3/SimpleDB)＋
スケーラブルなフレームワーク(Hadoop)
 特にHadoop固有の性質としてスケールアウトが非常に有効
 伸縮自在にHadoopを使えるメリット

Q.オンプレミスHadoopの方が安い
物理ハードウェアは最近本当に安い
 Hadoopであれば高価なハードウェアは要らない
 HDFSによるレプリケーション
NW機器のコストは別
 ラック越えしたあたりからコストはぐっと高くなる
調達の時間的コストも別
 ハードウェア調達して、インストール・設定するコストは無駄
膨大に増え続けるデータ量に比例してハードウェアを買い続
けるのも非効率
 ハードウェアを購入すると、分析・解析が制限されてしまう
HDFSの堅牢性(HDFSだけで本当に大丈夫か)
 バックアップの取得、またはマスタからロードしたくなる
• そこまで含めてコスト・運用効率があるか
 EMRであれば、S3の堅牢性で全て解決

S3のスケール

Peak Requests: 449 Billion
290,000+
per second
262 Billion

102 Billion

40 Billion
2.9 Billion 14 Billion

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

Total Number of Objects Stored in Amazon S3

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

EMRのHadoopは深刻な問題に対してはパッチを適用
 Hadoopの深刻なバグを低コストで回避可能
定期的にメンテナンス、バージョンアップに対応
 現状は0.18.3/0.20.2
ユーザの方でBootstrapAction時に差し替えも可能
 ただしEMR側での最適化が効かなくなるデメリットも
 ご利用は計画的に！
アプリケーション/データはユーザが開発
 ソリューションプロバイダさんがご支援可能

Q.AWSもリソースが足りなくなるのでは？
アマゾンドットコムが2000年当時年商27.6億ドルの
企業であった時に必要なキャパシティと同等のものを
AWSは毎日追加しています。
EMRだけでなく、様々なユースケースを含めてリソース
調達
 リソースの利用率を出来るだけ100%にもっていく→規模の経
済
 オンデマンド、リザーブド、そしてSpotでの利用
EMRでも多くのお客様から台数緩和申請
 20台を超える場合の緩和申請
• http://aws.amazon.com/jp/contact-us/ec2-
request/

クラウド上での大量データ処理

データの生
成・保存、
並列分析 (ニア)
インデクシ
構造化データデータ保存リアルタイム
処理ング、アグ
半構造化データリゲーショ分析
ン

Batch Tier Speed Tier

S3 Hadoop HBase
EMR SimpleDB
Cassandra
MongoDB
RDBMS

大規模データ処理＝クラウドが最も活躍できる場所
- EMRを中心にしたその一例 -

Cluster Spot 拡張 Elastic
Hadoop EMR Compute インス Batch
HPC タンス縮退 Processing

Hadoop オンデマンドで Each VM = コスト削減クラスタのスケーラブ
デファクト使える 2 Xeon “Spot 状況に応じてルな大規模
分散処理 “Nehalem” price” 拡張またはデータ処理
スケーラブルな
Quad-core 縮退できる
フレームインフラ基盤
ワーク 10G Ethernet
2 GPGPUs

まとめ
EMRはBigdataのためのキラーソリューション
 大量ログ解析のニーズは大きい
 Hadoopは既にデファクト
EMRはHadoopの煩雑さをカバーするサービス
 大量データ解析を、高い費用対効果で実現
 開発者は本来やるべきアプリ(分析、解析等)に集中
 データはS3で堅牢性を維持し、クラウドのスケーラ
ビリティのメリットを徹底的に活用

20111130 10 aws-meister-emr_long-public

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 20111130 10 aws-meister-emr_long-public

Semelhante a 20111130 10 aws-meister-emr_long-public (20)

Mais de Amazon Web Services Japan

Mais de Amazon Web Services Japan (20)

20111130 10 aws-meister-emr_long-public