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

この記事では、Azure portal を使用し、geo レプリケートされた Azure Cache を構成する方法について説明します。

geo レプリケーションによって 2 つの Premium Azure Cache for Redis インスタンスがリンクされ、データ レプリケーション関係が作られます。 これらのキャッシュ インスタンスは通常、異なる Azure リージョンに置かれますが、必須ではありません。 1 つのインスタンスはプライマリとして、もう 1 つはセカンダリとして機能します。 プライマリによって読み取りと書き込み要求が処理され、変更がセカンダリに反映されます。 2 つのインスタンス間のリンクが削除されるまで、このプロセスが続きます。

注意

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

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

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

  • 両方のキャッシュが Premium レベルのキャッシュである。
  • 両方のキャッシュが同じ Azure サブスクリプションに存在する。
  • セカンダリ リンク キャッシュがプライマリ リンク キャッシュと同じキャッシュ サイズであるか、またはそれより大きいキャッシュ サイズである。
  • 両方のキャッシュが作成され、実行状態になっている。

注意

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

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

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

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

  • セカンダリ リンク キャッシュは読み取り専用です。読み取ることはできますが、データを書き込むことはできません。 geo セカンダリ インスタンスからの読み取りを選択した場合は、次の点に注意することが重要です。geo プライマリと geo セカンダリの間で完全データ同期 (geo プライマリまたは geo セカンダリが更新されたときと、一部の再起動シナリオで発生) が実行されているときは必ず、geo プライマリと geo セカンダリの間の完全データ同期が完了するまで、geo セカンダリ インスタンスはそれに対する Redis 操作で (完全データ同期が進行中であることを示す) エラーをスローします。 geo セカンダリから読み取るアプリケーションは、geo セカンダリがこのようなエラーをスローするたびに geo プライマリにフォールバックするように構築する必要があります。
  • リンクが追加される前にセカンダリ リンク キャッシュにあったデータはすべて削除されます。 ただし、geo レプリケーションが後で削除された場合、レプリケートされたデータはセカンダリ リンク キャッシュに残ります。
  • キャッシュがリンクされている間は、どちらのキャッシュもスケーリングできません。
  • キャッシュでクラスタリングが有効になっている場合は、シャードの数を変更できません。
  • どちらのキャッシュでも永続化を有効にすることはできません。
  • どちらのキャッシュからもエクスポートできます。
  • セカンダリ リンク キャッシュにはインポートできません。
  • キャッシュをリンク解除するまでは、リンクされたキャッシュ、またはそれらを含むリソース グループのどちらも削除できません。 詳しくは、「リンクされたキャッシュを削除しようとすると、操作が失敗するのはどうしてですか」をご覧ください。
  • キャッシュが異なるリージョンに存在する場合、ネットワーク送信コストはリージョン間で移動されたデータに適用されます。 詳しくは、「Azure リージョン間でデータをレプリケートするコストはどれくらいですか」をご覧ください。
  • プライマリ リンク キャッシュとセカンダリ リンク キャッシュの間で自動フェールオーバーは発生しません。 詳細およびクライアント アプリケーションをフェールオーバーする方法については、「セカンダリ リンク キャッシュへのフェールオーバーはどのように動作しますか」を参照してください。
  1. geo レプリケーションのために 2 つのキャッシュをリンクするには、まずプライマリ リンク キャッシュにするキャッシュのリソース メニューの [geo レプリケーション] をクリックします。 次に、左側の [geo レプリケーション][キャッシュ レプリケーション リンクの追加] をクリックします。

    キャッシュ geo レプリケーションのメニュー

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

    互換性のあるキャッシュの選択

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

    geo レプリケーションのコンテキスト メニュー

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

    キャッシュのリンク

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

    リンクの状態

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

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

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

    キャッシュの状態

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

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

    [Unlink caches]\(キャッシュのリンク解除\)

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

注意

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

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

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

geo レプリケーションは、Premium レベルのキャッシュにのみ使用できます。

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

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

いいえ。2 つのキャッシュしかリンクできません。

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

セカンダリ リンク キャッシュがプライマリ リンク キャッシュより大きい場合は可能です。

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

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

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

はい。VNet 内のキャッシュの geo レプリケーションは注意事項付きでサポートされています。

  • 同じ VNet 内のキャッシュ間の geo レプリケーションがサポートされています。
  • 異なる VNet 内のキャッシュ間の geo レプリケーションもサポートされています。
    • VNet が同じリージョンに存在する場合は、VNet ピアリングまたは VPN Gateway VNet 間接続を使用してそれらを接続できます。
    • VNet がさまざまなリージョンに存在する場合は、VNet ピアリングを使用した geo レプリケーションがサポートされますが、Basic 内部ロード バランサーの制約のため、VNet 1 (リージョン 1) のクライアント VM で DNS 名を使用して VNet 2 (リージョン 2) のキャッシュにアクセスすることはできなくなります。 VNet ピアリングの制約の詳細については、Virtual Network - ピアリングの要件と制約に関するページを参照してください。 VPN Gateway による VNet 間接続を使用することをお勧めします。

この Azure テンプレートを使用すると、2 つの geo レプリケートされたキャッシュを VPN Gateway VNet 間接続で接続された VNet にすばやくデプロイできます。

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

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

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

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

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

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 レプリケートされたキャッシュでは、Azure リージョン間の自動フェールオーバーはサポートされていません。 ディザスター リカバリー シナリオでは、顧客がアプリケーション スタック全体をバックアップ リージョンで調整された方法で復旧する必要があります。 バックアップに切り替えるタイミングを個々のアプリケーション コンポーネントに個別に判定させるようにすると、パフォーマンスに悪影響を与える可能性があります。

Redis の主な利点の 1 つは、それが非常に待機時間の短いストアであることです。 顧客の主要なアプリケーションがそのキャッシュとは別のリージョンに存在する場合は、追加されるラウンド トリップ時間がパフォーマンスに大きな影響を与えます。 このため、一時的な可用性の問題から、自動的なフェールオーバーを回避しています。

顧客始動のフェールオーバーを開始するには、まずキャッシュをリンク解除します。 次に、(以前にリンクされた) セカンダリ キャッシュの接続エンドポイントを使用するように Redis クライアントを変更します。 2 つのキャッシュがリンク解除されると、セカンダリ キャッシュが再び通常の読み取り/書き込みキャッシュになり、Redis クライアントから直接要求を受け付けます。

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

はい。geo レプリケーションを使用して、ファイアウォールを構成することができます。 geo レプリケーションをファイアウォールと共に機能させるには、セカンダリ キャッシュの IP アドレスが、プライマリ キャッシュのファイアウォール規則に追加されていることを確認します。

次の手順

Azure Cache for Redis の機能について