クラウドネイティブなアーキテクチャでサクサク解析

クラウドネイティブなアーキテクチャでサクサク解析

@imai_factory

第 27 回 データマイニング +WEB ＠東京　 ( #TokyoWebmining 27th) 

2

自己紹介• 名前

–今井雄太 ( @imai_factory )

• 仕事–ソリューションアーキテクトという仕事をしていて、主にアド、デジタルマーケティング、スタートアップのお客様のアーキテクティングのお手伝いをしています。

3

今日のアジェンダ• Amazon流の AWSの使い方

• クラウドネイティブなアーキテクチャとは？

• AWS上でデータ解析を行うために理解しておくべきコンセプト

Amazon 流AWS の使い方

5

Werner Vogels

CTO of Amazon.com

平均 11.6秒ごとにデプロイ1時間で最大 1,079回のデプロイ

1回で平均 1万台のホストへデプロイ最大で 3万台のホストへ同時にデプロイ

LBを介して複数の AZに配置されたEC2へトラフィックを分散

新しいバージョンのコードをデプロイしたクラスタを新たに構築

テストして問題なければLBを新しいクラスタに振り向ける

問題が発生したら元のクラスタにトラフィックを戻す

環境をコピーしてABテストなども容易に実施可能

12

デプロイのスピードが早くて、リスクも少ないと

フィードバックループをより多く回せる

13

Amazon は自分たちのアーキテクチャをクラウドに最適化することにより、ビジネスを加速させている。

クラウドネイティブなアーキテクチャ

15

Controllable - 柔軟なコントロールResilient - 高い耐障害性

Adaptive - 状況の変化への追従性Data Driven - フィードバックループを回す

16

Controllable柔軟なコントロール

17

柔軟なコントロール

•システムを小さなコンポーネントにわけて疎結合に

•常にコストを意識したアーキテクチャを

コントロールしにくいアーキテクチャ• Webサーバーが CPUを食う？• DBがメモリを食う？• 画像がトラフィックを食う？• バッチが夜間に CPUを食う？

EC2インスタンス

本番環境

Amazon Route 53

EIP

特性の違うアプリが同一リソース上で動いているので扱いにくい

コントロールしやすいアーキテクチャ？

Amazon Route 53

LB1 LB2

API1 API2

IMG

Batch

DB1 DB2AW

S

アプリケーションごとにリソースを分ける

20

USD0/hr

USD17/hr

USD35/hr

USD52/hr

5AM 12PM 7PM 2AM

USD0/hr

USD17/hr

USD35/hr

USD52/hr

5AM 12PM 7PM 2AM

リザーブド オンデマンド スポット

事例： Pinterest

5AM 12PM 7PM 2AM

Provisioned Busy

AWS利用 リザーブド & スポット

システムが密結合しているとこんなに頻繁に構成変更はできない。

リソースが一定だと、如何に稼働率を上げるかが重要になり、 1サーバーにいろんな役割を持たせがち。結果、密結合なシステムができあがる。

オンプレミス

usecase

21

コンポーネントを小さくわけると・・

• 各コンポーネントごとに適切なスケーリングが可能なので無駄が出にくい

• スケールするときに他のコンポーネントとの兼ね合いを気にする必要がないので要求に迅速に対応できる

22

Resilient高い耐障害性

23

高い耐障害性

•障害を例外として捉えない

•障害が起こる前提でシステムを考える

24

事例： S3(Simple Storage Service)

LB

APIINDEX STORAGE

機能ごとにコンポーネント化し、それぞれに冗長性をもたせる。これによりホスト単位の障害でシステ

ムは止まらなくなる。

更に Availability Zone単位で構成を冗長化。AZが落ちてもシステムは止まらない。

usecase

25

NetFlixにはいたずらな猿たちが・・

usecase

Chaos MonkeyLatency Monkey

Conformity MonkeyDoctor MonkeyJanitor Monkey

Security Monkey

and

Chaos Gorilla

26

Adaptive状況変化への追従性

27

状況変化への追従性

•何も仮定しない

•キャパシティプランニングは後から精緻にすればよい

EC

2サーバの数

4/12/2008

Facebook上での公開

トラフィックの急増にも対応( ピーク時は5000サーバー )

4/14/2008 4/16/2008 4/18/2008 4/20/2008

ソーシャルアプリは爆発力を秘めている

usecase

29

AWSなら

• スモールスタートはもちろん

• ラージスタートもできる

AWS

Data Drivenフィードバックループを回

す

31

フィードバックループを回す

•すべての事象をロギングする

•データはリアルタイム性が高いほど価値が高くなる

•フィードバックループは小さく

32

Controllable - 柔軟なコントロールResilient - 高い耐障害性

Adaptive - 状況の変化への追従性Data Driven - フィードバックループを回す

AWS上でデータ解析を行うために

理解しておくべきコンセプト

34

AWSで解析や計算を行う際にメリットを最大限にレバレッジするための３つのコンセプト

1. Data First2. AWS is software3. Workflow driven

Concept1:Data First

36

S3: Simple Storage Service

• AWSの最初のサービスのひとつ。（もうひとつは SQS)

