Memorystore for Redis インスタンスが正しく管理および構成されていない場合、アプリケーションのパフォーマンスに影響するようなメモリの負荷が発生する可能性があります。このページでは、インスタンスのメモリ使用量を効率的に管理するために活用できるベストプラクティスについて説明します。
このトピックの内容:
メモリ管理のコンセプト - Memorystore インスタンスを正常に保つために知っておく必要がある重要なコンセプト。
メモリ使用量の多いオペレーション - メモリ負荷が発生する可能性のあるオペレーション。
インスタンスのメモリ使用量のモニタリング - インスタンスがメモリをどのように使用しているかを確認するためにモニタリングすべき指標。
メモリ不足状態の解決 - メモリ不足状態に関連する問題を解決する際の手順。
Memorystore インスタンスの適切なサイズ - オーバー プロビジョニングされたインスタンスを作成するのではなく、インスタンスを適切なサイズに設定する方法。
メモリ管理のコンセプト
このセクションでは、インスタンスのメモリ使用量を管理するために理解する必要があるコンセプトを説明します。
インスタンスの容量
- インスタンスの容量は、ギガバイト（GB）単位でプロビジョニングするメモリの量で、その量で課金されます。適切なインスタンス容量の選択の詳細については、Memorystore インスタンスの適切なサイズをご覧ください。
Maxmemory 構成
Maxmemory は、エビクション ポリシーを有効にするメモリ上限を設定できる Redis 構成です。Memorystore for Redis では、この構成を
maxmemory-gbとして指定します。インスタンスを作成すると、maxmemory-gbはインスタンスの容量に設定されます。システムのメモリ使用率の指標によっては、ワークロードの急増に合わせてメモリのオーバーヘッドを提供するためにmaxmemory-gbの上限を下げる必要があります。詳細については、システムのメモリ使用率を管理するをご覧ください。
maxmemory-gbを調整する方法については、Redis インスタンスの構成をご覧ください。
システム メモリ使用率
システム メモリ使用率の指標を使用すると、システム メモリに対するインスタンスのメモリ使用量を測定できます。システム メモリは、メモリ使用量の多いオペレーションと、オープンソースの Redis で一般的なメモリのフラグメンテーションによって発生するメモリ使用量の急増を処理するため、Memorystore によって自動的に管理されます。
システム メモリ使用率の指標が 80% を超える場合は、インスタンスがメモリ不足であることを示しているため、システムメモリ使用率の管理の手順に従ってください。何もせずにメモリ使用量が増え続けると、メモリ不足が原因でインスタンスがクラッシュする恐れがあります。メモリのフラグメンテーションが原因で、システムのメモリ使用率の指標が 80% を超える場合があります。あるいは、指標が 80% 以上に急増した場合は、メモリ使用量の多いオペレーションのいずれかを使用した可能性があります。
メンテナンス更新時のシステム メモリ使用率は 50% 以下でなければなりません。また、エクスポートでは、システム メモリ使用率が 50% 以下である必要があります。
使用済みメモリ
- 使用済みメモリの指標は、Memorystore インスタンス内にデータがどれくらいあるかを示しています。インスタンスの使用済みメモリは、
maxmemory-gb構成の上限まで増加できます。使用済みメモリがmaxmemory-gb上限を超えると、エビクション ポリシーが有効になります。
エビクション ポリシー
インスタンス データが
maxmemory-gbの上限に達すると、インスタンスのエビクション ポリシー（maxmemory ポリシーとも呼ばれます）により、Redis がキーを削除するかどうかが決定されます。Redis は、通常のキャッシュのユースケースの一部としてキーを削除します。キーのエビクションはバックグラウンド プロセスとして行われるため、maxmemory-gbの上限に達した直後にキーが削除されることはありません。書き込みレートが高いとキーのエビクションが追いつかない場合があり、その場合、メモリ不足の状態になる可能性があります。Memorystore インスタンスのデフォルトのエビクション ポリシーは
volatile-lruです。volatile-*エビクション ポリシーを使用している場合は、期限切れにするキーに TTL を確実に設定してください。そうしないと、Redis はキーを強制排除しません。エビクション ポリシーのリストについては、Maxmemory ポリシーをご覧ください。
エビクション ポリシーを変更する方法については、Redis インスタンスの構成をご覧ください。
メモリのフラグメンテーション
maxmemory-gbに対する使用済みメモリの比率が低い場合でも、メモリのフラグメンテーションにより、Memorystore インスタンスのメモリが不足することがあります。メモリのフラグメンテーションは、書き込みと削除のオペレーションが繰り返された後、オペレーティング システムにより Redis が完全には利用できないメモリページが割り当てられるときに発生します。このようなページが蓄積されるとシステムはメモリ不足に陥り、最終的に Redis サーバーがクラッシュする原因になります。activedefragRedis 構成を使用すると、フラグメンテーションを減らすことができます。
アクティブ デフラグメンテーション
Redis バージョン 4.0 以降には、
activedefrag構成が用意されています。可能であれば、Redis 4.0 を使用して Memorystore インスタンスを作成してください。Memorystore ではデフォルトでactivedefragを「no」に設定されます。activedefragを「yes」に設定すると、CPU のトレードオフが発生しますが、メモリのフラグメンテーションを軽減できるため、メモリ不足の問題に貢献します。システムのメモリ使用率の指標がメモリのフラグメンテーションを示している場合は、
activedefragをオンにする必要があります。それ以外の場合、activedefragはオプションの設定です。
メモリ使用量が多いオペレーション
次のオペレーションは、特に書き込みレートが高いオペレーションを一緒に実行すると、大量のメモリを使用します。
エクスポート オペレーション
Memorystore のエクスポート機能では、Redis の BGSAVE オペレーションを使用します。このオペレーションではコピー オン ライトが使用されます。データのサイズ、書き込みボリューム、タッチされたキーによっては、エクスポートに必要なメモリは、データが占める容量の 2 倍になる可能性があります。したがって、エクスポートを成功させるには、maxmemory-gb 上限をエクスポート中のインスタンスの容量の 50% に減らす必要があります。
スケーリングとバージョン アップグレードのオペレーション
書き込み負荷が高い期間にスケーリングやアップグレードを行うと、レプリケーションによるメモリのオーバーヘッドが原因で、インスタンスにメモリの負荷がかかります。また、読み取り負荷が高いと、Redis の出力バッファのサイズが増加し、メモリ負荷が増加する可能性があります。メモリの負荷が原因でスケーリングまたはアップグレードのオペレーションが失敗した場合は、次の対応を行います。
- スケーリング / アップグレード オペレーションの前に、
maxmemory-gbをインスタンス容量の 50% に引き下げます。可能であれば、インスタンスのトラフィックが少ない期間中は、maxmemory の値も下げてください。そうすることによって、maxmemory を下げることによるキャッシュ ヒット率に対する悪影響を減らすことができます。 - 書き込みが少ない期間にスケーリングまたはアップグレードを行う。
メンテナンス
メンテナンスもインスタンスにメモリ負荷を追加します。定期メンテナンス時にシステム メモリ使用率の指標が 50% 以下になるように対策する必要があります。これを行うには、インスタンスのトラフィックが少ない時間のスケジュールを設定するか、メンテナンスの時間枠でインスタンス サイズを一時的にスケールアップして、システム メモリ使用率の指標が 50% 以下になるようにします。
インスタンスのメモリ使用量をモニタリングする
指標をモニタリングして、このセクションで概要を説明するアラートを設定します。これらの指標とアラートはからは、インスタンスのメモリ使用量に関する分析情報が得られます。指標を表示してアラートを設定する方法については、Redis インスタンスのモニタリングをご覧ください。
メモリ管理に関連する指標
| 指標 | 指標の完全なアドレス |
|---|---|
| Maxmemory | redis.googleapis.com/stats/memory/maxmemory |
| メモリ使用量 | redis.googleapis.com/stats/memory/usage |
| メモリ使用率 | redis.googleapis.com/stats/memory/usage_ratio |
| システム メモリの過負荷期間 | redis.googleapis.com/stats/memory/system_memory_overload_duration |
| システム メモリ使用率 | redis.googleapis.com/stats/memory/system_memory_usage_ratio |
| キャッシュ ヒット率 | redis.googleapis.com/stats/memory/cache_hit_ratio |
| 有効期限のあるキー | redis.googleapis.com/keyspace/keys_with_expiration |
| 期限切れのキー | redis.googleapis.com/stats/expired_keys |
| 強制排除されたキー | redis.googleapis.com/stats/evicted_keys |
メモリ使用率
メモリ使用率の指標は、作業セットのサイズが maxmemory-gb の上限にどの程度近づいているかを示します。エビクション ポリシーが「エビクションなし」に設定されていない限り、maxmemory に到達するインスタンス データは常に問題を示すものではありません。ただし、キー排除はバックグラウンド プロセスであり、時間がかかります。書き込みレートが高い場合は、空き容量を増やすために Redis がキーを排除する前にメモリ不足になる可能性があります。
システム メモリ使用率
システム メモリ使用率は、モニタリングに重要な指標です。インスタンスを確保するには、ワークロードやその他のメモリ使用量の多いオペレーションをサポートするために十分なメモリがあり、利用可能で十分なシステム メモリが常にあることが重要です。
システムのメモリ使用率の指標が 80% に達した場合に通知するアラートを設定します。80% に達した場合は、システムのメモリ使用率の指標をより詳細にモニタリングする必要があります。システムのメモリ使用率が引き続き大幅に増加する場合は、activedefrag を有効にし、maxmemory を減らして、インスタンスのスケーリングを検討してください。
システムのメモリ使用率が 100% に達すると、インスタンスのメモリ フットプリントをさらに増加させるオペレーションはいずれもブロックされ、Redis は次のエラーを返します。
-OOM command not allowed under OOM prevention.
詳しくは、システム メモリ使用率の管理をご覧ください。
システム メモリの過負荷期間
メモリ使用量が高すぎる場合、インスタンスを正常に保つために、Memorystore によってインスタンスへの書き込みがブロックされます。システム メモリの過負荷期間は、インスタンスがブロックされた書き込み状態にある期間の長さを追跡します。
この指標に対するアラートを設定して、インスタンスへの書き込みがいつブロックされるかを把握する必要があります。また、この指標を参照して -OOM command not allowed under OOM prevention. エラーが発生した場合のトラブルシューティングを行うこともできます。
キャッシュ ヒット率
キャッシュ ヒット率を定期的にモニタリングして、Redis インスタンスのキーによって正常に返されるキー検索の割合を把握する必要があります。一般に、低いキャッシュ ヒット率よりは、高いキャッシュ ヒット率の方が良いと言われています。maxmemory-gb 上限の調整、エビクション ポリシーの変更、インスタンスのスケーリングなど、大きな構成変更を行う前に、キャッシュ ヒット率をメモしておく必要があります。次に、インスタンスを変更した後、キャッシュ ヒット率を再度確認して、変更がこの指標にどのように影響したかを確認します。
有効期限のあるキーと期限切れキー
Stackdriver 指標の有効期限のあるキーは、有効期限が設定されているキーの数をモニタリングします。有効期限のあるキーがない場合は、キーに TTL が設定されていない可能性があることを示しています。このような場合、インスタンス データが maxmemory-gb 上限に達すると、volatile-* エビクション ポリシーを使用している場合に、強制排除するキーがなく、メモリ不足状態になる可能性があります。
モニタリングできるもう 1 つの指標は期限切れキーです。指標に期限切れキーが多数表示されているにもかかわらず、インスタンスに対するメモリの負荷が残っている場合は、maxmemory-gb を下げてください。
メモリ不足状態の解決
インスタンスでメモリ負荷が発生した場合や、メモリ不足のエラーが発生した場合は、以下のベストプラクティスに従ってください。
volatile-*エビクション ポリシーを使用している場合は、期限切れにするキーに TTL を設定していることを確認します。詳しくは、エビクション ポリシーをご覧ください。Redis 4.0 以降を実行しているインスタンスの場合は、次の操作を行います。
- インスタンスの
activedefragをオンにします。詳細については、アクティブ デフラグをご覧ください。
- インスタンスの
指標を使用してメモリ状況を解消し、インスタンスのメモリ使用量を分析する方法については、インスタンスのメモリ使用量をモニタリングすると、システムのメモリ使用率を管理するをご覧ください。
メモリ使用量の多いオペレーションを実行する際に maxmemory を調整する方法については、メモリ使用量の多いオペレーションをご覧ください。
システムメモリ使用率の指標が 80% を超える場合は、インスタンスの
maxmemory-gb上限を下げます。詳しくは、システム メモリ使用率の管理をご覧ください。インスタンスのスケールアップを検討します。
それでも OOM の状態が続く場合は、Google Cloud Platform サポートまでお問い合わせください。
Memorystore インスタンスの適切なサイズ
このセクションでは、ワークロードに基づいてインスタンスを適切にサイズ設定する際に役立つ 3 つの別のアプローチについて説明します。
- Memorystore インスタンスの初期サイズを決定する。インスタンスを作成する前にインスタンス サイズを見積もる方法を説明します。
- インスタンスのメモリ使用量をモニタリングする。インスタンスがメモリをどのように使用しているかについての有用な情報を提供する指標を説明します。
- システム メモリ使用率を管理する。システム メモリ使用率が 80% を超えた場合の対処方法を説明します。
Memorystore インスタンスの初期サイズを決定する
最初に、スタンダード階層のインスタンスと基本階層インスタンスのどちらを使用するかを選択する必要があります。Memorystore for Redis の階層の詳細については、Redis の階層機能をご覧ください。アプリケーションに適した階層を選択したら、次の手順に従って、必要なインスタンス サイズを決定します。
データのサイズを決定します。
- アプリケーションが Redis インスタンスに書き込むキーの数と平均サイズを見積ります。これらの値を掛けて、必要なインスタンス サイズの大まかな見積もりを作成します。
エビクション ポリシーを選択します。
noevictionmaxmemory ポリシーを使用する場合は、ピークのワークロードとワーキング セットを保持するために十分な大きさのインスタンス サイズが必要です。この maxmemory ポリシーによるメモリを使い切ると、インスタンスがメモリ不足の状態になる可能性があります。- 他のエビクション ポリシーは、プロビジョニングするインスタンスのサイズには影響しません。
スタンダード ティア インスタンスの追加メモリをプロビジョニングする
- 基本階層インスタンスとは異なり、標準階層インスタンスはレプリケーション バッファとしてインスタンス容量の 10% を予約します。標準階層インスタンスを選択する場合は、手順 1 で作成したデータ見積もりを確認し、レプリケーション バッファに 10% の追加容量を設定します。
平均書き込みレートとピーク書き込みレートを見積もる
- 可能であれば、アプリケーションが使用するキーの書き込みレートとサイズを見積もります。キーの削除レートと比較した書き込みレートによって、時間の経過とともにインスタンスが増加する速度が決まります。
目的のキャッシュ ヒット率に達するまでスケールアップする
- キャッシュ ヒット率をモニタリングし、必要なキャッシュ ヒット数が得られない場合は、インスタンス サイズを増やすか、アプリケーションが、リクエストされて処理されなかった Memorystore インスタンスに、確実にキーを書き込むようにするかのどちらかが必要です。
インスタンスがメモリ不足の状態が原因で書き込みをブロックしているかどうかを確認する
次のエラーが発生した場合:
-OOM command not allowed under OOM prevention.
次の状況が起きているかどうかを確認します。
- インスタンスで問題が発生する直前に、システム メモリ使用率の指標が 80% を超えた。
- インスタンスの問題が発生する前に、システム メモリ使用率が急速に増加した。
- システム メモリの過負荷期間の指標が、書き込みがブロックされた期間と同じ期間にゼロを超えた。
もしこの状況が起こった場合は、メモリ不足の状態が原因で、インスタンスが書き込みをブロックしていることを示しています。
システムのメモリ使用率を管理する
アラートを設定するを使用すると、システム メモリ使用率の指標が 80% を超えると、通知されます。システム メモリ使用率が 80% を超える場合は、インスタンスのメモリが不足しないように適切な対応を行う必要があります。書き込みボリュームとキーのアクセス パターンによっては、システム メモリ使用量が急速に 100% まで増加する可能性があります。Memorystore では、システム メモリ使用率を次の方法で管理できます。
- Redis バージョン 4.0 以降を実行しているインスタンスで
activedefragをオンにする。 - インスタンスの
maxmemory-gb上限を引き下げる。 - インスタンスをスケールアップする。
- 適切なエビクション ポリシーを選択する。
- 変動キーに TTL を設定する。
- インスタンスから手動でキーを削除する。
activedefrag を有効にする
システムメモリ使用率が 80% を超える場合は、activedefrag（Redis バージョン 4.0 以降を実行しているインスタンスの場合）を有効にします。デフラグメンテーションによる断片化されたメモリの解放には、数時間を要する場合があります。書き込みトラフィック量が多い場合は、デフラグメンテーションのみではインスタンスのメモリ不足を回避するのに十分ではない可能性があります。このため、次の推奨事項を実装することが必要な場合があります。
インスタンスの最大メモリ上限を下げる
システムメモリ使用率が 80% を超える場合は、maxmemory-gb を引き下げる必要がありますが、まず、設定する新しい maxmemory-gb 上限を決めるために、システム メモリ使用率が時間経過とともに、どのように変化しているかを確認します。
シナリオ 1: システム メモリ使用率が徐々にゆっくりと上昇しています。フラグメンテーションが問題である可能性が高いため、システム メモリ使用率が安定して 80% を下回るまで maxmemory-gb を少しずつ小さくする必要があります。
シナリオ 2: システムのメモリ使用率が急速に上昇し、インスタンスに大量の書き込み負荷が発生しています。メモリ使用量の多いオペレーションが急増の原因である可能性があります。この状況では、maxmemory-gb の上限を大きくして、インスタンスがメモリ不足状態にならないようにするか、メモリ不足状態から回復する必要があります。maxmemory を下げると、インスタンスのキャッシュ ヒット率が低下する可能性があるので注意してください。キャッシュ ヒット率が大幅に低い場合は、Redis を使用するメリットを活用できるように、インスタンスをスケールアップする必要があります。maxmemory-gb 構成を調整する方法については、Redis インスタンスの構成をご覧ください。
インスタンスをスケールアップする
Redis インスタンスのスケーリングの手順に沿って、インスタンスの容量を増やします。
Maxmemory のスケーリング例:
maxmemory-gb が 8 GB に設定された 10 GB のインスタンスがある場合は、キーを保存する 8 GB と、メモリのオーバーヘッドの 2 GB があります。インスタンスを 20 GB にスケールすると、maxmemory-gb は 16 GB にスケールされます。そのため、インスタンスにはキーを保存するメモリが 16 GB と、4 GB のオーバーヘッドがあることになります。インスタンスのサイズを増減する方法については、Redis インスタンスのスケーリングをご覧ください。
適切なエビクション ポリシーを選択する
変動するデータを保存する場合は、volatile-* エビクション ポリシーのいずれかを選択します。変動しないデータを保存する場合は、allkeys-* ポリシーのいずれかを選択します。
インスタンスからキーを手動で削除する
インスタンスからキーを手動で削除することで、メモリ状態を改善できます。これは、インスタンスの状態改善に役立つ一時的なソリューションです。