いち早くユーザに価値を届ける。もしくは今ユーザが抱えている課題をいち早く解決することはとても重要でこのあたりをコアバリューにしているチームも多くあると思います。

そんな流れで継続的デリバリー、デプロイあたりが注目されていて（今更感）今回はCanary Releaseでshipした話をまとめておこうと思います。

ちなみにサーバサイドアプリケーション(rubyやpythonで作られたアプリケーション)またはミドルウェア系のリリースでは話がちょっと変わってくるので注意です。

今回はタイトルの通りミドルウェアを対象にしたCanary Releaseのお話です

サーバサイドアプリケーションではシンボリックリンクを使ったデプロイやBlue-Green Deploymentあたりの考えも似ていて一緒に考慮すべきなのかなぁと思ってみたり。

さて本題。前提として下記のようなシステム構成で話をします

構成

f:id:tsuyoshi_nakamura:20160916212221p:plain

構成の説明

基本的な監視アラートを一時的にOFF。メンテ作業するのでね。
アプリケーションサーバ群の1台のサーバをピックアップする（どれでもよい）今回は上記図の④を対象にした
ELBからサービスアウトさせてユーザからは参照できないようにする。サービスアウトさせる方法はコンソール画面でも、APIでもどちらでも
上記図の④のサーバに対してnginx_buildを活用してnginxのupgradeを実施 (Chef経由で実施した)
- nginx_build便利でした! github.com
リリース手順的なものを最初に作っていて、その手順に基づいた確認のコマンドとか打って確認する
良さげであれば④のサーバをELBにサービスインさせる
ELBはランドロビンなので1/4の確率で④のサーバがアクセスを受け付けるようになる
CloudwatchやZabbix,macherel,fluent経由のアプリケーションlogをkibanaからしばらく見てる
このモニタリングで何か通常とは違う数値が集計されると今回の作業が何かしらの影響を与えたことになるので注意深くみる
1. 問題があるようなら④のサーバにrollbackしてあげればよい
逆にこのモニタリングで通常どおりであると問題ないと判断ができるるので他のサーバ①~③のサーバに適用しても問題ない

今回は既存で動いているミドルウェアのupgradeで期待値が何も変化が無い事だったので比較的楽だった
「テスト環境でのテストはどうしても限界あるから、とりあえず本番リリースしちゃえば」という言葉がちょっと理解できてしまった....伝わるかな....
- 障害とか不具合ってどうしたって出るもんだから出すなら意図的？最小限に抑えて出してrollbackしてデバッグした方が全体的なスピードと品質に貢献するよねってゆう話かな
staging vs test-in-productionという言葉を思い出した
④だけを参照するELBを新たに作りELBのセキュリティポートでアクセス元を制御できればダークカナリアリリースも可能だなと思った。下記イメージ図
今回はDBは一つだったが別けてやってる事例も多く見かけた
新機能のアプリケーションのCanary Releaseとなるとまた考慮すべき点が多くありそうだな
- ELBのルーティンの課題
- 評価計測の課題
- アプリケーションでN%のユーザに利用できる機能といった感じでルーティンをする場合もあるっぽいね
何はともあれ実践を通して少しでも理解が深まって良かった。今後も活かしていきたいと思う