Important
Azure Cache for Redis Enterprise の移行エージェント スキルを使用すると、移行関連の質問に回答し、環境に合わせた移行計画を準備できます。 詳細については、「 Redis Enterprise 移行エージェント スキル」を参照してください。
この記事では、両方の移行パスの手順について説明します。
勤務時間外での移行を強くお勧めします。これは、通常のメンテナンス中と同様に短時間の接続途絶が発生するためです。
ジオレプリケーションを使用しないキャッシュのセルフサービスによる移行
手順 1: デプロイ スクリプトを更新する
適切な Azure Managed Redis SKU を特定したら、デプロイ スクリプト (ARM テンプレート、Bicep ファイル、Terraform 構成など) を更新して、Azure Cache for Redis Enterprise ではなく Azure Managed Redis をプロビジョニングします。
手順 2: 新しい Azure Managed Redis インスタンスを作成する
前に特定した サイズとパフォーマンスレベル を使用して、「 クイック スタート: Azure Managed Redis インスタンスを作成する」に従ってインスタンスを作成します。
代わりに、Redis Enterprise インスタンスで list-skus-for-scaling コマンドを使用して、推奨される Azure Managed Redis インスタンスを決定できます。
az redisenterprise list-skus-for-scaling --resource-group rg --cluster-name clustername.region.redisenterprise.cache.azure.net
手順 3: データを移行する
ダウンタイムとデータ損失に対する許容範囲に基づいて、データ移行戦略を選択します。 アプリケーションがデータ損失を許容できる場合、またはキャッシュをデータ ソースからリハイドレートするメカニズムがある場合は、この手順をスキップして、「 手順 4: アプリケーションを更新する」に直接進むことができます。
Important
Azure Managed Redis は、システム操作とオーバーヘッドのために約 20% のメモリを予約します。 新しいインスタンスに適したメモリ サイズを選択するときに、この予約を考慮してください。 たとえば、ワークロードに 10 GB の使用可能なメモリが必要な場合は、合計メモリが 12.5 GB 以上の SKU を選択します。
RDB ファイルを使用したデータのエクスポートとインポート
データのポイントインタイム スナップショットを作成するのに最適です。
- 長所： データ スナップショットを保持し、簡単なプロセス。
- 短所： スナップショットの作成後に書き込まれたデータはキャプチャされません。
ステップ:
- 既存のエンタープライズ キャッシュから Azure Storage アカウントに RDB ファイルをエクスポートします。
- Azure Storage アカウントから新しい Azure Managed Redis インスタンスにデータをインポートします。
- 詳細な手順については、「 Azure Managed Redis でのデータのインポートとエクスポート」を参照してください。
デュアルライト戦略
データ損失がゼロで、2 つのキャッシュの実行を一時的に許容できる場合に最適です。
- 長所： データ損失なし、ダウンタイムなし、中断のない操作。
- 短所： 2 つのキャッシュを長時間実行する必要があります。
ステップ:
- 既存の Enterprise キャッシュと新しい Azure Managed Redis インスタンスの両方に書き込むようアプリケーションを変更します。
- 新しいインスタンスにデータが入力されている間、Enterprise キャッシュからの読み取りを続行します。
- 十分なデータ同期が完了したら、読み取りを Azure Managed Redis に切り替えます。
- 「手順 4: アプリケーションを更新する」に進みます。
RIOT を使用したプログラムによる移行
RIOT には、Enterprise から Azure Managed Redis にコンテンツを移行する方法が用意されています。 詳細については、「 Azure Managed Redis の RIOT-X を使用したデータ移行」を参照してください。
- 長所： フル コントロール、カスタマイズ可能。
- 短所： 開発作業が必要です。
手順 4: アプリケーションを更新する
新しい Azure Managed Redis インスタンスを指すアプリケーションの接続構成を更新します。 少なくとも、以下を更新する必要があります。
-
ホスト名: DNS サフィックスが
redisenterprise.cache.azure.netからredis.azure.netに変更されます。 - アクセス キー: 新しい Azure Managed Redis インスタンスのアクセス キーを使用します。
Important
アクセス キーの代わりに Microsoft Entra ID 認証に切り替えることを検討してください。 Microsoft Entra ID は、セキュリティが強化されており、推奨される認証方法です。
注
プライベート エンドポイントを介して既存の Enterprise インスタンスに接続する場合は、新しい Azure Managed Redis インスタンスが、同様のネットワーク設定でアプリケーションと同じ仮想ネットワークにピアリングされていることを確認します。
手順 5: 検証と使用停止
- 新しい Azure Managed Redis インスタンスでアプリケーションが正しく動作することを確認します。
- 予期される動作、パフォーマンス、およびエラー率を新しいキャッシュで監視します。
- 新しいインスタンスが期待どおりに動作していることを確認したら、古い Enterprise インスタンスを削除します。
ジオレプリケーションを使用したキャッシュのセルフサービスによる移行
Geo によってレプリケートされた Redis Enterprise キャッシュのセットを Azure Managed Redis に移行する場合は、次の手順を使用してください。
- Azure CLI:
list-skus-for-scalingのaz redisenterprise list-skus-for-scaling --resource-group --cluster-nameコマンドを使用して、適切な Azure Managed Redis SKU を特定します。 - geo レプリケーション グループ内のすべての Redis Enterprise キャッシュが同じ SKU とサイズであることを確認します。
- 新しい Azure Managed Redis インスタンスを作成し、作成時に、移行する Redis Enterprise インスタンスを含む geo レプリケーション グループに追加します。
- プライベート エンドポイントを使用する場合は、同じ仮想ネットワーク内の
*.redis.azure.net用に新しいプライベート DNS ゾーンをプロビジョニングし、この新しい Azure Managed Redis インスタンスの新しいプライベート エンドポイントを作成します。 - 新しい Azure Managed Redis インスタンスにアクセス可能であることを確認し、新しい Azure Managed Redis エンドポイントを含むようにアプリケーションを更新します。
- Azure Managed Redis インスタンスがすべてのデータセットをレプリケートしたら、geo レプリケート されたグループから 1 つの Redis Enterprise インスタンスを削除します。
- geo レプリケーション グループ内の残りの Redis Enterprise キャッシュごとに、上記の手順を繰り返します。
制限事項/コールアウト
- Azure Managed Redis インスタンスが Redis Enterprise インスタンスの既存の geo レプリケーション グループに追加されると、その geo レプリケーション グループに新しい Redis Enterprise インスタンスを追加することはできません。 Azure Managed Redis のみを追加し、Redis Enterprise インスタンスのみを削除できます。
- geo レプリケーションに Azure Managed Redis と Redis Enterprise インスタンスの組み合わせが含まれている場合、スケーリングはブロックされます。
- geo レプリケーション グループには 5 つの Redis インスタンスの制限があります。移行を容易にするために、Azure Managed Redis と Redis Enterprise の組み合わせを含む geo レプリケーション グループには最大 6 つの Redis インスタンスを許可します。
Important
最初に既存のアクセス キーを引き続き使用する場合でも、移行後に Microsoft Entra ID 認証に移行することをお勧めします。