概要
Aurora Serverless v2 のメリット
- Aurora Serverless v2 は、データベースのリソースを自動的にスケーリングします。その結果、負荷の変動があるワークロードにおいて、コストメリットがあります。自動スケーリングは、ACU(Aurora capacity unit) に指定した最小容量と最大容量に基づいて行われます。
- ただし、ユースケースによっては、Aurora Serverless v2 の移行でコストが節約されるとは限りません。負荷が安定していれば、逆にコストが増えることも考えられます。
- Aurora Serverless v2 の詳細は、こちらのドキュメントを参照ください。
プロビジョニングインスタンスとServerless v2 の相違点
- プロビジョニングインスタンスと、Serverless v2 の一番大きい違いは、コストです。Serverless v2 の方が時間あたりの単価が高いです。コストの詳細は、こちらのドキュメントを参照ください。
- 基本的に、プロビジョニングインスタンスと、Serverless v2 は、多くのパラメータで動作は同じです。しかし、Serverless v2 では、一部のパラメータの取り扱いが変わります。詳細および相違点は、こちらのドキュメントを参照ください。
Aurora PostgreSQL のインスタンスをServerless v2 に移行する
今回やりたいこと
- 既存のAmazon Aurora をServerless v2 に切り替えます。
移行で注意すること
- Aurora MySQL で Aurora Serverless v2 が使用可能なエンジンバージョンは、バージョン 3.02.0 以降になります。Aurora PostgreSQL で Aurora Serverless v2 が使用可能なエンジンバージョンは、バージョン 15.2 以降、バージョン 14.3 以降、バージョン 13.6 以降になります。
- Aurora Serverless v2 が使用可能なエンジンバージョンの詳細は、こちらのドキュメントを参照ください。
- 既にAurora Serverless v2 をサポートするエンジンバージョンを使用している場合、特にバージョンアップ等を必要とせず、Serverless v2 への移行が出来ます。
- インスタンスのフェイルオーバーには、数十秒程度のダウンタイムがあります。ご承知おきください。
- 想定外のコストを回避するため、ACU(Aurora capacity unit) の最小容量と最大容量は、適切に指定します。
移行ステップを図解
- Aurora PostgreSQL クラスターがプロビジョニングされたインスタンス x2 で構成されています。
- クラスター内のインスタンスをServerless v2 に移行するため、Aurora Serverless v2 のリーダーを追加します。
- フェイルオーバーを行って、Aurora Serverless v2 のリーダーをライターに昇格させます。
- 経過観察の後に、プロビジョニングされたインスタンス x2 を削除します。
移行手順
- Aurora PostgreSQL クラスターがあります。ライター, リーダーがプロビジョニングされたインスタンスで構成されています。
- エンジンバージョンは、13.8 であり、Aurora Serverless v2 がサポートされているエンジンバージョンであることが分かります。
- 「アクション」→「リーダーの追加」を選択します。
- リーダーとなる追加インスタンスに Serverless v2 を選択します。
- ACU(Aurora capacity unit) を0.5～128 で指定します。ACUは、2 GiBのメモリと対応する CPU、ネットワークで提供されます。
- 追加インスタンスを配置するAZは、既存のライターインスタンスと同じ AZとします。
- フェイルオーバー優先順位は、既存のライターインスタンスに合わせます。
- Serverless v2 インスタンスの 1台追加に、約10分(7～9分くらい)掛かりました。続けて、リーダーインスタンスをもう1台追加します。
- 以下の通り、Aurora Serverless v2 のリーダーインスタンスが2台追加出来ました。(合計20分程度)
- Serverless v2 インスタンスを選択し、フェイルオーバーを実行します。「アクション」→「フェイルオーバー」を選択します。
- 以下の確認にて、「フェイルオーバー」を押します。
- 以下の通り、Serverless v2 インスタンスへフェイルオーバーが成功しました。
- フェイルオーバーの開始から完了まで、1分～1.5分程度掛かります。
- フェイルオーバーの実行中に、数秒から数十秒程度のダウンタイムがあります。クライアントからsql 接続が切断されました。
経過観察を行う
- 経過観察の期間はフェイルバックを考慮して、プロビジョニングのインスタンスは削除せず、キープしても良いと思います。
- ユースケースによっては、Aurora Serverless v2 の移行でコストが節約されるとは限りません。経過観察の期間に、スケーリングは行われるか、移行でインスタンスのコストは下がるか等を確認しましょう。
プロビジョニングのインスタンスを削除
- 最後に、移行の元になったプロビジョニングのインスタンスを削除します。
- 2つのインスタンス削除には、10分程度掛かりました。
補足
- リーダーの追加ではなく、既存のインスタンスを変更する方法もあります。インスタンスクラスをプロビジョニングのインスタンスから、Serverless v2 に変更する方法です。
- 実際に、インスタンスクラスを変更してプロビジョニングからServerless v2 への変更を試しました。リーダーの追加よりも、インスタンスクラスを変更する方が長い時間が掛かった認識です。私は、リーダーインスタンスの追加およびフェイルオーバーを行う手順を推奨します。
