はじめに

こんにちは、YUJIです。

先日、AWS Workshop Studioでレクチャー用にAWSアカウントを一時的に払い出していただき
ECS on EC2, ECS on Fargateの両方を学べるハンズオン、ECS Cats and Dogsを体験する機会があったので
感想レポートとして残します。

この記事で書くこと

• ハンズオン(ECS Cats and Dogs)の大まかな概要
• ハンズオンをなぞることで、実感したECSの裏側の挙動

この記事で書かないこと

• AWS Workshop Studioの概要、使用方法
• ハンズオン手順の細かなフォローアップ
• 各用語の説明(AWS セッションレベルで言うところの、Level 200以下の説明は割愛いたします。)

ハンズオン(ECS Cats and Dogs)の概要

ECS Cats and Dogs
https://catalog.workshops.aws/ecs-cats-and-dogs/en-US

ECSを利用して、3つのサービス　web、cats、dogsを作ります。

クラスター
├── web (Amazon EC2)
├── cats (Amazon EC2)
└── dogs (AWS Fargate)

これらの設定を通じて、Amazon ECSを使ったサービスの新規構築の方法、運用の勘所を学ぶという内容でした。
※ハンズオン当日の時間の都合のため、CI/CDパイプラインの構築パートまではたどり着けませんでした。無念。

アプリケーションの実際の挙動としては
トップページ(web)で、猫派か犬派かをクリックで選択して
かわいい猫のページ(cats)か、かわいい犬のページ(dogs)に到達するものになっています。

↓

子どもの頃、お隣さんが飼っていた犬といっぱい遊んだ経験から犬派です。
かわいいね。

大まかなハンズオン手順

① AWS Cloud9の環境を作って、資材をダウンロードする。
② AWS Cloud9上でweb、cats、dogsのイメージをビルドして、Amazon ECRにプッシュする
③ ALB、クラスター用のセキュリティグループを作る。
④ ECS クラスターを作成する。
⑤ web、cats、dogsそれぞれのタスク定義を作る。
⑥ 自動で作成されるタスク実行ロールに、CloudWatchFullAccessのポリシーをつける。
⑦ ALBを作成する。
⑧ web、cats、dogsのサービスを作成し、設定したパスパターンの通りにweb、cats、dogsにアクセスが可能か確認する。
⑨ Container Insights、Logs Insightsの使用感を確かめる。
⑩ オートスケール設定を行い、実際に負荷をかけてスケールするまでを確認してみる。
⑪ CI/CDパイプラインを構築する。

ハンズオンで得た学び

ただただ「ハンズオンしたよ」という報告では味気ないので、今回のハンズオンで得た学びを3つ記載します。

学びその① ECSクラスター作成の裏側では、AWS CloudFormationが実行されている。

クラスター作成失敗した時のエラー内容も、CloudFormationで改めて確認できます。

例えば

初回のクラスター作成で、まだECS用のサービスロール(AWSServiceRoleForECS)が出来上がっていない
↓
Resource handler returned message: "Error occurred during operation 'CreateCluster SDK error: Service Unavailable. Please try again later. (Service: AmazonECS; Status Code: 500; Error Code: ServerException; Request ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx; Proxy: null)'." (RequestToken: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, HandlerErrorCode: GeneralServiceException)
のエラーが発生する。
↓
クラスターの画面をすぐ閉じてしまい、失敗原因がなんだったのか分からない。
↓
再作成しようとしても、同名クラスターで再作成できない。

上記のように行き詰まってしまうケースもあると思います。

ですが、裏側を知っていれば

CloudFormationの失敗原因を確認する
↓
失敗したCloudFormationのスタックごと削除する
↓
改めてECSのコンソール画面から作成し直す
↓
今度はECS用のサービスロールが自動で作成されているため、クラスターの作成に成功する。

と、落ち着いて対処することが可能です。

学びその② ターゲット追跡スケーリングの裏側では、Amazon CloudWatch Alarmが動いている。

よほど「CPU使用率◯％の時はコンテナが何個、×％の時は何個…」という細かい要件がなければ、ターゲット追跡ポリシーを使っているケースが多いと思います。
ターゲット追跡タイプのスケーリングポリシーを使う場合は、裏側でCloudWatch Alarmが自動的に作られるようです。

ハンズオン手順に従い、最大8個までタスクが増えるよう、webサービスのスケーリングポリシーを編集してみます。

試しに、負荷テストツールSiegeを使い、多数のリクエストを送信します。

ALBのCloudWatchメトリクスからも、リクエスト数の増加を確認できました。

…すぐには、タスクは増えません。

そこで、CloudWatch Alarmを見に行ってみます。
「データポイント収集は1分ごとで、3回連続でしきい値に触れている必要がある」という設定になっていますが
まだこの条件を満たしていないから、スケールアウトが実行されていないだけだったんですね。

アラーム状態になると

タスクもどんどん増えていきます。

背景が分かっていると、このように確認がスムーズですね。
最終的には、webのタスクが6個までタスクが増えました。

…ん？6個？

学びその③ ECS on EC2の場合、サービスのスケーリング設定だけではEC2側のvCPUがボトルネックになることがある。

webのスケーリング設定では、最大8個のタスクが起動されるように設定したのに、6個までしかタスクが起動しなかった原因を
今回のハンズオンを担当したソリューションアーキテクトさんから解説していただきました。

下記画像にて示す通り、今回はEC2をm5.large × 2台で、合計4vCPU分の容量を確保しています。

タスク:cats(0.5vCPU) × 2台で、既に1vCPUを使っていることから、空きが3vCPUしかなく
タスク:web(0.5vCPU)は、6台までしか立てる余地が無かったんですね。

この問題を解消するため、EC2もスケーリングするよう運用するには
Capacity Providerを用いるなどして、タスクの増減に合わせてEC2もスケールする必要があるようです。
今までFargateしか触って来なかったので、知らなかったポイントでした。

まとめ

今回は、ハンズオン:ECS Cats and Dogsを実践したことでの学びを書いてみました。

今後のECS運用において役立つ部分が多く、充実した学びになりました。
引き続きいろんなことを学んで、アウトプットすることで知識の定着を図っていきます。

最後まで読んでいただき、ありがとうございました。