実践的 AWS コンテナ運ガイドモニタリングロギングデプロイスケーリングの実現法濵真アマゾンウェブサービスジャパン技術統括本部ソリューションアーキテクト Twitter ハッシュタグ #AWSInnovate 2020, Amazon Web Services, Inc. or it

(1)

実践的

AWS

コンテナ運⽤ガイド

〜モニタリング、ロギング、デプロイ、スケーリングの実現⽅法〜

濵真⼀

アマゾンウェブサービスジャパン

技術統括本部ソリューションアーキテクト

Twitter

ハッシュタグ #AWSInnovate

(2)

本セッションについて

セッションの対象者

• AWS 上でコンテナ化されたアプリケーションを運⽤している、もしくはこれから構築・運⽤されるエンジニア・

アーキテクトの⽅

• コンテナ化されたアプリケーションを作っているけど、運⽤⽅法に不安を抱えている⽅

セッションのゴール

• Amazon ECSでのコンテナアプリケーションの運⽤上の負担を低減するための⼿法を理解する

前提条件

• 以下についての概要レベルの知識が前提となります

• Amazon VPC、Amazon EC2、Amazon S3 などのAWS 基礎サービス

• コンテナおよびDockerについて(お先に「[S-11] ところで、コンテナ化ってどうやればいいの︖」をご覧いただ

くとより理解が深まります。)

【ご連絡事項】

本セッション内容について確認するためのクイズおよび簡単なアンケートがセッションの最後にあります。

なおクイズの回答はアンケートとあわせて表⽰されます。

(3)

アジェンダ

• イントロダクション︓

• アプリケーションをコンテナ化する背景

• ECS

上にデプロイされた、あるアプリケーションのシナリオ

• コンテナ化アプリケーションの運⽤における課題とその解決⼿法

• まとめ

• クイズ

(4)

(5)

なぜコンテナか︖

• Run Anywhere

• 複数環境に渡る

⼀貫した実⾏可能性

• Portability

• 可搬性の⾼さ

• コンテナイメージの作成

_(build)

、レジストリ、アップロード

_(push)

、ダウン

ロード

(pull)

に代表される、

可搬性の⾼さ

を⽀える

エコシステム

• Isolated processes

• コンテナによるプロセスレベルのリソースアイソレーション、それによる

CPU やメモリに代表される

リソースの柔軟な割り当て

、

⾼速な起動と停⽌

(6)

なぜコンテナか︖

• Run Anywhere

• Portability

• Isolated processes

→

CI/CD による⾃動化、デリバリ速度の向上

→

リソース集積率を⾼めることによる仮想マシンコストの削減

といったメリットが⾒込める

(7)

なぜオーケストレーションツールか︖

• コンテナの機能性のスコープは単⼀ノードにおけるライフサイクル管理

• オーケストレーションツール+αで実現される機能性の例

• 複数サーバにまたがるコンテナのレプリケーションやスケジューリング

• クラッシュしたコンテナの⾃動再配置

_{(オートヒーリング)}

• 宣⾔的デプロイメント

• オートスケーリング

• 秘密情報管理

• メトリクス・ログ収集

• etc.

(8)

Amazon Elastic Container Service (ECS)

Amazon ECS

グローバル展開

強⼒なスケジュールエンジン

オートスケーリング

ログ/メトリクス/イベント

ロードバランサー

コンテナレベルの

ネットワーク構成

⾼度なタスク配置

戦略

他のAWSサービス

との連携

ECS CLI

…

{ }

(9)

(10)

App Layer

VPC

DB Layer

今回のシナリオ

• EC2 上で動いていた WEB アプリケーション

をデリバリ速度の向上を⽬指し、コンテナ化

• コンテナを使ったアプリケーションの運⽤は

初めて

• Application Load Balancer、Amazon

ECS/Fargate、Amazon RDS というアーキ

テクチャ

• マネージメントコンソールから ECS にデプロ

イし動作することまでは確認済み

Amazon ECS

Nginx

app

_Nginx

app

(11)

運⽤時に必要となることも含めると・・・

App Layer

VPC

DB Layer

Amazon ECS

Nginx

app

_Nginx

app

Application Load Balancer(ALB)

Amazon ECR

AWS

CodeCommit

Amazon

CloudWatch

Developers

Amazon S3

アプリケーションソー

スコードの管理

Dockerイメージ

の管理

メトリクスとLog

Logの転送

Serviceの更新

(12)

(13)

今回取り上げる課題

• 課題1:より詳細なモニタリング

• 課題2:ログの柔軟なルーティング

• 課題3:ECS へのデプロイの⾃動化について

(14)

課題1

:

より詳細なモニタリング

• 負荷テストの結果、 ECS上のサービスが想定されたパフォーマンス

を出していない

• CloudWatch のデフォルトのメトリクスではタスク、コンテナ単位

のメトリクスが取れず、リソースの配分が難しい

タスク

Nginxコンテナ

Appコンテナ

256MiB

256ユニット

768MiB

768ユニット

250 /

