この記事では、移行パスの詳細な手順について説明します。 勤務時間外での移行を強くお勧めします。これは、通常のメンテナンス中と同様に短時間の接続途絶が発生するためです。
Important
Redis 移行エージェント スキルを使用すると、移行関連の質問に回答し、環境に合わせた移行計画を準備できます。 詳細については、「 Redis 移行エージェントスキル」を参照してください。
手順 1: デプロイ スクリプトを更新し、Managed Redis インスタンスAzure新しく作成する
- 適切なAzure Managed Redis SKU を特定したら、デプロイ スクリプト (ARM テンプレート、Bicep ファイル、Terraform 構成など) を更新して、Azure Cache for Redisではなく、Azure Managed Redis をプロビジョニングします。
- SKU マッピング テーブルを使用して、適切なサイズ (既存のキャッシュと同じサイズまたは大きいサイズ) とパフォーマンス レベルを選択します。
- Quickstart: Azure Managed Redis インスタンスの作成に従ってインスタンスを作成します。
ヒント
ワークロードがメモリ集中型かコンピューティング集中型か不明な場合は、 バランス型 のパフォーマンス レベルから始めます。
手順 2: データを移行する
ダウンタイムとデータ損失に対する許容範囲に基づいて、データ移行戦略を選択します。
注
アプリケーションがデータ損失を許容できる場合、またはデータ ソースからキャッシュをリハイドレートできる場合 (たとえば、ルックアサイド キャッシュ パターン)、この手順をスキップして 、手順 3 に直接進むことができます。
RDB ファイルを使用したデータのエクスポートとインポート
Premium レベルでのみサポートされます。 データの特定の時点のスナップショットを提供します。
- 長所： シンプルで、任意の Redis キャッシュと互換性があります。
- 短所： スナップショットの作成後に書き込まれたデータはキャプチャされません。
ステップ:
- export 命令または PowerShell Export コマンドレットを使用して、既存のAzure Cache for Redis インスタンスから RDB ファイルをエクスポートします。
- インポート手順または PowerShell Import コマンドレットを使用して、新しい Azure Managed Redis インスタンスに RDB ファイルをインポートします。
- 「手順 3: アプリケーションを更新する」に進みます。
デュアルライト戦略
データ損失がゼロで、2 つのキャッシュの実行を一時的に許容できる場合に最適です。
- 長所： データ損失なし、ダウンタイムなし、中断のない操作。
- 短所： 2 つのキャッシュを長時間実行する必要があります。
ステップ:
- 既存のキャッシュと新しい Azure Managed Redis インスタンスの両方に書き込むようアプリケーション コードを変更します。
- 新しいインスタンスが十分に準備されるまで、既存のキャッシュからデータの読み取りを続行します。
- 新しいインスタンスからのみ読み書きするようにアプリケーション コードを更新します。
- 「手順 3: アプリケーションを更新する」に進みます。
プログラムによる移行
RIOT には、コンテンツを Enterprise から Azure Managed Redis に移行する方法が用意されています。 詳細については、「Data Migration with RIOT-X for Azure Managed Redis」を参照してください。
- 長所： フル コントロール、カスタマイズ可能。
- 短所： 開発作業が必要です。
ステップ:
- 既存のキャッシュと同じリージョンに VM を作成します。 データセットが大きい場合は、コピー時間を短縮する強力な VM を選択します。
- 新しいキャッシュからデータをフラッシュして、空であることを確認します。 ソース キャッシュをフラッシュしないでください。
- ソース キャッシュから新しい Azure Managed Redis インスタンスにデータをコピーします。
- 「手順 3: アプリケーションを更新する」に進みます。
手順 3: アプリケーションを更新する
新しい Azure Managed Redis インスタンスを指すアプリケーションの接続構成を更新します。 少なくとも、以下を更新する必要があります。
-
ホスト名: DNS サフィックスが
.redis.cache.windows.netから<region>.redis.azure.netに変更されます。 -
ポート: TLS ポートが
6380から10000に変更されます。 - Access キー: 新しいAzure Managed Redis インスタンスのアクセス キーを使用します。
Important
アクセス キーではなく、Microsoft Entra ID認証に切り替えることを検討してください。 Microsoft Entra IDでは、セキュリティが強化されており、推奨される認証方法です。
注
プライベート エンドポイントを介して既存のキャッシュに接続する場合は、新しい Azure Managed Redis インスタンスが、同様のネットワークセットアップを使用して、アプリケーションと同じ仮想ネットワークにピアリングされていることを確認します。
Azure Cache for RedisとAzure Managed Redis には互換性があるため、ほとんどのシナリオで接続構成以外のアプリケーション コードの変更は必要ありません。
手順 4: 検証と使用停止
- 新しい Azure Managed Redis インスタンスでアプリケーションが正しく動作することを確認します。
- 予期される動作、パフォーマンス、およびエラー率を新しいキャッシュで監視します。
- 新しいインスタンスが期待どおりに動作していることを確認したら、古いAzure Cache for Redis インスタンスを削除します。