すべてのプロダクト
Search
ドキュメントセンター

Tair (Redis® OSS-Compatible):スロークエリログを使用したタイムアウト問題のトラブルシューティング

最終更新日:Sep 10, 2026

低速リクエストは、Tair (Redis OSS-compatible) のサービス品質に影響を与える接続タイムアウトの一般的な原因です。Tair (Redis OSS-compatible) の低速クエリログシステムは、各低速リクエストと送信元のクライアント IP アドレスを記録するため、リクエストとその送信元の両方を特定できます。このトピックの手順に従ってタイムアウトの原因を特定し、低速クエリログで問題が説明できない場合は代替手段を使用してください。

表示方法

タイプ方法
データノードのスロークエリログクライアントからインスタンスに接続し、SLOWLOG GET コマンドを実行します。詳細については、「SLOWLOG GET」をご参照ください。コンソールを使用するか、API を呼び出します: スロークエリログの照会、DescribeSlowLogRecords
プロキシノードのスロークエリログコンソールを使用するか、API を呼び出します: スロークエリログの照会、DescribeSlowLogRecords

トラブルシューティングパスの選択

スロークエリログはタイムアウト問題をトラブルシューティングする主要な方法ですが、すべての原因を網羅しているわけではありません。観測された事象をこのトピックの対応するパスと照合してください。

観測可能な状態パス
サービスタイムアウトが発生するプロキシノードのスロークエリログから始め、次にデータノードのスロークエリログを確認してください。「スロークエリログ分析によるタイムアウト原因の特定」をご参照ください。
サービスタイムアウトが発生し、インスタンスが標準アーキテクチャを使用しているプロキシノードのスロークエリログをスキップし、データノードのスロークエリログを分析してください。「スロークエリログ分析によるタイムアウト原因の特定」をご参照ください。
プロキシノードのスロークエリログが空で、インスタンスがパブリックネットワーク (インターネット) 経由でアクセスされているクライアントとインスタンス間のネットワークリンクを確認してください。「パブリックネットワーク接続のレイテンシーのトラブルシューティング」をご参照ください。
キーに対する読み取りリクエストが高頻度で発生するが、各リクエストの完了時間が slowlog-log-slower-than のしきい値よりも速いため、スロークエリログに記録されない「ホットキーのトラブルシューティングにおけるスロークエリログと監査ログの制限」をご参照ください。
スロークエリログの分析とパブリックネットワーク接続の確認で原因が特定できない「VPC、ECS、およびアプリケーション側でのトラブルシューティングの継続」をご参照ください。

サーバー側のパフォーマンスの最初の確認

スロークエリログには、スロークエリのしきい値を超えたリクエストのみが記録されます。タイムアウトが低速なリクエストによるものか、ネットワークリンクによるものかを判断する前に、インスタンス自体にパフォーマンスのボトルネックがないかを確認してください。

AI インスタンス診断の実行

  1. 製品ページで、[AI Instance Inspection] をクリックします。

  2. 8 つの診断項目をすべて選択し、[Start Inspection] をクリックします。

  3. 生成された診断レポートで、インスタンスのステータス、セキュリティ、高可用性 (HA) 、データノードのパフォーマンス、プロキシノードのパフォーマンス、スロークエリログ、ビッグキーとホットキーの状態、およびイベントアラートに異常がないかを確認します。

パフォーマンスモニタリングの表示

  1. 製品ページで、[Performance Monitoring] をクリックします。

  2. [Data Node] ビューまたは プロキシノード ビューに切り替え、CPU 使用率、1 秒あたりのリクエスト数 (QPS) 、平均応答時間 (RT) 、およびインバウンドとアウトバウンドのトラフィックレートを確認します。

  3. 各ノードのメトリクスを使用して、インスタンスにパフォーマンスの問題があるかどうかを判断します。

スロークエリログ分析によるタイムアウト原因の特定

