DBの不要なカラムを削除する

エキサイト株式会社の武藤です。

現在は担当サービスであるE・レシピのリビルドを進めており、技術負債の解消も行ってきました。 レシピデータを管理するテーブルには、現在の仕様で使われていないカラムが50個ほどあり、それらを削除しました。

今まで、仕様追加によって新たにデータ管理する際には、既存テーブルへのカラム追加で対応されてきました。 その仕様がフロントエンドやアプリから使われなくなっても、削除が困難なために放置され続けてきました。

不要なカラムやそれを参照しているコードは、開発時にノイズになるため、削除したほうがよいでしょう。 今回は、不要なカラムを削除するにあたって、バックアップテーブルとカラム削除後のテーブルを用意し、ダブルライト方式で安全に行った手順を紹介します。

不要カラムのピックアップ

まずは、現在使われていないカラムをリストアップしました。 運用経験や命名から使われていないカラムを推測します。

次に、リストアップしたカラムがコード上で使われていないことを確認します。 GitHubIDE上でカラム名を検索し、参照がないことを確認しました。 アプリケーションによっては、DBから取得した値が変数に格納された時にスネークケースからキャメルケースに変換されることがあります。 その点も加味しながら検索ワードを変えて調査していきます。

最終的に、表示に使われていないことを確認するため、フロントエンド、AndroidiOSなどクライアント側のコードを調査する必要があります。

DB接続から表示までと調査範囲は広く、アプリケーションの規模によっては複数のプロジェクトに跨るため、大変な作業です。。

アプリケーションから不要カラムの参照を削除

アプリケーションからリストアップした不要なカラムの参照を削除していきます。

リリース後、エラーの確認期間を数日設けます。

バックアップテーブル、削除後テーブルのダブルライトを実装する

アプリケーション側でダブルライトを実装します。

手順については後述しますが、問題発生時に切り戻しができるようにバックアップテーブルを作成します。 バックアップテーブルと削除後テーブルで更新内容を同期するためにダブルライトを行います。

この段階ではリリースせず、切り替えの準備をしておきます。

不要カラム削除の実施手順

ここまででカラム削除の準備ができました。 次にDBへの変更の順番を考えていきます。

E・レシピの場合は、DBの書き込みを一時停止してもサービス利用に影響がないので、一時的に書き込みを停止する判断をしました。

バックアップテーブルの作成

カラム削除前テーブルからバックアップを作成し、アプリケーションのリード先をバックアップテーブルに変更します。

f:id:excite-mthiroshi:20211015170744p:plain
カラム削除前テーブルをバックアップし、アプリケーションのリード先を変更

図では、レシピデータを管理するrecipeテーブルに、古いキャンペーンのカラムが放置された状態と仮定しています。

不要カラム削除前のテーブルを参照されないようにリネーム

外部キー制約を無効化します。削除対象のテーブルへの外部キー制約があると、制約の参照元のテーブルに影響が出る可能性があるためです。

カラム削除前テーブルをリネームして参照されない状態にします。 削除ではなく念の為リネームで留めておきます。

f:id:excite-mthiroshi:20211015171208p:plain
カラム削除前テーブルをリネーム

不要カラム削除後のテーブルにデータを投入

カラム削除後のテーブルを作成し、バックアップテーブルからSELELCT, INSERTでデータ投入をします。

f:id:excite-mthiroshi:20211015171746p:plain
カラム削除後テーブルを作成しデータ投入

アプリケーションのダブルライトを反映

その後、DBの外部キー制約を有効に戻し、アプリケーション側のバックアップテーブルとカラム削除後テーブルへのダブルライトをリリースします。

f:id:excite-mthiroshi:20211017174707p:plain
ダブルライトを反映

ダブルライトのリリース後、アプリケーション側で問題がないことを確認し、書き込み処理を再開します。

その後、数日経過を見て問題がなければ、ダブルライトを停止、バックアップテーブルを削除して完了です。 ダブルライトにすることで、切り替え後に問題があれば向き先を戻せばよいので、そこがメリットです。

最後に

ダブルライト方式のテーブルの不要カラム削除の手順について説明しました。

レシピサービスとして根幹となるテーブルの不要カラム削除は、影響を考えると慎重に進める必要があり、大変な作業でした。

今後はメンテナンスのしやすさも考慮して開発がしたいと思いました。