aws black belt online seminar amazon container services · 2018. 2. 23. · →aws codepipeline /...

© 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

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

CodePipelineSource Build Deploy

AWS

CodeCommitAWS

CodeBuild

Amazon RDS Amazon S3Developer

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: 100Application

Auto Scaling


IAM Role: Task毎に異なる権限のAWS認証が可能

IAM RoleをTask毎に設定可能

AWS SDKを利用していれば自動的に認証情報が得られる

アクセス鍵等の埋め込み不要

自分のRoleにない権限は当然利用不可なので、セキュア

AWS IAMAmazon

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/

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

CP

UT

raff

ic

De

sir

ed

Co

un

t

Time

100%

0%

50%

10%

20%

30%

40%

60%

70%

80%

90%

5

30

10

15

20

25

Target CPU Utilization DesiredCountNEW!!


Servic

e

Fargateを利用したコンテナAuto Scalingの優位性

Fargateの場合• Serviceのスケールに応じて自然にコンテナが起動・終了する

• コンテナの起動時間に対してのみ課金

EC2の場合• インスタンスのリソースも上手くスケールさせる必要があり煩雑

• 余分に持っているバッファ分もインスタンスの課金が必要

Amazon EC2

Servic

eResource

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

https://aws.amazon.com/jp/containers/

https://www.slideshare.net/AmazonWebServices/containers-on-aws-state-of-the-union-con201-reinvent-2017

https://www.youtube.com/watch?v=JXnhAZZnzQg

https://www.slideshare.net/AmazonWebServices/new-launch-introducing-aws-fargate-con214-reinvent-2017

https://www.youtube.com/watch?v=0SceSgOTyrw

https://www.slideshare.net/AmazonWebServices/deep-dive-into-aws-fargate-con333-reinvent-2017

https://www.youtube.com/watch?v=CdxdjDpF8Eo

https://www.slideshare.net/AmazonWebServices/new-launch-introducing-amazon-eks-con215-reinvent-2017

https://www.youtube.com/watch?v=WHTejF3W0s4

https://www.slideshare.net/AmazonWebServices/deep-dive-into-amazon-eks-con409-reinvent-2017

https://www.youtube.com/watch?v=vrYLrx-a_Wg


オンラインセミナー資料の配置場所

AWS クラウドサービス活用資料集• https://aws.amazon.com/jp/aws-jp-introduction/

AWS Solutions Architect ブログ• 最新の情報、セミナー中のQ&A等が掲載されています。

• http://aws.typepad.com/sajp/

https://aws.amazon.com/jp/aws-jp-introduction/

http://aws.typepad.com/sajp/


公式Twitter/Facebook

AWSの最新情報をお届けします

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

http://on.fb.me/1vR8yWm


AWSの導入、お問い合わせのご相談

AWSクラウド導入に関するご質問、お見積、資料請求をご希望のお客様は以下のリンクよりお気軽にご相談下さい。

https://aws.amazon.com/jp/contact-us/aws-sales/

※「AWS 問い合わせ」で検索して下さい。

https://aws.amazon.com/jp/contact-us/aws-sales/


AWS Well Architected 個別技術相談会お知らせ

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

• 参加無料

• 毎週火曜・木曜開催

https://pages.awscloud.com/well-architected-consulting-2017Q4-jp.html

aws black belt online seminar amazon container services · 2018. 2. 23. · →aws codepipeline /...

Documents