20180220 AWS Black Belt Online Seminar - Amazon Container Services

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
【AWS Black Belt Online Seminar】
Amazon Container Services
Ryosuke Iwanaga, Solutions Architect
Amazon Web Services Japan K.K.
2018.02.20

自己紹介
Ryosuke Iwanaga (岩永亮介)
• Twitter/GitHub @riywo
Amazon Web Services Japan K. K.
Solutions Architect
• Containers / DevOps / Serverless / Mobile / Developers
Before Amazon
• Software Engineer / Ops Engineer / DBA / etc.

内容についての注意点
• 本資料では2018年2月14日時点のサービス内容および価格についてご説明しています。最新の情報は
AWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。
• 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違が
あった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。
• 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費
税をご請求させていただきます。
• AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change
in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/.
Any pricing information included in this document is provided only as an estimate of usage charges
for AWS services based on certain information that you have provided. Monthly charges will be
based on your actual use of AWS services, and may vary from the estimates provided.

Agenda
• コンテナを利用した開発の実際
• Amazon Container Services 解説
• Amazon Elastic Container Registry (ECR)
• Amazon Elastic Container Service (ECS)
• Amazon Elastic Container Service for Kubernetes (EKS)
• AWS Fargate
• コンテナCI/CDパイプラインの構築
• コンテナのAuto Scaling

コンテナを利用した開発の実際

なぜコンテナが愛されているのか？
パッケージング配布イミュータブル
インフラストラクチャ

コンテナのユースケース
マイクロサービスアーキテクチャ
多数のマイクロサービスを同じ様に管理
非同期ジョブ実行 (バッチコンピューティング)
ジョブのリクエストに応じた柔軟なスケール
継続的インテグレーション、継続的デプロイ(CI/CD)
開発〜テスト〜本番まで一貫したイメージを利用

コンテナを利用した開発に必要な技術要素
• アプリのステートレス化
• レジストリ
• コントロールプレーン / データプレーン
• CI/CDパイプライン

アプリのステートレス化
コンテナの中に入れるのはステートレスなアプリに
コンテナのメリットを最大限活かせる
ステートが必要なものはコンテナの外に置く
例: RDBMSが必要 → Amazon RDS
例: オブジェクトの保存 → Amazon S3
参考: Twelve-factor Application – IV. Backing services
https://12factor.net/ja/backing-services

レジストリ
コンテナの起動元となるイメージの置き場所
アプリ＋実行環境をpush / 実行時にpullして起動
高い可用性、スケーラビリティが求められる
落ちたらデプロイ不能、同時に大量にpullされることも
自前で持つとその管理コストがかかる
→ Amazon ECR

コントロールプレーン / データプレーン
コントロールプレーン = コンテナの管理をする場所
どこでコンテナを動かす？生死は？いつ止める？
デプロイ時にどういう風に配置する？
→ Amazon ECS / Amazon EKS
データプレーン = 実際にコンテナが稼働する場所
コントロールプレーンからの指示に従って起動
各種状態をコントロールプレーンにフィードバック
→ AWS Fargate / Amazon EC2

CI/CDパイプライン
アプリのコード変更〜コンテナのデプロイを管理する
自動化することで誰がやっても同じようにデプロイ可能
ビルドはもちろん、単体テストや統合テスト、負荷テストも
カナリアデプロイやリージョンデプロイなども
途中にマニュアルでの承認を挟んでも良い
→ AWS CodePipeline / AWS CodeBuild
コントロールプレーンの違いを吸収することもできる
例: 同じコードから、AWSはECS / オンプレはKubernetesへ

Amazon EC2
AWS
CodePipeline
Source Build Deploy
AWS
CodeCommit
AWS
CodeBuild
Amazon RDS Amazon S3
Developer
Control plane
Data plane
Backing
service
Registry
CI/CD pipeline

Amazon Container Services 解説

レジストリ
Amazon ECR
コントロールプレーン
Amazon ECS
Amazon EKS
データプレーン
AWS Fargate