• データの堅牢性が高く、格納容量に制限がないのが大きな特徴。

• 様々な他の AWSサービスからも利用されている。Storage

37

S3

S3 as a origin data store

Amazon RDS

SnapshotAmazon EBS

Amazon EC2

DynamoDBAmazon EMR Amazon Redshift

backupt

Data

CloudFrontContents

38

S3

S3 上のデータ以外はステートレスにできる

Amazon RDS

SnapshotAmazon EBS

Amazon EC2

DynamoDBAmazon EMR Amazon Redshift

backupt

Data

CloudFrontContents

Glacier RDS

EMR

EMR

RedShift

DynamoDB

Data Pipeline

S3

Data

ETL

Sum

WebApp

BI

Dashboard

データ解析まわりのエコシステム

Store

Archive

Glacier RDS

EMR

EMR

RedShift

DynamoDB

Data Pipeline

S3

Data

ETL

Sum

WebApp

BI

Dashboard

データ解析まわりのエコシステム

Store

Archive

• まずは S3にデータを入れておく

• 容量無制限なのでディスク追加などを考慮しなくてすむ

• 耐久性が高いのでデータ損失の心配をせずにすむ

• そして、後の解析・計算工程も柔軟に構築可能

RedShiftData Warehouse

DynamoDBNoSQL

S3

Data

Elastic MapReduceHadoop

Concept1: Data First

増え続けるデータは S3 へ

必要に応じて解析・分析クラスタを構築

Concept2:AWS is software

43

AWS は様々なリソースやアプリケーショ

ンを提供してくれますが・・

44

すべてソフトウェアとして扱えるのが大きな特徴

コントロール

複数のマシンで実施する作業を、１台ずつ起動して SSHして・・のような作業が不要になる

45

ex. EC2 を任意の台数起動して特定の仕事をさせる

$ aws ec2 run-instances \ --image-id ami-39b23d38 \ --instance-type t1.micro \ --min-count 10 \ --max-count 10 \ --user-data IyEvYmluL3NoCndoaWxlIHRydWU7IGRvIGN1cmwgaHR0cDovL1lPVVJfSE9TVDsgZG9uZQ==

#!/bin/shwhile true; do curl http://YOUR_HOST; done

user-data を使うと EC2 起動時にシェルスクリプトを渡して、起動後実行させることができる

上記は 10 台の EC2 を起動して、下記のシェルスクリプトを実行させているサンプル。（ user-data は Base64 にエンコードする必要がある )

46

ex. Hadoop クラスタを立ちあげて特定の仕事をさせて終わったらクラスタを捨て

る

$ elastic-mapreduce \ --create --stream \ --num-instances 4 \ --slave-instance-type m1.large \ --master-instance-type m2.4xlarge \ --input s3://YOUR_INPUT_BUCKET --output s3://YOUR_OUTPUT_BUCKET --mapper s3://YOUR_MAPPER_PROGRAM_FILE --reducer s3://YOUR_REDUCER_PROGRAM_FILE

Elastic MapReduce では下記のように仕事の内容 (streaming の mapperと reducer を指定）と、データの in/out を指定してクラスタを起動することにより、クラスタ起動 -> ジョブを処理 -> クラスタを破棄　というパイプラインを自動化できる

上記は Elastic MapReduce のコマンドラインクライアントから実施しているが、 API や SDK 経由でも実行可能。

47

AWS はソフトェアなので自動化が容易

SSH や RDP したら負け（本番環境の話。笑）

Concept2: AWS is software

Concept3:Workload driven

Resource Driven

リスク対策としての余剰投資。これはある程度しょうがない。

リソース不足。これはヤバイ。広告のレポートが間に合わなくなるとか、次の仕事を待たせなきゃ

いけないとか。

予め Hadoop クラスタのキャパシティが決まっていると・・・

50

もちろん Resource Driven が最適な環境もあ

りますが、クラウドを利用すると・・

S3

データ

Workload Driven

必要なときにワークロードに合わせてキャパシティを用意することもできる

ワークロードに合わせてクラスタを作るので待ちも余剰もない

複数のクラスタを並列に起動することも可能

データは S3 においておけば

共用利用できる

52

AWS では時間とリソースが等価交換できる。

S3 にデータがあれば複数のクラスタから共有資源として利用できる。

Concept3: Workflow Driven

まとめ

54

フィードバックループを回す• クラウド外のアーキテクチャを

そのままクラウド上で再現してもあまりメリットがない

• Hadoop 、 SQL 等使われる技術のコンセプトは変わらない。

• 変わるのはインフラに対しての考え方。より柔軟に。