128 /

CPUユニット数: 1024ユニット

メモリ:

1024MB

を割り当てる

_タスク

Nginxコンテナ

Appコンテナ

CPUユニット数: 2048ユニット

メモリ:

2048MB

を割り当てる

512MiB

512ユニット

1536MiB

1536ユニット

250 /

128 /

(15)

解決アプローチ

• Amazon Cloud Watch Container Insights を使って適切なリソー

ス配分を⾒極める

• Container Insights

はコンテナ単位のリソースモニタリングが可能

• 適切なリソース配分により、効率的かつ安全に運⽤できるリソースを割り当てる

• Container Insights

のダッシュボードを起点により詳細な分析が可能

:

1235

A

44 A

2 B

/0 B

B

C

7 68

_:

1235

A

44 A

2 B

/0 B

B

C

7 68

Container Insightsを使ってリソースの使

チューニング

(16)

ステップ1. コンテナごとのメトリクスを確認

• Container Insights の⾃動ダッシュボードから「ECS Tasks」を選

択し、コンテナごとのパフォーマンスを確認する

⽚⽅のコンテナに負荷が偏ってい

ることが判明した︕

(17)

ステップ2. コンテナリソース配分を変更

• ECS タスク定義にてタスク内のコンテナリソース配分を変更する

app︓メモリ256MB/CPU 128ユニット

(18)

ステップ3. 再びコンテナごとのリソースを確認

• あらためて Container Insights からコンテナごとのリソース使⽤

状況を確認する

適切なリソース割り当てがで

きたことを確認︕

(19)

課題2

:

ログの柔軟なルーティング

• Nginx のアクセスログは現状の運⽤通り、S3 に格納したいが

CloudWatch Logs 経由でのログの転送となっている

• ログの種類に応じて、格納先にタスクから柔軟に転送して

CloudWatch Logs のコスト最適化をしたい

App Layer

Amazon ECS

Nginx

app

_Nginx

app

Amazon

CloudWatch

Amazon S3

nginx Log &

app Log

NginxのLog

を転送

(20)

App Layer

Amazon ECS

web

app

web

app

解決アプローチ

• Amazon ECS の FireLens をログドライバーとして利⽤する

• Fluentd または Fluent Bit のログルーターコンテナがサイドカーと

して実⾏され、カスタム設定により柔軟なログの保存が可能

CloudWatch Logs

app Log

Nginx Log

(21)

FireLens

を活⽤したログのルーティング

• ECS

のコンテナの標準出⼒/標準

エラー出⼒を、

Fluentd または

Fluent Bit

に簡単にルーティング

できる機能

• AWS

サービスまたは Third Party

製ツールの宛先にログをルーティ

ング可能

• Fluent bit

は C ⾔語で実装されて

いる。 Fluentd の⽅が機能は豊富

だが、軽量でコンテナのサイド

カーに最適

(22)

課題3

:ECS

へのデプロイの⾃動化について

• ソースコードとコンテナイメージのアップロード、Serviceの更新を

それぞれ⼿動で⾏なっており、デプロイに疲弊している

• ⼿作業でのデプロイの結果オペレーションミスによるトラブルが頻

発している

App Layer

Amazon ECS

Nginx

app

Nginx

app

Amazon ECR

AWS

CodeCommit

Developers

アプリケーションソー

スコードの管理

Dockerイメージ

の管理

Serviceの更新

(23)

解決アプローチ

⼿動セットアップ、⼿動デプロイ

- 増え続ける負担による開発速度の低

下

- 秘伝のタレ化されたデプロイ⼿法に

より、⼈依存が進み組織の拡⼤を遮る

可能な限りすべてを⾃動化

- ⾃動化されたデプロイにより開発速

度の向上

- すべてのプロセスが⾃動化されるこ

とにより、⼈依存ではなくコードに依

存したデプロイで組織の拡⼤が容易に

なる

(24)

効果的なコンテナデプロイメントのコンポーネント

Developers

ソースコード

レポジトリ

デプロイメント

マネジャー

Image Build/Test

Service

Container Image

Repository

コンテナオーケ

ストレーション

ツール

(25)

効果的なコンテナデプロイメントのコンポーネント

Developers

AWS

CodeCommit

AWS

CodePipeline

AWS CodeBuild

Amazon ECR

Amazon ECS

CodePipeline を使⽤した継続的なデプロイ

(26)

効果的なコンテナデプロイメントのコンポーネント

Developers

AWS

CodeCommit

AWS

CodePipeline

AWS CodeBuild

Amazon ECR

Amazon ECS

── app

├── Dockerfile

├── buildspec.yml

├── index.js

├── docker-compose.yml

└── package.json

git push

(27)

効果的なコンテナデプロイメントのコンポーネント

Developers

AWS

CodeCommit

AWS

CodePipeline

AWS CodeBuild

Amazon ECR

Amazon ECS

パイプライン発⽕

(28)

効果的なコンテナデプロイメントのコンポーネント

Developers

AWS

CodeCommit

AWS

