AmazonAuroraエンドポイントを理解する

インスタンスエンドポイントを使用することが理にかなっている状況があります 。 ElasticLoadBalancerの背後にステートレスマイクロサービスが多数あるアプリケーションがあるとします。この状況では、クエリがクライアント全体に均等に分散されていると想定するのが妥当です。したがって、リーダーエンドポイントを使用する場合は、読み取りレプリカ全体に分散されます。 。

しかし、各クライアントのワークロードが均一に分散されていない状況についてはどうでしょうか。レポートサービスがミックスに追加された場合、1つのリードレプリカは他のレプリカと比較して不釣り合いに高い負荷がかかります。前述のマイクロサービスもこのリードレプリカを使用している場合、レポートサービスで使用されているインスタンスをクエリするときに、クエリのパフォーマンスが低下する可能性が高くなります。これを回避するための1つのアプローチは、Amazon Auroraにこれを行わせるのではなく、クライアント側で接続の分散を管理することです。幸い、これはインスタンスエンドポイントを使用して簡単に実行できます。 リーダーエンドポイントの代わりに .MariaDB Connector / J for Aurora forMySQLまたはAmazonAuroraPostgreSQLを使用した高速フェイルオーバーを使用すると、ドライバーは、リードレプリカとして使用する個々のインスタンスを認識できるため、クエリが個々のインスタンスにどのように分散されるかをドライバーが直接管理できます。

DNSキャッシングを管理する

ワークロードの性質を理解することに加えて、Auroraの高可用性とリーダーエンドポイントを提供するために接続がどのように割り当てられるかを理解することが重要です。 負荷分散。

自動クラスタエンドポイントの管理 フェイルオーバーとリーダーエンドポイント ロードバランシングは、IP、TCP、またはデータベースクライアントプロトコルレイヤーではなく、DNS（Amazon Route 53）を介して処理されます。 DNSを介した接続の分散を処理するということは、そのアプリケーションが新しい接続要求ごとにDNSクエリを作成する必要があることを意味します。 DNSキャッシングを使用するアプリケーションは、AmazonAuroraのDNSレコードTTLと一致するようにキャッシュタイムアウトを調整する必要があります。 Aurora DNSレコードTTLよりも長いDNS応答をキャッシュすると、いくつかのエラー状態が発生します。高可用性（HA）フェイルオーバーイベントが発生した場合、つまり、リードレプリカがプライマリにプロモートされた場合、キャッシュされたDNS応答は、アプリケーションが古い障害のあるインスタンスへの再接続を試みることを意味します。 リーダーエンドポイントの場合 、DNS応答をキャッシュすると、複数の接続が使用可能なリードレプリカに分散されるのではなく、特定のリードレプリカに送られます。