みなさんこんにちは。マネージドサービス部MSS課の塩野（正）です。
突然ですがコンテナって使われてますか？コンテナといってもEC2にdockerなどのコンテナエンジンをインストールして動かすパターンやAWS ECS Fargateのようなマネージドで動かすパターンまで色々あると思います。もちろん実際の運用環境にそれらが乗った場合にそれぞれの環境で見るべきポイントが違ってきたりします。そういえばAWS ECSを監視する際に標準CloudWatchメトリクス、Container Insights、そして強化オブザーバビリティ（Enhanced Observability）という3つの選択肢があって、個人的にそれぞれどう使い分ければいいんだっけ？となりましたので、今回はそのあたりをまとめてみました。
目次
概要
AWS ECSでコンテナを運用していると、「どのレベルまで監視すれば良いんだろう？」という悩みに必ずと言っていいほど直面しますよね。AWSには標準CloudWatchメトリクス、Container Insights、そして強化オブザーバビリティ（Enhanced Observability）という3つの選択肢があるのですが、それぞれで監視の詳しさやコスト、運用の手間が結構違ってくるんです。
この記事では、これら3つの監視方法がそれぞれどんな特徴を持っているのか、コスト面ではどう違うのか、そして実際の現場ではどんな場面でどれを選べばよいのかを、できるだけ分かりやすく整理してみました。皆さんがシステムに最適な監視戦略を見つけるお手伝いができれば嬉しいです。
3つの監視手法の基本的な違い
標準ECS CloudWatchメトリクス ～まずはここから始めよう～
標準ECSメトリクスは、ECSサービスによって自動的に提供される基本的な監視機能です。基本的な監視機能ですが、クラスターやサービスレベルでのリソース使用状況をしっかりと把握できます。
監視できるのは、CPU使用率、メモリ使用率、CPU予約率、メモリ予約率といった、システム運用で本当に大切な基本メトリクスに絞られています。データは1分間隔で収集されて、AWS/ECSネームスペースに保存される仕組みです。シンプルなWebアプリケーションや開発環境なら、この標準メトリクスだけでも必要十分な監視ができます。
Container Insights ～もう少し詳しく見てみたい場合～
Container Insightsを有効にすると、標準メトリクスに加えて、タスクレベルでのより詳しい監視ができるようになります。特に便利なのは、ネットワークトラフィック、ストレージI/O、タスクの起動・停止の様子など、マイクロサービス環境で「これが分かったらいいのに」と思っていた詳細な情報が手に入ることです。標準ECS CloudWatchメトリクスに比べると、追加で生成されるカスタムメトリクスのコストが追加料金となりますので、メトリクス数が増えるとその分コストも上がってしまう点は考慮しておく必要があります。
強化オブザーバビリティ ～最新の詳細監視機能～
2024年11月のAWS re:Inventで発表されたばかりの強化オブザーバビリティは、これまでで一番詳しいコンテナレベルの監視を可能にしてくれます。今まで「きっとこのコンテナが重いんだろうな」と推測するしかなかった「タスク内のどのコンテナがリソースを食っているのか」や「タスク間でのリソース使用量の偏り具合」などが、はっきりと見えるようになります。この機能が本当に力を発揮するのは、複雑なマルチコンテナアプリケーションや、絶対に止められないミッションクリティカルなシステムでしょう。
メトリクス比較表
以下の表は、各監視レベルで取得可能なメトリクスの詳細な比較です。運用計画を立てる際の参考としてご活用ください。
| メトリクス名 | 標準ECS | Container Insights | 強化オブザーバビリティ | 備考 |
|---|---|---|---|---|
| 基本リソースメトリクス | ||||
| CPUUtilization | ○ | ○ | ○ | CPU使用率（%） |
| CPUReservation | ○ | ○ | ○ | CPU予約率（%） |
| MemoryUtilization | ○ | ○ | ○ | メモリ使用率（%） |
| MemoryReservation | ○ | ○ | ○ | メモリ予約率（%） |
| EBSFilesystemUtilization | ○ | ○ | ○ | EBSファイルシステム使用率（%）※１ |
| Container Insights追加メトリクス | ||||
| ContainerInstanceCount | ○ | ○ | コンテナインスタンス数 | |
| DeploymentCount | ○ | ○ | サービスのデプロイ数 | |
| DesiredTaskCount | ○ | ○ | 希望タスク数 | |
| RunningTaskCount | ○ | ○ | 実行中タスク数 | |
| PendingTaskCount | ○ | ○ | 保留中タスク数 | |
| ServiceCount | ○ | ○ | サービス数 | |
| TaskCount | ○ | ○ | タスク総数 | |
| TaskSetCount | ○ | ○ | タスクセット数 | |
| RestartCount | ○ | ○ | コンテナ再起動回数 | |
| NetworkRxBytes | ○ | ○ | ネットワーク受信バイト数 | |
| NetworkTxBytes | ○ | ○ | ネットワーク送信バイト数 | |
| StorageReadBytes | ○ | ○ | ストレージ読み取りバイト数 | |
| StorageWriteBytes | ○ | ○ | ストレージ書き込みバイト数 | |
| EphemeralStorageReserved | ○ | ○ | 一時ストレージ予約量（GB） | |
| EphemeralStorageUtilized | ○ | ○ | 一時ストレージ使用量（GB） | |
| 強化オブザーバビリティ専用メトリクス | ||||
| ContainerCpuUtilized | ○ | コンテナCPU使用量 | ||
| ContainerCpuReserved | ○ | コンテナCPU予約量 | ||
| ContainerCpuUtilization | ○ | コンテナCPU使用率（%） | ||
| ContainerMemoryUtilized | ○ | コンテナメモリ使用量（MB） | ||
| ContainerMemoryReserved | ○ | コンテナメモリ予約量（MB） | ||
| ContainerMemoryUtilization | ○ | コンテナメモリ使用率（%） | ||
| ContainerNetworkRxBytes | ○ | コンテナネットワーク受信バイト数 | ||
| ContainerNetworkTxBytes | ○ | コンテナネットワーク送信バイト数 | ||
| ContainerStorageReadBytes | ○ | コンテナストレージ読み取りバイト数 | ||
| ContainerStorageWriteBytes | ○ | コンテナストレージ書き込みバイト数 | ||
| EBSFilesystemSize | ○ | EBSファイルシステムの合計容量 (GB)※１ | ||
| EBSFilesystemUtilized | ○ | EBSファイルシステムの合計容量 (GB)※１ | ||
| TaskCpuUtilization | ○ | タスクCPU使用率（%） | ||
| TaskMemoryUtilization | ○ | タスクメモリ使用率（%） | ||
| TaskEphemeralStorageUtilization | ○ | タスク一時ストレージ使用率（%） |
※１．ただしEBSボリュームがアタッチされているタスクの場合
どの場面でどの監視レベルを選ぶべきか
標準メトリクス ～こんな環境にぴったり～
標準メトリクスがおすすめなのは、システム構成がシンプルで「基本的なことが分かれば十分」という環境です。開発・検証環境や、シンプルなWebアプリ、静的コンテンツの配信システムなんかでは、余計な費用をかけずに必要な監視ができます。
それから、バッチ処理システムみたいに、構成がシンプルで「ネットワークの細かい分析まではいらないかな」という場合も、標準メトリクスで事足ります。CPU使用率やメモリ使用率といった基本的なリソース使用状況さえ見えていれば、基本的なキャパシティ管理では十分なケースが多いと思います。
Container Insights ～こんな時に検討してみて～
Container Insightsが本領を発揮するのは、マイクロサービスアーキテクチャを使っている環境や、サービス同士がよく通信するようなシステムです。API Gateway の下に複数のバックエンドサービスがぶら下がっているような構成や、データベースアクセスが多いアプリケーションでは、ネットワークトラフィックやストレージI/Oの詳細が見えると嬉しい時があります。
特にCI/CDパイプラインと組み合わせているシステムでは、デプロイがうまくいったかどうかや、タスクがちゃんと動いているかの管理が大事な指標になってきます。Container Insightsがあれば、こういった情報をしっかり把握できて、問題の早期発見や素早い対応ができるようになるでしょう。
CloudWatch Logsとカスタムメトリクスのデータ量が増えることによりその分コストも上がってしまうので、保存期間を調整したり、本当に必要なものだけに絞ったりして、上手にコスト管理していくことが大切です。
強化オブザーバビリティ ～本格的な監視が必要な時～
強化オブザーバビリティが一番力を発揮するのは、絶対に止められないミッションクリティカルなシステムや、アクセスが多いWebサービスです。決済システム、リアルタイム処理システム、機械学習の推論サービスなど、「ちょっとでも止まったら大変なことになる」レベルのシステムでは、コンテナ一つ一つまで詳しく分析できることが本当に重要になってきます。
この監視レベルになると、タスクの中でコンテナ同士がリソースを取り合っていないかとか、個々のコンテナがどんなパフォーマンスを出しているかまで分かるようになります。今まで「なんとなくここが重そう」と推測するしかなかった詳細なボトルネックの特定や、先回りしたキャパシティプランニングができるようになるので、高い可用性とパフォーマンスが求められる環境では、かけたコストに見合った効果が期待できるでしょう。
技術的制約と実装時の注意点
ネットワークメトリクス ～設定で気をつけたいポイント～
Container InsightsやContainer Insights強化オブザーバビリティでネットワークメトリクスを取得したい場合、ECSタスクのネットワークモード設定がちょっと重要になってきます。bridgeモードやawsvpcモードなら問題なくメトリクスが取得できるのですが、hostモードだと取得できないんです。
Fargateを使っている場合は自動的にawsvpcモードになるので特に心配はいりませんが、EC2起動タイプでhostモードを使っている既存のシステムがある場合は、ネットワークモードの変更を検討してみてもいいかもしれません。
プラットフォーム ～それぞれの特徴と制限～
Fargateを使っている場合、EphemeralStorageメトリクスはLinux platform version 1.4.0以降でないと使えないという制限があります。それから、インスタンスレベルのメトリクスは取得できないので、もしインフラレベルでもっと詳しく監視したいということであれば、EC2起動タイプを検討してみるのも一つの手です。
EC2起動タイプの場合は、インスタンスレベルのメトリクスを取得するのにCloudWatchエージェントの追加設定が必要になります。GPUを使っているワークロードでは、GPUインスタンスを使っている時だけGPUメトリクスが取得できる仕組みになっています。
まとめ
AWS ECSの監視戦略選択は、システムがどのくらい重要か、技術的にどんなことが必要か、そしてコストはどこまでかけられるかを総合的に考えて決めていくのがベストです。基本的な監視で事足りそうなら標準メトリクスから始めて、「ネットワークやストレージもちゃんと見たいな」となったらContainer Insights、「コンテナ一つ一つまで詳しく知りたい」という場合にContainer Insights強化オブザーバビリティに移行していく、という段階的なやり方が現実的だと思います。
大切なのは、いきなり大きく始めずに、小さな環境でまずはお試し（PoC）から始めて、実際に使ってみて分かったことを元に少しずつ機能を広げていくことです。それから、監視に求められることは時間が経つにつれて変わってくるものなので、定期的に「これで合っているかな？」と見直しを行って、システムの成長に合わせて調整し続けることが、うまくいくコツだと思います。
適切な監視戦略を選ぶことで、システムの安定性を高めながらコストも最適化するという、両方のいいとこ取りができるはずです。この記事で紹介した選び方の基準や設定方法を参考にして、皆さんの環境にぴったりの監視レベルを見つけてもらえればと思います。
