もくじ
テーブルにカラムを1つ追加するだけでDBAは大変！
普段、設計や製造、テストを中心に行っている人が見落としがちな、データベースやネットワーク。開発時点でも問題無かったのに、本番環境で問題が発生したという話はよくある話です。
今回はデータベースについて、開発の時は問題無かったのに、本番環境では起こりうる現象について紹介したいと思います。
既に動いているサービスにて、入力項目を追加したい
とあるサービスで、こんな要件があったとします。
【要件】
1.お客様の情報を入力する画面にダイレクトメールの受信を許可するか否かを設定する新規項目を追加したい
2.既存ユーザーに関しては全てダイレクトメールの受信を許可するようにしたい
3.後々、許可したユーザー、許可しないユーザーが何ユーザーいるのかを管理していきたい
【修正内容】
画面
入力項目にダイレクトメール許可のチェックボックスを追加する。
データベース
お客様の情報を管理するテーブルに新規カラムを追加する
NOT NULL 項目とし、許可したユーザー、許可しないユーザーをきちんと管理。
※ 今回はあくまで例なので、画面以外のプログラムの修正については省略しています
開発者は画面や関連するプログラムを修正、及び開発用のデータベースに自身で下記のようなカラムを追加すれば良いでしょう。
DM_MAIL_APPROBAL CHAR(1) NOT NULL
普段からWEB開発を行っている方であれば、ちょろいですよね♪
その時DBAは何を考えるか
開発者と同じようにDBA(データベースの作成・運用・保守を行う人)の方も単純にテーブルにカラム追加をすればいいかと思いますが、実際はそう簡単にはいきません。
ローカル環境や開発環境で作業する分には、単純にカラム追加を行えばいいのですが、多くの開発者が同時にアクセスする、結合・総合環境、不特定多数の方がアクセスする本番環境では、そうゆう訳にもいきません。
特に、24時間365日提供しているサービスについては、リリース時に下記の二択を迫られるでしょう。
(1)一時的にサービスを停止してリリースする
(2)サービス停止させずにリリースする
(1)のケースについては、サービスそのものが停止しているので、安全にリリースが行えますが、(2)のケースの場合、考慮すべき点がいくつかあります。
サービス停止させずにリリースするとどうなるか？
結論から言うと、運がよければ何も起こらず、運が悪ければシステムエラーとなります。
何故かと言うと、テーブルにNOT NULL制約のカラムを追加した時点で、画面側がリリース前の場合、データをINSERTしようとしたところで、新規カラムに値が入らないため、NOT NULL制約に引っかかってしまい、システムエラーとなってしまうからです。また、アプリのみが更新された状態でも同様です。(そんなカラムないよ！ って怒られます)
システムエラー…というより、システム障害はとても怖いです。
24時間サービス提供しているシステムであれば、システムエラーを検知した時点で様々な関係者が時間帯に関わらず集まってくることでしょう。
私は以前、とあるシステムの保守開発を行っておりましたが、夜中の3時過ぎに障害発生の電話がきて、始発で駆け付けたことがあります。
サービスが提供出来なくなった場合、その期間の売り上げが無くなるのと同時に、顧客の信用まで失いかねません。
じゃあ、今回の場合はどうすればいいの？
脱線しましたが、じゃあ、どうすればいいのか？
その答えの一つが以下のような方法となります。
一気にカラム追加とNOT NULL制約を付けるのではなく、このように段階的に行えば、安全にリリースを行うことが出来ます。また、既存レコードのデフォルト値をUPDATEする際に、どのくらい時間が掛かるのか、事前に検証する必要があります。
今回はとてもシンプルな改修でしたが、改修規模が大きければ大きいほど、DBAの方はこのような懸念事項をいくつも洗い出して、対策を打たなければならないので、とても大変です。
DBAさんは凄い！