Amazon Aurora PostgreSQL 10.x の EOS に備えて DB のバージョンアップテストを行う その1

こんにちは。インサイトテクノロジーの松尾です!

今年2022年は、札幌のよさこいソーラン祭りも久々に実施されました!(個人的にはあまり踊りは興味ないですが・・・)

Amazon Aurora PostgreSQL 10.x の EOS が2023年1月にやってきます!

ところで、いよいよ Amazon Aurora PostgreSQL 10.x の EOS ( end of support、サポート終了 ) が2023年1月にやってきます!

移行は済ませましたか?または、移行の準備は進んでいますか?

Aurora PostgreSQL 10.x のクラスターを持っている方は、きっと、管理者宛に「[Action Required – xxxx Notice] Upgrade Amazon Aurora PostgreSQL 10.x by January 31, 2023」というメールが来ているのではないでしょうか。

重要な日付としては主に以下になると思われます。

  • Starting August 1, 2022, you will no longer be able to create new Aurora clusters or instances with Aurora PostgreSQL major version 10.x from either the AWS Console or the CLI.
  • Starting January 31, 2023 Amazon Aurora will upgrade your Amazon Aurora PostgreSQL 10.x databases to the appropriate Amazon Aurora PostgreSQL major version during a scheduled maintenance window on or after January 31, 2023.

これから新規のシステムで Aurora PostgreSQL 10.x のクラスターを新規に作成される方はいないかと思いますが、テスト用の何かを作成したいときも、2022年8月1日以降は新規には作成できなくなるようなので、どうぞご注意ください。

昨年も Aurora PostgreSQL 9.6 の EOS ( end of support, eol, end of life ) がありましたが、Aurora PostgreSQL の利用がどんどん増えていることを考えると、Aurora のバージョンアップに気を遣う方も、これからどんどん増えて来るのではないかと思います。

さあ移行を計画しよう!

全てを自分で管理できるオンプレ環境とは異なり、Aurora のようなマネージドなデータベースでは、クラウドベンダーが計画的にバージョンアップを行っていきます。EOS を待ってもらえることはありません。そのため、DB のバージョンアップを計画的に行うことが非常に重要となります。

また、メジャーバージョンアップでは、上記文中に “Major version upgrades can contain database changes that are not backward-compatible with existing applications.” とあるように、互換のない変更が行われている場合があります。そして、互換のない変更があるからこそ、”Before applying an upgrade to your production DB clusters, make sure that you thoroughly test any upgrade to verify that all your applications work correctly.” と記載があるよう、アプリケーションが正しく動作することを事前に確認しておく必要があります。

さて、どのように確認しますか?

一般的には、バージョンアップしたテスト環境を用意し、アプリケーションを接続して一通り確認して、という流れで確認することが多いのではないでしょうか?もちろん、アプリケーションを通してのテストで全シナリオを網羅できていれば問題ないですが、網羅性の確認や、マンパワーの確保など、テストを行うにも課題が多いのではないでしょうか?

そして、Aurora のようなマネージドデータベースでは、3~4年に一度、DB メジャーバージョンのバージョンアップが必然になってくることが予想されます。Aurora を長期的に運用していく上では、数年に1回の DB メジャーバージョンのバージョンアップをどのようにこなしていくかを計画しておくことも重要になってきますね!

SQL テストでバージョンアップテストを効率化

おそらく多くの方が実施されている、アプリケーションテスト。事前に GUI アプリケーションテストの自動化などが構築されている場合は、かなり網羅的なテストが実施できていることでしょう。もし、GUI アプリケーションテストの自動化が構築されていない場合、その多くは、人手でテストを実施することになります。

どのようなテストをするにせよ、一般的に 100% カバーするテストを行うことは難しいと思います。一方で、100%は目指せないまでも、限られたリソースで、なるべくカバレッジを上げるべく計画されていると思います。
当然マンパワーに頼るにはコストが多くかかりますので限界があります。ここに SQL テストを利用することで、効率的にテストのカバレッジを上げるツールが『Insight Database Testing』です。

