[アップデート] オブザーバビリティが強化された Amazon CloudWatch Container Insights が Amazon ECS で利用可能になったことでクラスターからコンテナレベルまでの詳細な監視ができるようになりました #AWSreInvent

AWS re:Invent 2024
#AWS
#Amazon ECS
#Container Insights
#Observability
#監視
中野ヨシユキ
2024.12.02
リテールアプリ共創部の中野です。
本日、Amazon Elastic Container Service(ECS) の Amazon CloudWatch Container Insights が監視を強化し、これまではクラスター、サービスレベルまでのメトリクスのみ分析可能だったのが、タスク、コンテナレベルまでの詳細なメトリクスを確認できるようになりました。

このアップデートで ECS の各構成要素ごとに問題の分析とトラブルシューティングができるようになりました。
https://aws.amazon.com/jp/about-aws/whats-new/2024/12/amazon-cloudwatch-container-insights-observability-ecs/
なお、Amazon CloudWatch Container Insights 上では新たに「オブザーバビリティが強化された Container Insights」という名前がマネコン上に表示されていました。
この機能は、EC2 および Fargate 起動タイプの両方でサポートされています。

以下は AWS 公式のブログです。
https://aws.amazon.com/jp/blogs/aws/container-insights-with-enhanced-observability-now-available-in-amazon-ecs/
本ブログでは、アップデート内容と実際にやってみた内容について取り上げてみます。
 何が嬉しいかもともと、以前から Amazon EKS 向けの Amazon CloudWatch Container Insights でも同じような機能が提供開始していました。
https://aws.amazon.com/jp/blogs/mt/new-container-insights-with-enhanced-observability-for-amazon-eks/
今回のアップデートで Amazon ECS でも同様の機能が追加されました。
これまでは ECS 上で発生した問題を調査する場合、Container Insights のメトリクスで確認したメトリクスデータを元に、実際のコンテナから出力された CloudWatch Logs 上のログや X-ray などの各サービスをそれぞれ調査していく必要がありました。

新しいアップデートで、クラスターレベルからコンテナレベルまでの詳細なメトリクスを CloudWatch Container Insights 上の一元的なダッシュボードで確認できるようになり、ECS 上の各コンテナレイヤー（クラスター、サービス、タスク、コンテナ）ごとの問題に対するトラブルシューティングがやりやすくなりました。
ECS 環境のインシデントの発生から解決までの時間短縮に寄与できそうなアップデートといえます。
また、既存のクラスターに対しても本機能を有効化できるので、すでに構築された ECS 環境でも有効にできます。
 なにができるかECS の AWS 公式ドキュメントを Deepl 翻訳した内容です。
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/container-insights-detailed-ecs-metrics.html
2024 年 12 月 2 日、AWS は Amazon ECS の観測性を強化した Container Insights をリリースしました。

このバージョンは、Amazon EC2 と Fargate の起動タイプを使用する Amazon ECS クラスタの拡張された観測性をサポートしています。

Amazon ECS 上で拡張された観測可能性で Container Insights を設定すると、Container Insights はクラスタレベルから環境内のコンテナレベルまで詳細なインフラストラクチャテレメトリーを自動収集し、これらの重要なパフォーマンスデータをキュレーションされたダッシュボードに表示します。
AWS ブログを読むと、新しい機能ではさまざまなコンテナレイヤーを視覚的にドリルアップおよびドリルダウンして、個々のコンテナの問題を直接特定できやすくなったとの記載がありました。
AWS 公式ブログより引用
上記の例だと、パフォーマンスメトリクスのメモリ使用率で問題が発生しているコンテナを特定したあと、そのコンテナのログを同一のマネコン上から掘り下げられるようになっています。
実際に運用しているアプリケーションの場合、インシデントアラートが発報した後、どのクラスター、サービス、タスク、コンテナが問題なのか原因を絞り込んでいき、ボトルネックとなっているところで、どんなログが出力されているのか確認しやすくなっています。
 機能の設定単位本機能を利用するには以下の単位での有効化が可能になっています。
クラスターレベル
特定のクラスターに対して個別での設定有効化が可能

アカウントレベル
AWS アカウント単位での設定有効化が可能。そのため、複数のクラスター間で統一して設定を有効にできる

もしアカウント共通で設定を有効にしておきたい場合は、アカウントレベルで設定しておけばよいかと思います。
 やってみた今回はアカウントレベルの機能設定で進めてみます。
 事前準備以下のような、ECS タスク定義を登録しておきます。

今回は Container Insights のダッシュボードを簡易的に確認することをゴールとしました。
 fargate-task.json
{
    "family": "sample-fargate",
    "containerDefinitions": [
        {
            "name": "fargate-app",
            "image": "public.ecr.aws/docker/library/httpd:latest",
            "cpu": 0,
            "portMappings": [
                {
                    "name": "fargate-app-80-tcp",
                    "containerPort": 80,
                    "hostPort": 80,
                    "protocol": "tcp"
                }
            ],
            "essential": true,
            "entryPoint": [
                "sh",
                "-c"
            ],
            "command": [
                "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
            ],
            "environment": [],
            "mountPoints": [],
            "volumesFrom": [],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/sample-fargate",
                    "mode": "non-blocking",
                    "awslogs-create-group": "true",
                    "max-buffer-size": "25m",
                    "awslogs-region": "us-east-1",
                    "awslogs-stream-prefix": "ecs"
                },
                "secretOptions": []
            },
            "systemControls": []
        }
    ],
    "taskRoleArn": "arn:aws:iam::<account id>:role/ecsTaskExecutionRole",
    "executionRoleArn": "arn:aws:iam::<account id>:role/ecsTaskExecutionRole",
    "networkMode": "awsvpc",
    "volumes": [],
    "placementConstraints": [],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "cpu": "256",
    "memory": "512"
}
タスク定義を登録します。
aws ecs register-task-definition --cli-input-json file://./fargate-task.json --region us-east-1
 クラスターレベルの Container insights 設定今回は、バージニア北部（us-east-1）でクラスターを作成します。
