こんにちは
今回は Aurora MySQL のインスタンスを t系 から Aurora Serverless へ移行した備忘録となります
なお、やってみた動機としては、既存のインスタンスクラスをAurora Serverlessへ変更したことがなく、ダウンタイムの有無や実際の挙動を確認したかったからとなります
■Aurora Serverless とは
まずは簡単に Aurora Serverless について説明します
公式ドキュメントによると下記が記載されており、負荷に応じてコンピューティングリソース（CPU・メモリ）を自動的にスケーリングが実行されます
それに従い、運用などで負荷が増大した際の手動でのインスタンス追加などからある程度は解放されます
Amazon Aurora のオンデマンドの自動スケーリング設定です。
アプリケーションニーズに応じて、自動的に起動、シャットダウン、および容量をスケールアップまたはスケールダウンします。
また、Serverless 同時の考え方として ACU が存在し、各 ACU では約 2 ギビバイト (GiB) のメモリと、対応する CPU、ネットワークが組み合わされ、0 ACU から 256 ACU までの容量を決めることができます
※0 ACU は Aurora PostgreSQL 13.15 以上、14.12 以上、15.7 以上、16.3 以上 、Aurora MySQL 3.08 以上 でサポートされています
なお、もし下限を 0 ACU としており、実際に 0 ACU までスケールダウンした場合、Aurora クラスターが一時停止状態となるので、本番環境などでは最低でも 0.5 か 1 ACU は設定しておいたほうが安全です
参考：Aurora serverless の自動一時停止と再開によるゼロ ACU へのスケーリング
■やってみた
それでは、実際にコンソール上にて t系(db.t3.medium) から Aurora Serverless へ移行してみます
なお、確認の観点としては下記とします
・コンソール上の設定画面項目
・切替完了までの所要時間
・ダウンタイムの有無
なお、今回は 一旦 最小ACU：1、最大ACU：2 で設定してみます
変更のサマリー画面では下記のようになり、移行にあたり手動でのパラメータグループの変更などは発生しませんでした
次に、切替完了までの時間とダウンタイムを確認してみます
インスタンスのログとイベントタブ内に下記が出力されていたので、切替完了までは大体10分ほどであり、ダウンタイム(DB instance shutdown)も2度ほど発生していました
なので、もし本番環境で移行する場合は、ダウンタイムを考慮して対応する必要がありそうです
|
Finished updating DB parameter group
|
|
|
Performance Insights has been disabled
|
|
|
Monitoring Interval changed to 60
|
|
|
DB instance restarted
|
|
|
DB instance shutdown
|
|
|
DB instance restarted
|
|
|
Finished applying modification to DB instance class
|
|
|
DB instance shutdown
|
|
|
Applying modification to database instance class
|
なお、もしダウンタイムを最小限に抑えたい場合は、下記流れをとることでフェイルオーバー実行時の瞬断のみに抑えることが可能です
1. Aurora Severless でリーダーインスタンスの追加
2. フェイルオーバーを実行し、Aurora Severless インスタンスをライターへ昇格
3. 旧t系インスタンスの削除
■最後に
いかがでしたでしょうか
私自身あまり Aurora と Aurora Serverless の知識がなく、正直 ACU などもかなり曖昧でした
ただ、今回の検証を通して、体系的な知識の取得と、移行時の実際の挙動を自分の目で確認できたのでかなり勉強になりました
おそらく今後は Serverless のインスタンスを利用する機会も増えてくると思うので、今回学んだことを頭の片隅に置いておくようにします
それではまた