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