Amazon Aurora のリストアにかかる時間
Amazon Aurora は、AWS の RDS のひとつとして提供されている RDB のサービスです。
MySQL および PostgreSQL の互換エディションが提供されています。
今回は、Aurora をスナップショットから復元する際の所要時間が、データサイズや DB インスタンスの種類によってどのように変化するのかを調べてみました。
検証条件
検証に使う Aurora は以下の構成としました。
- エディション : PorsgreSQL 13.5 互換
- キャパシティータイプ : Provisioned
- Aurora レプリカの作成 : なし
- リージョン : ap-northeast-1 (東京)
スナップショットからのリストア（復元）にかかる時間は、データサイズまたはインスタンスクラスによって違いが出るのではと考え、以下の組み合わせで全 9 パターンをリストアすることとしました。
- データサイズは 200GB / 400GB / 800GB の 3 パターン
- DB インスタンスクラスは t4g.medium, r6g.large, r6g.8xlarge の3パターン
インスタンスクラスは、以下の観点で選定しました。
- t4g.medium -> 選択可能な最も小さいもの
- r6g.large -> 現時点でデフォルトのインスタンスクラス
- r6g.8xlarge -> それなりの規模の商用環境などで使われる
計測にあたり、リストアにかかった時間の開始と終了は以下の定義としました。
RDS のイベントリストにはクラスタの作成開始が記録されないため、CloudTrail を利用しています。
- リストアの開始 : CloudTrail に記録された、当該 DB インスタンスの CreateDBInstance イベントのタイムスタンプ
- リストアの完了 : RDS のイベントに記録された、当該 DB インスタンスの "DB instance created" イベントのタイムスタンプ
検証データの作成
検証データの作成は こちら の stack overflow を参考にさせて頂きました。
1 テーブルあたり 13107200 行 (約 1,300 万行) のサンプルデータで、データサイズがほぼ 100 GB ぴったりになるため、きりの良い値で複数のデータサイズのスナップショットを用意することができました。
参考までに、下記の方のように pgbench でデータを投入し、CTAS でデータサイズをふくらませるという手段もありますね。
検証結果
最も所要時間が短かったのは 400GB x t4g.medium の 1,584 秒でした。
最も所要時間が長かったのは 800GB x r6g.8xlarge の 1,976 秒でした。
いずれの組み合わせも 1500 ~ 2000 秒の範囲に収まりました。
考察
検証結果から、200 ~ 800 GB程度のデータサイズでは、リストアの時間にデータサイズの大小がほぼ影響しないことがわかります。
追加で 1,200 GB x r6g.large も試しましたが、約 1,800 秒というところで他のパターンとの差はありませんでした。
また、インスタンスクラス毎の差はわずかにある（より大きいインスタンスクラスでリストアにより多くの時間を要している）ようにも見えますが、その差は大きくても 400 秒程度というところですので、実用上はこちらもほぼ差がないものと考えられます。
以上より、Aurora のリストアにかかる時間は、数百 GB 程度（おおよそ 1 TB 以下）のスナップショットであればインスタンスクラスに関わらず 30〜40 分程度で完了すると思っておいても良さそうです。
その他の気付き
参考までに、ひとつのスナップショットから複数のクラスタを一度にリストアしたところ、各クラスタの復元完了までの所要時間は上記検証の倍以上となりました。
おそらく、復元の際に行われるスナップショットからのデータ読み取りに関して I/O の制約があるものと思われます。
以下は Aurora MySQL 互換に関する AWS プレミアサポートのナレッジセンタに公開されている情報ですが、バックアップ作成時点でソース側に長時間実行されるトランザクションがある場合、リストアに通常よりも多くの時間を要することがあるようです。
商用の利用ではこうしたソースデータベース側の状態というのも影響要素になり得るかと思います。
あくまで個人による簡易な検証結果ですが、何かのお役に立てば幸いです。
