amr-migration-skill

Azure Managed Redis 移行スキル

このスキルは、Azure Cache for Redis（ACR）の Basic／Standard／Premium ティアから Azure Managed Redis（AMR）への移行を支援します。ARM REST API による自動移行も含まれます。

📝 用語に関する注意

ユーザーは Azure Cache for Redis を OSS、ACR、またはティア名（Basic、Standard、Premium）で呼ぶことがあります。これらはすべて同じ製品を指します。ユーザーが移行について尋ねた場合、これらの用語を同じ意味として扱ってください。

⚠️ 対象範囲の制限：Enterprise ティアはサポート対象外です

このスキルは、Azure Cache for Redis Enterprise（ACRE）の移行には対応していません。ユーザーが Enterprise または Enterprise Flash ティアからの移行について尋ねた場合、これらには異なる移行方法があることを説明し、Microsoft サポートへの問い合わせ、または公式ドキュメントの参照を提案してください。

サポート対象の移行元ティア：Basic（C0-C6）、Standard（C0-C6）、Premium（P1-P5）

⚠️ AMR の用語：「シャード」は使用しないでください

AMR を説明する際に「シャード」という用語は使用しないでください。AMR ではシャーディングは内部で管理され、顧客には公開されないため、この概念は当てはまらず、混乱を招きます。この用語が当てはまるのは、ACR Premium のクラスター化キャッシュのみです。AMR について説明する際は、代わりにパフォーマンスティア（Balanced、Memory Optimized など）とサイズ（B10、M20 など）を使用してください。

---

エージェント向けガイダンス

⛔ 破壊的操作の確認（必須）

移行スクリプトを使用して Migrate または Cancel の操作を実行する前に、エージェントは必ず次のことを行ってください。

1. 移行元と移行先のリソース ID 全体をユーザーに表示する
2. 実行する操作を明確に伝える（例：「これにより、ACR から AMR への DNS 切り替え移行が開始されます」）
3. スクリプトを実行する前に、ask_user ツールを使用してユーザーに明示的な確認を求める
4. これらの操作について、自動的に確認したり、ユーザーが同意したとみなしたりしない

これは、ユーザーが依頼をどのように表現したかにかかわらず適用されます。ユーザーが「移行を進めて」と言った場合でも、実行前に対象となるリソース ID を明示して確認する必要があります。

bash スクリプトを実行するときは、エージェントがターミナルのプロンプトに応答できないため、必ず --yes を渡してください。ただし、最初に ask_user ツールを通じてユーザーの確認を得てからにしてください。

🔍 移行前の検証（必須）

Migrate を実行する前に、エージェントは必ず、同じ移行元と移行先のリソース ID を指定して Validate を実行し、その結果をユーザーに提示してください。検証でエラーが返された場合は、Migrate に進まないでください。警告が返された場合はその内容を説明し、-ForceMigrate $true（PowerShell）または --force-migrate（bash）を使用して続行するか、ユーザーに確認してください。

バージョン確認（手動のみ — ユーザーから依頼された場合に実行）

自動的に更新を確認しないでください。ユーザーが明示的に依頼した場合（例：「amr skill の更新を確認して」、「amr-migration-skill の新しいバージョンはありますか？」）に限り、バージョンを確認してください。

依頼された場合：

1. このスキルのルートディレクトリにあるローカルの VERSION ファイルを読み取ります。
2. 次の場所からリモートバージョンを取得します：https://raw.githubusercontent.com/AzureManagedRedis/amr-migration-skill/main/VERSION
3. リモートバージョンのほうが新しい場合は、ユーザーに次のように伝えます："AMR Migration Skill の新しいバージョンがあります（ローカル：X、最新：Y）。次の場所から更新してください：https://github.com/AzureManagedRedis/amr-migration-skill"
4. バージョンが一致する場合は、ユーザーに次のように伝えます："最新バージョンを使用しています（X）。"
5. 取得に失敗した場合は、確認に失敗したことを伝え、後でもう一度試すよう提案します。

スクリプト選択のためのプラットフォーム判定

ユーザーの OS を確認し、適切な移行スクリプトの種類を選択してください。

• Windows／PowerShell：.ps1 スクリプトを使用します（Azure CLI が必要です）
• Linux／macOS／WSL／Bash：.sh スクリプトを使用します（Azure CLI と jq が必要です）

OS が不明な場合は、bash スクリプトを優先してください。クロスプラットフォームで動作します。どちらのスクリプトも、ARM API 呼び出しに Azure CLI（az rest）を使用します。

