Amazon RDS Proxy を使用したアプリケーションの可用性の向上

Amazon RDS Proxy の利点の 1 つは、データベースのフェイルオーバー後のアプリケーションにかかる復旧時間を改善できることです。RDS Proxy は MySQL と PostgreSQL エンジンの両方をサポートしていますが、この記事では、MySQL テストワークロードを使用して、RDS Proxy がフェイルオーバー後のクライアントリカバリ時間を Amazon Aurora MySQL で最大 79%、Amazon RDS for MySQL で最大 32% 削減する方法を示します。この記事では、RDS Proxy がクライアントをリーダー/ライターの移行問題から隔離し、次善のクライアント設定を克服する方法についても説明しています。アクティブ接続監視による計画的フェイルオーバーと計画外フェイルオーバー、およびフェイルオーバーを通じてアイドル接続を維持することによるクライアント接続プールの RDS Proxy の利点について説明します。最後に、この記事では、おすすめのクライアント構成をいくつか紹介します。

背景

RDS Proxy は、Amazon RDS for MySQL/PostgreSQL および Aurora MySQL/PostgreSQL データベースに向かって進むことができます。これにより、データベースへのアプリケーションへのアクセスを管理でき、接続プーリング、多重化、適切なフェイルオーバーを提供します。データベース接続の制限を超えてスケーリングし、接続のバーストとアプリケーションからのリクエストを管理できます。この記事では、RDS Proxy フェイルオーバーのメリットに焦点を当てています。

フェイルオーバーは、プライマリデータベースインスタンスにアクセスできなくなり、別のインスタンスが新しいプライマリとして引き継がれるときに発生します。これにより、クライアント接続が中断されます。ローリングアップグレードなどの管理アクションによって引き起こされた場合は計画的フェイルオーバー、障害が原因で発生した場合は計画外フェイルオーバーになります。どちらの場合も、クライアントの中断を最小限に抑えるためにダウンタイムを取り除くする必要があります。

Amazon RDS には複数の高可用性オプションがあり、RDS Proxy は各オプションにフェイルオーバー復旧の利点を提供します。Amazon RDS マルチ AZ オプションは、同期レプリケーションを備えたプライマリ構成およびスタンバイ構成です。Aurora は、最大 15 の非同期レプリカとマルチマスターの 2 つの高可用性オプションを提供します。すべての Aurora レプリカは読み取り専用アクセスで使用できます。データを失うことなくフェイルオーバーが発生した場合は、レプリカをクラスターの新しいプライマリに選択して昇格することができます。Aurora マルチマスターは、複数のアクティブなライターを提供します。

これらすべてのオプションを使用すると、フェイルオーバーが発生した場合、クライアントは接続障害を検出し、新しいプライマリを検出して、可能な限り迅速にプライマリに再接続する必要があります。RDS Proxy を使用すれば、アプリケーションはフェイルオーバーに関連する複雑さを回避し、より高速な復旧 (わずか 3 秒) を体験できます。フェイルオーバーが高速な Aurora では、DNS 伝播遅延がフェイルオーバー時間全体に最も大きい影響を与えます。RDS Proxy はデータベースインスタンスをアクティブに監視し、クライアントを適切なターゲットに自動的に接続します。また、アイドル状態のクライアント接続をドロップせずにデータベースフェイルオーバーによって維持します。このコンテキストでのアイドル接続は、未処理のリクエストがない接続です。

Aurora フェイルオーバー

Aurora クラスターへの直接接続と RDS Proxy 経由の Aurora クラスターへの接続の間のフェイルオーバー時間を比較して 100 回実行された内部テストの結果は、大幅な改善を示しています。

次のテーブルに 1 秒未満で結果をまとめます。

MariaDB ドライバーを使用してデータベースに直接接続する場合は 24 秒がかかりますが、RDS Proxy での平均フェイルオーバー時間は 3.1 秒でした。87% 改善された結果です。

リレーショナルデータベースでは、基本的なベンチマークであっても、フェイルオーバーが 3 秒中断されます。これは、いくつかの Aurora 革新による結果です。ただし、フェイルオーバー時間を短縮するための最適化を含め、推奨される MariaDB Aurora ドライバーでさえ、Aurora の利点をすべて体験するには明らかに不十分です。現在のボトルネックは、クライアントドライバーがデータベースと同じ速さで回復する能力を持っている可能性があるため、高速の Aurora MySQL フェイルオーバーを最大限に活用するには、RDS Proxy が必要です。

DNS の有効期限

クライアントドライバーはさまざまな方法で調整できます。たとえば、MariaDB ConnectorJ ドライバーには、100 近くの構成設定があります。OS、JVM、および接続プールフレームワークには、さらに多くの構成オプションがあります。この記事では、DNS クライアントのキャッシュ構成から始め、最も重要なものについて説明します。

