【Google Cloud Next Tokyo 2025】LIXIL が考える、異種間データベース マイグレーションを成功させる秘訣とは セッションレポート

はじめに

当記事は、先日開催された Google Cloud Next Tokyo 2025 の中で行われたセッションのレポートとなります。

タイトル：LIXIL が考える、異種間データベース マイグレーションを成功させる秘訣とは
登壇：株式会社LIXIL 志村 遼太氏、菅野 寛史氏、出井 彰記氏

セッション概要

本セッションでは、既存のデータベース (Oracle Database、MS SQL Server、IBM Db2) についての Google Cloud へのクラウドシフト戦略、その中での移行方法や課題、考慮点についてご紹介いただきました。
Oracle Database については、数十にわたるシステムのクラウドシフトを行い、Google Cloud のマネージドサービスを活用することにより運用効率を向上させ、MS SQL Server と IBM Db2 については、大規模な基幹システムをクラウドネイティブなアーキテクチャに移行する高難易度のマイグレーションを実施されています。

Oracle Database の移行

• プロジェクトの概要
  • 主な背景としては、既存の仮想基盤の老朽化やコストと運用工数の削減がある。
  • 個別のシステムではなく、複数のシステムを対象とした組織的なマイグレーション。
  • クラウドシフト戦略としては、OSS 系の採用と運用・費用の削減。
  • 体制発足から約2年での移行完了。
• 移行先の Google Cloud データベースサービスの評価
  • Cloud SQL や AlloyDB といったデータベースサービスへの移行によって、Google Cloud のマネージドな機能を活用することで、運用負荷の軽減や可用性向上、PostgreSQL といった OSS のエンジンを採用することによるライセンスコストの削減が可能となった。
• プロジェクトの推進
  • 各システムに対してドキュメントを公開
    • 移行ツール利用手順
      • Database Migration Service (DMS) を主に利用し、一部 DMS がサポートしない Oracle 9i 等のバージョンについては、Ora2Pg を利用。
    • DB ガイドライン
      • LIXIL社における推奨 / 非推奨  / 禁止事項を説明。
      • 品質維持のため監視メトリクスについても言及。
      • Query Insights やリードレプリカの設定方法の記載。
    • 問い合わせ
• 苦労した点
  • レガシーな Oracle Version の移行については、Ora2Pg などの代替ソリューションを利用したことでの追加検証が発生したこと。
  • クエリ変換について、DMS コンバージョン機能や社内 AI チームから提供された変換ツールを利用したこと。
  • マイグレーション後の品質低下を防止するために可用性やセキュリティ、監視などの対策が必要だったこと。
• 成功要因
  • 手順書やガイドライン、Tips を展開したことで移行や構築のハードルを下げたこと。
    • 副次的に DB 周りのガバナンスが強化。
  • DMS がサポートしない部分は Ora2Pg で対応したこと。
    • DMS はドキュメントが豊富かつ無償であり、今回のような大規模なケースでも横展開可能。
  • Google を含めたサポート体制を構築したこと。

MS SQL Serverの移行

• 移行対象システム概要
  • LIXIL社のショールームや営業、社外パートナーが使用する複数商材（キッチン、トイレ、洗面、浴室など）の見積システム。
  • ユーザーが選んだ仕様に合わせて3Dがリアルタイムで更新され、資材の測定と金額の計算を行う。
  • データボリュームや総量、1日のリクエスト数が膨大な大規模なシステム。
  • 年間365日稼働。
• 移行前の課題
  • システム老朽化により、DB 起因の原因不明の障害が発生。
    • 見積もりが不可になり被害が大きい。
  • バージョンが古く、新技術に遅れを取る。
    • パフォーマンス改善などのユーザーへの価値提供が難しい。
  • 申請や調整を含めてリソース変更に時間がかかる。
    • 障害復旧後の処理増加に対応した柔軟な運用が難しい。
  • 365日稼働のため、業務停止を極力避けた移行計画が必要。
    • 長期休暇を利用すると、半年〜1回のリリース計画しか立てられず、他システムとの調整も複雑になるため避ける必要があった。
• 移行の工夫と解決策
  •  移行アーキテクチャ
  • データマイグレーションツール選定
    • 検討当時、DMS が SQL Server → PostgreSQL へのマイグレーション未対応
    • SaaS はコスト観点で断念し、既に社内で利用実績のあった ETL ツール Embulk をカスタマイズして活用。
    • Embulk の Input/Output プラグインの自由なカスタマイズ性を活かし、Output 部分を PostgreSQL に変更することで、知識とスキルを活かして工数を短縮。
  • 並列処理によるデータ移行期間の短縮
    • Workflows と Batch を活用し、複数のテーブルを並列で移行できる仕組みを構築。
    • 7TBのデータ移行を約1日半、日次同期データを約1時間で完了させ、現実的な移行時間を実現。
  • DBMS の差異によるクエリのパフォーマンスチューニング
    • ユースケースごとの自動テストシナリオを用意し、ベンチマークを取得。
    • 影響の大きいシナリオで実行されるクエリを特定。
    • 実行プランを確認しつつ、AI活用によりクエリ修正。
  • 本番切り替え時のサービス停止時間の抑制
    • ある時点のデータを一括移行 (約1日半)し、それ以降は日次で差分のデータを移行 (約1時間)、本番切り替え時は当日差分データのみ移行 (約1時間)
      • 業務停止をほとんどすることなく本番切り替えを実施可能となった。
