20111130 10 aws-meister-emr_long-public
Upcoming SlideShare
Loading in...5
×
 

20111130 10 aws-meister-emr_long-public

on

  • 3,032 views

ほぼ週間AWSマイスターシリーズのAmazon Elastic MapReduceの回の資料です。

ほぼ週間AWSマイスターシリーズのAmazon Elastic MapReduceの回の資料です。

Statistics

Views

Total Views
3,032
Views on SlideShare
3,030
Embed Views
2

Actions

Likes
4
Downloads
74
Comments
0

2 Embeds 2

https://twitter.com 1
https://www.chatwork.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

20111130 10 aws-meister-emr_long-public 20111130 10 aws-meister-emr_long-public Presentation Transcript

  • 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処理 最終出力結果
  • Hadoop ”スタック”
  • RDBMSとHadoopの違いRDBMS Hadoop 事前定義したスキーマ  スキーマなし 1台で稼働する事が前提  分散・協調して動く前提 SQLによるアクセス  SQLでない複数言語サポート リニアにスケールしない  リニアにスケールする リアルタイム処理  バッチ処理 小規模データ  大規模データ 構造化データ  半構造化データ
  • Hadoopの課題Hadoopのスケーラビリティを活かすには大量のサーバが必要購入してしまうと拡張するのも困難。自由にノードを追加・縮小できないデータをHDFSだけに保存するのはリスク  データ紛失のリスクがぬぐいきれない
  • Amazon Elastic MapReduce(EMR)
  • 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.18Hive 0.5/0.7 Hive 0.4Pig 0.6 Pig 0.3Cascading 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 SimpleDBCode/ コード Master TaskScript 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で記述する  自由度も高いが、大変な面も。
  • EMRデモ
  • 例:HadoopStreaming
  • elastic-mapreduce --create --name emrrun1--stream --master-instance-type m1.small--slave-instance-type m1.small--num-instances 3 --mappers3://elasticmapreduce/samples/wordcount/wordSplitter.py --inputs3://elasticmapreduce/samples/wordcount/input --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 --mappers3://elasticmapreduce/samples/wordcount/wordSplitter.py --inputs3://elasticmapreduce/samples/wordcount/input --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 --mappers3://elasticmapreduce/samples/wordcount/wordSplitter.py --inputs3://elasticmapreduce/samples/wordcount/input --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 --mappers3://elasticmapreduce/samples/wordcount/wordSplitter.py --inputs3://elasticmapreduce/samples/wordcount/input --output s3://ohtaniprotected/emrtest_1--reducer aggregate --region ap-northeast-1
  • #!/usr/bin/pythonimport sysimport redef 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 Noneif __name__ == "__main__": main(sys.argv)
  • elastic-mapreduce --create --name emrrun1--stream --master-instance-type m1.small--slave-instance-type m1.small--num-instances 3 --mappers3://elasticmapreduce/samples/wordcount/wordSplitter.py --inputs3://elasticmapreduce/samples/wordcount/input --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機能: 稼働中ジョブフローの拡張 利用シナリオ: ジョブフローの高速化  要件変更によるジョブフローの実行速度の向上  ジョブの再起動なしに、ジョブにかけるコストとパフォーマン ス対比を変更できる Job Flow Job Flow Job Flow4ノード 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 $284ノードで 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インデックス構築
  • 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%改善
  • Razorfishの事例 –アーキテクチャ - Aggregat e Ad Log File ExportAPIs Serving Files data Internet Client Data SourcesProvided 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で解析
  • 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のスケール Peak Requests: 449 Billion 290,000+ per second 262 Billion 102 Billion 40 Billion2.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 タンス 縮退 ProcessingHadoop オンデマンドで Each VM = コスト削減 クラスタの スケーラブデファクト 使える 2 Xeon “Spot 状況に応じて ルな大規模分散処理 “Nehalem” price” 拡張または データ処理 スケーラブルな Quad-core 縮退できるフレーム インフラ 基盤ワーク 10G Ethernet 2 GPGPUs
  • まとめ EMRはBigdataのためのキラーソリューション  大量ログ解析のニーズは大きい  Hadoopは既にデファクト EMRはHadoopの煩雑さをカバーするサービス  大量データ解析を、高い費用対効果で実現  開発者は本来やるべきアプリ(分析、解析等)に集中  データはS3で堅牢性を維持し、クラウドのスケーラ ビリティのメリットを徹底的に活用
  • Q&A
  • ご参加ありがとう ございました Copyright © 2011 Amazon Web Services