クラスターを詳細監視する「Container Insights」のセットアップと有効化【前編】

はじめに

前回では、CloudWatchアラームを使った自動通知の仕組みを学びました。CPU使用率、ネットワークトラフィック、Auto Scaling Groupの最大サイズ検知など、基本的なアラームを設定し、問題を早期に検知できるようになりました。

そこでは、メモリ使用率やディスク使用率のアラームについても触れましたが「Container Insightsの有効化が必要」と簡単に説明するにとどめました。Container Insightsによる詳細監視について、今回(第21回)と次回(第22回)の2回に分けて詳しく解説します。

今回は前編として、Container Insightsとは何か、どのように有効化するのかを解説します。次回の後編では、具体的な使い方や監視すべき重要なメトリクスについて解説していきます。

Container Insightsとは

「Container Insights」はAmazon EKSやKubernetesクラスターの詳細な監視を実現するCloudWatchの機能です。

より詳細な監視の必要性

基本的なEC2レベルのメトリクス(CPU、ネットワーク)だけでは、Kubernetes特有の問題を検知できません。例えば、以下のような状況を考えてみましょう。

• 特定のPodだけがメモリを大量消費している

• ノード全体のディスク使用率は正常だが、特定のコンテナがログを大量出力している

• Pod間のリソース競合が発生している

• Podの再起動(Restart)が頻発している

これらの問題を検知するには、Kubernetesレベルのメトリクスが必要です。Container Insightsを有効化することで、Pod、コンテナ、ノードレベルの詳細なメトリクスを収集・可視化できるようになります。

収集できるメトリクス

Container Insightsを有効化すると、以下のレベルのメトリクスを収集できます。

ノードレベル

• node_cpu_utilization: ノードのCPU使用率
• node_memory_utilization: ノードのメモリ使用率
• node_filesystem_utilization: ノードのディスク使用率
• node_network_total_bytes: ノードのネットワーク転送量

Podレベル

• pod_cpu_utilization: PodのCPU使用率
• pod_memory_utilization: Podのメモリ使用率
• pod_number_of_container_restarts: Podのコンテナ再起動回数

コンテナレベル

• container_cpu_utilization: コンテナのCPU使用率
• container_memory_utilization: コンテナのメモリ使用率

クラスターレベル

• cluster_node_count: クラスター内のノード数
• cluster_failed_node_count: 失敗したノード

これらのメトリクスの詳しい活用方法については、次回(第22回)で解説します。詳細なメトリクスの一覧は「Container Insightsメトリクスリファレンス」を参照してください。

Amazon CloudWatch Observability EKS add-on

Container Insightsを有効化する最新の推奨方法は「Amazon CloudWatch Observability EKS add-on」を使用する方法です。

このadd-onをインストールすると、以下のコンポーネントが自動的にデプロイされます。

• CloudWatch Agent: インフラメトリクスを収集

• Fluent Bit: コンテナログをCloudWatch Logsに送信

• CloudWatch Application Signals: アプリケーションパフォーマンステレメトリを収集(オプション)

従来はCloudWatch AgentやFluent Bitを手動でデプロイする必要がありましたが、add-onを使うことで、これらのコンポーネントを一括で管理できるようになりました。

Container Insightsの料金体系

Container Insightsを有効化する前に、料金体系を理解しておくことが重要です。Container Insightsは、以下の料金が発生します。詳細は「CloudWatch料金ページ」を参照してください。

監視データ(Observations)の料金

Amazon CloudWatch Observability EKS add-onを使用した Container Insightsでは、収集される監視データはObservationsという単位で課金されます。Observationsにはメトリクスデータポイントやパフォーマンス情報が含まれます。

• $0.21/100万Observations

例えば、1クラスター、10ノード、1Namespace、5サービス、16ワークロード、20Pod、20コンテナのクラスターを監視する場合、1ヶ月あたり約2.46億Observationsが収集され、月額約$51.75の料金が発生します(AWS公式の料金例より)。

クラスターの規模(ノード数、Pod数、サービス数など)によって収集されるObservationsの数が変わるため、料金も比例して増加します。

