Metrics Index Analysis

メッセージライフサイクルから見る可観測性

本題に入る前に、RocketMQ のプロデューサー、コンシューマー、サーバー間のインタラクションプロセスを確認しておこう。

メッセージの生成と消費プロセス

RocketMQ のメッセージはパーティション分割され、キュー形式で秩序的に保存される。このキューモデルにより、プロデューサー、コンシューマー、読み書きキュー間に多対多のマッピング関係が実現され、無限に拡張できる。RabbitMQ などの従来のメッセージキューと比較して、大きな優位性がある。特にストリーミング処理シナリオでは、同じキュー内のメッセージが同じコンシューマーで処理されることが保証されるため、バッチ処理や集約処理に適している。

次に、メッセージライフサイクル全体における重要なノードを確認しよう。

メッセージライフサイクル

まずメッセージ送信がある。送信時間とは、メッセージがプロデューサーからサーバーに送信され、ディスクに保存されるまでの時間を指す。タイマーメッセージの場合は、指定されたタイミングに達しないとコンシューマーから参照できない。

サーバー側では、受信したメッセージをタイプごとに処理する必要がある。タイマーメッセージやトランザクションメッセージは、指定時刻の到来やトランザクションのコミット後に初めてコンシューマーから参照できる。RocketMQ にはメッセージ滞留機能があり、メッセージはサーバーに送信された後すぐにプルされるのではなく、クライアントの消費能力に応じて配信される。

コンシューマー側では、三つのフェーズに注目する必要がある。

- メッセージプル：プルの開始から、ネットワークとサーバーの処理を経てクライアントに到達するまでの時間。

- メッセージキューイング：処理リソースを待つ時間、つまりメッセージ到着から処理開始までの待ち時間。

- メッセージ消費：メッセージ処理の開始から、最後のコミットポイントまたは ACK 応答までの時間。

メッセージライフサイクルの各フェーズを明確に定義し観測できることが、RocketMQ の可観測性の核心理念である。本記事で紹介するメトリクスはこの概念を実装し、メッセージライフサイクルの全フェーズをカバーするモニタリングポイントを提供する。メトリクスが提供する原子機能を活用することで、ビジネスニーズに合ったモニタリングシステムを構築できる。

- 日常の巡回点検とモニタリング早期警告

- マクロトレンド分析とクラスターキャパシティ分析

- 障害診断

RocketMQ 4.x のメトリクス実装 — エクスポーター

RocketMQ チームが貢献した RocketMQ エクスポーターは、Prometheus の公式オープンソースエクスポーターエコシステムに組み込まれており、ブローカー、プロデューサー、コンシューマーの各フェーズに豊富なモニタリングメトリクスを提供している。

エクスポーターのメトリクス仕様

エクスポーターの仕組みの分析

RocketMQ エクスポーターがモニタリングメトリクスを取得するプロセスを次の図に示す。エクスポーターは MQAdminExtern を通じて RocketMQ クラスターからデータを取得する。取得したデータは Prometheus が要求する形式に変換され、/mics インターフェイスから公開される。

RocketMQ エクスポーター

RocketMQ の進化に伴い、エクスポーターモードには徐々にいくつかの欠点が露呈してきた。

- RocketMQ 5.x で新たに追加されたプロキシなどのモジュールの可観測性要件に対応できない。

- メトリクス定義がオープンソース仕様に準拠しておらず、他のオープンソースオブザーバビリティコンポーネントとの連携が困難。

- 大量の RPC 呼び出しがブローカーに追加負荷を与える。

- スケーラビリティが低い。メトリクスの追加や変更には、まずブローカーの管理インターフェイスを修正する必要がある。

これらの問題を解決するため、RocketMQ コミュニティはコミュニティ標準を採用し、OpenTelemetry ベースのメトリクスソリューションを RocketMQ 5.x で導入することを決定した。

RocketMQ 5.x のネイティブメトリクス実装

OpenTelemetry ベースのメトリクス

OpenTelemetry は CNCF のオブザーバビリティプロジェクトであり、可観測性分野の標準化ソリューションを提供することを目的としている。観測データのデータモデル、取得、処理、出力などの標準化問題を解決し、サードパーティベンダーに依存しないサービスを提供する。

