Lindorm:モニタリングとアラート

CPU と負荷

このモジュールは、CPU 使用率、CPU WIO 使用率、CPU アイドル率、平均負荷などのメトリックを含む、システムの CPU 使用率と負荷を監視します。CPU 使用率には、[CPU 使用率 ユーザー]（%）と[CPU 使用率 システム]（%）が含まれます。

アラートルールを構成する場合は、ビジネスの特性とレイテンシへの感度に基づいて、[CPU アイドル率 (%)] のアラートしきい値を設定することをお勧めします。一般に、CPU 使用率の増加は応答時間（RT）の増加につながりますが、その影響はビジネスの種類によって異なります。たとえば、CPU 使用率が 40% を超えると、オンラインビジネスではレイテンシが発生する可能性がありますが、オフラインビジネスでは CPU 使用率が 100% でも影響を受けない場合があります。そのため、ビジネスの状況に基づいてアラートしきい値を設定することをお勧めします。CPU 使用率が高すぎる場合は、インスタンスをスケールアップまたはスペックアップしてビジネスの需要に対応できます。インスタンスをスケールアップまたはスペックアップする方法の詳細については、「インスタンスストレージの管理」および「インスタンスの構成の変更」をご参照ください。

[CPU WIO 使用率 (%)] は、CPU が I/O 操作の待機に費やす時間の割合を示します。値が高い場合は、ディスクの読み取り/書き込み操作にボトルネックがあることを示します。マシンの正常性状態を評価するには、[CPU WIO 使用率 (%)] を[1 分あたりの平均負荷 (load1)]（以下、負荷メトリック）とともに分析できます。負荷メトリックは、CPU 使用率とディスク使用率の両方を反映します。

許容される負荷は、通常、CPU 構成によって異なります。たとえば、マシンに 8 つの CPU コアがある場合、負荷値が 8 を超えると、CPU 処理タスクがキューに入れ始め、マシンが最適ではない状態にあることを示します。CPU 使用率が低いのに負荷値が高い場合は、ディスク使用率が高すぎることを示します。CPU 負荷または WIO 使用率が高すぎる場合は、ビジネスへの影響を避けるために、インスタンスをスケールアップまたはスペックアップすることをお勧めします。

ネットワークとディスク

このモジュールは、マシンのネットワークとディスクのパフォーマンスを監視します。ネットワークトラフィック、ディスクの読み取り/書き込み操作、IOPS などの主要なメトリックに注意し、これらのメトリックの値が Elastic Compute Service (ECS) インスタンスとクラウドディスクの速度制限しきい値を下回っていることを確認する必要があります。

ECS インスタンスの種類によって、ネットワーク帯域幅が異なります。ネットワークの速度制限しきい値については、「インスタンスファミリの概要」をご参照ください。ディスクの速度制限しきい値については、「ブロックストレージのパフォーマンス」をご参照ください。ネットワークとディスクの制限についてご質問がある場合は、Lindorm テクニカルサポート（DingTalk ID: s0s3eg3）までお問い合わせください。

ローカル以外の ECS ディスクには、合計帯域幅に制限があります。読み取りトラフィックと書き込みトラフィックの合計が ECS ディスクの帯域幅制限を超えると、速度制限が発生し、ビジネス運用に影響を与える可能性があります。使用中は、基盤となるマシンのネットワークとディスクの制限を超えないように、ディスクとネットワークの使用状況を綿密に監視する必要があります。

クラスタ負荷

このモジュールには、次のメトリックが含まれています。

• [LindormTable 計算ノード メモリ使用率 (%)]: LindormTable によって現在使用されているヒープメモリの比率。ヒープ使用率が長時間高いままであると、LindormTable で Out of Memory (OOM) またはフルガベージコレクション (GC) が発生し、ビジネス運用に影響を与える可能性があります。ヒープメモリサイズは変動します。ヒープメモリを一時的に使いすぎると、システムは GC などの方法でヒープサイズを自然に削減します。ヒープメモリサイズが特定のしきい値を継続的に超える場合は、注意が必要です。この場合、LindormTable ノードの仕様をスペックアップしてメモリを増やすことをお勧めします。アラートルールを作成する場合は、この比率が 85% から 90% の間の値を超え、30 分から 60 分間続いた場合にアラート条件が満たされるように指定することをお勧めします。仕様をスペックアップする方法の詳細については、「インスタンスのエンジン仕様の変更」をご参照ください。

