Zabbix＋サイドカーコンテナを用いたECS on Fargate環境のリソース監視
はじめに
ビジネスにおける柔軟性や速度が重要になってきた昨今において、アジャイル開発やDevOpsといった開発・運用方式に多くの企業が本格的に取り組んでおります。
それらを実現する技術の一つとして、WEBシステムを中心に様々な場面で活用されているのが“コンテナ技術”です。
このコンテナ技術を用いた環境においても、物理サーバや仮想サーバを用いる環境と同様に、キャパシティ管理等の目的のためにリソース情報（CPU使用率やメモリ使用率など）を収集・監視することが必要です。
コンテナの監視の方法としてはいろいろな手段があるかと思われますが、本記事ではシステム監視でよく用いられる、OSSのZabbixを用いてFargate上で稼働するAmazon ECS(Amazon Elastic Container Service)（以降ECS）コンテナリソース監視の実施方法を検討した内容について記載いたします。
1.ECS on Fargate環境での監視にZabbixを採用するケース
ECS on Fargate環境でコンテナ監視を実現するツールとして真っ先に考えられるのは、Amazon CloudWatch Container Insights(※1)を利用する方式です。
また、Amazon Managed Service for Prometheusでメトリクスを収集し(※2)、Amazon Managed Grafanaで可視化するといった方法でもAWSのサービスのみで実現が可能です。
その他3rdPartyの製品やサービスを利用することでもコンテナの監視をスムーズに実現することは可能かと思われます。
そんな中で、以下のようなケースにおいてはコンテナ監視の方法としてZabbixを採用するケースもあります。
①既存の監視システムとしてZabbixを利用している
②マルチアカウント（AWSアカウント）、マルチリージョンの環境において一括モニタリングだけでなく、一括管理を実施したい
③監視時間帯の細かい制御(※3)やメンテナンス機能(※4)を用いた静観設定などの運用管理に関する機能を活用したい
最も多いのは①のケースではないかと思いますが、上記のような制約や要件がある場合にはAmazon CloudWatch やAmazon Managed Service for Prometheus ではなくZabbixを採用するケースがあると考え、ZabbixでのECS on Fargateのコンテナ監視について検討した内容を以降で記載していきます。
＜参考＞
※1 Container Insights の使用
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/ContainerInsights.html
※2 Metrics collection from Amazon ECS using Amazon Managed Service for Prometheus
https://aws.amazon.com/jp/blogs/opensource/metrics-collection-from-amazon-ecs-using-amazon-managed-service-for-prometheus/
※3 Zabbix- 2 監視間隔のカスタマイズ
https://www.zabbix.com/documentation/6.0/jp/manual/config/items/item/custom_intervals
※4 Zabbix-メンテナンス
https://www.zabbix.com/documentation/6.0/jp/manual/maintenance
2.CloudWatch Container Insights vs サイドカーコンテナ（Zabbix Agent）
ZabbixでECS on Fargate環境の各コンテナのパフォーマンスを監視する場合に、最もシンプルな方法は各ECSサービスにおいてContainer Insightsを有効化し、ZabbixからAmazon CloudWatchメトリクスを取得する方式となります。
上記の場合でも大きく以下の二つの方法が考えられます。
①Zabbixサーバ自身がスクリプト等でECSのAmazon CloudWatchメトリクスを取得する。
②Zabbixサーバとは別にLambda等を定期的に実行し、ECSのAmazon CloudWatchメトリクスを取得、Zabbix Sender等(※5)でZabbixにデータを送信する。
シンプルな実装としては①となりますが、監視対象のECSが増えるほどZabbixサーバ自身の負荷が高くなり監視全体に影響が出る懸念がでてきます。
そのため、大規模な環境での監視の場合にはZabbixサーバの負荷を分散するといった観点から②の方法が良いかと思われます。
ただし、こちらについても監視対象のECSの数や取得するメトリクス数次第ではAWS Lambda等のコストがかかってくるため、コストについてはあらかじめ整理しておく必要があります。
また、どちらの方式でもContainer Insightsを有効化するため少なからずコストがかかってきます。
Amazon CloudWatch 料金表(※6)のECSのContainer Insightsの情報から試算すると、少なくとも1クラスターあたり25のカスタムメトリクスがあるため、$0.3（カスタムメトリクスの料金）×25（メトリクス数）=$7.5、為替次第ですが1クラスターあたり1,000円/月ほどのコストとなります。
ボリュームディスカウントがあるため、単純にクラスター数に比例するわけではありませんが、規模が大きくなるほどコスト影響が大きくなることが懸念されます。
※5 Zabbix- 6 Sender
https://www.zabbix.com/documentation/2.2/jp/manual/concepts/sender
※6 Amazon CloudWatch 料金表
https://aws.amazon.com/jp/cloudwatch/pricing/
例11 – Amazon ECS用 Container insights
AWSコストを抑えつつ、Zabbixでの監視を実現する方法としてまず初めに検討したのが、各ECSタスクのサイドカーコンテナとしてZabbix Agentを導入したZabbix Agentコンテナを配置し、Zabbix AgentコンテナでECSタスクのリソース情報を取得する方式です。
以下が簡易的な構成図となります。
本方式でリソース監視を実現すれば、ECSサービスごとにContainer Insightsを有効化する必要がなく、AWS Lambdaの設計なども不要なためコスト面、構成面ともにシンプルになると考えました。
そのため、本方式でECSのリソース監視が可能かを確認するために、監視対象のECSでContainer Insightsを有効化し、Container Insightsで取得したメモリ使用量、CPU使用量とZabbix Agentから取得したメモリ使用量、CPU使用量の比較を実施しました。
結論から述べると、サイドカーコンテナ（Zabbix Agent）の方式ではECS on Fargate上でのリソース監視は実現できませんでした。
実際にZabbix AgentでCPU使用量、メモリ使用量といったデータ自体は取得できましたが、以下の図のようになりました。
（Zabbix=Zabbix Agent、CloudWatch Container Insight= Container Insights）
Container Insightsで取得した値に対して、サイドカーコンテナ（Zabbix Agent）で取得した値には大きなズレが発生してしまいました。
原因として、Zabbix Agentが取得したCPU使用量、メモリ使用量は、監視対象としているコンテナのリソースではなく、サイドカーコンテナ（Zabbix Agent）のみのリソース使用量もしくはFargateホストに対する使用率を取得してしまったため、Container Insightsで取得した値と大きくズレがでてしまったものと思われます。
3.サイドカーコンテナでECSメタデータを用いたパフォーマンス監視
次に検討したのがZabbix Agentの標準機能でデータを取得するのではなく、Amazon ECSタスクメタデータエンドポイント（※7）からデータを取得する方式です。
ECSタスクのコンテナ内からcurlコマンド等でAmazon ECSタスクメタデータエンドポイントにアクセスすると、ECSタスク及びコンテナに関する様々な情報(ECSタスクメタデータ)をjson形式で取得できます。
データ取得例：curl ${ECS_CONTAINER_METADATA_URI_V4}/task
実際に取得できるデータについては(※8)のページに記載されています。
例として、CPU使用量は「${ECS_CONTAINER_METADATA_URI_V4}/task/stats/」で取得したjsonの"cpu_stats.cpu_usage”内の"total_usage"や"percpu_usage"から値を取得することができます。”jq”などを利用することで、json形式データから目的のデータをスムーズに取得することができます。
※7 Amazon ECSタスクメタデータエンドポイント
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/task-metadata-endpoint-fargate.html
※8 タスクメタデータエンドポイントバージョン 4
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/task-metadata-endpoint-v4-fargate.html
このECSタスクメタデータにコンテナ毎のCPUやメモリの使用状況のデータも含まれているため、サイドカーコンテナからECSタスクメタデータを取得し、Zabbixに送信することでZabbixでのECS on Fargateでのコンテナリソースの監視が実現できると考えました。
実装した方式及び構成図は以下の通りとなります。
① サイドカーコンテナ上で実行することで、ECSタスクメタデータからCPU使用量、メモリ使用量を取得し、Zabbix SenderでZabbixサーバにデータを送信するスクリプトを作成
② スクリプトを実行するためのサービス（curl、Zabbix Senderなど）をインストールし、①のスクリプトを定期実行するcronを設定したDockerイメージを作成
③ ②のDockerイメージを監視対象のサイドカーコンテナとして起動、cronが定期的にスクリプトを実行し、リソースデータを収集、Zabbixに送信
Zabbix Agentと同じようにContainer Insightで取得したCPU、メモリ使用量とECSタスクメタデータで取得した結果の比較検証を実施しました。
結果は以下の図のようになりました。（Amazon CloudWatch= Container Insight、Zabbix＝ECSタスクメタデータ）
ECSタスクメタデータで取得したデータはContainer Insightと完全に一致はしませんでしたが、負荷に応じて同じような傾向の値が取得できました。
検証時には単純に1分間隔のデータを取得しましたが、取得間隔を短くして平均値を取得するなどの工夫をすればより近い値が取得できるのではないかと考えています。
上記結果を踏まえて、サイドカーコンテナからECSタスクメタデータを取得するという方式でもAmazon ECS on Fargate環境上のコンテナリソース監視が可能であると思われます。
今回検証したサイドカーコンテナを利用した方式とContainer Insightを利用した方式での比較表を下記に記載します。
監視対象数が少ない場合にはコスト差はほぼないかと思われますが大規模な環境の監視を行う場合にはサイドカー方式の方が、コストメリットが出てくるのではないかと考えております。
4.まとめ
本記事ではECSタスクメタデータとサイドカーコンテナを利用することで、Amazon CloudWatch Container Insightを有効化せずに、Zabbix でのAmazon ECS on Fargate環境のコンテナリソース監視（CPU、メモリなど）を実現する方法について記載しました。
単純にコンテナ環境を監視した場合にはAmazon CloudWatch Container InsightやAmazon Managed Service for PrometheusなどAWSが提供するサービスを活用したほうがスムーズに監視を実現できるとは思われますが、運用要件や制約などでZabbixを用いた監視が必要な場合の一案として参考となりましたら幸いです。
TISではサーバ環境・サーバレス環境問わず様々なシステム/サービスの構想・要件定義・設計・構築・運用に携わっております。AWSをはじめとしたクラウドやオンプレ環境でのシステム及びサービスの実現に際してお困りのお客様がおられましたら、是非TISまでご相談ください。
著：TIS株式会社
IT基盤技術事業本部 IT基盤技術事業部
IT基盤エンジニアリング第4部
上級主任 布川 将来人