新しいメトリクススキームの検討において、RocketMQ コミュニティは OpenTelemetry 仕様に準拠し、新しいメトリクスの定義を完全に再設計することを決定した。データ型は Prometheus と互換性のある Counter、Gauge、Histogram を採用し、Prometheus が推奨するメトリクス命名規則に従う。RocketMQ エクスポーターの旧メトリクスとの互換性はない。新しいメトリクスはブローカー、プロキシ、プロデューサー、コンシューマーなどの各モジュールをカバーし、メッセージライフサイクルの全フェーズにモニタリング機能を提供する。

メトリクスのレポート方法

メトリクスのレポート方法として、三つの方式を提供する。

- プルモード：K8s および Prometheus クラスターを自前で運用保守するユーザー向け。

- プッシュモード：メトリクスデータにポストプロセスを適用したい、またはクラウドベンダーのオブザーバビリティサービスを利用したいユーザー向け。

- エクスポーター互換モード：既にエクスポーターを使用しており、データセンター間（または他のネットワーク分離環境間）でメトリクスデータを転送する必要があるユーザー向け。

プル

プルモードは Prometheus との互換性を考慮して設計されている。K8s デプロイメント環境では追加コンポーネントをデプロイする必要はない。コミュニティが提供する K8s サービス検出機能（PodMonitor と ServiceMonitor CRD の作成）を利用することで、Prometheus がプル対象のブローカーとプロキシのリストを自動取得し、それらが提供するエンドポイントからメトリクスデータをプルできる。

プルモード

プッシュ

OpenTelemetry が推奨するプッシュモードでは、メトリクスデータを転送するためにコレクターをデプロイする必要がある。

プッシュモード

OpenTelemetry は公式にコレクターの実装を提供しており、メトリクスに対するユーザー定義の操作（フィルタリングやエンリッチメントなど）をサポートする。コミュニティが提供するプラグインを利用して独自のコレクターを実装することも可能である。また、AWS CloudWatch や Alibaba Cloud SLS など、クラウドベンダーが提供するオブザーバビリティサービスの多くは OpenTelemetry コミュニティに対応している。追加コンポーネントなしで、それらが提供するコレクターに直接データを送信できる。

OpenTelemetry コレクター

RocketMQ エクスポーターとの互換性

新しいメトリクスは RocketMQ エクスポーターとの互換性も提供している。エクスポーターを使用中のユーザーは、デプロイメントアーキテクチャを変更せずに新しいメトリクスにアクセスできる。さらに、コントロールプレーンアプリケーション（Prometheus など）とデータプレーンアプリケーション（RocketMQ など）は別々にデプロイされる場合があるため、エクスポーターをプロキシとして新しいメトリクスデータを取得するのは良い選択肢である。

RocketMQ コミュニティは、エクスポーターに OpenTelemetry コレクターの実装を内蔵した。ブローカーはメトリクスデータをエクスポーターにエクスポートし、エクスポーターは Prometheus 用に新しいエンドポイント（次の図の metrics v2）を提供する。

エクスポーターモード

モニタリングシステム構築のベストプラクティス

豊富なメトリクスカバレッジとコミュニティ標準への準拠により、RocketMQ のメトリクス機能を活用してビジネスニーズに合ったモニタリングシステムを容易に構築できる。本章では、次の典型的なフローに沿ったモニタリングシステム構築のベストプラクティスを主に紹介する。

クラスターモニタリングと巡回点検 → アラートトリガー → トラブルシューティングと分析

クラスター状態のモニタリングと巡回点検

メトリクスを Prometheus に収集した後、これらのメトリクスに基づいてモニタリングを設定できる。以下にいくつかの例を紹介する。

インターフェイスモニタリング：

インターフェイスの呼び出し状況をモニタリングし、異常なリクエストを素早く捕捉する。

次の図に、すべての RPC に関する関連例を示す。応答時間（平均、pt90、pt99 など）、成功率、失敗理由、インターフェイス呼び出しと戻り値の分布。

RPC メトリクス

クライアントモニタリング：

クライアントの使用状況をモニタリングし、超大規模メッセージの送信、クライアントのオンライン/オフライン、クライアントバージョン管理など、予期しないクライアントの使用状況を把握する。

次の図に、関連する例を示す。クライアント接続数、クライアント言語/バージョン分布、送信メッセージのサイズ/タイプ分布。

クライアントメトリクス

ブローカーモニタリング：

ブローカーのウォーターレベルとサービス品質をモニタリングし、クラスターの容量のボトルネックをタイムリーに発見する。

