大和総研が CRM システムを商用データベースから Amazon Aurora PostgreSQL に移行 (Part 2/3)

この連載の最初の記事「大和総研が CRM システムを商用データベースから Amazon Aurora PostgreSQL に移行 Part 1」では、大和証券様の CRM システムを商用データベースから Aurora PostgreSQL に移行した際の移行検討段階について、アセスメントや検証の内容などをご紹介しました。 このアセスメント結果を踏まえ、商用データベースから Aurora PostgreSQL への移行プロジェクトが開始されました。

移行プロジェクト開始

移行プロジェクトは、2020 年 4 月に開始され、2022 年 10 月にリリースされました。

移行作業では AWS Schema Conversion Tool（以下SCT）を使用してDDL 文を Aurora PostgreSQL に変換しました。アプリケーションについては、MyBatis 形式のソースコードが SCT に対応していなかったため（現在は対応済）、手作業での SQL の書き換え作業を実施しました。移行を担当した大和総研様では、商用データベースについての経験は豊富でしたが、PostgreSQL についての経験が少なく、データベースエンジンの移行に対するノウハウも不足していましたが、PostgreSQL が商用データベースに近いアーキテクチャーであった為、商用データベースの知識やノウハウをベースに移行開発を進めることができました。また、AWS のプロフェッショナルサービスによるバックエンドの移行支援もありました。プロジェクトとしては順調に進んでいましたが、データベースの移行に伴ういくつかの課題も発生しました。

課題１：パフォーマンス

PostgreSQL に書き換えた SQL の一部で、パフォーマンスが低下する事象が発生しました。遅延した原因を調査した結果、2 つの事象が発生していました。

1. 実行計画の差異

事象：当該システムで作成された SQL はサブクエリを多用しており、ネストが深いサブクエリもあるなど複雑な構造の SQL がありました。このような SQL に対して、商用データベースでは実行計画をコントロールするためにサブクエリ内でのヒント句を使用するなど、パフォーマンスチューニングが施されていました。

一方、PostgreSQL に変換した SQL の中には、PostgreSQL 用に最適化が必要な SQL もありました。特にサブクエリに指定されていたヒント句は PostgreSQL ではクエリ全体に適用されてしまう仕様であったため、対処が必要な状況でした。

対処：基本的には、pg_hint_planという拡張オプションを採用して実行計画をコントロールすることで対処しました。サブクエリに指定されていたヒント句については、テーブル構成の変更やSQL自体を一部書き換えるなど、PostgreSQL に最適なパフォーマンスが得られるよう試行錯誤を繰り返しながら、SQL のチューニングを実施しました。

2. 不要な読み込みの改善

事象：SQL の変換やチューニングを実施する中で、商用データベースで実行されていたSQLに改善の余地があることがわかりました。具体的には、商用データベースではデータ取得用の SELECT 文とデータ件数を取得する SQL を2 回実行していて、1 回あたりの処理時間やデータベースの負荷が高い状況でした。

対処：PostgreSQL の SELECT に変換する際に、OVER 句を使用したウィンドウ関数を使用することでデータ取得と件数を1 回で実行できるよう変更しました。

このようなチューニングを実施した結果、パフォーマンスについては商用データベースの時と同程度の状態に改善されました。

課題２：エラー時の結果差異

アプリケーションの異常系テスト中に、エラー発生時の結果に差異が生じました。商用データベースの場合、トランザクションを rollback する際、トランザクションの一部のみが rollback されますが、PostgreSQL の場合、すべてが rollback されるという仕様の違いがあります。例えば、以下のようにトランザクション内で INSERT 処理が一意制約違反でエラーになった場合、商用データベースではエラーのみが例外処理されますが、PostgreSQL の場合はトランザクション内で実行されたすべての INSERT 文が rollback されます。

この仕様差異により、異常時の結果が商用データベースと PostgreSQL で異なる状態になっていました。この問題に対しては、エラー後のリトライ処理でトランザクション内の全ての更新処理が rollback されることを前提にアプリケーションを修正することで対処しました。

このように、発生した課題を一つずつ解決していくことで、移行プロジェクトは無事カットオーバーを迎えることができました。

Part 3 に続く。