AWS
デプロイ

継続的デプロイ&ダウンタイムなしのデプロイのために

More than 3 years have passed since last update.

みなさん、デプロイしてますか!!

ロールバック失敗してないですか!!

ロールバックが失敗したとき冷や汗かきますよね。

さて、何気なくしているサーバーに対する新バージョンのアプリデプロイ。

どんな方法があるのでしょうか。

簡単にですが利用したことがある方法をまとめてみました。


サービス停止&デプロイ

最もシンプルですが駄目な奴です。

サービスを停止させないとデプロイできない悲しい方法。

アプリに必要なファイルを上書きしていたり配置している瞬間はサーバーが動作しないためです。


シンボリックリンク・デプロイ

CapistranoやFabricが有名かと思いますが、各サーバーに新しいアプリを配置してから一気にシンボリックリンクを書き換えていき、新しいアプリに向けさせる方法です。

ロールバックする場合は以前のシンボリックリンクに戻します。

たまにロールバックに失敗して悲しいことになることも。

Railsなどが流行ったときはこれが主流だったのではないでしょうか。


ローリング・デプロイ

1台ずつサーバーをロードバランサから切り離して、デプロイしデプロイが終わったらサーバーをロードバランサに戻す手法です。一時的とはいえ新旧のサーバが混在するため、そこは気をつける必要があります。

半数のサーバを切り離してからデプロイし、さらに半分をという事もあるようです。


Blue-Green Deployment(ブルーグリーン・デプロイ)

ブルーとグリーンという2つの環境を用意し、ブルーが動いているときグリーンにデプロイし、デプロイが終わったらブルーとグリーンを入れ替える方法です。

例えば、AWSのElastic BeanstalkがCNAMEをスワップさせることでこれを実現しています。

(2つの環境を用意し、URLを一瞬で入れ替える)

ロールバックする場合は、再度スワップします。

コストが2倍になるように聞こえますが、普段使ってない方の環境は縮退しておきます。


Immutable Infrastructure(イミュータブル・デプロイ)

ブルーグリーン・デプロイに近い(寧ろ、その仕組みを使うの)ですが、新バージョンでのアプリ環境を都度生成し、そちらに切り替えて使わなくなった環境は捨てるという手法です。

なぜイミュータブルなのかというと「運用中のサーバーに変更を加えない」というアプローチでサーバーを管理します。

基本的には都度新しいものを作っては捨てるという方法です。

DockerやAnsibleなどの構成管理ツールで環境の構築からデプロイ、入れ替え、破棄まで一括してやってしまうことが多いです。

どれも経験がありますが、やはり一番Immutable Infrastructureが安定しているようです。

常に真っ新な環境が立ち上がり、それに切り替わる訳ですから。