...
ウェブホスティングのロゴ

Redisのスローログを分析・最適化し、パフォーマンスを最大化させる

Redisのスローログを見ると、どのコマンドがサーバースレッドをブロックしているか、またその実行時間がマイクロ秒単位でどれくらいかかるかが正確にわかるため、レイテンシの原因を的確に特定して解消することができます。信頼性の高い閾値、正確なエクスポート、および相関するメトリクスを活用して、私は パフォーマンス 持続可能だ。

中心点

詳細に入る前に、目標を明確に定め、的を絞って進められるよう、最も重要なポイントを整理しておきます。明確な構成、繰り返し現れるパターン、そして効果的な対策に焦点を当てます。さらに、クライアントのコンテキストやシステム環境との関連性にも注意を払います。そうすることで、一貫性のある 分析 ノイズなし。その後、得られた知見をコード、データモデル、モニタリングの調整に直接反映させます。.

  • 閾値 また、ログの長さを適切に選ぶ
  • サンプルについて 時間, コマンドとクライアントの識別
  • 処理が遅いコマンド 代替案 置き換える
  • データモデルと キャッシング 引き締める
  • ログインが遅い モニタリング 統合

Slow Log：仕組みの簡単な解説

私は「スロー・ログ」を、純粋な……に対する集中的な視点として捉えています。 実行時間 Redisのシングルスレッドにおけるコマンドの実行。実行時間が「slowlog-log-slower-than」で設定されたしきい値（マイクロ秒単位）を超えると、サーバーは自動的にエントリを記録します。 各レコードには、ID、Unixタイムスタンプ、実行時間、引数付きのコマンド、クライアントのIPアドレス/ポート、およびオプションでクライアント名が含まれています。 ネットワークI/Oや応答の転送時間は、スローログでは意図的に除外されているため、スレッドの実際のブロック時間を確認できます。まさにこの区別によって、ネットワークやクライアントの遅延による原因と、それ以外の原因を明確に区別し、 原因 より絞り込む。.

設定：しきい値とログの長さ

生産的なスタートを切るために、私は 閾値 多くの場合、10,000マイクロ秒（約10ミリ秒）に設定していますが、テスト時にはより細かい詳細を把握するために一時的にこの値を下げることもあります。 保存されるエントリ数は `slowlog-max-len` で制御しており、通常は128から4096の範囲に設定して、負荷のピークが明確に把握できるようにしています。これらの値は、redis.confで変更するか、実行時に `CONFIG SET` を使用して変更しており、これにより柔軟な診断ウィンドウを実現しています。 大規模な負荷テストを行う前にはしきい値を下げ、テスト終了後には現実的な本番環境の値に戻します。これにより、重要な情報を失うことなく、ログをスリムに保つことができます。 信号 を失う。.

設定／コマンド 意味 実用価値
slowlog-log-slower-than エントリのしきい値（マイクロ秒単位） 製品：10,000 µs；テスト：1,000～5,000 µs
slowlog-max-len 保存できるエントリの最大数 128～4096件（データ量に応じて）
SLOWLOG GET N 直近のN件のデータを表示します アドホックなチェックの場合、N = 10～100
SLOWLOG LEN 現在のログの長さを返します 定期的に確認する
SLOWLOG RESET ログをクリアする 事前にエクスポート／バックアップを行う

日常生活におけるスローログの読み取り

日常の運用では、SLOWLOG GET を使って最新のエントリを取得し、SLOWLOG LEN で処理が遅いコマンドがどれほど蓄積しているかを確認してから、必要に応じて SLOWLOG RESET でログをクリアしています。リセット前にエクスポートを行うことで、貴重な 歴史 特に数日間にわたる傾向を比較したい場合には、データが欠落してしまいます。クラスター構成では、スローログがインスタンス固有のものであるため、すべてのインスタンスとレプリカを対象に含めます。そうしないと、データの盲点が残ってしまうからです。 体系的な分析を行う際には、エントリをIP、ポート、設定された名前などのクライアント情報と関連付け、アプリケーションコード内の発生源を明確に特定できるようにしています。さらに、INFO統計を確認し、全体的な利用状況の文脈で発生頻度やレイテンシを評価しています。.

事象からパターンへ：体系的な分析

まず、最も頻繁に目につき、かつ影響度の高いコマンドについて検討します。 ランタイム その後、そのインスタンス全体でそれらがどのくらいの頻度で発生しているかを確認します。しきい値をほとんど超えないコマンドは、しきい値をわずかに上回るものの、1分間に1000回も実行されるコマンドよりも、システムへの影響は少ないのです。 Cronジョブ、バックアップ、またはトラフィックのピーク時に発生する時間的なクラスターを分析することで、その原因が作業のピークなのか、アプリケーションのルーチン処理なのかを見極めることができます。INFO commandstats を使用すると、呼び出し回数や平均所要時間に関するコンテキスト情報を得ることができ、この情報は記事を通じて手軽に確認できます。 INFO commandstats 掘り下げる。「CLIENT LIST」から特定したクライアント名をサービスやマイクロサービスに関連付けることで、責任の所在を割り当て、 最適化 的を絞って計画を立てる。.