現在移行テスト中の方、現在移行テストを計画中の方、これから移行テストを計画される方、テストのカバレッジを上げる手段の一つとして、Insight Database Testing のテストをご検討下さい。

SQL テストによるバージョンアップテスト

バージョンアップの確認を目的とした SQL テストでは、
あらかじめ何らかの手段で用意した SQL が、バージョンアップ前とバージョンアップ後で同じ挙動をするかを確認します。
そのため、SQL テストは以下のような流れで行います。

  1. SQL の用意
  2. テスト用データベースの用意
  3. 用意した SQL をテスト用データベースに対して実行
  4. 実行結果の集計・評価

SQL テストで必要となる「SQL の用意 ~ SQL のテスト ~ 結果の評価」の流れを手作業で行うのには膨大な労力を要します。これを、ツールで簡単に実現するのが Insight Database Testing です。
Insight Database Testing による SQL テストでは、そのテスト用の SQL として、
現行稼働システムで動作中のデータベースに対して発行されている SQL を、テスト用の SQL として手をかけずに利用する仕組みを提供します。

SQL テストにおいて、テストする SQL のカバレッジをあげるには、ある一定期間に実行された SQL を対象とする必要があります。どれだけ期間を長くしても 100% を保証することはできませんが、カバレッジを少しでも上げることはには資するでしょう。システムで週次バッチや月次バッチなど、通常とは異なる SQL が発行される可能性があらかじめわかっている場合には、そのタイミングで実行される SQL を対象に含めるようにします。

Insight Database Testing には、Amazon Aurora バージョンアップを目的としたテストを効率よく行う機能である「AWS マイグレーション機能」という機能があります。AWS マイグレーション機能を使用すると、例えば2週間など、あらかじめ指定した期間に対する「SQL の用意 ~ SQL のテスト ~ 結果の評価」を自動で行うことができます。

AWS マイグレーション機能を用いた確認手順

本ブログでは、Aurora PostgreSQL のバージョンアップテストを例として、AWS マイグレーション機能を用いた確認手順を紹介します。Aurora PostgreSQL のバージョンアップは、10.19 から 12.9 へ行うことを想定しています。移行先として 12.9 を想定しているのは、12.9 が LTS だからです。ただ、12.9 へ自動でバージョンアップさせるには、スナップショットが 10.19 でなければならないことにもご注意ください。

テストの構成としては以下のようになります。

ポイントとしては、テスト用のインスタンスとして、新バージョンのものと旧バージョンのものとを使用することです。このような構成とすることで、同じ SQL を発行した時の挙動の差異の比較を行います。

AWS マイグレーション機能には、RDS のスナップショットを使用したテスト環境の自動生成も可能です。今回のブログでは、その機能を利用してテスト環境を用意して行います。

事前に必要なものとしては以下となります

  • 旧バージョンの現行稼働環境 (ソースDB、Amazon Aurora PostgreSQL 10.19)
  • 現行稼働環境から取得したスナップショット (テスト環境用)

AWS マイグレーション機能では以下の流れでテストが行われます。

  • AWS マイグレーションプロジェクトの作成
  • スナップショットからテスト環境の用意
  • 定期的なアセスメント開始 (以下を指定スケジュールの間繰り返す)
  • Aurora からログファイルを取得して SQL を抽出
  • SQL をテスト DB に対して実行 (アセスメント)

最初に AWS マイグレーションプロジェクトを作成すると、後は指定期間の SQL 取得とアセスメントが自動で行われます。

今回はバージョンアップ時のテストの流れや手順までご紹介しました。次回の記事「Amazon Aurora PostgreSQL 10.x の EOS に備えて DB のバージョンアップテストを行う その2」ではAWSマイグレーションを使ったアセスメントを行っていきます。

関連最新記事

TOP インサイトブログ Insight Database Testing Amazon Aurora PostgreSQL 10.x の EOS に備えて DB のバージョンアップテストを行う その1

Recruit 採用情報

Contact お問い合わせ

  購入済みの製品サポートはこちら