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

大和総研は、長年培ってきたIT分野における多くの実績とノウハウを基盤として、証券会社、銀行等の金融機関に加え、事業会社、官庁および地方自治体、健康保険組合といった公共団体等の幅広いお客様に向けて、戦略的かつ効率的な業務改革に資するコンサルティング、ならびに安全性の高い情報システムサービスを展開している AWS のパートナーです。大和総研では、大和証券の顧客情報管理システム（以下「CRM システム」）を 2022 年に全面更改しました。この更改のタイミングで、データベースエンジンを商用データベースから Aurora PostgreSQL に移行しています。本ブログでは、商用データベースから Amazon Aurora PostgreSQL に移行した時の検討から移行作業の詳細、移行したことで得られた効果や、そのときに直面した課題とその解決方法について、お客様の現場の声を交えてご紹介します。

CRM システム概要

今回移行を実現した CRM システムは、2 ノードで構築された商用データベースが 2 セットあり、1 ノードあたり 7CPU で 2 ノード合計 14CPU のサーバー上に構築されていました。500 を超えるデータベースのオブジェクトがあり、そのうち約半分がテーブルで、プロシージャなどの PL/SQL の使用はなく、アプリケーション側に数千以上の SQL がありました。

移行前システムにおける課題

この CRM システムは初期構築から 10 年以上が経過して、サーバー側ソフトウェアのサポートの問題が発生しており、これに伴うシステムの全面更改が必要な状況でした。また、10 年という期間の中でシステムに求められる要件もかわり、BCP 環境の構築など新しい要件への対応も必要でした。そして、最も重要な課題が商用データベースに関するもので、ライセンス費や保守費はシステム運用における大きな課題となっていました。

移行先の検討

このような現行システムの課題を踏まえ、システムの移行検討がスタートしました。システムの移行先は、AWS が第一候補として検討されました。大和総研では、増大するクラウド案件の増加に対応するため、2021 年に CCoE（Cloud Center of Excellence）を設置し、2023 年 7 月には AWS の認定資格取得数が 1,000 を超えて「AWS 1000 APN Certification Distinction」にも認定されるなど人材の育成も進めていました。また、会社の方針としてシステム更改時の移行先はパブリッククラウドファーストが原則とされており、このような背景から今回の CRM システム更改でも AWS が第一候補となりました。ここで課題になったのは、商用データベースの移行です。AWS へそのまま移行した場合、移行に伴うライセンス費や保守費が増加しコストがかさむことも判明しました。また、スケーリングの柔軟性も重要な要素でした。AWS の RDS や Aurora は、ユーザー数や機能の増減に合わせた柔軟なスケーリングが可能で、クラウド移行によるメリットの一つであり、システムの要求を満たすのに十分なレベルでした。一方、商用データベースのまま AWS に移行した場合、スケールアップやスケールアウトするためには追加ライセンスが必要で、タイムリーな対応が難しく、コスト面でも問題が生じます。このような背景から今回の CRM 更改プロジェクトにおいては、商用データベースからの移行を本格的に検討することになりました。

移行先決定に向けたアセスメント

データベースエンジンの変更については、AWS が提供している Database Freedom Workshop を利用しました。Database Freedom Workshop はデータベースエンジンの移行を検討しているお客様に AWS の Database Specialist が無償で提供するワークショップで、データベースエンジンの移行に対するアセスメントや商用データベースのパフォーマンス分析によるサイジングなどを実施するワークショップです。大和総研では、データベースエンジンの移行に対するアセスメントとパフォーマンス分析を行いました。

データベースエンジンの移行に対するアセスメントは、AWS が提供する無償ツールであります AWS Schema Conversion Tool（SCT）を使いました。その結果、対象のシステムでは Aurora PostgreSQL への移行難易度が低く、オブジェクトの 98% が最小限の変更で移行が容易であることがわかりました。

このアセスメント結果を踏まえ、机上検証と実機検証を実施しました。

机上検証

机上検証では、可用性、拡張性、性能、運用保守性、セキュリティの技術的な項目とコストについて調査を実施しました。移行対象としては、オンプレミスの商用データベースに対して商用の PostgreSQL と Aurora PostgreSQL を比較検証しました。

机上検証の結果、コストや可用性の観点から Aurora PostgreSQL が最適であるという結論に至りました。

実機検証

実機検証では、SCT で変換された PostgreSQL のオブジェクトを使用して動作検証を実施しました。動作検証では SCT で移行したオブジェクトを使用してアプリケーションで実行されるような SQL を Aurora PostgreSQL で実行し、その挙動や性能などを確認しました。検証の結果、移行前と移行後で基本的な動作や性能で大きな差異がないことを確認することができました。ただし、一点、パーティションについて課題があることがわかりました。移行前のデータベースではパーティションを跨ったインデックスを使用していましたが、Aurora PostgreSQL には同等の機能がなく、複数のパーティションを検索する場合パフォーマンスが数十秒程度劣化することがわかりました。

もう一つの観点として、アプリケーションの移行性についても検証しました。本システムでは、フレームワークとして MyBatis を採用しており、SQL が XML ファイルに定義されています。このSQLは条件によって動的に組み替えて実行する仕組みであった為、SCTを使っての変換が難しく、変換方法の検討が必要な状況でした（現在は対応済み）。

実機検証での課題に対する解決案

課題となっていたパーティションの遅延について、改善案を検討しました。その結果、今回のシステムではパーティションと通常テーブルの 2 つを用意して、参照処理を実行する際に効率の良いテーブルを参照するように変更することにしました。該当テーブルへの更新は、すべての更新処理で両方のテーブルに更新するよう変更することで、移行前と同等のパフォーマンスで動作することを確認することができました。

アプリケーションの移行性については、XML ファイルにある SQL を実行できる形で整形して、SCT で変換することで、SQL 自体の変換工数を効率化することが可能であることが確認されました。

これらの机上検証と実機検証により商用データベースを移行することによるリスクは低く、コストメリットがあると判断され、Aurora PostgreSQL へのデータベース移行が決定されました。

Part 2 に続く。