最適化戦略：コマンドとデータモデル

大量のデータに対して、KEYS のような高コストなコマンドの代わりに、カスタマイズしたカーソルを使用した SCAN を実行することで、ロックを回避し、 レイテンシー 実行時間を短縮する。Luaスクリプトの実行時間が長すぎる場合は、ロジックをいくつかの小さなステップに分割するか、あらかじめ集計済みのデータを利用する。実行時間が長くなるのは、多くの場合、データモデルの問題に起因している。そのため、非常に大きなリスト、セット、ハッシュを分割したり、追加のインデックスやより適切なデータ型を活用したりする。 繰り返し行われる計算コストの高い処理については、常に再計算を強制するのではなく、アプリケーションに近い場所で結果をキャッシュし、制御された方法でキャッシュを無効化します。典型的な設定ミスやアンチパターンについては、実践的な観点から以下にまとめます。 典型的な設定ミス をまとめて、避けられるミスをより早く解消し、 効率性 増加した。

クライアントのコンテキストとアプリケーションコード

コード内では、パイプライン化と束ねることでラウンドトリップを削減し、その結果、純粋な サーバー時間 変更はしませんが、1回の呼び出しあたりの体感レイテンシを大幅に低減します。Slow Logのエントリから得られるパラメータにより、不要なループや重複したアクセスが発生している箇所を特定できます。 チーム内で割り当てが即座に明確になるよう、クライアントにはCLIENT SETNAMEを介して意味のある名前を割り当てるようにしています。 ホットキーを特定し、アクセスパターンを分散させ、TTL戦略を見直すことで、書き込み負荷を分散させています。移行フェーズや機能フラグの設定時には、影響を受けるパスのエントリを重点的に監視し、影響を迅速に把握して、 品質 を確保する。.

リソース、トポロジー、およびレイテンシの原因

処理の遅さがすべて非効率な命令に起因するわけではないため、私はCPUの使用率のピーク、メモリのボトルネック、ネットワークの遅延を、以下の項目と並行して確認している。 エントリ スローログに記録されます。シャードの分散が不適切だったり、レプリカの数が少なすぎたり、ゾーン間の通信経路が長かったりすると、体感される処理時間が長くなります。 さらに、RDB/AOFの設定や、サーバープロセスに一時的な負荷をかけるバックグラウンドジョブについても確認します。高負荷時には、データモデルがすでに最適化されており、適切なコマンドが選択されている場合、スケーリングの選択肢を検討します。システムメトリクスとの相関関係を分析して初めて、私にとって明確な 原因と結果―チェーンが見える。.

Slow Logをモニタリングに統合する

専用のダッシュボードでは、ログの長さの推移、サービスごとの低速コマンドの数、およびCPUやメモリの使用率などの関連指標を確認できます。私はこのスローログデータを既存のオブザーバビリティ・パイプラインに組み込み、それによって継続的な モニタリング. グラフィカルユーザーインターフェースでは、コマンド、時刻、クライアントごとにフィルタリングを行い、異常を迅速に特定しています。実用的なワークフローには、Slow Logビューやワークベンチ、エクスポート機能を備えたツールを活用しています。これらは、 RedisInsight ガイド 説明する。これにより、診断までのプロセスを大幅に短縮し、その 指標.

実践ガイド：ステップ・バイ・ステップ

まず、ノイズを発生させたり、重要な情報を失ったりしないよう、slowlog-log-slower-than および slowlog-max-len が適切に設定されていることを確認します。 信号 を失う。その後、最新のデータセットを読み出し、それらをバックアップし、頻度や継続時間を踏まえて、不審なコマンドを特定する。 次のステップでは、時間枠を分析し、CLIENT名を関連付け、繰り返し出現するパラメータのパターンを探します。そこから、コード、データモデル、およびキャッシュの設計における具体的な対策を導き出します。最後に、この分析結果を常時監視システムに組み込み、トレンドを早期に検知できるようにします。 回帰分析 防ぐ。.

経験則とチューニングの基準

しきい値として10 msという初期値は、多くの本番環境ではうまく機能しますが、テストではこれより低い値が役立つ場合があります。 詳細 提供します。ログの長さは、ストレージを無駄にすることなく、典型的な日次や週次のパターンを反映するように調整しています。ベースラインを設定し、典型的なコマンドの分布を記録するとともに、徐々に生じる変化にも注意を払っています。 デプロイ後は、意図的にスローログを確認し、新機能が予期せぬレイテンシ経路を生み出していないかを早期に検知するようにしています。この取り組みにより、いつ調整を行うべきか、またどのように パフォーマンス 長期的に高い水準を維持する。.