CodePipeline

AWS CodeBuild

Amazon ECR

Amazon ECS

Test & Image build

成果物をS3か

ら取得

docker build -t $REPOSITORY_URI:latest .

docker tag $REPOSITORY_URI:latest

(29)

効果的なコンテナデプロイメントのコンポーネント

Developers

AWS

CodeCommit

AWS

CodePipeline

AWS CodeBuild

Amazon ECR

Amazon ECS

Image Push

(30)

効果的なコンテナデプロイメントのコンポーネント

Developers

AWS

CodeCommit

AWS

CodePipeline

AWS CodeBuild

Amazon ECR

Amazon ECS

成果物のDeploy

(31)

オープンソーススタックでの実現例

Developers

GitHub

Amazon ECR

Amazon ECS

Jenkins

AWS

CloudFormation

(32)

課題4

:

タスク数のオートスケーリングの設定

• アプリケーションの特性上、

⽇によってアクセスがばらつき

があり、

ECS サービスの Auto Scaling を設定することになった

• ステップスケーリングポリシーでの Auto Scaling を設定している

(33)

解決アプローチ

• Target Tracking

を利⽤したサービスの

スケーリングを⾏う

• メトリクスに対してターゲットとなる

値を設定するだけ

(e.g. CPU 使⽤率 50%)

• 指定値に近づくように

Application Auto Scaling が⾃動的に

サービスの DesiredCount を調整

• 以下のメトリクスを設定可能

ECSServiceAverageCPUUtilization

ECSServiceAverageMemoryUtilization

ALBRequestCountPerTarget

CP

U

Des

ir

ed

C

ou

n

t

Tr

af

fi

c

100%

0%

50%

10%

20%

30%

40%

60%

70%

80%

90%

5

30

10

15

20

25

(34)

(35)

Example Stack

App Layer

VPC

DB Layer

Amazon ECS

web

app

ALB

web

app

_CloudWatch

Container Insights

& Logs

Amazon S3

Developers

CodeCommit

CodeBuild

ECR

AWS Secrets Manager

Parameter Store

Auto Scaling

CodePipeline

Kinesis Data Firehose

Nginx Log

app Log

メトリクス

ECR

イメージ

スキャン

(36)

まとめ

周辺サービスをうまく活⽤して、

運⽤にかかる負担をオフロード

(37)

(38)

Quiz

Q: 今回のシナリオの課題2で上がった、Nginx コンテナのログを

Amazon Kinesis Data Firehose 経由で S3 に、app コンテナのログを

CloudWatch Logs に FireLens + FluentBit で転送するには、タスク定義

実践的

AWS

コンテナ運⽤ガイド

〜 モニタリング、ロギング、デプロイ、スケーリングの実現⽅法〜

濵 真⼀

アマゾン ウェブ サービス ジャパン

技術統括本部 ソリューションアーキテクト

Twitter

ハッシュタグ #AWSInnovate

本セッションについて

セッションの対象者

•

AWS 上でコンテナ化されたアプリケーションを運⽤している、もしくはこれから構築・運⽤されるエンジニア・

アーキテクトの⽅

•

コンテナ化されたアプリケーションを作っているけど、運⽤⽅法に不安を抱えている⽅

セッションのゴール

•

Amazon ECSでのコンテナアプリケーションの運⽤上の負担を低減するための⼿法を理解する

前提条件

•

以下についての概要レベルの知識が前提となります

•

Amazon VPC、Amazon EC2、Amazon S3 などのAWS 基礎サービス

•

コンテナおよびDockerについて(お先に「[S-11] ところで、コンテナ化ってどうやればいいの︖」をご覧いただ

くとより理解が深まります。)

【ご連絡事項】

本セッション内容について確認するためのクイズおよび簡単なアンケートがセッションの最後にあります。

なおクイズの回答はアンケートとあわせて表⽰されます。

アジェンダ

•

イントロダクション︓

•

アプリケーションをコンテナ化する背景

•

ECS

上にデプロイされた、あるアプリケーションのシナリオ

•

コンテナ化アプリケーションの運⽤における課題とその解決⼿法

•

まとめ

•

クイズ

なぜコンテナか︖

•

Run Anywhere

•

複数環境に渡る

⼀貫した実⾏可能性

•

Portability

•

可搬性の⾼さ

•

コンテナイメージの作成

(build)

、レジストリ、アップロード

(push)

、ダウン

ロード

(pull)

に代表される、

可搬性の⾼さ

を⽀える

エコシステム

•

Isolated processes

•

コンテナによるプロセスレベルのリソースアイソレーション、それによる

CPU やメモリに代表される

リソースの柔軟な割り当て

、

⾼速な起動と停⽌

なぜコンテナか︖

•

Run Anywhere

•

Portability

•

〜モニタリング、ロギング、デプロイ、スケーリングの実現⽅法〜

濵真⼀

アマゾンウェブサービスジャパン

技術統括本部ソリューションアーキテクト

_(build)

_(push)

_{(オートヒーリング)}

_Nginx