amazon ec2 container service deep dive
TRANSCRIPT
1
Amazon EC2 Container Service
Deep dive
Ryosuke Iwanaga
Solutions Architect, Amazon Web Services Japan
2
Agenda
• ContainerとDevOps
• Case studies– Sony: Batch jobs
• Summary
3
ContainerとDevOps
4
DevOps lifecycle
Build Test ProductionDevelopment
<>
<>
Application
CodeArtifact
5
DevOps lifecycle
Build Test ProductionDevelopment
<>
<>
+AMI Provisioning
Code
Application
CodeArtifact
Provisioning
Code
{}Config
{}Config
{}Config
6
After Docker…
+ <>+
Build Test ProductionDevelopment
<>
<>
+{} {} {}
7
After Docker…
+Provisioning
Code
<>
Application
Code
Docker
Image
+
DockerfileDocker
Image
Build Test ProductionDevelopment
8
Dev and Ops
• Dev– インフラに関するコードを書かずに、アプリをCI/CDする
– 価値あるコードを生み出し続ける
• Ops– どんなアプリが動くかに依存しないインフラ管理
– スケーラビリティ、コスト最適化
9
Infrastructure for Docker containersBuild Test ProductionDevelopment Registry
Service A
Service B
Service C
10
Resource Utility of Heterogeneous Containers
35%
85%
~80%
Amazon ECS
11
Resource Utility of Heterogeneous Instances
Amazon ECSAmazon EC2
Spot Fleet+
c3.xlarge
c3.xlarge
c3.xlarge
r3.8xlarge
r3.8xlarge
r3.8xlarge
c3.8xlarge
c3.8xlarge
c3.8xlarge
c3.4xlarge
c3.4xlarge
c3.4xlarge
r3.2xlarge
r3.2xlarge
r3.2xlarge
12
Cluster管理とScheduler
• Cluster管理
– 計算機群のリソース、状態を常に管理
• Scheduler
– Cluster全体を見て適切にContainerを配置
CPU: 500
Mem: 300
CPU: 10
Mem: 30 CPU: 2000
Mem: 1000
CPU: 10
Mem: 30CPU: 10
Mem: 30
Scheduler
Cluster Manager
13 Source: eurosys2013.tudos.org/wp-content/uploads/2013/paper/Schwarzkopf.pdf
14
Docker
Task
Container Instance
Amazon
ECS
Container
ECS Agent
ELB
Internet
ELB
User / Scheduler
API
Cluster Management Engine
Task
Container
Docker
Task
Container Instance
Container
ECS Agent
Task
Container
Docker
Task
Container Instance
Container
ECS Agent
Task
Container
AZ 1 AZ 2
Key/Value Store
Agent Communication Service
http://aws.typepad.com/sajp/2015/07/under-the-hood-of-the-amazon-ec2-container-service.html
15
Amazon ECS: Task Definition
16
Amazon ECS: Task Definition
• Containerの集合を定義– 必ず同じInstanceで稼働– 要求するリソースを指定
• CPU, memory, (Port)
• ボリュームも定義可能– Instanceのファイルシス
テムを利用できる
• バージョニングが可能
17
Task Definition: Container Definition{"name": "simple-demo","image": "foo/my-demo","cpu": 10,"memory": 500,"portMappings": [{"containerPort": 80,"hostPort": 80
}],"mountPoints": [{"sourceVolume": "my-vol","containerPath": "/var/www/my-vol"
}],"entryPoint": ["/usr/sbin/apache2","-D","FOREGROUND"
],"essential": true
},
{
"name": "busybox",
"image": "busybox",
"cpu": 10,
"memory": 500,
"volumesFrom": [
{
"sourceContainer": "simple-demo"
}
],
"entryPoint": [
"sh",
"-c"
],
"command": [
"while true; do /bin/date > /var/www/my-vol/date; sleep 1; done"
],
"essential": false
}
18
Task Definition: Overview
Shared data volume
PHP AppTime of day
App
Task Definition
19
Task Definition: Overview
Container
Instance
Schedule
Shared data volume
PHP AppTime of day
App
Task Definition Task
20
Amazon ECS: Service
21
Amazon ECS: Service
• Web/APIの様に長期稼働するワークロードに最適
• Taskを必要数保ってくれるスケジューラ– 自動復旧にも対応
• 新しいTask Definitionをデプロイしつつ切替
• Elastic Load Balancingとの連携も可能
22
Amazon ECS: Serviceの例
23
Amazon ECS: ServiceのUpdate
• Serviceが使うTask DefinitionをUpdateすると、新しいTaskをデプロイできる
• 空いているリソースで新しいTaskを起動しながら、徐々に古いTaskを止めていく– Blue-Green deployment
– 中間では、新旧のTaskが混在する
24
Cluster
Amazon ECS: ServiceのUpdate
Service
Task Definition:1
Task:1Task:1 Task:1
25
Cluster
Amazon ECS: ServiceのUpdate
Service
Task Definition:1 Task Definition:2
Task:1Task:1 Task:1
26
Cluster
Amazon ECS: ServiceのUpdate
Service
Task Definition:1 Task Definition:2
Task:1Task:1 Task:1Task:2 Task:2
27
Cluster
Amazon ECS: ServiceのUpdate
Service
Task Definition:1 Task Definition:2
Task:1Task:2 Task:2
28
Cluster
Amazon ECS: ServiceのUpdate
Service
Task Definition:1 Task Definition:2
Task:1Task:2 Task:2Task:2
29
Cluster
Amazon ECS: ServiceのUpdate
Service
Task Definition:1 Task Definition:2
Task:2 Task:2Task:2
30
Case: Sony (Batch jobs)
© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Konstantin Wilms, Enterprise Solutions Architect, AWS
Ben Masek, CTO, Solutions Engineering Group, Sony PSA
October 2015
CMP405
Containerizing VideoCreating the Next Generation Video Transcoding Pipeline
1秒1秒が大事
なぜ？
スピードがコストに跳ね返る
変化
なぜ？
動画エンコードのライフサイクルは速い
ソフトウェアは捨てられる
なぜ？
しばしば高いエンジニアリングコストでv1.0 v2.0 v3.0
AWSがどう役立ったか？
どのようにして？
エンコードの課題を解決するために
Amazon ECS
スケジュールAmazon EC2
処理
中心となるサービス群
保存AWS Lambda
繋ぎAmazon EFS &
Amazon S3
100ms単位課金インフラ管理不要
カスタムのバイナリ
中心となるストレージS3の代わり
コンテナとリンク
仕事の単位複数のクラスタ
エンコードに特化
スケジューラの代わり一般的なコンテナCPUを使い切る
アーキテクチャ全体
Source
Storage
Ingest
Container
Storage
EC2
Bootstrap
Transcode
ECS
EC2
Manager
Target
Stitch
Manager
入力ファイルがやってくると、イベント駆動なワークフローの全体が開始される
エンコードのためのAmazon ECSの起動用shellスクリプト
Amazon S3は長期保管用、Amazon EFSは一時的/コンテナ用ストレージ
中央集権のマネージャー
Amazon ECSのスケジューラを利用
マネージャーは分割し統合する
補助的な処理に、Lambda
他のワークフローとも、イベント駆動で連携
Auto Scaling
単純な複数AZを使ったスケール
ワークロードの単位で決定論的なスケジューリングのためにMin=Max=Desired
いつでも簡単に捨てることができる
インスタンスのタイプとトータルメモリが重要(~1.5MB エンコーダ)
Amazon EC2 インスタンスの初期化
起動時にECSクラスタに参加させる
ECSクラスタの各インスタンスでAmazon EFSをマウントする
どのAZかを知るためにメタデータにクエリする
これ以外の魔法は、全てDockerとLambdaで起こる
Amazon EFSでメディア処理
メディアのチャンク用の一時的なストレージ
メディアのソースとチャンクを移動する必要がない
Scales linearly 線形にスケールする 巨大なファイルを並列
で読み書きするのに理想的
ECSクラスタにアタッチするためのエンドポイントが各AZにある
Amazon ECSクラスタとスケジューラの設定
キャパシティの単位
共有ステータス、楽観的並行制御
単純なスケジューラの設計 – list*, describe*, run*, start*
10 CPU単位で我々はキャパシティ管理
‘swimlane’ でエンコードのアーキテクチャをモデル化
コンテナの構造
FROM ubuntu:14.04
ENV FLASK_JOB https://s3/xxx/jobs/h264.sh
ENV FLASK_FRAG https://s3/xxx/media/frag-000.mp4
ENV FLASK_THREADS 4
RUN wget http://xxx.com/ffmpeg/builds/ffmpeg-static.tar.xz \
&& tar xvfJ ffmpeg-static.tar.xz -C /usr/local/bin
RUN apt-get -y install libav-tools
RUN wget http://xxx.com/qpsnr.deb && dpkg -i qpsnr.deb
起動時の処理とスレッド数を環境変数で設定
固定した環境変数により簡単に開発とテストができる (デフォルトの呼び出しはデバッグ)
メモリの利用率を分析して、ホストのリソースを消費し尽くさないように
単一のAmazon ECS Task Definitionに紐付ける
420MBのイメージ、CLI無しなら350MB
CMD: s3 cp s3://…/bootstrap.sh . && chmod && bootstrap.sh
コンテナのデプロイパイプライン
docker save 2408e7a48bac \
| sudo docker-squash -t \
transcode-toolkit:1.01s \
-verbose | docker load
ロジックを起動処理で開始するので、非常に単純
Kitematicが役立つ 容量削減と高速なデプロイのために、
静的リンクしたバイナリを使う 自動化も可能だし、手動でもいい Webhooks & ビルド自動化 Unionファイルシステムのレイヤが増
えるので、コンテナをSquashする publicかprivateのDocker registryを
使う
44
まとめ
45
Batch Processing Open-source Paas Real-time Image Transformation
Solr Search Cluster
PaaSGaming Engine
Web Application Platform
Microservices Backend
Mapping Solution
Amazon ECS: Some Examples…
47
Amazon ECSまとめ
• 多数の本番稼働実績、多くのパートナー– 2,000 containersが動いているお客様、エンタープライズ・大規模企業
• とてもシンプルなのに強力– Master的なサーバ、Configuration KVS等の管理不要
– Service schedulerが、Blue-Greenデプロイや自動復旧してくれる
• 次世代のサービスインフラ– Just like “Amazon EC2” in 2006!
48
Appendix
49
Case: Remind
© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Eric Holmes & Michael Barrett, Remind
October 2015
DVO308
Docker & ECS in ProductionHow We Migrated Our Infrastructure from Heroku to AWS
Remind
• A messaging platform for teachers.
• Chat/announcements/files
• Over 30 million users
• Used actively in ~50% of U.S. public schools
• Over 2 billion messages delivered
• ~50 employees. ~30 engineers.
Heroku was great, but…
• Every app on Heroku is publicly accessible
• Databases need to be exposed to Internet traffic
• Limited visibility and control
What we want from a PaaS
• AWS
• Flexibility
• Shared patterns for deployment
• Easy service operation
• Containers/Docker
Building an Empire
Design Goals
• Easy to operate
• Open source
• Support 12-factor stateless apps (12factor.net)
• Swappable scheduling back-ends
• Stability!
• Docker images as a unit of deployment
Empire :: V2
Scheduler Router Control Plane
ECS ELB
Heroku Platform API
Spec + emp CLI
Empire :: V2
An open-source, self-hosted PaaS for running
twelve-factor Docker apps backed by AWS
services
Twelve-Factor Tenants
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, release, run
VI. Processes
VII. Port binding
VIII.Concurrency
IX. Disposability
X. Dev/prod parity
XI. Logs
XII. Admin processes
12factor :: Dependencies
“Explicitly declare and isolate dependencies”
FROM rubyRUN apt-get install imagemagickRUN bundle install
12factor :: Build, release, run
“Strictly separate build and run stages”
Empire
12factor :: Build
$ git push
12factor :: Release, Run
Config{}
Release
Amazon ECS
12factor :: Release, Run
$ cat Procfile
web: ./bin/web
worker: ./bin/worker
$ aws ecs list-services
arn:aws:ecs:us-east-1:***:service/api--web
arn:aws:ecs:us-east-1:***:service/api--worker
$ emp deploy org/api:latest
Status: Created v1 release.
Service Discovery
$ aws ecs describe-services --service api--web
"loadBalancers": [{
"containerName": "web”,
"containerPort": 9001,
"loadBalancerName”: "2888...a31d4c”
}]
$ curl http://api
Ok
12factor :: Concurrency
“Scale out via the process model”
$ emp scale web=10
$ aws ecs describe-service --service api--web
“desired-count”: 10
12factor :: Dev/prod parity
“Keep development, staging, and production as similar as
possible”
$ docker run --env-file <(emp env -a api) org/api
12factor :: Logs
“Treat logs as event streams”
$ emp log
“GET / HTTP/1.1” 200
STDOUT Amazon Kinesis
12factor :: Admin processes
“Run admin/management tasks as one-off processes”
$ emp run rake db:migrate
Migrated
69
Case: Coursera
© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Frank Chen, Coursera
Brennan Saeta, Coursera
October 2015
CMP406
Amazon ECS at CourseraPowering a general-purpose near-line execution
microservice, while defending against untrusted code
Bad Old Days of Batch Processing @ Coursera
Cascade
• PHP-based job runner
• Originally ran in screen sessions
• Polled APIs for new jobs
• Forced restarts on regular basis
due to unidentified memory leaks
• Fragile and unreliable
The early
days…
Bad Old Days of Batch Processing @ Coursera
Saturn
• Scala scheduled batch job runner• Powered by Quartz Scheduler library
• Better than Cascade, but…
• All jobs ran on same JVM, causing
interference
The not-
so early
days?
What Else Did We Look At?
Home-grown Tech
• Tried, but proved
to be unreliable
• Difficult to
handle
coordination and
synchronization
• Powerful, but
hard to
productionize
• Needs
developers with
experience
• Designed for
GCE first
• Not a managed
service, higher
Ops load
Amazon ECS to the Rescue
Little
maintenance
Integrated with
rest of AWSEasy to
develop for
However…
Amazon ECS is a great building block,
but we still need to build tools around it
for our purposes.
What We Built: Iguazú
Marissa Strniste (https://www.flickr.com/photos/mstrniste/5999464924) CC-BY-2.0
• Batch Job Scheduler for Amazon ECS
• Immediately
• Deferred (run once at X time)
• Scheduled recurring (cron-like)
• Programmatically accessible internally via
our standard APIs and clients
• Named for Iguazú falls
• World’s largest waterfall by volume
• We hope Iguazú handles a similar volume of jobs
Iguazú
Frontend
Iguazú
SchedulerIguazú
Backend
Iguazú: Architecture
CassandraServices Services
Iguazú
Admin
ECS
Workers
SQS
ECS API
Devs
Users
Iguazú: Developer / Ops User Interface
Deploying Jobs
Easy Deployment
1. Developers Merge into master. Done!
Jenkins Build Steps:
1. Builds zip package from master
2. Prepares Docker image with zip file
3. Pushes image into Docker registry
4. Registers updated jobs with
Amazon ECS API
Since April 2015…
65 jobs in
production
>1000 runs
per day
44 different
scheduled jobs
Programming Assignments at Coursera
The Security Challenge
Compiling and running untrusted, arbitrary code in
Amazon EC2
Would you like to compile and run C code from random
people on the Internet on your servers?
What We Built: GrID
Patrick Hoesly (https://www.flickr.com/photos/zooboing/5665221326/) CC-BY-2.0
• Service + architecture for grading
programming assignments
• Builds on Amazon ECS and Iguazú
• Named for Tron’s “digital frontier”
• Backronym: Grading Inside Docker
High-level GrID Architecture
Learners
GrID
Iguazú
S3 Bucket
ECS API
Grading
Machines
VPC
Firewalls
Production Acct GrID Grading Account