データ書き込み遅延の対処方法
概要¶
本ドキュメントでは、データ書き込みレイテンシが大きい問題を対象に、トラブルシューティングの考え方を整理します。
インフラストラクチャ設定の確認¶
1 時刻の確認¶
Guance関連サービス のマシン時刻が正常であることを確認します。遅延がある場合は、マシンのタイムゾーンと時刻を調整します。
2 データノード設定の確認¶
ストレージエンジンのデータノード 設定が、実際のリソース状況に応じて変更されているか確認します。
1）データノードのマシン構成を確認します
2）ストレージエンジンの関連設定が、デプロイ時に変更されたか確認します。
3）変更されていない場合は、以下の設定ガイドに従って変更します。
上記の確認でリソース状況が 8c32g の場合を想定します。
# 一般的にはlimitsの半分に設定
## リソースが十分に大きい場合、最大32gに設定します。超過分はリソースの無駄になります。
- name: OPENSEARCH_JAVA_OPTS
value: -Xmx14g -Xms14g
# limitsは余裕を持たせ、他のプログラムやシステムにCPUとメモリの余力を残す必要があります
REsources:
limits:
cpu: "7"
memory: 28Gi
requests:
cpu: "7"
memory: 7Gi
業務ロジックによるトラブルシューティング¶
以下はトラブルシューティングのロジックを示すマインドマップです。この図に従って、調査の順序を決定します。
1 kodo-x サービスの再起動頻度を確認¶
2 Redis ミドルウェアの確認¶
Redis のパフォーマンスがボトルネックになっていないか確認します。CPU またはメモリの使用率が高い場合は、垂直スケーリングを実施します。
3 topic に基づいてストレージエンジンの種類を判断¶
1）middleware Namespace の nsqadmin サービスの service 設定を NodePort に変更します。
ブラウザで、node_IP + ポート形式でアクセスします。
2）topic 名に基づいて、ストレージエンジンの種類を特定します
df_metric_xxx で始まるものは時系列エンジン、それ以外の topic はすべてログエンジンのデータです。
3）データノードのパフォーマンスを確認
リソース消費が大きすぎる場合は、エンジン異常対応 の内容を参照してください。
4）対応するサービスのデータを確認
| フィールド名 | フィールド説明 |
|---|---|
| Topic | メッセージキューの名前 |
| Depth | 現在のトピックのメッセージキュー内の未処理メッセージ数 |
| In-Flight | 現在コンシューマーが取得したが、処理完了を確認していないメッセージ数 |
| Deferred | 再エンキューされた、または明示的に遅延配信するために配信されていないメッセージ数 |
| Connections | 現在の最大同時消費接続数 |
4 エンジン異常対応¶
4.1 単一ノードの負荷が高い場合¶
Guanceのすべてのインデックス設定はデフォルトで1シャードです。つまり、1つのデータノードのみが処理を行うため、ここでパフォーマンスのボトルネックが発生します。そのため、管理画面にログインし、インデックスのシャード数を調整して、データノードの並列処理能力を向上させる必要があります。
このとき、nsq 管理ページを頻繁にリフレッシュし、Channel の Depth の滞留数が大幅に減少していることを確認できれば、対応は成功です。
4.2 クラスター全体の負荷が高い場合¶
クラスター全体の負荷が高い場合は、水平スケーリングまたは垂直スケーリングを検討します。
ログエンジンの容量計画 を参照してください。
5 消費能力不足による kodo-x サービスのスケーリング¶
上記の方法でもデータ滞留の問題が解決しない場合、nsq 管理画面の Channel の connections 数が少なすぎて、大量のデータリクエストを処理しきれていない可能性があります。この場合は、kodo-x サービスの数をスケーリングします。
マシンリソースが十分な場合、通常は2倍ずつスケーリングします。上記の nsq 管理ページの Depth 滞留が明らかに減少するまで続けます。