ECの心臓外科手術【前編】：雁字搦めの1TB中間DBを摘出した話

この記事が語ること

ECの商品データフローに施した"手術"の話。
約1TBのデータと30本近いバッチに依存した中間DBを、稼働中システムから解体するまでの1年間の記録。
前後編の前編。 → 後編はこちら

エンジニアは、しばしば医者になる

それはECの心臓外科手術だった。

ECサービスの表と裏、あらゆる箇所に商品データを加工し送り込む、巨大なDB群とバッチ群。
それはまさにサービスの循環系を担う、心臓部だった。

課せられたミッションは、
このDB群から"中間DB"と呼ばれるDBインスタンスを丸ごと削除する
ことだった。

参照が散らばり、その場しのぎが積み重なり、歪みが押し込められ、誰も把握できていない構造が層になっている──。
そんな中間DBの現状は、現場の全員が知っていた。

目的は、この巨大な負債の一括返済だ。
「これはヤバい」と戦慄するのは当然のことだった。

この手術は、ざっくり言うとこういう流れだった。

診察

調査開始時点で中間DBについて分かっていた状況は、こうだ。

• サイズ：約1TB
• バッチ：20〜30本
• 複数システムが直接参照
• 責務が集中
  • データ集約
  • 商品データキャッシュ
  • 外部連携用データ
  • バッチ処理の中継
  • 各種APIの参照先

だが、蓋を開けてみたら、この想定を軽く超えていた。

テーブルの下にテーブルがあり、その下に集計ロジックがあり、その集計ロジックが別のデータフローを前提にしていて、そのデータフローがさらに別のシステムに依存していて――。
まるで血管が何層にも絡み合い、どこを触っても別の場所が揺れるような構造だった。

中間DBは表向きサービスの中心だったが、実際は「取り敢えず使われていた便利な塊」に過ぎず、多くの依存は本体DBやバッチで代替可能だった。チームも薄々、その無秩序さに気付いていた。

ひとつ依存を特定してみると、その下からさらなる依存が三つ出てくる。

三つ辿ってみると、九つ増える。

そんなことの繰り返しだった。

負債というものは、放置すればするほど深く、太く、複雑に絡み合う。
その事実を痛いほど突きつけてきた。

これは“1年かけたプロジェクト”ではない。

“1年かかってしまった現実” だった。

流路追跡

依存関係を洗い出した。
一言で言えばそれだけだが、実際には数百の末端を追いかけ、地図を作る、狂気的な作業だった。
PHP、Java、Python、バッチ、シェルスクリプト、SQL──言語もリポジトリもバラバラで、参照は枝分かれし、データは別のデータの前提となり、例外ルートは歴史的負債の層に埋もれていた。

「このデータは何に使っている？」

APIを逆算し、サービスを追い、メソッドを分解し、参照を確認し、リポジトリをいくつも跨ぎ、フロントエンドまで辿った。
言語もフレームワークも違う。それでも「この値はどこで生まれ、どこで死ぬのか」を一本の線として確実に辿る必要があった。
スプレッドシートに、チケットに、紙の資料に、把握できた構造を記していった。

外部連携も絡んでいた。
委託先が運用しているシステムが中間DBを前提にしていたり、外部APIのパラメータの生死が不明だったりする。
ここは人間同士で話すしかない。
静的解析だけには頼れない。

「このAPI、まだそちらで使っていますか？」
「この値、まだ必要ですか？」
「これ止めたら、死にますか？」

複数のレガシーと化した機能とも繋がっていた。
誰も触っておらず、誰も説明できない。
だが、動いてはいる。

そのたびに立ち止まり、

「これは消していいのか？」
「作り替えるべきなのか？」
「本当に誰も使っていないのか？」

逐一確認した。

必要なら横道にも入った。
大きなフローと細かい分岐を往復し、一本ずつ潰していった。
数百回は繰り返した。

思い返せば、よく把握しきれたと思うほどの量だった。
もっと効率よくできたのかもしれない。
でも、これが当時の筆者なりの、誠実な負債の返し方だった。

術前処置

依存を辿り切ったあとに残ったのは、“中間DBが抱えていた責務の塊”だった。

参照、変換、集計、キャッシュ、データレイク。
本来なら別々の場所にあるべき概念が、ひとつの場所に押し込まれている。

まずはこれを手術可能な状態に整える必要があった。
まだ心臓にメスは入れない。
やることは、絡み合ったコードの解体と、境界の見極めと、契約の調整だ。

• 不要なものは消し去る
• 責務境界を分割する
• 集計処理用のテンポラリテーブルを削る
• 外部システムとの契約を洗い直す
• レガシー機能の生死を確認する
• 不十分な例外処理を整える

これは、「どこに手を入れると死ぬか」を見極め、患部の核心を削り出す作業だった。

• 中間DBが抱えていた“歴史的な絡まり”を一つずつ剥がした
• 本来あるべき責務の位置を見極め、設計に反映させた
• 外部との暗黙契約をすべて明確化した
• 単位を分割し、デプロイし、過程を記し、前提を更新した

こうして、"手術に耐えられる身体"を整えていった。
費やした時間は莫大だった。

循環系再編

術前処置が終わり、ようやく“新しい循環系”を作る段階に辿り着いた。
ここからが、リファクタにおける中心作業となる。

• 中間DBを使わずに済むよう、商品データフローにバイパスを通す
• 補正・変換・集計を適切な層に移す
• バッチフローを再構築する
• API整合性を再定義する
• データのライフサイクルを再設計する
• 新旧フローを並行稼働させ、差分を潰す

中間DBが担っていた役割を適切なサービスへ移し替え、責務を整理し、境界を整え、"中間DBなしで成立する循環系”を構築していく。

既存の重要処理に傷をつけないように、境界を見極めながらドラスティックな改善を仕込んでいく。

ここまで来て、いよいよ心臓にメスを入れる準備が整った。

手術シミュレーション

再編が終わっても、まだ切り替えはできない。
新しい循環系が想定通りに動くかどうかを、既存のものと並行して検証する必要がある。

• 旧フローと新フローを並行稼働させておく
• 商品データ差分を比較テストし、異常を潰す
• どこに負荷が移動するかを見極め、監視体制を整えておく
• データのマイグレーション作業のリハーサルを行う

検証用に新旧フローを並行稼働させておくということは、当然複数種類のインフラが必要だ。
期待通りの検証環境を整えるのにも注意を払った。

検証を通じて、中間DBをバイパスしても異常が出ないことの確信を得ていった。

作業手順も整える。

• 分単位の当日スケジュール確立
• ロールバックポイントの明確化
• 起こりうる不具合に対しての備え

あとは本番当日を迎えるだけとなった。

(後編へ)