クラウドネイティブなアーキテクチャでサクサク解析
@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で解析や計算を行う際にメリットを最大限にレバレッジするための3つのコンセプト
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
すべてソフトウェアとして扱えるのが大きな特徴
コントロール
複数のマシンで実施する作業を、1台ずつ起動して 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 等使われる技術のコンセプトは変わらない。
• 変わるのはインフラに対しての考え方。より柔軟に。