Azure Managed Redis インスタンスのスケーリング (プレビュー)

2025-05-20
適用対象: ✅ Azure Managed Redis

Azure Managed Redis には、キャッシュサイズとパフォーマンスの選択に柔軟性を提供するさまざまな SKU とレベルのオファリングがあります。より大きなメモリサイズにスケーリング (プレビュー) したり、コンピューティングパフォーマンスを向上させるレベルに変更したりできます。また、より小さいレベルまたはより適切なレベルにスケールダウンすることもできます。このアーティクルでは、Azure Portal と、Azure PowerShell や Azure CLI などのツールを使用して、キャッシュをスケーリングする方法を説明します。

注

Azure Managed Redis の各レベルにはほぼ同じ機能があるため、スケーリングは通常、メモリとパフォーマンスの特性を変更するためにのみ使用されます。スケーリングは現在パブリックプレビュー段階です。

スケールのタイプ

Azure Managed Redis では、次の 2 つのディメンションでスケーリングをサポートしています。

メモリ メモリを増やすと Redis インスタンスのサイズが増え、より多くのデータを格納できます。メモリを減らすときは、現在のメモリ使用量が、使用する新しいメモリサイズよりも小さいことを確認する必要があります。
vCPU Azure Managed Redis には、3 つのレベル ("メモリ最適化"、"バランス"、"コンピューティング最適化") が用意されていて、メモリの各レベルに対応して vCPU の数が増加します。より多くの vCPU を備えたレベルにスケーリングすると、メモリを増やさなくても、インスタンスのパフォーマンスは向上します。 1 つの vCPU のみを使用する Azure Cache for Redis の Basic、Standard、Premium レベルとは異なり、Azure Managed Redis では Redis Enterprise スタックが使用されます。 Redis Enterprise スタックでは複数の vCPU を使用できます。つまり、Redis インスタンスで使用される vCPU の数は、スループットと待機時間のパフォーマンスと直接関連しています。

パフォーマンスレベル

Azure Managed Redis には 4 つのレベルが用意されており、それぞれパフォーマンス特性と価格レベルが異なります。

メモリ内データには、次の 3 つのレベルがあります。

メモリ最適化 - 高いメモリ対 vCPU 比 (8:1) を必要とするが、最高のスループットパフォーマンスを必要としないメモリ集中型のユースケースに最適です。処理能力やスループットが低く必要なシナリオでは価格が低く、開発環境やテスト環境に最適です。
バランス (メモリ + コンピューティング) - バランスの取れたメモリ対 vCPU (4:1) 比率を提供するため、標準ワークロードに最適です。メモリとコンピューティングリソースの適切なバランスを実現します。
コンピューティング最適化 - メモリ対 vCPU (2:1) の比率が低く、最大スループットを必要とするパフォーマンス集中型ワークロード向けに設計されています。最高のパフォーマンスを必要とするアプリケーションに最適です。

1 つの層には、メモリ内とディスク上の両方のデータが格納されます。

フラッシュ最適化 (プレビュー) - Redis クラスターで、アクセス頻度の低いデータをメモリ (RAM) から NVMe ストレージに自動的に移動できるようにします。これによりパフォーマンスは低下しますが、大規模なデータセットを使用したキャッシュのコスト効率の高いスケーリングが可能になります。

Von Bedeutung

120 GB を超えるストレージを使用するすべてのメモリ内層は、メモリ最適化 M150 以上、バランス B150 以上、コンピューティング最適化 X150 以上を含めて、パブリックプレビュー段階にあります。これらのレベル以上はすべてパブリックプレビュー段階です。

フラッシュ最適化レベルはすべてパブリックプレビュー段階です。

レベルと SKU の概要

Azure Managed Redis の SKU とレベルごとに、メモリと vCPU のさまざまな構成を示す表。

パフォーマンス (スループットと待機時間)

パフォーマンスベンチマークについて、また、各 SKU とレベルのパフォーマンスを測定する方法の詳細については、Azure Managed Redis を使用したパフォーマンステストに関するページを参照してください。

スケーリングするタイミング

Azure Cache for Redis の監視機能を使用すれば、ご利用のキャッシュの正常性とパフォーマンスを監視できます。その情報を使用して、キャッシュのスケーリングが必要である場合を判断します。

次のメトリックを監視して、スケーリングの必要性が判断できます。

