クラウドネイティブな
アーキテクチャでサクサク解析
@imai_factory
第27回 データマイニング+WEB @東京 ( #TokyoWebmining
27th)
自己紹介
• 名前
– 今井雄太( @imai_factory )
• 仕事
– ソリューションアーキテクトという仕事をし
ていて、主にアド、デジタルマーケティン
グ、スタートアップのお客様のアーキテク
ティングのお手伝いをしています。
2
今日のアジェンダ
• Amazon流のAWSの使い方
• クラウドネイティブなアーキテク
チャとは?
• AWS上でデータ解析を行うために理
解しておくべきコンセプト
3
Amazon流
AWSの使い方
5
Werner Vogels
CTO of Amazon.com
平均11.6秒ごとにデプロイ
1時間で最大1,079回のデプロイ
1回で平均1万台のホストへデプロイ
最大で3万台のホストへ同時にデプロイ
LBを介して複数のAZに配置された
EC2へトラフィックを分散
新しいバージョンのコードを
デプロイしたクラスタを新たに構築
テストして問題なければ
LBを新しいクラスタに振り向ける
問題が発生したら
元のクラスタにトラフィックを戻す
環境をコピーして
ABテストなども容易に実施可能
12
デプロイのスピードが早く
て、リスクも少ないと
フィードバックループを
より多く回せる
クラウドネイティブな
アーキテクチャ
14
Controllable - 柔軟なコントロール
Resilient - 高い耐障害性
Adaptive - 状況の変化への追従性
Data Driven - フィードバックループを回す
15
Controllable
柔軟なコントロール
柔軟なコントロール
• システムを小さなコンポーネ
ントにわけて疎結合に
• 常にコストを意識したアーキ
テクチャを
16
コントロールしにくいアーキテク
チャ
• WebサーバーがCPUを食う?
• DBがメモリを食う?
• 画像がトラフィックを食う?
• バッチが夜間にCPUを食う?
EC2
インスタンス
本番
環境
Amazon
Route 53
EIP
特性の違うアプリが同一リ
ソース上で動いているので
扱いにくい
コントロールしやすいアーキテク
チャ?
Amazon
Route 53
アプリケーションごとに
リソースを分ける
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
19
5AM 12PM 7PM 2AM
Provisioned Busy
AWS利用 リザーブド& スポット
オンプレミス
コンポーネントを小さくわける
と・・
• 各コンポーネントごとに適切なス
ケーリングが可能なので無駄が出に
くい
• スケールするときに他のコンポーネ
ントとの兼ね合いを気にする必要が
ないので要求に迅速に対応できる
20
21
Resilient
高い耐障害性
高い耐障害性
• 障害を例外として捉えない
• 障害が起こる前提でシステム
を考える
22
事例:S3(Simple Storage Service)
23
NetFlixにはいたずらな猿たち
が・・
24
25
Adaptive
状況変化への追従性
状況変化への追従性
• 何も仮定しない
• キャパシティプランニングは
後から精緻にすればよい
26
EC2
4/12/2008
Facebook
( 5000 )
4/14/2008 4/16/2008 4/18/2008 4/20/2008
ソーシャルアプリは爆発力を秘めてい
る
AWSなら
• スモールスタートはもちろん
• ラージスタートもできる
28
Data Driven
フィードバックループを回
す
フィードバックループを回す
• すべての事象をロギングする
• データはリアルタイム性が高
いほど価値が高くなる
• フィードバックループは小さ
く 30
31
Controllable - 柔軟なコントロール
Resilient - 高い耐障害性
Adaptive - 状況の変化への追従性
Data Driven - フィードバックループを回す
AWS上で
データ解析を行うために
理解しておくべきコンセプト
AWSで解析や計算を行う際に
メリットを最大限にレバ
レッジするための3つのコ
ンセプト
1. Data First
2. AWS is software
3. Workflow driven
33
Concept1:
Data First
S3: Simple Storage Service
• AWSの最初のサービスのひと
つ。(もうひとつはSQS)
• データの堅牢性が高く、格納
容量に制限がないのが大きな
特徴。
• 様々な他のAWSサービスから
も利用されている。
35
Storage
36
S3
S3 as a origin data store
Amazon RDS
SnapshotAmazon EBS
Amazon EC2
DynamoDB
Amazon EMR Amazon Redshift
backupt
Data
CloudFront
Contents
37
S3
S3上のデータ以外はステートレスにできる
Amazon RDS
SnapshotAmazon EBS
Amazon EC2
DynamoDB
Amazon EMR Amazon Redshift
backupt
Data
CloudFront
Contents
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にデータを入れてお
く
• 容量無制限なのでディスク追
加などを考慮しなくてすむ
• 耐久性が高いのでデータ損失
の心配をせずにすむ
• そして、後の解析・計算工程
も柔軟に構築可能
RedShift
Data Warehouse
DynamoDB
NoSQL
S3
Data
Elastic MapReduce
Hadoop
Concept1: Data First
Concept2:
AWS is software
42
AWSは様々な
リソースやアプリケーショ
ンを提供してくれます
が・・
43
すべてソフトウェアとして
扱える
コントロール
44
ex. EC2を任意の台数起動して特
定の仕事をさせる
$ aws ec2 run-instances 
--image-id ami-39b23d38 
--instance-type t1.micro 
--min-count 10 
--max-count 10 
--user-data
IyEvYmluL3NoCndoaWxlIHRydWU7IGRvIGN1cmwgaHR0cDovL2lwLTEwLTEyMC00Ni0xODAuYXAtbm9ydGhlYXN0LTEu
Y29tcHV0ZS5pbnRlcm5hbDsgZG9uZQ==
#!/bin/sh
while true; do curl http://ip-10-120-46-180.ap-northeast-1.compute.internal; done
user-dataを使うとEC2起動時にシェルスクリプトを渡して、起動後実行させ
ることができる
上記は10台のEC2を起動して、下記のシェルスクリプトを実行させているサン
プル。(user-dataはBase64にエンコードする必要がある)
45
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経由でも実行可能。
46
AWSはソフトェアなので自動
化が容易
SSHやRDPしたら負け
(本番環境の話。笑)
Concept2: AWS is software
Concept3:
Workload driven
Resource Driven
リスク対策とし
ての余剰投資。
これはある程度
しょうがない。
リソース不足。これはヤ
バイ。広告のレポートが
間に合わなくなるとか、
次の仕事を待たせなきゃ
いけないとか。
予めHadoopクラスタのキャパシ
ティが決まっていると・・・
49
もちろんResource Drivenが
最適な環境もありますが、
クラウドを利用すると・・
S3
データ
Workload Driven
必要なときにワークロードに合わせて
キャパシティを用意することもできる
ワークロードに
合わせてクラス
タを作るので待
ちも余剰もない
複数のクラスタ
を並列に起動す
ることも可能
データはS3にお
いておけば共用
利用できる
51
AWSでは時間とリソースが等
価交換できる。
S3にデータがあれば複数の
クラスタから共有資源とし
て利用できる。
Concept3: Workflow Driven
まとめ
フィードバックループを回す
• クラウド外のアーキテクチャをそ
のままクラウド上で再現してもあ
まりメリットがない
• Hadoop 、SQL等使われる技術のコ
ンセプトは変わらない。
• 変わるのはインフラに対しての考
え方。より柔軟に。
53
クラウドネイティブなアーキテクチャでサクサク解析

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