デプロイ戦略

DevOps プラクティスでは、多くの点で組織とエンド ユーザーにメリットをもたらす頻繁なリリース サイクルを使用します。 個々のデプロイは小さいため、迅速でストレスも少ないのですが、それでも問題が発生する可能性があります。 問題が発生する可能性を減らすには、組織のニーズに最も適したデプロイ戦略を採用する必要があります。

"ビッグバン" 戦略と呼ばれることもある "エピック デプロイ" のアプローチについては既に学習しました。 この方法は、最新のアプリケーションではうまく機能しないことがわかっています。 最新の運用のコンテキストでは、他にも人気のあるデプロイ戦略がいくつかあり、それぞれ状況に応じて長所と短所があります。

ローリング デプロイ戦略

ローリング デプロイ戦略では、新しいバージョンのコードの導入について、段階的なアプローチを採用しています。 新しいバージョンは一定期間段階的に段階的に行われます。新しいコードのインスタンスは徐々に増加し、古いコードのインスタンスは減少します。 その結果、ロールアウト中に、古いインスタンスと新しいインスタンスがデプロイ ターゲット間で共存します。 たとえば、一度に 1 つのサーバー、仮想マシン、またはコンテナーでソフトウェアをアップグレードできます。

この戦略の利点は、運用環境で新しいコードを監視して、パフォーマンス、セキュリティ、信頼性、およびその他の標準を満たすことを確認してから、広範囲にデプロイできることです。

ブルー/グリーン展開の戦略

ブルーグリーンデプロイメント戦略では、2 つの異なる環境を使用します。それらは可能な限り類似した状態に保たれ、いずれも本番環境のトラフィックを処理できる能力を持っています。 1 つの環境で現在の運用負荷が処理され、もう 1 つの環境で新しいバージョンのソフトウェアがホストされるため、トラフィックをシフトする前に検証できます。 新しいバージョンが正常である場合は、一度にすべてのトラフィックを切り替えるか、結果を監視しながら新しい環境に移動するトラフィックの共有を徐々に増やすことができます。

青い環境は、現在運用トラフィックを提供している環境です。 緑の環境は、その並列に対応します。 最初に、新しいバージョンのソフトウェアを緑色に展開し、検証してから、運用環境のトラフィックを青から緑にルーティングします。 カットオーバー後、ロールは切り替えることができます。緑色はライブ環境になり、青は次のリリースに備えることができます。

この戦略の利点は、多くの場合、ダウンタイムをほとんどまたはまったく使用せず、すばやく切り替えることができることです。 また、新しい環境が稼働した後に問題が発生した場合は、トラフィックを以前の環境に戻すのも比較的簡単です。

カナリア デプロイ戦略

カナリア デプロイ戦略は、ローリング デプロイのいくつかの要素をブルーグリーン デプロイの要素と組み合わせます。 切り替えを一度に行うのではなく、新しいバージョンを運用環境の限られた部分にデプロイし、すべてのトラフィックを新しいバージョンに徐々に移行します。 ソフトウェアは、適切に動作することが確認されるまで、限られた数のインスタンスまたはユーザーに対して段階的なステップでデプロイされ、その後で、インフラストラクチャの残りの部分にロールアウトされます。

この名前は、早期警告システムとして、石炭採掘所でカナリアを使っていたことに由来しています。 カナリア デプロイでは、自動テストを実行し、監視と分析を使用して、インスタンスまたはユーザーのサブセット内の新しいバージョンに関する問題の早期警告を受け取ることができます。 この方法では、運用環境全体は影響を受けません。

機能フラグ

機能フラグの考え方は、開発者の側でもう少し洗練された方法を必要とするもう 1 つの戦略です。 同じソフトウェアの 2 つの異なるバージョン (古いバージョンと新しい機能を備えた新しいバージョン) を用意する代わりに、古い動作と新しい変更を含む 1 つのバージョンを出荷します。 新しい変更は既定では休止状態であり、対応する "機能フラグ" がアクティブになるまで表示されません。 フラグは、構成ファイル内の行、コマンドライン引数、リモート構成サービスから取得して実行時に評価される値など、多くの形式を取ることができます。

この方法の強い利点は、問題が発生した場合のロールバックの容易さと、緩やかに変化を展開しやすくなる点です。 多くの場合、機能を公開または非表示にするために新しいリリースを出荷する必要はありません。 適切なフラグをオフまたはオンにするだけで、実行中のアプリケーションが新しい設定に対応できるようになります。

Azureでは、Azure App Configuration の feature management 機能は、.NET、Java、Python、JavaScript、Go に対する SDK サポートを使用して、アプリケーションが実行時に読み取ることができるマネージド機能フラグ ストアを提供します。

リングベースのデプロイ

リングベースの展開は、MicrosoftおよびAzure内で広く使用される段階的ロールアウトの構造化された形式です。 新しいコードは、一連の "リング" にリリースされます。 たとえば、内部リングやドッグフード リング、早期導入者リング、広範なデプロイ リング、そして一般提供リングなどです。 各リングは前のリングよりも大きく、現在のリングからの正常性信号が定義された条件を満たした後にのみ、デプロイは次のリングに進みます。 リングベースのデプロイでは、カナリア デプロイの段階的な公開と、明示的な対象ユーザーおよびリング間の承認ゲートが組み合わせられます。

プログレッシブ配信

上記の戦略 (カナリア、リングベース、および機能フラグ) は、多くの場合、 段階的デリバリーという傘下にグループ化されます。 統一されたアイデアは、リリースが制御された方法で徐々に拡大する対象ユーザーに公開され、健全性およびビジネスメトリクスで監視され、それらのシグナルに基づいて自動的に進行またはロールバックされるということです。 プログレッシブ デリバリーは、個々の変更の爆発半径を制限するため、信頼性の高いクラウド サービスの既定のモデルとしてますます増加しています。

デプロイのベスト プラクティス

使用する展開戦略に関係なく、いくつかのベスト プラクティスは、新しいソフトウェアまたは既存のソフトウェアの新しいバージョンをロールアウトするときのリスクを最小限に抑えるのに役立ちます。

• 継続的インテグレーションとデプロイ パイプラインを作成するには、Azure PipelinesやGitHub Actionsなどの適切なツールを使用します。

• 自動テストを統合します。

• 通信チャネルを使用して、適切な当事者にテスト結果を通知します。 たとえば、デプロイが失敗したり、問題が発生したりしたときにチームにアラートを送信します。

• デプロイ後すぐに問題を監視します。

• 新しいバージョンが正常性チェックに合格しない場合や正常に動作しない場合は、ロールバックの計画を立てます。