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

この記事が語ること

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

手術当日

ここまでで全行程の9割は完了していると言っていい。
残すは、いかに手早く正確にオペを実施するかだけだった。

全体構成の概略の一部は以下のようになる。

中間DBをバイパスし、参照を完全に絶つ。
それが当日のゴールだ。

手術実施

出勤者の多い午後から作業を始めた。
周囲に人がいれば、困った時に助けてもらえる。
この安心感は強い。

無停止で切り替え可能であったため、サービスを平常起動させながらの作業となった。

まずはタイミングを調整し、麻酔を打つように、既存バッチを停止。

参照先の切り替え

いよいよメスを入れる。

デプロイを開始。
バイパスを通す工程だ。

手順書に従い、確実に確認しながら進めていく。
API、外部連携、ログの揺れをチェック。

粛々と進めていった。

データ加工フローの切り替え

新しいバッチを稼働開始。
変更した流路に血流を順次送り込む。

引き続き、バッチや各サービスの稼働状況を監視。

時間差で動くバッチも順次走り始める。
ログを監視し、エラーなし。

待機組はいるが、実際に手を動かすのは自分だけ。

本番確認

ここで異常が発覚した。

商品データ公開バッチが、初めて本番データをストアに掲出した瞬間だった。
商品の価格に狂いが出たのだ。

あってはならない事故だった。

「なぜ？」

頭をよぎる。

テスト段階では一度も再現しなかった。

原因調査

症状から目星はついていた。
見落としていたのは、商品データインデックス作成に使用する、ローカルな環境変数の直書きだった。
これが新規バッチと競合したのだ。

grepでも見つからない、設定レイヤの外側にあった。
ドメインに精通していたはずの自分でも見逃しうる構造だった。

「なぜ直接書いてあるんだ」という冷たい焦り。
これは“深く埋没して常態化した種類の負債”だった。

しかしこれも、ある意味想定内。
きっと何かは起こると、心の準備はしていた。

判断

この手術は、原則「後退なし」でやり切るつもりだった。

なぜなら、ロールバックは複雑で、戻すにもダメージが大きい構造だったからだ。

戻すより新フローで修正するほうが圧倒的に合理的と、即時判断した。

アドリブで前に進むしかない。

軌道修正

頭が真っ白になりかけていたが、修正にとりかかる。
原因箇所を特定し、修正。
再デプロイ、バッチの再実行、差分確認。

1〜2時間の作業。

実行結果は、今度は、正常だった。

手術は終わった。

監視

その後も徹夜で監視を続けた。
オフィスで一人、静かな夜に淡々とログが流れる。
新しい循環系の脈動は安定していた。

手術を1人で完遂した実感。
1年間の負債返済が終わった瞬間。

疲弊と安堵と地雷を踏んだ反省が、頭の中をぐるぐると巡る。

事故の報告書を書きながら、夜明けを待った。

中間DBの削除

数日後、中間DBを完全削除することになった。
完全に安定稼働しており、摘出したDBを残しておく理由はなくなった。

1TBのデータ、30本近いバッチ、数えきれない依存。
1年間追い続けたものを、ついに削除する瞬間だった。

依存はすべて消えた。
歴史的負債の塊はもうどこにもない。
サービスは新しい循環系で動き続けている。

ようやく、長かった戦いに幕を下ろしたのだった。

コストの現実

中間DB撤去だけなら月百万円以上の削減効果だった。
ただし、責務分散により、ほかのリソースに割く監視・運用コストは増加する。
結果としては、差し引き数十万円規模の削減に落ち着いた。

負債返済は必ずしも単純な引き算にはならないということだ。

学びとして残ったこと

● 負債除去の本質は“依存関係の洗い出し”
核心部分のリファクタよりも圧倒的に重要なのが、依存の把握だ。
この手の負債に切り込もうとすれば、"負債を温存する何層もの壁"があることに気づくはずだ。

● 全体を俯瞰し、順序を見極めること
どこから切り、どこを残し、どの順番で移すか。
順序を誤れば崩壊する。
でも、正しい順序を踏めば怖くない。

● 負債の返済を、評価される仕事にする
この仕事は評価されないだろう、と同僚に言われたことがある。
確かに、新規開発よりはるかに地味で効果も成果も見えにくい。
ただ、運が良かったのか、たまたまそういう組織だったのか、周囲にありがたがられ、評価される仕事になった。
巨大負債を除去しただけでなく、立ち回りと判断が評価された結果だったのだろう。

● 誰が引き受けるのか
誰も手を挙げない現場は珍しくない。
負債の返済は、個人の自発性に任せるのではなく、組織的な戦略として取り組まなければならない。
組織のあり方が、負債の返済へのモチベーションに直結するはずだ。

おわりに

負債は自然には消えず、触られなければ組織の寿命を削る。
技術的負債は返済しないといけない、というのはもはや言うまでもないエンジニアの常識だ。
問題は、いつ、誰が返すのか。

この記事を、他山の石としてもいい。
ただの一例として読み流してもいい。

この1年で、巨大な負債に向き合う方法を自分なりに学んだ。
心臓を止めずに心臓を取り出すような大掛かりな工程。
この経験は、エンジニアとしての自分の血肉になったと思っている。