こんにちは。テクニカルサポート課の森本です。
昨今巷は生成 AI 関連のブログで溢れていますがこのブログではあえてまったく関係ないニッチな Aurora PostgreSQL クローンの小ネタを紹介します。
クローン機能について
Aurora のクローン機能では、既存のクラスターと同様のデータを持つクローンを迅速に作成できます。コピーオンライト（Copy-on-Write）プロトコルを使用するため、スナップショットから復元する場合と比較してもコスト面でも優位性があります。
By using Aurora cloning, you can create a new cluster that initially shares the same data pages as the original, but is a separate and independent volume. The process is designed to be fast and cost-effective. The new cluster with its associated data volume is known as a clone. Creating a clone is faster and more space-efficient than physically copying the data using other techniques, such as restoring a snapshot.
Cloning a volume for an Amazon Aurora DB cluster - Amazon Aurora
有用な場面について
ドキュメントにも記載がありますが、特に以下のような場面でクローン機能は有効です。当社テクニカルサポートへお問い合わせいただいた場合でも、”クローンを使用して検証していただければ〜" とご案内することがよくあります。
潜在的な変更 (スキーマの変更やパラメータグループの変更など) を試して、すべての影響を評価する。
データのエクスポートや分析クエリの実行など、大量のワークロードを扱うオペレーションをクローン上で実行する。
開発、テスト、またはその他の目的のために、本番 DB クラスターのコピーを作成する
注意点
現時点で確認できている動作として、クローンを作成する場合、Aurora のパッチバージョンがクローン作成元と同じバージョンで固定されず、クローン作成時に利用可能な最新パッチバージョンで作成されます。
クローン作成元(17.7.3)
postgres=> select aurora_version(); aurora_version ---------------- 17.7.3 (1 row)
クローンしたクラスター(17.7.4)
postgres=> select aurora_version(); aurora_version ---------------- 17.7.4 (1 row)
何が困るのか
例えば、重いバッチ処理を行う場合のおおまかな時間を事前に計測することを目的として、クローン環境で実施するとします。
仮にパッチバージョンの差異によりパフォーマンス関連の改善が行われていた場合、クローン環境での確認結果とクローン元の実際の時間に大きな差異が発生してしまう可能性があります。
パッチバージョンの違いによる影響を最小限に留めるため、クローンでの検証時は可能な限りクローン元も最新のパッチバージョンを実行しておくことが有効と考えられます。
以下は Aurora PostgreSQL 17.4.3 で修正された内容の例です。
Fixed an issue where unexpected internal communication channel re-establishments may cause increased latency on data processing.
Amazon Aurora PostgreSQL updates - Amazon Aurora
余談
じゃあクローンではなく、スナップショットからの復元ではパッチバージョンは固定されないの？と考えて試しましたが、クローン同様スナップショットからの復元でも、最新のパッチバージョンで復元されます。 現時点では、最新のパッチバージョンを実行していない場合において、パッチバージョンを固定した環境を復元することはできないようです。
まとめ
今回は Aurora PostgreSQL のクローン/スナップショットの復元時に発生するちょっとした小ネタをまとめました。
この記事がどなたかのお役に立てば幸いです。