「スローログ」の制限事項と解釈上の注意事項

スローログは、サーバースレッド内での純粋な実行時間のみを測定している点を考慮しています。コマンドキューでの待機時間、TLSハンドシェイクにかかる時間、あるいはネットワーク経由での大規模な応答の転送時間は、そこには反映されません。 同様に、スロウログではメモリの都合上、コマンド引数が制限され、場合によっては切り詰められるため、私はパラメータをあくまで参考情報として捉え、完全な事実とは見なしていません。また、このログは閾値ベースで動作するため、最も遅いケースのサンプルが得られるだけで、完全な分布は得られません。 そのため、私は分析結果にモニタリングから得られたレイテンシのパーセンタイルを追加し、必要に応じて組み込みのLATENCYモニター（しきい値はlatency-monitor-thresholdで設定）を使用して、散発的なスパイクを検出しています。.

クラスタおよびレプリケーションの特記事項

クラスタ構成では、処理に時間がかかるコマンドが個々のスロットやシャードに集中していないかを確認します。 スロットをまたぐ操作（例：ハッシュタグのないキーに対する MGET）は、エラーや迂回を引き起こし、スローログには反映されないものの、体感されるレイテンシを増加させる不要なラウンドトリップを発生させます。 リバランス、フェイルオーバー、レプリケーションの追跡処理はシステム負荷に影響を与えます。WAIT などのコマンドは、確認応答が到着するまで意図的に時間を要することがあります。スタンバイレプリカでは異なるアクセスプロファイルが適用されます。 そこでは、読み取り負荷、同期処理、バックグラウンドプロセスがそれぞれ異なるため、スローログのエントリを個別に確認しています。正確な診断を行うために、各インスタンスからスローログをエクスポートし、すべてのノードにわたってタイムスタンプを照合しています。.

永続性、フォーク、およびメモリの挙動

RDBスナップショットとAOF書き換えには注意を払っています。Redisプロセスのフォーク時に、Copy-on-Writeによって一時的にメモリ使用量が増加したり、CPU使用率が急上昇したりすることがあり、その結果、コマンドの実行時間が長引く可能性があります。 AOFの設定（例：appendfsync）は書き込みレイテンシに影響を与えます。「everysec」は通常、良い妥協点となりますが、「always」は耐久性を高める一方で、ピークの発生を招く可能性があります。 さらに、アクティブなメモリデフラグ、エヴィクション、および期限切れキーの処理にも注意を払っています。大規模な単一キー（例：数万のフィールドを持つハッシュ）は、Expireサイクルや削除処理の際に顕著な遅延を引き起こします。 lazyfreeオプション（例：lazyfree-lazy-eviction）を使用することで、ワークロードのプロファイルが適合する場合、大規模な構造体の解放を非同期で行うようにし、メインスレッドの負荷を軽減しています。.

ブロッキングコマンド、マルチキーコマンド、およびスクリプトコマンド

私は、線形時間（O(N)）のコマンドと、対数時間または定数時間のバリエーションとを区別しています。大規模な構造体に対してSORT、SUNIONSTORE、ZUNIONSTORE、あるいはHGETALLを実行すると、しばしばスローログに記録されます。 EVALやEVALSHAはアトミックで実用的ですが、内部ループによってサーバースレッドを長時間占有してしまう可能性があります。この場合は、より小規模で適切に調整された部分処理の方が適しています。 BLPOPやXREAD BLOCKのようなブロッキング命令は、主にクライアントをブロックし、サーバースレッドをブロックするわけではありませんが、非常に大規模なデータ構造と組み合わされると深刻な問題となります。 スキャン時には、インデックスロジックを伴わない幅の広いMATCHパターンを避け、負荷を制御可能な範囲に保つようCOUNTを調整しています。SCANは完全なブロックを防ぐ役割を果たしますが、無計画な検索を許容する「フリーパス」ではありません。.

エクスポート、自動化、データ加工

再現性のある分析を行うため、私は定期的にスローログをエクスポートし、その形式を統一しています。所有権が明確になるよう、クライアント名、ユーザー（ACL）、サービスタグを含むエントリをエクスポートしています。シェルを使ったシンプルなワークフローにより、アドホックなエクスポートもスムーズに行えています：

# 直近500件のエントリをJSON形式でエクスポート
redis-cli SLOWLOG GET 500 > slowlog.raw

