実践的 AWS コンテナ運⽤ガイド · 2020. 10. 23. · セッションの対象者 • aws 上でコンテナ化されたアプリケーションを運⽤している、もしくはこれから構築・運⽤されるエンジニア・

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

実践的 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

• Isolated processes

→ CI/CD による⾃動化、デリバリ速度の向上→ リソース集積率を⾼めることによる仮想マシンコストの削減

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


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

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

• オーケストレーションツール+αで実現される機能性の例• 複数サーバにまたがるコンテナのレプリケーションやスケジューリング• クラッシュしたコンテナの⾃動再配置 (オートヒーリング)

• 宣⾔的デプロイメント• オートスケーリング• 秘密情報管理• メトリクス・ログ収集• etc.


Amazon Elastic Container Service (ECS)

Amazon ECS

グローバル展開

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

オートスケーリング

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

ロードバランサー

コンテナレベルのネットワーク構成

⾼度なタスク配置戦略

他のAWSサービスとの連携

ECS CLI…{ }



App Layer

VPC

DB Layer

今回のシナリオ

• EC2 上で動いていた WEB アプリケーションをデリバリ速度の向上を⽬指し、コンテナ化

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

• Application Load Balancer、Amazon ECS/Fargate、Amazon RDS というアーキテクチャ

• マネージメントコンソールから ECS にデプロイし動作することまでは確認済み

Amazon ECSNginx app Nginx app

Application Load Balancer(ALB)


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

App Layer

VPC

DB Layer


Application Load Balancer(ALB)

Amazon ECR

AWS CodeCommit

Amazon CloudWatch

Developers

Amazon S3

アプリケーションソースコードの管理

Dockerイメージの管理

メトリクスとLog

Logの転送

Serviceの更新



今回取り上げる課題

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

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

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

• 課題4:タスク数のオートスケーリングの設定


課題1:より詳細なモニタリング• 負荷テストの結果、 ECS上のサービスが想定されたパフォーマンス

を出していない• CloudWatch のデフォルトのメトリクスではタスク、コンテナ単位

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

タスク

Nginxコンテナ Appコンテナ

256MiB256ユニット


250 /250 /

128 /128 /

CPUユニット数: 1024ユニットメモリ: 1024MB

を割り当てるタスク

Nginxコンテナ Appコンテナ

CPUユニット数: 2048ユニットメモリ: 2048MB

を割り当てる



250 /250 /

128 /128 /


解決アプローチ• Amazon Cloud Watch Container Insights を使って適切なリソー

ス配分を⾒極める• Container Insights はコンテナ単位のリソースモニタリングが可能

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

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

:

1235 A 44 A

2B

2B

��

/0 B BC

7 68 :

1235 A 44 A 2 B

2B

/0 B BC

7 68

Container Insightsを使ってリソースの使用状況をモニタリングする

チューニング


ステップ1. コンテナごとのメトリクスを確認• Container Insights の⾃動ダッシュボードから「ECS Tasks」を選

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

⽚⽅のコンテナに負荷が偏っていることが判明した︕


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

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

app︓メモリ384MB/CPU 192ユニットNginx︓メモリ128MB/CPU 64 ユニット


ステップ3. 再びコンテナごとのリソースを確認• あらためて Container Insights からコンテナごとのリソース使⽤

状況を確認する

適切なリソース割り当てができたことを確認︕

Amazon ECS CloudWatch Container Insightshttps://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/cloudwatch-container-insights.html

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/cloudwatch-container-insights.html


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

• Nginx のアクセスログは現状の運⽤通り、S3 に格納したいがCloudWatch Logs 経由でのログの転送となっている

• ログの種類に応じて、格納先にタスクから柔軟に転送してCloudWatch Logs のコスト最適化をしたい

App Layer


Amazon CloudWatch

Amazon S3

nginx Log & app Log

NginxのLogを転送

ログ分析


App Layer

Amazon ECS

web app web app

解決アプローチ

• Amazon ECS の FireLens をログドライバーとして利⽤する• Fluentd または Fluent Bit のログルーターコンテナがサイドカーと

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

Amazon S3

CloudWatch Logsapp Log

Kinesis Data Firehose

Nginx Log

ログ分析


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

• ECS のコンテナの標準出⼒/標準エラー出⼒を、 Fluentd またはFluent Bit に簡単にルーティングできる機能

• AWS サービスまたは Third Party 製ツールの宛先にログをルーティング可能

