Kafka Consumer Lag の監視：遅延検知と対策（CCDAK / CCAAK 対応）

Consumer Lag は「各パーティションで最新の末尾オフセットとコンシューマの位置（またはコミット済み位置）の差」です。定義の取り違えが監視の誤検知や取りこぼしにつながります。

本稿では、ラグの算出式と主要メトリクス、実運用のアラート設計、ツール比較、遅延の主因と対策、そして CCDAK/CCAAK の出題で問われやすい要点を一気に押さえます。

Consumer Lag の定義と読み解き方

Consumer Lag は、パーティションの End Offset（最新の書き込み位置）とコンシューマの位置の差です。実務では「コミット済みオフセットとの差」を採用するツール（kafka-consumer-groups.sh や多くのエクスポーター）と、「フェッチ済みの現在位置との差」を採用するクライアントメトリクス（records-lag 系）があります。どちらも正しいが、アラートの意味合いが異なるため、基準を統一して監視設計することが重要です。

Kafka のコンシューマグループは、各パーティションに対して最後に処理した位置を __consumer_offsets という内部トピックにコミットします。ラグはパーティション単位で計算され、グループ全体のラグは単純合算（サム）で評価するのが基本です。

• Partition Lag（件数）= EndOffset − ConsumerPosition（または CommittedOffset）
• Group Total Lag = Σ Partition Lag
• Backlog Seconds（推定遅延時間）= Lag ÷ コンシューマの処理レート（records/sec）

Consumer Lag の概念図（1トピック2パーティション例）

算出式と主要メトリクス（JMX/CLI の読み方）

kafka-consumer-groups.sh の LAG 列は、通常 EndOffset − CommittedOffset の差です。これは「どこまで処理を確定させたか」を示すため、運用アラートの基準にしやすい値です。一方、クライアント JMX の records-lag 系はフェッチ・処理中の“現在位置”基準で、短期の詰まり検知に有効です。

代表的メトリクスは以下です。JMX 名称は安定的に利用されますが、監視基盤側のエクスポート名はツールごとに差異があるため、拾い先のドキュメントで最終確認してください。

• kafka-consumer-groups.sh --describe の LAG（Committed 基準）
• JMX: kafka.consumer:type=consumer-fetch-manager-metrics,client-id=..., metric=records-lag-max / records-lag-avg
• JMX: kafka.consumer:type=consumer-fetch-manager-metrics,client-id=..., metric=records-consumed-rate / bytes-consumed-rate
• JMX: fetch-latency-avg / fetch-rate などはスループット低下の兆候把握に有効

現場で使う確認コマンドと Prometheus アラート例

# 1) グループごとのラグ確認（Committed 基準）
$ kafka-consumer-groups.sh \
  --bootstrap-server broker1:9092 \
  --group orders-app \
  --describe

# 2) 特定グループのラグが5分間1万件超で通知（Prometheus 例）
#   ※ メトリクス名はエクスポーター実装により異なります（例: Kafka Lag Exporter）。
ALERT KafkaConsumerLagHigh
  expr: max_over_time(kafka_consumergroup_group_lag{group="orders-app"}[5m]) > 10000
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Kafka consumer lag high (orders-app)"
    description: "Lag > 10k for 5m. Investigate consumer throughput, rebalancing, or downstream slowness."

アラート設計としきい値（遅延を過不足なく検知）

固定しきい値だけでは、ピーク時の一時的増加と本質的な詰まりを区別しづらいので、“量”と“持続時間”を組み合わせます。さらに Backlog Seconds を併用すると、ビジネス影響（どれだけ遅れているか）に直結するアラートが作れます。

また、コンシューマの取り込みレートがゼロ近傍で records-lag-max が増え続ける組み合わせは、処理ループ停止やリバランス多発の典型パターンです。アラートは単一指標の絶対値だけでなく、レートや傾きの組で設計します。

• 量×時間: Group Total Lag > X 件が Y 分以上継続
• Backlog Seconds: (ΣLag) ÷ max(1, Σ処理レート) > S 秒
• 傾向検知: records-lag-max 上昇 かつ records-consumed-rate 低下（または 0）
• コミット遅延検知: 最終コミット時刻が max.poll.interval.ms を越えて古い
• 夜間バッチなど既知ピークはスケジュールに応じてしきい値を切替

監視ツール比較（導入のしやすさと検知精度）

ツールによりラグの“基準”（Committed vs 現在位置）と評価ロジックが異なります。運用要件（SLA 準拠か、傾向監視か、ダッシュボード重視か）で選択してください。

Confluent Control Center はプラットフォーム統合で可視化・アラートが容易。Burrow はコミットの傾きで状態（OK/WARN/ERROR）を判定し、偽陽性を抑制します。軽量に始めるなら CLI とエクスポーターによる Prometheus/Alertmanager 連携が扱いやすいです。

• 本番では「早期検知のリアルタイム系（records-lag-max）」と「確定処理遅延のコミット系（LAG）」を併用
• 人手オペは CLI、継続監視はエクスポーター/Control Center、傾向評価は Burrow

遅延の主因と具体的対策

ラグは「生産＞消費」の時間帯が続くと累積します。処理スループット不足、リバランス多発、エラー再試行地獄、外部依存（DB/HTTP）の待ちが主因です。設定調整だけでなく、処理設計（バッチ化・非同期化・DLQ）まで含めて対策します。

スケールアウトは万能ではありません。コンシューマ数はパーティション数を超えても並列度は増えません。スループットのボトルネックが下流 I/O の場合、単純な並列化は効果が薄く、キューイングやキャッシュ、バルク API 化が有効です。

• コンシューマ調整: max.poll.records を増やしてバッチ処理効率化、fetch.min.bytes/fetch.max.wait.ms で取り込みバッチ最適化
• 処理時間が max.poll.interval.ms を超えるなら、値を引き上げるか、pause/resume で明示的制御
• リバランス対策: session.timeout.ms/heartbeat.interval.ms の適正化、協調的リバランスを採用（対応クライアント）
• パーティション設計: 消費の並列度はパーティション数まで。不足時は計画的に増分（キー分布の偏りに注意）
• エラー分離: リトライ回数・待機時間の上限を定め、DLQ に退避してメインフローを止めない
• プロデューサ側: linger.ms/batch.size でバッチ効率を高めつつ、過剰な突発流量を平準化

運用の落とし穴と試験対策ポイント（CCDAK / CCAAK）

試験では、ラグの定義、コミットと現在位置の違い、スケールの限界（パーティション数制約）、オフセット管理、リバランス関連設定が頻出です。CLI の出力解釈問題や、実装に応じた設定の優先度判断も問われます。

エンドツーエンド遅延（生成から処理完了までの時間）はラグと同義ではありません。ラグが小さくても、処理内部の待ちや外部 I/O で実時間遅延が大きいケースがあります。

• オフセットは __consumer_offsets 内部トピックに保存（コンパクション）。CLI の LAG は Committed 基準が基本
• 並列度はパーティション数まで。コンシューマ N > パーティション M のとき、同時処理は M 本
• enable.auto.commit を無効にした場合、コミット頻度が低いと LAG は大きく見えやすい
• max.poll.interval.ms を超えるとリバランスが発生し、ラグ悪化の連鎖に。処理時間との整合を取る
• read_committed は可視化遅延を増やし得るが、ラグ算出式そのものは不変

問題で確認

よくある質問