次の図に、関連する例を示す。配信遅延、メッセージ保持時間、スレッドプールキューイング、メッセージ滞留。

ブローカーメトリクス

上記の例はメトリクス活用の氷山の一角に過ぎない。ビジネスニーズに応じて、異なるメトリクスを柔軟に組み合わせ、モニタリングと巡回点検を設定する必要がある。

アラート設定

適切なモニタリングが整えば、注意が必要なメトリクスに対してアラートを設定できる。たとえば、ブローカーモニタリングの配信遅延メトリクスに対してアラートを設定する例を見てみよう。

ブローカーアラート

アラートを受信した後、モニタリングを通じて具体的な原因を確認できる。関連する送信インターフェイスの失敗率を見ると、消費送信の 1.7% が失敗していることがわかる。対応する障害は、サブスクリプショングループが未作成であることだ。

問題分析

トラブルシューティングと分析

最後に、メッセージ滞留シナリオを例に、メトリクスに基づいてオンライン問題を分析する方法を見てみよう。

メッセージライフサイクルから見る滞留問題

本記事の冒頭で述べたように、RocketMQ の問題はメッセージライフサイクルを組み合わせて総合的に分析する必要がある。サーバー側またはクライアント側のどちらか一方だけの問題だと一方的に判断すると、誤ったトラブルシューティングの方向に進む可能性がある。

滞留問題では、主にメッセージライフサイクルの二つのフェーズに注目する。

- 準備完了メッセージ：消費可能だがまだプルされていないメッセージ、つまりサーバー上に滞留しているメッセージ。

- 処理中メッセージ：クライアントがプルしたがまだ消費完了していないメッセージ。

消費ラグ

多次元メトリクス分析による滞留問題の分析

滞留問題に対して、RocketMQ は消費遅延に関連するメトリクス rocketmq_consumer_lag_latency を提供しており、このメトリクスに基づいてアラートを設定できる。アラートしきい値は、現在のビジネスの消費遅延に対する許容度に応じて柔軟に指定する必要がある。

アラート発火後、メッセージが準備完了状態と処理中状態のどちらに滞留しているかを分析する必要がある。RocketMQ が提供する rocketmq_consumer_ready_messages と rocketmq_consumer_inflight_messages の二つのメトリクスを、他の消費関連メトリクスやクライアント設定と組み合わせることで、メッセージ滞留の根本原因を特定できる。

- ケース 1：準備完了メッセージが継続的に増加し、処理中メッセージがクライアントのスタック上限に達している

これは最も一般的な滞留シナリオである。クライアントの処理中のメッセージ量（rocketmq_consumer_inflight_messages）がクライアント設定のしきい値に達している。つまり、コンシューマーの消費能力がメッセージ送信量を下回っている。ビジネスが可能な限りリアルタイムでのメッセージ消費を必要とする場合、コンシューマーの台数を増やす必要がある。ビジネスがメッセージ遅延にそれほど敏感でない場合、ビジネスピークが過ぎた後に滞留したメッセージを消化すればよい。

- ケース 2：準備完了メッセージがほぼ 0 で、処理中メッセージが継続的に増加している

このケースは RocketMQ 4.x クライアントを使用しているシナリオで多く発生する。この場合、消費オフセットは順番にコミットされる。あるメッセージの消費が停滞すると、オフセットがコミットされなくなる。クライアント側で大量のメッセージが滞留しているように見えるが、これは処理中メッセージの継続的な増加である。消費トレースと rocketmq_process_time メトリクスを組み合わせて消費が遅いメッセージを特定し、上下游のリンクを分析して根本原因を見つけ、消費ロジックを最適化する。

- ケース 3：準備完了メッセージが継続的に増加し、処理中メッセージがほぼ 0

このシナリオは、クライアントがメッセージをプルしていないことを示している。一般的に次のような状況が考えられる。

- 認証の問題：ACL 設定を確認する。クラウド製品を使用している場合は AK と SK の設定を確認する。

- コンシューマーのハング：スレッドスタックまたは GC 情報を出力して、プロセスが停止していないか判断する。

- サーバー側の応答遅延：RPC 関連メトリクスと組み合わせて、プルインターフェイスの呼び出し量と応答時間、ディスクの読み書き遅延を確認する。ディスク IOPS が飽和していないかなど、サーバー側の問題かどうかを検証する。