Amazon Elastic Container Registry (ECR)
フルマネージドの高可用性・スケーラブルなレジストリ
エンドポイントにアクセスできるならAWS外からでも利用可能
AWS IAMによる強力な認証管理機構
pullのみの権限、クロスアカウントアクセスも可能
ライフサイクルポリシーでイメージの自動クリーンアップ
何日以前や何個以上は自動削除といったルールを組み合わせて設定
NEW!!

AWS上の本番環境のコンテナを支える
AWS VPCネット
ワークモード
タスク配置
他のAWSサービス
との深い連携
ECS CLI…{ }
グローバル展開
強力なスケジューラ
オートスケーリング
CloudWatch メトリクス
ロードバランサ
Linux & Windows
NEW!!

450+%
年間アクティブユーザの成長
(2016年と比較)
数億コンテナ
が毎週起動
数百万もの
インスタンス上で
Amazon Elastic Container Service

Task: コンテナ(群)の実行単位
Task Definitionの情報から起動される
family:revisionで指定
1つ以上のコンテナを実行しているリソース
Task内のコンテナ群は同じホスト上で実行
CPUとメモリの上限を指定する
それを元にスケジュールされる
{
"family": “scorekeep",
"containerDefinitions": [
{
"name":“scorekeep-frontend",
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe"
},
{
"name":“scorekeep-api",
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api"
}
]
}
Task Definition – scorekeep:10
scorekeep-frontend
scorekeep-api
Task

Service: ロングランニングアプリ用スケジューラ
Taskの数を希望数に保つ
Task Definitionを新しくすると
Blue/Greenデプロイ
ELBと連携することも可能
メトリクスに応じてTask数の
Auto Scalingも可能(後述)
Servic
e
app:1
app:2
Elastic
Load Balancing
desiredCount: 2
maximumPercent: 200
minimumHealthyPercent: 100
Application
Auto Scaling

IAM Role: Task毎に異なる権限のAWS認証が可能
IAM RoleをTask毎に設定可能
AWS SDKを利用していれば自
動的に認証情報が得られる
アクセス鍵等の埋め込み不要
自分のRoleにない権限は当然
利用不可なので、セキュア
AWS IAM
Amazon
DynamoDB
Amazon S3
AWS IAM
DynamoDBRole
S3Role

AWS VPC ネットワークモード
Task毎にENIを自動割り当て
Security GroupをTask毎に設定可能
Task内のコンテナはlocalhostを共
有
Link不要で互いにアクセス可能
VPC内の他のリソースへPrivate IP
で通信が可能
FargateではPublic IPの割当も可能
172.31.0.0/16
Subnet
172.31.1.0/24
Internet
Other Entities in VPC
EC2 ELB RDS etc.
Elastic Network Interface (ENI)
Public IP / Private IP
208.57.73.13 / 172.31.1.164
us-east-1a
us-east-1b
us-east-1c
NEW!!

その他のAmazon ECSの特徴
Amazon CloudWatch Logsと簡単に連携
Amazon CloudWatch Eventsに各種イベントが流れる
[Coming soon] Service Discovery by Route 53
EC2へのTask配置を柔軟に設定可能
NEW!!

63% のKubernetes利用者が
AWSを今日利用している
—CNCF アンケートより
https://www.cncf.io/blog/2017/06/28/survey-shows-kubernetes-leading-orchestration-platform/
https://www.cncf.io/blog/2017/12/06/cloud-native-technologies-scaling-production-applications/

Amazon Elastic Container Service for Kubernetes
(EKS)
Tenet 1
EKSはエンタープライズ企業が本番
のワークロードを実行するためのプ
ラットフォームであること
Tenet 2
EKSはネイティブで最新の
Kubernetesの体験を提供すること
Tenet 3
EKSユーザが他のAWSサービスを使
う時、シームレスな連携を実現し不
要な作業を取り除くこと
Tenet 4
EKSチームは積極的にKubernetesプ
ロジェクトに貢献していくこと
NEW!! (Preview)

