アスクル株式会社におけるEmbulkを使用したOracleからPostgreSQLへのDB移行

現在、アスクルでは、中小事業所向けのECサイト「ASKUL」と中堅・大企業向けのECサイト「SOLOEL ARENA」を統合するプロジェクトが進行しています！
私もそのプロジェクトに従事しており、注文チームに所属しています。
注文チームでは、主にカゴ画面から注文完了までの注文関連のAPI、バッチ処理、画面などの対応を行っています。また、それらに関連するデータも注文チームで管理しています。

統合にあたり、ASKULとSOLOEL ARENAで保持しているデータを新サイトに移行する必要がありました。
データ量が少ないチームであれば、SQLで取得して対応できますが、注文チームはデータ量が多いため、単純にSQLで取得・移行するのは難しい状況でした。
さらに、データ量以外にも、移行に際して以下のような課題がありました。

【課題】

• DB
  旧サイトはOracle、新サイトはPostgreSQLと、データベースが異なる。
• レコード量
  全テーブルを合わせると数十億件にのぼり、単純にSQLで取得して移行するのが困難。
• テーブル構成
  新サイトと旧サイトでテーブル構成が異なるため、そのまま移行することができない。

• AWS DMS
• データファイル連携
• Embulk

• 処理速度
• 開発コスト
• 使用性

Embulkを使用し、問題なくデータ移行を完了することができました。導入にあたって大きな問題はなく、比較的簡単に導入することができました！
しかし、今回は数十億件という大規模なデータ移行を行う中で、いくつか課題も発生しました。
今後、同様にEmbulkを利用してデータ移行を行う方の参考になればと思い、弊社で発生した問題とその解決策を以下に共有します！

問題1：新サイトとの仕様の違いによる障害

発生した問題
弊社では、新サイトと旧サイトで仕様やデータ構造が異なるため、移行ツールでデータ変換処理を加えて移行を実施しました。
しかし、変換処理において新サイト側との認識の違いがあったり、旧サイトの仕様を十分に把握できていなかったため、障害が発生しました。
また、本来は両サイトの仕様に精通している担当者が移行を行うべきでしたが、さまざまな事情により新旧両方の仕様に詳しい人がいない状態で移行を進めたため、トラブルが発生しました。

予防策

1. 旧テーブルのデータ構造のまま移行できないか検討する
   データ構造が同じか異なるかで移行の難易度が大きく変わります。
   可能な限り旧テーブルのデータ構造を維持して移行することで、障害リスクを大幅に下げることができます。
   難しい場合は、リスクが高いことを周知し、十分なテストや人員、期間を確保するなどの対策が重要です。
2. 新旧の仕様に詳しい人をアサインする
   新旧のテーブルやデータ構造に詳しい担当者をアサインすることで、障害リスクを低減できます。
   どちらの仕様にも精通している人がいない場合は、旧サイト担当者と密に連携し、仕様の不明点をその都度確認する体制を整えました。
   根本的には新旧両方の仕様に詳しい人を配置することが理想ですが、難しい場合は壁打ちができる環境を整備するなどの対策が重要です。
3. チーム外とのコミュニケーションを取る
   移行時にはチーム間の認識の違いが発生しやすく、チーム内では合意できていてもチーム外では認識齟齬が起こりやすいです。
   認識合わせの場を設けるなど、コミュニケーションの工夫により障害リスクを低減できると考えています！

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

発生した問題
移行ツールで一次テーブルからデータ取得時にタイムアウトが発生しました。
原因と対応策
これらはよくある原因ですが、データ移行の事例が少ないため、私たちも十分に考慮できていませんでした。
度重なるテストを経て、タイムアウトが発生していた主な原因は以下の3点であることがわかりました。

1. データ量の把握不足 各テーブルのデータ量を把握せずにSELECT文を作成していたため、データ量が多くタイムアウトになるケースが見られました。
   そのため、各テーブルにどれくらいのデータが存在するかを把握し、このSELECT文でどの程度のデータが取得されるかを事前に確認することが重要だと感じました。
   また、データ量が多い場合は、LIMIT句を付けるなどして、取得データ量を調整しながら処理を作成することが重要だと思います！
2. 一次テーブルのインデックス設計の見落とし
   一次テーブルは現行テーブルを参考に作成しましたが、インデックスも現行通りに作成していました。
   しかし、この一次テーブルは移行ツールから参照される一時的なテーブルのため、インデックス設計も移行ツールの利用に合わせて最適化する必要がありました。
   同様に多くのデータを移行する場合や一時テーブルを利用する場合は、インデックス設計に注意することが重要です。
3. 本番同等環境でデータ取得時の実行計画を確認していない
   今回の経験から、事前に実行計画を取得することで、取得したデータ量が多い場合やインデックスが設定されていない場合を事前に検知し、対策を講じることができました。
   SQLのパフォーマンス確認のためには、実行計画を取得することをおすすめします！

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

発生した問題
日々移行を重ねていく中でデータ量が増加し、一次テーブルからのデータ取得時のSQLの性能が徐々に悪化していきました。
そのため、しばらくの間はインデックスのチューニングに注力していましたが、データ量が多すぎてインデックスが効かない場合や、インデックスが機能していても十分な性能が得られないケースがありました。
解決策
データマートの作成を提案し、対応しました！
データマートとは、蓄積されたデータから目的に応じて必要なデータを抽出・集計し、利用しやすい形に加工して格納するデータベースのことです。
データ量が多くなった要因は、日々の移行作業によってデータが増えていったためです。
また、過去データについてはすでに移行済みであり、基本的には障害時の調査用として保持しているだけでした。
そこで、移行対象データのみを格納した一次テーブル（データマート）を作成することで、この問題の解決を図りました。
その結果、SQLの性能悪化問題も解消できたため、同様のケースではデータマートの作成を検討することをおすすめします。