Kafkaの監視：何が重要ですか？

Kafkaのアーキテクチャと動作原理

Kafkaは分散型メッセージングシステムとして、高吞吐量、低遅延、高可用性を実現しています。メッセージは複數のノードに永続化され、オフラインおよびオンラインでの消費が可能になります。Partitionを用いて並列処理を実現し、各PartitionにはLeaderとFollowerのレプリカが存在します。Consumer GroupはConsumerとPartitionの対応関係を管理し、負荷分散を実現します。Controller Brokerはクラスタ狀態を管理し、トピックの作成・削除などの操作を擔當します。

キー構成と協調メカニズム

• ZooKeeper（舊版）とKafka自前の協調メカニズム（新版）
• ISR（In-Sync Replicas）：レプリカの同期を保証し、データロスを防ぎます。
• Rebalance：Consumer Group內のPartition再配分を行い、データの一貫性を維持します。
• Leader Election：Partitionのリーダー権を管理し、高可用性を確保します。

監視の必要性と観測の考え方

監視 vs 観測

• 監視はCPU、メモリ、トゥルース量などの限られた指標を提供しますが、複雑な障害の予測には不十分です。
• 観測はシステム內部狀態を理解し、根本原因（例：ネットワークパケットのロス、クロック同期問題）を特定します。

キー指標

• Active Controller Count（必ず1つで、Split-Brain問題を防ぎます）
• Offline Partition Count（必ず0で、Partitionの可用性を保証します）
• Under Min ISR Partition Count（ISR數が設定値未満で、書き込み中斷を引き起こします）

性能最適化とキーメトリクス

プロデューサー側（Producer）

• 核心指標：
  • Batch Size：バッチサイズがトゥルース量に影響し、バッチサイズと圧縮率のバランスが重要です。
  • Compression Rate：圧縮率が低いほど（圧縮後のデータが小さいほど）望ましいです。
  • Request Latency：リクエスト遅延を合理的な範囲（例：パーセンタイル）に制御します。
• ベストプラクティス：
  • バッチサイズと圧縮フォーマット（Snappy、GZIP、LZ4、ZSTD）を調整します。
  • 大きなバッチはGC問題を引き起こすため、特に若い世代GCを避ける必要があります。

ブローカー側（Broker）

• キーメトリクス：
  • Log Flush Latency：ログフラッシュ遅延がデータの永続性とトゥルース量に影響します。
  • Fetcher Lag：フォロワーのレプリカとリーダーのデータ遅れ（理想は0に近い）。
  • Partitionの分佈均等性：単一ノードの負荷過多を防ぎます。
• 監視視點：
  • ネットワークリクエスト/エラー率（リクエスト毎秒、エラー毎秒）
  • ディスクI/O行動（読み取り/書き込み速度）
  • メモリとCPU使用率

コンシューマー側（Consumer）

• 核心指標：
  • Consumer Lag：コンシューマーがプロデューサーのデータに遅れ（絶対値と相対値）。
  • 消費速度：プロデューサー速度と一致させる必要があります。
• 監視視點：
  • 各Partitionの消費進捗
  • コンシューマー群內の負荷均等狀態

システムリソースとネットワーク監視

• キーリソースメトリクス：
  • CPU使用率：過剰または不足（過剰は遅延、不足はリソース浪費）
  • メモリ使用率：JVMヒープと非ヒープメモリを監視
  • ディスク容量：履歴メッセージの十分な保存を確保
  • ネットワーク帯域幅：進出流量を監視し、ボトルネックを避ける
• ネットワーク遅延：
  • 同一地域または跨地域ノードの遅延差
  • ネットワークパケットロス率（データ伝送の信頼性に影響）

監視ツールと実踐

• メトリクス収集：
  • PrometheusでKafkaブローカーのGMSメトリクスを収集
  • ZooKeeperは內蔵Exporterでメトリクスを収集
• 可視化とアラート：
  • Grafanaで時系列グラフ（トゥルース量、遅延、ラグ）を描畫
  • アラート閾値を設定（例：Offline Partitionが0を超える、ISR數が設定値未満）
• ツール選択：
  • Confluent Control Center：リアルタイム監視と管理
  • Kafka Manager：クラスタ構成と狀態監視
  • Cruise Control：自動化された負荷バランスと容量計畫

結論

監視重點

• プロデューサー側：バッチサイズ、圧縮率、遅延
• ブローカー側：Partition分佈、ログフラッシュ、Fetcher Lag
• コンシューマー側：Consumer Lag、消費速度
• システムリソース：CPU、メモリ、ディスク、ネットワーク

観測の考え方

• システム內部狀態を理解し、潛在的な問題（Partitionの遅れ、ISR數不足）を予測
• 時系列データを分析し、クラスタ構成と拡張戦略を最適化

キーメトリクスと監視

• Partition分佈：各ブローカーが擔うPartition數を監視し、過負荷を防ぐ
• ネットワーク行動：各ブローカーのリクエスト/秒（RPS）とエラー率を観察し、負荷の不均等を分析
• ログフラッシュ遅延：各Partitionのログファイルがディスクにフラッシュされる遅延を監視し、データの永続性とトゥルース量に影響
• レプリカ同期狀態（Fetcher Lag）：各Partitionのフォロワーのレプリカの遅れを追跡し、理想値は0または極めて低い
• コンシューマー監視：
  • 現在のオフセット（Current Offset）とコミットされたオフセット（Committed Offset）を監視
  • 自動コミットの頻度を調整し、トゥルース量とデータの一貫性をバランス
  • コンシューマー群のオフセットと遅れの傾向を分析
• 滯後分析と時系列：
  • 絶対値と相対値の監視を組み合わせ、時間ベースのラグ（Time-based Lag）を計算
  • トピックの成長速度（Producer Rate）を比較し、今後の流量（例：大規模なキャンペーン）を予測
  • データの保持時間（TTL）と滯後との関係を分析し、データロスリスクを迴避
• ツールとアーキテクチャ：
  • Burrow：コンシューマー群のコミットオフセットを自動追跡し、視覚化分析
  • Prometheus & Grafana：メトリクスの収集と時系列データの可視化
  • ZooKeeperの健康チェック：各ブローカーが最大4,000のPartitionを擔うことを避ける
• よくある問題と解決策：
  • コンシューマーの停滯（Stall）：プロデューサー速度がコンシューマー処理能力を上回る場合、解決策はコンシューマー數の増加やサーバーの拡張
  • 異常な尖峰（Spikes）：予期せぬプロデューサーまたはコンシューマー速度の急増、解決策はPartition數の動的調整
  • テストコンシューマーの遺留問題：無効なコンシューマー群を定期的にクリーンアップ
• ベストプラクティス：
  • ブローカー、コンシューマー、ZooKeeperなどの層のメトリクスを統合し、包括的な監視ビューを構築
  • 自動化ワークフローを実裝し、コンシューマー狀態を監視し、関連チームに通知
  • データ保持ポリシーを設定し、業務ニーズに応じたTTLをバランス