次の方法で共有

Premium Azure Cache for Redis インスタンスのパッシブ geo レプリケーションを構成する

  • [アーティクル]

この記事では、Azure portal を使用して、Azure Cache for Redis インスタンスのペアでパッシブ geo レプリケーションを構成する方法について説明します。

パッシブ geo レプリケーションによって 2 つの Premium レベル Azure Cache for Redis インスタンスがリンクされ、アクティブ/パッシブ データ レプリケーション関係が作られます。 アクティブ/パッシブとは、データが同期されているキャッシュのペア (プライマリとセカンダリ) があることを意味します。 ただし、ペアの一方の側 (プライマリ) にのみ書き込むことができます。 ペアのもう一方の側であるセカンダリ キャッシュは読み取り専用です。

"アクティブ/パッシブ" を "アクティブ/アクティブ" と比較すると、後者では、ペアのどちら側にも書き込むことができ、それが反対側と同期します。

パッシブ geo レプリケーションを使用する場合、これらのキャッシュ インスタンスは通常、異なる Azure リージョンに置かれますが、必須ではありません。 1 つのインスタンスはプライマリとして、もう 1 つはセカンダリとして機能します。 プライマリによって読み取りと書き込み要求が処理され、変更がセカンダリに反映されます。

フェールオーバーは自動では行われません。 フェールオーバーを使用する方法の詳細については、geo プライマリから geo セカンダリへのフェールオーバーの開始に関する記事を参照してください。

Note

パッシブ geo レプリケーションは、ディザスター リカバリー ソリューションとして設計されています。

可用性のスコープ

レベル Basic、Standard Premium Enterprise、Enterprise Flash
使用可能 いいえ イエス はい

パッシブ geo レプリケーションは、Azure Cache for Redisの Premium レベルでのみ使用できます。 Enterprise および Enterprise Flash レベルでも geo レプリケーションは提供されますが、これらのレベルでは、''アクティブ geo レプリケーション'' と呼ばれるより高度なバージョンが使用されます。

geo レプリケーションの前提条件

2 つのキャッシュの間に geo レプリケーションを構成するには、次の前提条件を満たす必要があります。

  • 両方のキャッシュが Premium レベルのキャッシュである。
  • 両方のキャッシュが同じ Azure サブスクリプションに存在する。
  • セカンダリ リンク キャッシュがプライマリ リンク キャッシュと同じキャッシュ サイズであるか、またはそれより大きいキャッシュ サイズである。 geo フェールオーバーを使用するには、両方のキャッシュのサイズが同じである必要があります。
  • 両方のキャッシュが作成され、実行状態になっている。
  • どちらのキャッシュも同じバージョンの Redis サーバーを実行しています。

Note

Azure リージョン間のデータ転送は、標準の帯域幅レートで課金されます。

geo レプリケーションでは一部の機能がサポートされていません。

  • ゾーン冗長は geo レプリケーションではサポートされていません。
  • 永続化は geo レプリケーションではサポートされていません。
  • 複数のレプリカを含むキャッシュを geo レプリケートすることはできません。
  • クラスタリングは、両方のキャッシュでクラスタリングが有効になっており、かつ同じ数のシャードが存在する場合にサポートされます。
  • 同じ仮想ネットワーク (VNet) 内のキャッシュはサポートされています。
  • 異なる VNet 内のキャッシュは、注意事項付きでサポートされています。 詳細については、「VNet 内の自分のキャッシュで geo レプリケーションを使用することはできますか」を参照してください。

