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

[アーティクル]
11/19/2024

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

Note

Azure Managed Redis の各レベルの機能は実質的に同じであるため、スケーリングは通常、メモリとパフォーマンスの特性を変更するためにのみ使用されます。

重要

現時点では、より大きなメモリサイズまたはより高いパフォーマンスレベルへのスケールアップのみがサポートされています。メモリサイズのスケールダウンも、より低いパフォーマンスレベルへのスケールダウンもまだサポートされていません。

スケールのタイプ

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

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

パフォーマンスレベル

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

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

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

1 つのレベルでは、メモリ内とディスク上の両方にデータを格納します:

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

レベルと 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 を使用したパフォーマンステストに関するページを参照してください。

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

Note

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

Azure Managed Redis のスケーリングの前提条件と制限事項

メモリ最適化、バランス、コンピューティング最適化の各レベルからフラッシュ最適化レベルにスケーリングすることはできません。その逆のこともできません。
vCPU の数が少ない SKU にスケールダウンすることはできません。 (レベル間またはレベル内で。)
vCPU の数が同じかそれ以上の場合であっても、より小さなメモリサイズにスケールダウンすることはできません。
場合によっては、スケーリング時に、Redis インスタンスの基になる IP アドレスが変更される場合があります。インスタンスの DNS レコードが変わり、ほとんどのアプリケーションに対して透過的になります。ただし、IP アドレスを利用してキャッシュへの接続を構成するか、キャッシュへのトラフィックを許可する NSG またはファイアウォールを構成する場合、DNS レコードの更新後、アプリケーションで接続に問題が発生することがあります。
geo レプリケーショングループ内のインスタンスのスケーリングには、さらにいくつかの制限があります。詳細については、「geo レプリケーションにスケーリング制限はありますか」を参照してください。

規模の設定方法

ヒント

メモリサイズとパフォーマンスレベルの両方を 1 回の操作で変更できます。

Azure Portal を使用したスケール

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

重要

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

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

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

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku ComputeOptimized_X20

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

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

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

スケーリングに関する FAQ

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

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

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

常に、同じメモリサイズでより高いパフォーマンスレベルにスケーリングすることも、同じパフォーマンスレベル内でより大きなメモリサイズにスケーリングすることもできます。より低いパフォーマンスレベルまたはより小さいメモリサイズにスケーリングする場合は、「Azure Managed Redis のスケーリングの前提条件と制限事項」を参照してください。

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

いいえ、スケーリング処理中にキャッシュ名やキーが変更されることはありません。

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

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

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

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

高可用性モードが有効になっている場合、スケーリング操作中にはすべてのデータが保持されます。
より小さなメモリレベルにスケールダウンする場合は、キャッシュのスケールダウン時にデータサイズが、そのより小さな新しいサイズを超えると、データが失われる可能性があります。スケールダウンのときにデータが失われた場合、 allkeys-lru 削除ポリシーを使用してキーが削除されます。
高可用性モードが無効になっている場合は、すべてのデータが失われ、スケーリング操作中にキャッシュが使用できなくなります。

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

高可用性モードが有効になっている 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 の価格。

OSS と Enterprise クラスターポリシーの違いは何ですか?

OSS クラスターポリシーは、コミュニティエディション Redis で使用されるクラスタリングアプローチと同じです。通常、OSS クラスターポリシーの方がパフォーマンスは高くなります。 Enterprise クラスターポリシーでは、クラスタリングを実装して、それが非クラスター化 Redis インスタンスとしてクライアントに表示されるようにします。この方法を使用するとパフォーマンスが低下する可能性がありますが、クライアントの互換性の問題を防ぐことができます。現在、実行中のインスタンス上でクラスターポリシーを切り替えることはできません。詳細については、クラスターポリシーに関するページを参照してください。

次のステップ

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