KDOC 393: ビックバンデプロイのやり方を考える

• 作成
  • 2025-06-16 貴島
• レビュー
  • 2025-06-25 貴島

フルタイムのプログラマーとして働き始めて1年目のときに、「データ変更とコード変更を同時にやってはいけない」を教わった。データ変更 → デプロイ → コード変更 → デプロイというように片方ずつ変更せよ、片方ずつデプロイできるように変更せよ、というようなことだ。データ変更はコード変更に比べて、カラム変更、インデックス追加、レコード変更といった操作に長時間費やす可能性がある。その間はデータとコードが一致しなくなる。リクエストが来た場合、動かない可能性がある。最悪の場合、不整合レコードになる。

教わった内容は単なる無意識の習慣になり、意識することはなくなっていた。あるとき、誇張した形でそれが現れた。デプロイが3ヶ月ごとにしかできないような¹Webのシステムにおいては、常にデプロイ可能なシステムよりシビアに、データとコードについて考える必要があった。ビックバンデプロイをそもそも避けたほうがいいのは間違いない。しかし避けられないシステムだって世の中には存在している。

問題なくデプロイをするには、2つの方法があるように見える。

• ダウンタイムを受け入れて、バックエンドサーバを止めるか遮断する。ブロックしないと、データ変更中にリクエストが来て不整合になってしまう。フロントエンドを止めるだけでは不十分である。リロードしてない人はアクセスを飛ばせてしまう
  • ❌ ダウンタイムの発生
  • ❌ 停止させるための方法確立が必要
  • ❌ 何か起こった場合に原因が切り分けにくい
  • ⭕ 手順が単純、少ない
• チェックポイントとなるコミットで、数回繰り返してデプロイする
  • ⭕ ダウンタイムが発生しない
  • ❌ 数回デプロイする分時間がかかる
  • ⭕ 何か起こった時点で把握しやすく、原因を切り分けやすい
  • ❌ 手順が複雑、多い

ダウンタイムの許容ポリシーにもよるが、規模が大きくなるほど段階的に進めてデプロイしたほうがよさそうに見える。

なし。