Redisのmaxmemoryを適切に設定する：データと運用ためのメモリの余裕

実際にmaxmemoryが制限しているもの

maxmemory Redis Open Source に 立ち退き基準 Redisプロセスやそのコンテナに対して、厳格な上限は設定されていません。メモリ制御に関連する使用量が閾値に達すると、Redisは選択されたポリシーに応じてキーの削除を試みます。エヴィクションを行わないポリシーの場合、メモリ使用量を増加させる書き込みコマンドは代わりに失敗することがあります。

指標 used_memory Redisがアロケーターを介して割り当てたメモリを含みます。これには、アプリケーションの実際の値だけでなく、管理構造やその他のRedisのメモリ領域も含まれます。ユーザーデータの推定サイズだけに基づいて制限値を算出すると、このオーバーヘッドが考慮されなくなります。

の一部 used_memory 「エヴィクション」の検証では、以下のものが除外されます： mem_not_counted_for_evict 特に、一時的なレプリケーション・バッファやAOF・バッファが存在します。これらのバッファは、それでも実メモリを必要とします。この値はすでに used_memory が含まれているため、検証なしにこの指標に再度加算してはならない。

だからといって、すべてのクライアントやレプリケーション用ストレージがエヴィクションの対象外になるわけではない。また、単一の大きなコマンドによって、一時的にしきい値を大幅に超えてしまうこともある。もし maxmemory コンテナの容量上限に達してしまうと、こうした変動や追加のプロセス消費に対応できる確実な余裕は残されません。

したがって、計画にあたっては、次の2つの質問に別々に答える必要があります。メモリ管理の範囲内で、データセットとRedisのオーバーヘッドにはどれだけのスペースが必要か？そして、それ以外に実行環境全体にはどれだけの予備容量が必要か？この2つの視点を合わせて初めて、選択した値が実際のメモリ制限の範囲内で妥当であるかどうかが判断できます。

RSS、アロケーター、および永続性のピーク

負荷のピークが過ぎると、 used_memory …一方で、 used_memory_rss 高いままとなる：Redisはアロケーターを介してメモリを解放したとはいえ、そのメモリが必ずしも直ちにOSに返却されたわけではない。RSSはOSの観点から見たプロセスの常駐メモリを表すものであり、したがって別の観測レベルである。

ある操作中にキャッシュが大幅に増加し、その後多くのキーの有効期限が切れたと仮定する。Redisのメモリ使用量が減少したからといって、コンテナが即座にそれに見合った分の空き容量を取り戻せるわけではない。したがって、次のピーク時には、解放されたメモリが即座に消滅するという仮定よりも、実際の使用状況の推移の方が重要となる。

また mem_fragmentation_ratio これは単なる断片化率ではありません。この比率にはその他のプロセス要素も含まれています。原因分析を行う際には、入手可能なデータと併せて検討する必要があります。 allocator_*- メトリクスと負荷履歴を考慮する。単一の比率から、普遍的に適用できる予備容量を導き出すことはできない。

RDBスナップショットやAOF書き換えの際、Redisは子プロセスを生成します。これにより コピー・オン・ライト 永続化処理中にページが変更される場合、追加の物理メモリページが必要になる可能性があります。その間の書き込み負荷が強くて広範囲に及ぶほど、容量計画においてこのフェーズを注視することが重要になります。

Redisの管理チームは、書き込み負荷の高いアプリケーションの場合、極端なケースでは通常使用されるメモリの最大2倍が必要になると指摘しています。これは負荷バランスが不適切な場合の警告であり、一律の倍率を示すものではありません。 また、親プロセスと子プロセスのRSS値を単純に足し合わせないでください。共有されているページが複数回カウントされてしまうため、適切なホストまたはコンテナの監視を行うことが重要です。

レプリカには独自の予算が必要だ

レプリカは基本的にデータセットのコピーを保持しており、そのため専用のRAMを必要とします。したがって、プライマリとレプリカは別々のメモリ消費源となります。プライマリ上の予備容量は、レプリカのコンテナ内に空き容量を生み出すことはありません。各ノードについては、それぞれの制限値と実際の消費量に基づいて計画を立ててください。