geo レプリケーションを構成した後、次の制限が、リンク キャッシュ ペアに適用されます。

  • セカンダリ リンク キャッシュは読み取り専用です。 そこから読み取ることはできますが、データを書き込むことはできません。 geo セカンダリ インスタンスからの読み取りを選択した場合は、geo プライマリと geo セカンダリの間で完全データ同期が実行されているときは、完全データ同期が完了するまで、geo セカンダリ インスタンスはそれに対する Redis 操作でエラーをスローします。 エラーは、完全なデータ同期が進行中であることを示します。 また、geo プライマリまたは geo セカンダリのいずれかが更新されたときや、一部の再起動シナリオの際に、エラーがスローされます。 geo セカンダリから読み取るアプリケーションは、geo セカンダリがこのようなエラーをスローするたびに geo プライマリにフォールバックするように構築する必要があります。

  • リンクが追加される前にセカンダリ リンク キャッシュにあったデータはすべて削除されます。 ただし、geo レプリケーションが後で削除された場合、レプリケートされたデータはセカンダリ リンク キャッシュに残ります。

  • キャッシュがリンクされている間は、どちらのキャッシュもスケーリングできません。

  • キャッシュでクラスタリングが有効になっている場合は、シャードの数を変更できません。

  • どちらのキャッシュでも永続化を有効にすることはできません。

  • どちらのキャッシュからもエクスポートできます。

  • セカンダリ リンク キャッシュにはインポートできません。

  • キャッシュをリンク解除するまでは、リンクされたキャッシュ、またはそれらを含むリソース グループのどちらも削除できません。 詳しくは、「リンクされたキャッシュを削除しようとすると、操作が失敗するのはどうしてですか」をご覧ください。

  • キャッシュが異なるリージョンに存在する場合、ネットワーク送信コストはリージョン間で移動されたデータに適用されます。 詳しくは、「Azure リージョン間でデータをレプリケートするコストはどれくらいですか」をご覧ください。

  • フェールオーバーは自動では行われません。 プライマリからセカンダリ リンク キャッシュへのフェールオーバーを開始する必要があります。 フェールオーバーを使用する方法の詳細については、geo プライマリから geo セカンダリへのフェールオーバーの開始に関する記事を参照してください。

  • プライベート リンクは、既に geo レプリケートされているキャッシュには追加できません。 geo レプリケートされたキャッシュにプライベート リンクを追加するには: 1. geo レプリケーションのリンクを解除します。 2. プライベート リンクを追加します。 3. 最後に、geo レプリケーションを再リンクします。

  1. geo レプリケーションのために 2 つのキャッシュをリンクするには、まずプライマリ リンク キャッシュにするキャッシュのリソース メニューの [geo レプリケーション] を選択します。 次に、作業ウィンドウで [キャッシュ レプリケーション リンクの追加] をクリックします。

    キャッシュの geo レプリケーション メニューを示すスクリーンショット。

  2. [互換性のあるキャッシュ] の一覧で目的のセカンダリ キャッシュの名前を選択します。 そのセカンダリ キャッシュが一覧に表示されていない場合は、セカンダリ キャッシュの geo レプリケーションの前提条件が満たされていることを確認します。 キャッシュをリージョンでフィルター処理するには、マップ内のリージョンを選択して、 [互換性のあるキャッシュ] の一覧にあるキャッシュのみを表示します。

    geo レプリケーションとリンクするための互換性のあるキャッシュを示すスクリーンショット。

    また、コンテキスト メニューを使用してリンク プロセスを開始したり、セカンダリ キャッシュに関する詳細を表示したりすることもできます。

    geo レプリケーションのコンテキスト メニューを示すスクリーンショット。

  3. [リンク] を選択して、2 つのキャッシュをリンクし、レプリケーション プロセスを開始します。

    geo レプリケーションのキャッシュをリンクする方法を示すスクリーンショット。

  4. [リソース] メニューの [geo レプリケーション] を使用して、レプリケーション プロセスの進行状況を表示できます。

    現在のリンク状態を示すスクリーンショット。

    プライマリとセカンダリ キャッシュの両方の [リソース] メニューから [概要] を使用して、リンクの状態を表示することもできます。

    プライマリ キャッシュとセカンダリ キャッシュのリンク状態を表示する方法を強調表示するスクリーンショット。

    レプリケーション プロセスが完了すると、[リンクのプロビジョニング状態] が [成功] に変わります。

    キャッシュ リンクの状態が [成功] であることを示すスクリーンショット。

    プライマリ リンク キャッシュは、リンク プロセス中も引き続き使用できます。 セカンダリ リンク キャッシュは、リンク プロセスが完了するまで使用できません。

geo プライマリ URL

キャッシュがリンクされると、常に geo プライマリ キャッシュを指す各キャッシュの URL が生成されます。 geo プライマリから geo セカンダリへのフェールオーバーが開始された場合、URL は変わりませんが、基になる DNS レコードは新しい geo プライマリを指すように自動的に更新されます。

geo レプリケーションを追加することで作成された 4 つの URL を示すスクリーンショット。

次の 3 つの URL が表示されます。

  • geo プライマリ URL は、<cachename>.geo.redis.cache.windows.net の形式のプロキシ URL です。 URL は常に、現在の geo プライマリである geo レプリケーション ペア内のキャッシュを指します。
  • 現在の Geo プライマリ キャッシュは、現在 geo プライマリであるキャッシュの直接アドレスです。 アドレスは redis.cache.windows.net であり、geo.redis.cache.windows.net ではありません。 フィールドに一覧表示されているアドレスは、フェールオーバーが開始されると変更されます。
  • 現在の geo セカンダリ キャッシュは、現在 geo セカンダリであるキャッシュの直接アドレスです。 アドレスは redis.cache.windows.net であり、geo.redis.cache.windows.net ではありません。 フィールドに一覧表示されているアドレスは、フェールオーバーが開始されると変更されます。