• 移行によるメリット
  • オンプレミスの SQL Server から AlloyDB for PostgreSQL へ移行したことで、DBのインフラコストを43%削減。
  • AlloyDB の Query Insights により、利用状況の可視化やリアルタイム分析が可能となり、アドバイザー機能により迅速にパフォーマンス改善が可能となった。
  • リードプールインスタンスを用いて不具合や問い合わせの調査に活用。
  • 本番のバックアップからリストアした環境で、短期間でコストを抑えながら本番相当のデータで性能テストや負荷テストが可能となった。

IBM Db2 Databaseの移行

• 移行対象システム概要
  • LIXIL社のものづくりを支える生産工場で利用される生産管理システムであり、安定したDBサービスの提供が必要。
  • 約30拠点、5,400人の従業員が日々の業務で利用。
  • データボリューム、1日のトランザクション数ともに大規模なシステム。
  • 24時間稼働。
• 移行前の課題
  • サーバーの老朽化による DB 起因の障害の発生と、OS 制約等での最新ツールの採用不可。
  • 社内でも Db2 を採用しているチームが他になく、現在の有識者の退職などにより、長期的な目線でDb2の有識者が減少していく懸念がある。
• 移行アーキテクチャ
  •  DB サーバーは AlloyDB for PostgreSQLを採用し、アプリケーションサーバーも老朽化していたため、サーバーレスな Cloud Run を採用。
• プロジェクト推進体制
  • LIXIL社内体制
    • システムのユーザーである生産業務部と連携し、週次で進捗や課題を共有しながら推進。
    • 生産業務部門にデジタル部門との間を取り持つ役割の担当者をアサインし、デジタル側がシステムアーキテクチャ構築に集中できる体制を構築。
    • デジタル部門内でもアプリ開発メンバーとインフラメンバー間で明確に役割分担し、密にコミュニケーションを取りながらアーキテクチャ構築を進めた。
  • Googleからの支援
    • カスタマーエンジニアやソリューションスペシャリストがPoC段階から参加し、週次で進捗や課題共有を実施し、技術課題に迅速に対応可能となった。
    • データ移行に関しては、Professional Services Organization (PSO) が関与し、移行ツールの検討等の支援を受けた。
• 移行における技術的課題と対策
  • トランザクションスコープの変化
    • Db2 では SQL エラーがあってもエラーハンドリングロジック内で別の SQL を実行可能だったが、PostgreSQL ではトランザクション中に SQL エラーが発生すると、後続のロジックで SQL を実行できず、トランザクション全体がロールバックしてしまうという違いがあった。
      • エラーハンドリングのロジックは同期性を保ちつつ、別トランザクションに切り出すという Java アプリケーションの改修を実施。
  • 数値の丸め差異:
    • DECIMAL 項目で定義していない小数点に値を格納する際、Db2 では切り捨てであったが、PostgreSQL では四捨五入になる挙動の差異があった。
      • DECIMAL 項目全てに対して影響調査を実施し、対応が必要な項目を設定する箇所に Java 側での実装で対応。
  • 事前検証で検出できたことで、リソースを調達し納期を達成。
• データ移行の工夫
  • 工場ごとに移行を完了させるため、土日での移行を達成する必要があり、9時間以内でのデータ移行を目標としていたた。
    • PSO の支援を受けながら、データ移行ツールの検討や、テーブルを「全拠点共通のテーブル」と「工場ごとに移行できるテーブル」などに分類し、分類ごとに移行方法の妥当性を確認。
    • データサイズが大きな BOM 系のマスター (全データ量の約3割を占める) は、1週間前に事前移行を行い、その間はマスター更新をしないようユーザーと調整。
    • 全てのテーブルを直列で移行するのではなく、エクスポートとインポートの多重度を上げて並列で処理を実施し、検証を通じて多重度4での作業が現実的な時間で移行可能であることが分かり、目標の9時間を達成。
• 移行によるメリット
  •  AlloyDB for PostgreSQL へ移行したことで、DBのインフラコストを53%削減。
  • オンラインバックアップが可能となり、DBサービスを停止することなくバックアップが可能となった。
  • リストアが容易になり、性能検討時のバックアップ断面を再利用することで、性能検証時のデータ準備が不要となり効率が大幅に向上。
  • その他、高負荷時のレプリケーションの迅速さや BigQuery へのデータ連携においてもメリットを享受。

まとめ

• Oracle Database の移行では、DMS を用いた共通の手順がスムーズな移行に貢献。
• MS SQL Server / IBM Db2 Database の移行では、データ移行時間を短縮することで、ユーザーへの影響を最小限に抑えて重要システムの移行を実現。
• Google Cloud への移行によって、コスト面と運用面でメリットを享受。

さいごに

今回のセッションを通じて、エンジンや重要度の異なるデータベースを Google Cloud へ移行させる際の考慮点を学ぶことができました。印象的だったのは、ドキュメントの共通化や先行チームのナレッジ共有による大量のシステムのスムーズな移行の実現と、本番切り替え時の停止時間を短縮させるための事前移行や移行処理の多重化でした。運用の観点や技術的な観点で課題解決に繋げることが可能であるため、課題に直面した際は多角的な視点で解決策を探ることが重要だと思いました。