デフォルトでは、レプリカは設定された maxmemory 自身のエヴィクションについて。プライマリはキーの削除を決定し、その削除処理をレプリケートします。とはいえ、バッファやデータ構造の違いなどにより、ストレージの状態が異なる場合があります。したがって、同じ閾値を設定しても、負荷が完全に同一になることは保証されません。

ある プロモーション 以前のレプリカがプライマリの役割を引き継ぎます。そのため、読み取り用コピーとして十分な容量があるかどうかだけでなく、そのストレージ上限や構成がプライマリとしての運用に耐えられるかどうかも確認してください。これには、特に書き込み負荷、レプリケーション接続、およびその時点で適用されるエヴィクション制御が含まれます。

Redis 7.0 以降、レプリカバッファとレプリケーションバックログはメモリを共有するようになりました。 mem_clients_slaves そのため、レプリケーションがメモリを消費しているにもかかわらず、0 と表示される場合があります。このフィールドを単独で解釈したり、バックログとレプリカバッファを、完全に独立した領域として無批判に合算したりしないでください。

メモリ使用量に加え、データ転送の進捗状況も運用上重要です。遅延は、バッファのサイズとは異なる特性を示します。レプリケーションの状態と遅れをどのように分類できるかについては、以下の記事で解説しています。 Redisのレプリケーションオフセット。とはいえ、蓄電余力については、各インスタンスの実際の消費推移が依然として決定的な要素となる。

3つのレベルでメモリを把握する

サイジングを行うには、Redisおよびインスタンスが実行されている環境からの値が必要になります。その 観測レベル その数値が何を意味するかを決定づけるものです。アロケーターの割り当て、プロセスのRSS、コンテナの使用量はそれぞれ異なる指標であり、単純に足し合わせることはできません。

と一緒に INFO memory Redisの保存値や設定済みのポリシーなどを読み取ります。 MEMORY STATS メモリ割り当てに関する詳細を追加します。どちらのコマンドも読み取り専用です。利用可能なフィールドは、Redisのバージョン、権限、およびホスティングプランによって異なります。

また、時間的な関連性については、以下の点を確認してください。 INFO persistence 永続化アクティビティおよび利用可能なコピー・オン・ライトの値について。 INFO replication ロールとレプリケーションの状態を表示します。評価の際にロールの切り替えや同期が明確に把握できるよう、プライマリとレプリカについてこれらの情報を別々に記録してください。

単一の値だけでは、通常の負荷状況も、必要なピーク時の予備容量も示されません。 そのため、通常稼働時、書き込みのピーク時、およびパーシステンス実行時の時系列データを収集し、同時に観測されたホストまたはコンテナのリソース使用量をそれらに紐付けてください。そうすることで、高いRSS値が現在の負荷に伴うものなのか、それとも以前のピーク後に残っているものなのかも把握できます。

現実的なストレージ予算の算出

出発点は、実際に効力を有する 保存制限: コンテナの場合、ホストのRAM容量よりも少なくなることがあります。同じリミットを消費している他のプロセスやシステムコンポーネントを特定してください。それらに割り当てられているリソースは、Redisがデータやピーク時の負荷に対応するために利用できません。

その後、追加のRSSおよびアロケーター効果、エヴィクションの対象外となるバッファ、持続性のピーク、および安全マージンを見込んで余裕分を差し引きます。その結果、暫定的な maxmemory-予算であり、Redis内部の計算式ではない。予備容量は、同じ制限値に合致し、現実的に同時に発生し得る負荷状況に対応していなければならない。

参考となる計算例（実測値ではない）：8 GiBのコンテナ制限のうち、0.5 GiBは他の消費者に、0.5 GiBは追加のRSS効果に、0.5 GiBはエヴィクション計算から除外されるバッファに割り当てられ、 1 GiBが永続性のピーク用に、0.5 GiBが安全マージンとして差し引かれます。暫定値として、5 GiBが maxmemory.