CPU
- CPU の使用率が高いということは、Redis サーバーがすべてのクライアントからの要求に対応できるわけではないことを意味します。より多くの vCPU にスケーリングすると、複数の Redis プロセスに要求を分散できます。スケーリングは、TLS 暗号化/暗号化解除と接続/切断を配布し、TLS を使用してキャッシュインスタンスを高速化するのにも役立ちます。
メモリ使用量
- メモリ使用量が多い場合は、データサイズが現在のキャッシュサイズに対して大きすぎるかことを示します。メモリがより大きいキャッシュサイズにスケーリングを検討してください。メモリを減らすときは、現在のキャッシュのメモリ使用量が、使用する新しいメモリサイズよりも小さいことを確認する必要があります。大きなデータセットを小さなキャッシュサイズに配置することはできません。
クライアント接続
- 各キャッシュサイズには、サポートできるクライアント接続の数に制限があります。ご利用のクライアント接続がキャッシュサイズの制限に近い場合は、より大きなメモリサイズまたはより高いパフォーマンスレベルにスケーリングすることを検討してください。
- キャッシュサイズ別の接続制限の詳細については、Azure Managed Redis を使用したパフォーマンステストに関するページを参照してください。
ネットワーク帯域幅
- Redis サーバーが使用可能な帯域幅を超えると、サーバーがクライアントに十分な速度でデータをプッシュできないので、クライアントの要求がタイムアウトする可能性があります。サーバー側の帯域幅がどれだけ使用されているかを把握するには、"キャッシュの読み取り" および "キャッシュの書き込み" メトリックを確認します。 Redis サーバーが使用可能なネットワーク帯域幅を超える場合は、より高いパフォーマンスレベルまたはより大きなキャッシュサイズにスケーリングすることを検討してください。
- どのクラスターポリシーを選択するかは、使用可能なネットワーク帯域幅に影響します。一般に、OSS クラスターポリシーのネットワーク帯域幅は、Enterprise クラスターポリシーよりも高くなっています。詳細については、クラスターポリシーに関するページを参照してください
- キャッシュサイズ別のネットワークで使用可能な帯域幅の詳細については、Azure Managed Redis を使用したパフォーマンステストに関するページを参照してください。

使用するキャッシュの価格レベルを決定する方法の詳細については、「最適なサービスレベルを選択する」を参照してください。

スケーリングプロセスを最適化する方法の詳細については、スケーリングガイドのベストプラクティスに関するページを参照してください

Azure Managed Redis のスケーリングの制限事項

メモリ最適化、バランス、コンピューティング最適化の各レベルからフラッシュ最適化レベルにスケーリングすることはできません。その逆のこともできません。
Redis インスタンスのメモリを減らす場合、Redis インスタンスの現在のメモリ使用量は、意図した新しいメモリサイズよりも小さくする必要があります。詳細については、「より小さなメモリサイズにスケーリングした場合のデータの動作」を参照してください。
Redis インスタンスのメモリまたは vCPU を減らすときは、現在のインスタンスの構成と互換性のある vCPU とシャード構成を持つ SKU にのみスケーリングできます。
場合によっては、スケーリング時に、Redis インスタンスの基になる IP アドレスが変更される場合があります。インスタンスの DNS レコードが変わり、ほとんどのアプリケーションに対して透過的になります。ただし、IP アドレスを使用して Redis インスタンスへの接続を構成したり、NSG を構成したり、Redis インスタンスへのトラフィックを許可するファイアウォールを構成したりすると、DNS レコードの更新後にアプリケーションの接続に問題が発生する可能性があります。
geo レプリケーショングループ内のインスタンスのスケーリングには、さらにいくつかの制限があります。詳細については、「geo レプリケーションにスケーリング制限はありますか」を参照してください。
スケールダウンする場合は、特定のレベルにのみスケールできます。詳細については、「小さい SKU のサブセットにのみスケールダウンできる理由」を参照してください。

スケーリング方法 (プレビュー)

このセクションでは、Azure Managed Redis Cache をスケーリングする方法について説明します。

Azure Portal を使用したスケール

キャッシュをスケーリングするには、Azure portal でキャッシュを参照し、リソースメニューの スケール をクリックします。
vCPU をスケーリングするには、別の キャッシュの種類 を選択し、[ 保存] を選択します。

Von Bedeutung

スケールできない SKU を選択した場合、[ 保存] オプションは無効になります。許可されるスケーリングオプションの詳細については、「 Azure Managed Redis のスケーリングの制限事項」セクションを参照してください。
キャッシュを新しいレベルにスケーリングしている間、 [Redis Cache のスケールを設定しています] という通知が表示されます。
スケーリングが完了すると、[リソース] メニューの [概要] セクションを表示すると、状態が [スケーリング] から [実行中] に変わります。