作成画面の[モニタリング - オプション]内にある[オブザーバビリティが強化された Container Insights]のラジオボタンを選択します。
前提で作成したタスク定義を利用してサービスを作成します。

タスク数は 2 つにして Fargate で起動しました。
 CloudWatch Container Insights 上でモニタリングしばらくすると Container Insights 上に情報が反映されます。
たとえば、一覧画面だと現在稼働中のクラスターとサービス状態が見られます。

（2 個 6 角形のクラスターがあるのは、既存の Container Insights と新機能の Container Insights を確認するためです）
作成したクラスターの詳細をみると、以下のようなダッシュボードが確認できます。

右側にタスクのステータスや CPU 使用率、メモリ使用率などのメトリクスが確認できます。
サービスでも同様の画面が見られます。


さらにタスクでもメトリクスが見られます。


また、タスク内のコンテナのメトリクスも確認できました。
特定のコンテナを選択して、[アクション]からログ、X-ray、パフォーマンスログが確認できます。

なお、今回の検証ではアプリケーションログや X-ray を出力するようなサイドカーをタスク定義にいれていないため確認はできません。
 料金について本機能を利用する場合は、ECS 環境全体で取り込まれたメトリックの数に基づいて課金されます。

以下の公式ドキュメントに詳細の計算方法があります。
https://aws.amazon.com/cloudwatch/pricing/?nc1=h_ls
1/Container Insights with enhanced observability for Amazon ECS
When using Container Insights with enhanced observability, you will be charged based on the number of metrics ingested across your container environment where this number is dependent on your container set-up including the number of container components. Assume a set-up where you monitor 1 container cluster with 5 unique service names, 10 unique task names with 20 unique task ids, and 50 average running containers, your charges would be as follows:
There is a predefined number of metrics reported for every cluster, task, service, and containers running on Fargate. Every cluster reports 29 metrics; every service reports 31 metrics; every task definition reports 26 metrics; every task reports 26 metrics, and every container reports 26 metrics. All CloudWatch metrics are prorated on an hourly basis. This example assumes that data points are reported for the entire month.
たとえば、今回の検証のようなクラスターの場合を想定します。
1 つのコンテナクラスター
1 つの一意のサービス名
1 の一意のタスク名を持つ 2 の一意のタスク ID
平均 2 つのタスク
また、前提としてドキュメントにあるように Fargate の場合は、すべてのクラスター、タスク、サービス、コンテナについて、AWS 側で定義済みの数のメトリクスが自動的に作成されます。

この場合、各コンテナレイヤーは以下の数のメトリクスを自動的に作成します。
クラスター： 29 個
サービス： 31 個
タスク定義： 26 個
タスク： 26 個
コンテナ： 26 個
この場合は、以下の計算になります。
メトリクスの計算
クラスターのメトリクス: 29 メトリクス 1 クラスター = 29 メトリクス
サービスのメトリクス: 31 メトリクス 1 サービス = 31 メトリクス
タスク定義のメトリクス: 26 メトリクス 1 タスク定義 = 26 メトリクス
タスクのメトリクス: 26 メトリクス 2 タスク ID = 52 メトリクス
コンテナのメトリクス: 26 メトリクス 2 コンテナ = 52 メトリクス
合計メトリクス数

29 + 31 + 26 + 52 + 52 = 190
以上から、us-east-1 の CloudWatch のメトリクスコストから月間のコストは以下のように算出できます。
月間 CloudWatch メトリクスコスト
メトリクス単価: $0.07
合計コスト: $0.07 × 190 = $13.30
この計算に基づき、指定された構成での月間 CloudWatch メトリクスコストは約$13.30 となります。
 リージョンについて中国リージョン（AWS GovCloud (US) Regions, China (Beijing, operated by Sinnet)、 China (Ningxia, operated by NWCD)）を含むすべてのパブリックリージョンで利用可能になっています。
 さいごにAmazon ECS の Container insights でオブザーバビリティが強化されて、クラスターレベルからコンテナレベルまでのメトリクスからの詳細な分析が可能になりました。
この機能を活用することで、ECS で構築したコンテナワークロードの監視と最適化がより効率的に行えるようになります。

ブログの例では、複数のアカウントにまたがるリソースの監視もできることが取り上げられていました。
ECS 環境を本番で運用するにあたって事前に有効化していると、トラブル発生時のインシデント対応で役に立つかもしれないですね。

この記事がどなたかの参考になれば幸いです。
 参考Container Insights with enhanced observability for Amazon ECS - Amazon CloudWatch
Container Insights with enhanced observability now available in Amazon ECS | AWS News Blog
料金 - Amazon CloudWatch | AWS