ログの料金

Fluent Bitがコンテナログを収集し、CloudWatch Logsに保存します。ログの料金は、以下の2つの要素で構成されます。

• 取り込み料金: $0.50/GB(最初の5GBまでは無料)

• 保存料金: $0.03/GB/月(最初の5GBまでは無料)

Container Insightsは、ログにメタデータを追加するため、1ログ行あたり約700バイトの追加データが発生します。ログの出力量が多いアプリケーションの場合、ログの料金が高額になる可能性があります。

なぜ第20回で有効化しなかったのか

第20回ではCloudWatchアラームの設定方法を解説しましたが、Container Insightsは有効化しませんでした。その理由は、Container Insightsを有効化すると追加の料金が発生するためです。

監視は重要ですが、どのようなメトリクスが収集され、どの程度の料金が発生するかを理解した上で有効化することが大切です。今回と次回(第21回・第22回)でContainer Insightsの機能と料金体系を理解し、コストとメリットを比較した上で有効化するかを判断できるようになります。

開発環境ではコスト削減のためにContainer Insightsを無効化し、本番環境でのみ有効化するという運用も検討できます。

Container Insightsの有効化

Container Insightsを有効化する方法はいくつかありますが、本記事ではAWSマネジメントコンソールを使う方法とTerraformでコード化する方法を解説します。

方法1: AWSコンソールから有効化

最も簡単な方法は、AWSマネジメントコンソールからadd-onを有効化する方法です。Container Insightsを使用するには、まずEKS Pod Identity Agent add-onをインストールする必要があります。

ステップ1: EKS Pod Identity Agent add-onのインストール

1. AWSマネジメントコンソールにログイン
2. 「Amazon EKS」サービスを開く
3. 左側メニューから「クラスター」を選択
4. Container Insightsを有効化したいクラスター(例: <code>eks-dev<code>)をクリック
5. クラスター詳細画面で「アドオン」タブをクリック
6.  「アドオンを追加」ボタンをクリック
7. アドオン一覧から「Amazon EKS Pod Identity Agent」を選択
8.  「次へ」をクリックし、デフォルト設定のまま「作成」をクリック

アドオン一覧から「Amazon EKS Pod Identity Agent」を選択

ステップ2: CloudWatch Observability add-onのインストール

Pod Identity Agentのインストールが完了したら、次にCloudWatch Observability add-onをインストールします。

1. 同じ「アドオン」タブで「アドオンを追加」ボタンをクリック
2. アドオン一覧から「Amazon CloudWatch Observability」を選択
3.  「次へ」をクリック

アドオン一覧から「Amazon CloudWatch Observability」を選択

ステップ3: IAMロールの設定

1.  「サービスアカウントIAMロール」で「新しいロールを作成」を選択
2. ロール名を入力(例: <code>CloudWatchAgentServerRole<code>)
3. 必要な権限ポリシー(CloudWatchAgentServerPolicy)が自動的にアタッチされます
4.  「次へ」をクリック

ステップ4: 設定の確認と作成

1. 設定内容を確認
2.  「作成」をクリック

インストールが完了するまで数分かかります。「アドオン」タブで両方のadd-onのステータスが「アクティブ」になれば、インストール完了です。

両方のadd-onが「アクティブ」になった画面

add-onが正しくデプロイされたか確認します。

$ kubectl get pods -n amazon-cloudwatch
# 出力例
NAME                                  READY   STATUS    RESTARTS   AGE
cloudwatch-agent-xxxxx                1/1     Running   0          2m
fluent-bit-xxxxx                      1/1     Running   0          2m

動作確認

Container Insightsが正しく動作しているか確認します。以下の2つの方法で確認できます。

1. CloudWatch Logsでログググループの確認

Container Insightsが有効化されると、/aws/containerinsights/<cluster-name>/performanceというログググループが自動的に作成されます。

以下の手順で確認します。

1. CloudWatchコンソールを開く
2. 左側メニューから「ログ管理」を選択
3. ロググループ一覧から/aws/containerinsights/<cluster-name>/performanceが作成されていることを確認

