いろいろあると思うのですが。おいちゃんの想定している運用は…多分、 http://www.publickey1.jp/blog/14/immutable_infrastructure_1.html にある、 http://www.publickey1.jp/blog/14/imm04.jpg の絵がとても近いような気がするのですが、こんな感じ。
とりあえずAWS用語を使うので、他のクラウドなら適宜読み替えてくださいませ。ンなに固有の機能は使わないので。
登場人物
ELB：Webのロードバランサ@AWS。「ロードバランサ」と読み替えていただければ、大抵のところでイケるんじゃなかろうか、と。
ec2：いわゆるヴァーチャルなサーバインスタンス@AWS。これも「サーバインスタンス」って読み替えていただければ以下略。
AMI：マシンイメージ。これもAWS。サーバインスタンス作る元ねた的なもの。これも大抵あると思うので以下略。
初手
・必要と思われるdaemonを一式いれて「基本AMI」を独自に作成
・「基本AMI」から、開発用のサーバ、いるんならステージングサーバ(おいちゃんはよく、開発用サーバに共存させちゃう)、本番用のサーバ(とりあえず１台を仮定)をそれぞれ作成
・ELBを適切に紐付けます*1。本番サーバは、一旦「本番サーバテスト用ELB」に紐付けておきます
・開発サーバで適宜開発が進んでいる、と仮定します
・適当なタイミングで、一旦「これをデプロイしませう」なブランチなりなんなりを、ステージングサーバに持ち上げます。具体的には、おいちゃんは「ステージングサーバで、masterなりdevelopなりdeployなり、適切なブランチを git pull する」程度
・ステージングで適宜確認
・本番サーバにデプロイ。おいちゃんは「あらかじめ用意してあるrsync叩く」程度。このタイミングで、本番サーバは「本番サーバテスト用ELB」と紐づいている
・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する
・本番サーバのインスタンスを「本番サーバテスト用ELB」からはずして「本番用のELB」につなげる
以降のプログラムソースのデプロイ(開発中も、本番時も)
・とりあえず１台、AMIから新しく鯖インスタンスを作成 → 新鯖
・「新鯖」に、ステージングのソースを一式デプロイする
・新鯖を「本番サーバテスト用ELB」に紐付ける
・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する
・新鯖をcopyして、「現在、本番用のELBにぶら下がってる鯖と同じ数の新しい鯖(理由があるならインスタンス数を増減させてももちろんOK)」を作成する。これを「新鯖群」と呼称
if(ELB的なものの「接続ドメイン」がスイッチできるのなら) {
・「本番用のELB」と「本番サーバテスト用ELB」のドメインをスイッチ(スワップ)する
} else(スイッチできないのなら) {
// 幾分スピード勝負なんで、バッチ的なもので処理をするとよりよいように思います
・新鯖群を一通り「本番用のELB」に紐付ける
・旧鯖群を全部、一気にはずす
・新鯖群を「本番サーバテスト用ELB」からはずす：ここは落ち着いて、少々タイムラグがあってもよし
}
・不安なら、旧鯖群の１台を、AMIとかでスナップショットっておく
・１時間くらい様子をみて、問題なさそうなら、旧鯖群のインスタンスを全部削除する
daemon等のupdate
・新しいAMIつくる。「０から作る」でもいいんだけど、既存最新のAMIから作ったほうがいろいろと楽
・新しいAMIから新しい鯖インスタンスを作成、開発環境で使って「問題ない」事を確認する
→あたらしいAMI作る
→あたらしいAMIからインスタンスを１つ作る
→開発を一旦停止、ソースは全部gitにしまっていただく
→開発DBの中身をダンプする
→新開発鯖にDBの中身を入れる
→ソースコードを新開発鯖にpullする
→開発ELBの向き先を「新開発鯖」にする
→開発を続ける：不具合があったら適宜対応をする
・ステージング鯖を作り直す：開発鯖とおおむねいっしょ。
・本番鯖を作り直す：「以降のプログラムソースのデプロイ」と手順一緒
DBの変更：テーブルの追加
・開発鯖で確認
・ステージングでとっととcreate tableして確認
・本番鯖DBには「ソースコードあげる前」にとっととテーブル作っておく(使われないだけだから、エラーは起こさないし)
DBの変更：カラムの追加
・開発鯖で確認
・ステージングでとっととalter tableして確認
・本番鯖DBには「ソースコードあげる前」にとっととカラム追加しておく(使われないだけだから、エラーは起こさないでしょ？)
DBの変更：INDEXの追加
・開発鯖で確認
・ステージングでとっととalter tableして確認
・本番鯖DBのもとっととalter
DBの変更：テーブル/カラムの削除
・まずそもそも、削除なんてそんなに頻繁にあるの？
・開発鯖で確認
・ステージングで確認
・本番鯖に、まず「修正後のコード」をデプロイする
・デプロイ後、問題がおきなければ、本番鯖DBのテーブルを消すなりカラムを消すなりする
基本はこんなところかなぁ、と。
これで「どうしてもにっちもさっちもいかない」ような状態は、とりあえずおいちゃんは経験ないのと、だから「比較的レアケースなんじゃないか？」って思うので。
レアケースなら、レアな時くらい「1時間程度のメンテナンス停止をかけて作業」でもいいんじゃないかなぁ？ っと。
「どうしてもにっちもさっちもいかない」が恒常的に発生するようなケースなら…むしろ話を聞いてみたいなぁ、と思います(笑
*1:開発用ELB、(作ってるんならステージング用のELB、)本番用のELB、あと「本番サーバテスト用ELB」を、それぞれ、こさえておきます。開発ELBは開発サーバに紐付けておきます。ステージング用ELBがある場合、ステージングサーバに紐付けておきます