geo プライマリから geo セカンダリへのフェールオーバーを開始する

1 回の選択で、geo プライマリから geo セカンダリへのフェールオーバーをトリガーできます。

[フェールオーバー] が強調表示されているリンクされたキャッシュのスクリーンショット。

これにより、次の手順が実行されます。

  1. geo セカンダリ キャッシュは geo プライマリに昇格されます。
  2. geo プライマリ URL が新しい geo プライマリにリダイレクトされるように DNS レコードが更新されます。
  3. 古い geo プライマリ キャッシュはセカンダリに降格され、新しい geo プライマリ キャッシュへのリンクを形成しようとします。

geo フェールオーバー プロセスが完了するまでに数分かかります。

geo フェールオーバーを開始する前に確認するための設定

フェールオーバーが開始されると、geo プライマリと geo セカンダリのキャッシュが入れ替えられます。 新しい geo プライマリが geo セカンダリとは異なる方法で構成されている場合は、アプリケーションに問題が発生する可能性があります。

次の項目を必ず確認してください

  • いずれかのキャッシュでファイアウォールを使用している場合は、接続の問題が発生しないように、ファイアウォール設定が似ていることを確認してください。
  • 両方のキャッシュで同じポートと TLS/SSL 設定が使用されていることを確認します
  • geo プライマリ キャッシュと geo セカンダリ キャッシュには、異なるアクセス キーがあります。 フェールオーバーがトリガーされた場合は、新しい geo プライマリと一致するように、アプリケーションで使用されているアクセス キーを更新できることを確認してください。 または、キャッシュ認証に Microsoft Entra トークンを使用します。これにより、geo プライマリ キャッシュと geo セカンダリ キャッシュの両方に同じ認証資格情報を使用できます。

データ損失を最小限に抑えるフェールオーバー

geo フェールオーバー イベントでは、特にクライアントがフェールオーバー プロセス中に古い geo プライマリへの接続を維持している場合に、移行中にデータの不整合が発生する可能性があります。 次のヒントを使用して、計画された geo フェールオーバー イベントでのデータ損失を最小限に抑えることができます。

  • geo レプリケーション データ同期オフセットのメトリックを確認します。 このメトリックは、現在の geo プライマリ キャッシュによって生成されます。 このメトリックは、geo プライマリにまだレプリケートされていないデータの量を示します。 可能であれば、メトリックが、書き込まれる残りのバイト数が 14 バイト未満であることを示す場合にのみ、フェールオーバーを開始します。
  • フェールオーバーを開始する前に、現在の geo プライマリで CLIENT PAUSE コマンドを実行します。 CLIENT PAUSE を実行すると、新しい書き込み要求がブロックされ、代わりにタイムアウト エラーが Azure Cache for Redis クライアントに返されます。 CLIENT PAUSE コマンドでは、タイムアウト期間をミリ秒単位で指定する必要があります。 フェールオーバーを開始するのに十分な長いタイムアウト時間が指定されていることを確認します。 開始時には、この一時停止の値を約 30 分 (1,800,000 ミリ秒) に設定することをお勧めします。 この数値は、必要に応じていつでも小さくすることができます。

新しい geo プライマリはクライアントの一時停止を保持するため、CLIENT UNPAUSE コマンドを実行する必要はありません。

Note

geo フェールオーバー シナリオでは、キャッシュに対して Microsoft Entra ID ベースの認証を使用することをお勧めします。これによって、geo プライマリ キャッシュと geo セカンダリ キャッシュに対する異なるアクセス キーを管理する困難がなくなるためです。

  1. 2 つのキャッシュ間のリンクを削除し、geo レプリケーションを停止するには、左側の [geo レプリケーション] で [キャッシュのリンク解除] を選択します。

    キャッシュのリンクを解除する方法を示すスクリーンショット。

    リンク解除プロセスが完了すると、セカンダリ キャッシュが読み取りと書き込みの両方に対して使用可能になります。

Note

geo レプリケーション リンクが削除された場合も、プライマリ リンク キャッシュからレプリケートされたデータはセカンダリ キャッシュに残ります。

