信頼性を確保するために Kafka クラスタをモニタリングする

このドキュメントでは、Managed Service for Apache Kafka クラスタをモニタリングして、Kafka ワークロードの信頼性を確保する方法について説明します。

概要

信頼性とは、システムが時間の経過とともに正しく一貫して動作する能力です。Kafka ベースのワークロードの場合、信頼性とは、Kafka クラスタ自体だけでなく、メッセージを生成および消費するクライアントアプリケーションの両方を含みます。

Managed Service for Apache Kafka は、多くの一般的な障害に耐え、そこから復旧できるように設計されています。たとえば、サービスはフォールト トレランスのためにレプリカを異なるゾーンに配置し、障害が発生したブローカーを自動的に再起動します。ただし、信頼性に影響する他の要因は、サービスの直接的な制御の範囲外です。

  • クライアントの構成
  • クラスタの負荷（平均負荷やスパイクなど）
  • パーティションとレプリカの数
  • トピック設定、例: メッセージ保持

信頼性の高いオペレーションを実現するには、クラスタのこれらのオペレーション パラメータをモニタリングし、推奨範囲内に維持することが重要です。以降のセクションでは、信頼性にとって重要な主要な指標について説明します。

クラスタ容量をモニタリングする

クラスターの過負荷を避けるため、以下のシグナルを監視してください。推奨範囲から長期間外れた場合に通知するアラートを作成します。

  • CPU 使用率。すべてのブローカーで CPU 使用率を 80% 未満に保つようにしてください。

  • ブローカーのディスク使用率: ブローカーのディスク使用率が 80% を超えないようにします。

  • ディスクサイズ。安全策として、ブローカーごとにパーティションごとに少なくとも2*(segment.bytes)を用意することをお勧めします。実際には、必要なディスク容量は多くの場合、これよりもかなり少なくて済む。

    デフォルトでは、セグメント ファイルは 7 日後に閉じられ、リモート ストレージに移動されます。ほとんどのパーティションがこの期間に segment.bytes 未満のデータを受信するのが一般的です。つまり、ほとんどのパーティションが segment.bytes 未満のディスク容量を使用します。ディスクサイズを増やす前に、クラスタにパーティションを追加しながらディスク使用率をモニタリングします。

  • パーティション数。ブローカーあたりのパーティション数を 4,000 未満、クラスタあたりのパーティション数を 100,000 未満に維持するようにしてください。

クラスタの容量が不足している場合は、次の軽減策を検討してください。

以下の表は、Prometheus クエリ言語（PromQL）のクエリを示しています。これらのメトリクスをカスタムのCloud Monitoring ダッシュボードに追加できます。

シグナルPromQL クエリ
CPU 使用率 
rate(
  {
    "managedkafka.googleapis.com/cpu/core_usage_time",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/cpu/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
ブローカーのディスク使用率 
max_over_time(
  {
    "managedkafka.googleapis.com/disk/used_bytes",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
パーティションあたりのセグメント サイズ 
# Assumes that segment files are 225 MiB. Check your cluster configuration.
2*225*(1024*1024) * max_over_time(
  {
    "managedkafka.googleapis.com/partitions",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
ブローカーあたりのパーティション数 
max by (resource_container, location, cluster_id, broker_index) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
クラスターごとのパーティション数 
max by (resource_container, location, cluster_id) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)

ブローカー間のパーティションバランスを監視する

負荷が不均一になると、Kafka クラスタがクライアント リクエストを適切に処理できなくなる可能性があります。単一のブローカーに割り当てられるパーティションの数は、ブローカーあたりの平均パーティション数の約 10% 以内に収まるようにする必要があります。この指標における外れ値を探してください。

パーティションのバランスを維持するには、クラスタでスケールアップ時の自動再調整を有効にすることを検討してください。

次の表に、パーティションの不均衡をモニタリングするために使用できる PromQL クエリを示します。

シグナルPromQL クエリ
ブローカーごとのパーティション数 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
分割の不均衡 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
/ on (resource_container, location, cluster_id)
  group_left avg by (resource_container, location, cluster_id) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
) - 1

パーティション レプリケーションをモニタリングする

データ レプリケーションは、ワークロードのフォールト トレランスを確保するために不可欠です。正常なクラスタでは、トピック内のすべてのパーティションに、トピックの構成されたレプリケーション係数に基づく完全な数のレプリカがあります。

パーティションレプリケーションを監視するには、以下のシグナルを使用します。

  • 同期レプリカ（ISR）が最小数を下回っている。パーティションの同期済み ISR の数が構成された最小値（min.insync.replicas）よりも少ない場合、データ損失と可用性の重大なリスクがあります。通常、この状況は、1 つ以上のブローカーの容量不足またはインフラストラクチャの障害が原因で発生します。

  • 複製不足のパーティション。同期されたレプリカの数がレプリケーション係数を下回ると、パーティションのレプリケーション不足となります。パーティションのレプリケーションが数十秒間不足した状態が続く場合、ブローカー、ストレージ容量、またはその他の何らかの問題が発生している可能性があります。

    ローリング再起動中、ブローカーは再起動されるため使用できなくなり、一時的にレプリケーション不足が発生します。この状況は想定内のことであり、介入は不要です。

以下の表は、レプリケーションを監視するために使用できる PromQL クエリを示しています。

シグナルPromQL クエリ
最小 ISR を下回る 
max by (
  resource_container,
  location,
  cluster_id
) (
  max_over_time(
    {
      "managedkafka.googleapis.com/broker/under_min_isr_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
レプリケーション中 
max by (
  resource_container,
  location,
  cluster_id
) (
  min_over_time(
    {
      "managedkafka.googleapis.com/broker/under_replicated_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[10m:${__interval}]
  )
)

次のステップ