前回
これまでの関連記事は、下記のとおり
今回
ECSサービス に設定した AutoScaling を試してみます。
AutoScaling の設定
今回のテストは、bffを使用します。
bffのAutoScaling の設定は下図のとおり。ECSサービスのCPU使用率が７０％をこえたらスケールアウトします。
ECSタスクのCPU使用率を上昇
bffコンテナをスケールアウトして1台から２台に増やしますが、
検証環境はECSインスタンスを１台にしているので、タスクは２つ以上起動できません。
そこで、api01のタスク数をゼロにします。
cfnテンプレート（cfn_ecs_service_api01.yml）を修正します。
ローカルのcfnディレクトリで下記コマンドを実行して、スタックを更新します。
$ make cfnapi01 CFNCMD=update-stack
次に、前回と同じように、bffコンテナ定義で CPU割り当て（256）をコメントアウトしてスタックを更新します。
しばらく待つと、アラームが発生しスケールアウトが発動しました。
なぜか、CPU使用率が70%を超えました。
メトリクスは下図のとおり。
タスク定義でCPU割り当てをやめただけで、CPU使用率が上がり、スケールアウトが完了してもCPU利用率は下がらなかった。
なんでだろう。。。AWSのヒトに聞いてみたいが、とりあえず、無視。
スケールアウトが発動したのでECSのbffコンテナが２台になりました。
ログイン画面を表示して、複数回、再表示します。
bffコンテナのログを見ると、２つのコンテナにアクセスログが記録されています。
CloudWatch ServiceLensのマップは下図のとおり。
スケールアウトしてもマップの表示は変化なし。
下図のようにXRayで生のトレースデータを見ることができるが、リクエストを実行したコンテナを特定できるような情報は見当たらない。
[MEMO]
- ECSの capacity provider を使うと、タスクの増減にあわせて、自動的にインスタンスをAutoScalingしてくれる。(SpotFleetは使用しない）
https://dev.classmethod.jp/articles/ecs_on_ec2_capacity_provider/
