Amazon Web Services ブログ
CloudWatch アラームを使用した Amazon MSK の本番環境向けモニタリングの設定
本記事は 2026 年 3 月 3 日 に公開された「Set up production-ready monitoring for Amazon MSK using CloudWatch alarms」を翻訳したものです。
Apache Kafka をストリーミングプラットフォームとして運用する組織には、安定した運用を維持するための十分なモニタリングが欠かせません。ブローカーの健全性、リソース使用率、データフローのメトリクスを適切に把握できなければ、サービス中断、データ損失、パフォーマンス低下といったリスクが生じ、重要なビジネスオペレーションに影響しかねません。高いシステム負荷から接続の問題まで、異常を早期に検知し、本番ワークロードに影響が出る前に予防措置を講じるには、効果的なモニタリングとアラートが不可欠です。
Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、詳細なメトリクスを Amazon CloudWatch に発行することで、モニタリングの課題に対応します。プロビジョンド (Standard) クラスターでは 1 分間隔でメトリクスが出力され、粒度とコストを制御するための柔軟なモニタリングレベル (DEFAULT、PER_BROKER、PER_TOPIC_PER_BROKER、PER_TOPIC_PER_PARTITION) が用意されています。DEFAULT レベル (無料) ではクラスターレベルのメトリクスが利用でき、上位レベル (有料) ではブローカーレベル、トピック単位、パーティション単位のメトリクスが公開されます。
本記事では、Amazon CloudWatch を使用した MSK クラスターの効果的なモニタリング方法を紹介します。ブローカーの健全性、リソース使用率、コンシューマーラグなどの重要なメトリクスの追跡方法と、運用上の問題を未然に防ぐための自動アラートの設定方法を解説します。紹介するプラクティスは、ストリーミングオペレーションの信頼性向上、リソース使用の最適化、ミッションクリティカルなアプリケーションの高可用性確保に役立ちます。
モニタリングすべき主要メトリクス
本記事では、Amazon MSK の重要なメトリクスを論理的なカテゴリに分類しています。各カテゴリの主要メトリクスとその意味を説明します。
- ブローカーの健全性とクラスターの可用性:
- ActiveControllerCount はクラスターレベルのメトリクスで、各ブローカーがアクティブコントローラーかどうか (1 または 0) を報告します。正常なクラスターでは、常に 1 つのブローカーだけがアクティブコントローラーとして機能します。average 統計で表示すると、値は 1 をブローカー数で割った値になります。例えば、3 ブローカーのクラスターでは 0.33 (1/3) と表示されます。CloudWatch アラームのしきい値はこれに応じて設定してください。6 ブローカーの場合、average が 0.166 (1/6) を下回ったらアラートを発報します。sum 統計では、クラスターサイズに関係なく値は常に 1 になり、アクティブコントローラーが 1 つ存在することを示します。sum が 1 以外の場合、コントローラー選出が進行中です。これは通常、メンテナンス作業、設定変更、ローリングリスタート時に発生します。
注意: KRaft ベースのクラスターでは、ActiveControllerCount は専用のコントローラーエンドポイントでのみ公開されるため、サンプル数は 3 で、コントローラーのみが 1 の値を報告します。そのため、クラスター内のブローカー数に関係なく average は常に 0.33 です。KRaft ベースのクラスターでブローカーの健全性を監視するには、LeaderCount メトリクスを確認してください。ブローカーがメトリクスを出力していない場合、そのブローカーに問題がある可能性を示す良い指標です。 - OfflinePartitionsCount (クラスター): アクティブなリーダーがないパーティションの数です。0 以外の値は、データが一時的に利用不可または書き込み不可であることを意味します。0 を超えたらアラートを発報してください。
- UnderReplicatedPartitions (ブローカー単位): すべてのレプリカが追いついていないパーティションの数です。通常は 0 のままであるべきです。スパイクはトラフィックが容量を超えているか、レプリケーションラグが発生していることを示します。持続的な値は設定や ACL の問題を示すことが多いです。Amazon MSK クラスターのトラブルシューティングを参照してください。
- UnderMinIsrPartitionCount (ブローカー単位): 最小 In-Sync Replica (ISR) 数を下回っているパーティションです。0 以外の値は、ブローカー障害時にデータ損失のリスクがあることを意味します。レプリケーションの健全性を確保するために監視してください。カスタム設定を参照してください。
- GlobalPartitionCount (クラスター): すべてのトピックにわたるパーティションの合計数 (リーダーのみ) です。キャパシティプランニングや整合性チェックに役立ちます。
- PartitionCount (ブローカー単位): ブローカーがホストするパーティション数 (レプリカを含む) です。急激な変化はリバランスが発生している可能性を示します (ブローカーあたりのパーティション数が過剰になるとパフォーマンスが低下する可能性があります)。
- ActiveControllerCount はクラスターレベルのメトリクスで、各ブローカーがアクティブコントローラーかどうか (1 または 0) を報告します。正常なクラスターでは、常に 1 つのブローカーだけがアクティブコントローラーとして機能します。average 統計で表示すると、値は 1 をブローカー数で割った値になります。例えば、3 ブローカーのクラスターでは 0.33 (1/3) と表示されます。CloudWatch アラームのしきい値はこれに応じて設定してください。6 ブローカーの場合、average が 0.166 (1/6) を下回ったらアラートを発報します。sum 統計では、クラスターサイズに関係なく値は常に 1 になり、アクティブコントローラーが 1 つ存在することを示します。sum が 1 以外の場合、コントローラー選出が進行中です。これは通常、メンテナンス作業、設定変更、ローリングリスタート時に発生します。
- リソース使用率:
- CPU: ブローカーの合計 CPU 使用率は CpuUser + CpuSystem で定義されます。ベストプラクティスとして、平均 CPU 使用率を 60% 未満に維持してください。user + system の合計にアラームを設定して過負荷を検知します。
- CPUCreditBalance / CPUCreditUsage (ブローカー単位): バースト可能なインスタンスタイプ (T3) の場合、獲得/消費した CPU クレジットを追跡します。クレジット残高の減少やクレジット使用量の増加は、インスタンスが CPU 不足になる可能性を警告します。
- メモリ: MemoryUsed、MemoryFree (ブローカー単位) は RAM 使用量を示します。特に重要なのは HeapMemoryAfterGC (ブローカー単位) で、ガベージコレクション後の JVM ヒープ使用率 (%) を報告します。AWS は、メモリ不足を防ぐために HeapMemoryAfterGC が 60% を超えた場合にアラートを発報することを推奨しています。
- ディスク: Kafka ブローカーはトピックデータにアタッチされた EBS ストレージを使用します。KafkaDataLogsDiskUsed (ブローカー単位) を監視してください。これはメッセージログが使用しているディスクの割合です。ベストプラクティス: データログ使用率が 85% を超えたらアラームを設定してください。また、RootDiskUsed (ブローカーが使用するルートディスクの割合) も追跡してください。
- EBS I/O: ボリュームメトリクス (ブローカー単位) として VolumeQueueLength、VolumeReadOps、VolumeWriteOps、VolumeReadBytes、VolumeWriteBytes があり、I/O レイテンシーとスループットを示します。キュー長の増加やレイテンシー (VolumeTotalReadTime など) の上昇は、ディスクの競合を示唆します。
- ネットワーク: ブローカー単位の基本的なネットワーク統計には、NetworkRxPackets、NetworkTxPackets、エラー/ドロップ数 (NetworkRxErrors、NetworkTxErrors、NetworkRxDropped、NetworkTxDropped) があります。予期しないエラーやドロップはネットワークの問題を示す可能性があります。
- トピックとパーティションのアクティビティ:
- スループット: BytesInPerSec と BytesOutPerSec は、ブローカー単位またはトピック単位の受信/送信データレートを測定します。持続的な低下はプロデューサー/コンシューマーの喪失を示す可能性があり、スパイクはスケーリングが必要な場合があります。
- レプリケーショントラフィック: ReplicationBytesInPerSec / ReplicationBytesOutPerSec (トピック単位) は、ブローカー間のレプリケーション量を示します。
- コンシューマーラグ: コンシューマーラグメトリクスは、トピックに書き込まれた最新データとアプリケーションが読み取ったデータの差を定量化します。Amazon MSK は、Amazon CloudWatch または Prometheus によるオープンモニタリングで取得できる以下のコンシューマーラグメトリクスを提供します: EstimatedMaxTimeLag、EstimatedTimeLag、MaxOffsetLag、OffsetLag、SumOffsetLag。これらのメトリクスの詳細は、CloudWatch を使用した Standard ブローカーの Amazon MSK メトリクスを参照してください。
- クライアント接続:
- ConnectionCount (ブローカー単位): アクティブな接続の合計数 (クライアント + ブローカー間) です。急激な減少や持続的な高い値 (上限に達している場合) は注意が必要です。
- ClientConnectionCount (ブローカー単位、認証フィルター付き): アクティブな認証済みクライアント接続数です。
- ConnectionCreationRate / ConnectionCloseRate (ブローカー単位): 1 秒あたりの新規接続数または切断数です。接続チャーンのスパイクはクライアント側の問題を示す可能性があります。
- 認証: IAMNumberOfConnectionRequests と IAMTooManyConnections (ブローカー単位) は、IAM 認証リクエストレートとスロットル違反 (同時接続数 100 の上限) を示します。
- ネットワーク帯域幅メトリクス:
- TrafficShaping > 0 (スロットリング発生) メトリクスは、主要な警告シグナルです。この値が 0 を超えると、MSK クラスターで EC2 レイヤーのネットワークスロットリングが発生しており、割り当てを超過したためにパケットがドロップまたはキューイングされています。このスロットリングは、スループットの低下、レイテンシーの増加、ネットワークエラーとして現れ、プロデューサーとコンシューマー双方のパフォーマンスに影響します。TrafficShaping の問題は、BwInAllowanceExceeded と BwOutAllowanceExceeded の 2 つの帯域幅制限に起因します。
- BwInAllowanceExceeded は、受信の合計帯域幅がブローカーの上限を超えた場合を追跡します。
- BwOutAllowanceExceeded は、送信の合計帯域幅が上限を超えた場合を監視します。
BwInAllowanceExceeded と BwOutAllowanceExceeded の両メトリクスは、ネットワークスロットリングイベント全体に直接影響します。
- その他の運用メトリクス:
- スレッドプール: RequestHandlerAvgIdlePercent、NetworkProcessorAvgIdlePercent (ブローカー単位) は、Kafka の内部スレッドプールのビジー状態を示します。アイドル率 (%) が常に低い場合、ボトルネックの可能性があります。
- ZooKeeper: ZooKeeper ベースの MSK クラスターでは、ZooKeeperRequestLatencyMsMean と ZooKeeperSessionState が ZK のパフォーマンスを反映します (ZooKeeper を使用する古い Kafka バージョン向け)。ZooKeeperSessionState が 5〜10 分間 1 以外の場合、ブローカーに問題があるか、断続的なネットワークの問題で ZooKeeper がブローカーに接続できない可能性があるため、注意が必要です。
- 階層型ストレージ: 階層型ストレージが有効なクラスターでは、Amazon MSK は RemoteFetchBytesPerSec、RemoteCopyBytesPerSec、RemoteLogSizeBytes などのメトリクスと関連するエラー/キューメトリクスを提供します。リモートストレージへのオフロードを追跡するメトリクスです。
- インテリジェントリバランスメトリクス: Express ブローカーを使用する MSK プロビジョンドクラスターでは、Amazon MSK はリバランス操作を監視するための 2 つの主要メトリクス (RebalanceInProgress と UnderProvisioned) を提供します。インテリジェントリバランスメトリクスの監視を参照してください。
メトリクスをカテゴリに分類することで、Amazon MSK の健全性とパフォーマンスを全体的にカバーするダッシュボードとアラートを構築できます。Amazon CloudWatch は Amazon MSK 用の自動ダッシュボードも提供しています。
CloudWatch の自動ダッシュボードへのアクセス方法を簡単に見てみましょう。AWS コンソールで CloudWatch サービスに移動します。CloudWatch コンソールで「ダッシュボード」を選択します。自動ダッシュボードタブを開き、フィルターバーで MSK を検索します。
自動ダッシュボードには主要メトリクスのビジュアライゼーションが事前設定されており、MSK クラスターの健全性とパフォーマンスを素早く把握できます。
推奨される CloudWatch アラーム
主要メトリクスにアラームを設定することで、問題を早期に検知できます。ストリーミングアプリケーションでは 1 秒が重要であり、早期検知が欠かせません。1 つのブローカーの障害が連鎖反応を引き起こし、データ取り込みの停止、上流システムのバックアップ、下流アプリケーションの障害につながる可能性があります。注文処理の遅延から収益損失へと急速にエスカレートすることもあります。適切にモニタリングすることで、ビジネスオペレーションに影響が出る前に問題を検知して修正できます。AWS のベストプラクティスと経験に基づき、以下のようなアラームを検討してください。
| メトリクス (ディメンション) | アラーム条件 | 根拠 |
| ActiveControllerCount (クラスター) | ≠ 1 (カウント) | アクティブコントローラーは 1 つだけ存在すべきです。逸脱はクラスターの不安定性を示します。 |
| CPU 使用率 (Sum(CPUUser+CPUSystem)、ブローカー単位) | > 60% (平均) が 5 分以上 | ブローカーの負荷やメンテナンスに備えた余裕を維持します。CPU が高いと処理が遅くなる可能性があります (MSK ベストプラクティスドキュメント参照)。 |
| HeapMemoryAfterGC (ブローカー) | > 60% (パーセンテージ) | Kafka ヒープが逼迫していることを示します。OOM を防ぐために早期にアラートを発報します。 |
| KafkaDataLogsDiskUsed (ブローカー) | ≥ 85% (パーセント) | ディスクがほぼ満杯であることを警告します。スケーリングやクリーンアップの時間を確保してデータ損失を防ぎます。 |
| OfflinePartitionsCount (クラスター) | > 0 (カウント) | オフラインパーティションはデータが利用不可であることを意味します。即座に調査が必要です。 |
| UnderReplicatedPartitions (ブローカー) | > 0 (カウント) | 正常な状態ではレプリカの遅延は発生しません。スパイクや持続的なラグは、過負荷や ACL の設定ミスを示す可能性があります。 |
| UnderMinIsrPartitionCount (ブローカー) | > 0 (カウント) | min.insync.replicas 設定より少ない In-Sync Replica を持つパーティション、または RF=MinISR のトピックが存在するはずです。パーティションがアンダーレプリケートされているトピックを見つけるには、以下のコマンドを使用してください:
<path-to-your-kafka-installation>/bin/kafka-topics.sh –bootstrap-server <bootstrap-server:port> —command-config client.properties –describe –under-min-isr-partitions |
| ConnectionCount (ブローカー) | 急激な低下 (例: ベースラインの 90% 未満) または高しきい値を超えるスパイク | クライアントの接続問題や接続フラッドを検知します。予期しない低下はブローカーに到達できないことを意味する場合があります。Amazon MSK Standard ブローカーのクォータを参照してください。 |
| CPUCreditBalance (T3 ブローカー向け) | < 低しきい値 (例: 10 クレジット) | バースト可能なインスタンスで、クレジットがほぼ枯渇した場合にアラートを発報し、パフォーマンス低下を防ぎます。 |
| VolumeQueueLength (ブローカー) | > 0 (持続的) または上昇傾向 | I/O オペレーションがキューイングされていることを示し、ディスクのボトルネックの可能性があります。 |
| NetworkRxErrors/TxErrors (ブローカー) | > 0 (カウント) | ネットワークエラーはパケットロスや切断を引き起こす可能性があります。 |
| IAMTooManyConnections (ブローカー) | > 0 (カウント) | IAM 接続上限 (100) を超えると、新しい接続がブロックされます。 |
| コンシューマーラグ (MaxOffsetLag または SumOffsetLag) (コンシューマーグループ/トピック単位) | > しきい値 (SLA に依存、例: 想定を超えて増加) | コンシューマーの遅延をアラートし、コンシューマーのスケーリングやバックログの調査を促します。 |
| TrafficShaping | > 0 (スロットリング発生) | ブローカーが割り当てられたネットワーク帯域幅を超過していることを示します。 |
上記は例示的なしきい値です。ワークロードと SLA に合わせて調整してください。Standard および Express ブローカーの CloudWatch メトリクスドキュメントに記載されている残りのメトリクスは、上記の主要メトリクスの異常による下流への影響を受けやすいものです。MSK フリート全体にカバレッジを拡大する前に、まず単一のテストクラスターで CloudWatch アラームを有効にしてしきい値を検証することを推奨します。
まとめ
本記事では、Amazon MSK クラスターを効果的にモニタリングするための重要な CloudWatch メトリクスとアラームについて解説しました。推奨アラームを実装すれば、Kafka ワークロードに影響が出る前に潜在的な問題を検知して対応できます。Amazon MSK のモニタリングの詳細については、Amazon MSK モニタリングベストプラクティスドキュメントを参照するか、Amazon MSK ワークショップでハンズオン体験をお試しください。
著者について
この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。