Azure Managed Redis は、Redis Enterprise に基づくフル マネージドの Azure サービスです。 アプリケーションに高パフォーマンスのメモリ内データ ストレージを提供し、超低待機時間、高スループット、高度なデータ構造を必要とするエンタープライズ ワークロード向けに設計されています。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな潜在的な障害や問題に対する Azure Managed Redis の回復性を確保する方法について説明します。 また、バックアップ戦略とサービス レベル アグリーメント (SLA) についても説明します。
運用環境のデプロイに関する推奨事項
運用環境の Azure Managed Redis インスタンスの高い信頼性を確保するには、次のことをお勧めします。
高可用性を使用して、キャッシュに複数のノードをデプロイします。
可用性ゾーンがあるリージョンに高可用性キャッシュをデプロイすることで、ゾーンの冗長性を使用します。
リージョン間フェールオーバーを必要とするミッション クリティカルなワークロードに対してアクティブ geo レプリケーションを実装することを検討してください。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
Azure Managed Redis は Redis Enterprise 上に構築されており、高可用性の構成とレプリケーション機能を通じて信頼性を提供します。
Azure Managed Redis の インスタンス ( キャッシュ インスタンス または キャッシュとも呼ばれます) をデプロイします。 クライアント アプリケーションは、Redis API を使用してキャッシュ内のデータを格納および操作します。
物理アーキテクチャ
Azure Managed Redis で回復性を計画する場合は、ノードとシャードの主要な概念を理解する必要があります。
ノード： 各キャッシュ インスタンスは、仮想マシン (VM) である ノードで構成されます。 各 VM は、クラスター内の独立したコンピューティング ユニットとして機能します。 ユーザーが VM を直接表示したり管理したりすることはありません。 プラットフォームは、インスタンスを自動的に作成し、インスタンスの正常性を監視し、異常になったインスタンスを置き換えます。 この一連の VM がクラスターを形成 します。
高可用性のためにインスタンスを設定できます。 高可用性を使用すると、Azure Managed Redis によって、インスタンスに少なくとも 2 つのノードが確実に存在し、それらの間でデータが自動的にレプリケートされます。 可用性ゾーンがあるリージョンでは、サービスによってノードが異なる可用性ゾーンに配置されます。 詳細については、「 可用性ゾーンの障害に対する回復性」を参照してください。
サービスは、複雑さを回避し、最適な構成を確保するために、各構成の特定の数のノードを抽象化します。
シャード： 各ノードは シャードと呼ばれる複数の Redis サーバー プロセスを実行します。 各シャードは、キャッシュのデータのサブセットを管理します。 高可用性のためにキャッシュを設定すると、シャードはノード間で自動的に分散およびレプリケートされます。 クラスター ポリシーを指定すると、シャードがノード間でどのように分散されるかが決まります。
詳細については、 Azure Managed Redis のアーキテクチャ と フェールオーバーと Azure Managed Redis の修正プログラムの適用に関するページを参照してください。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Azure Managed Redis を使用するときに一時的な障害を管理するには、次の推奨事項に従います。
一時的な障害が発生したときに自動的に再試行し、適切なバックオフとタイムアウト期間を適用する SDK 構成を使用します。 アプリケーションで 再試行パターン と サーキット ブレーカー パターン を使用することを検討してください。
キャッシュアサイド パターンの設計。Redis が一時的に使用できなくなったときにプライマリ データ ストアにフォールバックすることで、アプリケーションのパフォーマンスが低下して動作し続けることができます。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure Managed Redis Cache インスタンスの ゾーン冗長化を行うと、リージョン内の複数の可用性ゾーンにキャッシュ ノードが自動的に分散されます。 ゾーンの冗長性により、データセンターまたは可用性ゾーンの停止によってキャッシュが使用できなくなるリスクが軽減されます。
キャッシュ ゾーンを冗長にするには、サポートされているリージョンにデプロイし、高可用性構成を使用するように設定する必要があります。 可用性ゾーンのないリージョンでは、高可用性構成によって少なくとも 2 つのノードが作成されますが、個別のゾーンには配置されません。
次の図は、2 つのノードを持つゾーン冗長キャッシュを示しています。各ノードは個別のゾーンにあります。
Requirements
リージョンのサポート: ゾーン冗長 Azure Managed Redis キャッシュは、可用性ゾーンをサポートし、サービスが利用可能な任意のリージョンにデプロイできます。 可用性ゾーンをサポートするリージョンの一覧については、可用性ゾーン を持つ Azure リージョンを参照してください。 Azure Managed Redis をサポートするリージョンの一覧については、「 リージョン別の製品の可用性」を参照してください。
高可用性の構成: ゾーン冗長にするには、キャッシュで高可用性構成を使用する必要があります。
層： すべての Azure Managed Redis レベルでは、可用性ゾーンがサポートされています。
費用
ゾーン冗長では、高可用性のためにキャッシュを設定する必要があります。この場合、キャッシュ用に少なくとも 2 つのノードがデプロイされます。 高可用性構成では、高可用性以外の構成よりもコストがかかります。 詳細については、 Azure Managed Redis の価格に関するページを参照してください。
可用性ゾーンのサポートを設定する
新しいゾーン冗長インスタンスを作成します。 新しい Azure Managed Redis インスタンスを作成するときは、高可用性構成を使用して、可用性ゾーンをサポートするリージョンにデプロイします。 インスタンスには既定でゾーン冗長性が含まれています。追加の構成は必要ありません。
詳細については、「 Azure Managed Redis インスタンスの作成」を参照してください。
既存のインスタンス ゾーンを冗長にします。 既存の Azure Managed Redis インスタンス ゾーンを冗長にするには、可用性ゾーンをサポートするリージョンにデプロイし、キャッシュに高可用性を設定します。
ゾーンの冗長性をオフにします。 既存のインスタンスでゾーンの冗長性を無効にすることはできません。これは、高可用性をキャッシュに適用した後に元に戻すことはできません。
容量の計画と管理
ゾーンダウン イベント中に、インスタンスでワークロードに対応できるリソースが少なくなる場合があります。 インスタンスでリソースの負荷が頻繁に発生し、可用性ゾーンの障害に備える必要がある場合は、次のいずれかの方法を検討してください。
インスタンスをオーバープロビジョニングします。 インスタンスが容量の損失を許容し、パフォーマンスを低下させることなく引き続き機能できるように、必要以上のパフォーマンス レベルを選択します。 詳細については、Azure Managed Redis インスタンスのオーバープロビジョニングとスケーリングによる容量の管理に関するページを参照してください。
アクティブな地理的レプリケーションを使用します。 異なるリージョンに複数のインスタンスをデプロイし、 アクティブ geo レプリケーション を設定して、それらの個別のインスタンスに負荷を分散させることができます。
すべてのゾーンが正常な場合の動作
このセクションでは、マネージド Redis キャッシュがゾーン冗長であり、すべての可用性ゾーンが正常に動作する場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: Azure Managed Redis は、クラスター ポリシーに基づいてノード間でシャードを分散します。 また、クラスター ポリシーによって、トラフィックが各ノードにルーティングされる方法も決定されます。 ゾーンの冗長性によって、サービスによるトラフィックのルーティング方法は変わりません。
ゾーン間のデータ レプリケーション: Azure Managed Redis では、非同期レプリケーションを使用してノード間でシャードが自動的にレプリケートされます。 通常、シャード間のレプリケーションのラグを秒単位で測定しますが、正確な期間はキャッシュのワークロードによって異なります。 書き込み負荷が高く、ネットワーク負荷の高いシナリオでは、通常、レプリケーションの遅延が高くなります。
ゾーン障害時の動作
このセクションでは、マネージド Redis キャッシュがゾーン冗長であり、1 つ以上の可用性ゾーンが使用できなくなった場合に想定される内容について説明します。
- 検出と応答: Azure Managed Redis は、可用性ゾーンの障害を検出する役割を担います。 ゾーンのフェールオーバーを開始するために何もする必要はありません。
- 通知： ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
アクティブな要求: サービスは、インフライト要求を削除する可能性があり、アプリケーションはそれらを再試行する必要があります。 アプリケーションでは、これらの一時的な中断を処理するための 再試行ロジックを実装 する必要があります。
予想されるデータ損失: 別のゾーンのシャードにレプリケートされていないデータは、ゾーン障害時に失われる可能性があります。 通常、データ損失の量は秒単位で測定しますが、レプリケーションのラグによって異なります。
予想されるダウンタイム: シャードが正常なゾーン内のノードにフェールオーバーする間、少しのダウンタイム (通常は 10 ~ 15 秒) が発生する可能性があります。 計画されていないフェールオーバー プロセスの詳細については、「 フェールオーバーの説明」を参照してください。 アプリケーションを設計するときは、 一時的な障害処理のプラクティスに従ってください。
トラフィックの再ルーティング: Azure Managed Redis は、正常なゾーン内のノードにトラフィックを自動的にリダイレクトします。
ゾーンの回復
影響を受ける可用性ゾーンが復旧すると、Azure Managed Redis はそのゾーンに操作を自動的に復元します。 Azure プラットフォームは、このプロセスを完全に管理し、顧客の介入を必要としません。
ゾーンエラーのテスト
Azure Managed Redis は、ゾーン障害のトラフィック ルーティング、フェールオーバー、フェールバックを完全に管理するため、可用性ゾーンの障害プロセスを検証したり、それ以上入力したりする必要はありません。
リージョン全体の障害に対する回復性
Azure Managed Redis では、 アクティブ geo レプリケーションによるネイティブマルチリージョンのサポートが提供されます。これにより、異なる Azure リージョン間で複数の Azure Managed Redis インスタンスを 1 つのレプリケーション グループにリンクできます。 その後、インスタンス間で独自のフェールオーバー アプローチを設定できます。
アクティブ geo レプリケーション
アクティブ geo レプリケーションを使用すると、アプリケーションはグループ内の任意のキャッシュ インスタンスとの間で読み取りと書き込みを行うことができます。変更はすべてのリージョンで自動的に同期されます。 このサービスでは、アクティブ/アクティブ レプリケーション パターンがサポートされています。このパターンでは、各リージョンで読み取り操作と書き込み操作の両方を同時に処理できます。 異なるリージョンでの同時書き込みが原因で競合が発生した場合、サービスは、手動による介入を必要とせずに、事前に定義された競合解決アルゴリズムを使用して自動的に解決します。 この方法では、グローバル分散アプリケーションの低待機時間アクセスを維持しながら、リージョンの障害に対する回復性が提供されます。
次の図は、同じアクティブ geo レプリケーション グループ内の異なるリージョンにある 2 つのキャッシュ インスタンスと、各キャッシュ インスタンスに接続するクライアント アプリケーションを示しています。
リージョン インスタンスが失敗した場合に正常なインスタンスに要求をリダイレクトするようにクライアント アプリケーションを設定する必要があります。 次の図は、通常使用するインスタンスが失敗したときに、アプリケーションが正常なキャッシュ インスタンスに要求をリダイレクトする方法を示しています。
Requirements
リージョンのサポート: サービスが利用可能な任意の Azure リージョン間で Azure Managed Redis のアクティブ geo レプリケーションを設定できます。
インスタンスの構成: アクティブ geo レプリケーションでは、参加しているすべてのリージョンで同じレベルとサイズを使用する Azure Managed Redis インスタンスが必要です。 レプリケーション グループ内のすべてのキャッシュ インスタンスでは、永続化オプション、モジュール、クラスタリング ポリシーなど、同じ設定を使用する必要があります。
その他の要件: キャッシュ インスタンスは、使用するモジュールなど、他の要件を満たしている必要があります。 これらの要件は、キャッシュ インスタンスのスケーリング方法に影響します。 詳細については、アクティブ ジオ レプリケーションの前提条件を参照してください。
考慮事項
フェールオーバーの責任: アクティブ geo レプリケーションを使用する場合は、 キャッシュ インスタンス間のフェールオーバーを担当します。 フェールオーバーを処理するアプリケーションを準備します。 フェールオーバーには準備が必要であり、複数の手順を実行する必要がある場合があります。 詳細については、「 リージョンの停止中にリンクを強制解除する」を参照してください。
最終的な整合性: ネットワークの状態や地理的な距離によっては、変更がすべてのリージョンに反映されるまでに時間がかかる可能性があるため、最終的な整合性シナリオを処理するようにアプリケーションを設計します。 リージョンの停止中に、接続が復元されて同期が完了するまで、データの不整合が増える可能性があります。
費用
アクティブ geo レプリケーションを設定すると、レプリケーション グループ内のすべてのリージョンの Azure Managed Redis インスタンスごとに料金が発生します。 リージョン間のリージョン間レプリケーション トラフィックに対するデータ転送料金が発生する場合もあります。 詳細については、 Azure Managed Redis の価格 と帯域幅の価格の詳細に関する ページを参照してください。
複数リージョンのサポートを構成する
新しい geo レプリケート キャッシュ インスタンスを作成します。 レプリケーション グループを指定し、複数のインスタンスをリンクすることで、キャッシュをプロビジョニングするときにアクティブ geo レプリケーションを設定します。 詳細については、「 アクティブ geo レプリケーション グループの作成または参加」を参照してください。
geo レプリケーション グループに既存のキャッシュ インスタンスを追加します。 既存のキャッシュ インスタンスをアクティブ geo レプリケーション グループに追加できます。
アクティブ geo レプリケーション グループに既存のインスタンスを追加する場合、プラットフォームはインスタンス内のデータをクリアする必要があり、少しのダウンタイムが発生します。 可能であれば、キャッシュ インスタンスを作成するときにアクティブ geo レプリケーションを設定することを計画してください。
詳細については、「 アクティブ geo レプリケーション グループに既存のインスタンスを追加する」を参照してください。
キャッシュ インスタンスでの geo レプリケーションを無効にします。 キャッシュ インスタンスを削除して、geo レプリケーション グループからインスタンスを削除します。 残りのインスタンスは自動的に設定を調整します。
容量の計画と管理
リージョンダウン イベント中に、他のインスタンスの負荷が高くなる可能性があります。 インスタンスがリソース制限に近い状態で実行されることが多く、リージョンの障害時に容量要件の増加に備える必要がある場合は、 インスタンスのオーバープロビジョニングを検討してください。 詳細については、「 Azure Managed Redis インスタンスのスケーリング」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、アクティブ geo レプリケーションを使用するようにインスタンスを設定し、すべてのリージョンが正常に動作するように設定する場合の動作について説明します。
リージョン間のトラフィック ルーティング: 特定のキャッシュ インスタンスに接続するようにアプリケーションを設定する必要があります。 アプリケーションは、レプリケーション グループ内の任意のキャッシュ インスタンスに接続し、読み取り操作と書き込み操作の両方を実行できます。 アプリケーションはトラフィック ルーティングを処理します。これにより、クライアントを最も近いリージョンに転送して待機時間を最小限に抑えることができます。 Azure Managed Redis では、リージョン間でトラフィックが自動的にルーティングされることはありません。
リージョン間のデータ レプリケーション: このサービスでは、リージョン間の非同期レプリケーションを使用して、最終的な一貫性を維持します。 ローカル リージョンで書き込み操作が直ちにコミットされ、バックグラウンドで他のリージョンに反映されます。 競合のないレプリケートされたデータ型 (CRDT) により、サービスは異なるリージョンの同時書き込みを自動的にマージします。
リージョン障害時の動作
このセクションでは、アクティブ geo レプリケーションを使用するようにインスタンスを設定し、1 つのリージョンで停止が発生した場合に想定される内容について説明します。
検出と応答: キャッシュ インスタンスの障害を検出し、フェールオーバーするタイミングを決定する必要があります。 ジオレプリケーションされたクラスターの状態を監視することで、フェールオーバーを開始するタイミングを決定するのに役立ちます。 詳細については、「 geo レプリケーション メトリック」を参照してください。
フェールオーバーでは、複数の手順を実行する必要があります。 詳細については、「 リージョンの停止中にリンクを強制解除する」を参照してください。
通知： リージョンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
各インスタンスの正常性を監視することもできます。
geo レプリケーションリレーションシップの正常性を監視するには、 geo レプリケーションの正常な メトリックを使用します。 メトリックの値は常に
1(正常) または0(異常) です。 このメトリックに対して Azure Monitor アラートを設定して、インスタンスが同期されていない可能性があるタイミングを特定します。アクティブな要求: サービスは失敗したリージョンへの要求を終了し、アプリケーションのフェールオーバー ロジックで要求を処理する必要があります。 アプリケーションでは、トラフィックを正常なキャッシュにリダイレクトできる再試行ポリシーを実装する必要があります。
予想されるデータ損失: リージョン間の非同期レプリケーションでは、それらの書き込みが他のリージョンにレプリケートされていない場合、失敗したリージョンへの最近の書き込みが失われる可能性があります。 潜在的なデータ損失の量は、障害発生時のレプリケーションのラグによって異なります。 詳細については、アクティブ/アクティブのジオ分散Redisおよび競合のないレプリケーションデータベース（CRDB）のリージョン障害に関する整合性とデータ損失の考慮事項を参照してください。
予想されるダウンタイム: アプリケーションでは、障害を検出し、トラフィックを正常なリージョンにリダイレクトするために必要な期間だけダウンタイムが発生します。 このダウンタイムは通常、数秒から数分の範囲であり、アプリケーションの正常性チェックとフェールオーバーの構成の設定方法によって異なります。
トラフィックの再ルーティング: リージョンの障害を検出し、トラフィックを正常なリージョンにルーティングするロジックをアプリケーションに実装する必要があります。 このロジックは、正常性チェック、サーキット ブレーカー パターン、または外部負荷分散ソリューションを使用して実装できます。
リージョンの復旧
障害が発生したリージョンが復旧すると、Azure Managed Redis は、ユーザーの介入なしに、そのリージョン内のインスタンスをアクティブ geo レプリケーション グループに自動的に再統合します。 サービスは、正常なインスタンスのデータを自動的に同期します。 このプロセス中に、復旧されたインスタンスは、停止中に発生した変更を徐々に同期します。 同期が完了すると、復旧されたインスタンスは完全にアクティブになり、読み取り操作と書き込み操作の両方を処理できます。
復旧されたリージョン インスタンスにトラフィックをルーティングするようにアプリケーションを再構成する必要があります。
リージョン障害のテスト
アプリケーションのフェールオーバー手順を定期的にテストします。 アプリケーションは、インスタンス間でフェールオーバーでき、移行中のダウンタイムに関するビジネス要件を満たす必要があります。 また、ファイアウォールやその他のインフラストラクチャの再構成や復旧プロセスなど、全体的な応答プロセスもテストします。
サービス メンテナンスに対する回復性
Azure Managed Redis は、通常のサービス アップグレードやその他のメンテナンス タスクを処理します。
メンテナンス中、Azure Managed Redis は自動的に新しいノードを作成し、フェールオーバーします。 クライアント アプリケーションでは、接続の中断やその他の一時的な障害が発生する可能性があります。 アプリケーションでは、これらの一時的な中断を処理するための 再試行ロジックを実装 する必要があります。
Azure Managed Redis のメンテナンス プロセスの詳細については、「Azure Managed Redis のフェールオーバーと修正プログラムの適用」を参照してください。
バックアップと復元
Azure Managed Redis には、データの永続化とバックアップの両方の機能が用意されており、他の信頼性機能では対処できない可能性があるデータ損失シナリオから保護します。 バックアップは、データの破損、誤った削除、構成エラーなどのシナリオから保護します。
データの永続化: 既定では、Azure Managed Redis はすべてのキャッシュ データをメモリに格納します。 サービスは、必要に応じて、データ 永続化を使用してデータのスナップショットをディスクに書き込むことができます。 ハードウェア障害がノードに影響を与える場合、Azure Managed Redis によってデータが自動的に復元されます。 さまざまな種類のデータ永続化から選択できます。スナップショットの頻度とキャッシュに対するパフォーマンスの影響とのトレードオフが異なります。
データ ファイルを別のインスタンスに復元することも、ファイルにアクセスすることもできません。 データの永続化によって、データの破損や偶発的な削除から保護されることはありません。
インポートとエクスポート: Azure Managed Redis では、 インポートおよびエクスポート機能を使用するときにデータのバックアップがサポートされます。これにより、バックアップ ファイルが Azure Blob Storage に保存されます。 サポートされているリージョンの Azure Storage アカウントに geo 冗長ストレージ (GRS) を設定することも、バックアップ BLOB をコピーまたは他の場所に移動してさらに保護することもできます。
エクスポートしたファイルは、同じキャッシュ インスタンスまたは別のキャッシュ インスタンスに復元できます。
このサービスには組み込みのインポートまたはエクスポート スケジューラは含まれていませんが、Azure CLI または Azure PowerShell を使用してエクスポート操作を開始する独自の自動化プロセスを開発できます。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。
Azure Managed Redis の SLA では、キャッシュ エンドポイントへの接続について説明します。 データ損失からの保護には対応していません。
Azure Managed Redis の可用性 SLA の対象にするには、次の要件を満たす必要があります。
高可用性構成を使用する必要があります。
一時的な使用不能を生み出すために文書化されている製品の機能や管理アクションを開始しないでください。
高可用性 SLA は、インスタンスがゾーン冗長である場合に適用されます。 一部のレベルでは、アクティブ geo レプリケーションを使用してゾーン冗長インスタンスを少なくとも 3 つのリージョンにデプロイすると、より高い可用性 SLA を受けることができます。