geo レプリケーションに関する FAQ

Standard または Basic レベル キャッシュで geo レプリケーションを使用することはできますか

いいえ、パッシブ geo レプリケーションは Premium レベルでのみ使用できます。 アクティブ geo レプリケーションと呼ばれるより高度なバージョンの geo レプリケーションは、Enterprise および Enterprise Flash レベルで使用できます。

リンクまたはリンク解除のプロセス中にキャッシュを使用できますか

  • プライマリ リンク キャッシュは、リンク プロセスが完了するまで引き続き使用できます。
  • セカンダリ リンク キャッシュは、リンク プロセスが完了するまで使用できません。
  • 両方のキャッシュは、リンク解除プロセスが完了するまで使用できます。

フェールオーバーを開始した後、新しい geo プライマリに書き込むことができるのはいつですか?

フェールオーバー プロセスが開始されると、リンク プロビジョニングの状態が [削除中] に更新されることがわかります。これは、前のリンクがクリーンアップされていることを示します。 これが完了した後、リンク プロビジョニングの状態は [作成中] に更新されます。 これは、新しい geo プライマリが稼働中であり、古い geo プライマリ キャッシュへの geo レプリケーション リンクを再確立しようとしていることを示します。 この時点で、読み取りと書き込みの両方について、新しい geo プライマリ キャッシュ インスタンスにすぐに接続できるようになります。

はい。geo レプリケーションの状態を追跡するのに役立つ使用可能なメトリックがいくつかあります。 これらのメトリックは、Azure portal で利用できます。

  • [Geo Replication Healthy](Geo レプリケーションの正常性) には、geo レプリケーション リンクの状態が表示されます。 geo プライマリまたは geo セカンダリのキャッシュのどちらかがダウンしている場合、リンクは異常であると表示されます。 これは通常、標準的なパッチ適用操作が原因ですが、障害の状況を示している可能性もあります。
  • [geo レプリケーションの接続ラグ] は、geo プライマリと geo セカンダリの間の最後の正常なデータ同期からの経過時間を示します。
  • [geo レプリケーション データ同期オフセット] には、geo セカンダリ キャッシュにまだ同期されていないデータの量が表示されます。
  • [geo レプリケーションの完全同期イベントの開始] は、geo プライマリ キャッシュと geo セカンダリ キャッシュの間で完全同期アクションが開始されたことを示します。 これは、標準レプリケーションが新しい書き込みの数に追いつくことができない場合に発生します。
  • [Geo Replication Full Sync Event Finished] (geo レプリケーションの完全同期イベントの完了) は、完全同期アクションが完了したことを示します。

geo レプリケーションの正常性メトリックがすべて 1 つのビューに含まれる geo レプリケーション ダッシュボードと呼ばれる事前構築済みのブックもあります。 geo プライマリまたは geo セカンダリ キャッシュ インスタンスからのみ生成される情報を集計するため、このビューを使用することをお勧めします。

いいえ。パッシブ geo レプリケーションを使用する場合、リンクできるのは 2 つのキャッシュのみです。 アクティブ geo レプリケーションでは、最大 5 つのリンク キャッシュがサポートされます。

いいえ、両方のキャッシュが同じ Azure サブスクリプションにある必要があります。

セカンダリ リンク キャッシュがプライマリ リンク キャッシュより大きい場合は可能です。 ただし、キャッシュのサイズが異なる場合は、フェールオーバー機能を使用できません。

クラスタリングを有効にして geo レプリケーションを使用することはできますか

両方のキャッシュのシャード数が同じ場合は可能です。

VNet 内の自分のキャッシュで geo レプリケーションを使用することはできますか

ほとんどの場合、VNet インジェクション経由で Azure Private Link を使用することをお勧めします。 詳細については、「VNet インジェクション キャッシュから Private Link キャッシュに移行する」を参照してください。

キャッシュを geo レプリケートするときに VNet インジェクションを使用することは技術的には引き続き可能ですが、Azure Private Link をお勧めします。

重要

Azure Cache for Redis では、ネットワーク アーキテクチャが簡素化され、Azure 内のエンドポイント間の接続がセキュリティで保護される Azure Private Link の使用を推奨しています。 仮想ネットワーク内のサブネットでプライベート IP アドレスが割り当てられているプライベート エンドポイント経由で、仮想ネットワークから Azure Cache インスタンスに接続できます。 Azure Private Link はすべてのレベルで提供されており、Azure Policy のサポートと、簡略化された NSG ルール管理が含まれます。 詳細については、Private Link に関するドキュメントのページを参照してください。 VNet インジェクションされたキャッシュから Private Link に移行する方法については、「VNet インジェクション キャッシュから Private Link キャッシュに移行する」を参照してください。

