目的

Aurora ClusterのWriter/Readerのインスタンスタイプの変更を実施するにあたり、ダウンタイムが最小化できる方法を検討。
アプリのアクセスがWriter/Reader双方に対してあったため、Readerをもう一台追加してオンラインでサイズ変更を行う方法を検証。

検証手順

以下手順における、踏み台サーバからのアクセスにおけるダウンタイム時間を調べてみる。
1. Readerインスタンスを1台追加
2. Reader1のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
3. Reader2のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
4. WriterのFailover
5. Writerのインスタンスタイプ変更(db.t3.medium -> db.t3.large)

検証構成

以下の構成でWriter/Readerのインスタンスタイプをt3.mediumからt3.large変更する。

インスタンス台数	Engine	Engine version
Writer1台+Reader2台	Aurora PostgreSQL	12.9

構成図

ダウンタイム測定

今回の検証では以下のスクリプトで1秒単位で以下の処理を行い、ダウンタイムを計測する。

クラスタエンドポイントに対して書き込み

write.sh

#! /usr/bin/sh
ENDPOINT='db.ap-northeast-1.poc-rds-custom'
DB_NAME='rds_poc'
DB_USER='root'
COMMAND='INSERT INTO rds_poc VALUES (1);'

# INSERT
while true
do
  echo `date` `psql -h ${ENDPOINT} -d ${DB_NAME} -U ${DB_USER} -c "${COMMAND}"`;
  sleep 1;
done

リードエンドポイントに対して読み込み

read.sh

#! /usr/bin/sh
ENDPOINT='db.ap-northeast-1.poc-rds-custom'
DB_NAME='rds_poc'
DB_USER='root'
COMMAND='SELECT * FROM rds_poc LIMIT 1;'

# SELECT
while true
do
 echo `date` `psql -h ${ENDPOINT} -d ${DB_NAME} -U ${DB_USER} -c "${COMMAND}"`;
 sleep 1;
done

事前にテスト用のテーブルを作成しておく

create_table.sql

CREATE TABLE rds_poc (
 NAME TEXT  NOT NULL
);

測定結果

検証手順（再掲）
1. Readerインスタンスを1台追加
2. Reader1のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
3. Reader2のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
4. WriterのFailover
5. Writerのインスタンスタイプ変更(db.t3.medium -> db.t3.large)

	Writeダウンタイム（sec）	Readダウンタイム（sec）	所要時間（min）
手順1	-	-	15 min
手順2	0 sec	0 sec	10 min
手順3	0 sec	0 sec	10 min
手順4	9 sec	14 sec	1 min
手順5	0 sec	0 sec	10 min

所感

Reader2台構成とすることで、donwtimeを最小化しつつインスタンスタイプの変更が実施できた
今回は踏み台サーバからの簡単なスクリプトを用いて検証を行なったが、client cache保持時間や作業時のアプリケーションのワークロード次第ではアクセスエラーとなる可能性があるため、考慮が必要
Readアクセスをインスタンス単位で制御する場合にはカスタムエンドポイントの利用も考えた方が良さそう（今回はアプリ側の改修インパクトが高いため、一旦見送り）