デプロイ パターンとは
"デプロイ パターン" は、新しいアプリケーション機能をユーザーにスムーズにロールアウトするための、自動化された方法です。 適切なデプロイ パターンを使用すると、ダウンタイムを最小限に抑える助けになります。 一部のパターンでは、新機能を段階的にロールアウトすることもできます。 その方法では、それらの機能をユーザー全員に提供する前に、選ばれたユーザーと共に新機能を検証できます。
このセクションでは、いくつかの一般的なデプロイ パターンについて学びます。 Tailspin チームが選択したパターンを実装するのに、Azure App Service がどのように役立つかも学習します。
朝の会議
Tailspin チームの士気は上々です。 彼らのパイプラインによってプロセスがスピードアップしました。 チームは、Web アプリとデータベースを統合できる開発環境を備えています。 Tim と Amita はどちらも、自分たちの仕事を簡略化する、自動化されたテストがあって満足しています。 一般的に、遅延とバグが減少する結果が得られています。
しかし、いつものように問題があります。 Tim が話しているチーム ミーティングを訪ねてみましょう。
Tim: 全員を満足させ続けるのはとても困難です。 Irwin は、新機能のリリースに時間がかかりすぎていると考えています。 管理者がリリースを承認するまで、私は何もすることができません。そして現時点では、彼らの承認後に機能をスムーズにロールアウトする方法がありません。 このプロセスは、長いだけでなく面倒です。 これは手作業なので、ダウンタイムがあります。 プロセス全体で 5 日間かかる場合があります。 長すぎることはわかっていますが、私はどうすればよいのでしょうか。 たぶん、もっとコーヒーを飲むだけで解決策を思い付くでしょう。
Andy:効果的な問題解決のためには、コーヒーが欠かせないのは間違いないね。
私は、われわれが必要としている解決策は、適切なデプロイ パターンだと思います。 デプロイ パターンは、一括移行を行うための自動化された方法です。 これは、ソフトウェアを、最終的な実稼働前ステージからライブの実稼働に移行する方法です。
適切なパターンを選択すれば、ダウンタイムを最小限に抑えるなど、確実に君たちの助けになります。 デプロイ パターンのもう 1 つの利点は、実稼働環境で実際に行う必要があるテストを実行する機会が得られることです。
Andy がホワイトボードに書き始めます。
検討する必要がある候補は以下のとおりです。
- ブルーグリーン デプロイ
- カナリア リリース
- フィーチャー トグル
- 非通知起動
- A/B テスト
- 段階的公開型デプロイ
各パターンについて簡単に説明しましょう。
ブルーグリーン デプロイ
"ブルーグリーン デプロイ" では、まったく同じ環境を 2 つ実行することでリスクとダウンタイムを軽減します。 これらの環境が、"ブルー" および "グリーン" と呼ばれます。 どの時点でも、いずれか 1 つの環境だけがライブになります。 ブルーグリーン デプロイでは、通常、トラフィック フローの制御に役立つルーターまたはロード バランサーが必要です。
ブルーがライブになっているとしましょう。 新しいリリースを準備するときに、グリーンの環境で最終的なテストを行います。 グリーン環境でソフトウェアが機能していれば、すべての受信要求がグリーン環境に行くようにルーターだけを切り替えます。
ブルーグリーン デプロイでは、ロールバックを行うためのすばやい手段も利用できます。 グリーン環境で何らかの問題が発生した場合は、ルーターを切り替えてブルー環境に戻すだけです。
カナリア リリース
"カナリア リリース" は、すべてのユーザーを問題にさらすことなく、潜在的な問題を早期に特定する方法です。 これは、ユーザー全員に新機能を提供する前に、少数の一部ユーザーにのみ公開するという考え方です。
カナリア リリースでは、機能をリリースしたときに何が起きるかを監視します。 リリースに問題がある場合は、修正プログラムを適用します。 カナリア リリースが安定していることがわかったら、それを実際の運用環境に移行します。
フィーチャー トグル
フィーチャー トグル では、実行時に "スイッチの反転" を行えるようになります。 ユーザーに新しい機能や変更された機能を公開することなく、新しいソフトウェアをデプロイできます。
このデプロイ パターンでは、Mara と私が、トグルの背後に新機能を構築します。 リリースが行われるときには、運用環境のソフトウェアに影響を与えないように、機能は "オフ" になっています。 トグルをどう構成するかに応じて、スイッチを "オン" に反転し、希望する方法でそれを公開することができます。
たとえば、最初に少数のユーザーに機能を公開して、彼らがどのように反応するかを確認することができます。 そのランダムなサンプルのユーザーに、この機能が表示されます。 または単に、ユーザー全員に対して機能がライブになるようにすることもできます。
しかし、このデプロイ パターンでは、他の誰よりも Mara と私がメリットを得る可能性があります。 ブランチが多くなりすぎないようにするのに役立つ点が、フィーチャー トグル パターンの大きなメリットです。 ブランチのマージは困難な場合があります。
非通知起動
"非通知起動 は、カナリア リリースや、フィーチャー トグルの切り替えと似ています。 非通知起動では、新機能をユーザー全員に公開するのではなく、少数のユーザーに機能をリリースします。
それらのユーザーは、私たちのために機能をテストしていることを知りません。 彼らに対する新機能の強調表示さえ行いません。 それが理由で、非通知起動と呼ばれます。 ソフトウェアは段階的に (さりげなく) ユーザーにリリースされるため、フィードバックを得てパフォーマンスをテストできます。
A/B テスト
"A/B テスト" では、Web ページまたはアプリの 2 つのバージョンを比較して、どちらのパフォーマンスが優れているかを判定します。 A/B テストは、古典的な実験のようなものです。
A/B テストでは、ランダムに、ページの 2 つ以上のバリエーションをユーザーに表示します。 次に、統計分析を使用して、目標に関してどちらのバリエーションのパフォーマンスが優れているかの結論を下します。
段階的公開型デプロイ
"段階的公開型デプロイ" は、"リングベース デプロイ" と呼ばれることもあります。 これは、変更が運用環境において有効であることを確認するのと同時に、変更がユーザーに与える影響を限定する別の方法です。
リングは、基本的にはカナリア ステージの拡張版です。 カナリア リリース自体は、効果を測定するためのステージにリリースされます。 別のリングを追加することは、基本的に同じ考え方です。
リングベース デプロイでは、最初に、リスクへの耐性がある顧客に変更をデプロイします。 その後は段階的に、より多くの顧客にロールアウトします。
ブルーグリーン デプロイの実装
Andy が Mara を見ています。
Andy: それは多いですね、分かっています。 それについて考える時間を少し取りたいですか。 それとも、あなたと私で...
Tim: ブルーグリーンで。
部屋の全員が笑います。
Mara: それってただのおしゃべりなの。
Tim: フィーチャー トグルでは、あなたと Andy が作業する方法を変更する必要があります。 一度に 1 つのことをやりましょう。 機能を段階的に公開する方法では、統計分析やフィーチャー トグルが必要になります。
ブルーグリーン デプロイは、私が制御できるやり方です。 ルーターを切り替えることは簡単です。 それは容易で、安全に思われます。 また、ブルーグリーン デプロイでは、管理者の評価対象となる環境があります。 OK が出れば容易に切り替えることができます。 そこから始めましょう。
それならば問題は、どのようにブルーグリーン デプロイをパイプラインに実装するかです。
デプロイ スロットとは何でしょうか。
Andy: 私たちは Azure App Service を使用しているため、"デプロイ スロット" を利用できます。 デプロイ スロットは、独自のホスト名を持つ実行中のアプリです。
Space Game Web サイトを、自動化されたパイプラインの一部として運用環境にデプロイする準備がまだできていないことは知っています。 しかしテストとして、ステージング環境にデプロイ スロットを追加できます。
ロード バランサーやルーターを設定する代わりに、既存の "ステージング" 環境で使用している App Service インスタンスに 2 番目のスロットを追加するだけで済みます。 プライマリ スロットを "ブルー"、セカンダリ スロットを "グリーン" と呼べます。
このようにして、まったくダウンタイムなしで新機能をデプロイできます。 2 つのデプロイ スロット間でアプリケーションとその構成をスワップします。 基本的に、2 つのスロットの IP アドレスをスワップすることになります。
Tim: それはいいですね。 ブルーグリーン デプロイのこのバリエーションは、"ダウンタイムなしのデプロイ" と呼んだらどうでしょう。
Andy: すばらしい。 このデプロイ パターンの実装は、Tim と私が取り組みます。 後日全員で会って、結果を確認できます。
機能フラグの使用についての推奨事項
機能フラグは、チームが検討したリリース周期手法の 1 つでした。 チームは機能フラグを使用しないと決めましたが、多くの人がこれらのフラグは有用であると認めてきました。 このセクションでは、機能フラグの詳細について説明します。
"機能フラグ" は、"フィーチャー トグル" と呼ばれることもあり、コードを変更することなくシステムの動作方法を変更することができます。 これらのフラグを使用すると、新しいコードを中央の開発用ブランチにプッシュし、コードがデプロイされるようにできますが、必ずしも機能するとは限りません。 フラグは、一般に、条件付きのロジックを制御する変数の値として実装されます。
チームが銀行アプリケーションの中央の開発用ブランチで作業中であるとします。 後の面倒なマージ操作を回避するため、メイン ブランチですべての作業を行うと決定しました。 しかし、問題があります。 金利計算を大幅に変更しようとしており、毎日そのコードに頼っている人たちがいます。 一層悪いことに、変更が完了するまで数週間かかる予定です。 それほど長い間、メイン コードを使用不能にしておくことはできません。
このシナリオでは、機能フラグが適切なソリューションとなる可能性があります。 機能フラグが設定されていないユーザーが、対象となっている元の金利計算コードを使い続けられるようにコードを変更できます。 一方、チームには機能フラグが設定されるので、チームは変更しようとしているコードを参照することができます。
もう 1 つの種類の機能フラグは、"リリース フラグ" です。 対象となっている計算コードの作業完了後、一般にリリースする前にコードを試してみようと考えているとします。 新しいコードと、考えられるいかなる問題にも十分対処できる立場にいるユーザーのグループがあります。 まず、彼らに機能を試してもらいます。 彼らに機能フラグが設定されて、新しいコードをテストできるように、あなたが構成を変更します。 問題が発生した場合は、あなたがすぐにフラグを無効にできます。