こんにちは！テクノロジー本部基盤開発ユニット改善推進グループ所属の王です。
基盤開発ユニットは常にLIFULLの各種サービスが依存する基盤システムの構築と改善のために、いろいろな取り組みをしています。
今回は技術負債の解消の一つである、DB移行プロジェクトの詳細について紹介します。
DB移行プロジェクトとは？
現在LIFULL HOME'Sの各種サービスが依存している中心的なデータベースをOracle DatabaseからPostgreSQLに置き換えることを推進しているプロジェクトです。
背景の詳細は省略しますが、現状のDB運用体制を続けると会社の事業発展のボトルネックとなることが予想されているので、運用コストの削減、開発効率およびパフォーマンス改善の面から移行の必要が出てきています。
プロジェクトの概要
次はこのプロジェクトの進め方について、我々が取り組んでいることの紹介をさせていただきます。
DB移行手順
今回のプロジェクトの目的、アプリケーションが使っているDBをOracle DatabaseからPostgreSQLに変更するには、以下移行手順の元で進めています。
スキーマオブジェクトとアプリケーションの依存関係の洗い出し
Oracle Databaseに依存するアプリケーションからSQL文を抽出して分析する、アプリケーションとデータベースのスキーマオブジェクトの対応関係を以下のようにまとめます。
Application SQL Schema Object SQL Type app1 sql1 table1 select app1 sql1 table2 select app1 sql2 table1 insert 以上の調査により、各アプリケーションがOracle Databaseの使用状況を明確にして、アプリケーションDB移行に必要な修正および移行の優先順位を決めます。
ソースデータベースとターゲットデータベースのデータ同期を確保する
アプリケーションへの影響を最小限にするために、ソースデータベース（移行元）とターゲットデータベース（移行先）のデータの一致性を確保することが必要です。テーブルの移行を例として考えると、以下の条件を満足する必要があります。
テーブル構造の一致性
テーブルの定義がソース・ターゲットデータベースで正しく対応する必要があります。たとえば、カラム名、カラムのデータ型、インデックス、制約などのものはできるだけソースデータベースの仕様を再現することによりアプリケーションへの影響を最小化します。
テーブルデータの一致性
対応するテーブルが常に同じデータを持っていることを確保すること。
テーブルに対するトランザクションの一致性
ソースデータベースでテーブルへのデータ更新が、できるだけ遅延少なくターゲットデータベースの対応するテーブルに反映されること。
以上のデータベースのデータ同期を確保した上で、移行作業を始めます。
参照系SQLを先に移行する
まずは各アプリケーションからOracle Databaseを参照するSQL文（SELECT文）の参照先をPostgreSQLに変更します。
後述するしくみによってソース・ターゲットデータベースのデータは同期されるため、許容できる範囲のタイムラグはありますがデータの不整合は発生しません。
参照系の後に更新系SQLを移行する
参照系のSQLをすべて移行した後に、更新系SQL文（UPDATE、INSERT、DELETE…）の参照先のDBを少しずつターゲットデータベースに変更します。
全体図
移行手順の全体図は以下の通りです
DB移行に採用する技術
移行の全体図を一見するとそこまで複雑ではないと思う方がいると思います。ですが、Oralce Databaseを参照するアプリケーション数および参照するデータベーススキーマオブジェクト数が多いため、各アプリケーションとスキーマオブジェクトの依存関係が複雑になります。ゆえに、システム全体のDB移行の難易度が上がっています。
移行に必要な工数を削減するために、AWSから提供されている以下のツールを利用しています。
SCT (Schema Conversion Tool)
AWS Schema Conversion Tool は、ソースデータベーススキーマ、およびビュー、ストアドプロシージャ、関数といったデータベスコードオブジェクトの大部分を自動的にターゲットデータベース互換フォーマットへと変換することにより、異種データベース間の移行を計画的なものにします。
上記AWS SCT の公式ドキュメントの紹介の通り、異種データベース関のスキーマオブジェクト変換に使用されています。現在はこのサポートツールを利用して、Oracle Databaseのスキーマオブジェクトを正しい型でPostgreSQLに移行しています。LIFULLではデータベース内に複雑なDDLを持っているスキーマオブジェクトが比較的多いので、この自動変換ツールはプロジェクトを進める上で欠かせません。
下記はSCTの使用画面です。
GUIでソースデータベースのスキーマオブジェクトを指定すると、ターゲットデータベースに通用するDDLが自動出力されます。
AWS DMS (AWS Database Migration Service)
AWS Data Migration Service(AWS DMS)はAWSが提供するDB間のデータ移行をサポートするサービスです。サービスの処理プロセスは以下の図のように示されています。
DMSプロセス 図が示すように、DMSはデータレプリケーション機能を持つAWSクラウドサービスです。ソース・ターゲットデータベースを指定すると、2つのデータベース間のデータ同期が実現できます。
詳しい説明はAWS DMSの公式ドキュメントを参照してください
我々のDB移行プロジェクトでは、ソースデータベースとデータベースのデータ同期を実現するために、DMSを使用しています。ソース・ターゲットデータベースのデータ同期はアプリケーションの参照DBを切り替えるために必要なことですので、DMSは我々のDB移行プロジェクト内で重要な役割を果たしています。
以上2つの外部サービスを利用してDB移行の推進をしています。AWSが提供するハンズオンを見ていただければより詳細を理解できるので、興味がある方は参照してください。
プロジェクトの体制
プロジェクトの体制についても少し紹介させていただきます。
DB移行プロジェクトは私が所属する基盤開発ユニット改善推進グループと基盤運用ユニット基盤グループが共同作業しています。
改善推進グループは主に必要なアプリケーションの改修に注力していてます。そして基盤グループはDB移行に使用される本番環境インフラ(DBおよびAWS DMSの関連リソース)の運用、検証および改善に注力しています。
そのほか、アプリケーションの改修には各アプリケーションの主管部署の協力も不可欠ですので、全社に渡り影響範囲が大きいプロジェクトとも言えます。
プロジェクトが完了するまでの課題
DB移行プロジェクトはLIFULLの技術負債を解消する重要な施策の一つであり、目的を達成するために我々は日々取り組んでいます。しかし、プロジェクトの完了までにまだ解決しないといけない課題がいくつもあります。
安定的なデータ同期のためにDMSのチューニングが必要
プロジェクトを進める上で、処理するデータ量が増えると同時にデータ同期の遅延が大きくなることまたはデータ同期の一時的な停止などの予想外の問題が発生しました。安定的なデータ同期を確保するため、AWSからのサポートしていただきながらインスタンスのサイジングやパラメータの調整、設定変更などDMS側のチューニング施策に取り組んでいます。
データ同期によるデータベースへの負荷が上昇する
DMSへの負荷だけではなく、データ同期によるデータベースへの負荷が上昇することも無視できません。ソース・ターゲットデータベースを正常稼働させながらプロジェクトを進めるための施策も今いくつか進めています。
SQLの調査が不十分
移行が必要なSQL文への調査がまだまだ不十分で、移行の抜け漏れがアプリケーションの障害を起こす可能性があります。ですので、抜け漏れ検知のためのデータベースへのアクセス監視の強化などの施策を今取り組んでいます。
上記の課題はLIFULLのDB移行プロジェクトにとって大きなリスクであり、解決するためにプロジェクトメンバーが日々取り組んでいます。
以上DB移行プロジェクトの紹介となります、ここまで読んでいただきありがとうございます。参考になれば幸いです。
まだまだプロジェクトの完了は先が長いですが、LIFULLの技術負債をなくすには必要不可欠の一歩ですから、これから頑張って取り組んでいきたいと思います。今後プロジェクトの進捗が何かありましたら、また記事を出させていただきます。
