Azure Managed Redis (プレビュー) インスタンスのアクティブ geo レプリケーションを構成する
この記事では、Azure portal を使用し、アクティブ geo レプリケートされたキャッシュを構成する方法について説明します。
アクティブ geo レプリケーションは、最大 5 つの Azure Managed Redis (プレビュー) のインスタンスをグループ化して、複数の Azure リージョンにまたがる 1 つのキャッシュにします。 インスタンスはすべて、ローカルのプライマリ キャッシュとして機能します。 アプリケーションでは、読み取りおよび書き込み要求に使用するインスタンスを決定します。
Note
Azure リージョン間のデータ転送は、標準の帯域幅レートで課金されます。
アクティブ geo レプリケーションのしくみ
アクティブ geo レプリケーションでは、競合のないレプリケートされたデータ型 (CRDT) を使用して、大陸をまたいで分散可能な Redis インスタンス間でデータをシームレスに分散します。 これらのインスタンスはアクティブ/アクティブ構成で接続されており、1 つのインスタンスへの書き込みが、同じ geo レプリケーション グループ内の他のインスタンスに自動的に反映されます。 この双方向データ レプリケーションは、一方向のアクティブ/パッシブ レプリケーション アプローチ、つまりプライマリから geo レプリカにデータがレプリケートされ、反対方法にはレプリケートされないものとは異なります。 この強力なツールの一般的な使用方法はいくつかあります。
- "ユーザーにより近い場所でキャッシュを分散してローカル待機時間を提供"。 アクティブ geo レプリケートされた Redis インスタンスのネットワークを使用すると、各リージョンのユーザーに地理的に近い場所にキャッシュを配置でき、待機時間が短縮され、アプリのパフォーマンスが向上します。
- "グローバル アプリケーションの同期"。 geo レプリケートされたキャッシュは 1 つの Redis インスタンスのように見えるため、データをグローバルに分散できます。リージョンごとにデータをセグメント化する必要はありません。 たとえば、地理的リージョンごとに個別のランキングを提供するのではなく、世界中のすべてのユーザーに対して、1 つの並べ替えられた Redis セットを使用してゲーム ランキングを提供することができます。
- リージョン障害によるダウンタイムとリスクを軽減。 geo レプリケーション グループ内の Redis インスタンスは、そのグループの他のインスタンスの最新データで常に更新されているため、リージョンで障害が発生してもデータは適切に保持されます。 アプリケーションは、グループの他のインスタンスのいずれかを使用するように一時的に切り替えることができ、リージョンがオンラインに戻ると、そこにある Redis インスタンスには、他の geo レプリケートされたキャッシュのデータが自動的に再読み込みされます。
アクティブ geo レプリケーションのしくみの詳細な内訳については、アクティブ/アクティブ geo 分散 (CRDTS ベース) に関する記事を参照してください
可用性のスコープ
レベル | メモリ最適化、バランス、コンピューティング最適化 | フラッシュ最適化 |
---|---|---|
対応可能 | はい (B0 と B1 を除く) | はい |
重要
バランス B0 と B1 の SKU は、アクティブ geo レプリケーションをサポートしていません。
アクティブ geo レプリケーションの前提条件
アクティブ geo レプリケーションを使用する場合は、いくつかの制限があります。
- アクティブ geo レプリケーションは、Azure Managed Redis が高可用性構成になっている (つまり、レプリケーションを使用している) 場合にのみサポートされます。
- RediSearch モジュールと RedisJSON モジュールのみがサポートされています。
- "フラッシュ最適化" レベルでは、"削除なし" 削除ポリシーのみを使用できます。 他のレベルでは、すべての削除ポリシーがサポートされています。
- アクティブ geo レプリケーションでは優れたエクスペリエンスが提供されているため、データ永続化はサポートされていません。
- geo レプリケーション グループ内のすべてのキャッシュは、同じ構成である必要があります。 たとえば、すべてのキャッシュに同じ SKU、容量、削除ポリシー、クラスタリング ポリシー、モジュール、TLS 設定が必要です。
- geo レプリケーション グループ内の一方のインスタンスがスケーリングされる場合は、追加のスケーリングが発生する前に、そのグループ内のもう一方のインスタンスを同じサイズにスケーリングする必要があります。 詳細については、「geo レプリケーション グループ内のインスタンスのスケーリング」を参照してください。
- アクティブ geo レプリケーションを使用する場合、
FLUSHALL
およびFLUSHDB
Redis コマンドを使用することはできません。 コマンドを禁止することで、意図しないデータの削除が防止されます。 代わりに、フラッシュ操作を使用します。
アクティブ geo レプリケーション グループを作成または参加する
新しい Azure Managed Redis リソースを作成する場合は、[詳細設定] タブを選択します。クラスタリング ポリシーを含むフォームの最初の部分に記入します。 クラスタリング ポリシーの選択の詳細については、Azure Managed Redis でのクラスタリングに関する記事を参照してください。
[構成] を選択して [アクティブ geo レプリケーション] を設定します。
最初のキャッシュ インスタンスに対して新しいレプリケーション グループを作成します。 または、リストから既存のものを選択します。
[構成] を選択して完了します。
最初のキャッシュが正常に作成されるまで待ちます。 完了すると、アクティブ geo レプリケーションに対して [構成済み] が設定されたことが表示されます。 Geo レプリケーション グループ内のキャッシュ インスタンスごとに、上記の手順を繰り返します。
アクティブ geo レプリケーション グループに既存のインスタンスを追加する
アクティブ geo レプリケーション グループに既存のキャッシュ インスタンスを追加するには、REST API を使用して強制リンク アクションを実行します。
リンクされているキャッシュ インスタンス内のすべてのデータが破棄されます。 また、geo レプリケーション グループに参加している間、インスタンスは一時的に数分間使用できなくなります。 この機能では、ポータルと CLI はまだサポートされていません。
アクティブ geo レプリケーション グループから削除する
アクティブ geo レプリケーション グループからキャッシュ インスタンスを削除するには、そのインスタンスを削除します。 その後、残りのインスタンスは自動的に再構成されます。
リージョンが停止した場合に強制的にリンク解除する
アクティブ geo レプリケーションは、Azure Managed Redis を使用する場合に可用性を大幅に向上させる強力な機能です。 ただし、リージョンで障害が発生した場合は、キャッシュを準備する手順を実行する必要があります。
たとえば、次のヒントについて考えてみます。
- リージョンがダウンした場合に切り替える geo レプリケーション グループ内の他のキャッシュを事前に特定します。
- 特定されたバックアップ キャッシュにアプリケーションとクライアントがアクセスできるように、ファイアウォールの設定を確認します。
- geo レプリケーション グループ内の各キャッシュには、独自のアクセス キーがあります。 バックアップ キャッシュをターゲットにするときに、アプリケーションでさまざまなアクセス キーを切り替える方法を決定します。
- geo レプリケーション グループ内のキャッシュがダウンすると、geo レプリケーション グループ内のすべてのキャッシュでメタデータの蓄積が開始されます。 書き込みをすべてのキャッシュに再度同期できるようになるまで、メタデータを破棄することはできません。 ダウンしているキャッシュの "リンクを強制的に解除" して、メタデータの蓄積を防ぐことができます。 特に書き込み負荷の高いワークロードでは、キャッシュ内の使用可能なメモリを監視し、メモリ不足がある場合はリンクを解除することを検討してください。
サーキット ブレーカー パターンを使用することもできます。 このパターンを使用して、リージョンが停止しているキャッシュから、同じ geo レプリケーション グループ内のバックアップ キャッシュにトラフィックを自動的にリダイレクトします。 リダイレクトを有効にするには、Azure Traffic Manager や Azure Load Balancer などの Azure サービスを使用します。
リージョンの停止によってレプリケーション グループ内のキャッシュの 1 つが使用できない場合、使用できないキャッシュをレプリケーション グループから強制的に削除できます。
使用できないキャッシュに共有されていないメタデータの格納を、レプリケーション グループ内の残りのキャッシュが開始するため、使用できないキャッシュは削除する必要があります。 これが起こると、レプリケーション グループ内の使用可能なキャッシュでメモリ不足になる可能性があります。
Azure portal に移動し、引き続き使用可能なレプリケーション グループ内のいずれかのキャッシュを選択します。
設定は、左側の [リソース] メニューの [アクティブ geo レプリケーション] を選択すると作業ウィンドウに表示されます。
チェック ボックスをオンにして、強制的にリンク解除する必要があるキャッシュを選択します。
[強制的にリンク解除] を選択し、[OK] を選択して確定します。
影響を受けるリージョンの可用性が復元されたら、影響を受けているキャッシュを削除し、再作成してレプリケーション グループに戻す必要があります。
Azure CLI または PowerShell を使用してアクティブ geo レプリケーションを設定する
Azure CLI
Azure CLI を使用して新しいキャッシュおよび geo レプリケーション グループを作成するか、既存の geo レプリケーション グループに新しいキャッシュを追加します。 詳細については、「az redisenterprise create」をご覧ください。
Azure CLI を使用して新しい geo レプリケーション グループに新しい Azure Managed Redis インスタンスを作成する
この例では、米国東部リージョンに Cache1 という新しい Azure Managed Redis Balanced B10 インスタンスを作成します。 次に、キャッシュが replicationGroup という名前の新しいアクティブ geo レプリケーション グループに追加されます。
az redisenterprise create --location "East US" --cluster-name "Cache1" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"
アクティブ geo レプリケーションを適切に構成するには、作成するキャッシュ インスタンスの ID を、--linked-databases
パラメーターを使用して追加する必要があります。 ID の形式は次のとおりです。
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
Azure CLI を使用して既存の geo レプリケーション グループに新しい Azure Managed Redis インスタンスを作成する
この例では、米国西部リージョンに Cache2 という新しい Balanced B10 キャッシュ インスタンスを作成します。 次に、前の手順で作成した replicationGroup
アクティブ geo レプリケーション グループにキャッシュを追加します。 このようにして、それは Cache1 を使用したアクティブ/アクティブ構成にリンクされます。
az redisenterprise create --location "West US" --cluster-name "Cache2" --sku "Balanced_B10" --resource-group "myResourceGroup" --group-nickname "replicationGroup" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default" --linked-databases id="/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"
前と同様に、--linked-databases
パラメーターを使用して Cache1 と Cache2 の両方を一覧表示する必要があります。
Azure PowerShell
Azure PowerShell を使用して、新しいキャッシュと geo レプリケーション グループを作成するか、既存の geo レプリケーション グループに新しいキャッシュを追加します。 詳細については、「New-AzRedisEnterpriseCache」をご覧ください。
PowerShell を使用して新しい geo レプリケーション グループに新しい Azure Managed Redis インスタンスを作成する
この例では、米国東部リージョンに Cache1 という新しい Azure Managed Redis Balanced B10 キャッシュ インスタンスを作成します。 次に、キャッシュが replicationGroup という名前の新しいアクティブ geo レプリケーション グループに追加されます。
New-AzRedisEnterpriseCache -Name "Cache1" -ResourceGroupName "myResourceGroup" -Location "East US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}'
アクティブ geo レプリケーションを適切に構成するには、作成するキャッシュ インスタンスの ID を、-LinkedDatabase
パラメーターを使用して追加する必要があります。 ID の形式は次のとおりです。
/subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>/providers/Microsoft.Cache/redisEnterprise/<your-cache-name>/databases/default
PowerShell を使用して既存の geo レプリケーション グループに新しい Azure Managed Redis インスタンスを作成する
この例では、米国西部リージョンに Cache2 という新しい Balanced B10 キャッシュ インスタンスを作成します。 次に、前の手順で作成したアクティブ geo レプリケーション グループ "replicationGroup" にキャッシュを追加します。 その結果、Cache1 と Cache2 という 2 つのキャッシュがアクティブ/アクティブ構成でリンクされます。
New-AzRedisEnterpriseCache -Name "Cache2" -ResourceGroupName "myResourceGroup" -Location "West US" -Sku "Balanced_B10" -GroupNickname "replicationGroup" -LinkedDatabase '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache1/databases/default"}', '{id:"/subscriptions/34b6ecbd-ab5c-4768-b0b8-bf587aba80f6/resourceGroups/myResourceGroup/providers/Microsoft.Cache/redisEnterprise/Cache2/databases/default"}'
前と同様に、-LinkedDatabase
パラメーターを使用して Cache1 と Cache2 の両方を一覧表示する必要があります。
geo レプリケーション グループ内のインスタンスのスケーリング
アクティブ geo レプリケーションを使用するように構成されたインスタンスをスケーリングできます。 ただし、異なるキャッシュ サイズが混在する geo レプリケーション グループでは問題が発生する可能性があります。 これらの問題の発生を防ぐには、geo レプリケーション グループ内のすべてのキャッシュのサイズとパフォーマンス レベルが同じである必要があります。
スケーリングにはサイズまたはレベルの変更が必要で、geo レプリケーション グループ内のすべてのインスタンスを同時にスケーリングすることは難しいため、Azure Managed Redis はロック メカニズムを備えています。 geo レプリケーション グループ内の 1 つのインスタンスをスケーリングすると、基になる VM がスケーリングされますが、他のインスタンスも同様にスケールアップされるまで、使用できるメモリは元のサイズに制限されます。 また、残りのインスタンスに対するその他のスケーリング操作は、スケーリングされる最初のキャッシュと同じ構成に一致するまでロックされます。
スケーリングの例
たとえば、geo レプリケーション グループに 3 つのインスタンスがあり、すべてメモリ最適化 M10 インスタンスであるとします。
インスタンス名 | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | メモリ最適化 M10 | メモリ最適化 M10 | メモリ最適化 M10 |
この geo レプリケーション グループ内の各インスタンスをコンピューティング最適化 X20 インスタンスにスケールアップするとします。 まず、キャッシュの 1 つを X20 にスケールアップします。
インスタンス名 | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | コンピューティング最適化 X20 | メモリ最適化 M10 | メモリ最適化 M10 |
この時点では、Redis01
インスタンスと Redis02
インスタンスは、コンピューティング最適化 X20 インスタンスにのみスケールアップできます。 他のすべてのスケーリング操作はブロックされます。
Note
この時点では、Redis00
インスタンスのさらなるスケーリングはブロックされていません。 ただし、Redis01
または Redis02
がコンピューティング最適化 X20 にスケーリングされるとブロックされます。
各インスタンスが同じレベルとサイズにスケーリングされると、すべてのスケーリング ロックが削除されます。
インスタンス名 | Redis00 | Redis01 | Redis02 |
---|---|---|---|
Type | コンピューティング最適化 X20 | コンピューティング最適化 X20 | コンピューティング最適化 X20 |
フラッシュ操作
不注意によるデータ損失の可能性があるため、geo レプリケーション グループに存在するキャッシュ インスタンスで FLUSHALL
および FLUSHDB
Redis コマンドを使用することはできません。 代わりに、[アクティブ geo レプリケーション] 作業ウィンドウの上部にある [キャッシュのフラッシュ] ボタンを使用します。
Azure CLI または PowerShell を使用してキャッシュをフラッシュする
Azure CLI と PowerShell を使用して、フラッシュ操作をトリガーすることもできます。 Azure CLI の使用の詳細については、「az redisenterprise database flush」を参照してください。 PowerShell の使用の詳細については、「Invoke-AzRedisEnterpriseCacheDatabaseFlush」を参照してください。
重要
[キャッシュのフラッシュ] 機能を使用する場合は注意してください。 ボタンを選択すると、現在のキャッシュと geo レプリケーション グループ内のすべてのリンクされたキャッシュからすべてのデータが削除されます。
Azure ロールベースのアクセス制御を使用して、この機能へのアクセスを管理してください。 許可されているユーザーのみに、すべてのキャッシュをフラッシュする権限を付与する必要があります。