web-dev-qa-db-ja.com

AWSElasticacheのRedisクライアントLettuceマスター/スレーブ設定

私は、AWSElasticacheと通信するためのRedisクライアントとしてLettuceを使用しています。私が現在使用している特定の構成は 事前定義されたノードアドレスを持つ静的マスター/スレーブ です。最近、プライマリノードがフェイルオーバープロセスを開始し、最終的にすべてのアプリケーション書き込み要求が次のエラーで失敗する原因になりました。

redis.RedisCommandExecutionException: READONLY You can't write against a read only slave.

それ以来、私はいくつかの調査を行っており、 スタンドアロンマスター/スレーブ はおそらくAWSのドキュメントによると（非クラスターモードで）Elasticacheと通信する目的に適した構成であることに気付きました。クライアントは常にプライマリエンドポイントとのみ通信する必要があります。プライマリエンドポイントは、フェイルオーバーが発生した場合に新しいマスターを指すように更新されます。

これは私に疑問を残しました、なぜ著者はAWS Elasticacheを使用するときに 事前定義されたノードアドレスを持つ静的マスター/スレーブ メソッドを使用することを推奨するのですか？

何かご意見は？

構成：1つのマスターノードと2つのスレーブノード

javaredisamazon-elasticachelettuce
13
ideaz

AWS ElastiCacheはさまざまな方法で使用できるため、質問に対する2つの回答があります。

  1. マスターノードのみを使用する
  2. マスターとレプリカの使用

説明

AWS ElastiCache（非クラスター化）には、フェイルオーバーが発生したときにアプリケーションに通知しない独自のフェイルオーバーメカニズムが付属しています。これが良いか悪いかは、用途によって異なります。

マスターのみの使用

フェイルオーバーに依存したいが、レプリカを追加の読み取りに使用したくない場合は、マスターのみを使用するのが最善の方法です。マスターのみを使用する場合は、クライアントをプライマリエンドポイントにポイントします。 ElastiCacheがフェイルオーバーした場合、クライアント接続はリセットされます。 AWSは、プライマリエンドポイントの舞台裏で更新し、クライアントが正常に再接続すると、（新しい）マスターノードと再び通信します。

このシナリオでレプリカを使用できないのはなぜですか？

唯一のトポロジソースは、AWSElastiCacheノード自体です。レタスはAWSのAPIに接続しません（これは決して起こりません）。 Redisは接続されたレプリカをINFO REPLICATIONセクションで公開しますが、ElastiCache Redisノードは到達できないレプリカIPアドレスを報告するため、トポロジ検出を介してこれらのノードに接続することはできません。

マスターとレプリカの使用

ElastiCacheサーバーからレプリカエンドポイントを推測することはできませんが、静的エンドポイントを提供することは可能です。レタスはすべてのノードに接続し、startupでノードの役割を決定します。これにより、ノードの役割に応じて再度ルーティングできます。 （あなたの場合のように）フェイルオーバーが発生した場合、Lettuceはフェイルオーバーに関する通知を受け取らず、初期トポロジーに固執します。

フェイルオーバー通知

フェイルオーバー通知は欠落しているビットです。 Redis Sentinelは昇進/役割の変更を示す通知を提供しますが、「マスター/レプリカ」だけのメカニズムはありません。次のように言うことができます。トポロジの更新をトリガーするシグナルとして切断しましょう。これは場合によっては機能するかもしれませんが、はるかに多くの場合（アプリケーションとRedisノード間のネットワークパーティション、接続タイムアウト）、必要なしに更新をトリガーします。定期的なトポロジのアップグレードも、変更を発見するための試みにすぎません。

3番目の答え

AWSElastiCacheの実装に満足していません。マスターのみの使用では問題なく機能しますが、レプリカを使用するようになるとすぐに、フェイルオーバーの独自の実装に依存することになります。 AWSフェイルオーバーがない場合（つまり、独自のデータセンター/ Redisセットアップ内）、一部のOps担当者からRedisがダウンしていることが通知されます。 Redisノードを再起動するか、アプリケーションを再起動して操作を復元します。これらの信号が欠落しています。

それまでの間、AWSはRedisクラスターを提供します。これはHA /フェイルオーバーのセットアップとして優れている可能性がありますが、Redisクラスターにはアプリケーションに厳しい制限があります。 AWSのElastiCacheAPIをポーリングして、API側からトポロジを検出し、トポロジの更新（再接続）を開始することもできます。

静的トポロジで使用するためのレタスのマスター/レプリカAPIは、少なくともレプリカを操作する方法を提供することです。他のすべてはこの経験から派生しています。あらゆる形式（経験、提案、ドキュメント、コード）での投稿を歓迎します。

更新： antirez/redis＃5335に従ってレプリカの文言を調整しました

16
mp911de