高可用性とディザスター リカバリー
他のクラウドシステムと同様に、計画外の停止が発生すると、仮想マシン (VM) インスタンス、可用性ゾーン、または Azure リージョン全体がダウンする可能性があります。 お客様には、ゾーンまたはリージョンの停止に対処するための計画を策定しておくことをお勧めします。
この記事では、お客様が Azure Cache for Redis または Azure Cache for Redis Enterprise の実装用に "事業継続とディザスター リカバリー計画" を策定するための情報を提供します。
Standard、Premium、および Enterprise レベルで、さまざまな高可用性オプションを使用することができます。
| オプション | 説明 | 可用性 | Standard | Premium | エンタープライズ |
|---|---|---|---|---|---|
| 標準のレプリケーション | 単一のデータセンターでのデュアルノードのレプリケートされた構成 (自動フェールオーバーあり) | 99.9% (詳細を参照) | ✔ | ✔ | ✔ |
| ゾーン冗長性 | 可用性ゾーン間でレプリケートされたマルチノード構成 (自動フェールオーバーあり) | Premium 99.9%、Enterprise 99.99% (詳細を参照) | - | ✔ | ✔ |
| geo レプリケーション | 2 つのリージョンでのリンクされたキャッシュ インスタンス (ユーザー制御のフェールオーバーあり) | Premium、Enterprise (詳細を参照) | - | パッシブ | アクティブ |
| Import/Export | キャッシュ内の特定の時点のスナップショット。 | 99.9% (詳細を参照) | - | ✔ | ✔ |
| 永続化 | ストレージ アカウントへの定期的なデータ保存。 | 99.9% (詳細を参照) | - | ✔ | プレビュー |
高可用性のための標準のレプリケーション
適用対象レベル: Standard、Premium、Enterprise、Enterprise Flash
推奨対象: 高可用性
Azure Cache for Redis は、停止によって基になる仮想マシン (VM) が影響を受けた場合でも、マネージド インスタンスが機能することを保証する高可用性アーキテクチャを備えています。 停止が計画済みまたは計画外の停止であるかどうかにかかわらず、Azure Cache for Redis では、単一の VM で Redis をホストすることで達成できる割合よりも高い可用性率を提供します。
適応できるレベルのAzure Cache for Redis は、既定では 1 組の Redis サーバーで実行されます。 2 台のサーバーは専用の VM 上でホストされます。 オープンソースの Redis を使用すれば、1 台のサーバーだけでデータ書き込み要求を処理できます。
Azure Cache for Redis を使用する場合、一方のサーバーが "プライマリ" ノードになり、もう一方のサーバーが "レプリカ" になります。 サーバー ノードのプロビジョニング後に、Azure Cache for Redis によってプライマリおよびレプリカ ロールが割り当てられます。 通常、プライマリ ノードは、クライアントからの書き込みおよび読み取り要求の処理を担当します。 書き込み操作で、新しいキーとキーの更新をその内部メモリにコミットし、クライアントにすぐに応答します。 操作を "レプリカ" に非同期に転送します。
Note
通常、Azure Cache for Redis クライアント アプリケーションは、すべての読み取りおよび書き込み要求について、キャッシュ内のプライマリ ノードと通信を行います。 レプリカ ノードから読み取るように、特定のクライアントを構成することができます。
キャッシュ内の "プライマリ" ノードが使用できない場合、"レプリカ" は自動的に自身をレベルを上げて新しいプライマリになります。 このプロセスは "フェールオーバー" と呼ばれます。 フェールオーバーは、プライマリ/レプリカ、取引ロール、レプリカ/プライマリの 2 つのノードのみであり、ノードの 1 つが数分間オフラインになる可能性があります。 ほとんどのフェールオーバーでは、プライマリ ノードとレプリカ ノードがハンドオーバーを調整するため、プライマリなしでほぼ 0 時間が発生します。
前者のプライマリは、新しいプライマリから更新プログラムを受け取るために一時的にオフラインになります。 次に、現在のレプリカがオンラインに戻り、完全に同期されたキャッシュに再び参加します。 重要なのは、ノードが使用できない場合は一時的な状態であり、オンラインに戻るということです。
メンテナンスのためにプライマリがダウンする必要がある場合、一般的なフェールオーバー シーケンスは次のようになります：
- プライマリ ノードとレプリカ ノードは、調整されたフェールオーバーとトレード ロールをネゴシエートします。
- レプリカ (以前のプライマリ) は、再起動のためにオフラインになります。
- 数秒または数分後に、レプリカがオンラインに戻ります。
- レプリカは、プライマリからのデータを同期します。
プライマリ ノードは、Redis ソフトウェアやオペレーティング システムの更新などの計画メンテナンス アクティビティの一環としてサービスを停止する場合があります。 また、基になるハードウェア、ソフトウェア、またはネットワークでの障害など、計画外のイベントが原因で動作を停止することもあります。 フェールオーバーの種類については、「Azure Cache for Redis のフェールオーバーと修正プログラムの適用」で詳しく説明しています。 Azure Cache for Redis により、その有効期間中に多くのフェールオーバーが確認されます。 高可用性アーキテクチャの設計によって、キャッシュの内部でのこれらの変更が、そのクライアントに対して可能な限り透過的になります。
また、Premium レベルの場合、Azure Cache for Redis にはより多くのレプリカ ノードが提供されます。 複数レプリカのキャッシュは、最大 3 つのレプリカ ノードで構成できます。 一般に、レプリカが増えると、プライマリをバックアップするノードがあるため、回復性が向上します。 レプリカが増えても、データ センターまたは可用性ゾーンの停止によって、Azure Cache for Redis インスタンスが大きな影響を受ける可能性があります。 複数のレプリカをゾーン冗長性と共に使用することで、キャッシュの可用性を向上させることができます。
ゾーン冗長性
適用対象レベル: Premium、Enterprise、Enterprise Flash
推奨対象: 高可用性、ディザスター リカバリー - リージョン内
Azure Cache for Redis によって、Premium レベルと Enterprise レベルでのゾーン冗長構成がサポートされます。 ゾーン冗長キャッシュを使用すると、同じリージョン内の異なる Azure Availability Zones にわたってノードを配置できます。 これにより、データセンターまたは AZ の停止が単一障害点となることが回避され、キャッシュの全体的な可用性が向上します。 これを設定する方法については、この記事を参照してください。
この記事で前述のとおり、2 つ以上のゾーンを使用するようにキャッシュを構成すると、キャッシュ ノードは異なるゾーンに作成されます。 あるゾーンがダウンすると、他のゾーンのキャッシュ ノードが使用可能になり、キャッシュは通常どおり機能し続けることができます。
Azure Cache for Redis によって、Premium レベルと Enterprise レベルでのゾーン冗長構成がサポートされます。 ゾーン冗長キャッシュを使用すると、同じリージョン内の異なる Azure Availability Zones にわたってノードを配置できます。 これにより、データ センターまたは可用性ゾーンの停止が単一障害点になることはなくなり、キャッシュの全体的な可用性が向上します。
Premium レベル
次の図は、Premium レベルのゾーン冗長の構成を示しています。
Azure Cache for Redis によって、ゾーン冗長キャッシュ内のノードが、選択された可用性ゾーンにラウンドロビン方式で分散されます。 また、最初にプライマリとして機能するノードが決定されます。
Premium レベルのゾーン ダウン エクスペリエンス
ゾーン冗長キャッシュによって自動フェールオーバーが提供されます。 現在のプライマリ ノードが使用できない場合、レプリカの 1 つに引き継がれます。 新しいプライマリ ノードが異なる AZ に配置されている場合、アプリケーションでのキャッシュ応答時間が長くなる可能性があります。 可用性ゾーンは、地理的に分離されています。 AZ を切り替えると、アプリケーションとキャッシュがホストされている場所の間の物理的な距離が変わります。 この変更は、アプリケーションからキャッシュへのラウンドトリップ ネットワークの待機時間に影響します。 余分な待機時間は、ほとんどのアプリケーションで許容範囲内に収まることが想定されます。 アプリケーションをテストして、ゾーン冗長キャッシュが適切に機能するかどうかを確認することをお勧めします。
Enterprise レベルと Enterprise Flash レベル
いずれかの Enterprise レベルのキャッシュは、Redis Enterprise "クラスター" で実行されます。 クォーラムを形成するには、常に奇数個のサーバー ノードが必要です。 既定では、3 つのノードがあり、それぞれが専用の VM でホストされています。
- Enterprise キャッシュには、2 つの同じサイズのデータ ノードと、それよりも小さな 1 つのクォーラム ノードがあります。
- Enterprise Flash キャッシュには、3 つの同じサイズのデータ ノードがあります。
Enterprise クラスターでは、内部的に Azure Cache for Redis データがパーティションに分割されます。 各パーティションには 1 つのプライマリと、少なくとも 1 つのレプリカがあります。 各データ ノードは、1 つまたは複数のパーティションを保持します。 Enterprise クラスターによって、プライマリと任意のパーティションのレプリカが、同じデータ ノードに併置されないことが保証されます。 パーティションは、プライマリから対応するレプリカにデータを非同期的にレプリケートします。
Enterprise レベルのゾーン ダウン エクスペリエンス
データ ノードが使用できなくなった場合、またはネットワークの分割が発生した場合、「標準のレプリケーション」に記載されているようなフェールオーバーが行われます。 Enterprise クラスターでは、クォーラムベースのモデルを使用して、新しいクォーラムに参加する残りのノードを決定します。 また、必要に応じて、これらのノード内のレプリカ パーティションをプライマリに昇格させます。
リージョン別の提供状況
ゾーン冗長 Premium レベルは、次のリージョンで使用可能です。
| アメリカ | ヨーロッパ | 中東 | アフリカ | アジア太平洋 |
|---|---|---|---|---|
| ブラジル南部 | フランス中部 | カタール中部 | 南アフリカ北部 | オーストラリア東部 |
| カナダ中部 | ドイツ中西部 | インド中部 | ||
| 米国中部 | 北ヨーロッパ | 東日本 | ||
| 米国東部 | ノルウェー東部 | 韓国中部 | ||
| 米国東部 2 | 英国南部 | 東南アジア | ||
| 米国中南部 | 西ヨーロッパ | 東アジア | ||
| US Gov バージニア州 | スウェーデン中部 | China North 3 | ||
| 米国西部 2 | スイス北部 | |||
| 米国西部 3 |
ゾーン冗長 Enterprise および Enterprise Flash レベルのキャッシュは、次のリージョンで使用可能です。
| アメリカ | ヨーロッパ | 中東 | アフリカ | アジア太平洋 |
|---|---|---|---|---|
| カナダ中部* | 北ヨーロッパ | オーストラリア東部 | ||
| 米国中部* | 英国南部 | インド中部 | ||
| 米国東部 | 西ヨーロッパ | 東南アジア | ||
| 米国東部 2 | 東日本* | |||
| 米国中南部 | 東アジア* | |||
| 米国西部 2 | ||||
| 米国西部 3 | ||||
| ブラジル南部 |
* このリージョンでは、Enterprise Flash レベルは使用できません。
可用性ゾーンの再デプロイと移行
現時点では、キャッシュを AZ 以外の構成から AZ 構成に変換する唯一の方法は、キャッシュを再デプロイすることです。 現在のキャッシュを再デプロイする方法については、「Azure Cache for Redis のインスタンスを可用性ゾーンのサポートに移行する」を参照してください。
永続性
適用対象レベル: Premium、Enterprise(プレビュー)、Enterprise Flash(プレビュー)
推奨対象: データの持続性
キャッシュ データはメモリに格納されるため、まれに発生する複数ノードの計画外の障害によって、すべてのデータが削除される可能性があります。 データが完全に失われるのを回避するために、Redis の永続性を使用することにより、メモリ内のデータのスナップショットを定期的に作成し、ストレージ アカウントに格納することができます。 複数のノードで障害が発生し、それに起因してデータ損失が発生すると、キャッシュによってストレージ アカウントからスナップショットが読み込まれます。 詳細については、「Premium Azure Cache for Redis インスタンスのデータ永続化の構成」を参照してください。
永続化用のストレージ アカウント
永続化されたデータの高可用性を確保するために、geo 冗長ストレージ アカウントを選択することを検討してください。 詳細については、「Azure Storage の冗長性」を参照してください。
インポート/エクスポート
適用対象レベル: Premium、Enterprise、Enterprise Flash
推奨対象: ディザスター リカバリー
Azure cache for Redis では、データの移植性を提供するために、Redis データベース (RDB) ファイルをインポートおよびエクスポートするオプションがサポートされています。 これを使用すると、RDB スナップショットを使用してデータを Azure Cache for Redis にインポートするか、Azure Cache for Redis からエクスポートすることができます。 Premium キャッシュからの RDB スナップショットは、Azure Storage アカウント内の BLOB にエクスポートされます。 ストレージ アカウントへのエクスポートを定期的にトリガーするスクリプトを作成できます。 詳細については、「Azure Cache for Redis でデータをインポートまたはエクスポートする」を参照してください。
エクスポート用のストレージ アカウント
エクスポートされたデータの高可用性を確保するために、geo 冗長ストレージ アカウントを選択することを検討してください。 詳細については、「Azure Storage の冗長性」を参照してください。
パッシブ geo レプリケーション
適用対象レベル: Premium
推奨対象: ディザスター リカバリー - 単一リージョン
geo レプリケーションは 2 つ以上の Azure Cache for Redis インスタンスをリンクするためのメカニズムであり、通常 2 つの Azure リージョンにまたがります。 geo レプリケーションは主にリージョン間のディザスター リカバリーのために設計されています。 Premium レベルの 2 つのキャッシュ インスタンスは、geo レプリケーションを介して、プライマリ キャッシュに対して読み取りと書き込みを行うように接続され、そのデータはセカンダリ キャッシュにレプリケートされます。
設定方法については、「Premium Azure Cache for Redis インスタンスの geo レプリケーションを構成する」を参照してください。
プライマリ キャッシュをホストしているリージョンがダウンした場合、フェールオーバーを開始する必要があります。まず、セカンダリ キャッシュのリンクを解除し、読み取りと書き込みにセカンダリ キャッシュのポイントを使用するようにアプリケーションを更新します。
アクティブな地理的レプリケーション
適用対象レベル: Enterprise、Enterprise Flash
推奨対象: 高可用性、ディザスター リカバリー - マルチリージョン
Enterprise レベルでは、複数のリージョンにわたる高可用性とリージョン間のディザスター リカバリーの両方を提供する、アクティブ geo レプリケーションと呼ばれるより高度な形式の geo レプリケーションがサポートされています。 Azure Cache for Redis Enterprise ソフトウェアでは、競合のないレプリケートされたデータ型を使用して、複数のキャッシュ インスタンスへの書き込みのサポート、変更のマージ、競合の解決を行います。 異なる Azure リージョン内の最大 5 つの Enterprise レベルのキャッシュ インスタンスを参加させて、geo レプリケーション グループを形成することができます。
このようなキャッシュを使用するアプリケーションは、対応するエンドポイントを経由して、地理的に分散された任意のキャッシュ インスタンスに対して読み取りと書き込みを行うことができます。 このアプリケーションでは、各アプリケーション インスタンスに最も近いものを使用する必要があります。これにより、待機時間が最も短くなります。 詳細については、「Enterprise Azure Cache for Redis インスタンスのアクティブ geo レプリケーションを構成する」を参照してください。
レプリケーション グループ内にあるいずれかのキャッシュのリージョンがダウンした場合、アプリケーションでは、使用可能な別のリージョンに切り替える必要があります。
レプリケーション グループ内のキャッシュが使用できない場合、同じレプリケーション グループ内にある他のキャッシュのメモリ使用量を監視することをお勧めします。 いずれかのキャッシュがダウンしている間、レプリケーション グループ内にある他のすべてのキャッシュでは、ダウンしているキャッシュと共有できなかったメタデータの保存が開始されます。 いずれかのキャッシュがダウンした後、使用可能なキャッシュのメモリ使用量が急速に増加し始めた場合、使用できないキャッシュのリンクをレプリケーション グループから削除することを検討してください。
強制リンク解除の詳細については、「リージョンが停止した場合の強制リンク解除」を参照してください。
キャッシュの削除と再作成
適用対象レベル: Standard、Premium、Enterprise、Enterprise Flash
リージョンの停止が発生した場合、別のリージョンでキャッシュを再作成して、代わりに新しいキャッシュに接続するようにアプリケーションを更新することを検討してください。 リージョンの停止中にデータが失われることを理解しておくことが重要です。 アプリケーション コードは、データ損失に対して回復力を備えている必要があります。
影響を受けるリージョンが復元されると、使用できない Azure Cache for Redis が自動的に復元され、再び使用できるようになります。 キャッシュを別のリージョンに移動するための他の戦略については、「Azure Cache for Redis インスタンスを別のリージョンに移動する」を参照してください。
次の手順
Azure Cache for Redis の高可用性オプションを構成する方法について学習します。