VNet を使用した geo レプリケーションのサポートの詳細については、「Premium キャッシュでの VNet インジェクションを使用した geo レプリケーション」を参照してください。

Redis の geo レプリケーションのレプリケーション スケジュールは何ですか

レプリケーションは継続的かつ非同期に行われます。 特定のスケジュールで実行されるわけではありません。 プライマリに対して実行された書き込みはすべて、セカンダリに瞬時にかつ非同期的にレプリケートされます。

geo レプリケーションのレプリケーションにはどのくらいの時間が必要ですか

レプリケーションは増分的、非同期、および継続的であるため、かかる時間はリージョン間の待機時間とそれほど変わりません。 特定の状況では、セカンダリ キャッシュがプライマリからのデータの完全な同期を実行することが必要になる場合があります。 この場合のレプリケーション時間は、プライマリ キャッシュへの負荷、使用可能なネットワーク帯域幅、リージョン間の待機時間など、多くの要因によって異なります。 53 GB の完全な geo レプリケートされたペアのレプリケーション時間は 5 ～ 10 分であることがわかりました。 Azure Monitor の Geo Replication Data Sync Offset メトリックを使用して、まだレプリケートされていないデータの量を追跡できます。

レプリケーションの回復ポイントは保証されますか

geo レプリケーション モードのキャッシュの場合、永続化は無効になっています。 geo レプリケートされたペアがリンク解除された場合 (顧客始動のフェールオーバーなど)、セカンダリ リンク キャッシュは同期されたデータをその時点まで保持します。 このような状況では、復旧ポイントは保証されません。

復旧ポイントを取得するには、どちらかのキャッシュからエクスポートします。 後で、プライマリ リンク キャッシュにインポートできます。

PowerShell または Azure CLI を使って geo レプリケーションを管理することはできますか

はい。geo レプリケーションは、Azure Portal、PowerShell、または Azure CLI を使用して管理できます。 詳細については、PowerShell のドキュメントまたは Azure CLI のドキュメントを参照してください。

Azure リージョン間でデータをレプリケートするコストはどれくらいですか

geo レプリケーションを使用している場合、プライマリ リンク キャッシュからのデータは、セカンダリ リンク キャッシュにレプリケートされます。 2 つのリンクされたキャッシュが同じリージョンに存在する場合、データ転送の料金は必要ありません。 2 つのリンクされたキャッシュが異なるリージョンに存在する場合、データ転送の料金は、どちらかのリージョン内を移動するデータのネットワーク送信コストです。 詳しくは、「帯域幅の料金詳細」をご覧ください。

リンクされたキャッシュを削除しようとすると、操作が失敗するのはどうしてですか

geo レプリケートされたキャッシュとそのリソース グループは、geo レプリケーション リンクを削除するまでは削除できません。 リンクされたキャッシュの一方または両方を含むリソース グループを削除しようとすると、リソース グループ内の他のリソースは削除されますが、リソース グループは deleting 状態のままとなり、リソース グループ内にあるリンクされたキャッシュは running 状態のままとなります。 リソース グループとその中のリンクされたキャッシュを完全に削除するには、「geo レプリケーション リンクの削除」の説明に従ってキャッシュをリンク解除します。

セカンダリ リンク キャッシュにはどのリージョンを使う必要がありますか

一般に、キャッシュは、それにアクセスするアプリケーションと同じ Azure リージョンに配置することをお勧めします。 プライマリおよびフォールバック リージョンが個別に存在するアプリケーションの場合は、プライマリおよびセカンダリ キャッシュをそれらの同じリージョンに配置することをお勧めします。 ペアになっているリージョンについて詳しくは、ベスト プラクティス - ペアになっている Azure リージョンに関する記事をご覧ください。

geo レプリケーションを使用してファイアウォールを構成することはできますか

はい。geo レプリケーションを使用して、ファイアウォールを構成することができます。 geo レプリケーションをファイアウォールと共に機能させるには、セカンダリ キャッシュの IP アドレスが、プライマリ キャッシュのファイアウォール規則に追加されていることを確認します。 ただし、キャッシュでパブリック ネットワーク アクセスが無効になっていて、プライベート エンドポイントのみが有効になっている場合、キャッシュでのファイアウォールの使用はサポートされません。

次のステップ

Azure Cache for Redis の機能について