クライアントが DNS 名を使用してデータベースに接続する場合、クライアントは最初に DNS サーバーにクエリを実行して IP アドレスを解決する必要があります。次に、クライアントは応答をキャッシュします。プロトコルごとに、DNS 応答は、クライアントがレコードをキャッシュする必要がある期間を管理する有効期限 (TTL) を指定します。RDS はデフォルトの TTL を 4 秒に設定します。ただし、多くのシステムは異なる設定でクライアントキャッシュを実装し、TTL が長くなるよう指定します。OS と JVM ランタイム環境の両方にこのようなキャッシュがあります。JVM のキャッシュ設定はバージョンと OS によって異なるため、明示的に設定することが重要です。次のコードは、推奨設定を示しています。

java.security.Security.setProperty("networkaddress.cache.ttl" , "1");
java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "1");

これにより、JVM のデフォルト DNS キャッシングが減少し、ドライバーはフェイルオーバー中に DNS 名の IP アドレスの変更をより速く検出できるようになります。

最適化されたクライアントでのフェイルオーバーベンチマーク

次のベンチマークでは、前述のように DNS TTL 設定で最適化されたクライアントと、この記事で後述する他の推奨クライアント設定を使用します。次のグラフは、MariaDB ドライバーを最適な設定で使用し、Aurora MySQL に直接接続する場合と RDS Proxy 経由で接続する場合のフェイルオーバー時間を比較しています。

次のテーブルに 1 秒未満で結果をまとめます。

十分に調整された MariaDB クライアントを使用すると、RDS Proxy を使用した場合の平均フェイルオーバー時間は 2.9 秒、直接接続する場合は 13.8 秒となり、RDS Proxy で 79% 改善されます。復旧時間を改善する場合は特定のワークロードに依存することになるので、ご注意ください。

Aurora クライアントの構成

上記のテストでは、Aurora 固有の拡張機能を備えた推奨 MariaDB ConnectorJ を使用しました。具体的には、データベースへの直接接続では、jdbc:mariadb:aurora://<cluster-endpoint> で始まる接続 URL を使用しました。これにより、MariaDB ConnectorJ ドライバーは Aurora 固有のシステムテーブルを使用して、プライマリデータベースインスタンスをすばやく検出できます。詳細については、MySQL と互換性がある Amazon Aurora での Maria JDBC ドライバーの使用を参照してください。

RDS Proxy 経由の接続では、jdbc:mariadb://<proxy-endpoint> などの URL を使用した通常のドライバー機能を使用していました。特別なクライアント構成を使用していないにもかかわらず、RDS Proxy はフェイルオーバー時間を最小限に抑えるのにより効果的でした。単純なクライアントロジックを使用すると、必要な任意のクライアントを使用できるというメリットもあります。

リーダーとライターのロール移行

なんらかの理由でプライマリインスタンスが使用できなくなった場合、Aurora は自動的にフェイルオーバーを実行します。このフェイルオーバー中に、プライマリインスタンスはロールを変更してリーダーになり、Aurora クラスター内のリーダーの 1 つがプライマリに昇格されます。クラスターエンドポイントに直接接続している場合、DNS レコードがキャッシュされている可能性があるため、クライアントは古いプライマリインスタンスに再接続する可能性があります。接続が確立されても、クライアントはインスタンスではなく、読み取り専用インスタンスとして指定されているため、インスタンスへの書き込みを実行できません。RDS Proxy は常にクライアントを現在のプライマリに接続するため、このようなエラーを取り除きます。

アクティブな監視と計画外のフェイルオーバー

RDS Proxy はフェイルオーバーを実行するために DNS 伝播に依存しないため、フェイルオーバーを改善します。RDS Proxy は、Aurora クラスタークライアントのリーダーとライターの移行問題を解消します。Aurora データベースクラスター内の各データベースインスタンスをアクティブに監視して、フェイルオーバー中に迅速にクライアントに代わって動作します。

これまでのところ、この記事では、計画的フェイルオーバーシナリオや管理的フェイルオーバーシナリオにおける最も基本的なシナリオについて説明しました。Aurora の場合、このようなフェイルオーバーは、AWS マネジメントコンソール、API、または AWS コマンドラインインターフェイス (AWS CLI) を介してオンデマンドで開始し、インスタンスサイズを変更したとき、または Amazon がオプトインする定期メンテナンスオペレーションのフェイルオーバーを実行したときに発生します。このようにデータベースホストでデータベースプロセスの準備ができていないすべての場合、接続を適切に閉じ、新しい接続を拒否できます。つまり、クライアントまたは RDS Proxy は問題を簡単に検出して再試行できます。

ただし、ホストが突然到達不能になる計画外フェイルオーバーのシナリオを検討してください。既存のクライアント TCP 接続は開いたままであり、クライアントは応答がないため、接続が停止していることを検出する必要があります。このようなシナリオを処理するには、ソケットタイムアウト、接続タイムアウト、TCP キープアライブを構成するための次のベストプラクティスが必要です。RDS Proxy は、計画外のフェイルオーバーでクライアントを支援できます。

