編集

Azure Cache for Redis に関する FAQ

  • よく寄せられる質問

Azure Cache for Redis についてよく寄せられる質問に対する回答、パターン、ベスト プラクティスについて説明します。

Redis ライセンスの変更

Redis ライセンスにどのような変更が加えられましたか?

Redis オープン ソース プロジェクトは、Redis Source Available License version 2 (RSALv2) または Server-Side Public License version 1 (SSPLv1) をサポートするデュアル ライセンス モデルに変更されました。 詳細については、「Redis のプレス リリース」を参照してください。 「Redis ライセンスの変更に関する Microsoft ブログ投稿」も参照してください。

Azure Cache for Redis は RSALv2 ライセンスおよび SSPLv1 ライセンスの対象にもなりましたか?

いいえ。Azure Cache for Redis は、Microsoft のサービス使用条件に基づいてお客様に提供されます。 RSALv2 ライセンスおよび SSPLv1 ライセンスは、Azure Cache for Redis の使用には適用されません。

私の Azure Cache for Redis インスタンスは引き続きパッチとバグ修正を受け取りますか?

はい。Azure Cache for Redis、 Azure Cache for Redis Enterprise、および Enterprise Flash は、ライセンスの発表後も引き続きパッチとバグ修正を受け取ります。

このライセンスの発表を受けて、Azure Cache for Redis の顧客として私は何を行う必要がありますか?

ライセンスの発表に関して、Azure のお客様が実施する必要のあるアクションはありません。

非推奨のサービス

非推奨となった Azure Cache for Redis サービスはどれですか?

  • Managed Cache Service - Managed Cache service は 2016 年 11 月 30 日に終了しました。

  • In-Role Cache - In-Role Cache は 2016 年 11 月 30 日に終了しました。

Cloud Services (クラシック) に依存するキャッシュ

Cloud Services (クラシック) に依存する Azure Cache for Redis のインスタンスで何を行う必要がありますか?

Cloud Services (クラシック) に依存するすべてのキャッシュを移行する必要があります。 2021 年 8 月、Cloud Services (クラシック) は 2024 年 8 月 31 日に廃止されると発表されました。 Cloud Services (クラシック) に依存する Azure Cache for Redis のインスタンスは、同日までに廃止する必要があります。

Cloud Services (クラシック) に依存するキャッシュを、2024 年 8 月 31 日までに移行する必要があります。

影響を受けるキャッシュの数はいくつですか?

可能な限り多くのキャッシュを透過的に移行するよう努力しました。 このため、影響を受けるキャッシュと顧客はほとんどありません。

キャッシュが影響を受けるかどうかを知るにはどうすればよいですか?

Azure Advisor の推奨事項を確認します。 キャッシュが影響を受ける場合は、サブスクリプションに推奨事項が表示されます。

クラウド サービスからキャッシュを移行するようにという Advisor の推奨事項のスクリーンショット。

Cloud Services (クラシック) キャッシュを Azure Virtual Machine Scale Sets に移行するにはどうすればよいですか?

ほとんどのキャッシュは、Cloud Services (クラシック) 上での構築から Azure Virtual Machine Scale Sets 上での構築に移行しました。 Azure Virtual Machine Scale Sets に移行すると、依存関係が取り除かれます。 仮想ネットワーク内のキャッシュに対してこのプロセスを開始するには、次の 3 つの方法があります。

  • プライベート リンクを使用して新しいキャッシュに移行する。

    仮想ネットワーク インジェクションではなくネットワーク分離に Private Link を使用する新しいキャッシュを作成し、データをこのキャッシュに移行します。 このオプションを使用すると、最適で最も安全なネットワーク分離エクスペリエンスが提供され、更新されたインフラストラクチャを使用してすべての新しいキャッシュが確実に作成されます。

  • 新しい Azure Resource Manager VNet サブネット内の新しいキャッシュに移行します。

    クラシック VNet 内にキャッシュを作成すると、Azure Virtual Machine Scale Sets キャッシュではなく、Cloud Services (クラシック) キャッシュが作成されます。 新しい Azure Resource Manager VNet サブネット内の新しいキャッシュに移行すると、同等の仮想ネットワーク エクスペリエンスを維持しながら、Cloud Services に対する基になる依存関係が修正されます。

    ほとんどのキャッシュは、Cloud Services (クラシック) 上での構築から Azure Virtual Machine Scale Sets 上での構築に移行しました。 移行するには、既存のキャッシュを削除し、新しい Azure Resource Manager VNet サブネットに新しいキャッシュを作成します。 キャッシュの移行中に古いサブネットを使用しないことを強くお勧めします。 キャッシュ内のデータを移行するための推奨オプションについては、「Azure Cache for Redis への移行」を参照してください。

  • データ損失を伴う自動移行 (推奨)。

    キャッシュの構成 (アクセス キーとホスト名を含む) を保持したまま、キャッシュを Cloud Services (クラシック) から Virtual Machine Scale Sets へ自動的に移行できます。 ただし、この方法では約 30 分のダウンタイムが必要で、キャッシュ上のデータは完全に失われます。 インポート/エクスポート機能を使用して、移行前のデータのコピーを保存できます。

    このオプションを利用するには、azurecachemigration@microsoft.com に連絡するか、サポート リクエストを作成して移行を要求してください。