• [RS のリージョン数 (ユニット)]: 各 LindormTable ノードのデータシャード (リージョン) の数。LindormTable は、範囲ごとにテーブルをシャードに分割し、マスターノードによって管理される集中割り当てを使用して、シャードをマシンに分散します。各シャードはメタデータメモリ空間を占有するため、シャード数が多すぎると、マシンのメモリが不足する可能性があります。たとえば、テーブルの数を減らすか、テーブルを作成するときに事前パーティションの数を減らすことによって、シャードの数を制御する必要があります。

  次の表に、さまざまな構成で推奨されるマシンあたりのシャード数を示します。

  マシン構成 (メモリサイズ)	推奨されるマシンあたりのシャード数
  8 GB	500 未満
  16 GB	1000 未満
  32 GB	2000 未満
  64 GB	3000 未満
  128 GB	5000 未満

  上記の値は参考値です。実際に使用する場合は、LindormTable 計算ノードの使用済みメモリ / LindormTable 計算ノードの合計メモリ という式に基づいて、インスタンスのメモリが不足しているかどうかを判断できます。

• [HandlerQueue の長さ (ユニット)]: サーバー上のリクエストのキューイング状況。HandlerQueue の長さが 0 より大きい場合、リクエストはサーバーでキューイングする必要があり、サーバーリソースが現在のリクエストをタイムリーに処理するのに不十分であることを示します。インスタンス構成をスペックアップして CPU リソースを増やすことをお勧めします。

• [圧縮キューの長さ (ユニット)]: サーバー上の圧縮タスクのキューイング状況。書き込み操作が増加すると、実行する必要のある圧縮操作が増え、キューイングシナリオが発生する可能性があります。

  説明

  • [圧縮キューの長さ] の値が 0 より大きいだけでは、インスタンスが異常な状態にあることを示すことはできません。ビジネスに明確な定期的な書き込みパターン（たとえば、日中のピークと夜間のトラフ）がある場合、日中の書き込みピーク時に圧縮タスクが累積し、[圧縮キューの長さ] の値が 0 を超える可能性があります。ただし、システムは、[圧縮キューの長さ] の値が 0 に減少する夜間に、これらの累積されたタスクを自動的に処理します。この場合、インスタンスは正常です。さらに、圧縮キューの長さが特定の値で長時間安定している場合は、インスタンスが安定した状態にあり、注意を払う必要がないことを示します。

  • [圧縮キューの長さ] の値が下降傾向なく上昇し続ける場合は、インスタンスリソースが不十分であることを示します。システムが圧縮タスクをタイムリーに処理できるように、ノードを追加するか構成をスペックアップして CPU リソースを増やす必要があります。圧縮タスクの短期間の累積はビジネスに影響しませんが、長期間の累積はシャード内のファイル数が過剰になり、読み取り RT が増加する可能性があります。ファイル数が増加し続けると、書き込みバックプレッシャーが発生し、書き込み RT の増加やタイムアウトが発生する可能性があります。

• [リージョン内のファイルの平均数]: シャード内のファイルの平均数。値が高いほど、読み取り RT が増加します。ファイルメタデータはメモリ空間を占有し、ファイル数が多すぎると、フル GC または OOM が発生する可能性があります。

• [リージョン内のファイルの最大数]: 単一シャード内のファイルの最大数。この制限を超えると、書き込みバックプレッシャーが発生し、書き込みタイムアウトが発生します。詳細については、「データリクエストの制限」をご参照ください。

読み取りリクエスト

このモジュールには、次のメトリックが含まれています。