RDS Proxy はすべてのデータベースインスタンスを監視し、数秒以内に障害を検出できます。RDS Proxy は、障害を検出すると、障害が発生したデータベースインスタンスへの新しいクエリの送信を停止します。RDS Proxy は、トランザクションの途中ではなかったアイドル状態のクライアント接続をフェイルオーバー中に維持します。つまり、プール内に非アクティブな接続があったクライアント接続プールは、すべての接続を再作成しなくても、フェイルオーバーをより適切に処理できます。これにより、多くのアイドル状態の TLS 接続を再作成するオーバーヘッドからクライアントを解放します。RDS Proxy は、障害が発生したデータベースインスタンスでトランザクションを実行している間のクライアント接続も積極的に終了します。これにより、クライアントはタイムアウトを待たずにすばやく再試行できます。

RDS Proxy は常に新しい接続を受け入れ、新しいプライマリが使用可能になるまでクエリの転送を遅らせます。RDS Proxy がない場合にフェイルオーバーが発生すると、クライアントはプライマリデータベースインスタンスが利用できないことを検出し、すぐに再接続を試みる可能性があります。プライマリが復旧中である可能性があるため、これらの再接続試行が失敗する場合があります。プライマリが復旧するときに再接続を試行しすぎると、再び失敗する可能性があります。その結果、クライアントは適切な待機時間を伴う再試行ロジックを構築する必要があります。RDS Proxy を使用すれば、複雑な再試行ロジックを構築する必要がなくなります。

Amazon RDS マルチ AZ

計画外のフェイルオーバーの影響を軽減するのに役立つ RDS 機能の 1 つは、Amazon RDS のマルチ AZ です。RDS MySQL のマルチ AZ 構成では、プライマリデータベースインスタンスが 1 つのアベイラビリティーゾーンに存在し、同期スタンバイインスタンスが 2 番目のアベイラビリティーゾーンに存在します。クライアントアプリケーションがデータベースへの接続に使用するプライマリインスタンスを指すホスト名が 1 つあります。障害が発生した場合、RDS サービスはプライマリインスタンスとセカンダリインスタンスのロールを切り替えます。RDS サービスは、データベースホスト名の基になる IP アドレスも変更するため、フェイルオーバー中にクライアントアプリケーションが接続設定を変更する必要はありません。

Amazon RDS マルチ AZ では、フェイルオーバー時に、元のプライマリが TCP 接続を閉じることはありません。フェイルオーバーの開始後、クライアントはデータベースからこれ以上 TCP トラフィックを取得しません。代わりに、タイムアウトするかどうかはクライアント次第です。フェイルオーバー時に元のプライマリデータベースのハードフェンシングを慎重に設計することを選択すると、クライアントが計画的フェイルオーバーと計画外のフェイルオーバー中に同様の動作を期待できるということを意味します。これには、Amazon RDS API または CLI を介して管理フェイルオーバーを実行するだけで、計画的フェイルオーバーと計画外のフェイルオーバー両方のシナリオを簡単にテストできるという実用的な利点があります。ただし、MariaDB ドライバーおよび多くのオペレーティングシステムのデフォルト設定は、このシナリオを処理するには不十分です。デフォルトでは、MariaDB ドライバーは応答の待機中にタイムアウトすることがなく、特定のオペレーティングシステムの TCP キープアライブ設定は 2 時間を超える場合があります。ただし、RDS Proxy では、ホスト名 (この場合は RDS Proxy) の基礎となる DNS 構成が変更されないため、これらの設定はもう重要ではありません。

RDS マルチ AZ フェイルオーバー復旧ベンチマーク

以下の結果は、MariaDB ドライバーを使用してデータベースに直接、および RDS Proxy 経由で挿入クエリを実行しているときの 50 個のフェイルオーバーの結果を示しています。次のテーブルに 1 秒未満で結果をまとめます。

まとめると、Amazon RDS マルチ AZ データベースで RDS Proxy を使用する場合は平均 25 秒以内に回復が見られましたが、データベースへの直接接続では 37〜40 秒のダウンタイムが発生しました。

Amazon RDS マルチ AZ 復旧は 25 秒でしたが、Aurora は db.r5.large インスタンスで 3 秒未満で復旧しました。Aurora には、フェイルオーバー後のデータベースの復旧時間を短縮するための革新方法が既にあるため、これは驚くべきことではありません。

まとめ

この記事では、RDS Proxy の次の利点を示しました。

• テストワークロードの Aurora MySQL フェイルオーバー時間を最大 79% 短縮
• テストワークロードの RDS MySQL マルチ AZ フェイルオーバー時間を最大 32% 短縮
• 特別なクライアントロジックを必要とせずに、さまざまなクライアントドライバーと同等に機能します。
• Aurora リーダーおよびライターの移行からクライアントを隔離する
• 計画外のフェイルオーバーを含め、各データベースをアクティブに監視する
• フェイルオーバー時にアイドル接続をドロップしないため、クライアント接続プールへの影響が軽減される
• 常に接続を受け入れ、クライアントを接続タイムアウトから隔離します。

RDS Proxy は使いやすいです。MySQL または PostgreSQL のクライアントドライバーを RDS Proxy エンドポイントに向けると、そのメリットを享受できます。ご使用のアプリケーションで今すぐ RDS Proxy をお試しください。

著者について

Anton Okmyanskiy はアマゾン ウェブ サービスのプリンシパルエンジニアです。

Steve Abraham はアマゾン ウェブ サービスのプリンシパルデータアーキテクトです。お客様と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。