こんにちは。インサイトテクノロジーの松尾です！
さて、RDS for MySQL 5.6 の EOL ( end-of-life、サポート終了 ) のタイミングが延期される旨の連絡がありましたね！準備が進んでいなかった方は、少し一息つける方もいらっしゃるのではないでしょうか？
当初のサポート終了タイミングまで約一か月となったこのタイミングでの延長の発表は、多くのユーザーがこの強制バージョンアップに対して準備万端ではないことを物語っているのかもしれません。とはいえ、いずれはバージョンアップしなければならないタイミングがやってくるのは確かなので、着実に準備を進めていくことが求められることに変わりはありません。
本ブログでは Amazon RDS や Amazon Aurora の EOL に伴うバージョンアップ確認作業に、Insight Database Testing を使用した例を紹介いたします。
迫りくる RDS や Aurora の EOL
ソフトウェアがどんどん機能追加されたり不具合修正されたりしてバージョンアップされていくのは世の常であり、それはデータベースも例外ではありません。MySQL や PostgreSQL そして Oracle Database も、DBMS のソフトウェア自身がサポートされなくなることに伴い、RDS や Aurora でもサポートが打ち切られていくようです。
- Amazon RDS for MySQL バージョン 5.6 のサポート終了のお知らせ – 2021 年 8 月 3 日 → 2022 年 3 月 1 日へ延期
- Amazon RDS for PostgreSQL バージョン 9.6 のサポート終了のお知らせ – 2022 年 1 月 18 日
- Aurora PostgreSQL バージョン 9.6 のサポート終了のお知らせ – 2022 年 1 月 31 日
- Amazon RDS for Oracle バージョン 12.1.0.2と12.2.0.1 のサポート終了のお知らせ – 2022 年 7 月 31 日
データベース自体の稼働を管理しなくてよい RDS や Aurora は、利用する分には非常に便利であり、マネージドな DBMS の利用は今後もますます増えていくものと思われます。が、DBMS のバージョンアップ問題についてはオンプレ環境にデータベースを持っているときと同様にケアしなければならないことには注意が必要です。
‘古いまま’ 使い続けることができない
全てを自分で管理できるオンプレ環境では、サポートが打ち切られることを許容もしくはサードパーティのサポート提供会社と契約すれば、バージョンアップをせずに古いバージョンのまま動かすという選択肢がありました。しかし、ソフトウェアの管理自体をクラウドベンダーが行うマネージドなデータベースでは、クラウドベンダーが計画的にバージョンアップを行っていきます。
RDS の例だと、メジャーバージョンリリースは最低 3 年間サポートされていることが謳われており、DBMS 自体のそのバージョンが延長サポートに移行された場合や、ソフトウェアの修正やセキュリティアップデートが行われなくなった場合に廃止対象となるようです。
サポート停止となる場合は、廃止までの移行期間が設定され、その期間に手動でバージョンアップの処理を行わなかったデータベースは、強制バージョンアップの対象となります。
- 参考 (Amazon RDS のよくある質問 )
- Q: Amazon RDS では、現在サポートされているバージョンのデータベースエンジンの廃止についてガイドラインが提供されていますか?
- Q: RDS DB のエンジンバージョンが廃止されるとどうなりますか?
データベースバージョンアップにテストはどれくらい必要か？
データベースのバージョンアップであれば、互換性は基本保たれているであろう、と、テストを簡単な稼働確認レベルで済ませることも多いかもしれません。実際、マイナーバージョンアップなどは、RDS でも自動バージョンアップもできるくらいですので、アプリが動かなくなるような大きな修正は基本は発生しないと考えてよいかもしれません。
一方、メジャーバージョンアップともなると、さすがに何も考えずにバージョンアップするわけにはいかず、テスト環境へバージョンアップテスト用のデータベースを用意して、アプリケーションを接続して一通り確認して、という流れで確認することが多いのではないでしょうか？
もちろん、アプリケーションを通してのテストで全シナリオを網羅できていれば問題ないですが、網羅性の確認や、マンパワーの確保など、テストを行うにも課題が多いのではないでしょうか？
バージョンアップのテストに有効な SQL テスト
バージョンアップ時によくある変更としては、一般的には以下のようなものがあります。
- 非互換な変更
- 構文チェック強化
- 予約語/キーワードの追加
- システムテーブルの変更
- 組み込み関数の挙動の変更
- パフォーマンス関連
- オプティマイザの変更
- パラメータのデフォルトの変更
データベースのバージョンアップであれば、基本的にはこれまで通り動作すること、そして性能劣化がないことが期待されていると思います。
現行のデータベースで発行されている SQL が、バージョンアップ後のデータベースでもそのまま動作するか？著しい性能劣化がないかを、テストするのが SQL テストで実施することとなります。SQL テストは以下の流れで行います。
- SQL の収集
- テスト用データベースの用意
- 収集した SQL をテスト用データベースに対して実行
- 実行結果の集計・評価
弊社で提供している Insight Database Testing は、Oracle から PostgreSQL など、異なる種類のデータベースへ移行する際の SQL テストをサポートする移行アセスメントツールですが、移行元と移行先のそれぞれのデータベースで Oracle Database、SQL Server、PostgreSQL、MySQL をサポートしていることから ( 詳細はお問い合わせください )、データベースのバージョンアップ確認へ利用されている例も多くあります。
- 参考：ネットプロテクションズ｜Insight Database Testingでテストの網羅性を向上し、テスト工数を大きく削減 – Oracle Database のバージョンアップでの利用事例
RDS for MySQL を 5.6 から 5.7 へバージョンアップする際のテスト例
今回は、まさに延期が発表された RDS for MySQL を 5.6 から 5.7 へバージョンアップすることを想定し、Insight Database Testing を使用したアセスメント例をご紹介します。
RDS for MySQL 5.6 から 5.7 への変更点はどういったものがあるでしょうか？
MySQL のサイト – Changes in MySQL 5.7 などにて変更点が公開されておりますが、なかなかこれらのドキュメントを読み込んで、自分たちのアプリケーションへの影響を調査することは簡単ではありません。
Insight Database Testing で行うような、普段実行されている SQL に対しての実行可否などを確認できる SQL テストは、バージョンアップに備える方法として一つの大きな選択肢になると考えます。
以下は、RDS for MySQL 5.6 では実行できていた SQL を RDS for MySQL 5.7 で実行してエラーとなった例となります。( ※今回はドキュメントで変更点として挙がっているものをあえて実行していますが。。。 )
予約語追加の確認例
以下は、予約語の追加の確認例です。先述のドキュメントにもあるよう、MySQL 5.7 ではいくつか予約語が追加されています。5.6 でカラム名に追加となる予約語を使用していた場合、SQL がエラーとなるケースがあります。
なお、Insight Database Testing では、エラーとなった SQL を修正して確認することもできます。予約語に対しては、’`’ で括ると正常に通ることを確認できます。
構文チェック強化の確認例
また、以下は、UNION と SELECT ～ LIMIT の記述の組み合わせがエラーとなる例です。ドキュメントにあるように、MySQL 5.7 では、個々の SELECT ～ LIMIT を、括弧で括る必要があります。
同様に修正してみると、以下のように構文としてはエラーとならないことを確認できます。
なお、修正を行う場合には、修正が意図したものになっているかを確認することを忘れてはなりません。MySQL 5.6 で括弧なしの SQL 文を実行したときと、カッコつきの SQL 文を実行したときとでは以下のように結果が異なります。
mysql> select * from emp limit 10
-> union all
-> select * from emp limit 10;
+-------+--------+-----------+------+------------+------+------+--------+
| empno | ename | job | mgr | hiredate | sal | comm | deptno |
+-------+--------+-----------+------+------------+------+------+--------+
| 7369 | SMITH | CLERK | 7902 | 1980-12-17 | 800 | NULL | 20 |
| 7499 | ALLEN | SALESMAN | 7698 | 1981-02-20 | 1600 | 300 | 30 |
| 7521 | WARD | SALESMAN | 7698 | 1981-02-22 | 1250 | 500 | 30 |
| 7566 | JONES | MANAGER | 7839 | 1981-04-02 | 2975 | NULL | 20 |
| 7654 | MARTIN | SALESMAN | 7698 | 1981-09-28 | 1250 | 1400 | 30 |
| 7698 | BLAKE | MANAGER | 7839 | 1981-05-01 | 2850 | NULL | 30 |
| 7782 | CLARK | MANAGER | 7839 | 1981-06-09 | 2450 | NULL | 10 |
| 7788 | SCOTT | ANALYST | 7566 | 1982-12-09 | 3000 | NULL | 20 |
| 7839 | KING | PRESIDENT | NULL | 1981-11-17 | 5000 | NULL | 10 |
| 7844 | TURNER | SALESMAN | 7698 | 1981-09-08 | 1500 | 0 | 30 |
+-------+--------+-----------+------+------------+------+------+--------+
10 rows in set (0.02 sec) mysql> (select * from emp limit 10)
-> union all
-> (select * from emp limit 10);
+-------+--------+-----------+------+------------+------+------+--------+
| empno | ename | job | mgr | hiredate | sal | comm | deptno |
+-------+--------+-----------+------+------------+------+------+--------+
| 7369 | SMITH | CLERK | 7902 | 1980-12-17 | 800 | NULL | 20 |
| 7499 | ALLEN | SALESMAN | 7698 | 1981-02-20 | 1600 | 300 | 30 |
| 7521 | WARD | SALESMAN | 7698 | 1981-02-22 | 1250 | 500 | 30 |
| 7566 | JONES | MANAGER | 7839 | 1981-04-02 | 2975 | NULL | 20 |
| 7654 | MARTIN | SALESMAN | 7698 | 1981-09-28 | 1250 | 1400 | 30 |
| 7698 | BLAKE | MANAGER | 7839 | 1981-05-01 | 2850 | NULL | 30 |
| 7782 | CLARK | MANAGER | 7839 | 1981-06-09 | 2450 | NULL | 10 |
| 7788 | SCOTT | ANALYST | 7566 | 1982-12-09 | 3000 | NULL | 20 |
| 7839 | KING | PRESIDENT | NULL | 1981-11-17 | 5000 | NULL | 10 |
| 7844 | TURNER | SALESMAN | 7698 | 1981-09-08 | 1500 | 0 | 30 |
| 7369 | SMITH | CLERK | 7902 | 1980-12-17 | 800 | NULL | 20 |
| 7499 | ALLEN | SALESMAN | 7698 | 1981-02-20 | 1600 | 300 | 30 |
| 7521 | WARD | SALESMAN | 7698 | 1981-02-22 | 1250 | 500 | 30 |
| 7566 | JONES | MANAGER | 7839 | 1981-04-02 | 2975 | NULL | 20 |
| 7654 | MARTIN | SALESMAN | 7698 | 1981-09-28 | 1250 | 1400 | 30 |
| 7698 | BLAKE | MANAGER | 7839 | 1981-05-01 | 2850 | NULL | 30 |
| 7782 | CLARK | MANAGER | 7839 | 1981-06-09 | 2450 | NULL | 10 |
| 7788 | SCOTT | ANALYST | 7566 | 1982-12-09 | 3000 | NULL | 20 |
| 7839 | KING | PRESIDENT | NULL | 1981-11-17 | 5000 | NULL | 10 |
| 7844 | TURNER | SALESMAN | 7698 | 1981-09-08 | 1500 | 0 | 30 |
+-------+--------+-----------+------+------------+------+------+--------+
20 rows in set (0.03 sec)求められる継続的なバージョンアップ対策
このようなバージョンアップに対する備えは、どのようなタイミングで行うとよいのでしょうか？
仮に全ての実行されている SQL を収集できたとしても、ソースコード上の全 SQL を網羅しているかどうかの保証はありません。が、通常実行されている SQL に対する確認としては十分ではないかと考えられます。また、どれくらいの期間の SQL を対象にすればよいか、についても、アプリケーションに依存する部分もありますが、3日間 ～ 1か月程度を対象にされているケースが多いようです。
継続的に確認しつづけることも可能です。バージョンアップの場合はエラーがほぼないケースが想定されますが、直前になって大量のエラーが発見されても準備不足になってしまう恐れもあるため、ある程度、定期的に確認を行うことも検討されてもよいかもしれません。
おわりに
本ブログでは Amazon RDS や Amazon Aurora の EOL に伴うバージョンアップ確認作業に、Insight Database Testing を使用する方法を紹介しました。
Amazon RDS や Amazon Aurora の利用が広がるに伴い、EOL に伴う強制バージョンアップのための対策として、Insight Database Testing をご利用・ご検討いただくケースが急激に増えてきました。
Insight Database Testing について詳しくお知りになりたい方は、以下ボタンからカタログのダウンロード、もしくはお問い合わせいただければと思います。
次回もどうぞお楽しみに！
|
Amazon RDS利用の普及に伴い、バージョンアップサイクルの短期化が課題になっています。Insight Database Testingは、RDSのバージョンアップに必要なSQLテストの工数を大幅に削減できます。詳細は以下のカタログをダウンロード下さい。 |