ARM リソース ID の構築

通常、ユーザーからキャッシュ名、リソースグループ、サブスクリプションが提供されます。次のように完全な ARM リソース ID を構築してください。

• ACR のソース：/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Cache/Redis/<cacheName>
• AMR のターゲット：/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Cache/redisEnterprise/<cacheName>

ユーザーがキャッシュ名しか指定しない場合は、az redis show -n <name> -g <rg> --query id -o tsv を使って完全なリソース ID を取得してください。サブスクリプションまたは RG も不明な場合は、az redis list --query "[?name=='<name>'].{id:id, rg:resourceGroup}" -o table を使って確認してください。

SKU の推奨内容の検証

AMR の SKU をユーザーに推奨する前に、AMR SKU Specs に記載された有効な SKU の一覧と照合してください。このファイルに記載されていない SKU は絶対に推奨しないでください。理想的な容量が 2 つの SKU サイズの中間にある場合は、次に大きいサイズを推奨してください。

接続変更に関する注意

移行について説明する際は、アプリケーションの変更が必要となる以下の点を必ず伝えてください。

• TLS ポート：ACR は 6380 → AMR は 10000
• 非 TLS：ACR は 6379 → AMR は 10000（プレーンテキストモード。作成時に設定し、同時に有効にできるモードは 1 つのみです）
• DNS サフィックス：.redis.cache.windows.net → <region>.redis.azure.net
• Redis バージョン：6 → 7.4

DNS の切り替えを伴う自動移行をユーザーが利用する場合、古いホスト名は引き続き使用できますが、ポートの変更は必要です。

移行後の推奨事項：Microsoft Entra ID authentication をアクセスキーの代わりに使用することを提案してください。Entra ID の構成は自動的に移行されないため、新しい AMR インスタンスで設定する必要があります。

利用可能なリソース

重要：料金の検索とメトリックの取得には、必ず提供されているスクリプトを使用してください。独自の API 呼び出しやスクリプトを作成しないでください。提供済みのスクリプトは、ティア固有の計算ロジック（HA、シャード、MRPP）とメトリックの集計を適切に処理します。ユーザーが別の期間を指定しない限り、メトリックのデフォルト期間は 7 日間です。

ドキュメントへのアクセス

注：移行に関するガイダンスの大部分は、このスキルのローカル参照ファイルで確認できます。ローカルに記載されていない情報（最新のリリースノート、リージョンの利用可否、新機能など）を調べる場合にのみ、MCP サーバーを使用してください。

最新のドキュメントを取得するには、Microsoft Learn MCP サーバーを使用してください。

• MCP エンドポイント：https://learn.microsoft.com/api/mcp
• セットアップガイド：セットアップ手順（GitHub Copilot、Claude Desktop）については、MCP Server Configuration を参照してください。
• 主なドキュメントのパス：
  • /azure/redis/ - Azure Managed Redis ドキュメントのハブ
  • /azure/redis/overview - AMR の概要、主なシナリオ、ティア選択の出発点をまとめたページ
  • /azure/redis/architecture - AMR のアーキテクチャ、クラスタリングモデル、ポリシーに関するガイダンス
  • /azure/redis/migrate/migrate-overview - 「違いを理解する」「オプションを検討する」「実行を計画する」の各セクションに整理された移行ハブ

Azure CLI コマンドのリファレンス

Azure CLI Commands では、次の操作に利用できる az redis の実用的な例を紹介しています。

• サブスクリプションまたはリソースグループ内の ACR キャッシュを一覧表示する
• キャッシュの詳細（リージョン、SKU、シャード数、レプリカ）を抽出する
• 永続化と geo レプリケーションの設定を確認する

SKU マッピングのリファレンス

SKU Mapping Guide では、ガイドライン、ACR → AMR のマッピング表、選択基準、決定マトリックスを確認できます。AMR SKU の定義（M、B、X、Flash シリーズ）については、AMR SKU Specs を参照してください。

動的な価格の照会

候補 SKU を特定したら、月額費用の計算を含むリアルタイムの価格を取得します。

# Windows PowerShell
.\scripts\get_redis_price.ps1 -SKU M10 -Region westus2
.\scripts\get_redis_price.ps1 -SKU M10 -Region westus2 -NoHA
.\scripts\get_redis_price.ps1 -SKU C3 -Region westus2 -Tier Standard
.\scripts\get_redis_price.ps1 -SKU P2 -Region westus2 -Shards 3 -Replicas 2

