[負債解消] e-dashの核になるテーブルのリプレイスが完了しました

はじめに

こちらはe-dash advent calendar 2024の24日目の記事です。

CO2の排出量可視化サービスを提供する弊社e-dashでは、CO2排出量の計算に関わる係数を保持する様々なテーブルが存在し、日々メンテされております。
しかしながら、ある係数の複数のテーブルについて下記のようなペインが浮上しました。

1. 外部キー制約が貼られておらずキーが見つからないケースがある
2. キーはあるがjoinした値が間違っている
3. テーブル名/カラム名がわかりにくい/実態と異なる
4. 利用されていないカラムがある
5. 上記への認知負荷が高い

これらのペインはプロダクトの信頼性を損ねることにつながると判断し、リプレイスするプロジェクトが立ち上がりました。

対象読者

• 負債が辛いと感じてる人
• 影響範囲が大きい修正をする際の進め方が分からない人

リプレイスプロジェクトの概要

影響範囲

アプリ本体のDBは、他のサービスから内部APIとしてDBを参照したり、アプリ本体用のlambda、batchから参照されることがあるため、影響範囲をまず調査しました。（下の図）

その結果、影響範囲は以下であることがわかりました。

• 内部APIの一部からは呼ばれているものの、数は数本程度
• lambda、batchからはリプレイス対象のテーブルが参照されており、影響範囲が大きい
• 管理画面からリプレイス対象のテーブル参照が一部あり（ここは別teamが担当）

リプレイスのスコープ

”リプレイス”と一括りに言ってもリソースには限りがあるため、やる・やらないの整理を行いました。

やること

• データ移行
  • 旧テーブルのうち、顧客が利用してるデータの修正
  • 新テーブルの作成
  • 旧テーブルのデータを新テーブルに移行（顧客が利用してるデータのみ）
• Feature Flagを使って、アプリ本体・lambda・batchの切り替え処理と監視
• リリース前後の監視
• [できれば] 不要なメソッドの削除

やらないこと

• リプレイス対象以外のテーブルやentityの命名変更
  • やり出したらキリがないため
• 内部APIのIFの変更
  • アプリ本体に集中し、影響範囲を狭めるため

プロジェクトの進行方針とステークホルダーとの合意

プロジェクトのリソース及び期間

以下の期間・メンバー構成・計画で進めて行く点をPMと合意をとり、着手しました。

※1Sprint=2週間 でやってます。

• エンジニア：3名 ※ ４名の時もありましたが、平すと3名。
• 期間：3ヶ月

スケジュール

• Sprint 0: 新テーブル作成&旧テーブルのデータの修正
  • 旧テーブルのうち、顧客が利用してるデータの修正
  • 新テーブルのDDL作成
  • Feature Flagの準備
• Sprint 1: 新テーブルからのデータ取得
  • 新テーブルからのデータ取得を実装
    • 影響のあるアプリ本体・lambda・batchの修正
• Sprint 2: 限定公開
  • log出力（利用してるテーブル, 企業ID, 排出量の合計値）を追加
  • Feature Flagでdemoテナントのみ、新テーブルからのデータ取得に切り替え&監視
• Sprint 3: 全社公開
  • Feature Flagを外して、全社にリリース
  • 不要なメソッドの削除
• Sprint 4: リリース後の監視
  • リリース前後の監視
  • バッファ期間
• Sprint X: 旧テーブルの削除
  • リリースして、一定期間問題がなければ削除する

うまくいったこと

1. 旧テーブルのデータ整合性をとること
   新テーブルに移行しても、元データが汚れていては元も子もありません。
   本プロジェクトの肝は元データをいかにクリーンなデータにできるか、でした。
   メンバーにはかなり負担をかけましたが、なんとかやりきってくれました。本当に感謝しかありません。

2. 新旧テーブルからの出力データを比較し、99.8%の一致率を達成したこと
   新旧のテーブル間のデータ比較は行っていましたが、それだけではPMのOKがもらえなかったため、全社展開の前に
   全社のCO2排出量出力データを比較しました。
   その結果、99.8%の一致率を達成し、PMのOKをもらうことができました。
   もしズレたらどうしようという心理な的負荷は高かったです。
   （releaseしてから気づくよりはマシ）

3. 不要なメソッドを9割は削除できたこと
   おそらく時間がなくて残るだろうと思っていた不要なメソッドですが、9割は削除できました。
   Feature Flag削除のPRが差分少なかったので、ここぞとばかりに混ぜこみました。
   また、他のメンバーも混ぜ込みに協力してくれたことも大きいです。

幸運だったこと

• e2e test , unit testがしっかりしていたため、修正の手を入れやすかったこと
• Feature Flagがすでに他のプロジェクトでも使われていたこと
• 全社のCO2排出量出力機能がすでにあったこと

unit testがなかったら、移行時に修正を入れにくいですし、Feature Flagの選定からやっていたら、もっと時間がかかっていたと思います。
また、PMから「全社分のCO2排出量を比較して欲しい」と言われた時に、すでに全社のデータを出力する機能があったのはラッキーでした。
（自分が作ったんですが、完全に忘れてた）

まとめ

e-dashの核になるテーブルのリプレイスプロジェクトの進め方について記事を書かせていただきました。
今のところ大きなトラブルはなく、良い年末を迎えることができそうです。

今後は運用を固め、マスターデータを高品質な状態を維持できる体制を作っていきたいと考えております。