https://tech.askul.co.jp/entry/2025/03/12/170000

こんにちは！アスクルの住石です。
今回は、OracleからPostgreSQLにデータを移行したので、そのお話をしようと思います！

なぜ移行することになったのか

現在、アスクルでは、中小事業所向けのECサイト「ASKUL」と中堅/大企業向けのECサイトの「SOLOEL ARENA」を統合しようというプロジェクトが動いています。
私もそのプロジェクトに従事しており、その中でも注文チームに属しています。

注文チームでは、主にカゴ画面から注文完了までの注文周りのAPI、バッチ、画面などの対応をしています。
そこにまつわるデータも注文チームで管理することになっています。

統合するにあたり、ASKULとSOLOEL ARENAで保持しているデータを新サイトに持ってくる必要が出てきました。
データ量が少ないチームであれば、SQLで取得し対応できるのですが、注文チームはデータ量が多く、単純にSQLで取得し移行するのが難しい状況でした。
また、データ量が多いだけではなく、さまざまな問題があってかなり苦戦したので、その経験を共有したいと思います！

移行するにあたっての課題

DB
旧サイトはOracle、新サイトはPostgreSQLであるため、DBが異なっている。
レコード量
全テーブル合わせると数十億件あるため、単純にSQLで取得し移行するのが難しい。
テーブル構成
新サイトは旧サイトと異なるため、そのまま移行することが難しい。
人員
旧サイトに詳しい人が常駐していない。
旧サイトの担当者は、旧サイトの運用があるため、移行プロジェクトに参加することが難しい状況でした。

違いが大きく、難易度が高いことがわかります！

旧サイトが運用されて10年以上経過しており、保守を行なっていく過程で負債も重なり、新規の開発をするにしても時間がかかる状況でした。
また、同じ機能を作成するにしてもASKULとSOLOEL ARENAでシステムが異なるため、同じECだが両システムで開発が必要であり、時間とコストを要していたという背景から統合プロジェクトが始まりました。
でも、移行する側としてはどうやって移行したらいいんだと思いながら始まった移行プロジェクトでした！

移行方法

移行概要上記で記載したとおり、旧サイトと新サイトではDBが異なっており、注文に関するレコードは数十億件程度あります。
データ量が少なければ、旧サイトから新サイトの形式に合わせてCSVなどで取得して新サイトでそのCSVを取り込むということもできると思いますが、データ量が多いため、その方法では対応できませんでした。
そこで、アプリケーション（※ 以下、移行ツール）を作成し、そのツールを使ってデータを移行することにしました。
移行ツールは、大きく分けるとEmbulkとKotlinで作成したアプリケーションに分けることができます。
Embulkを実行した後にアプリケーションを実行し、新サイトに旧サイトのデータを移行するという方針をとっています！

Embulk
Embulkは、Treasure Data社が開発したオープソースで、データベースやストレージから別のデータベースやストレージに転送するためのものです。
弊社では、旧サイトのOracleからPostgreSQLにデータを移行する際に使用しました。
PostgreSQLにworkテーブルとして、Oracleのテーブルと同じテーブルを用意し、Embulkを用いてデータを移行しました。

移行ツール
Emublkで移行してきたworkテーブルを用いて、新サイトの仕様に合わせたデータを修正し、新サイトから登録・更新されるテーブルにデータを移行しました。

移行した際に起こった問題

移行した際に生じたさまざまな問題について、具体的な事例をご紹介しながら移行を成功させるためのポイントだと感じた点を整理しました！

問題1 新サイトと仕様が異なることによる障害

発生した問題

弊社では、新サイトと旧サイトで仕様やデータ構造が異なるため、移行ツールで変換処理などを加えて移行していました。
その変換処理が新サイト側と認識が異なっていたり、旧サイトの仕様把握が足りておらず、障害が発生していました。
また、本来は両サイトの仕様に精通している人が移行を担当した方が良かったのですが、さまざまな事情もあり新旧のサイトの仕様に精通している人がいない状態で移行を進めた結果、トラブルが発生しました。

予防策