これらの数値は、特定のインスタンスに対する推奨値ではありません。 この例では、割り当てられたリザーブが、コンテナの境界に対して重複しない追加的な貢献を表していることを前提としています。特にパーシステンス実行の場合、共有メモリページやコピー・オン・ライトにより割り当てが複雑になる可能性があり、親プロセスと子プロセスのRSS値を単純に足し合わせるだけでは不適切です。

避ける 重複集計: mem_not_counted_for_evict すでに含まれている used_memory. 観測されたRSSまたはコンテナの総消費量を基準とする場合、このバッファ分を検証せずに再度加算してはならない。残りのエヴィクション・バジェットには、データセットと、それに含まれるRedisのオーバーヘッドの両方を収める必要がある。その後、同等の負荷条件下でこのアプローチを検証すること。

立ち退き政策の実務比較

仝 立ち退き方針 メモリ不足時にRedisが書き込みコマンドにどのように対応するかを決定します。これは容量計画の代わりにはなりません。適切なポリシーであっても、エヴィクションの計算範囲外の予備容量が必要です。この決定は、主にどのキーを損失してもよいか、およびアプリケーションがエラーにどのように対応するかによって決まります。

純粋なキャッシュの場合、 allkeys-lru 削除されたエントリが別のソースから再構築できる場合に適しています。RedisにおけるLRUは近似値であり、厳密なグローバルソートではありません。頻繁なエヴィクションはバックエンドへのアクセス増加を招く可能性があるため、空きバイト数だけでなく、キャッシュヒット率やバックエンドの処理能力も重要です。

任意に削除できないデータについては、 noeviction 別の決定事項：アプリケーションは、書き込み操作が失敗した場合に対処できなければならず、書き込みが成功したと黙って想定してはならない。このポリシーは、永続性を保証するものでも、OSやコンテナレベルでのOOM（メモリ不足）からの保護を目的としたものでもない。

構成が混在している場合は、 TTL種目 決定的なのは、ある volatile-*-Policy は、有効期限が設定されたキーのみを選択できます。適切な候補が十分にない場合、TTL だけでは書き込みエラーを防ぐことはできません。したがって、キャッシュと重要なデータが、本当に同じインスタンスおよびエラー処理戦略を共有すべきかどうかを確認してください。

セッションデータは、この目的間の矛盾を浮き彫りにしています。エントリが削除されると、アプリケーションが技術的には引き続き動作していても、ユーザーにとってはセッション状態が失われることを意味する可能性があります。ポリシーを選択する前に、その影響と復元可能性を評価してください。この件に関する追加の基礎情報は、以下の記事で提供されています。 Redis やその他のストレージを用いたセッション管理.

負荷がかかった状態での予備容量を確認する

の計算値 maxmemory まずは出発点となります。Redisのバージョン、データ構造、メモリ制限が同等の、隔離された環境でこれを検証してください。負荷は通常の運用状況を再現するだけでなく、書き込みのピーク時や、永続化とレプリケーションが同時に有効になっている局面も反映させる必要があります。

その際、以下の点に注意してください。 コンテナの使用量 あるいは、対応するホストメトリクスやRedisのストレージ値も同様です。スナップショットやAOF書き換えが実行されているタイミング、およびレプリカが同期されているかどうかを記録してください。重要なのは、イベントが重複している間、実際の閾値までどれだけの余裕があるかであり、その後のアイドル状態だけではありません。

読み取りコマンドを使用して INFO stats とりわけ、エヴィクションカウンターを記録します。時間間隔ごとの変化を評価してください。過去の数値が高いというだけでは、現在キーが追い出されているかどうかは判断できません。アプリケーションでこれらの数値が提供されている場合は、エヴィクションの増加傾向をキャッシュヒット数やバックエンドの負荷と関連付けて分析してください。

さらに、アプリケーション内のRedis OOM応答や、プラットフォーム上のストレージ関連のコンテナイベントも記録してください。これらのエラーは、同様の負荷下で発生する可能性がありますが、それぞれ異なる制限値に関連しています。したがって、アラート設定では、利用可能な予備容量に加え、観測されたエラーとその経時的な推移も考慮に入れる必要があります。

データセット、書き込み負荷、または永続化およびレプリケーションに変更を加えた後は、評価を再度実施してください。プロモーションが行われると、レプリカの役割が変化し、その結果、検証すべき負荷プロファイルも変化します。隔離環境での結果は、本番インスタンスの継続的な監視に代わるものではありません。

