ECS のタスクを再起動せずにコンテナを再起動する “再起動ポリシー” を設定してみた
By msysh on 2024-08-31
Amazon ECS で “タスクを再起動せずにコンテナを再起動する機能が提供” されました。これは ECS タスク内のコンテナが終了した場合に、コンテナをローカルで再起動させることができる機能で、タスクを置き換える (再デプロイする) ことなく迅速にコンテナを回復できる機能です。こちらの機能を使ってどのぐらい早く回復できるか試してみました。
ECS Blue/Green デプロイでもリクエストカウント追跡のオートスケーリングを利用したい (Metric Math 編)
By msysh on 2024-03-21
2023年3月に「Application Auto Scaling がターゲット追跡ポリシーに対する Metric Math に対応」というアップデートがありました。こちらを使うことで以前課題となっていた、CodeDeploy による ECS Blue/Green デプロイ環境下でのリクエストカウント追跡のオートスケーリングをシンプルに実現できそうだったので試してみました。
ECS 外部デプロイを使って Blue/Green デプロイを Step Functions で実装してみたデモ
By msysh on 2023-07-08
ECS で Blue/Green デプロイ（以下、B/G デプロイ）をしたい場合、CodeDeploy を使うと比較的簡単に構成することができますが、Green 環境をデプロイした後のテスト期間が最大2日間までになります。リリース前のテスト期間をもっと取りたいようなケースに対処するために、ECS のデプロイタイプを外部デプロイにし、デプロイコントローラを AWS Step Functions で実装することで B/G デプロイを実現できそうでしたのでデモアプリとして作ってみました。
#aws #cdk #ecs #bluegreen #external-deploy #stepfunctions #codepipeline
Service Connect を使用した ECS サービスにオートスケーリングを設定してみる
By msysh on 2022-12-26
2022年の re:Invent にて ECS の新しいネットワーク機能として Service Connect がリリースされました（アナウンス）。これまで、ECS におけるサービス間通信として ELB、Service Discovery（Cloud Map）、App Mesh がありましたが、新しく 4つ目の選択肢として登場しました。今回、この Service Connect を使用した ECS サービスにおいて Auto Scaling の設定を検討する機会がありましたのでどんなメトリクスが使えるか調査してみました。
#aws #service-connect #ecs #service-discovery #cloud-map #auto-scaling
ECS Blue/Green デプロイでもリクエストカウント追跡のオートスケーリングを利用したい
By msysh on 2021-08-22
コンテナワークロードでは CodeDeploy などで継続的なデリバリを行い、Auto Scaling を利用して負荷に応じて、動的にコンテナを増減させて運用されているのではないかと思います。特に ECS では CodeDeploy を利用して、Blue/Green デプロイメントを行うことができます。また、Auto Scaling ではスケーリングを判断する指標の1つとして Application Load Balancer（ALB）ターゲットグループ内のターゲットごとに完了したリクエストの数（ALBRequestCountPerTarget）を利用することができます。が、実は現時点ではそれらを一緒に使うと、そのままでは期待通りに動作してくれません。それぞれをうまく利用するために検討する機会がありましたので、考え方のベースとして記録に残しておきたいと思います。
ECS タスクの各コンテナ単位のパフォーマンスメトリクスを取得する方法
By msysh on 2021-08-08
ECS での標準的に利用できるメトリクスとしては、サービス単位での CPU 利用率、メモリ利用率であり、タスク毎にどんなパフォーマンスなのかというのはわかりません。そこで Container Insights を利用することで、マネジメントコンソールからは現在値になりますがタスク単位での平均 CPU 使用率、メモリ利用率の他、サービス単位で時系列のネットワーク I/O、ストレージ I/O などが確認可能になります。これらでも充分有用なのですが、タスクにサイドカーも備えるなど複数コンテナで構成しているケースで、時には調査のため “コンテナ単位” でのパフォーマンス値を確認したいことがあるかもしれません。一発でグラフなどに出せるわけではありませんが、そんなシーンで利用できる Tips を紹介します。
CDK で既存のタスク定義を参照する場合のリビジョン指定について
By msysh on 2020-12-23
AWS CDK (Cloud Development Kit) の小ネタです。
CDK で既存のタスク定義を参照したい場合、ecs.TaskDefinition.fromTaskDefinitionArn で arn からタスク定義がとってこれるわけですが、タスク定義の arn はマネジメントコンソールから確認できる JSON や CLI から参照すると末尾にリビジョン番号がついてきます。
describe で出力した ECS タスク定義をさくっと登録可能な形に整形する
By msysh on 2020-12-12
Amazon ECS (以下、ECS) のタスク定義は aws cli などの describe-task-definition で JSON 形式で出力することができますが、その JSON ファイルはそのままではタスク定義の登録や更新（register-task-definition）には使えなかったりします。
うまく整形してやれば、タスク定義の登録や更新に利用できるので jq などを駆使してさくっと整形する方法をメモっておきます。
ALB と docker ヘルスチェックによる ECS の挙動について
By msysh on 2020-08-30
AWS による docker コンテナのオーケストレーションサービスである Amazon ECS / Fargate のヘルスチェックの挙動について調査する機会がありましたのでアウトプットしておきたいと思います。
前提として Fargate で ECS のサービスとして、ロードバランサーは Application Load Balancer（ALB）を利用して実行するケースで調査しました。網羅的ではない点、ご了承ください。
FireLens で rewrite_tag による複数ターゲットへのログの振り分け
By msysh on 2020-07-19
FireLens fluent bit でログを振り分けたい場合、 fluent bit の設定ファイル内で Parsers_File などで指定した別のファイルを用いて、カスタム docker イメージを作成するサンプルが多いかと思いますが、カスタムイメージを作成することなく（ Parsers_File 無しで）ささやかながら実現した例を紹介したいと思います。
#aws #fluentbit #firelens #ecs #logging #firehose #elasticsearch