Auroraのスケールイン時の動作を検証してみた

記事タイトルとURLをコピーする

こんにちは。テクニカルサポート課の森本です。

最近、ちょくちょく 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 インスタンスに接続されるという、期待された動作の確認ができました。

今回はオートスケール時の動作確認を行いましたが、手動でリーダーインスタンスを削除する場合も同様の動作が期待されます。

特に理由がない限りは、インスタンスエンドポイントではなくリーダーエンドポイントを使用することでスケールイン時の可用性が担保されますね。

この記事がどなたかの参考になれば幸いです。

森本 晃大(執筆記事の一覧)

テクニカルサポート課

2023年10月入社。絶賛仕事と子育てに奔走中です。