メモリの問題を的確に特定する

プロセスRSSが上昇している間、 used_memory が低下した場合は、まずその推移と以前の負荷を確認してください。解放されたメモリは、必ずしも直ちにオペレーティングシステムに返されるわけではありません。その アロケーターのメトリクス より INFO memory 分類の参考になります。断片化率だけでは、メモリリークそのものやその原因を証明するものではありません。

その後、その上昇が、パーシステンス実行や同期処理と時期が一致しているかどうかを確認してください。そのために以下のものが役立ちます。 INFO persistence そして INFO replication. エヴィクションの対象外とされるバッファの単一の値は、あくまで現在の状態を表すに過ぎない。予備容量を算出するには、関連する負荷段階や障害段階にわたる観測データが必要となる。

ある RedisのOOM応答 設定されたポリシーを確認し、エヴィクションに適切なキーが存在するかどうかを確認してください。特に、適用中のポリシーの下でRedisが十分な空き領域を確保できない場合、書き込みコマンドが失敗する可能性があります。アプリケーションは、書き込みが成功することを前提とするのではなく、このエラーを適切に処理する必要があります。

一方、メモリ不足によるコンテナの停止が発生した場合は、プラットフォームイベントと、コンテナの制限値に対する使用量を調査してください。その際、永続化処理のピークや、コンテナ内で記録されたその他のリソース消費量も考慮に入れてください。 RedisのOOMとコンテナのOOMは同一視できません。事前のRedis OOM応答がなくても、外部のメモリ上限に達する可能性があります。

maxmemory-clients さらに、クライアントが占有するメモリを制限することもできます。該当するクライアントのメモリ使用量が設定された閾値を超えた場合、Redisはメモリ使用量の多いクライアントの接続を切断することがあります。アプリケーション側では、接続切断への対応が必要です。 この設定は、すべてのレプリケーション接続を制限するものではなく、総使用量の上限やバッファのピーク値の監視に代わるものでもありません。

Redisのホスティングとアーキテクチャを検討する

代表的な負荷条件下で観測されたリザーブが不十分な場合、データセットと負荷を基本的に1つのインスタンス上に留めておく必要があるなら、RAMを増設することが有効な場合があります。ただし、追加された容量は、実際に有効なホストまたはコンテナの制限範囲内に含まれている必要があります。Redisの制限値を大きくしただけでは、物理メモリが追加されるわけではありません。

あるいは、 負荷分散 メモリ使用量と書き込み処理を複数のインスタンスに分散させる。これには、データの適切な分割と、関与する各インスタンスごとの個別のリソース割り当てが必要となる。なお、レプリカはデータセットの分割と同義ではない。レプリカは基本的にデータのコピーを保持しており、そのために専用のRAMを必要とする。

アーキテクチャの変更も有効な手段となり得ます。例えば、損失許容性の高いキャッシュと、より厳しい要件を持つデータを分離することなどが挙げられます。これにより、ポリシーと容量を独立して選択できるようになります。ただし、この分離やRAMの増設、負荷分散のいずれを行っても、将来的に永続化、レプリケーション、書き込みのピークが発生しないことを保証するものではありません。

を比較すると、 プロバイダーの制限 表示されている値が、コンテナ制限、インスタンス制限、あるいはその他の定義されたデータベース制限のいずれを指すのかを確認してください。また、利用可能なメトリクスや診断コマンド、予約済みストレージにレプリカが含まれているかどうか、およびプロモーションが利用可能なリソースにどのような影響を与えるかについても確認してください。

Redis Open Source、Redis Software、および Redis Cloud は、それぞれ別個に考える必要があります。Redis Software の場合、プライマリおよびレプリカ・シャード全体にわたって、ドキュメントに記載されたデータベースの制限が適用されます。したがって、単一の Redis OSS インスタンスに対して同様のルールが適用されるわけではありません。 Redis Cloud やその他のホスティングサービスについては、この定義を無批判に適用するのではなく、それぞれの具体的な製品条件を確認してください。