こんにちは！ 株式会社インサイトテクノロジーの松尾です。先日、札幌で開催された勉強会「札幌IT 石狩鍋 #3」で、Amazon RDS や Aurora のバージョンアップとそれに伴う SQL の非互換性についてお話しさせていただきました。その講演内容を、より深く掘り下げた形でブログ記事にしてみました。勉強会のリンクと当日使った資料はこちらです！
ちょうど、Amazon RDS for MySQL 8.0 の標準サポート終了も来年に予定されていますので、メジャーバージョンアップの検討の参考になれば幸いです。
Amazon RDS / Amazon Aurora って使ってますか？
まずは、今回お話しするテーマの主役である Amazon RDS と Amazon Aurora について、改めてその特徴を整理しておきましょう。
Amazon RDS (Relational Database Service)
PostgreSQL、MySQL、MariaDB、SQL Server、Oracle、Db2 といった、様々なリレーショナルデータベースエンジンをクラウド上で簡単に利用できるフルマネージドサービスです。これにより、OS や DB のパッチ適用、バックアップ、フェイルオーバーといった、面倒で時間のかかる管理タスクから解放されます。まさに、「データベースをサービスとして使う」という新しい体験を提供してくれます。
Amazon Aurora
Amazon RDS のエンジンの一つでありながら、AWS が独自に開発した、いわば「AWS ネイティブ」なデータベースエンジンです。MySQL 互換と PostgreSQL 互換の2種類があり、MySQL や PostgreSQL の利点を活かしつつ、さらに高いパフォーマンスと可用性を、商用データベースに匹敵するレベルで提供します。コスト効率の高さも魅力の一つです。
マネージドデータベースのメリデメ、あなたは本当に理解してる？
マネージドデータベースは非常に便利ですが、その恩恵を受ける一方で、いくつかの注意点も存在します。メリットとデメリットをしっかりと理解しておくことが、スムーズな運用には欠かせません。
-
メリット:
- 管理の簡素化: OS や DB の管理、バックアップ、パッチ適用などを AWS に任せられるため、エンジニアはアプリケーション開発など、より価値の高い業務に集中できます。
- 簡単な構築・削除: 数クリックでデータベースを構築でき、不要になったらすぐに削除できます。検証環境の構築なども非常に手軽です。
- 高い可用性・耐久性: マルチ AZ 構成やリードレプリカの利用など、AWS が提供する強固なインフラ上で高い可用性を確保できます。
-
デメリット:
- EC2 より高コストになりがち: マネージドならではの便利な機能やサービスレベルの対価として、EC2 上で自分でデータベースを構築・運用するよりもコストが高くなる傾向にあります。AWS にかかる費用だけではなく、運用にかかる費用なども含めてトータルで考える必要はあるでしょう。
- サポート切れの DB は利用できない: コミュニティサポートが終了したデータベースバージョンは利用できません。これが今回の本題にも繋がる重要なポイントです。
サポートが切れるとどうなるの？ 延長サポートの現実
マネージドデータベースは、常に最新のセキュリティパッチや機能が提供されるように、新しいバージョンへのアップグレードが推奨されます。また、仮にバージョンを上げずに LTS などを使用し続けていても、バージョンには必ずサポート期間の終了が訪れます。Amazon RDS には、以下の2つのサポート終了のタイミングがあります。
- 標準サポート終了: MySQL の場合、コミュニティサポートの終了とほぼ同じタイミングで迎えます。この時点で、AWS による標準的なサポートが終了します。
- 延長サポート終了: 標準サポート終了後も、AWS 側で追加料金を支払うことで、最長3年間はサポートを継続してくれます。ただし、この延長サポートは決して安価ではありません。
例えば、東京リージョンでは 1 VCPU あたり 0.12 USD / 時間です。これを db.m5.2xlarge（8 VCPU）で計算すると、1か月で約10万円程度の費用が発生する計算になります。
サポートが切れそうなデータベースを使っていると、以下のようなレコメンデーションが AWS から届きます。
お使いの Aurora MySQL 2.x データベースは、2024年10月31日に RDS 延長サポートに自動的に登録されます。RDS 延長サポートによる料金の増加を避けるため、2024年10月31日までにデータベースを新しいメジャーエンジンバージョンにアップグレードすることをお勧めします。
これは、費用がかさむ前に、新しいバージョンへのアップグレードを強く推奨する AWS からのメッセージです。延長サポートはあくまで一時的な猶予期間であり、いつかは必ずバージョンアップが必要になるのです。
直近の MySQL メジャーバージョンサポート終了タイミング
直近のメジャーバージョンの終了のタイミングは、MySQL の場合以下のようになります。昨年は Aurora MySQL 2 (MySQL 5.7 互換) の標準サポート終了があり、多くの方がバージョンアップの必要性に迫られたと思いますが、RDS for MySQL 8.0 の標準サポート終了までも 1 年を切っています。
なお、今のところ(ブログ公開時点)では
- Aurora MySQL の MySQL 8.4 互換バージョンについては発表されていません。
- Aurora MySQL については延長サポートの 3 年目価格(延長サポート費用が倍になる)の開始タイミングは設定されていません。
サポート終了日や延長サポートの情報は随時アップデートされていますので正確には公式ドキュメント(できれば英語版)を参照ください。
| 標準サポート終了日 | 延長サポートの終了日 | |
|---|---|---|
| RDS for MySQL 5.7 | 2024 年 2 月 29 日 (すでに終了) | 2027 年 2 月 28 日 |
| RDS for MySQL 8.0 | 2026 年 7 月 6 日 (1年を切りました) | 2029 年 7 月 31 日 |
| RDS for MySQL 8.4 | 2029 年 7 月 31 日 | 2032 年 7 月 31 日 |
| 標準サポート終了日 | 延長サポートの終了日 | |
|---|---|---|
| Aurora MySQL 2 (MySQL 5.7互換) | 2024 年 10 月 31 日 (すでに終了) | 2027 年 2 月 28 日 |
| Aurora MySQL 3 (MySQL 8.0互換) | 2028 年 4 月 30 日 | 2029 年 7 月 31 日 |
じゃあ、バージョンアップすればいいじゃない？ それが簡単じゃないんです！
マネージド DB の最大の恩恵は、運用管理の簡素化にありますが、メジャーバージョンアップだけは、そう簡単にはいきません。
弊社が 2023 年に実施したアンケート調査では、バージョンアップに伴う影響が不明という課題を多く抱えていることが明らかになっています。
バージョンアップで何が起こるの？ 予想外の非互換
メジャーバージョンアップは、単なる機能追加やバグ修正だけではありません。
- SQL の仕様変更: 構文チェックが厳しくなったり、以前は使えていた関数が非推奨になったりします。
- SQL 実行結果の変化: データ型の扱いが厳密になったり、演算子の挙動が変わったりすることで、意図しない結果になることがあります。
- 関数の仕様変更: 新しいバージョンでは関数内のエラーチェックがより厳密になったり、戻り値の型が変わったりすることがあります。
- 性能の変化: オプティマイザの改良は性能向上をもたらしますが、一方で特定のクエリの実行計画が変わってしまい、かえって性能が悪化する可能性もあります。
MySQL 5.7 から MySQL 8.0 の非互換例
いくつか具体的な非互換の例を見てみましょう。MySQL 5.7 から MySQL 8.0 へのメジャーバージョンアップで実際に発生しうる問題です。
| 実行 SQL | 備考 |
|---|---|
select * from emp e where hiredate >= '1981-05’; |
8.0.16 のバグ修正により、この形式のクエリは実行できなくなりました。クエリの修正が必要です。 |
select d.loc, count(*) from emp e inner join dept d on e.deptno = d.deptno group by d.loc; |
GROUP BY 句の暗黙的なソートが保証されなくなったことで、実行結果の順序が変わる可能性があります。アプリケーションがこの順序に依存している場合、バグに繋がります。 |
select first_value, last_value from testtable; |
MySQL 8.0 で first_value と last_value が予約語に追加されました。そのため、これらの単語を識別子として使用している場合、クエリがエラーになります。 |
エラーになるならまだ発見しやすい、とも言えますが、エラーにならずに結果が変わってしまうような SQL の非互換はなかなか問題を見つけるのが難しいですよね。
MySQL 8.0 から MySQL 8.4 の非互換例
さらに、MySQL 8.0 から 8.4 へのバージョンアップでも、予約語の追加などによるエラーが発生するケースは十分に考えられます。例えば以下の SQL はエラーになります。
| 実行 SQL | 備考 |
|---|---|
create temporary TABLE table3 (PARALLEL int) |
MySQL 8.4 で PARALLEL が予約語となりました。 |
create table tablesample (id int); |
MySQL 8.4 で TABLESAMPLE が予約語となりました。 |
select empno as parallel from emp; |
MySQL 8.4 で PARALLEL が予約語となりました。 |
create temporary TABLE $$tmp_table7 (id int); |
MySQL 8.4 で $ を識別子の先頭に使うことができなくなりました。 |
結論：DB メジャーバージョンアップには、計画的な対応と徹底的なテストが必須！
ご覧いただいたように、メジャーバージョンアップは決して簡単ではありません。対応とテストには、一般的に以下の手順が必要となり、多くの時間と労力を要します。
- 非互換情報の調査: 公式ドキュメントや移行ガイドを読み込み、変更箇所を特定します。
- 影響範囲の特定: アプリケーションのソースコードから、影響を受ける可能性のある SQL を洗い出します。
- テスト環境の構築: 新しいバージョンのデータベースを構築し、本番環境のデータをコピーしてテスト環境を準備します。
- テストシナリオの実行: 影響を受ける SQL を含むテストシナリオを作成し、実際に実行して動作を確認します。
この作業をすべて手作業で行うのは、非常に骨が折れる作業です。
バージョンアップの悩みを解決する自動テストツール、Insight SQL Testing
こうした DB バージョンアップに伴うテスト作業を効率化するために、弊社では「Insight SQL Testing」というツールを開発しています。
このツールは、
- 現行環境でアプリケーションから発行された SQL を自動的に取り込みます。
- 取り込んだ SQL を、バージョンアップ後のテスト環境で自動的に実行します。
- テスト結果を自動で評価し、非互換性によるエラーや性能劣化を検知します。
- さらに、Amazon Bedrock を活用して、エラーが発生した SQL に対する修正提案まで自動で行うことができます。
Amazon RDS や Aurora を利用している限り、バージョンアップは「いつか必ず直面する課題」です。その時に慌てないためにも、事前の準備が重要になります。もしバージョンアップでお困りでしたら、ぜひお気軽に弊社にご相談ください！
まとめ
最後に、今回のポイントを改めてまとめます。
- マネージド DB は便利ですが、DB のバージョンアップを管理できないことがあるので、サポート期間を意識して計画的に利用しましょう。
- DB のメジャーバージョンアップは、単なる機能追加だけでなく、SQL の非互換性や性能劣化を引き起こす可能性があります。
- バージョンアップの際には、影響を十分に確認し、入念なテストを実施することが非常に重要です。
この記事が、皆さんの DB 運用の一助になれば幸いです。