gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

サーバ系ツールに関する雑感(実践変)

いろいろあると思うのですが。おいちゃんの想定している運用は…多分、 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」から、開発用のサーバ、いるんならステージングサーバ(おいちゃんはよく、開発用サーバに共存させちゃう)、本番用のサーバ(とりあえず1台を仮定)をそれぞれ作成
・ELBを適切に紐付けます*1。本番サーバは、一旦「本番サーバテスト用ELB」に紐付けておきます
・開発サーバで適宜開発が進んでいる、と仮定します
・適当なタイミングで、一旦「これをデプロイしませう」なブランチなりなんなりを、ステージングサーバに持ち上げます。具体的には、おいちゃんは「ステージングサーバで、masterなりdevelopなりdeployなり、適切なブランチを git pull する」程度
・ステージングで適宜確認
・本番サーバにデプロイ。おいちゃんは「あらかじめ用意してあるrsync叩く」程度。このタイミングで、本番サーバは「本番サーバテスト用ELB」と紐づいている
・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する
・本番サーバのインスタンスを「本番サーバテスト用ELB」からはずして「本番用のELB」につなげる

以降のプログラムソースのデプロイ(開発中も、本番時も)

・とりあえず1台、AMIから新しく鯖インスタンスを作成 → 新鯖
・「新鯖」に、ステージングのソースを一式デプロイする
・新鯖を「本番サーバテスト用ELB」に紐付ける
・「本番サーバテスト用ELB」のドメインにアクセスをして、ちゃんとデプロイできていることを確認する
・新鯖をcopyして、「現在、本番用のELBにぶら下がってる鯖と同じ数の新しい鯖(理由があるならインスタンス数を増減させてももちろんOK)」を作成する。これを「新鯖群」と呼称
if(ELB的なものの「接続ドメイン」がスイッチできるのなら) {
 ・「本番用のELB」と「本番サーバテスト用ELB」のドメインをスイッチ(スワップ)する
} else(スイッチできないのなら) {
 // 幾分スピード勝負なんで、バッチ的なもので処理をするとよりよいように思います
 ・新鯖群を一通り「本番用のELB」に紐付ける
 ・旧鯖群を全部、一気にはずす
 ・新鯖群を「本番サーバテスト用ELB」からはずす:ここは落ち着いて、少々タイムラグがあってもよし
}
・不安なら、旧鯖群の1台を、AMIとかでスナップショットっておく
・1時間くらい様子をみて、問題なさそうなら、旧鯖群のインスタンスを全部削除する

daemon等のupdate

・新しいAMIつくる。「0から作る」でもいいんだけど、既存最新のAMIから作ったほうがいろいろと楽
・新しいAMIから新しい鯖インスタンスを作成、開発環境で使って「問題ない」事を確認する
 →あたらしいAMI作る
 →あたらしいAMIからインスタンスを1つ作る
 →開発を一旦停止、ソースは全部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がある場合、ステージングサーバに紐付けておきます