移行する前に、効果的に計画できるように、Azure Cache for Redis と Azure Managed Redis の主な違いを確認してください。
Important
Redis 移行エージェント スキルを使用すると、移行関連の質問に回答し、環境に合わせた移行計画を準備できます。 詳細については、「 Redis 移行エージェントスキル」を参照してください。
Azure Managed Redis のパフォーマンスが高い理由
Azure Managed Redis は Redis Enterprise ソフトウェア スタック上に構築されており、Basic、Standard、Premium レベルで使用されるオープンソース Redis よりもパフォーマンスが大幅に向上します。 Redis Enterprise では、1 秒あたりの操作数を増やし、待機時間を短縮し、基になるハードウェアをより効率的に使用できるマルチスレッド アーキテクチャを使用します。 つまり、同じ量のメモリとコンピューティングに対して、Azure Managed Redis は同等の Basic、Standard、または Premium レベルのキャッシュと比較して、大幅に高いスループットを提供できます。
さらに、Azure Managed Redis では、Basic、Standard、または Premium レベルでは使用できない Redis モジュール (RediSearch、RedisJSON、RedisBloom など) を介した高度なデータ構造がサポートされています。 アーキテクチャの詳細については、 Azure Managed Redis のアーキテクチャに関するページを参照してください。
主な機能と機能の違い
Basic、Standard、または Premium から Azure Managed Redis に移行する場合に注意する必要がある重要な違いを次に示します。
SKU の構造。 Azure Managed Redis は、Azure Cache for Redis とは異なる方法で SKU を整理します。 階層によって機能が異なる階層ベースの SKU (Basic、Standard、Premium) の代わりに、Azure Managed Redis SKU は 、メモリ サイズ と パフォーマンスレベル (バランス、メモリ最適化、コンピューティング最適化) の 2 つのディメンションに基づいています。 すべての高可用性とディザスター リカバリー (HADR) 機能 (ゾーン冗長性、データ永続化、geo レプリケーション、インポート/エクスポートなど) は、すべてのサイズとパフォーマンス レベルで利用できます。 これらの機能にアクセスするためだけに、より高いレベルの SKU を選択する必要はなくなりました。
高可用性と非高可用性。 Azure Managed Redis には、高可用性の有無に関係なくデプロイするオプションがあります。 非 HA オプションは、コストを削減する非運用環境および開発/テスト ワークロード向けに設計されています。 HA 以外のインスタンスでは SLA が提供されないため、メンテナンス中にデータが失われる可能性があります。 これに対し、Basic レベル、Standard レベル、Premium レベルでは、この柔軟性は提供されません。Basic には HA はありませんが、Standard と Premium には常に含まれます。
クラスタ リング。 Azure Managed Redis は既定でクラスター化され、OSS クラスタリングと Enterprise クラスタリングの 2 つのクラスタリング ポリシーが提供されます。 最適なパフォーマンスを得るための OSS クラスタリングを選択することをお勧めします。 現在、非クラスター化 Basic キャッシュまたは Standard キャッシュを使用している場合、Redis クライアント ライブラリの構成では、クラスター化されたインスタンスを操作するために変更が必要になる場合があります (たとえば、クラスター対応クライアント ライブラリを使用した
MOVEDリダイレクトの処理)。 アプリケーションで非クラスター化インスタンスが絶対に必要な場合、Azure Managed Redis は最大 25 GB のキャッシュに非クラスター化モードを提供します。ネットワークの分離。 Azure Managed Redis では、仮想ネットワークの挿入と IP ベースのファイアウォール規則の構成はサポートされていません。 既存の Azure Cache for Redis インスタンスがネットワーク分離のために仮想ネットワークインジェクションを使用している場合は、新しい Azure Managed Redis インスタンスで Azure Private Link を使用するように切り替える必要があります。
スケーリング。 Azure Managed Redis では、メモリ サイズとパフォーマンスレベルの変更がサポートされています。
Microsoft Entra ID。 どちらのサービスも、Microsoft Entra ID 認証をサポートしています。 ただし、Azure Managed Redis では現在、Microsoft Entra ID RBAC はサポートされていません。
スケジュールされた更新。 Azure Cache for Redis では、Redis エンジンの更新プログラムのスケジュールされた更新ウィンドウの構成がサポートされています。 Azure Managed Redis では、現在プレビュー段階のスケジュールされた更新プログラムがサポートされています。
TLS と TLS 以外のポートのサポート。 Azure Cache for Redis Basic、Standard、Premium レベルでは、同じキャッシュ インスタンスで TLS (ポート 6380) とプレーンテキスト (ポート 6379) の両方の接続を同時にサポートできるため、異なるアプリケーションがどちらのモードでも接続できます。 Azure Managed Redis では、キャッシュは一度に 1 つのモード (TLS または TLS 以外) のみをサポートします。 キャッシュの作成時にモードを選択したら、そのキャッシュに接続するすべてのアプリケーションが同じモードを使用する必要があります。
ゾーンの冗長性。 高可用性が有効になっており、リージョンが複数の可用性ゾーンをサポートしている場合、Azure Managed Redis は既定でゾーン冗長です。 これに対し、ゾーン冗長は Premium レベル (および Standard のプレビュー) でのみ使用できます。
データベース。 Basic レベル、Standard レベル、Premium レベルでは、複数の Redis データベースがサポートされます (既定では最大 16 個、Premium では最大 64 個まで構成可能)。 Azure Managed Redis では、1 つのデータベース (データベース 0) のみがサポートされます。 アプリケーションで複数のデータベースを使用する場合は、データ モデルをリファクタリングして 1 つのデータベースを使用するか、キー プレフィックスを使用してデータを論理的に分離してから移行する必要があります。
ジオレプリケーション。 Azure Managed Redis ではアクティブ geo レプリケーションがサポートされています。これにより、異なるリージョンのリンクされたキャッシュ間で読み取りと書き込みの操作が可能になります。 Premium レベルでは、セカンダリ キャッシュが読み取り専用であるパッシブ geo レプリケーションのみがサポートされます。 Azure Cache for Redis とは異なり、Azure Managed Redis は明示的なフェールオーバー コマンドをサポートしていません。 代わりに、いずれかのリージョンがダウンしているのを検出した場合、アプリケーションは別の geo レプリケートされた Azure Managed Redis インスタンスに切り替える必要があります。
データの永続化。 Azure Managed Redis では、すべての SKU でデータ永続化がサポートされています。 Azure Cache for Redis では、永続化は Premium レベルでのみ使用できます。
Redis モジュール。 Azure Managed Redis では、RediSearch、RedisJSON、RedisBloom、RedisTimeSeries などの Redis モジュールがサポートされています。 これらのモジュールは、Basic、Standard、または Premium レベルでは使用できません。
インポートとエクスポート。 Azure Managed Redis では、すべての SKU で RDB のインポートとエクスポートがサポートされています。 Azure Cache for Redis では、この機能は Premium レベルでのみ使用できます。
キースペース通知。 キースペース通知は Azure Cache for Redis でサポートされていますが、現在、Azure Managed Redis では使用できません。
再起動します。 Azure Cache for Redis では、キャッシュ ノードの手動再起動がサポートされています。 この操作は、ノード操作を自動的に管理する Azure Managed Redis では使用できません。 Reboot を使用してキャッシュからデータをフラッシュする場合、Azure Managed Redis は管理操作として Flush を提供します。 アプリケーションの回復性をテストするためのメンテナンス イベントをシミュレートするための Azure Managed Redis API がロードマップに掲載されています。
クライアント アプリケーションの主な違い
アプリケーションの更新を計画するときは、次の違いを確認してください。
| 機能の説明 | Azure Cache for Redis | Azure マネージド再配布 |
|---|---|---|
| DNS サフィックス (Azure パブリック クラウド用) | .redis.cache.windows.net |
<region>.redis.azure.net |
| TLS ポート | 6380 | 10000 |
| TLS 以外のポート | 6379 | 10000 |
| 個々のノードの TLS ポート | 13XXX | 85xx |
| 個々のノードの非 TLS ポート | 15XXX | 85xx |
| クラスタリングのサポート | OSS クラスタリングのみ | OSS とエンタープライズ クラスタリング |
| 非クラスター化/スタンドアロン | はい (Basic、Standard、Premium 最大 120 GB) | はい (非クラスター化モード、最大 25 GB のみ) |
| Redis のバージョン | 6 | 7.4 |
| 対応している TLS のバージョン | 1.2 および 1.3 | 1.2 および 1.3 |
適切な Azure Managed Redis のサイズと SKU を選択する
適切な Azure Managed Redis SKU を選択するには、適切な メモリ サイズ を選択してから、適切な パフォーマンス レベルを選択する 2 つの手順が必要です。
手順 A: 適切なメモリ サイズを選択する
- 現在のキャッシュのメモリ サイズを特定します。 Azure portal に移動し、Basic、Standard、または Premium のキャッシュを開き、[ 概要 ] ページのメモリ サイズをメモします (例: C3 = 13 GB、P2 = 13 GB)。
注
Premium クラスター化キャッシュの場合: シャード化されたクラスターの場合は、すべてのシャードで同等の合計メモリを持つサイズを選択します。
Azure Managed Redis で同様のサイズの SKU を見つけます。 同じ量以上の使用可能なメモリを提供する Azure Managed Redis SKU を探します。 サイズを比較する場合、Azure Managed Redis はシステム操作とオーバーヘッドのために約 20% のメモリを予約することに注意してください。 サイズを選択するときにこの予約を考慮します。たとえば、B10/M10/X10 SKU では、合計メモリが 12 GB ですが、予約後のデータに対して約 9.6 GB の使用可能なメモリが提供されます。
実際のメモリ使用量に基づいて最適化します。 キャッシュの名目上のサイズと一致させるのではなく、Azure Monitor の既存のキャッシュにおける 使用済みメモリ メトリックを確認してください。 過去 1 か月間のメモリ使用量のピークを調べて、適切な SKU を特定します。 実際のメモリ使用量がキャッシュ サイズを大きく下回っている場合は、より小規模でコスト効率の高い Azure Managed Redis SKU を選択できる場合があります。
手順 B: 適切なパフォーマンス レベルを選択する
Azure Managed Redis には、バランス、メモリ最適化、コンピューティング最適化の 3 つのパフォーマンス レベルが用意されています。 ワークロードの特性に基づいて選択します。
- バランス。 どこから始めればよいか分からない場合の良いスタート地点です。 メモリとコンピューティングの正常な組み合わせを提供します。
- メモリ最適化 - ワークロードがメモリを集中的に消費し、CPU より前にメモリ不足になる可能性が高い場合は、これを選択します。
- コンピューティング最適化 - ワークロードがスループットを集中的に使用する場合や待機時間が影響を受けやすい場合に選択します。
詳細については、「 適切なレベルの選択」を参照してください。
その他の考慮事項
- Basic レベルの移行の高可用性を無効にします。 Basic キャッシュ (レプリケーションまたは SLA がない) から移行する場合は、新しい Azure Managed Redis インスタンスの高可用性を無効にします。 これにより、コストが半減し、開発/テスト ワークロードに対して同等のセットアップが提供されます。