• Get 操作メトリック: [Get リクエスト (個/秒)]、[Get 平均 RT (ミリ秒)]、[Get P99 RT (ミリ秒)]。ポイントクエリ呼び出しは、完全なプライマリキー情報を使用して Lindorm サーバーで実行され、QPS、平均 RT、P99 RT などの関連する監視メトリックを取得します。BatchGet 操作を使用する場合、BatchGet 操作に含まれる行数に関係なく、BatchGet 操作は単一サーバーで順番に実行されるため、1 つのポイントクエリ呼び出しと見なされます。BatchGet 操作のみを使用する場合、または BatchGet 操作と単一行 Get 操作の両方を使用する場合、平均 RT は単一行 Get 操作の RT よりも高くなります。

• スキャン操作メトリック: [スキャンリクエスト (個/秒)]、[スキャン平均 RT (ミリ秒)]、[スキャン P99 RT (ミリ秒)]。これらのメトリックは、範囲スキャンリクエストを監視するために使用されます。Lindorm サーバーは、広範囲のスキャンリクエストを分割し、ストリーミング方式でデータを返します。[スキャンリクエスト (個/秒)] は、広範囲のスキャンリクエストが分割された後にサーバーに送信されるサブスキャンリクエストの数/秒を示し、[スキャン平均 RT (ミリ秒)] は、各スキャン操作で使用される平均時間を示します。したがって、[スキャンリクエスト (個/秒)] の値は、実際に開始されたサブスキャンリクエストの数よりも多くなる場合があります。完全なスキャンリクエストで使用される時間は、複数のサブスキャンリクエストで使用される時間の合計です。

• 読み取り操作メトリック: [読み取りリクエスト (秒/秒)]、[読み取り平均 RT (ミリ秒)]、[読み取りトラフィック]。これらのメトリックは、Get リクエストとスキャンリクエストの両方を監視し、インスタンスによって返される行数/秒や各データ行を返すために使用される平均 RT などの情報を収集するために使用されます。1 つの Get リクエストまたはスキャンリクエストで複数の行が返される可能性があるため、これらのメトリックはインスタンスの読み取りスループットをより正確に反映できます。

書き込みリクエスト

• [書き込みトラフィック]: このメトリックは、LindormTable への書き込み操作のスループット (単位: KB/秒) を監視するために使用されます。LindormTable が基盤となるストレージにデータを書き込むとき、ワイドテーブルの列はキーと値のペアに変換されるため、格納される列のデータ量は実際に書き込まれた列よりも大きくなります。このメトリックを使用して LindormTable の書き込みスループットを判断することをお勧めします。

  書き込みスループットが高いと、圧縮タスクが累積し、インスタンスの安定性に影響を与える可能性があります。ビジネス要件に基づいて CPU を適切に構成することをお勧めします。

  次の表に、さまざまな構成で推奨される書き込みスループットを示します。

  CPU 構成	推奨される書き込みスループット
  4 コア	5 MB/秒未満
  8 コア	10 MB/秒未満
  16 コア	30 MB/秒未満
  32 コア	60 MB/秒未満

  上記の値は参考値です。実際に使用する場合は、[圧縮キューの長さ]、[リージョン内のファイルの平均数]、[リージョン内のファイルの最大数] などのメトリックと組み合わせてさらに検討できます。

• [Memstore の上限を超えた回数 (回)]: LindormTable は最初にデータを対応するシャードの Memstore に書き込みます。Memstore の使用率が高すぎると、システムはフラッシュ操作をトリガーしてデータをディスクに書き込みます。書き込みリクエストが少数のシャードに集中している場合、これらのシャードの Memstore の使用率が高くなりすぎて、スループットに影響を与える書き込みバックプレッシャーが発生します。したがって、このメトリック値が 0 より大きい場合は、書き込みホットスポットが存在するかどうか、または書き込みトランザクション/秒 (TPS) がインスタンスで処理できる制限を超えているかどうかを検討する必要があります。これにより、データがディスクにタイムリーに書き込まれない可能性があります。この場合、ハッシュアルゴリズムを使用してプライマリキーをより均等に分散し、ホットスポットを回避できます。詳細については、「Lindorm ワイドテーブルのプライマリキーの設計」をご参照ください。