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

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

リテールアプリ共創部の中野です。

本日、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」という名前がマネコン上に表示されていました。

スクリーンショット 2024-12-02 0.07.55.png

この機能は、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 News Container Insights 2024.png

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

スクリーンショット 2024-12-01 22.51.00.png

クラスターレベルの Container insights 設定

今回は、バージニア北部(us-east-1)でクラスターを作成します。

作成画面の[モニタリング - オプション]内にある[オブザーバビリティが強化された Container Insights]のラジオボタンを選択します。

スクリーンショット_2024-12-01_21_31_58.png

スクリーンショット_2024-12-01_21_32_12.png

前提で作成したタスク定義を利用してサービスを作成します。
タスク数は 2 つにして Fargate で起動しました。

CloudWatch Container Insights 上でモニタリング

しばらくすると Container Insights 上に情報が反映されます。

たとえば、一覧画面だと現在稼働中のクラスターとサービス状態が見られます。
(2 個 6 角形のクラスターがあるのは、既存の Container Insights と新機能の Container Insights を確認するためです)

スクリーンショット 2024-12-02 0.36.10.png

作成したクラスターの詳細をみると、以下のようなダッシュボードが確認できます。
右側にタスクのステータスや CPU 使用率、メモリ使用率などのメトリクスが確認できます。

スクリーンショット 2024-12-02 0.42.18.png

サービスでも同様の画面が見られます。

スクリーンショット 2024-12-02 0.56.38.png
スクリーンショット 2024-12-02 0.32.42.png

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

スクリーンショット 2024-12-02 0.44.08.png
スクリーンショット 2024-12-02 0.44.15.png

また、タスク内のコンテナのメトリクスも確認できました。

スクリーンショット 2024-12-02 0.45.21.png

特定のコンテナを選択して、[アクション]からログ、X-ray、パフォーマンスログが確認できます。
なお、今回の検証ではアプリケーションログや X-ray を出力するようなサイドカーをタスク定義にいれていないため確認はできません。

スクリーンショット_2024-12-02_0_46_13.png

料金について

本機能を利用する場合は、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 環境を本番で運用するにあたって事前に有効化していると、トラブル発生時のインシデント対応で役に立つかもしれないですね。
この記事がどなたかの参考になれば幸いです。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.