Upload
amazon-web-services-japan
View
2.214
Download
0
Embed Size (px)
DESCRIPTION
ほぼ週間AWSマイスターシリーズのAmazon Elastic MapReduceの回の資料です。
Citation preview
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処理
Reduce処理
最終出力結果
(Shuffle処理)
Map処理の入力
(<a, > , <o, > , <p, > , …)
Map処理の出力
(<a’, >, <o’, >, <p’, >, …)
Reduce処理の入力
(<a’, >, …)
チャンクに分解
Hadoop ”スタック”
RDBMSとHadoopの違い
RDBMS
事前定義したスキーマ
1台で稼働する事が前提
SQLによるアクセス
リニアにスケールしない
リアルタイム処理
小規模データ
構造化データ
Hadoop
スキーマなし
分散・協調して動く前提
SQLでない複数言語サポート
リニアにスケールする
バッチ処理
大規模データ
半構造化データ
Hadoopの課題
Hadoopのスケーラビリティを活かすには大量のサーバが必要
購入してしまうと拡張するのも困難。 自由にノードを追加・縮小できない
データをHDFSだけに保存するのはリスク
データ紛失のリスクがぬぐいきれない
Amazon Elastic MapReduce(EMR)
Amazon Elastic MapReduceとは
Hadoopをオンデマンドにいつでも実行可能
• 使った分だけなので、低コスト
開発者は分析・解析アプリケーションに集中
• 結果を出すまでの最短パス
S3による入力・出力データを強力に保護
• データをロストしない仕組み
Amazon Elastic MapReduceとは(2)
Big Data処理のための煩雑な事を肩代わり
サーバ調達、見積もり、チューニング・・・
解析をトライアンドエラー出来る
ユーザ動向にあわせ、アドホックに解析可能
• 収集→保存→解析→アクションの サイクルをもっと早く!
AWSの他サービスとのインテグレーション
S3との連携機能
JavaやRubyなどのSDKが利用可能
図で表すと・・・
HWの購入
ラックへ設置
電源とNWを設定
OS インストール
基本設定 Hadoop インストール
Hadoop クラスタ
構築
Hadoop 稼働確認
図で表すと・・・
HWの購入
ラックへ設置
電源とNWを設定
OS インストール
基本設定 Hadoop インストール
Hadoop クラスタ
構築
Hadoop 稼働確認
EMRであれば・・・
Hadoop 何ノードであげるか、指定する
Hadoop 稼働確認
EMRがサポートするHadoopスタック
Hadoop 0.20
Hive 0.5/0.7
Pig 0.6
Cascading 1.1
Hadoop 0.18
Hive 0.4
Pig 0.3
Cascading 1.1
EMR Hadoop Cluster
Amazon S3
Amazon SimpleDB
BI Apps
巨大なデータセットや、 膨大なログをアップロード データ
ソース
Code/ Script
s
Amazon S3
Service
Amazon Elastic MapReduce
HiveQL Pig Latin Cascading
MapReduce コード
複数のジョブフローのステップを実行
JDBC ODBC
HiveQL Pig Latin アドホック
クエリ
EMRの全体アーキテクチャ
Input Data
Output Data
メタデータ
Master
Instance
Group
Task
Instance
Group
Master
Node
Task Node
Task Node
Core
Instance
Group
HDFS
Core Node
Core Node
HDFS
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で記述する
自由度も高いが、大変な面も。
EMRデモ
例:Hadoop
Streaming
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
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
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
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)
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
Hadoopの
ノードを
動的に追加
elastic-mapreduce
--add-instance-group TASK
--instance-count 1
--instance-type m1.small --jobflow $JOBID$
--region ap-northeast-1
elastic-mapreduce
--add-instance-group TASK
--instance-count 1
--instance-type m1.small --jobflow $JOBID$
--region ap-northeast-1
elastic-mapreduce
--add-instance-group TASK
--instance-count 1
--instance-type m1.small --jobflow $JOBID$
--region ap-northeast-1
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インスタンスの活用
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%
EMR+Spotの使いどころ
ユースケース Master Instance Group
Core Instance Group
Task Instance Group
長時間稼働のジョブフローの高速化
オンデマンド オンデマンド Spot
低コストで実行したいジョブ
Spot Spot Spot
クリティカルデータを扱うジョブ
オンデマンド オンデマンド Spot
アプリケーションのテスト
Spot Spot Spot
コストを抑えつつ、利用目的にあわせて柔軟に変更可能
その他の機能
クラスタインスタンスタイプのサポート
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 Provisionin
g DB
OLAP
Client Provided
Data
HBase/SDB
ODBC
Razorfishの事例 –アーキテクチャ-
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で解析
Etsyアーキテクチャ
本日ご紹介できなかった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のスケール
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だけでなく、様々なユースケースを含めてリソース
調達
リソースの利用率を出来るだけ100%にもっていく→規模の経
済
オンデマンド、リザーブド、そしてSpotでの利用
EMRでも多くのお客様から台数緩和申請
20台を超える場合の緩和申請
• http://aws.amazon.com/jp/contact-us/ec2-request/
データ保存 並列分析
処理
データの生成・保存、インデクシング、アグリゲーショ
ン
Batch Tier Speed Tier
(ニア) リアルタイム 分析
構造化データ 半構造化データ
クラウド上での大量データ処理
HBase SimpleDB Cassandra MongoDB RDBMS
Hadoop S3 EMR
大規模データ処理=クラウドが最も活躍できる場所 - EMRを中心にしたその一例 -
Hadoop EMR Cluster
Compute HPC
Spot
インスタンス
拡張
縮退
Elastic
Batch
Processing
Hadoop デファクト 分散処理 フレーム ワーク
オンデマンドで 使える スケーラブルな インフラ
Each VM = 2 Xeon “Nehalem” Quad-core 10G Ethernet 2 GPGPUs
コスト削減 “Spot price”
クラスタの 状況に応じて 拡張または 縮退できる
スケーラブルな大規模データ処理基盤
まとめ
EMRはBigdataのためのキラーソリューション
大量ログ解析のニーズは大きい
Hadoopは既にデファクト
EMRはHadoopの煩雑さをカバーするサービス
大量データ解析を、高い費用対効果で実現
開発者は本来やるべきアプリ(分析、解析等)に集中
データはS3で堅牢性を維持し、クラウドのスケーラビリティのメリットを徹底的に活用
Q & A
ご参加ありがとう ございました
Copyright © 2011 Amazon Web Services