キャッシュ障害を予測する 5 つの指標

Momento を構築するとき、私たちは根本的な問いに答える必要がありました。本番のキャッシュインフラで、問題を本当に予測できる指標は何でしょうか。

見栄えのよい数字や、ダッシュボードを飾る指標ではありません。データベースが過負荷になったり、P999 レイテンシが 500ms に跳ね上がったりして、午前 2 時に呼び起こされる原因を捉える指標です。

大規模なキャッシュインフラを運用してきた経験から、社内で徹底して注視している 5 つの指標と、その確認点を紹介します。

メモリ使用率とエビクション率

誰もが used_memory と maxmemory を比較して監視します。しかし、本当に重要なのはエビクション率です。

エビクションが増え始めると、キャッシュの動作は根本から変わります。アプリケーションが存在を期待するキーが削除され、ヒット率が崩れ、データベース負荷が急増します。テールレイテンシは 1 ミリ秒未満から数百ミリ秒へ跳ね上がります。

Momento では、ストレージノードをメモリ使用率 95% で運用しません。それは効率的な容量計画ではなく、本番障害が起きるのを待つ状態です。95% の使用率で一度トラフィックが急増すれば、大量のエビクションが起きます。そうなると、キャッシュは本来の役割を果たせません。

確認点： evicted_keys を追跡してください。ベースラインを超えるエビクションが持続しているなら、今すぐ容量を増やす必要があります。

接続の生成と破棄

多くのチームは connected_clients を確認するだけで終わります。本当の兆候は接続の入れ替わり、つまり毎秒どれだけ新しい接続を作っているかに表れます。

新しいコードをデプロイし、接続数は安定しているように見えたのに、2 時間後にクラスターが停止する。このような状況を何十回も調査してきました。原因は新しいコードでコネクションプーリングが適切に行われず、毎秒数千の接続を生成・破棄していたことでした。

確認点： total_connections_received を追跡し、増加速度を監視してください。トラフィックが安定しているなら、新規接続の生成はほぼゼロになるはずです。毎秒数十の接続を作っているなら、コネクションプーリングが機能していません。

P999 レイテンシ

P99 は最も遅い 1% のリクエストの境界、P999 は最も遅い 0.1% の境界を示します。毎秒 100,000 リクエストを処理するサービスでは、P999 より遅いリクエストは毎秒 100 件に相当します。単なる分布の裾ではなく、大規模なユーザー体験の問題です。

P99 と P999 の差は多くを語ります。P99 が 2ms でも P999 が 80ms なら、一部のリクエストにリソース競合やネットワークの問題が影響しています。

1 ミリ秒未満の P999 レイテンシは、単なる付加価値ではありません。多くの本番ワークロードでは、キャッシュの価値そのものです。わずか 0.1% でもキャッシュが 50ms の遅延を加えるなら、アプリケーションを高速にするどころか、予測しづらくしています。そして予測できないレイテンシは、常に遅いレイテンシより厄介です。

私たちの内部 SLA は P99 ではなく P999 を対象にしています。実システムが破綻するのはそこだからです。

確認点： P99 が横ばいなのに P999 が急上昇していないかを見てください。少数のリクエストが、遅いコマンドやリソース競合の大きな影響を受けている兆候です。

キャッシュミス率

多くのダッシュボードはキャッシュヒット率を表示します。私たちはキャッシュミス率（CMR）を追跡しています。

これは言い換えではなく、考え方の転換です。キャッシュヒット率が 99% から 98% に下がっても、小さな変化に見えます。1% の低下なら問題なさそうでしょう。しかし、ミス率で見ると 1% から 2% への倍増です。データベースに届くリクエストが 100% 増えたことになります。

ヒット率 98% の本番システムが停止する例を見てきました。残りの 2% が、500ms かかる高コストのデータベースクエリであり、ミス率が上昇した瞬間にバックエンドを圧倒したからです。

Momento がキャッシュミス率の急増に敏感なのは、データベース負荷の急増に直結するためです。コールドキャッシュ、失敗したデプロイ、スケーリングは、いずれも CMR の急増を引き起こします。

ミス率とミス時のレイテンシを併せて追跡する必要があります。ミスの処理が 10～20ms なら、ミス率 5% でも許容できるかもしれません。しかし 500ms かかるなら、99.5% 以上のヒット率を確保するか、何をキャッシュするかを見直す必要があります。

確認点： デプロイ、スケーリング、ノード障害の際の CMR 急増を確認してください。

レプリケーション遅延

レプリケーションを使って Valkey を運用しているなら、プライマリとレプリカの遅延は早期警戒の仕組みになります。

1～2 秒を超える遅延が持続するなら、何かが限界に達しています。ネットワークの飽和、レプリケーション能力を超える書き込みスループット、レプリカの過負荷などが考えられます。

私たちはレプリケーション遅延を容量計画の指標としています。遅延が増加傾向になったら、フェイルオーバーの問題に波及する前に容量を追加するか、負荷を再分散します。

確認点： master_repl_offset と slave_repl_offset の差を監視してください。1～2 秒を超える遅延が続く、または際限なく増える場合は、対処が必要です。

運用から学んだこと

これらの指標はすべて、オープンソースの Valkey ですでに利用できます。しかし、何を監視するかを知ることは課題の 10% にすぎません。デプロイ中にノードをウォームアップし、CMR が急増する前にスケールし、負荷がかかっても 1 ミリ秒未満の P999 を維持するなど、信号に自動で対応するシステムを作ることが残りの 90% です。

午前 2 時に呼び出されるチームと、夜通し眠れるチームの違いは運ではありません。適切な指標を選び、事後対応のアラームではなく予測のための信号として扱っているかどうかです。

この 5 つから始め、ベースラインを定め、変化率にアラートを設定してください。アラートが発生したとき、ユーザーが気づく前に、どこで問題が起きているかを正確に把握できます。