PowerShell を使用したスケーリング

PowerShell では、Update-AzRedisEnterpriseCache コマンドレットを使用して、Azure Managed Redis インスタンスをスケーリングできます。 Sku プロパティを変更することで、必要なレベルおよび SKU を選択できます。次の例では、myCache という名前のキャッシュを、Compute Optimized X20 (24 GB) インスタンスにスケーリングする方法を示しています。

   Update-AzRedisEnterpriseCache -ResourceGroupName <your-group> -Name <your-cache-name> -Sku <sku-name>

Azure CLI を使用したスケーリング

Azure CLI を使用して Azure Managed Redis インスタンスをスケーリングするには、az redisenterprise update コマンドを呼び出します。 sku プロパティを変更することで、必要なレベルおよび SKU を選択できます。次の例では、myCache という名前のキャッシュを、Compute Optimized X20 (24 GB) インスタンスにスケーリングする方法を示しています。

az redisenterprise update --cluster-name <your-cache-name> --resource-group <your-resource-group> --sku <name-of-sku>

スケーリングに関する FAQ

次の一覧は、Azure Managed Redis のスケーリングに関するよく寄せられる質問への回答です。

レベル内またはレベル間でスケーリングできますか?
より小さなメモリサイズにスケーリングすると、データはどうなりますか?
スケーリング後にキャッシュ名やアクセスキーを変更する必要はありますか
スケーリングはどのように処理されますか
スケーリング中にキャッシュからデータは失われますか?
スケーリング中にキャッシュを使用できますか?
geo レプリケーションにスケーリング制限はありますか
スケーリングにはどのくらいの時間がかかりますか
スケーリングが完了したことをどのようにして確認できますか
Azure Managed Redis ではクラスタリングを使用しますか?各 Azure Managed Redis SKU で使用されるシャードの数はいくつですか?
クラスターにはキーはどのように配布されるのですか
作成できる最大キャッシュサイズはどれくらいですか
小さい SKU のサブセットのみにスケールダウンできるのはなぜですか?

レベル内またはレベル間でスケーリングできますか?

常に、同じメモリサイズでより高いパフォーマンスレベルにスケーリングすることも、同じパフォーマンスレベル内でより大きなメモリサイズにスケーリングすることもできます。より低いパフォーマンスレベルまたは小さいメモリサイズにスケーリングする場合は、"listskusforscaling" REST API を実行して、スケーリングできる SKU の一覧を取得することをお勧めします。

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

より小さなメモリサイズにスケーリングすると、データはどうなりますか?

現在のメモリ使用量が目的の小さいメモリサイズより小さい場合にのみ、より小さなメモリサイズにスケーリングできます。現在のメモリ使用量が意図したサイズより大きい場合、スケーリング要求は失敗します。不要なキー値ペアを削除するか、フラッシュ操作を実行することで、現在のメモリ使用量を減らすことができます。

az redisenterprise database flush --cluster-name <your-redis-instance> --resource-group <your-resource-group>

スケーリング後にキャッシュ名やアクセスキーを変更する必要はありますか

いいえ。スケーリング操作中、キャッシュ名とアクセスキーは変更されません。

スケーリングはどのように処理されますか

Redis インスタンスをスケーリングすると、Redis クラスター内のいずれかのノードがシャットダウンされ、新しいサイズに再プロビジョニングされます。その後、データが転送され、もう一方のノードは再プロビジョニングの前に同様のフェールオーバーを実行します。これは、ファイルの部分置換の適用中に、またはいずれかのキャッシュノードの障害時に発生するプロセスに似ています。
より多くの vCPU を持つインスタンスにスケーリングすると、新しいシャードがプロビジョニングされ、Redis サーバークラスターに追加されます。その後、すべてのシャード間でデータが再シャードされます。

Azure Managed Redis でシャーディングを処理する方法の詳細については、シャーディングの構成に関する記事を参照してください。

スケーリング中にキャッシュからデータは失われますか?

高可用性モードが有効になっている場合、スケーリング操作中にはすべてのデータが保持されます。
より小さなメモリレベルにスケーリングする場合は、現在のメモリ使用量が意図した新しいメモリサイズよりも小さいことを確認する必要があります。現在のメモリ使用量が目的の SKU メモリサイズを超える場合は、Flush 操作を使用してデータをフラッシュするか、削除するキー値を手動で選択できます。

高可用性モードが無効になっている場合は、すべてのデータが失われ、スケーリング操作中にキャッシュが使用できなくなります。