キャッシュで VNet インジェクションが使用されていませんが、移行する必要があるという通知を受け取りました。 どうすればよいですか。

キャッシュで geo レプリケーションが使用されているかどうかを確認します。 その場合は、現在の geo レプリケート ペアから新しい geo レプリケート ペアにデータを移行する必要があります。

次に例を示します。

  1. 現在のキャッシュのペアと同じ構成に一致する Premium キャッシュの新しい geo レプリケート ペアを作成します。
  2. geo レプリケートされたキャッシュの元のペアのリンクを解除し、プライマリ キャッシュから RDB ファイルをエクスポートします。
  3. 新しい geo レプリケート ペアのプライマリ キャッシュに RDB ファイルをインポートします。

geo レプリケートされたキャッシュの新しいペアは、Cloud Services に対して同じ依存関係を持ちません。

"the subnet is affected by Cloud Services retirement" (サブネットは Cloud Services の廃止による影響を受けます) というエラー メッセージにより、新しいキャッシュ インスタンスを作成できない場合はどうすればよいですか?

Cloud Services (クラシック) デプロイ モデルを使用して、新しいキャッシュの作成のブロックを開始します。 新しいキャッシュは、Cloud Services キャッシュが一度は含まれていた VNet サブネットに作成された場合、またはクラシック仮想ネットワークにキャッシュがデプロイされている場合、この古いデプロイ モデルを使用して引き続き作成できます。 このメッセージが表示された場合は、キャッシュをデプロイする VNet に新しいサブネットを作成します。 仮想ネットワークにサブネットを作成すると、Cloud Services に依存することなくキャッシュが作成されます。

サブネット内に 1 つ以上の Cloud Services ベースのキャッシュがあるかどうかを確認するには、ポータルで Azure Advisor を確認するか、resource-navigation-links REST API を使用します。 サブスクリプション ID、リソース グループ名、仮想ネットワーク名、サブネット名を含む resource-navigation-links API を使用すると、そのサブネット内にある、Cloud Services を使用しているすべてのキャッシュを取得します。

REST API を使用して新しいキャッシュを作成する場合は、作成要求と共に redis-configuration {"CacheVmType": "CloudService"} を渡さないようにします。 このパラメーターはドキュメント化されていないパラメーターであるため、この操作を実行する可能性は低いでしょう。

Cloud Services (クラシック) デプロイ モデルを使用して新しいキャッシュを作成する必要がある場合は、azurecachemigration@microsoft.com に連絡するか、サポート リクエストを作成して除外を要求してください。

キャッシュが 2024 年 8 月 31 日までにアップグレードまたは移行されない場合はどうなりますか?

これらのキャッシュはシャットダウンされ、キャッシュ内のデータは失われます。

サポートのタイムラインは何ですか?

移行のために最大限の時間を得ることができるように、廃止は次の 3 つのフェーズで行われます。

  1. アクティブ ステージ (2023 年 4 月 30 日まで)

    キャッシュは完全にサポートされ、状態は現在から変更されません。 この期間は、お客様に最小限の中断で Cloud Service (クラシック) から移行する時間を与えるために提供されます。

  2. メンテナンス ステージ (2023 年 5 月 1 日から 2023 年 12 月 31 日)

    キャッシュは重要なセキュリティ修正プログラム、安定性に関する修正、バグ修正を受け取りますが、新機能はありません。

  3. 非アクティブ ステージ (2024 年 1 月 1 日から 2024 年 8 月 31 日)

    キャッシュは重要なセキュリティ修正プログラムのみを受け取ります。 サポートの問題があるすべてのお客様は、サポートを受ける前に VMSS ベースのキャッシュに移行するように要求されます。 お客様は、2024 年 8 月 31 日までにキャッシュから移行する必要があります。

Cloud Services (クラシック) の廃止のタイムラインを示す画像。

このタイムラインは Redis 4.0 で実行するキャッシュに適用されますか?

不正解です。 このタイムラインは Redis 6.0 で実行するキャッシュにのみ適用されます。 Redis 4.0 は、クラウド サービス (クラシック) の廃止前に終了する個別の廃止の一部です。 Cloud Services (クラシック) で Redis 4.0 を使用している残りのキャッシュはすべて、2023 年 10 月 31 日以降、Virtual Machine Scale Sets と Redis 6.0 を使用するように自動的に移行されます。 この移行方法では、キャッシュのダウンタイムと完全なデータ損失が発生するため、ダウンタイムやデータ損失を避けるには、この期日より前に移行してください。 2023 年 10 月 31 日までの自動アップグレードを希望する場合は、azurecachemigration@microsoft.com に連絡するか、サポート リクエストを作成してください。

この提供終了に関する質問がまだある場合は、どこで詳細情報を入手できますか?

ご質問がある場合は、Cloud Services (クラシック) の廃止に関するお問い合わせページに投稿してください。 また、azurecachemigration@microsoft.com に電子メールを送信して詳細を確認することもできます。

一般的な質問

Azure Cache for Redis に関する質問にここで回答されない場合はどうしたらよいですか?

質問がここに表示されていない場合はご連絡ください。答えを見つけるお手伝いをします。