メモリ管理のベスト プラクティス

Memorystore for Redis インスタンスが正しく管理および構成されていない場合、アプリケーションのパフォーマンスに影響するようなメモリの負荷が発生する可能性があります。このページでは、インスタンスのメモリ使用量を効率的に管理するために活用できるベストプラクティスについて説明します。

このトピックの内容:

メモリ管理のコンセプト

このセクションでは、インスタンスのメモリ使用量を管理するために理解する必要があるコンセプトを説明します。

インスタンスの容量

  • インスタンスの容量は、ギガバイト(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 サーバーがクラッシュする原因になります。activedefrag Redis 構成を使用すると、フラグメンテーションを減らすことができます。

アクティブ デフラグメンテーション

  • 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 を下げてください。

メモリ不足状態の解決

インスタンスでメモリ負荷が発生した場合や、メモリ不足のエラーが発生した場合は、以下のベストプラクティスに従ってください。

  1. volatile-* エビクション ポリシーを使用している場合は、期限切れにするキーに TTL を設定していることを確認します。詳しくは、エビクション ポリシーをご覧ください。

  2. Redis 4.0 以降を実行しているインスタンスの場合は、次の操作を行います。

    1. インスタンスの activedefrag をオンにします。詳細については、アクティブ デフラグをご覧ください。
  3. 指標を使用してメモリ状況を解消し、インスタンスのメモリ使用量を分析する方法については、インスタンスのメモリ使用量をモニタリングすると、システムのメモリ使用率を管理するをご覧ください。

  4. メモリ使用量の多いオペレーションを実行する際に maxmemory を調整する方法については、メモリ使用量の多いオペレーションをご覧ください。

  5. システムメモリ使用率の指標が 80% を超える場合は、インスタンスの maxmemory-gb 上限を下げます。詳しくは、システム メモリ使用率の管理をご覧ください。

  6. インスタンスのスケールアップを検討します。

  7. それでも OOM の状態が続く場合は、Google Cloud Platform サポートまでお問い合わせください。

Memorystore インスタンスの適切なサイズ

このセクションでは、ワークロードに基づいてインスタンスを適切にサイズ設定する際に役立つ 3 つの別のアプローチについて説明します。

Memorystore インスタンスの初期サイズを決定する

最初に、スタンダード階層のインスタンスと基本階層インスタンスのどちらを使用するかを選択する必要があります。Memorystore for Redis の階層の詳細については、Redis の階層機能をご覧ください。アプリケーションに適した階層を選択したら、次の手順に従って、必要なインスタンス サイズを決定します。

  1. データのサイズを決定します。

    • アプリケーションが Redis インスタンスに書き込むキーの数と平均サイズを見積ります。これらの値を掛けて、必要なインスタンス サイズの大まかな見積もりを作成します。
  2. エビクション ポリシーを選択します。

    • noeviction maxmemory ポリシーを使用する場合は、ピークのワークロードとワーキング セットを保持するために十分な大きさのインスタンス サイズが必要です。この maxmemory ポリシーによるメモリを使い切ると、インスタンスがメモリ不足の状態になる可能性があります。
    • 他のエビクション ポリシーは、プロビジョニングするインスタンスのサイズには影響しません。
  3. スタンダード ティア インスタンスの追加メモリをプロビジョニングする

    • 基本階層インスタンスとは異なり、標準階層インスタンスはレプリケーション バッファとしてインスタンス容量の 10% を予約します。標準階層インスタンスを選択する場合は、手順 1 で作成したデータ見積もりを確認し、レプリケーション バッファに 10% の追加容量を設定します。
  4. 平均書き込みレートとピーク書き込みレートを見積もる

    • 可能であれば、アプリケーションが使用するキーの書き込みレートとサイズを見積もります。キーの削除レートと比較した書き込みレートによって、時間の経過とともにインスタンスが増加する速度が決まります。
  5. 目的のキャッシュ ヒット率に達するまでスケールアップする

    • キャッシュ ヒット率をモニタリングし、必要なキャッシュ ヒット数が得られない場合は、インスタンス サイズを増やすか、アプリケーションが、リクエストされて処理されなかった Memorystore インスタンスに、確実にキーを書き込むようにするかのどちらかが必要です。

インスタンスがメモリ不足の状態が原因で書き込みをブロックしているかどうかを確認する

次のエラーが発生した場合:

-OOM command not allowed under OOM prevention.

次の状況が起きているかどうかを確認します。

  1. インスタンスで問題が発生する直前に、システム メモリ使用率の指標が 80% を超えた。
  2. インスタンスの問題が発生する前に、システム メモリ使用率が急速に増加した。
  3. システム メモリの過負荷期間の指標が、書き込みがブロックされた期間と同じ期間にゼロを超えた。

もしこの状況が起こった場合は、メモリ不足の状態が原因で、インスタンスが書き込みをブロックしていることを示しています。

システムのメモリ使用率を管理する

アラートを設定するを使用すると、システム メモリ使用率の指標が 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-* ポリシーのいずれかを選択します。

インスタンスからキーを手動で削除する

インスタンスからキーを手動で削除することで、メモリ状態を改善できます。これは、インスタンスの状態改善に役立つ一時的なソリューションです。