サービスタイムアウトの原因は複雑な場合がありますが、多くは低速なリクエストに関連しています。以下の手順に従ってタイムアウト問題をトラブルシューティングしてください。

  1. サービスタイムアウトが発生した場合、まずプロキシノードのスロークエリログを確認します。手順については、「スロークエリログの照会」をご参照ください。

    説明
    • インスタンスが標準アーキテクチャを使用している場合は、手順 3 に進み、データノードのスロークエリログを分析します。

    • プロキシノードのスロークエリログが空の場合、クライアントとインスタンス間のネットワーク接続を確認します。インスタンスがパブリックネットワーク (インターネット) 経由でアクセスされている場合は、以下の「パブリックネットワーク接続のレイテンシーのトラブルシューティング」をご参照ください。

  2. プロキシノードのスロークエリログの最も古いエントリからコマンドを特定します。

    説明

    通常、プロキシノードのスロークエリログは、データノードでの低速なリクエストが原因でコマンドが滞留したときに生成されます。

    この例では、最も古いスロークエリログのエントリは KEYS コマンドによって生成されています。ログレコード内の IP アドレスは、コマンドを送信したクライアント IP アドレスです。

    スローログ ページで プロキシノード タブをクリックし、プロキシノードのスロークエリログを表示します。この例では、テーブルに 5 つのレコードが表示されています。1 つは KEYS コマンド、4 つは SET コマンドのもので、実行時間は 64,048~88,861 マイクロ秒の範囲です。

  3. データノードのスロークエリログを確認し、プロキシログで見つかったコマンドが同様に記録されているかを確認します。これにより、そのコマンドが根本原因であることを特定できます。

    説明

    通常、最初にプロキシノードでスロークエリログエントリを生成したコマンドは、データノードでもエントリを生成します。2 つのログでは実行時間の定義が異なり、使用されるスロークエリのしきい値も異なるため、通常、データノードのスロークエリログのエントリ数はプロキシノードのスロークエリログよりも少なくなります。

    この例では、2 つのログを比較すると、KEYS コマンドのエントリが両方に存在することがわかります。データノードのログにプロキシログの他のコマンドが存在しないことから、KEYS コマンドが根本原因であることが確認されます。

    スローログ ページで [Data Node] タブをクリックし、データノードのスロークエリログを表示します。この例では、KEYS コマンドのスロークエリログエントリのみが表示されています。その長い実行時間から、このコマンドがタイムアウトの根本原因であることが確認できます。

  4. プロキシノードのスロークエリログで前の手順のコマンドを検索し、ソースクライアントの IP アドレスを見つけます。その後、クライアントアプリケーションを最適化します。

    スロークエリログの分析とパブリックネットワーク接続の確認で原因が特定できない場合は、「VPC、ECS、およびアプリケーション側でのトラブルシューティングの継続」をご参照ください。

ホットキーのトラブルシューティングにおけるスロークエリログと監査ログの制限

slowlog-log-slower-than パラメーターは、データノードのスロークエリログのしきい値を設定します。デフォルト値は 20,000 マイクロ秒 (20 ms) です。高頻度で発生する読み取りリクエストでも、個々の完了時間がこのしきい値より速い場合は記録されません。その結果、デフォルトのスロークエリログでは、ホットキー問題の原因となる読み取りリクエストをキャプチャできません。ホットキー問題が疑われる場合は、slowlog-log-slower-than の値を下げてより多くのリクエストをログに記録し、高頻度の読み取りリクエストのソースを特定してください。手順については、「スロークエリログの照会」をご参照ください。

監査ログを有効にすると、書き込み操作のみが記録されます。読み取り操作は記録されません。そのため、監査ログを使用してホットキーにアクセスする読み取りリクエストのクライアント IP アドレスを表示することはできません。これらのクライアント IP アドレスを特定するには、slowlog-log-slower-than のしきい値を下げ、結果のスロークエリログを確認してください。監査ログ機能の詳細については、「監査ログの概要」をご参照ください。ホットキー問題が書き込みリクエストによって引き起こされている場合は、監査ログベースのホットキー照会機能を使用してください。手順については、「履歴ホットキーの照会」をご参照ください。

パブリックネットワーク接続のレイテンシーのトラブルシューティング

サーバー側のメトリクスでパフォーマンスのボトルネック (CPU、メモリ、接続がすべて正常で、スロークエリログが空) が示されていないにもかかわらず、クライアントが接続タイムアウトエラーを報告する場合は、クライアントとインスタンス間のネットワークリンクを確認してください。

一般的な症状

クライアントは "socket error"、"read error"、または "connection timeout" などのエラーを報告しますが、インスタンスのサーバー側の CPU、メモリ、および接続メトリクスは正常で、RT は低いです。

主な原因

クライアントとインスタンス間のパブリックネットワークリンクが不安定であり、リージョン間の伝送で遅延が発生します。これらの影響は、クロスボーダーアクセスシナリオでより顕著になります。

推奨事項

  1. パブリックネットワークリンクに依存せず、コアビジネスのワークロードには内部ネットワーク接続を使用してください。

  2. クロスリージョン展開の場合は、Cloud Enterprise Network (CEN) を使用してリージョン間の VPC を接続し、低レイテンシーで安定した内部ネットワーク接続を実現してください。手順については、「リージョン間接続の管理」をご参照ください。

  3. クライアント側で、接続タイムアウトと読み取り/書き込みタイムアウトの値を増やし、ネットワークの変動に対応するためのリトライロジックを実装してください。一般的なタイムアウトエラーの解決策については、「一般的なエラーとトラブルシューティング」をご参照ください。

VPC、ECS、およびアプリケーション側でのトラブルシューティングの継続

スロークエリログの分析とパブリックネットワーク接続の確認で原因が特定できない場合は、VPC、ECS、およびアプリケーション側の情報を使用して範囲を絞り込みます。

  1. 製品ページから VPC ID と vSwitch ID を取得します。

  2. 低速またはタイムアウトが発生している ECS インスタンスに異常があるかどうか、またそのタイミングがアプリケーションの変更と一致するかどうかを確認します。

  3. タイミングがアプリケーションの変更と一致する場合は、変更をロールバックするか、手がかりがないか調査します。VPC ID と vSwitch ID を使用して、VPC または ECS コンソールでトラブルシューティングを続行します。