SIOS Tech. Lab | エンジニアのタメになるOSS・クラウド・認証の技術トピックス 
こんにちは、サイオステクノロジー武井です。今回はAzure App ServiceやWeb App for Containersで実施可能な色々なデプロイ方法についてお話したいと思います。
目次
色んなデプロイ方法
ここで主なデプロイ方法をまとめてみます。
In-Placeデプロイ
既存の環境に新しアプリをエイヤとデプロイする手法です。旧来から用いられている伝統的な手法かと思います。
最もシンプルな方法で、後に紹介する他のデプロイ方法と違って、他のマシンなどのリソースを用意する必要はありませんが、ダウンタイムは発生することがあります。
Blue-Greenデプロイ
現在動いている環境(旧環境)とは別に、新たにリリースする別の環境(新環境)を用意して、DNSのレコード切り替え等により、旧環境から新環境にエイヤと切り替える手法です。
ダウンタイムほぼゼロですが、旧環境と新環境の2つのリソースを用意しなければならないので、ちょっと費用がかさみます(´・ω・｀)
カナリアデプロイ
現在動いている環境(旧環境)とは別に、新たにリリースする別の環境(新環境)を用意して、旧環境に振られているリクエストを徐々に少しずつ新環境に割り振っていく手法です。一気にエイヤで新環境に切り替えると、もし万が一新環境に切り替えたときに、その影響が大きいです。この手法では、少しずつ新環境に切り替えていくので、影響を最小限に食い止めることができます。
メリデリ
先に紹介したデプロイ方法のメリデリをまとめてみました。
| デプロイ方法 | ユーザー影響 | コスト | 切り戻し |
| In-Placeデプロイ | ☓ | ◯ | ☓ |
| アプリの設計にもよるが、単なる入れ替えなのでサービスが停止することが多い。 | 既存のサーバーに対するアプリの入れ替えなので、他のサーバーを用意しなくていい。 | もう一度同じアプリを上書きしなければいけないので、切り戻し大変。 | |
| Blue-Greenデプロイ | ◯ | ☓ | ◯ |
| 旧アプリから新アプリへの切り替えはロードバランサーやDNSの変更だけなので、ほとんど影響なし。 | 新旧両方のサーバーを用意しなければならないので、コストがかかる。 | DNSやロードバランサーを変更するだけで旧サーバーにリクエストが行き切り戻しできるのでラクチン。 | |
| カナリアデプロイ | ◯ | ☓ | ◯ |
| 旧アプリから新アプリへの切り替えはロードバランサーやDNSの変更だけなので、ほとんど影響なし。 | 新旧両方のサーバーを用意しなければならないので、コストがかかる。 | DNSやロードバランサーを変更するだけで旧サーバーにリクエストが行き切り戻しできるのでラクチン。 |
やってみよう！！
Azureで提供されているサービスである「Azure App Service」(アプリケーション実行基盤のPaaS)やWeb App for Containers(コンテナ実行基盤のPaaS)には、Blue-Greenデプロイやカナリアリリースができる機能が既にあります。
Blue-Greenデプロイ
まずはBlue-Greenデプロイを試してみます。すでにブラウザに「hoge」と表示するアプリがリリースされているとします。これを「fuga」と表示されるアプリにBlue-Greenデプロイでリリースするというのが今回のユースケースです。
今はこんな感じになっています。App Serviceプランの中に「スロット」というのがあり、その中にさらにApp Service本体があります。今、下図にあるのが「本番用スロット」で、エンドユーザーはここにアクセスしています。ここに、ステージング環境用のスロットを一つ追加して、その中にステージング用のApp Serviceを作成し、それらを入れ替えることでリリースを行います。言葉だけで説明するとちょっとわかりにくいので、これから図もふんだんに交えて説明します。
App Service(もしくはWeb App for Containers)の管理画面にアクセスして、左部メニューの「デプロイスロット」をクリックします。すでにbluegreentestスロットというのが出来上がっています。この名前はApp Service名とイコールです。ここに新しいスロットを追加しましょう。「+スロットの追加」をクリックします。
「名前」に任意の名称を入力します。「次から設定を複製」はどっちでもいいです。
以下の画面のように「bluegreentest-stg」というスロットが出来上がっていると思います。
ちょうどイメージにすると、現在は以下のような状態になります。bluegreentest-stgというスロットが作成されて、その中にbluegreentestというスロット内のApp Serviceが複製されています。以下の図を見るとわかると思いますが、スロットはすべて同じApp Serviceプランの中に作成されます。
先程のスロットの一覧の画面で、bluegreentest-stgをクリックすると、bluegreentest-stgスロット内のApp Serviceの設定画面に移ります。ここで、システム管理者はfugaと表示するアプリをデプロイします。App ServiceとWeb App for Containersでその方法は違うかと思いますが、その説明についてはここでは割愛させて頂きます。
そして以下のような状態になりました。先程作成した新しいスロット(bluegreentest-stg)には、fugaと表示される新しいアプリがあります。実際にユーザーがアクセスしているのは、bluegreentestスロットにある旧アプリです。bluegreentest-stgスロットにある新アプリにはまだリクエストが来ていないので、システム管理者は安全に新アプリをテストすることができます。
そして、ここからがBlue-Greenデプロイの実行なのですが、旧アプリ(hoge)と新アプリ(fuga)を入れ替えます。先程のスロット一覧画面にアクセスして、「スワップ」をクリックします。
「ソース」にスワップ元のスロット、「ターゲット」にスワップ先のスロットを選択します。「運用」と表示されているスロットは、実際にエンドユーザーがアクセスしている本番のスロットになります。最後に「スワップ」をクリックします。しばらくすると完了します。
見た目にはわかりませんが、スワップされています。試しにbluegreentestのスロットにあるApp Serviceにアクセスしたら「fuga」と表示されるはずです。
これでBlue-Greenデプロイは完了です。ちなみにスワップ中にスワップ元にリクエストがあった場合、そのリクエストの終了を待ってスワップが行われます。ただし、あまりにもそのリクエストの処理時間が長いと、ブツっと中断されてスワップが始まってしまうそうです。
カナリアデプロイ
次にカナリアデプロイです。新アプリにだけ全体のアクセスの20%を向けるということをやっみたいと思います。
現在、先程作成したbluegreentest-stgに新アプリが適用済みで、エンドユーザーのアクセスは旧アプリに向いているものとします。App Serviceのポータルで見ると以下のような状態です。
イメージにすると以下のような感じですね。
この状態から、新アプリにだけ全体のアクセスの20%を向けるということをやっみたいと思います。デプロイスロットの一覧画面で、以下のようにbluegreentest-stgのスロットの「トラフィック」を20にして「保存」をクリックします。
以下のようなイメージの状態になりました。
ブラウザから、bluegreentestスロット(運用スロット)のURLにアクセスすると適宜リクエストが振り分けられるのが確認できると思いきや、ちょっとそうは行きません。というのは、実際は、最初のアクセスのときにx-ms-routing-nameという名前のCookieが発行されてその値がselfの場合には運用スロット、stagingの場合には運用スロット以外(以降、ステージングスロットと呼びます)に固定でアクセスされるようになります。つまり、今の状態(運用スロット：ステージングスロット＝80%：20%)とすると、x-ms-routing-nameという名前のstagingという値のCookieが発行される確立が20%という感じになります。
なので、もし同じ端末から動作確認をする場合には、プライベートブラウズにしたりCookie消したりして何度もアクセスしないと、その効果がわかりません。
引き継がれる設定と引き継がれない設定
設定が引き継がれるタイミングは2つあります。
- 新規にスロットを作成したときに、親のスロットから引き継がれる
- スロットをスワップしたときに引き継がれる
全部説明していますと、ちょっとキリがないので、代表的なものを上げて留意点をご説明したいと思います。
バックアップ
App ServiceやWeb App for Containersには、その中のファイルをバックアップする機能があります。以下のように設定します。
スロットを新規作成した場合
さて、この設定がしてあるスロットを元に、新規スロットを作成した場合はどうなるでしょか？ちなみに今の状態はイメージにすると以下のような感じです。
ではスロットを作成してみます。その際、忘れずに「次から設定を複製」で複製元のスロットを選択して下さい。
複製したスロットを見てみます。複製されていませんね。バックアップを取りたいのはだいたい運用スロットのみだと思うので、妥当な動作かなと思います。
イメージとしてはこんな感じですね。
スロットをスワップした場合
スワップして見てみましょう。まずは運用スロットから。なるほど、スワップしても運用スロットの設定は変わらないですね。
次はステージングスロットです。ステージングスロットも変わらずバックアップされない設定になっていますね。
つまりイメージにすると以下のような感じなのですが、たしかにスワップしたときにバックアップの設定もスワップされてしまうと、今までバックアップを取っていた運用スロットがスワップ後にバックアップ取られなくなったとかなると、もう大騒ぎです(汗)
アクセス制限
App ServiceやWeb App for Containersには、IPアドレスでアクセス制限をできます。
スロットを新規作成した場合
以下のような制限を設定していた場合に、スロットを新規作成した場合を見ていきましょう。スロットの新規作成方法は先程と同じ手順です。
今のイメージはこんな感じです。
ではスロットを新規作成して、複製されたスロットを見てみましょう。まずは運用スロットからですが、設定が複製されています。
つまりこういう状態ですね。なるほどです。
スロットをスワップした場合
次はスロットをスワップした場合です。両方のスロットとも同じ設定が入っていて、この状態でスワップしても差がわからないので、運用スロットの設定を削除して以下のような状態にしてみます。
ではスロットをスワップしてみて、運用スロットの方から見てみましょう。うん、アクセス制限設定なしですね。
ステージングスロットは先程と変わらずアクセス制限設定ありです。
つまり変わらずこういう状態です。そらそうですよね。例えば、ステージングスロットのみに施していたアクセス制限が運用スロットに反映されてしまったら、いきなりアクセスできなくなるユーザーがたくさん出て大騒ぎになります。
つまり、今まで出した例は、まぁ妥当な動作かもしれませんが、設定によっては想定外のものが引き継がれたり、もしくは引き継がれなかったりすることもあるかもしれません。
なので、特にスワップする際は、運用スロットに影響がないか十分な注意が必要になります。
ちなみに、どういった設定がスワップされたりされなかったりするかは、以下のMS公式ドキュメントに記載があります。
https://docs.microsoft.com/ja-jp/azure/app-service/deploy-staging-slots#which-settings-are-swapped
まとめ
Azure App ServiceやWeb App for ContainersにはBlue-Greenデプロイやカナリアデプロイなど様々なデプロイ方法があります。これらを活用すればとても簡単に、しかもユーザー影響なく確実にリリースできますので、ぜひご活用下さいませ！！
Be the first to comment