こんにちは、石原です。
最近、AWS上のデータベースのバージョンアップの検証を行うタイミングで「Insight SQL Testing」を触る機会があったので、こちらの製品についてご紹介いたします。
Insight SQL Testingとは？
Insight SQL Testingはインサイトテクノロジー社が提供している製品になります。
Insight SQL Testingは、データベース移行やバージョンアップに伴うSQLテストを効率化するためのソフトウェアになります。このツールは、データベース移行やバージョンアップ時の工数を大幅に削減し、性能や互換性を確認して修正が必要なSQLを検出することができます。
こちらの製品には以下のような特徴があります。
①マルチデータベース対応
Oracle をはじめ、様々なデータベースをサポートしています。
②自動SQL収集
本番環境で実行されるSQLを自動(または手動)で収集し、テストを実行することができます。これにより、手動での作業を大幅に削減できます。
③異種データベース間のテスト
異なるデータベース製品間でのSQLテストを行うことができ、移行時の問題点を洗い出すことができます。
MySQLのバージョンアップで使ってみた
データベースのバージョンアップを行うことにより内部動作が大きく変わることがあります。そこまで動作が変わらないだろうと思い、バージョンアップした後に今まで実施していた処理を流してみたらエラーになったという話はよく聞くと思います。では事前にバージョンアップさせた検証機を作成し、テストしようとしても結局どれの処理で問題が起きエラーになったのか、処理が遅延が発生したのか切り分けていくのは大変です。
今回は、このような検証を一括で容易に行えるInsight SQL Testingを用いることでどのような結果が得られるか、本当にSQLテストを効率化させることができるのか試してみました。なお用いたデータベースはMySQLになるため、本内容もMySQLに特化した内容となる点はあらかじめご了承ください。
Insight SQL Testingを利用するうえで用意するもの
今回私がInsight SQL Testing環境を用意するにあたり、AWS上で実施しました。そのためAWS観点で使用する前提の内容とはなりますが、具体的には AWS Marketplace から SQL Testing Manager のAmazon マシンイメージを入手してInsight SQL Testing用の EC2 を用意しました。
後は、別途以下を用意する必要があります。Insight SQL Testingにこれらの環境を自動で生成する能力はないので、頑張って用意します。いずれもAWS上にあるRDSになります。
①移行元のジェネラルログ
※ジェネラルログは一般ログと呼称する場合もありますが、ここではジェネラルログで統一します。
②移行元のコピーDB(A)
※コピー後にバージョンアップした環境
③移行元のコピーDB(B)
それぞれについて用途を説明します。
①移行元のジェネラルログ
このログはMySQL環境で出力されるログであり、データベース内で実行されるすべてのSQLの処理を記録します。SELECT文も含め、全部のSQLを記録するのですからMySQLは凄いですね。この特性を持つジェネラルログを利用して移行元で作成されるジェネラルログをまるっとInsight SQL Testing側に読み込ませます。ちなみにユーザー情報もセットで読み込ませることができるので、最終的には不要なユーザーの処理を省くことも可能です。
②移行元のコピーDB(A) ※コピー後にバージョンアップした環境
これは移行元のコピー環境を用意し、その後目的のバージョンまで引き上げたものです。Insight SQL Testingで読み込ませた処理をこの環境に実行することになります。Insight SQL Testingで読み取った処理は元々はバージョンアップ前では正常に実行できていたものなので、それをバージョンアップした環境で実行するとどうなるかデータの互換性を確認することができます。
③移行元のコピーDB(B)
これはコピーDB(A)同様、移行元のスナップショットなどのバックアップから作成したものです。目的としてはバージョンアップした環境との対比として使用します。移行元のコピー環境Bも用いることでパフォーマンス観点からも確認が行えるようになります。
Insight SQL Testingの操作
環境が揃った状態で、いよいよInsight SQL Testingを操作していきます。操作は大きく分けると以下のような感じになります。
①ログの読み込み
取り込み方は色々用意されており、実際に移行元につないでQueryの情報を引っ張って来ることも可能です。
今回の場合は、MySQLのジェネラルログをローカルに配置し、そのログを直接読ませて取り込むという方法で実施しました。
②SQLを流す先のDBの登録
前の記載内容の移行元のコピー環境Bとバージョンアップした環境AをInsight SQL Testingに認識させます。
③SQLを実行し結果をみる
あとは実際に登録したDBに対して読み込んだログの内容を実行をします。バージョンアップ前(コピーDB(B))と後(コピーDB(A))の2つの環境に対して、Insight SQL Testingに読み込ませた処理をInsight SQL Testingの命令によって実行させます。Insight SQL Testingは最終的にパフォーマンス結果や処理の失敗などをまとめて報告してくれるので実際のバージョンアップ前に事前に問題の洗い出しが可能となります。
結果から得られるもの
具体的には以下の項目が確認できます。
①ターゲットDBでのみ失敗
②テスト用ソースDBでのみ失敗
③両DBで失敗
④結果が相違
⑤性能が劣化
⑥成功
最後にそれぞれについて簡単に説明します。
①ターゲットDBでのみ失敗
ここでいうターゲットDBは「バージョンアップしたDB(A)」を指します。ここに引っかかったSQLはバージョンアップの影響で失敗した可能性が高いといえます。もちろん、そのSQLについて念のために再実行するなどして再現性は確認した方がいいとは思います。なお、Insight SQL Testing内で任意のSQLを実行する画面もあるので、そこから再実行可能です。
②テスト用ソースDBでのみ失敗
このテスト用ソースDBは「移行元のコピーDB(B)」を指します。本来、ここで失敗することはないと思われます。失敗する可能性としては、例えば移行元のコピーとして用意していますが、その後、コピー元またはコピー先で操作(テーブルなどの作成)を実施しその影響でテーブルがコピー先にないことや逆に既に表が存在するなどが考えられます。
③両DBで失敗
これは記載どおり、「バージョンアップしたDB(A)」および「移行元のコピーDB(B)」で処理が失敗したSQLになります。これも②同様、ここに載って来る可能性は少ないと考えられます。
ただし、例えば以前実行したことがあるInsert文を含むジェネラルログを実行した場合、Insert先がPRIMARY KEY制約などを持った表の場合には失敗することがあります。
④結果が相違
こちらはSQL自体、両DBともに正常に実行できたが、処理の結果として影響があった件数が異なる場合や、処理結果自体が異なる場合（ソート順の仕様変更等に起因するものなど）にカウントされます。基本はSELECTの結果になりますが、他にDMLやSHOWコマンドなどの結果も対象となります。こちらに該当したものは、ただ単に②のような環境コピー後の差異の影響であるのか、またはバージョンアップによる影響や③のようなDMLを重複実行している場合など確認が必要になります。
⑤性能が劣化
今までのような問題が発生しない場合、⑤か⑥に振り分けられます。実行速度が、 「コピーDB(B)」＞ 「バージョンアップしたDB(A)」になったSQLがこちらになります。なお、デフォルトの設定を満たしてしまうと劣化扱いになります。そのため、アセスメントの設定において、遅延をどれだけ容認できるか設定しておくことが重要です。設定には秒数だけなく割合も指定することが可能です。実際に実行する場合は、事前にここの設定を行ったうえで実施することがお勧めです。
⑥成功
以下を満たしたものが対象となります。
・「エラーにならない」
・「結果も同じ」
・「処理時間も今まで以下」
基本的に、こちらの枠に入ったSQLは特にバージョンアップにおいて考慮する必要はありません。
一例ですが、以下のように振り分けられます。ステータスは先の画像から判断できます。以下は意図的に各項目に引っかかるような処理をジェネラルログ上に出力させ、Insight SQL Testingから処理を実行したものなのですべてのパターンを網羅した表記になっています。
これらの結果を踏まえて、再度調整してSQLを実行したりしながらバージョンアップの問題点を解決していきます。
まとめ
今回、Insight SQL Testingを操作するにあたって簡単に概要や操作の流れをまとめてみました。
Insight SQL Testingを用いても失敗した処理などにおいて、改善する方法は提示されることはありませんが、Insight SQL Testingを用いた方がより短時間で確実なバージョンアップまたは別ＤＢ移行などが出来そうです。改良の余地がある点はありますが、これは今後に期待です。
今回は簡単に全体の流れからどのようなものが確認できるのかをブログで記載してみました。もっと詳しく細かく知りたい方のために、今後具体的にインストールから実行結果、Insight SQL Testingを扱う際の注意事項を今後も取り上げていこうと思います。
少しでもInsight SQL Testingについて興味を持っていただければ幸いです。