AzureでBlue-Green Deploymentを行う方法いくつか

メモ。

方法1 Application Gatewayとルーティングルール

Application Gatewayで受けてBlueとGreenのbackend poolを用意しておく。ルーティングルールを変更することで両者を切り替える。

backend poolにはそれぞれblue, green専用のinternalなロードバランサを指定する。指定せずに直接フロントエンドのApplication Gatewayのbackend poolに Blue / Green を担当するVM, IPを入れていっても良いが、そうするとフロントのApplication Gatewayにアタッチされていない系にリクエストを送ってテストすることが出来ない(出来なくはないがインスタンス指定になる)。

Application Gatewayに加えてblue, green両方のロードバランサが必要になるが、後述する方法で見られるような問題が無いのが利点

参考:
Blue-Green Deployment on Azure with Zero Downtime

方法2 Traffic Managerを使う

Traffic Manager を使用してリクエストの配送先を動的に変える。おそらくこれがもっとも採られている方法?公式ブログでもこの方法を紹介している。

Traffic ManagerはまさにBlue-Green Deploymentのようなことをするために使用する方法だ。ただひとつだけ引っかかる所があって、それはDNSベースで配送先を決めるという点。リクエストの配送先にウェイトを付けるという用途では何の問題もなく動作するが、デプロイした後で片方のインスタンスが止まってしまった場合でもそちらにクライアントがアクセスしてしまう可能性がある。DNSのTTLは任意の秒数に設定できるが、TTLが切れたからといってDNSに再問い合わせしてくれるとは限らないのが「DNSが浸透するのに時間がかかる」1の議論でもさんざん繰り返されたとおり。

たとえば、OkHttpなどはコネクションプールを持つので指し示すIPアドレスが変わっても追従してくれない。こういうのに考慮した設計をユーザーがしてくれるとは思えない。正直、自分だっていちいちこんなことに気を配らない。だから何かしらの問題は発生するだろうという懸念はある。

参考:
Blue-Green deployments using Azure Traffic Manager

方法3 API Managementを使う

API Managermentでリクエストを受けて配送先を動的に変える。これはTraffic Managerを使用したものに比べるとDNSベースではないので問題は発生し無さそうだが、API Managementという機能がそもそも配送先を動的に切り替えたいという用途のみで使うにはいささか重厚な感がある。だったら方法1で良いかな、という気がする。

参考: Blue-Green deployment on Azure Service Fabric

まとめ

普通に考えたら案1かな…。


  1. 「浸透と言うな」という意見もあるが、単に日本語の形容詞の使い方の問題だと個人的には思うのでひとまず放っておく