信頼性を確保するために 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 未満に維持するようにしてください。

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

次の表に、カスタムの 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 クラスタがクライアント リクエストを適切に処理できないことがあります。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 つ以上のブローカーの容量不足、またはインフラストラクチャの障害によって発生します。

  • レプリケーションが不十分なパーティション。同期中のレプリカの数がレプリケーション係数を下回ると、パーティションのレプリケーションが不足します。パーティションが 10 分間アンダーレプリケートされたままになっている場合は、ブローカー、ストレージ容量、またはその他の問題が発生している可能性があります。

    ローリング再起動中、ブローカーは再起動されると使用できなくなり、一時的にレプリケーションが不十分になります。この状況は想定内であり、対応は必要ありません。

次の表に、レプリケーションのモニタリングに使用できる 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}]
  )
)

認可リクエストの割り当てをモニタリングする

クライアントがクラスタに接続すると、接続の承認は、プロジェクトごと、リージョンごとの 1 分あたりのクラスタ認証接続リクエスト数の割り当てにカウントされます。プロジェクトとリージョン内のすべてのクラスタがこの割り当てを共有します。割り当てを超えると、新しいクライアント接続がブロックされます。割り当て使用率を 80% 未満に保つようにしてください。使用率が高いままの場合は、アラートを作成して通知を受け取るようにしてください。

割り当ての使用率が高い場合は、次の緩和策を検討してください。

  • クライアントが不要な新しい接続を作成する頻度を減らします。たとえば、プロデュース エラーとコンシューム エラーで指数バックオフを使用するようにクライアントを構成し、必要に応じてクライアント インスタンスを統合して、既存の接続を再利用します。

  • 割り当ての増加をリクエストします。詳細については、割り当てと上限をご覧ください。

次の表に、プロジェクトとリージョン別に上位 3 つの認可リクエストの割り当て使用率をモニタリングするために使用できる PromQL クエリを示します。

シグナルPromQL クエリ
プロジェクトとリージョン別の承認リクエスト割り当て使用率の上位 3 件 
topk(3,
  sum by (project_id, location) (
    rate(
      {
        "serviceruntime.googleapis.com/quota/rate/net_usage",
        monitored_resource="consumer_quota",
        service="managedkafka.googleapis.com",
        quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests"
      }[${__interval}]
    )
  )
  / (
    min by (project_id, location) (
      min_over_time(
        {
          "serviceruntime.googleapis.com/quota/limit",
          monitored_resource="consumer_quota",
          service="managedkafka.googleapis.com",
          quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests",
          limit_name="ClusterAuthPerMinutePerProjectPerRegion"
        }[${__interval}]
      )
    )
    / 60
  )
)

次のステップ

Apache Kafka® は、Apache Software Foundation または米国その他の諸国における関連会社の商標です。