こんにちは！インサイトテクノロジーの松尾です。
AWS 上でデータベースを運用されている皆さま、Amazon Aurora PostgreSQL の バージョンアップ計画 は順調に進んでいますでしょうか？ AWS のマネージドサービスとはいえ、メジャーバージョンアップへの対応 は、システムの安定稼働を維持するために計画的に行う必要があります。
特に Aurora PostgreSQL 13 は、まもなく標準サポート終了日が迫っていて、早急な対応が求められています。本記事では、このアップグレードに際して、PostgreSQL のバージョンアップ で共通して注意すべき SQL の非互換性 の具体例と、その課題を解決する 「持続可能な体制」 について解説します。
Aurora PostgreSQL 13、標準サポート終了は「2026年2月28日」
まず、最も重要なスケジュールを確認しましょう。AWS 公式ドキュメントに基づき、Aurora PostgreSQL の バージョンごとの標準サポート終了のスケジュール を以下にまとめました。
| バージョン | 標準サポート終了日 | 延長サポートの終了日 |
|---|---|---|
| Aurora PostgreSQL 11 | 2024年2月29日 (既に終了) | 2027年3月31日 |
| Aurora PostgreSQL 12 | 2025年2月28日 (既に終了) | 2028年2月29日 |
| Aurora PostgreSQL 13 | 2026年2月28日 | 2029年2月28日 |
| Aurora PostgreSQL 14 | 2027年2月28日 | 2030年2月28日 |
| Aurora PostgreSQL 15 | 2028年2月29日 | 2031年2月28日 |
| Aurora PostgreSQL 16 | 2029年2月28日 | 2032年2月29日 |
すでに Aurora PostgreSQL 11 と 12 は標準サポートが終了しています。バージョン 13 をご利用中の場合、標準サポート終了まで残りわずかです。延長サポートの利用には追加の料金が発生しますし、延長サポートも 3 年という期限があります。できるだけ標準サポート期間内に新しいメジャーバージョンへ移行していくことが重要です。新しいバージョンに移行することで新しい機能も使えますし、余計な費用の発生も避けることができます。
PostgreSQL バージョンアップで直面する課題と非互換の具体例
データベースのバージョンアップで最も神経を使うのは、やはり サービスやアプリケーションへの影響、特に SQL の互換性 の確認です。同じデータベースエンジンだからそんなに差異はないだろうと思いつつも、やはり確認しないわけにはいきません。
SQL の非互換性による実行エラー・結果の差異
データベースのメジャーバージョンアップでは、データベースの仕様変更により、既存の SQL が予期せぬ挙動を示すことがあります。
- 構文チェックの厳格化 や 予約語の追加。
- 演算や関数の仕様変更 による SQL 実行結果の変化。
- 性能の変化（オプティマイザの仕様変更）。
PostgreSQL 13 → 16 で発生する非互換の具体例
Aurora PostgreSQL 13 からのバージョンアップを考える場合、現行の LTS から最新の LTS に乗り換えるというパターンが多いかもしれません。Aurora PostgreSQL 13 の LTS は 13.9 で、現在の最新の LTS は 16.8 です。
そのため、ここでは、Aurora PostgreSQL 13.9 から 16.8 へといったアップグレード（PostgreSQL 14, 15, 16 の変更を含む）で発生しうる SQL 非互換の具体例を紹介します。
プログ執筆時点では公式ドキュメントの日本語版では 15.10 が最新の LTS と記載されていましたが、英語版には 16.9 が追加されていました。
| 実行 SQL の例 (v13 で実行可) | バージョンアップ後での挙動 | 理由 |
|---|---|---|
SELECT 123abc; |
エラー となる | 数値リテラルの後に続く非数値文字が禁止 されました。(PostgreSQL 15) |
prepare p1(int,int,int) as update t1 set a = $1, b = $2where a = $3; |
エラー となる | 数値リテラルの後に続く非数値文字が禁止 されました。(PostgreSQL 15) |
select extract (minute FROM '2021-10-05'::date) |
エラー となる |
EXTRACT(date) が date 型に含まれない部分を要求したとき エラー となるようになりました。(PostgreSQL 14) |
SELECT array_to_tsvector(ARRAY['']) |
エラー となる |
array_to_tsvector() に空文字列の配列要素が渡された場合に エラー となるようになりました。(PostgreSQL 15) |
特に「数値リテラルの後に続く非数値文字が禁止」の影響は大きく、これまで(おそらく意図せずに)スペースなしでも動作していたものがエラーになってしまうようなケースもあり得ますので、要注意ですね。
膨大なテスト工数と網羅性の課題
一般的な確認手順では、非互換情報をドキュメントなどで確認し、アプリのソースコードを修正、テストシナリオに従って動作確認を行います。しかし、このプロセスには 膨大な確認作業やテスト工数 がかかり、本番で発行され得る SQL をどれだけ網羅できているか という課題が常に付きまといます。重要なシステムで問題が発生してしまうことへのインパクトは言うまでもないでしょう。
Insight SQL Testing で実現する「持続可能なバージョンアップ体制」
メジャーバージョンアップは数年ごとに必ず発生するイベントです。都度、膨大な工数をかけて手動テストを行う属人的・短期的な対応ではなく、バージョンアップを 持続可能 にするための体制を確立することが重要です。
バージョンアップを持続可能にするためのポイントとして、以下の点が挙げられます。
- 計画的なアップグレードサイクル の確立。
- 継続的な非互換性の早期検出（シフトレフト）。
- 手順の自動化と標準化。
これらの実現に役立ち、特に「SQL の非互換性テスト工数や網羅性の課題」を解決するのが、SQL テスト自動化ツール「Insight SQL Testing」 です。
Insight SQL Testing が実現すること
「Insight SQL Testing」は、本番環境で実際に発行される SQL を自動収集し、それをテストケースとして利用して、新バージョン DB での実行互換性（構文チェック、実行結果、実行速度）をテスト します。
このツールは、以下の機能により、バージョンアップ時の SQL 互換性テストを大幅に省力化します。
- テストケースの自動生成: 本番環境でアプリケーションが発行する SQL を自動収集 し、そのままテストケースとします。
- 新バージョン DB でのテスト自動実行: 収集した SQL を新バージョン DB（テスト環境）に対して実行し、構文チェック実行可否、実行結果、実行速度 を比較・検証します。
- テスト結果の評価: 互換性の差異を可視化し、テスト工数や修正工数を大幅に削減します。
Insight SQL Testing を活用することで、人手では非現実的だった 網羅的な SQL の検証 を現実的な時間で実施できるようになり、安心してメジャーバージョンアップを迎え撃つことができるでしょう。
画面イメージ（非互換検出）
実際、Insight SQL Testing を使ってエラー検出を行うと、以下のような形で検出されます。
また、このエラーに対して Bedrock を使ってエラー原因や SQL の修正案も確認することも可能です。
そのほか、Insight SQL Testing では、SELECT 結果が異なることの検出や、実行計画の確認なども画面上から行うことが可能です。
まとめ
最後に、今回のポイントを改めてまとめます。
-
バージョンアップを持続可能にするためには計画と自動化/省力化が重要 です。
- Amazon RDS や Aurora を利用している限り、バージョンアップは「いつか必ず直面する課題」です。その時に慌てないためにも、事前の準備が重要になります。
-
DB のメジャーバージョンアップは、SQL の非互換性や性能劣化を引き起こす可能性があります。
- バージョンアップの際には、影響を十分に確認し、入念なテストを実施することが非常に重要です。
Insight SQL Testing のような SQL テスト自動化ツールの活用も是非ご検討ください。
ご興味をお持ちの方は、ぜひお気軽に弊社にご相談ください！
この記事が、皆さんの DB 運用の一助になれば幸いです。