Scaling
負荷時のスケーリング
負荷時にキャッシュをスケーリングする場合は、システムの応答性を向上させるために 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 は無視されます。 スケーリングの変更のみが受け入れられます。 これらのメモリ設定は、スケーリング操作の完了後に更新できます。
データを最小限に抑えることで、スケーリングをより迅速に完了できます
キャッシュ内のデータを保持することが要件ではない場合は、スケーリングの前にデータをフラッシュすることを検討してください。 キャッシュをフラッシュすると、スケーリング操作がより迅速に完了し、新しい容量をより早く使用できるようになります。 「フラッシュ操作の開始方法」で詳細を参照してください。
Enterprise レベルのキャッシュのスケーリング
Enterprise レベルと Enterprise Flash レベルは、オープンソース Redis ではなく Redis Enterprise 上に構築されているため、スケーリングのベスト プラクティスにはいくつかの違いがあります。 詳細については、Enterprise レベルと Enterprise Flash レベルのベスト プラクティスに関する記事をご覧ください。