Dress Rehearsal

ALTER TABLEのプログレスバーを4時間見つめたことがある。

決済系のサービスだった。メンテナンスウィンドウは4時間。数億行のテーブルにカラムを追加する。一瞬で終わると踏んでいた。

大丈夫ではなかった。

ALTER TABLEがメタデータの変更で済むか、テーブルの物理データを丸ごと作り直すか。その判定は見た目ほど単純ではない。MySQLのバージョン、ストレージエンジン、カラムの型、DEFAULT値、インデックス構成。条件の組み合わせで結果が変わる。その境界が直感に反する。数億行のテーブルで後者に当たると、もう祈るしかない。

祈った。

ローカルではそこそこの時間で終わっていた。だから油断した。本番はクラウドだった。

1時間経っても終わらない。2時間。3時間。メンテナンスウィンドウの枠を食い破った。10分サービスを落とせば始末書では済まないシステムだ。画面を睨みながら、何もできることがないという事実と向き合っていた。エンジニアとして最も無力な時間だった。

クラウドのディスクI/Oは読めない。AWSやGCPならまだ知見が溜まっているが、当時の本番環境は国産のクラウドだった。ディスク性能の実測値も事例もほとんど出回っていない。ローカルのリハーサルで通ったからといって、本番で同じ時間に収まる保証はどこにもなかった。

本来やるべきだったのは、ALTERを最小限に留めて、データはバッチで塗りつぶすことだ。作り直しが発生しないALTERだけ打って、投入は非同期でやる。サービスを止めなくていい。知っていた。知っていたのに、横着した。

YAGNIという言葉がある。必要になるまで作るな。ソフトウェア開発の鉄則で、わたしも基本的にはそう思う。ただしデータベースの設計だけは別だ。数億行に育ったテーブルのスキーマを変えるコストは、アプリケーションコードのリファクタリングとは桁が違う。テーブル設計は先を読むしかない。読みが外れることもあるが、読まないよりはましだ。

幸か不幸か、クラウド側の性能問題ということで先方の担当者が責を負った。わたしの会社は責められなかった。ALTERを書いたのはわたしなのに。

リハーサルは大事だが、タダではない。本番同等のデータを用意し、本番同等の環境を立てる。時間もインフラも食う。AIに任せたところで人件費が浮くだけで、ディスクI/Oのコストは変わらない。

だからカラムはなるべく先に作るようにしている。使うかどうかわからなくても。YAGNIに怒られそうだが、数億行のテーブルに後からALTERを打つよりはましだ。