# Linux/Mac bash
./scripts/get_redis_price.sh M10 westus2
./scripts/get_redis_price.sh P2 westus2 --shards 3

スクリプトのオプション：

• -NoHA / --no-ha - 非 HA デプロイ（AMR のみ。開発／テスト環境では 50％のコスト削減）
• -Shards N / --shards N - シャード数（ACR Premium のクラスター構成）
• -Replicas N / --replicas N - プライマリごとのレプリカ数（ACR Premium MRPP、既定値：1）
• -Currency X / --currency X - 通貨コード（既定値：USD）

対応 SKU：

• ACR：C0-C6（Basic／Standard - ティアの指定が必要）、P1-P5（Premium）
• AMR：M10-M2000、B0-B1000、X3-X700、A250-A4500

リソース：

• 価格ティアのルール - HA、クラスター構成、MRPP の計算ロジック
• Azure 料金計算ツール - 公式見積もり

機能比較

ACR（Basic／Standard／Premium）と AMR の機能の詳しい比較については、機能比較を参照してください。

廃止に関する FAQ

廃止日程、タイムライン、よくある移行に関する質問については、廃止に関する FAQを参照してください。

このスキルに関連する内容（ACR Basic／Standard／Premium）：

• 2026 年 4 月 1 日：新規顧客による作成をブロック
• 2026 年 10 月 1 日：既存顧客による作成をブロック
• 2028 年 9 月 30 日：廃止日（2028 年 10 月 1 日にインスタンスが無効化）

このスキルの対象外：

• Enterprise／Enterprise Flash の廃止（2027 年 3 月 31 日）— Microsoft サポートにお問い合わせください

移行の概要

以下を含む詳しい移行ガイダンスについては、移行の概要を参照してください。

• 移行戦略（新しいキャッシュ、RDB のエクスポート／インポート、デュアルライト、RIOT）
• 接続文字列の変更
• クラスター構成ポリシーとネットワーク分離に関する考慮事項

Infrastructure-as-Code（IaC）テンプレートの移行

ACR テンプレート（ARM、Bicep、Terraform）を AMR 形式に変換するには、以下のリファレンスドキュメントを使用してください。

• ACR テンプレート解析ガイド — ACR テンプレートから構成を読み取り、抽出する方法
• AMR テンプレート構造ガイド — AMR テンプレートの変換ルール、プロパティのマッピング、出力構造
• テンプレートの例 — 形式別に整理された変換前／変換後のテンプレートペア：
  • arm/ — ARM JSON の 6 つのシナリオ（basic、premium non-clustered、clustered、VNet、persistence、all-features）
  • arm-parameterized/ — パラメータファイルを分けた ARM JSON の 4 つのシナリオ
  • bicep/ — Bicep の 2 つのシナリオ（basic、premium clustered）
  • terraform/ — Terraform の 2 つのシナリオ（basic、premium clustered）

ワークフローの選択

ユーザーの意図に基づいて、適切なワークフローを選択してください。 2 つのワークフローは独立しているため、手順を混在させないでください。

ユーザーの意図	判断の手がかりとなるフレーズ	ワークフロー
稼働中のキャッシュを AMR に移行する	「キャッシュを移行」「AMR に移す」「SKU を選択」「メトリックを評価」「移行戦略」「トラフィックを切り替え」	移行ワークフロー（手順 1～4）
IaC テンプレートを AMR 形式に変換する	「テンプレートを変換」「Bicep の移行」「ARM から AMR」「Terraform」「IaC」「テンプレートの変換」「リージョンの構築」	IaC 移行ワークフロー（手順 1～8）
機能を比較する、または一般的な質問に回答する	「ACR と AMR の比較」「機能の互換性」「廃止日」「ベストプラクティス」	リファレンスドキュメントを使用して直接回答します。ワークフローは不要です

曖昧なリクエスト

ユーザーの意図が不明確な場合（例：「AMR への移行を手伝って」はどちらの意味にも取れます）、次のように尋ねてください。

「稼働中のキャッシュを移行（データ移行、SKU の選択、トラフィックの切り替え）したいですか、それとも Infrastructure-as-Code テンプレート（Bicep／ARM／Terraform）を AMR 形式に変換したいですか？ あるいは両方ですか？」

両方のワークフロー

両方が必要な場合（例：「IaC を含めてすべてを移行」）：

1. まず移行ワークフローを実行します。これにより、移行先の AMR SKU を決定し、メトリクスを使ってサイズを検証します
2. 次にIaC 移行ワークフローを実行します。ステップ 1 で選択した SKU を移行先として使用します

