企業チーム所属の岡山です。
稼働中サービスのデータベースからカラムを削除された経験はあるでしょうか？
長年運用されているサービスでは、データベースの肥大化が避けられない課題の一つです。 私たちのサービスでも例外ではなく、機能の追加・変更を重ねる中で、使われなくなったカラムが大量に蓄積されていました。 使わないカラムが溜まっていくと、新規メンバーのキャッチアップの妨げとなったり、パフォーマンス面での影響も懸念されます。
そこで今回、あるメインテーブルのカラム整理に取り組むことになりました。 まず、不要と思われるカラムの中から本当に削除可能なカラムを特定する作業から始めました。 調査の結果、120個あったカラムのうち63個が不要であることが判明し、これらをDROPすることになったのです。
本記事では、63個のカラムをDROPするまでの手順と、その過程で学んだ知見をお伝えします。
安全なカラム削除のために
稼働中サービスで63個のカラムを削除する—この作業で最も重要なのは、エラーを発生させないことです。
カラム削除とアプリケーション修正を同時に行うのは非常に困難です。 デプロイタイミングのズレを考慮すると、安全な実行順序を決める必要がありました。
選択肢1：DB先行削除 → アプリケーションの参照が残っていればエラーが発生
選択肢2：アプリケーション先行修正 → 参照されないカラムが残るだけでエラーは発生しない
アプリケーション先行のアプローチを採用することで、修正後に十分な確認期間を設けてからカラム削除を実行する安全な戦略を立てました。
カラム削除までの5つのステップ
以下が実際に行った手順です。
1. 不要カラムの洗い出し
まず、120個のカラムの中から本当に不要なものを特定する作業から始めました。
データベース側の調査
ここ数年のレコードを調べ、以下の条件に該当するカラムを未使用候補として洗い出しました：
- 常に同じデフォルト値が登録されている
- 常にNULLとなっている
アプリケーション側の調査
次に候補となったカラムが実際にアプリケーションから参照されていないか、一つずつ確認していきます。
- 参照がない場合：削除可能カラムとしてリストアップ
- 参照がある場合：その機能が現在も稼働しているかを調査し、判断を保留
この段階で、120個のカラムから63個の削除対象カラムを特定することができました。
2. アプリケーション内からのカラム参照をなくす
手順1の調査で参照が見つかったカラムについて、不要機能の削除を行いました。 カラム削除後にエラーを発生させないため、アプリケーションコードからの参照をすべて除去する必要があります。具体的には以下の作業を実施しました：
削除対象の特定
- 提供が終了した機能を削除
- SELECT文やINSERT文での参照を削除
- 関連するバリデーション処理の削除
段階的なリリース
安全性を重視し、以下の単位で作業を進めました：
- 1機能または1カラム単位での修正
- 修正完了後、即座にリリースして動作確認
この段階では、削除予定のカラムはまだデータベースに残っているため、仮に見落としがあってもデータ喪失など致命的なエラーにはなりません。 万が一エラーが発生した場合でも当該の修正をRevertすることで、元の状態へ容易に復元することができます。
3. アプリケーション外からのカラム参照をなくす
アプリケーション以外からのカラム参照も忘れてはいけない重要なポイントです。
分析環境での使用チェック
ソースコード上では不要と判断したカラムでも、データ分析基盤など、アプリケーション外のシステムから参照されている可能性を考慮しなければなりません。 私たちのシステムでも、利用実績の分析のために本番DBが外部から直接参照されているため、同様の確認が必要でした。
そこで以下の手順で関係者との調整を行いました：
- 削除対象カラムのリスト作成
- 63個のカラム名とテーブル名を整理
- 削除予定日も含めて資料化
- 分析チームへの事前連絡
- 削除対象カラムのリストを共有
- 分析処理への影響がないか確認を依頼
分析チームの協力のもと利用箇所の確認が取れたため、実際のカラム削除作業に進むことができました。
4. 削除対象カラムをリネーム
これまでの作業で削除に向けた下準備は完了しました。しかし、いきなり削除するのではなく、まず リネーム で様子を見る安全策を採用しました。
リネーム戦略
削除対象カラムに「delete_」プレフィックスを付けてリネームすることにしました：
-- 例：profile カラムの場合 ALTER TABLE users RENAME COLUMN profile TO delete_profile;
リネームを行った理由は以下の通りです
- 削除のリスク：一度削除してしまうと、データの復元は困難です。仮に復元できたとしても、バックアップのタイミングによっては完全に元に戻らないデータも存在します。
- リネームの利点：参照が残っていた場合、以下のようなエラーが発生するため、見落としを即座に発見できます：
Unknown column 'profile' in 'field list'
リネーム後、数週間エラー監視を行い、エラーが検知されなければ、いよいよ削除に入ります。
5. カラムをDROP
ここまでの準備によってカラム削除の安全性は十分に担保されているため、最終ステップとして、本番データベースから対象カラムを完全に削除します。
ALTER TABLE users DROP COLUMN delete_profile;
まとめ
今回の手順を振り返ってみると、単にカラム削除といっても作業完了までの道のりは非常に長いものでした。 特に以下の2点が重要だったと考えています。
- 段階的アプローチ：アプリケーション先行修正とリネーム戦略
- 十分な監視期間：リネーム後の慎重な確認作業
カラム削除は早く終わらせてテーブル整理を進めたい気持ちになりますが、石橋を叩いて渡るくらいの慎重さが重要です。 63個という大規模なカラム削除でしたが、段階的なアプローチにより大きな障害なく、完了することができました。同様の課題に取り組む皆さんの参考になれば幸いです。
