「動いている」を言い訳にしない ― 壊さず変えるDB移行5年の記録

250 Views

October 21, 26

#lifull #技術的負債 #database

スライド概要

2026年9月16日の「技術的負債に向き合うConference 2026」での登壇資料

株式会社LIFULL

@LIFULL

スライド一覧

LIFULL HOME'Sを運営する株式会社LIFULLのアカウントです。 LIFULLが主催するエンジニア向けイベント「Ltech」等で公開されたスライド等をこちらで共有しております。

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

pmconf2023【プロダクトマネジメントで高速PDCA】アウトカムが激増したLIFULL HOME’Sのグロース事例

プロダクトマネジメントプロダクトマネージャー lifull

株式会社LIFULL 26.8K

CloudWatch LogsからGrafana Lokiにログ基盤を移行

lifull aws grafana ログ

株式会社LIFULL 25.6K

HNSWの内部構造

lifull hnsw search

株式会社LIFULL 23.4K

PrometheusとGrafanaで追求する、より良いアプリケーションの可観測性

lifull grafana ログ kuberentes

株式会社LIFULL 21.8K

100人超のエンジニア組織の統合、60以上のアプリケーションの基盤集約、日本最大級の不動産・住宅情報サイト『LIFULL HOME'S』を支え続けるエンジニアリング＿長沢翼

lifull lifull home's cto keel engineering technology

株式会社LIFULL 20.7K

#ED6103との付き合い方

アクセシビリティコントラスト wcag apca

株式会社LIFULL 15.5K

各ページのテキスト

LIFULL / 技術的負債に向き合うConference 2026 登壇者紹介渡部⻯也 [写真] テクノロジー本部事業基盤部アーキテクトグループシニアエンジニア ● ● ● © 2026 LIFULL Co., Ltd. 2012年LIFULL入社バックエンド開発からデータ基盤構築、海外版プロダクト開発まで幅広く担当現在はアーキテクトGにて、LIFULL HOME’Sの基盤DB移行プロジェクトを推進中 2

LIFULL / 技術的負債に向き合うConference 2026 LIFULLが⼤切にするものあらゆるLIFEを、FULLに。世界中の⼀⼈ひとりの暮らしや⼈⽣を、安⼼と喜びで満たす社是ガイドラインガイドライン利他主義⼤胆に挑戦する⾃ら動く、⾃ら変えるみんなを幸せにしたい過去にとらわれず挑む課題の中⼼に⼊り解決する価値観が、挑戦と改善の意思決定を⽀える。 © 2026 LIFULL Co., Ltd. 4

LIFULL / 技術的負債に向き合うConference 2026 住まい探しの「業界初」を、LIFULLから 2019 2022 2024 ⾃動⾮掲載街歩きAR Vision Pro 募集終了情報を連携業界初 ARグラス時代を⾒据える不動産業界初没⼊型モデルルーム国内不動産ポータル初 2019年の仕組みは、現在⽉約10万件の物件広告を⾃動⾮掲載※ ※「初」は各発表時点の⾃社調べ。2019年は管理会社連携型の⾃動⾮掲載。⽉約10万件は2024年2⽉時点。 © 2026 LIFULL Co., Ltd. 5

LIFULL / 技術的負債に向き合うConference 2026 エンジニア部⾨横断「負債解消祭り」負債解消は、攻めの投資。 2026.03.18 11:00‒17:30 グループ単位で集中実施最後に3〜5分の成果発表⽂化技術越境負債解消を⽌めない AI等で最⼩⼯数‧最⼤成果グループを越えて知⾒を共有成果の⼀例 Visual Regression Testing（VRT）を導⼊ © 2026 LIFULL Co., Ltd. 画⾯の⾒た⽬の差分を⾃動で検知する仕組み 8

10.

11.

12.

13.

14.

15.

16.

課題 1｜DMS同期ラグによるデータ不整合の発生更新直後の参照クエリで「最新データが未反映」となるリスク ① WRITE 📱 アプリ / バッチ・データ更新（WRITE）・更新直後の参照（SELECT） ② DMS同期 (※同期ラグ発生 ) 🗄 Oracle DB (移行元 / 最新データ) 🐘 PostgreSQL (移行先 / 参照試行 ) ❌ ③ 直後SELECT：ラグにより古いデータを取得！【結論】データ最新性が必須な機能では、参照（ SELECT）のみの先行移行が不可能に

17.

課題 2｜複数JOINによる「移行不可」の連鎖（ドミノ倒し） 1つの不整合リスクが、 JOINに含まれる全テーブルの移行をブロック 🔍 複合SELECTクエリの構造 SELECT * FROM Table_A (更新直後参照 ) JOIN Table_B JOIN Table_C JOIN Table_D; Table_A 1つでも「リアルタイム参照必須」であれば、このクエリ全体をPG側へ切り替えられない。 ① Table_A が移行不可（Oracleに残す必要あり） ⛓ 連鎖的に増大する移行不能領域 ② JOIN相手の Table_B, C, D も連鎖して移行不可に ③ 段階移行の範囲が狭まり、移行規模が巨大化【影響】参照の段階切り替えが阻まれ移行規模が肥大化 ➔ 対策「二面書き」の採用へ

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.