データベース サービスに Amazon RDS を使用しており、リード レプリカ機能を使用して、リード レプリカ ボリューム間でトラフィックを分散させたいと考えています。現在、データベースの接続情報を単一の構成ファイルに保存しています。したがって、私の考えは、アプリケーションが読み取りを実行するたびに、構成ファイル内のリードレプリカ エンドポイント/アドレスのリストからランダムに選択する関数を作成できるということです。
書き込みで実行しない限り、このアイデアに問題はありますか?
データベース サービスに Amazon RDS を使用しており、リード レプリカ機能を使用して、リード レプリカ ボリューム間でトラフィックを分散させたいと考えています。現在、データベースの接続情報を単一の構成ファイルに保存しています。したがって、私の考えは、アプリケーションが読み取りを実行するたびに、構成ファイル内のリードレプリカ エンドポイント/アドレスのリストからランダムに選択する関数を作成できるということです。
書き込みで実行しない限り、このアイデアに問題はありますか?
私の推測では、負荷を分散したい複数の rds リードレプリカがある場所に十分なトラフィックがあるサービスがある場合、その前に複数のアプリケーションサーバーがロードバランサーの背後で動作していると思います。
そのため、アプリ サーバー インスタンスの特定のクラスターがそれぞれ特定の読み取りレプリカを指すようにした方がよいでしょう。おそらく、アベイラビリティーゾーンごとにこれを行います。
ここで考えられるのは、ロード バランサーは、最終的にデータベースの読み取りにつながる着信要求を適切に分散するためのメカニズムとして機能するということです。異なるレプリカ間で DB 読み取りをランダム化した場合、予期しないスパイクが発生する可能性があります。1 つの DB レプリカに大量のトラフィックが送信され、結果としてサービスのレイテンシ スパイクが発生する可能性があります。
最大の課題は、更新が行われたときにリードレプリカがマスターまたは相互に最新であるという保証がないことです。読み取りを行うたびに異なるリード レプリカを選択すると、リード レプリカの 1 つが遅れていると、奇妙なことがわかります。
トランザクションまたはセッションごとにランダムな読み取りレプリカを選択すると、一貫性の観点から扱いやすくなる場合があります。