kubectl
3) AWSアイデンティティをRBACで認可する
k8s API
1) AWSアイデンティティを渡す
2) AWSアイデンティティ
を検証する
4) k8sのアクションが許
可・拒否される
AWS Auth

アプリケーションの開発に集中したい
Amazon EC2
• アプリ開発してデプロイ
• コンテナのAuto Scale
• コンテナのセキュリティ管理
• OSのプロビジョン
• OSのセキュリティ管理
• インスタンスのAuto Scale

計算リソースの使い方を根本的に変える
簡素で、使いやすく、
強力な
新しいリソース利用モデル
=インスタンス
管理不要
タスク
ネイティブAPI
リソース
ベースの価格
NEW!!

Scheduling and Orchestration
Cluster Manager Placement Engine
ECS
AMI
Docker
agent
ECS
agent
EC2 Instance
ECS
AMI
Docker
agent
ECS
agent
EC2 Instance
ECS
AMI
Docker
agent
ECS
agent
EC2 Instance

タスクに割り当てるCPUとメモリの設定
柔軟な設定の選択肢
– 50 のCPU/メモリ設定から
CPU Memory
256 (.25 vCPU) 512MB, 1GB, 2GB
512 (.5 vCPU) 1GB to 4GB (1GB 刻み)
1024 (1 vCPU) 2GB to 8GB (1GB 刻み)
1 vCPU = $0.00001406/秒
1 GB Mem = $0.00000353/秒

Fargateの料金計算例
• 0.25 vCPU + 1 GB MemのTask
• 10個のTaskが毎日1時間実行
30日分のCPU料金
10 x 0.25 x 0.00001406 x 3600 x 30 = $3.80
30日分のMemory料金
10 x 1 x 0.00000353 x 3600 x 30 = $3.81
30日分のトータル料金
$3.80 + $3.81 = $7.61
• 実際にTaskを起動していた
vCPUとMemoryに対する秒
単位の計算
• ストレージ料金は不要
• データ転送料は標準
• その他に利用するサービス
は追加料金が発生
• 例: CloudWatch Logs

サービスレベルアグリーメント
99.99
NEW!!

コンテナCI/CDパイプラインの構築

なぜCI/CDパイプラインが重要なのか？
• 誰がやっても同じ様にデプロイできること
• イメージがどうやって作られどこで使われてるか把握
• アプリ毎に統一された手法を利用する
しかし、CI/CDパイプラインの実装や構築自体は、典型的
な差別化を産まない重労働
→ AWS CodePipeline / AWS CodeBuild

AWS CodePipeline
柔軟なCI/CDパイプラインをフルマネージド
Source, Build, Test, Deployを複雑に組合せ
並列実行や、手動承認も設定可能
Deploy TargetにECS Serviceも対応
ユースケース
テスト環境にデプロイ後、各種テスト実行
カナリア、リージョンデプロイ
NEW!!

AWS CodeBuild
マネージドの実行環境
ビルドやテスト等が主な目的
実行環境はDockerイメージ
各種言語対応の環境
Dockerイメージのビルドも可能
CodePipelineとも連携可能
もちろん単体でも利用可能
version: 0.2
phases:
pre_build:
commands:
- $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)
- REPOSITORY_URI=0123456789.dkr.ecr.us-east-1.amazonaws.com/fargate-demo
- IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
build:
commands:
- docker build -t $REPOSITORY_URI:latest .
- docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
post_build:
commands:
- docker push $REPOSITORY_URI:latest
- docker push $REPOSITORY_URI:$IMAGE_TAG
- printf '[{"name":"app","imageUri":"%s"}]' $REPOSITORY_URI:$IMAGE_TAG > imageDefinition.json
artifacts: files: imageDefinition.json
buildspec.yaml

