Important
Azure Cache for Redis は、すべての SKU の提供終了タイムラインを発表しました。 できるだけ早く既存の Azure Cache for Redis インスタンスを Azure Managed Redis に移行することをお勧めします。
提供終了の詳細については、以下を参照してください。
回復性と成功を収めるクライアント アプリケーションを構築するには、Azure Cache for Redis サービスのフェールオーバーを理解することが重要です。 フェールオーバーは、計画された管理操作の一部である場合もあれば、計画外のハードウェアまたはネットワーク障害が原因である可能性があります。 キャッシュ フェールオーバーの一般的な用途は、管理サービスが Azure Cache for Redis バイナリにパッチを適用する場合です。
この記事では、次の情報を確認します。
- フェールオーバーとは
- 修正プログラムの適用中にフェールオーバーが発生する方法。
- 回復性のあるクライアント アプリケーションを構築する方法。
フェールオーバーとは
まず、Azure Cache for Redis のフェールオーバーの概要を見てみましょう。
キャッシュ アーキテクチャの概要
キャッシュは、個別の IP アドレスとプライベート IP アドレスを持つ複数の仮想マシンで構成されます。 各仮想マシン (ノードとも呼ばれます) は、1 つの仮想 IP アドレスを使用して共有ロード バランサーに接続されます。 各ノードは Redis サーバー プロセスを実行し、ホスト名と Redis ポートを使用してアクセスできます。 各ノードは、プライマリ ノードまたはレプリカ ノードと見なされます。 クライアント アプリケーションがキャッシュに接続すると、そのトラフィックはこのロード バランサーを通過し、プライマリ ノードに自動的にルーティングされます。
Basic キャッシュでは、単一ノードは常にプライマリです。 Standard キャッシュまたは Premium キャッシュには、2 つのノードがあります。1 つはプライマリとして選択され、もう 1 つはレプリカです。 Standard キャッシュと Premium キャッシュには複数のノードがあるため、1 つのノードが使用できない可能性があり、もう 1 つのノードは要求の処理を続行します。 クラスター化キャッシュは、それぞれが個別のプライマリ ノードとレプリカ ノードを持つ多数のシャードで構成されます。 他のシャードが使用可能な状態であるとき、1 つのシャードがダウンしている場合があります。
注
Basic キャッシュには複数のノードがないため、可用性に関するサービス レベル アグリーメント (SLA) は提供されません。 基本的なキャッシュは、開発とテストの目的でのみ推奨されます。 可用性を高めるために、マルチノードデプロイに Standard キャッシュまたは Premium キャッシュを使用します。
フェールオーバーの説明
フェールオーバーは、レプリカ ノードが自身をプライマリ ノードに昇格させ、古いプライマリ ノードが既存の接続を閉じるときに発生します。 プライマリ ノードがバックアップされると、ロールの変更に気付き、自身を降格してレプリカになります。 その後、新しいプライマリに接続し、データを同期します。 フェールオーバーが計画されているか、計画されていない可能性があります。
計画されたフェールオーバーは、次の 2 つの異なる時間に行われます。
- Redis の修正プログラムの適用や OS のアップグレードなどのシステム更新プログラム。
- スケーリングや再起動などの管理操作。
ノードは更新の事前通知を受け取るため、ロールを協調的にスワップし、変更のロード バランサーをすばやく更新できます。 通常、計画されたフェールオーバーは 1 秒未満で完了します。
計画 外のフェールオーバーは 、ハードウェア障害、ネットワーク障害、またはプライマリ ノードへのその他の予期しない障害が原因で発生する可能性があります。 レプリカ ノードはそれ自体をプライマリに昇格させますが、プロセスにかかる時間は長くなります。 レプリカ ノードは、フェールオーバー プロセスを開始する前に、プライマリ ノードが使用できないことを最初に検出する必要があります。 また、レプリカ ノードは、この計画外の障害が一時的またはローカルでないことを確認して、不要なフェールオーバーを回避する必要があります。 この検出の遅延は、通常、計画外のフェールオーバーが 10 ~ 15 秒以内に完了することを意味します。
修正プログラムの適用はどのように行われますか?
Azure Cache for Redis サービスは、最新のプラットフォーム機能と修正プログラムを使用してキャッシュを定期的に更新します。 キャッシュにパッチを適用するために、サービスは次の手順に従います。
- サービスは最初にレプリカ ノードにパッチを適用します。
- 修正プログラムが適用されたレプリカは、それ自体をプライマリに協調的に昇格させます。 この昇格は、計画されたフェールオーバーと見なされます。
- 前者のプライマリ ノードが再起動して新しい変更が行われ、レプリカ ノードとしてバックアップされます。
- レプリカ ノードはプライマリ ノードに接続し、データを同期します。
- データ同期が完了すると、残りのノードに対して修正プログラムの適用プロセスが繰り返されます。
修正プログラムの適用は計画されたフェールオーバーであるため、レプリカ ノードはすぐにプライマリになるように昇格します。 その後、ノードは要求と新しい接続のサービスを開始します。 基本キャッシュにはレプリカ ノードがなく、更新が完了するまで使用できません。 クラスター化されたキャッシュの各シャードには個別にパッチが適用され、別のシャードへの接続は閉じられません。
Important
ノードには、データ損失を防ぐために一度に 1 つずつパッチが適用されます。 基本的なキャッシュでは、データが失われます。 クラスター化されたキャッシュには、一度に 1 つのシャードにパッチが適用されます。
同じリソース グループとリージョン内の複数のキャッシュにも、一度に 1 つずつパッチが適用されます。 異なるリソース グループまたは異なるリージョンにあるキャッシュには、同時にパッチが適用される場合があります。
プロセスが繰り返される前に完全なデータ同期が行われるため、Standard または Premium キャッシュを使用する場合、データ損失が発生する可能性はほとんどありません。 データを エクスポート し 、永続化を有効にすることで、データ損失をさらに防ぐことができます。
追加のキャッシュ読み込み
フェールオーバーが発生するたびに、Standard キャッシュと Premium キャッシュは、1 つのノードから他方のノードにデータをレプリケートする必要があります。 このレプリケーションにより、サーバー メモリと CPU の両方で負荷が増加します。 キャッシュ インスタンスが既に大量に読み込まれている場合、クライアント アプリケーションの待機時間が長くなる可能性があります。 極端な場合、クライアント アプリケーションはタイムアウト例外を受け取る可能性があります。 負荷の影響を軽減するには、キャッシュの設定をmaxmemory-reservedします。
フェールオーバーはクライアント アプリケーションにどのように影響しますか?
クライアント アプリケーションは、Azure Cache For Redis からいくつかのエラーを受け取る可能性があります。 クライアント アプリケーションによって表示されるエラーの数は、フェールオーバー時にその接続で保留されていた操作の数によって異なります。 接続を閉じたノードを介してルーティングされた接続には、エラーが表示されます。
接続が中断されると、多くのクライアント ライブラリでは、次のようなさまざまな種類のエラーがスローされます。
- タイムアウト例外
- 接続の例外
- ソケットの例外
例外の数と種類は、キャッシュが接続を閉じるときに、要求がコード パス内のどこにあるかによって異なります。 たとえば、要求を送信するが、フェールオーバーが発生したときに応答を受け取っていない操作では、タイムアウト例外が発生する可能性があります。 閉じた接続オブジェクトに対する新しい要求は、再接続が正常に行われるまで接続例外を受け取ります。
ほとんどのクライアント ライブラリは、そのように構成されている場合、キャッシュへの再接続を試みます。 ただし、予期しないバグにより、ライブラリ オブジェクトが回復不能な状態になる場合があります。 構成済みの時間よりも長くエラーが続く場合は、接続オブジェクトを再作成する必要があります。 Microsoft.NET やその他のオブジェクト指向言語では、アプリケーションを再起動せずに接続を再作成するには、 ForceReconnect パターンを使用します。
メンテナンスの前に通知を受け取ることができますか?
Azure Cache for Redis は、 AzureRedisEventsと呼ばれる発行/サブスクライブ (pub/sub) チャネルでランタイム メンテナンス通知を発行します。 多くの一般的な Redis クライアント ライブラリでは、pub/sub チャネルのサブスクライブがサポートされています。 通常、 AzureRedisEvents チャネルからの通知の受信は、クライアント アプリケーションに簡単に追加できます。 メンテナンス イベントの詳細については、「 AzureRedisEvents」を参照してください。
注
AzureRedisEvents チャネルは、数日または数時間前に通知できるメカニズムではありません。 チャネルは、サーバーの可用性に影響を与える可能性がある今後のサーバー メンテナンス イベントをクライアントに通知できます。
AzureRedisEvents は、Basic レベル、Standard レベル、Premium レベルでのみ使用できます。
メンテナンスに含まれる更新プログラムは何ですか?
メンテナンスには、次の更新プログラムが含まれます。
- Redis Server の更新プログラム: Redis サーバー バイナリの更新プログラムまたはパッチ。
- 仮想マシン (VM) の更新: Redis サービスをホストしている仮想マシンのすべての更新。 VM の更新プログラムには、ホスト環境のソフトウェア コンポーネントにパッチを適用して、ネットワーク コンポーネントのアップグレードや使用停止が含まれます。
メンテナンスは、パッチの前に Azure portal のサービス正常性に表示されますか?
いいえ。メンテナンスは、ポータルやその他の場所の サービス正常性 の下には表示されません。
計画メンテナンスの前に通知を受け取るにはどのくらいの時間がかかりますか?
AzureRedisEvents チャネルを使用すると、メンテナンスの 15 分前に通知されます。
クライアント ネットワーク構成の変更
クライアント側のネットワーク構成の変更によっては、 接続が使用できない エラーがトリガーされる場合があります。 このような変更には、次のようなものがあります。
- ステージング スロットと運用スロットの間でクライアント アプリケーションの仮想 IP アドレスをスワップする。
- アプリケーションのインスタンスのサイズまたは数をスケーリングします。
このような変更により、通常は 1 分未満の接続の問題が発生する可能性があります。 クライアント アプリケーションは、他の外部ネットワーク リソースだけでなく、Azure Cache for Redis サービスへの接続を失う可能性があります。
耐障害性の構築
フェールオーバーを完全に回避することはできません。 代わりに、接続の中断と失敗した要求に対する回復性を備えたクライアント アプリケーションを作成します。 ほとんどのクライアント ライブラリはキャッシュ エンドポイントに自動的に再接続しますが、失敗した要求の再試行を試みるクライアント ライブラリはほとんどありません。 アプリケーションのシナリオによっては、バックオフで再試行ロジックを使用することが理にかなっている場合があります。
アプリケーションに回復性を持たせるにはどうすればよいですか?
耐障害性の高いシステムを構築する際には、特にサーキットブレーカーとリトライパターンを含む次の設計パターンを参照してください。
クライアント アプリケーションの回復性をテストするには、接続切断の手動トリガーとして 再起動 を使用します。
さらに、スケジュールされた更新プログラムを使用して、更新チャネルと、キャッシュのメンテナンス期間を選択して、特定の週単位の期間に Redis ランタイムパッチを適用することをお勧めします。 これらのウィンドウは、通常、潜在的なインシデントを回避するために、クライアント アプリケーションのトラフィックが少ない期間です。 詳細については、「 更新チャネル」および「更新プログラムのスケジュール」を参照してください。
詳細については、「 接続の回復性」を参照してください。
関連コンテンツ
- チャネルの更新と更新のスケジュール
- 再起動を使用してアプリケーションの回復性をテスト する
- メモリ予約とポリシーを構成する