デプロイ戦略
- 4 分
DevOps プラクティスでは、多くの点で組織とエンド ユーザーにメリットをもたらす頻繁なリリース サイクルを使用します。 個々のデプロイは小さいため、迅速でストレスも少ないのですが、それでも問題が発生する可能性があります。 問題が発生する可能性を減らすには、組織のニーズに最も適したデプロイ戦略を採用する必要があります。
"ビッグバン" 戦略と呼ばれることもある "エピック デプロイ" のアプローチについては既に学習しました。 この方法は、最新のアプリケーションではうまく機能しないことがわかっています。 最新の運用のコンテキストでは、他にも人気のあるデプロイ戦略がいくつかあり、それぞれ状況に応じて長所と短所があります。
ローリング デプロイ戦略
ローリング デプロイ戦略では、新しいバージョンのコードの導入について、段階的なアプローチを採用しています。 新しいバージョンを、一定の期間にわたって段階的に採用し、新しいコードのインスタンスを徐々に増やしながら、同時に古いインスタンスを減らしていきます。 これは、古いインスタンスと新しいインスタンスが組織内で共存することを意味します。 たとえば、一度に 1 台のサーバー、仮想マシン、またはコンテナーでソフトウェアをアップグレードすることができます。
この戦略の利点は、運用環境で新しいコードを監視して、パフォーマンス、セキュリティ、信頼性、およびその他の標準を満たすことを確認してから、広範囲にデプロイできることです。
ブルーグリーン デプロイ戦略
ブルーグリーン デプロイ戦略では、互いに同一である 2 つの別々の環境を使用します。 1 つは新しいバージョンのソフトウェアを含むテスト環境で、もう 1 つは現在の運用環境です。 ソフトウェアが正常に動作し、標準を満たしていることを確認したら、現在の運用環境から新しい環境への完全な切り替えを実行して、そこですべての運用トラフィックを処理できるようにします。
ブルー環境は、現在の運用環境です。 グリーン環境は、それを完全に複製したものです。 最初に、新しいバージョンのソフトウェアをグリーン環境にデプロイします。次に、準備ができたら、アプリケーション トラフィックをブルー環境からグリーン環境にルーティングし、今度はグリーン環境が運用環境になります。
この戦略の利点は、ダウンタイムを発生させずに、切り替えをほぼ瞬時に行うことができることです。 また、グリーン環境を稼働させた後に問題が発生した場合は、ブルー環境に簡単に戻すことができます。
カナリア デプロイ戦略
カナリア デプロイ戦略は、ローリング デプロイのいくつかの要素をブルーグリーン デプロイの要素と組み合わせます。 切り替えを一度に行うのではなく、新しいバージョンを運用環境の限られた部分にデプロイし、すべてのトラフィックを新しいバージョンに徐々に移行します。 ソフトウェアは、適切に動作することが確認されるまで、限られた数のインスタンスまたはユーザーに対して段階的なステップでデプロイされ、その後で、インフラストラクチャの残りの部分にロールアウトされます。
この名前は、早期警告システムとして、石炭採掘所でカナリアを使っていたことに由来しています。 カナリア デプロイでは、自動テストを実行し、監視と分析を使用して、インスタンスまたはユーザーのサブセット内の新しいバージョンに関する問題の早期警告を受け取ることができます。 この方法では、運用環境全体は影響を受けません。
機能フラグ
機能フラグの考え方は、開発者の側でもう少し洗練された方法を必要とするもう 1 つの戦略です。 同じソフトウェアの古いバージョンと新しいバージョン (おそらく新機能が含まれている) の 2 つの異なるバージョンを使用するのではなく、古いソフトウェアと新しい変更 (機能など) の両方を含むソフトウェアのバージョンを送付します。 新しい変更は、既定では非アクティブになり、その変更の "機能フラグ" をオンにすることによってそのフラグをアクティブ化するまで表示されません。 このフラグには、構成ファイル内の行、コマンドライン引数、ソフトウェアが起動時に参照するオンライン サーバーからの特別な応答など、さまざまな形式があります。
このアプローチの強力な利点の 1 つは、問題が発生した場合に簡単にロールバックできること、または変更を簡単にゆっくりロールアウトできることです。 サーバーや顧客に新しいリリース (これらすべてのビットを含む) を送信する必要はなく、適切なフラグをオンまたはオフにして、ダウングレードまたはアップグレードするだけで済みます。
デプロイのベスト プラクティス
どのデプロイ戦略を使用するかにかかわらず、新しいソフトウェアまたは既存のソフトウェアの新しいバージョンをロールアウトする際に、リスクを最小限に抑えるのに役立ついくつかのベストプラクティスがあります。
Azure Pipelines などの適切なツールを使用して、継続的インテグレーションとデプロイ パイプラインを作成します。
自動テストを統合します。
通信チャネルを使用して、テストの結果を適切な当事者に通知します。つまり、デプロイが失敗した場合や問題が発生した場合にチームに通知します。
デプロイ後すぐに問題を監視します。
新しいバージョンのデプロイが正常性チェックに合格しなかったり正常に動作しない場合のロールバックを計画します。