こんにちは。インサイトテクノロジーの松尾です！
前回の記事ではバージョンアップテストの流れや手順をご紹介しました。今回は早速、AWS マイグレーション機能を使った継続的なアセスメントを行ってみましょう。
Insight Database Testing の起動
Insight Database Testing のマネージャーである IDT Manager を起動します。IDT Manager は AWS Marketplace で提供しているため、通常の EC2 を起動する流れで簡単に IDT Manager を起動することができます。
詳細は、マニュアル ( IDT Managerの構築と設定（EC2の場合） ) を参照ください。
AWS マイグレーション機能を使用するにあたり、Insight Database Testing の EC2 には必要な RDS 操作を行うためのロールが設定されている必要があります。マニュアル ( 必要なIAM設定について ) の「AWSマイグレーション機能でスナップショットからRDSインスタンス/Aurora DBクラスターを作成する場合」の部分を参考にEC2にロールを設定してください。
Aurora PostgreSQL クラスターの用意
使用する Aurora PostgreSQL クラスターとして以下のものを使用します。
- 旧バージョンの現行稼働環境 （ソースDB、Amazon Aurora PostgreSQL 10.19）
なお、以下の2つの環境が AWS マイグレーション機能により作成されます。
- 旧バージョンのテスト環境 （テスト用ソースDB、Amazon Aurora PostgreSQL 10.19）
- 新バージョンのテスト環境 （ターゲットDB、Amazon Aurora PostgreSQL 12.9）
「旧バージョンの現行稼働環境」は、現在アプリケーションなどが使用している本番 DB となります。ここに対して実行されている SQL を取り込み、テストに使用します。
「旧バージョンのテスト環境」「新バージョンのテスト環境」については、取り込んだ SQL をテスト実行する DB となります。AWS マイグレーション機能では、スナップショットから両DBを作成できますので、スナップショットを用意しておきます。 （※あらかじめユーザーが用意することも可能です）
Aurora PostgreSQL からログを取得するための設定について
現行稼働環境の Aurora PostgreSQL では SQL の情報を出力するよう、pgaudit を有効にします。Aurora PostgreSQL の場合、クラスターパラメータグループで以下のような設定を行います。
pgaudit.logをALLに設定します。pgaudit.log_parameterをonに設定します。pgaudit.roleをrds_pgauditに設定します。log_rotation_ageを10に設定します。log_connectionsをonに設定します。log_disconnectionsをonに設定します。shared_preload_librariesにpgauditを追加（元の設定値は削除しないでください。）log_filenameをpostgresql.log.%Y-%m-%d-%H%M（通常は分単位（%M）を指定してください。）
詳細は、PostgreSQL を実行している Amazon RDS DB インスタンスを pgaudit 拡張機能を使用して監査するにはどうすればよいですか? や、マニュアル ( Amazon RDS/Aurora上でのログファイル出力設定 – RDS for PostgreSQL、Amazon Aurora（PostgreSQL互換エディション） ) を参考にしてください。
このパラメータの変更は Aurora PostgreSQL の再起動が必要となります。pgaudit のログが出力されるようになると、PostgreSQL のログファイルに、PGAUDIT と記載された行が出力されるようになります。AWS コンソールからログファイルをダウンロードしてみると、pgaudit のログが出力されるようになっているかを確認することができます。
AWS マイグレーション機能による設定
AWS マイグレーション機能を設定していきましょう。
- AWS マイグレーションの「新規作成」を選択します。
- 概要を入力します。
- ソースDB(現行稼働環境、ログ取得元)に関する情報を入力します。必要な情報は、リージョン、クラスターID、テスト対象DBです。既にログが大量に蓄積されている場合には、取得開始日を指定して古い日付を対象外にすることもできます。指定しない場合は、保存されているすべてのログが対象となりますが、量が多い場合には初回アセスメントに非常に時間を要する場合があります。
- テストDB(SQL実行先データベース)に関する情報を設定します。ここではAWSマイグレーション機能でテスト用のAuroraクラスターを用意します。使用するスナップショット、インスタンスクラス、リージョンの情報を入力します。オプショングループ、パラメータグループについては指定しない場合はデフォルトのものが使用されます。
- テストDB(SQL実行先データベース)に関する情報として、アップルグレード先のバージョンを指定する必要があります。使用するスナップショットからバージョンアップ可能なバージョンがわかっていればそれを指定します。わからなければいったん適当な文字を入力しておき、後で設定確認の時に修正することができます。ここでは適当に1.1と指定してみます。自動停止を有効にすると、アセスメント終了時に毎回クラスターを停止し、次回のアセスメント時に再度起動します。
- アセスメントの設定を入力します。通常のアセスメントの設定と変わりません。DBへの結果反映を「しない」とするとアセスメント時のSQL実行はセッション単位でロールバックされます。ここで、アセスメント時に使用するユーザー情報を設定しますが、この画面ではテスト対象DBがないためにテスト接続を行うことができません。入力が間違っているとアセスメントは全てエラーになるのでご注意ください。
- 実施スケジュールを設定します。いつまで実行するかと、実施の頻度を指定します。短い頻度で実施した方が、早めに問題に気づくことができるので、1-2時間ごとなど、短めの時間を指定した頻度で実施することをお勧めします。
- 以上で設定は終わりになるので、設定の確認を行います。IAMロールの設定がされていなかったり、設定値に問題があるとここでエラーが表示されます。
- 今回は移行先バージョンを適当に入力しているため、そこでエラーが出ました。
- さて、早速修正してみましょう。バージョン番号のところを確認すると、可能な値が表示されていますね。今回は想定した12.9を設定します。
- 再度確認してみると、今回は問題なしとなりました。ので早速新規作成を選択しましょう。
- 新規作成を開始すると、AWS マイグレーションの一覧へ追加されます。
- テスト用のAuroraクラスターの作成が開始されています。
- しばらくすると、クラスターが作成されたことを確認できます。
AWS マイグレーション機能による実行の確認
スケジュールのタイミングが過ぎたら、作成した AWS マイグレーションを確認してみましょう。スケジュール後は、SQLの取得（評価SQLセットの作成）、Auroraの起動(停止している場合)、アセスメント、の順で実行されます。まだアセスメントが実行されていない場合は、10分後などに再確認してみてください。
アセスメント実行後には、AWS マイグレーション画面にて結果のサマリーと、スケジュールのタイミングで実行したアセスメントの一覧を確認することができます。何かSQLの問題などがあった場合などは、アセスメントの画面から確認することができます。（※現在のバージョンではわずかでも時間が遅いと性能劣化と判定されるため、約半分のSQLが性能劣化と判定されます。今後のバージョンで改善予定。）
例えば実行結果が異なるようなSQLがあった場合も以下のように確認できます。
dbeaverで接続していくつか非互換SQLを実行してみたのですが、PostgreSQL 11でのpower関数の仕様変更や、dbeaver自体が発行したと思われる、SELECT version() も結果が異なるSQLとして検出されていることがわかります。結果が異なるSQLについては、実際にどのように結果が異なったかを表示することもできます。
このようなツールを行うことで、既に現在のアプリケーションで発行中のSQLに、どのくらい非互換のSQLが含まれているのか、含まれていないのかを簡単に事前に確認することができます。
どれくらい楽できるか？
このツールを使うとこれまでの手法に比べてどれくらい楽ができるでしょうか？
アプリケーションの規模、クリティカル度合い、どのくらいバージョンアップのテストに時間をかけるているかにもよると思いますが一例を考えています。
- Insight Database Testingを使わないこれまでのバージョンアップ確認
- DBの仕様変更調査 （0.25人月）
- ソースコードの調査 （1人月）
- 手動によるアプリケーションテスト （3人月）
- 発覚した問題の修正と確認 （0.5人月）
- Insight Database Testingを使ったバージョンアップ確認
- DBの仕様変更調査 （0.25人月）
- Insight Database Testingによる設定 （0.25人月）
- Insight Database Testingの実行結果の確認 （0.25人月）
- 発覚した問題の修正と確認 （0.5人月）
- 簡易的なアプリケーションテスト （0.5人月）
使わないとき（=4.75人月）、使ったとき（=1.75人月）で、3人月程度の工数削減効果があると計算してみました。小規模なアプリケーションだとこんな感じでしょうか。（※あくまで試算です）
さて、テストされているSQLの網羅レベルはどんなものでしょうか？これも手動アプリケーションテストの整備具合にもよりますが、、一般的には手動でやるテストから発行されるSQLのパターンとしては限定的となります。一方で、Insight Database Testingでは1週間や1か月など、指定期間中の稼働環境において発行されているSQLを対象とできるため、もちろん “実行されていないSQL” を対象とすることはできませんが、稼働中に発行されるいろんなパラメータの種類などを網羅していると考えられます。そのため、よりクリティカル度合いの高いアプリケーションでは、手動による手法に加えて、Insight Database Testing を使ったSQLテストも行う、という選択肢もあると思われます。
さらに、対象のDBが大量にある場合には、ツールを使用する効果は非常に大きなものとなります。Auroraの利用はますます広がってきており、自社内で数10を超えるAuroraを運用しているというケースも少なくないのではないでしょうか？このような状況に対し、どのようにDBバージョンアップをどのようにこなしていくか、という課題の解決は、喫緊の課題でもあるのです。
Amazon Aurora バージョンアップ対策ツール、Insight Database Testing
弊社で提供している Insight Database Testing について今回紹介しましたが、これまでのブログでも、そのような例を紹介してきました。
- 利用事例：ネットプロテクションズ｜Insight Database Testingでテストの網羅性を向上し、テスト工数を大きく削減 – Oracle Database のバージョンアップテストでの利用事例
- 利用事例：NTTデータ｜Amazon RDS のバージョンアップに伴いSQLを自動抽出しテストを2週間で完了 – Amazon RDS for MySQL のバージョンアップテストでの利用事例
- ブログ：Oracle 12c の EOL がやってくる！ – Oracle Database のバージョンアップでの利用についてのブログ
- ブログ：RDS や Aurora の EOL に備えて Insight Database Testing を使う – RDS for MySQL のバージョンアップでの利用についてのブログ
また、Oracle から PostgreSQL など、異なる種類のデータベースへ移行する際の SQL テストにももちろん利用可能です。
- 利用事例：電算システム｜Insight Database Testingで膨大な手間となるSQL検証を自動化し迅速化にする – Oracle Database からの PostgreSQL への移行アセスメントでの利用事例
- ブログ：Insight Database Testing と AWS SCT と連携して移行アセスメントをさらに省力化 – Insight Database Testing と AWS SCT を連携してのアセスメントの手順を記載したブログ
SQL テストにおいて、テストする SQL のカバレッジをあげるには、ある一定期間に実行された SQL を対象とする必要があります。どれだけ期間を長くしても 100% を保証することはできませんが、カバレッジを少しでも上げることはには資するでしょう。システムで週次バッチや月次バッチなど、通常とは異なる SQL が発行される可能性があらかじめわかっている場合には、そのタイミングで実行される SQL を対象に含めるようにするとよいと思います。
おわりに
本ブログでは、2023年1月に迎える Amazon Aurora PostgreSQL 10.x の EOS に伴うバージョンアップ確認作業に着目し、Insight Database Testing を使用する方法を紹介しました。
Insight Database Testing をまだご利用いただいていない方で実際に試されたい場合は、製品の説明やデモ、トライアルなどについて
Insight Database Testingに関するお問い合わせ よりお問い合わせいただければと思います。
次回もどうぞお楽しみに！
