メッセージの蓄積は、コンシューマーグループのコミット済みオフセットが、ブローカーで生成された最新のオフセット (ハイウォーターマーク) より遅れている場合に発生します。この 2 つのオフセット間の差分が、蓄積されたメッセージ数です。蓄積数の増加が必ずしも問題を示すわけではありません。重要なのは、消費が生成のペースに追いついているかどうかです。このガイドでは、蓄積が正常かどうかを診断し、異常なケースを解決する方法について説明します。
メッセージ消費の仕組み
蓄積を診断する前に、各クライアントにおける 2 段階の消費サイクルを理解してください。
プル：クライアントがブローカーからメッセージを取得します。
処理：クライアントが各メッセージに対してビジネスロジックを実行し、その後コンシューマーオフセットをブローカーにコミットします。
蓄積されたメッセージ数は、ブローカーのハイウォーターマークからコンシューマーグループのコミット済みオフセットを引いた値です。大きな数値だけでは問題を示しません。傾向に注目してください。差が安定しているか、増加しているか、またはコミットされていないオフセットによって引き起こされているかを確認してください。
蓄積の診断
蓄積が正常かどうかを確認するには、ApsaraMQ for Kafka コンソールでコンシューマーグループのメトリクスを確認します。
ApsaraMQ for Kafka コンソールにログインします。
上部のメニューバーで、インスタンスが配置されているリージョンを選択します。
左側のナビゲーションペインで、[インスタンス] をクリックします。
[インスタンス] ページで、対象のインスタンス名をクリックします。
[インスタンス詳細] ページの左側のナビゲーションペインで、[グループ] をクリックします。
[グループ] ページで、対象のグループを探し、[操作] 列の [その他] > [コンシューマーステータス] を選択します。
[コンシューマーのステータス] ページで、[最終消費時刻]、[堆積メッセージ]、および [コンシューマーオフセット] の値を確認します。
これらの値は 1 分間隔で更新されます。[詳細] をクリックすると、各パーティションのコンシューマーオフセットを表示できます。
次の判断表を使用してメトリクスを解釈してください。
| 症状 | 診断 | 対処方法 |
|---|---|---|
| [Last Consumed At] が現在時刻に近く、[Accumulated Messages] が安定した範囲内で変動している | 正常です。クライアントは安定したペースでメッセージをプルして処理しています。 | 対処は不要です。 |
| [Accumulated Messages] が増加し続け、[Consumer Offset] が変化しない | 異常です。コンシューマースレッドがブロックされています。クライアントがメッセージの処理とオフセットのコミットを停止しています。 | 「異常な蓄積の解決」をご参照ください。 |
| [Accumulated Messages] が増加し続けているが、[Consumer Offset] は進んでいる | 異常です。消費が遅すぎます。クライアントはメッセージを処理していますが、処理速度が生成速度より低くなっています。ボトルネックはプルフェーズではなく、処理フェーズ (フェーズ 2) にあります。 | 「異常な蓄積の解決」をご参照ください。 |
| パーティションにメッセージが蓄積されているように見えるが、ダウンストリームの処理は正常 | 誤検出の可能性があります。ダウンストリームシステムが assign 消費モードを使用している場合、オフセットは手動で管理されます。メッセージはすでに消費されている可能性がありますが、オフセットがコミットされていないため、蓄積として表示されます。 | オフセットを手動でコミットして、報告された蓄積をクリアしてください。 |
| [Accumulated Messages] が増加し、[Consumer Offset] がゆっくり進んでいるが、インスタンスレベルのコンシューマー帯域幅モニタリングでスループットがレート制限に達していることが示されている | コンシューマーのレート制限の可能性があります。インスタンスがコンシューマースループットのスロットリングをトリガーしています。クライアントは完全にブロックされているわけではなく、メッセージをプルできますが、制限された速度でプルするため、徐々に蓄積が発生します。 | インスタンスレベルのモニタリングのメトリクスでコンシューマー帯域幅を確認してください。スロットリングが確認された場合は、インスタンスの仕様のアップグレード、またはコンシューマーのプル量の削減を検討してください。 |
| 1 つのトピックで [Accumulated Messages] が大幅に増加し、同じインスタンス内の他のトピックの消費が遅くなる | コールドリードによる間接的な影響の可能性があります。通常、1 つのトピックの蓄積が同じインスタンス内の他のトピックに直接影響を与えることはありません。ただし、蓄積されたメッセージがディスクにフラッシュされている場合、取得時にメモリからの読み取り (ホットリード) ではなくディスク I/O (コールドリード) がトリガーされます。ディスクの読み取り IOPS またはスループットが高いと、インスタンス全体のパフォーマンスが低下する可能性があります。 | インスタンスレベルのディスク I/O およびネットワークスループットのモニタリングのメトリクスを確認してください。ディスクの読み取り IOPS またはトラフィックが異常に高い場合は、まず影響を受けているトピックの蓄積を減らすことを優先してください。 |
[Accumulated Messages] の値が大きいことが、必ずしも問題を意味するわけではありません。表示される数は、生成速度とオフセットのコミット頻度によって異なります。たとえば、トピックが 1 秒あたり 10,000 メッセージを受信し、オフセットが 1 秒に 1 回コミットされる場合、蓄積数は通常 10,000 前後で変動します。
異常な蓄積の解決
異常な蓄積を確認した後、ボトルネックを特定し、消費速度を向上させます。
ボトルネックの特定
コンシューマースレッドがブロックされているか、単に遅いかを判断します。
ブロックされたスレッド：[Consumer Offset] が進んでいない場合、コンシューマースレッドがスタックしている可能性があります。
jstack(Java アプリケーションの場合) を使用してスレッドダンプをキャプチャし、ブロックポイントを特定してください。詳細については、「jstack - Stack Trace」をご参照ください。処理が遅い：[Consumer Offset] が進んでいるものの生成ペースに追いついていない場合は、アプリケーション内のメッセージ処理ロジックをプロファイリングしてください。処理フェーズで低速な I/O 呼び出し、データベース書き込み、またはブロッキング操作を探してください。
消費速度の向上
次のいずれかまたは両方のアプローチを使用してください。
コンシューマーの追加：同じコンシューマーグループ内に、既存のプロセス内の追加スレッドとして、または別のプロセスとして、コンシューマーインスタンスをさらに追加します。各コンシューマーは 1 つ以上のパーティションを処理します。コンシューマー数がすでにパーティション数と等しいか、それを超えている場合、コンシューマーを追加しても効果はありません。余分なコンシューマーはアイドル状態のままです。
消費スレッドの増加：各コンシューマーインスタンス内でマルチスレッド消費を使用します。実装の詳細については、「コンシューマーのベストプラクティス」の「消費速度の向上」セクションを参照してください。
ほとんどの場合、異常なメッセージの蓄積は、メッセージ消費が遅いか、消費スレッドがブロックされていることが原因です。消費ロジック内の関連パラメータに長い期間を設定しないでください。
リバランスの確認
メッセージが蓄積され、コンソールでコンシューマーステータスが異常と表示される場合、コンシューマーグループがリバランス中である可能性があります。リバランス中は、メッセージは消費されません。
頻繁なリバランスは、通常、コンシューマーが高い頻度で接続および切断することが原因です。詳細については、「コンシューマークライアントでリバランスが頻繁に発生するのはなぜですか?」をご参照ください。
read tcp i/o timeout エラーのトラブルシューティング
Q: ApsaraMQ for Kafka インスタンスの垂直スケーリングによって、メッセージの蓄積を引き起こす read tcp i/o timeout エラーを解決できますか?
A: 垂直スケーリングでは、通常 read tcp i/o timeout エラーを直接解決できません。このエラーは、サーバー側のリソース制約よりも、ネットワーク接続またはクライアント設定の問題に関連していることが多いです。スケールアップを検討する前に、次のトラブルシューティング手順に従ってください。
クライアントとブローカー間のネットワーク接続が安定していることを確認してください。パケットロス、高レイテンシー、または断続的な接続の問題がないかを確認してください。
クライアントのバージョンを確認してください。クライアントのバージョンが 0.10.2 より前の場合は、サポートされているバージョンにアップグレードしてください。
max.poll.interval.msおよびsession.timeout.msパラメータを調整してください。これらの値が各ポーリングバッチの処理に必要な時間に対して短すぎる場合、クライアントがタイムアウトして意図しないリバランスがトリガーされ、消費が中断されて蓄積が増加する可能性があります。これらの値を、実際のメッセージ処理時間に見合った期間に設定してください。ApsaraMQ for Kafka コンソールで、[コンシューマーのステータス] ページをチェックし、蓄積数とオフセットの変更が想定どおりであるかを確認します。サーバー側のリソースのボトルネックがタイムアウトの原因であることが確認された場合にのみ、スケールアップを検討してください。