旧テーブルとデータ構造のまま移行することが難しいかを検討する
データ構造が同じか異なるかでは移行の難易度が大きく異なるため、移行する際にはデータ構造を維持することにより障害のリスクを大きく下げることが可能となります。
そのため、基本的には旧テーブルとデータ構造のまま移行できるかを検討することが望ましいです。
もし難しい場合は、大きなリスクがあることを周知し、十分なテスト、人員、期間を確保するなどの対策を取ることが重要となります！
新旧の仕様に詳しい人をアサインする
新旧のテーブルとデータ構造の仕様に詳しい人をアサインすることにより、障害のリスクを低減させることが可能となると考えています。
どちらの仕様にも精通している人は、組織的にもなかなかいない場合が多いです。
私たちの場合は、新サイトの仕様は把握しているが、旧サイトの仕様は把握していないという状況でした。
そのため、旧サイトを担当している人と仕様の不明点が出る度に壁打ちさせて頂いて対応しました。
根本的な対応としては、新旧のサイトに精通している人をアサインすることが重要だと思います。
もし、そのような人員の確保が難しい場合は、壁打ちできるような環境を整えるなどの対策を取ることが重要だと思います！
コミュニケーションを取る
移行する際、新旧の認識の違いというものは必ずといってもいいくらい発生します。
認識合わせの場を設けるなど、コミュニケーションの取り方を工夫することにより、障害のリスクを低減させることが可能となると考えています。

問題2 移行ツールのデータ取得時にタイムアウトが発生

発生した問題

移行ツールでworkテーブルからデータ取得時にタイムアウトとなる事象が発生しました。

原因と対応策

どれもよくある原因かとは思いますが、データ移行を行なっている企業が少なく、情報として世の中に出てきづらい部分でもあるので、私たちとしても考慮ができておりませんでした。
度重なるテストを経て、データ取得時にタイムアウトが起こっていた原因としては大きく分けると以下3点だということがわかりました！

データ量の把握不足
各テーブルのデータ量がどれくらいなのかを把握せずにselect文が作成されていたので、データ量が多くてタイムアウトになっているものが散見されました。
そのため、各テーブルがどれくらいのデータ量であるかを把握し、このselect文でどれくらいのデータが取得されるかを把握することが重要だと思いました！
また、データ量が多い場合は、limit句をつけるなどして、データ量を調整しながら処理を作成していくの重要だと思います。
workテーブルのインデックス設計の見落とし
workテーブルは、現行のテーブルを参考にし、作成したものです。
そのため、インデックスにおいても同様に現行のとおりに作成していました。
しかし、この場合のworkテーブルは、移行ツールから参照される一時テーブルなので、インデックスにおいては、移行ツールに従う必要がありました。
弊社同様に、多くのデータを移行する必要があり、一時テーブルを使用する場合は気をつけてもらえたらと思います。
本番同等環境でデータ取得時の実行計画を取っていない
今回のことを経て、事前に実行計画を取得するようにした結果、取得されるデータが多かったり、インデックスが貼られていないということを見つけることができるようになり、事前に対応できました。
その結果、取得されるデータが多かったり、インデックスが貼られていないということが発覚し、対応できました。 SQLに関しては、実行計画を取得することをお勧めします！

問題3 データ量の増加によるSQLの性能悪化

発生した問題

日々移行を重ねていく中で、データ量が多く、workテーブルからのデータ取得時のSQLの性能が悪化していきました。
そのため、対策として一生懸命インデックスのチューニングをしていた時期がありました。
しかし、データ量が多すぎるためインデックスが効かない場合やインデックスが効いていても性能が悪いという問題がありました。

解決策

データマートの作成を提案し対応しました。データマートとは、蓄積されたデータから目的に応じて必要なデータを抽出、集計し、利用しやすい形に加工し格納したデータベースのことです。
データ量が多いのは、日々の移行を重ねていく中でデータが増えたことによるものです。そして、過去データはすでに移行されたものであり、基本的には障害時の調査のために残しているだけでした。
そのため、データマートして、移行したいものだけのworkテーブルを作成することでこの問題を解決できるのではないかと考えて提案しました。
その結果、性能悪化問題も解決できたので、データマートの作成も検討してもいいかなと思いました！