CloudWatch Logsのロググループ一覧

2. Container Insightsダッシュボードでメトリクスの確認

CloudWatchコンソールの「Container Insights」でダッシュボードを開き、CPU使用率、メモリ使用率、ネットワーク転送量などのメトリクスが表示されていれば、Container Insightsが正しく動作しています。詳細なダッシュボードの使い方は、次回(第22回)で詳しく解説します。

【注意】: メトリクスが表示されるまで数分かかる場合があります。Podが起動直後の場合はCloudWatch Agentを再起動(kubectl rollout restart daemonset/cloudwatch-agent -n amazon-cloudwatch)することで、Pod Identityの設定が反映され、メトリクス収集が開始されます。

方法2: Terraformでadd-onを管理

第16回で作成したEKSモジュールに、Container Insightsのadd-onを追加します。Terraformを使ってインフラをコード化している場合は、add-onもコードで管理することで環境の再現性が向上します。

terraform/modules/eks/main.tfに以下のコードを追加します。
# EKS Pod Identity Agent add-on(前提条件)
# Pod Identityを使用するために必要
resource "aws_eks_addon" "pod_identity_agent" {
 cluster_name = aws_eks_cluster.main.name
 addon_name   = "eks-pod-identity-agent"
 depends_on = [
   aws_eks_node_group.main
 ]
}
# CloudWatch Observability add-onのためのIAMロール
# EKS Pod Identityを使用: https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/pod-identities.html
resource "aws_iam_role" "cloudwatch_agent" {
 name = "${var.cluster_name}-cloudwatch-agent-role"
 assume_role_policy = jsonencode({
   Version = "2012-10-17"
   Statement = [
     {
       Effect = "Allow"
       Principal = {
         Service = "pods.eks.amazonaws.com"
       }
       Action = [
         "sts:AssumeRole",
         "sts:TagSession"
       ]
     }
   ]
 })
}
# CloudWatch Agentに必要な権限をアタッチ
resource "aws_iam_role_policy_attachment" "cloudwatch_agent_policy" {
 role       = aws_iam_role.cloudwatch_agent.name
 policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
}
# CloudWatch Observability add-on
# Terraform ドキュメント: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon
resource "aws_eks_addon" "cloudwatch_observability" {
 cluster_name             = aws_eks_cluster.main.name
 addon_name               = "amazon-cloudwatch-observability"
 service_account_role_arn = aws_iam_role.cloudwatch_agent.arn
 depends_on = [
   aws_eks_addon.pod_identity_agent
 ]
}
# EKS Pod Identity Association
# add-onとIAMロールを関連付ける
resource "aws_eks_pod_identity_association" "cloudwatch_agent" {
 cluster_name    = aws_eks_cluster.main.name
 namespace       = "amazon-cloudwatch"
 service_account = "cloudwatch-agent"
 role_arn        = aws_iam_role.cloudwatch_agent.arn
 depends_on = [
   aws_eks_addon.cloudwatch_observability
 ]
}

第16回で説明したように、環境ごとのディレクトリでTerraformを適用します。

$ cd terraform/environments/dev
$ terraform plan
$ terraform apply

同様に、本番環境にも適用する場合はterraform/environments/prodディレクトリで実行します。

適用後、AWSコンソールから有効化した場合と同じ方法で動作確認を行います。CloudWatch Logsでログググループが作成されていることと、Container Insightsダッシュボードでメトリクスが表示されていることを確認してください。

おわりに

今回(第21回)では、Container Insightsのセットアップと有効化について学びました。

Amazon CloudWatch Observability EKS add-onを有効化することで、ノード、Pod、コンテナレベルの詳細なメトリクスを収集できるようになりました。これにより、Kubernetes特有の問題を検知するための基盤が整いました。

次回(第22回・後編)では、Container Insightsの具体的な使い方について解説します。Container Insightsダッシュボードの見方や、監視すべき重要なメトリクス、トラブルシューティングの方法を紹介します。