# CSVの例（ID;タイムスタンプ;所要時間（µs）;コマンド;クライアント）
# 注：スローログでは引数が省略されている場合があります
redis-cli --raw SLOWLOG GET 200 | awk '
  BEGIN{FS="\n"; OFS=";"} 
  /1\)/{id=$2} /2\)/{ts=$2} /3\)/{dur=$2} /4\)/{cmd=$0; gsub(/^[^"]*"/,"",cmd); gsub(/"[^$]*/,"",cmd)} /5\)/{client=$0}
  /5\)/{print id,ts,dur,cmd,client}
' > slowlog.csv

自動化パイプラインでは、すべてのノードからデータを取得し、タイムスタンプ（UTC）を正規化し、コマンドごと、クライアントごと、および時間枠ごとのメトリクスを算出しています。 ピークデータが失われないよう、SLOWLOG RESETを実行する前には必ずデータをエクスポートし、ログの長さに合わせてローテーション頻度を調整するようにしています。.

インシデント対応の手順パターン

深刻なケースでは、まず現状を維持します。SLOWLOG LENを確認し、直近のエントリを十分にエクスポートした上で、データがローテーションによって消失しないよう、一時的にslowlog-max-lenを増やします。その後、閾値を適度に下げて、従来の閾値をわずかに下回るパターンも把握できるようにします。 並行して、CPU、RSSメモリ、ページフォールト、ネットワークRTT、および永続化イベント（RDB/AOF）を監視します。特定のコマンドが大量に発生している場合は、フィーチャーフラグやレート制限の引き締めにより、一時的にその発生を抑制します。 ホットキーについては、アクセスを分散させ（キーハッシュ／シャードスプレッド）、必要に応じてレプリケーション容量を増強します。ピークが収まり次第、より詳細な原因分析を行い、コードおよびデータモデルに恒久的な修正を適用します。.

デプロイ前後の品質保証

リリース前には、ステージング環境でスローログの閾値を大幅に引き下げ、微細な非効率な箇所を早期に発見するようにしています。許容されるレイテンシの予算（例：コマンドごとのp95/p99）を定義し、文書化されたベースラインと比較します。 ロールアウト後は、対象となるサービスのSlow Logエントリを綿密に監視します。基準値からの逸脱が見られた場合は、速やかにロールバックを行うか、的を絞った最適化を行います。シャード／ゾーンごとにカナリーロールアウトを行うことで、影響を個別に観察しやすくなります。 重要なのはコミュニケーションです。各クライアントにはわかりやすい名前を付け、スローログのエントリを即座に担当者に割り当てられるようにしています。これにより、問題解決が大幅に加速されます。.

閾値および対数長に関する決定ロジック

しきい値は絶対的な値だけでなく、状況に応じて設定しています： NVMeを搭載し、CPUリソースが豊富な高速ノードでは、運用時間帯に細かいホットスポットを検出できるよう、しきい値を5～8 msに下げる傾向があります。一方、低コストのハードウェアやバーストトラフィックが激しい場合は、ログの信号強度が保たれるよう、より保守的な設定にしています。 ログの長さは、コマンドレートとエクスポート間隔に応じて調整します。コマンドレートが高いほど、トラフィックサイクル全体を捕捉できるよう、ウィンドウを長く設定します（例：2048～4096）。 負荷テストでは、ピークを見逃さないよう、意図的に長さを長く設定し、エクスポートを適時行うように計画します。負荷が低い時期には、メモリを節約し、分析の焦点を絞るために、これらの値を低く設定します。.

実務におけるよくあるパターン

一般的に、原因には3つの種類があると考えています。第一に、大規模な構造体に対する高コストなO(N)操作（SORT、大規模なセット／ハッシュの結合、完全な反復処理）、第二にシステムの副作用（フォーク、デフラグ、 エヴィクション）、そして第三に、アプリケーションのパターン（N+1アクセス、二重計算、キャッシュの欠如）です。 対策はこれらから直接導き出されます。命令の置換とデータ量の制限、負荷の高い操作をジョブやキューに分離すること、大規模オブジェクトの非同期解放、適切なTTLおよび無効化戦略、そして消費者に近い場所での集約の強化などです。 私は常にこれらの対策をメトリクスと結びつけ、成果を測定可能にし、パフォーマンスの低下を迅速に把握できるようにしています。.

コンパクトな概要

私はスローログを使って、純粋な サーバー時間 高コストなコマンドを可視化し、適切な閾値を設定し、リセットからデータセットを保護します。redis.conf や CONFIG SET による設定により、不要なメモリを消費することなく、診断期間を柔軟に調整しています。 これらのエントリから、コマンド、時間、クライアントに関するパターンを導き出し、それに基づいてコマンドの選択、データモデル、キャッシュ、アプリケーションコードを最適化します。並行して、スローログの統計情報をシステムメトリクスやAPMシグナルと照合し、原因を明確に特定できるようにしています。これにより、 パフォーマンス 計画可能となり、レイテンシの問題による予期せぬ影響もなくなります。.

現在の記事