スケーリング中にキャッシュを使用できますか?

高可用性モードが有効になっている Azure Managed Redis インスタンスは、スケーリング操作中も引き続き使用できます。ただし、これらのキャッシュのスケーリング中には、接続の中断が発生する可能性があります。こうした接続の中断は一般に短く、Redis クライアントは通常、即座に接続を再確立できます。
高可用性モードが無効になっている場合、Azure Managed Redis インスタンスはスケーリング操作中にオフラインになります。

geo レプリケーションにスケーリング制限はありますか

アクティブ geo レプリケーションが構成されている場合、geo レプリケーショングループ内にさまざまなキャッシュサイズを混在させることはできません。そのため、geo レプリケーショングループ内のキャッシュをスケーリングするには、さらにいくつかの手順が必要になります。手順については、「geo レプリケーショングループ内のインスタンスのスケーリング」を参照してください。

スケーリングにはどのくらいの時間がかかりますか

スケーリング時間はいくつかの要因によって異なります。ここでは、スケーリングにかかる時間に影響する要因について説明します。

データ量: 大量のデータがレプリケートされるまでに長い時間がかかります。
高書き込み要求: 書き込み数が多いほど、ノードまたはシャード間でデータがレプリケートされることを意味します。
高い CPU 使用率: CPU 使用率が高くなると、Redis サーバーがビジーになり、データの再分配を完了するのに利用できる CPU サイクルが制限されます。

一般に、データを含まないインスタンスをスケーリングする場合は、約 10 分かかります。

スケーリングが完了したことをどのようにして確認できますか

スケール処理の進捗は Azure Portal で確認できます。スケーリングが完了すると、[リソース] メニューの [概要] を表示すると、キャッシュの状態が [実行中] に変わります。

Azure Managed Redis ではクラスタリングを使用しますか?

Azure Cache for Redis とは異なり、Azure Managed Redis では、すべてのレベルと SKU にわたってクラスタリングを使用します。クラスタリングを使用すると、パフォーマンスを大幅に最適化できます。 Azure Managed Redis の各 SKU は、利用可能な vCPU の数に合わせて最適化されたシャード数に構成されます。シャードの数をユーザーが構成することはできません。

各 Azure Managed Redis SKU で使用されるシャードの数はいくつですか?

Azure Managed Redis は Redis Enterprise ソフトウェア上で実行されるため、シャードはコミュニティ Redis よりも高密度の構成で使用できます。各 SKU で使用されるシャードの具体的な数については、シャーディング構成に関するページを参照してください。

クラスターにはキーはどのように配布されるのですか

キー配布モデルのRedisごとに関するドキュメントによると、キースペースは 1,6384 スロットに分割されます。各キーはハッシュされ、クラスターのノード全体に配布される、これらのスロットのいずれかに割り当てられます。ハッシュタグを使用して同じシャードに複数のキーが配置されていることを確認するために、キーのどの部分をハッシュするかを構成することができます。

ハッシュタグのあるキー - キーの任意の部分を { と } で囲むと、キーのその部分のみが、キーのハッシュスロットを決定するためにハッシュされます。たとえば、{key}1、{key}2、{key}3 という 3 つのキーは、名前の key 部分のみがハッシュされるため、同じシャードに配置されます。キーのハッシュタグ仕様に関する完全なリストについては、「キーのハッシュタグ」を参照してください。
ハッシュタグのないキー - キー名全体がハッシュに使用されるので、キャッシュのシャードにわたって統計的に均等に配布されます。

最高のパフォーマンスとスループットを得るために、キーを均等に配布することをお勧めします。ハッシュタグのあるキーを使用する場合、キーが均等に配布されていることを確認するのはアプリケーションの責任です。

詳細については、「Keys distribution model (キー配布モデル)」、「Redis Cluster data sharding (Redis クラスターのデータシャーディング)」、および「Keys hash tags (キーのハッシュタグ)」を参照してください。

作成できる最大キャッシュサイズはどれくらいですか

使用できる最大キャッシュサイズは 4.5 TB であり、Flash Optimized A4500 インスタンスと呼ばれます。 Azure Cache for Redis の価格。

小さい SKU のサブセットのみにスケールダウンできるのはなぜですか?

シャードと vCPU の数との互換性を維持するために、特定の SKU のみにスケールダウンできます。 Redis インスタンスがスケールダウンできる SKU を確認するには、Azure portal のリソースメニューの [スケール] セクションで設定されている SKU の一覧を確認できます。次の CLI コマンドを実行することもできます。

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

スケーリングに関するベストプラクティス