AWS
CodePipeline
AWS
CodeCommit
AWS
CodeBuild
Developer
Application
Load Balancer
Servic
e
パイプライン確認、手動承認
コードのチェックイン
ビルド済
イメージの確認
デプロイ後の
状態確認
registerTaskDefinition & updateService
docker build & push
imageDefinition.json
source code

コンテナのAuto Scaling

コンテナの数をAuto Scalingさせる
何らかのメトリクスに応じて、コンテナの数を自動スケールさせたい
コンテナのCPUやメモリ使用率、リクエスト数
コントロールプレーンの課題
メトリクスの変化に対して、コンテナ数をどの程度変化させれば良い？
データプレーンの課題
コンテナのスケールに応じて、インスタンス数もスケールが必要
→ ECSのTarget TrackingとFargateの組合せがオススメ

ECSの特徴: Target Trackingとの連携
メトリクスに対してターゲットの値を
設定するだけ
(例: CPU使用率 50%)
その値に近づく様に、Application Auto
Scalingが自動的にServiceの
DesiredCountを調整
ECSではコンソールからも設定可能
ECSServiceAverageCPUUtilization
ECSServiceAverageMemoryUtilization
ALBRequestCountPerTarget
CPUTraffic
DesiredCount
Time
100%
0%
50%
10%
20%
30%
40%
60%
70%
80%
90%
5
30
10
15
20
25
Target CPU Utilization DesiredCount
NEW!!

Servic
e
Fargateを利用したコンテナAuto Scalingの優位性
Fargateの場合
• Serviceのスケールに応じて自然に
コンテナが起動・終了する
• コンテナの起動時間に対してのみ
課金
EC2の場合
• インスタンスのリソースも上手く
スケールさせる必要があり煩雑
• 余分に持っているバッファ分もイ
ンスタンスの課金が必要
Amazon EC2
Servic
e Resource
buffer
(+~15%)

まとめ
コンテナ開発の要素
CI/CDパイプライン
Auto Scaling

参考資料
• Amazon Container Services Page
• Containers on AWS - State of the Union
- CON201 - re:Invent 2017 Slides /
Video
• Introducing AWS Fargate - CON214 -
re:Invent 2017 Slides / Video
• Deep Dive into AWS Fargate - CON333
- re:Invent 2017 Slides / Video
• Introducing Amazon EKS - CON215 -
re:Invent 2017 Slides / Video
• Deep Dive into Amazon EKS - CON409
- re:Invent 2017 Slides / Video

オンラインセミナー資料の配置場所
AWS クラウドサービス活用資料集
• https://aws.amazon.com/jp/aws-jp-introduction/
AWS Solutions Architect ブログ
• 最新の情報、セミナー中のQ&A等が掲載されています。
• http://aws.typepad.com/sajp/

公式Twitter/Facebook
AWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、
お得なキャンペーン情報などを日々更新しています！
もしくは
http://on.fb.me/1vR8yWm

AWSの導入、お問い合わせのご相談
AWSクラウド導入に関するご質問、お見積、資料請求をご希望のお客様は以下
のリンクよりお気軽にご相談下さい。
https://aws.amazon.com/jp/contact-us/aws-sales/
※「AWS 問い合わせ」で検索して下さい。

AWS Well Architected 個別技術相談会お知らせ
• Well Architectedフレームワークに基づく数十個の質問項目を元に、お客様が
AWS上で構築するシステムに潜むリスクやその回避方法をお伝えする個別相
談会です。
https://pages.awscloud.com/well-architected-consulting-2017Q4-jp.html
• 参加無料
• 毎週火曜・木曜開催

20180220 AWS Black Belt Online Seminar - Amazon Container Services

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 20180220 AWS Black Belt Online Seminar - Amazon Container Services

Similar a 20180220 AWS Black Belt Online Seminar - Amazon Container Services (20)

Más de Amazon Web Services Japan

Más de Amazon Web Services Japan (20)

20180220 AWS Black Belt Online Seminar - Amazon Container Services