目的
- Aurora ClusterのWriter/Readerのインスタンスタイプの変更を実施するにあたり、ダウンタイムが最小化できる方法を検討。
- アプリのアクセスがWriter/Reader双方に対してあったため、Readerをもう一台追加してオンラインでサイズ変更を行う方法を検証。
検証手順
- 以下手順における、踏み台サーバからのアクセスにおけるダウンタイム時間を調べてみる。
- Readerインスタンスを1台追加
- Reader1のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
- Reader2のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
- WriterのFailover
- 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.sqlCREATE TABLE rds_poc ( NAME TEXT NOT NULL );
測定結果
- 検証手順(再掲)
- Readerインスタンスを1台追加
- Reader1のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
- Reader2のインスタンスタイプ変更(db.t3.medium -> db.t3.large)
- WriterのFailover
- 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アクセスをインスタンス単位で制御する場合にはカスタムエンドポイントの利用も考えた方が良さそう(今回はアプリ側の改修インパクトが高いため、一旦見送り)