---

移行ワークフロー

ステップ 1：現在のキャッシュを評価する

既存の ACR キャッシュからメトリクスを収集し、SKU の選択に役立てます。

# Windows PowerShell
.\scripts\get_acr_metrics.ps1 -SubscriptionId <id> -ResourceGroup <rg> -CacheName <name>
.\scripts\get_acr_metrics.ps1 -SubscriptionId <id> -ResourceGroup <rg> -CacheName <name> -Days 7

# Linux/Mac bash
./scripts/get_acr_metrics.sh <subscriptionId> <resourceGroup> <cacheName>
./scripts/get_acr_metrics.sh <subscriptionId> <resourceGroup> <cacheName> 7

また、実際のメモリ予約量を取得して、実際に使用可能な容量を把握します（SKU マッピング表の既定値では約 20％を想定しています）。

az redis show -n <cache-name> -g <resource-group> -o json \
  --query "{maxfragmentationmemoryReserved: redisConfiguration.maxfragmentationmemoryReserved, maxmemoryReserved: redisConfiguration.maxmemoryReserved}"

どちらの値も MB 単位です。**実際の使用可能容量 = SKU 容量 −（maxmemoryReserved + maxfragmentationmemoryReserved）**です。サイズを決める際は、この値を正確な基準として使用してください。

必要条件：Azure CLI にログインしていること（az login）

代替手段：スクリプトが失敗する場合（テナントがロックされている、権限が不足している、CLI にアクセスできないなど）、ユーザーに Azure Portal のキャッシュにある Monitoring → Metrics ブレードから同じメトリクスを手動で取得するよう案内してください。

取得するメトリクス（それぞれのピーク値、P95 値、平均値）：

• 使用メモリ RSS（バイトおよび GB）
• サーバー負荷（％）
• 接続中のクライアント数
• ネットワーク帯域幅 — キャッシュの読み取りと書き込み（バイト/秒）

クラスター化されたキャッシュ：複数のシャードを持つ Premium キャッシュの場合、スクリプトはシャード数を自動的に検出し、すべてのシャードのメトリクスを集計します。メモリと帯域幅は合計（総容量）し、サーバー負荷と接続中のクライアント数はシャードごとの最大値（ボトルネック値）を報告します。シャードの集計が有効な場合は、出力のヘッダーに表示されます。

これらの値を次の用途に使用します。

1. 移行先 AMR SKU のサイズを決めます（使用可能メモリ ≥ 使用メモリのピーク値。エビクションポリシーがあれば、追加のバッファーは不要です）
2. ティアを選択します（サーバー負荷が高くメモリ使用量が少ない場合は、Compute Optimized X-series）
3. 接続数の上限が十分であることを確認します
4. P95 値を使って、継続的な負荷と一時的な急増を区別します

ゾーン固定の確認：ソースキャッシュでゾーン固定が使用されているかどうかも確認します。

az redis show -n <cache-name> -g <resource-group> -o json \
  --query "{zones: zones, zonalAllocationPolicy: properties.zonalAllocationPolicy}"

zones が設定され、zonalAllocationPolicy が UserDefined の場合、キャッシュはゾーン固定されており、顧客が選択した特定の可用性ゾーンにデプロイされています。AMR はゾーン固定をサポートしていないことをユーザーに警告してください。高可用性が有効な場合、AMR はリージョン内のすべての利用可能なゾーンに自動的にゾーン冗長でデプロイされますが、特定のゾーンに固定することはできません。他のリソース（レイテンシーを低減するために同じゾーンにある VM など）との近接性を確保するためにゾーン固定を使用していた場合、その保証は AMR には引き継がれないことをユーザーに伝えてください。

ステップ 2：移行先 AMR SKU を選択する

1. SKU マッピングガイドを参照します
2. ステップ 1 のメトリクスを使ってサイズを検証します
3. 候補となる SKU の料金を取得します。

   .\scripts\get_redis_price.ps1 -SKU M20 -Region westus2
   .\scripts\get_redis_price.ps1 -SKU B20 -Region westus2
   

ステップ 3：移行を計画する

1. 移行戦略を決定します（二重書き込み、スナップショットと復元など）
2. クラスタリングポリシー：ソースキャッシュの種類と移行先 AMR のサイズに基づいて選択します。ガイダンスについては移行の概要を、決定マトリックス全体についてはAMR テンプレートの構造 §6を参照してください。
3. ネットワーク分離：VNet インジェクションを使用している ACR キャッシュは、AMR が VNet インジェクションをサポートしていないため、AMR ではPrivate Linkに置き換える必要があります。切り替え前に Private Endpoint が構成されていることを確認してください。
4. ダウンタイムの可能性やデータ同期の要件を考慮して計画します
5. アプリケーションの接続文字列と構成を更新します

