Azure Cache for Redis のフェールオーバーと修正プログラムの適用

  • [アーティクル]

回復性の高い優れたクライアント アプリケーションを構築するには、Azure Cache for Redis サービスでのフェールオーバーを理解することが重要です。 フェールオーバーは、計画された管理操作の一環であることも、計画外のハードウェアやネットワーク障害で発生することもあります。 一般的にキャッシュ フェールオーバーは、管理サービスが Azure Cache for Redis バイナリに修正プログラムを適用するときに使用します。

この記事では、次の情報を確認します。

  • フェールオーバーとは
  • 修正プログラムの適用中にフェールオーバーがどのように発生するか。
  • 回復性があるクライアント アプリケーションを構築する方法。

フェールオーバーとは

まず、Azure Cache for Redis のフェールオーバーの概要について説明します。

キャッシュ アーキテクチャの簡単な概要

キャッシュは、個別のプライベート IP アドレスを持つ複数の仮想マシンで構成されます。 ノードとも呼ばれる各仮想マシンは、1 つの仮想 IP で共有のロード バランサーに接続されています。 各ノードでは Redis サーバー プロセスを実行し、ホスト名と Redis ポートを使用してアクセスできます。 各ノードは、プライマリまたはレプリカ ノードのいずれかと見なされています。 クライアント アプリケーションがキャッシュに接続されると、そのトラフィックはこのロード バランサーを通過し、自動的にプライマリ ノードにルーティングされます。

Basic キャッシュでは、1 つのノードが常にプライマリとなります。 Standard または Premium キャッシュには、プライマリとして選択されているノードと、レプリカとして選択されているノードの 2 つのノードがあります。 ノードが複数ある Standard および Premium キャッシュでは、1 つのノードが要求の処理を続けているとき、1 つのノードは利用できない場合があります。 クラスター化されたキャッシュは多くのシャードで構成され、それぞれに個別のプライマリ ノードとレプリカ ノードがあります。 他のシャードが使用可能な状態であるとき、1 つのシャードがダウンしている場合があります。

Note

Basic のキャッシュにはノードは複数はなく、可用性に関する SLA は提供されていません。 Basic のキャッシュは、開発およびテストの目的でのみに推奨されます。 マルチノード デプロイには、可用性を高めるために Standard または Premium キャッシュを使用してください。

フェールオーバーの説明

フェールオーバーは、1 つのレプリカ ノードが自身をプライマリ ノードに昇格し、古いプライマリ ノードが既存の接続を切断したときに発生します。 復帰後、そのプライマリ ノードによってロールの変更が認識されると、自身をレプリカに降格させます。 その後、新しいプライマリに接続し、データを同期します。 フェールオーバーは、計画されている場合とされなていない場合があります。

"計画されたフェールオーバー" は、次の 2 つの異なるときに実行されます。

  • Redis の修正プログラムの適用や OS のアップグレードなどのシステムの更新時。
  • スケーリングや再起動などの管理操作時。

ノードには更新が事前通知されているため、ロールを協調的に交換し、ロード バランサーをすばやく変更で更新できます。 計画フェールオーバーは通常 1 秒未満で終了します。

計画外のフェールオーバーは、ハードウェア障害、ネットワーク障害、またはその他のプライマリ ノードに対する予期しない停止が原因で発生します。 レプリカ ノードによってそれ自体がプライマリに昇格されますが、そのプロセスには時間がかかります。 レプリカ ノードでは、フェールオーバー プロセスを開始する前に、そのプライマリ ノードが使用できないことを最初に検出する必要があります。 また、不要なフェールオーバーがなされないよう、この計画外の障害が一時的なものでもローカルのものでもないことをレプリカ ノードによって確認される必要もあります。 検出が遅れるということは、計画外のフェールオーバーは通常 10 秒から 15 秒以内に完了することを意味します。

修正プログラムの適用はどのように行われますか?

Azure Cache for Redis サービスでは、お使いのキャッシュを最新のプラットフォーム機能と修正プログラムで定期的に更新します。 このサービスは、キャッシュへの修正プログラムの適用を次の手順で実行します。

  1. サービスは、まずレプリカ ノードにパッチを適用します。
  2. パッチが適用されたレプリカは、自身を協調的にプライマリに昇格させます。 この昇格は、計画されたフェールオーバーと見なされます。
  3. 以前のプライマリ ノードは再起動されて新しい変更が取得され、レプリカ ノードとして復帰します。
  4. レプリカ ノードがプライマリ ノードに接続し、データを同期します。
  5. データの同期が完了すると、残りのノードに対する修正プログラムの適用プロセスが繰り返されます。

修正プログラムの適用は計画されたフェールオーバーであるため、レプリカ ノードではプライマリになるために迅速に自身を昇格させ、 次に、ノードは要求の処理と新しい接続を開始します。 Basic のキャッシュにはレプリカ ノードはなく、更新が完了するまで使用することはできません。 クラスター化されたキャッシュの各シャードには個別にパッチが適用され、別のシャードへの接続は閉じられません。

重要

データの損失を防ぐために、ノードには一度に 1 つずつ修正プログラムが適用されます。 Basic キャッシュではデータが失われます。 クラスター化されたキャッシュでは、一度に 1 つのシャードに修正プログラムが適用されます。

