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

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

概要

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

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

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

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

クラスタ容量

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

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

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

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

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

次の表に、これらの指標の Prometheus Query Language(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 クラスタがクライアント リクエストを適切に処理できなくなる可能性があります。1 つのブローカーに割り当てられるパーティションの数は、ブローカーあたりの平均パーティション数の約 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}]
  )
)

次のステップ