• Fluent bit は C ⾔語で実装されている。 Fluentd の⽅が機能は豊富だが、軽量でコンテナのサイドカーに最適

Amazon ECS FireLens Examples︓https://github.com/aws-samples/amazon-ecs-firelens-examples

https://github.com/aws-samples/amazon-ecs-firelens-examples


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

• ソースコードとコンテナイメージのアップロード、Serviceの更新をそれぞれ⼿動で⾏なっており、デプロイに疲弊している

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

App Layer


Amazon ECR

AWS CodeCommit

Developers

アプリケーションソースコードの管理

Dockerイメージの管理

Serviceの更新


解決アプローチ

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

- 増え続ける負担による開発速度の低下- 秘伝のタレ化されたデプロイ⼿法により、⼈依存が進み組織の拡⼤を遮る

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

- ⾃動化されたデプロイにより開発速度の向上- すべてのプロセスが⾃動化されることにより、⼈依存ではなくコードに依存したデプロイで組織の拡⼤が容易になる


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

Developers ソースコードレポジトリ

デプロイメントマネジャー

Image Build/Test Service

Container Image Repository

コンテナオーケストレーション

ツール



DevelopersAWS

CodeCommitAWS

CodePipelineAWS CodeBuild

Amazon ECR

Amazon ECS

CodePipeline を使⽤した継続的なデプロイhttps://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-cd-pipeline.html

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-cd-pipeline.html



DevelopersAWS

CodeCommitAWS


Amazon ECR

Amazon ECS

── app├── Dockerfile├── buildspec.yml├── index.js├── docker-compose.yml└── package.json

git push



DevelopersAWS

CodeCommitAWS


Amazon ECR

Amazon ECS

パイプライン発⽕

変更を取得



DevelopersAWS

CodeCommitAWS


Amazon ECR

Amazon ECS

Test & Image build成果物をS3から取得

docker build -t $REPOSITORY_URI:latest .

docker tag $REPOSITORY_URI:latest$REPOSITORY_URI:$IMAGE_TAG



DevelopersAWS

CodeCommitAWS


Amazon ECR

Amazon ECS

Image Push

docker push $REPOSITORY_URI:$IMAGE_TAG



DevelopersAWS

CodeCommitAWS


Amazon ECR

Amazon ECS

成果物のDeployregisterTaskDefinition & updateService


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

DevelopersGitHub

Amazon ECR

Amazon ECSJenkins AWS CloudFormation


課題4:タスク数のオートスケーリングの設定

• アプリケーションの特性上、⽇によってアクセスがばらつきがあり、ECS サービスの Auto Scaling を設定することになった

• ステップスケーリングポリシーでの Auto Scaling を設定しているが、スケールアウト・インの設定が複雑


解決アプローチ• Target Tracking を利⽤したサービスの

スケーリングを⾏う

• メトリクスに対してターゲットとなる値を設定するだけ (e.g. CPU 使⽤率 50%)

• 指定値に近づくようにApplication Auto Scaling が⾃動的にサービスの DesiredCount を調整

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

ECSServiceAverageMemoryUtilizationALBRequestCountPerTarget

CPU

Desired

Coun

t

Traffic

Time

100%

0%

50%

10%

20%

30%

40%

60%

70%

80%

90%

5

30

10

15

20

25

Target CPU Utilization DesiredCount


まとめ


Example Stack

App Layer

VPC

DB Layer

Amazon ECS

web app

ALB

web app CloudWatch Container Insights

& Logs

Amazon S3

DevelopersCodeCommitCodeBuild

ECR

AWS Secrets Manager

Parameter Store

Secrets/Configs

Auto Scaling

CodePipeline

Kinesis Data Firehose

Nginx Log

app Log

メトリクス

ECRイメージスキャン


まとめ

周辺サービスをうまく活⽤して、運⽤にかかる負担をオフロード



Quiz

Q: 今回のシナリオの課題2で上がった、Nginx コンテナのログをAmazon Kinesis Data Firehose 経由で S3 に、app コンテナのログをCloudWatch Logs に FireLens + FluentBit で転送するには、タスク定義をどのように設定をすれば良いでしょうか︖

Thank you!


Shinichi [email protected]

track3jyo

Documents

実践的 AWS コンテナ運⽤ガイド · 2020. 10. 23. · セッションの対象者 • aws 上でコンテナ化されたアプリケーションを運⽤している、もしくはこれから構築・運⽤されるエンジニア・