同じリソー スグループとリージョン内の複数のキャッシュにも、一度に 1 つずつ修正プログラムが適用されます。 異なるリソース グループまたは異なるリージョンにあるキャッシュには、同時に修正プログラムが適用できる場合があります。

データの完全な同期はプロセスが繰り返される前に行われるため、Standard または Premium キャッシュを使用している場合にデータが失われる可能性は低いです。 データをエクスポートして、永続化を有効にすると、データの損失をさらに防御できます。

追加のキャッシュの負荷

フェールオーバーが発生するたびに、Standard および Premium キャッシュでは、ノード間でデータをレプリケートする必要があります。 このレプリケーションによって、サーバーのメモリと CPU の両方で負荷が増加します。 キャッシュ インスタンスに既に大きな負荷がかかっている場合は、クライアント アプリケーションの待機時間が長くなることがあります。 極端な場合、クライアント アプリケーションがタイムアウト例外を受け取ることがあります。 このさらなる負荷の影響を軽減するには、キャッシュの maxmemory-reserved 設定を構成します。

フェールオーバーはクライアント アプリケーションにどのような影響を与えますか?

クライアント アプリケーションは、Azure Cache for Redis からいくつかのエラーを受信することがあります。 クライアント アプリケーションで確認されるエラーの数は、フェールオーバー時にその接続で保留になっている操作の数によって異なります。 接続が閉じられているノード経由でルーティングされている接続では、エラーが発生します。

接続が中断されると、多くのクライアント ライブラリでは、次のようなさまざまな種類のエラーがスローされます。

  • タイムアウト例外
  • 接続例外
  • ソケット例外

例外の数と種類は、キャッシュで接続が閉じられたときに、その要求がコード パス内のどこにあるかによって異なります。 たとえば、要求を送信した操作が、フェールオーバーの発生で応答を受信しない場合、タイムアウト例外を取得する可能性があります。 接続が閉じられたオブジェクトは、再接続が正常に行われるまで、新しい要求で接続例外を受け取ります。

ほとんどのクライアント ライブラリは、構成されている場合、キャッシュへの再接続を試みます。 ただし、予期しないバグによってライブラリ オブジェクトが回復不能な状態になることがあります。 エラーが事前構成された時間を超えて続く場合は、接続オブジェクトを再作成する必要があります。 Microsoft .NET およびその他のオブジェクト指向言語では、ForceReconnect パターンを使用することで、アプリケーションを再起動せずに接続を再作成できます。

計画メンテナンスの通知を前もって受け取ることはできますか?

Azure Cache for Redis では、AzureRedisEvents という名前の発行とサブスクライブ (pub/sub) チャネルで、ランタイム メンテナンスの通知を発行します。 一般的な Redis クライアント ライブラリの多くで、pub/sub チャネルのサブスクライブがサポートされています。 通常、クライアント アプリケーションに AzureRedisEvents チャネルからの通知の受信を追加することは簡単です。 メンテナンス イベントの詳細については、「AzureRedisEvents」を参照してください。

Note

AzureRedisEvents チャネルは、数日や数時間も前にユーザーに通知できるメカニズムではありません。 このチャネルは、サーバーの使用可能性に影響するおそれがある、計画されたサーバー メンテナンス イベントの予定をクライアントに通知することができます。 AzureRedisEvents は、Basic、Standard、Premium レベルでのみ使用できます。

クライアントのネットワーク構成の変更

クライアント側の特定のネットワーク構成の変更によって、"接続が使用できません" というエラーが発生することがあります。 このような変更には、次のものが含まれます。

  • クライアント アプリケーションの仮想 IP アドレスをステージング スロットと運用スロット間で交換しました。
  • お使いのアプリケーションのインスタンスのサイズまたは数をスケーリングしました。

このような変更では、1 分未満の接続の問題が発生する可能性があります。 お使いのクライアント アプリケーションからは、Azure Cache for Redis サービスに加え、他の外部のネットワークのリソースにも接続できなくなる場合があります。

回復性を組み込む

フェールオーバーを完全に回避することはできません。 接続の中断や要求の失敗への回復性を備えるようにクライアント アプリケーションを作成してください。 ほとんどのクライアント ライブラリは自動的にキャッシュ エンドポイントに再接続できますが、少数は失敗した要求を再試行します。 アプリケーションのシナリオによっては、バックオフによる再試行ロジックが理にかなっている場合があります。

アプリケーションの回復性を高める方法

回復性があるクライアントを作成するには、これらの設計パターン、特にサーキット ブレーカー パターンや再試行パターンを参照してください。

クライアント アプリケーションの回復性をテストするには、接続が切断された場合の手動トリガーとして、再起動を使用します。

さらに、スケジュールされた更新を使用して、更新プログラム チャネルとキャッシュのメンテナンス期間を選択し、毎週の特定の期間に Redis ランタイム パッチを適用することをお勧めします。 通常これらの時間枠は、発生の可能性のある事柄を回避する、クライアント アプリケーションのトラフィックが少ない時間です。 詳細と手順については、「更新プログラム チャネルと更新プログラムのスケジュール」を参照してください。

詳細については、「接続の回復力」を参照してください。

関連するコンテンツ