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

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

概要

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

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

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

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

クラスタ容量

クラスタの過負荷を回避するには、次のシグナルをモニタリングします。推奨範囲から外れた状態が長時間続く場合は、通知する アラートを作成します。

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

  • ブローカーのディスク使用率: ブローカーのディスク使用率が 80% 未満であることを確認します。

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

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

次の表に、カスタム Cloud Monitoring ダッシュボードに追加できるこれらの指標のPrometheus Query Language（PromQL）クエリ を示します。

シグナル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}]
  )
)

次のステップ