ステップ 4：移行を実行する

1. 移行先 AMR キャッシュを作成します
2. 適切な方法でデータを移行します
3. データの整合性を検証します
4. アプリケーションのトラフィックを新しいキャッシュに切り替えます

---

IaC 移行ワークフロー

8 ステップのワークフロー全体については、IaC 移行ワークフローを参照してください。

参照ドキュメントを基にした AI 主導の変換により、ACR テンプレート（ARM JSON、Bicep、Terraform）を AMR 形式に変換します。SKU のマッピング、価格の比較、機能ギャップの分析、顧客による確認ゲート、テンプレートの生成が含まれます。スクリプトは価格の照会にのみ使用されます。

---

自動移行（ARM REST API）

Azure では ARM REST API を介した ACR から AMR への自動移行パスが提供されており、DNS の切り替えが自動的に処理されるため、従来の OSS エンドポイントを使用しているクライアントは移行後も引き続き動作します。

重要：この機能は現在、パブリックプレビューです。一般提供（GA）までは、本番環境のワークロードに手動移行戦略（上記のステップ 1～4）を使用してください。

主な情報：

• サポート対象：Basic／Standard／Premium のすべての SKU。ただし、VNet が挿入されたキャッシュまたは Geo-Replicated キャッシュを除きます。Private Link とクラスター化されたキャッシュは移行できますが、データ移行の対象にはなりません
• ソースとターゲットは同じリージョンおよびサブスクリプションにある必要があります
• 移行対象：アクセスキー、OSS ホストエンドポイント（DNS 切り替え）、OSS ポート、キャッシュデータ（要求された場合）。Entra ID、永続化の構成、マネージド ID は移行されません
• ワークフロー：検証 → 移行 → 状態確認 → キャンセル（ロールバック）
• Azure Portal からも、機能フラグを有効にすることで利用できます

スクリプト：

• PowerShell：scripts/Azure-Redis-Migration-Arm-Rest-Api-Utility.ps1（Azure CLI が必要です）
• Bash：scripts/azure-redis-migration-arm-rest-api-utility.sh（Azure CLI と jq が必要です）

📖 ワークフロー全体、前提条件、スクリプトのパラメーター、トラブルシューティングについては、自動移行リファレンスをお読みください。 ARM API の内部仕様については、移行スクリプトのリファレンスを参照してください。 検証エラーコードについては、検証エラーと警告を参照してください。

よくある質問

Azure Cache for Redis（ACR）と Azure Managed Redis（AMR）の違いは何ですか？

機能の全体的な一覧については、機能比較を参照してください。主な違いは次のとおりです。

• AMR は Redis Stack の機能（JSON、Search、Time Series、Bloom フィルター）を提供します
• AMR には、異なるワークロードに最適化された別々の SKU ティアがあります
• AMR は、強化されたパフォーマンスとスケーラビリティのオプションを提供します

適切な AMR SKU を選ぶにはどうすればよいですか？

SKU マッピングガイドを参照し、次の点を考慮してください。

• 現在のメモリ使用量
• コンピューティング負荷（サーバー負荷 %）
• 必要な機能（クラスター化、geo-replication、Redis モジュール）
• 予算の制約

AMR で利用できない機能は何ですか？

現在の機能一覧については、機能比較を確認してください。正式な情報を得るには、MCP サーバーを使用して最新のドキュメントを取得してください。

Enterprise ティアの移行についてはどうですか？

このスキルでは Enterprise ティアの移行を扱いません。 ACRE（Azure Cache for Redis Enterprise）の移行について尋ねられた場合は、Enterprise ティアには異なる考慮事項があることをユーザーに伝え、Microsoft サポートまたは公式ドキュメントを参照するよう案内してください。

効果的な移行のヒント

1. 十分にテストする：まず必ず本番環境以外でテストしてください
2. パフォーマンスを監視する：移行の前後でベースラインのメトリックを比較してください
3. ロールバックを計画する：問題が発生した場合に備えて、ロールバック戦略を用意してください
4. クライアントライブラリを更新する：Redis クライアントライブラリが AMR の機能をサポートしていることを確認してください
5. セキュリティ設定を見直す：ファイアウォールルール、プライベートエンドポイント、認証を更新してください