Azure Managed Redis は、完全に統合されたマネージド Redis Enterprise on Azure を提供し、アプリケーション用の高パフォーマンスのメモリ内データ ストレージを提供します。 このサービスは、超低待機時間、高スループット、高度なデータ構造を必要とするエンタープライズ ワークロード向けに構築されています。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの障害、リージョン全体の障害に対する回復性など、Azure Managed Redis の信頼性について説明します。 この記事では、バックアップ戦略とサービス レベル アグリーメント (SLA) についても説明します。
運用環境のデプロイに関する推奨事項
運用環境の Azure Managed Redis インスタンスの高い信頼性を確保するには、次のことをお勧めします。
- 高可用性を有効にして、キャッシュに複数のノードをデプロイします。
- 可用性ゾーンがあるリージョンに高可用性キャッシュをデプロイすることで、ゾーンの冗長性を有効にします。
- リージョン間フェールオーバーを必要とするミッション クリティカルなワークロードに対してアクティブ geo レプリケーションを実装することを検討してください。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
Azure Managed Redis は Redis Enterprise 上に構築されており、高可用性の構成とレプリケーション機能を通じて信頼性を提供します。
Azure Managed Redis の インスタンス をデプロイします。これは キャッシュ インスタンス または キャッシュとも呼ばれます。 クライアント アプリケーションは、Redis API を使用してキャッシュ内のデータを格納および操作します。
物理アーキテクチャ
Azure Managed Redis の回復性を計画するときは、ノードとシャードという 2 つの重要な概念を理解する必要があります。
ノード： 各キャッシュ インスタンスは、仮想マシン (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 レプリケーションを使用する: 異なるリージョンに複数のインスタンスをデプロイし、それらの個別のインスタンスに負荷を分散するように アクティブ geo レプリケーション を構成できます。
すべてのゾーンが正常な場合の動作
このセクションでは、マネージド 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 Managed Redis のアクティブ geo レプリケーションは、サービスが利用可能な任意の Azure リージョン間で構成できます。
インスタンスの構成: アクティブ 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 アラートを構成して、インスタンスが同期されていない可能性があるタイミングを把握できます。アクティブな要求: 失敗したリージョンへの要求は終了され、アプリケーションのフェールオーバー ロジックによって処理される必要があります。 アプリケーションでは、トラフィックを正常なキャッシュにリダイレクトできる再試行ポリシーを実装する必要があります。
予想されるデータ損失: リージョン間の非同期レプリケーションにより、障害が発生したリージョンに対する最近の書き込みが、まだ他のリージョンにレプリケートされていない場合に失われる可能性があります。 潜在的なデータ損失の量は、障害発生時のレプリケーションのラグによって異なります。 詳細については、「Active-Active geo-distributed Redis (アクティブ/アクティブ geo 分散 Redis)」と、「Considerations about Consistency and Data Loss in a CRDB Regional Failure (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 冗長ストレージを構成することも、バックアップ BLOB をコピーまたは他の場所に移動してさらに保護することもできます。
エクスポートされたファイルは、同じキャッシュ インスタンスまたは別のキャッシュ インスタンスに復元できます。
組み込みのインポートまたはエクスポート スケジューラはありませんが、Azure CLI または Azure PowerShell を使用してエクスポート操作を開始する独自の自動化プロセスを開発できます。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。
Azure Managed Redis の SLA では、キャッシュ エンドポイントへの接続について説明します。 SLA は、データ損失からの保護には対応していません。
Azure Managed Redis の可用性 SLA の対象となるには、次の手順を実行します。
- 高可用性構成を有効にする必要があります。
- 一時的な使用不能を生み出すために文書化されている製品の機能や管理アクションを開始しないでください。
インスタンスがゾーン冗長である場合は、高可用性 SLA が適用されます。 一部のレベルでは、アクティブ geo レプリケーションを使用してゾーン冗長インスタンスを少なくとも 3 つのリージョンにデプロイした場合、より高い可用性 SLA を利用できます。