Important
Azure Cache for Redis は、すべての SKU の提供終了タイムラインを発表しました。 できるだけ早く既存の Azure Cache for Redis インスタンスを Azure Managed Redis に移行することをお勧めします。
提供終了の詳細については、以下を参照してください。
負荷時のスケーリング
負荷時にキャッシュをスケーリングする場合は、システムの応答性を向上させるために maxmemory-reserved の設定を行ってください。 詳細は、「maxmemory 設定の構成」を参照してください。
クラスターのスケーリング
クラスタリングされたキャッシュをスケーリングする前に、キャッシュ内のデータをできる限り削減してください。データを削減することで、移動するデータ量が少なくなり、拡張操作に必要な時間が短縮されます。 拡張の時期については、「拡張の時期」を参照してください。
負荷が高くなる前に拡張する
サーバーの負荷またはメモリの使用量が増大する前に、スケーリングを開始します。 高すぎる場合は、Redis サーバーがビジー状態であることを意味します。 ビジー状態の Redis サーバーには、データの拡張と再配布に必要なリソースが不足しています。
キャッシュ サイズ
TLS を使用し、接続数が多い場合は、負荷をより多くのコアに分散できるようにスケール アウトすることを検討してください。 一部のキャッシュ サイズは、コアが 4 つ以上の VM でホストされます。 ワークロードを複数のコアに分散することで、キャッシュ VM の全体的な CPU 使用率を下げることができます。 詳細は、「VM のサイズとコアの詳細」を参照してください。
スケーリングとメモリ
キャッシュ インスタンスは、Azure portal で次の方法でスケーリングできます。 PowerShell コマンドレット、Azure CLI、および Microsoft Azure 管理ライブラリ (MAML) を使用して、プログラムでキャッシュをスケーリングすることもできます。
ポータルでキャッシュをスケールアップまたはスケールダウンすると、maxmemory-reserved と maxfragmentationmemory-reserved の設定の両方が、キャッシュ サイズに比例して自動的にスケーリングされます。 たとえば、maxmemory-reserved が 6 GB のキャッシュで 3 GB に設定されていて、12 GB のキャッシュにスケーリングする場合、スケーリング中に設定が自動的に更新されて 6 GB になります。 スケールダウンすると、逆の処理が行われます。
PowerShell、CLI、または Rest API を使用してプログラムによってキャッシュをスケールアップまたはスケールダウンする場合、更新要求の一部としての maxmemory-reserved または maxfragmentationmemory-reserved は無視されます。 スケーリングの変更のみが受け入れられます。 これらのメモリ設定は、スケーリング操作の完了後に更新できます。
スケーリングとメモリの詳細については、レベルに応じて、次のいずれかを参照してください:
Note
プログラムによってキャッシュをスケールアップまたはスケールダウンする場合、更新要求の一部としての maxmemory-reserved または maxfragmentationmemory-reserved は無視されます。 スケーリングの変更のみが受け入れられます。 これらのメモリ設定は、スケーリング操作の完了後に更新できます。
データを最小限に抑えることで、スケーリングをより迅速に完了できます
キャッシュ内のデータを保持することが要件ではない場合は、スケーリングの前にデータをフラッシュすることを検討してください。 キャッシュをフラッシュすると、スケーリング操作がより迅速に完了し、新しい容量をより早く使用できるようになります。 詳しくは、フラッシュ操作の開始方法に関する記事をご覧ください。