こんにちは。テクニカルサポート課の森本です。
最近、ちょくちょく Aurora のオートスケール時の動作、特にスケールイン時についての問い合わせを目にしているので検証も兼ねて調べてみました。
Aurora Auto Scaling とは
指定されたポリシーに応じてAuroraのリーダーインスタンスを増減します。
接続およびワークロード要件を満たすために、Aurora Auto Scaling は、Aurora DB クラスター用にプロビジョニングされる Aurora レプリカ (リーダー DB インスタンス) の数を動的に調整します。
Aurora レプリカでの Amazon Aurora Auto Scaling の使用 - Amazon Aurora
よくいただくお問い合わせ
よくいただくお問い合わせは Aurora のスケールイン時の動作についてです。
基本的には ELB の connection drain のような機能は存在せず、スケールイン時にスケールイン対象のリーダーインスタンスで実行されているクエリは失敗する可能性があります。 リーダーインスタンスで実行されるクエリは読み取り専用のため、失敗した時の影響も限定的ではある認識です。(書き込み時のようなトランザクションのロールバック処理等が発生しない）
During a scale down operation Aurora terminates the extra reader instance, any running queries are terminated.
Schedule scaling for Amazon Aurora replicas using AWS Application Auto Scaling | AWS Database Blog
スケールインが発生した場合、スケールイン対象の DB インスタンスは deleteDBInstance API により削除されますが、削除が開始されるとリーダーエンドポイントから参照されなくなることが期待されます。
リーダーエンドポイントは、Aurora DB クラスター内の利用可能な Aurora レプリカへの接続を負荷分散します。
Amazon Aurora 接続管理 - Amazon Aurora
検証
検証環境
Aurora MySQL 3.05.1
ライターインスタンス1台
AutoScalingにより作成したリーダーインスタンス2台（後に1台削除)
リーダーエンドポイントの確認
dig コマンドにてリーダーエンドポイントを確認します。
リーダーエンドポイントに対してリーダーインスタンスのインスタンスエンドポイントがCNAMEレコードで登録されており、 インスタンスエンドポイントのAレコードからIPアドレスが取得されています。
また、繰り返し dig コマンドを実行することにより参照先が変わるので、参照先の変更により負荷分散が行われていることがわかります。
$ dig test.cluster-ro-xxxxxx.ap-northeast-1.rds.amazonaws.com (中略) ;; ANSWER SECTION: test.cluster-ro-xxxxxx.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME application-autoscaling-aaaaaa.ap-northeast-1.rds.amazonaws.com. application-autoscaling-aaaaaa.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.4.139 (中略) $ dig test.cluster-ro-xxxxxx.ap-northeast-1.rds.amazonaws.com (中略) ;; ANSWER SECTION: test.cluster-ro-xxxxxx.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME application-autoscaling-bbbbbb.ap-northeast-1.rds.amazonaws.com. application-autoscaling-bbbbbb.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.3.36 (中略)
Aurora リーダーエンドポイントは DNS CNAME エントリです。クラスターに複数のリーダーインスタンスがある場合、リーダーエンドポイントを解決すると、ラウンドロビン方式で選択されたインスタンス IP が取得されます。これは、リーダーエンドポイントにすべての Aurora レプリカが含まれ、新しい接続に対し DNS ベースのラウンドロビン負荷分散を提供するからです。
Amazon Aurora ライターエンドポイントに接続する際、接続がリーダーインスタンスにリダイレクトされる理由のトラブルシューティング | AWS re:Post
検証方法
1秒毎にDBインスタンスに接続し日時を取得しテキストに書き込むワンライナーを使用しました
#リーダーエンドポイント用 for i in `seq 1 600` ; do mysql -h test.cluster-ro-xxxxxx.ap-northeast-1.rds.amazonaws.com -u admin -pxxxxxx -e "select 'readerendpoint' as endpoint ,now()" >> ./readerendpoint.txt ; sleep 1 ; done #インスタンスエンドポイント1用 for i in `seq 1 600` ; do mysql -h application-autoscaling-aaaaaa.ap-northeast-1.rds.amazonaws.com -u admin -pxxxxxx -e "select 'instanceendpoint1' as endpoint ,now()" >> ./instanceendpoint1.txt ; sleep 1 ; done #インスタンスエンドポイント2用 for i in `seq 1 600` ; do mysql -h application-autoscaling-bbbbbb.ap-northeast-1.rds.amazonaws.com -u admin -pxxxxxx -e "select 'instanceendpoint2' as endpoint ,now()" >> ./instanceendpoint2.txt ; sleep 1 ; done
上記のコマンド実行中にリーダーインスタンスのスケールインを行います。
今回はインスタンスの最大容量を手動で2->1に減らしました。
検証結果
CloudTrailで確認したdeleteDBInstance API の実行時間は2024-2-13 15:32:51 (UTC+09:00)、インスタンスエンドポイント1側のDBインスタンスが削除されていました。
インスタンスエンドポイント側のクエリ実行はdelete DB Instance APIの実行から約4分後まで続き、その後は接続エラーにより実行できなくなりました。
(中略) endpoint now() instanceendpoint1 2024-02-13 15:36:43 endpoint now() instanceendpoint1 2024-02-13 15:36:44 endpoint now() instanceendpoint1 2024-02-13 15:36:45 (EOF)
リーダーエンドポイント、およびインスタンスエンドポイント2で実行していたクエリは当該時間帯も問題なく実行されていました。
(中略) endpoint now() readerendpoint 2024-02-13 15:36:40 endpoint now() readerendpoint 2024-02-13 15:36:41 endpoint now() readerendpoint 2024-02-13 15:36:42 endpoint now() readerendpoint 2024-02-13 15:36:43 endpoint now() readerendpoint 2024-02-13 15:36:44 endpoint now() readerendpoint 2024-02-13 15:36:45 endpoint now() readerendpoint 2024-02-13 15:36:46 endpoint now() readerendpoint 2024-02-13 15:36:47 endpoint now() readerendpoint 2024-02-13 15:36:48 endpoint now() readerendpoint 2024-02-13 15:36:49 endpoint now() readerendpoint 2024-02-13 15:36:50 (中略)
(中略) endpoint now() instanceendpoint2 2024-02-13 15:36:40 endpoint now() instanceendpoint2 2024-02-13 15:36:41 endpoint now() instanceendpoint2 2024-02-13 15:36:42 endpoint now() instanceendpoint2 2024-02-13 15:36:43 endpoint now() instanceendpoint2 2024-02-13 15:36:44 endpoint now() instanceendpoint2 2024-02-13 15:36:45 endpoint now() instanceendpoint2 2024-02-13 15:36:46 endpoint now() instanceendpoint2 2024-02-13 15:36:47 endpoint now() instanceendpoint2 2024-02-13 15:36:48 endpoint now() instanceendpoint2 2024-02-13 15:36:49 endpoint now() instanceendpoint2 2024-02-13 15:36:50 (中略)
リーダーエンドポイントの確認
digコマンドで確認しても、削除されていない方のDBインスタンスの結果しか返さなくなりました。
$ dig test.cluster-ro-xxxxxx.ap-northeast-1.rds.amazonaws.com (中略) ;; ANSWER SECTION: test.cluster-ro-xxxxxx.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME application-autoscaling-bbbbbb.ap-northeast-1.rds.amazonaws.com. application-autoscaling-bbbbbb.ap-northeast-1.rds.amazonaws.com. 5 IN A 10.0.3.36 (中略)
結論
スケールイン動作が発生した場合でも、リーダーエンドポイントを使用していればその時点で利用可能な DB インスタンスに接続されるという、期待された動作の確認ができました。
今回はオートスケール時の動作確認を行いましたが、手動でリーダーインスタンスを削除する場合も同様の動作が期待されます。
特に理由がない限りは、インスタンスエンドポイントではなくリーダーエンドポイントを使用することでスケールイン時の可用性が担保されますね。
この記事がどなたかの参考になれば幸いです。
