テクノロジー DEVOPS 非公開: Blue-Green デプロイメントと Canary デプロイメント: 主な違い

Blue-Green デプロイメントと Canary デプロイメント: 主な違い

ソフトウェア配信の展開フェーズは、今日のソフトウェア開発において重要な役割を果たしており、クラウド環境ではさらに重要です。

それにもかかわらず、これは最も過小評価されている配信フェーズの 1 つでもあります。通常、企業は展開の高速化、信頼性の向上、自動化などに十分な時間とエネルギーを投資しません。

ほとんどの場合、依然としてさまざまな形式の手動導入手順が見られます。少なくとも適切に文書化された手順チェックリストがあれば、より良いケースが得られます。最悪の場合は、最後の数分間で即興で作成されたランダムな計画だけになります。

自動展開手順は常に遠い目標であり、短期から中期のロードマップの代替品ですが、そこに至るまでの実際の道はでこぼこで予測不可能です。ただし、完全に自動化された信頼性の高い展開手順を実行することが、長期的に大幅なコスト削減の鍵となります。これにより、開発チームのほとんどが通常、各実稼働リリースのデプロイに費やす労力を削減できます。

Canary および Blue-Green の展開戦略は、これらすべての利点を活用し、さらに高可用性、高速なインストールとロールバックのプロセスを追加します。チームがさらに頻繁に、眠れない夜を過ごすことなくリリースできるようになります。それらが何をもたらし、どのように異なるのかを見てみましょう。

Blue-Green デプロイメントと Canary デプロイメント: 主な違い
Blue-Green デプロイメントと Canary デプロイメント: 主な違い

Blue-Green 導入: 概要

出典: cncf.io
プロジェクトのさまざまな段階を示す図。
プロジェクトのさまざまな段階を示す図。

Blue-Green 導入では、アクティブ (青) と非アクティブ (緑) の 2 つの同一の環境を作成することで、ダウンタイムと新しいソフトウェア バージョンのリスクを軽減します。

アクティブ環境とは、ソフトウェアの現在のバージョンが実行されており、ユーザーが運用トラフィックを生成している環境です。非アクティブな環境では、ソフトウェアの新しいバージョンが展開され、テストされます。

新しいバージョンがテストされ準備が完了すると、トラフィックはアクティブ環境から非アクティブ環境に切り替えられ、それが新しいアクティブ環境になります。必要に応じてこのプロセスを繰り返すことができます。

こちらもお読みください: Blue-Green デプロイメントと DevOps におけるその役割の説明

主な機能と利点

Blue-Green 導入プロセスの具体的な機能は次のとおりです。

  • 2 つの同一の環境は、データとプロセスの観点からは同一です。青色 (アクティブ) 環境は、運用ユーザーが日常のプロセスを実行する場所です。緑色 (非アクティブ) の環境は新しい展開がインストールされ、常に青色の環境と同期されます。
  • アクティブ環境から非アクティブ環境にトラフィックを切り替えて、新しいアクティブ環境にすることができます。切り替えは瞬時です。導入はすべて過去のものになりました。ダウンタイム枠はありません。ユーザーは新しい環境にアクセスするために何もする必要はありません。
  • 問題が発生した場合には、迅速なロールバックが必要になります。これにより、ソフトウェアの新しいバージョンで問題が発生した場合でもダウンタイムが最小限に抑えられ、アプリケーションの可用性が維持されます。
  • 自動テストは、Blue-Green 導入の重要な側面です。これにより、ソフトウェアの新しいバージョンがアクティブな環境に展開される前に徹底的にテストされるようになります。
  • この展開は継続的デリバリー パイプラインの一部であり、最終的にはソフトウェアの実稼働環境へのリリースがより速く、より頻繁になることを意味します。導入はすでに完了しており、トラフィックの切り替え自体を実行するだけでよいため、これを毎日行うことができるほど高速です。あなたがテスト活動を迅速に行っていると仮定します。

カナリア展開: 概要

出典: cncf.io
プロジェクトのさまざまな段階を示す図。
プロジェクトのさまざまな段階を示す図。

カナリア展開では、ユーザー ベース全体に展開する前に、一部のユーザーに対して新機能や更新の段階的なリリースを実行します。

このアプローチには、ソフトウェアの新しいバージョンを作成して小規模なグループに展開し、残りのユーザーに対して古いバージョンを実行し続けることが含まれます。開発チームは、新しいバージョンが安定しており、期待どおりに動作することを確認するために注意深く監視しています。

すべてがうまくいけば、新しいバージョンはより多くのユーザーに展開され、最終的にはユーザー ベース全体に到達します。このようにして、プロジェクト チームは、すべてのユーザーに一度に影響を与える可能性のあるバグやその他の問題が発生するリスクを最小限に抑えます。

目的は、大規模なユーザー ベースに新機能を導入するリスクを軽減することです。したがって、新しいバージョンへの移行がよりスムーズに行われます。

こちらもお読みください: Canary デプロイメントと DevOps におけるその役割の説明

主な機能と利点

以下は、Canary デプロイメント プロセスの固有の機能です。

  • 新しいバージョンを最初は少数のユーザーに展開し、その後、時間をかけて徐々により多くのユーザーに展開します。すべてのユーザーに一度に影響を与える可能性のあるバグやその他の問題が発生するリスクを最小限に抑えます。
  • 新しいバージョンを注意深く監視して、安定しており、期待どおりに動作していることを確認します。開発者は新しいバージョンに関するフィードバックをより迅速に受け取ることができるため、ユーザー ベース全体に展開する前に必要な調整を行うことができます。
  • 問題が発生した場合は、デプロイメントを以前のバージョンに迅速かつ簡単にロールバックできます。これにより、ユーザー エクスペリエンスに影響を与える可能性のある問題が発生するリスクが軽減されるため、展開プロセスにおける開発者や関係者の信頼が高まります。
  • 人的エラーのリスクを軽減するために、展開プロセスを可能な限り自動化します。

概要: Blue-Green デプロイメントと Canary デプロイメント

特徴 ブルーグリーン展開 カナリア展開
データ同期 ブルー環境とグリーン環境の間での継続的なデータ同期。 ユーザーまたはサーバーのサブセットが新しいバージョンを受け取ります。残りは現在のバージョンで続行します。
アクティベーションプロセス 新しいバージョンの準備ができたら、アクティブ環境から非アクティブ環境に切り替えます。 新しいバージョンを積極的にテストするユーザーの定義されたサブセットに段階的にロールアウトします。
本番環境のユーザーエクスペリエンス 生産のダウンタイムはありません。アクティブな環境間のシームレスな切り替え。 運用ユーザーの一部は新しいバージョンを積極的にテストします。このグループの潜在的な問題。
高可用性とフィードバック速度の比較 高可用性を優先します。 より迅速なフィードバックと制御されたロールアウトを優先します。
リスクの軽減 一部のユーザーに段階的にリリースすることで、問題の可能性を低減します。 主に非アクティブな環境でテストします。テスターは現実世界の問題をすべて把握できるわけではありません。
テストアプローチ 主に非アクティブな環境でテストします。テスターは現実世界の問題をすべて把握できるわけではありません。 実稼働ユーザーはテスターとして機能し、現実の問題を早期に発見します。
注目すべき使用例 Netflix、Amazon、Etsy、LinkedIn、IBM はブルーグリーンを使用しています。 Netflix と Google は、自動テストと段階的なロールアウトとともに Canary を使用しています。

Blue-Green デプロイメントと Canary デプロイメント: 機能

導入

ブルーグリーン展開とは、2 つの環境 (ブルーとグリーン) を意味します。しかし同時に、2 つの環境はデータに関して常に同期されています。これにより、2 つの環境間での永続的なデータ同期プロセスの需要が増加します。

新しいバージョンがテストされ、準備ができているとみなされると、トラフィックがアクティブ環境から非アクティブ環境に切り替えられ、それが新しいアクティブ環境になります。

新しいコードのデプロイに時間を費やす必要はなく、本番環境のダウンタイムも発生しません。すべての実稼働ユーザーは、現在アクティブな環境で常に作業しており、切り替えにさえ気づきません。

出典: aws.amazon.com
アマゾンの csc がどのように機能するかを示す図。
アマゾンの csc がどのように機能するかを示す図。

カナリア展開では、ほとんどのユーザーまたはサーバーが現在のバージョンを使用し続ける一方で、ソフトウェアの新しいバージョンを少数のユーザーに展開することが含まれます。これは完全な切り替えではなく、段階的な展開です。この場合、テスターは、定義されたサブセットにすぎませんが、直接の運用ユーザーです。このグループは実稼働プロセスで新しいバージョンを積極的にテストしており、最終的に安定すると、新しいバージョンは残りのユーザーに普及します。

高可用性が優先される場合は、Blue-Green デプロイメントを選択してください。より迅速なフィードバックとより制御された (ただし遅い) ロールアウトを希望する場合は、カナリア デプロイメントを優先できます。

リスク差の軽減

Blue-Green デプロイメントでは、安定した以前のバージョンにすぐに切り替えることで、リリース失敗のリスクが軽減されます。すべてのユーザーに、そして即座に。明らかに、ロールバックの場合にユーザーへの新機能の提供が遅れるリスクは依然としてありますが、少なくとも、新しいリリースによるいくつかの重大な問題によってブロックされるユーザーは一人もいません。

カナリア展開のリスク軽減戦略は、問題の可能性を段階的に減らすことにあります。新機能は運用ユーザーのサブグループにリリースされるため、リリースがすべてのユーザーに配布される前に、ユーザーはすでにそのソフトウェア バージョンを使用しています。初期ユーザーがそのような問題をすぐに発見する可能性は非常に高くなります。

テストアプローチの違い

Blue-Green デプロイメントでは、テスト プロセスは非アクティブな環境のみに残ります。ここでは、開発者、テスター、さまざまな関係者が望むものを何でもテストできます。テストがアクティブな運用環境で直接実行されているかのように、常に同様の動作が期待できます (データと構成が 2 つの環境間で常に同期されているため)。

したがって、テスターはテスト ショーを実行していますが、実際の運用ユーザーが行うであろうすべての問題を検出できない可能性がまだあります。ただし、非アクティブな環境とアクティブな環境の間の切り替えは常に迅速であるため、これは実際には問題ではありません。その後、開発者に問題を修正してもらい、再度切り替えることができます。

出典: IBM.com
ビジネスプロセスのプロセスを示す図。
ビジネスプロセスのプロセスを示す図。

Canary デプロイメントでは、実稼働ユーザーをテスターとして使用できます。このようなユーザーは通常、より短時間でより多くの問題を発見する傾向があります。日々のビジネス プロセスを完全なエンドツーエンドで実行するだけです。

そのようなテストシナリオやケースを構築したからというだけでなく、とにかくそれを実行しなければならないからです。グループのメンバーがしばらくの間、深刻な問題を抱えてしまう危険性があります。しかし、大多数のユーザーには影響がなく、開発チームは現実世界の最も深刻な問題にすぐに集中できます。

経験と使用例

このようなデプロイメントがすでに正常に実行されている既知のユースケースのいくつかを以下に示します。

  • Netflix は、Blue-Green 導入を使用して、ストリーミング サービスの新しいバージョンを導入します。
  • Amazon と Etsy は、Blue-Green デプロイメントを使用して、e コマース プラットフォームの新しいバージョンをデプロイします。
  • LinkedIn は、Blue-Green デプロイメントを使用して、ソーシャル ネットワーキング プラットフォームの新しいバージョンをデプロイします。
  • IBM は、Blue-Green デプロイメントを使用して、クラウド プラットフォームの新しいバージョンをデプロイします。
  • Netflix は、Canary Deployment を使用して、ストリーミング サービスへの変更をロールアウトします。同社は、自動テスト、機能フラグ、A/B テストを組み合わせて、変更をゆっくり展開しています。
  • Google は Canary Deployment を使用して、クラウド サービスへの変更をロールアウトします。同様に、同社は自動テスト、トラフィック分割、監視の組み込みの利点を利用して、変更をすべてのユーザーに展開する前に、一部のユーザーに段階的に展開しています。

自動化が鍵であり、DevOps パイプラインは間違いなくデプロイメント プロセスの未来です。これらは、次のようなステップを含む完全に自動化されたプロセスです。

  • サービス、データ、ユーザー、権限に関するターゲット環境の作成または更新。
  • コード リポジトリから直接ソース コードのフル/デルタ バージョンを自動展開します。
  • データベース スキーマのアップグレードとデータの更新。
  • 導入アクティビティ中に直接テストを自動実行します。
  • 重要なテスト ケースが正常に完了しなかった場合の自動ロールバック プロセス。
  • 手動介入ステップをゼロにします。

このようなデプロイメント パイプラインを作成したら、Canary プロセスや Blue-Green プロセス、あるいはその他の任意のプロセスを接続できます。これらは、すでにうまく機能することが証明されている 2 つの例にすぎません。しかし、これらは展開活動に関するほとんどの問題を解決するための哲学的な枠組みにすぎません。時間の経過とともにそれらを切り替えたり、両方を組み合わせて使用​​したりすることも難しくありません。

最後の言葉

手動の導入手順に固執することは、成熟していない開発プロセス、さらにはチームの目に見えます。あるいは、特定の企業がソフトウェア配信に関していかに柔軟性に欠け、一枚岩であるかを暴露する可能性もあります。どちらの場合も、現状を修正するには多大な労力がかかります。したがって、上記の展開戦略をプロジェクトに実装してみてください。

次に、Kubernetes にアプリケーションをデプロイする方法を確認してください。

「 Blue-Green デプロイメントと Canary デプロイメント: 主な違い」についてわかりやすく解説!絶対に観るべきベスト2動画

【Official】 Red & Blue, Green & White / JiLL-Decoy association (ジルデコ)
Blue In Green

ソフトウェア配信の展開フェーズは、今日のソフトウェア開発において重要な役割を果たしており、クラウド環境ではさらに重要です。

それにもかかわらず、これは最も過小評価されている配信フェーズの 1 つでもあります。通常、企業は展開の高速化、信頼性の向上、自動化などに十分な時間とエネルギーを投資しません。

ほとんどの場合、依然としてさまざまな形式の手動導入手順が見られます。少なくとも適切に文書化された手順チェックリストがあれば、より良いケースが得られます。最悪の場合は、最後の数分間で即興で作成されたランダムな計画だけになります。

自動展開手順は常に遠い目標であり、短期から中期のロードマップの代替品ですが、そこに至るまでの実際の道はでこぼこで予測不可能です。ただし、完全に自動化された信頼性の高い展開手順を実行することが、長期的に大幅なコスト削減の鍵となります。これにより、開発チームのほとんどが通常、各実稼働リリースのデプロイに費やす労力を削減できます。

Canary および Blue-Green の展開戦略は、これらすべての利点を活用し、さらに高可用性、高速なインストールとロールバックのプロセスを追加します。チームがさらに頻繁に、眠れない夜を過ごすことなくリリースできるようになります。それらが何をもたらし、どのように異なるのかを見てみましょう。

Blue-Green デプロイメントと Canary デプロイメント: 主な違い
Blue-Green デプロイメントと Canary デプロイメント: 主な違い

Blue-Green 導入: 概要

出典: cncf.io
プロジェクトのさまざまな段階を示す図。
プロジェクトのさまざまな段階を示す図。

Blue-Green 導入では、アクティブ (青) と非アクティブ (緑) の 2 つの同一の環境を作成することで、ダウンタイムと新しいソフトウェア バージョンのリスクを軽減します。

アクティブ環境とは、ソフトウェアの現在のバージョンが実行されており、ユーザーが運用トラフィックを生成している環境です。非アクティブな環境では、ソフトウェアの新しいバージョンが展開され、テストされます。

新しいバージョンがテストされ準備が完了すると、トラフィックはアクティブ環境から非アクティブ環境に切り替えられ、それが新しいアクティブ環境になります。必要に応じてこのプロセスを繰り返すことができます。

こちらもお読みください: Blue-Green デプロイメントと DevOps におけるその役割の説明

主な機能と利点

Blue-Green 導入プロセスの具体的な機能は次のとおりです。

  • 2 つの同一の環境は、データとプロセスの観点からは同一です。青色 (アクティブ) 環境は、運用ユーザーが日常のプロセスを実行する場所です。緑色 (非アクティブ) の環境は新しい展開がインストールされ、常に青色の環境と同期されます。
  • アクティブ環境から非アクティブ環境にトラフィックを切り替えて、新しいアクティブ環境にすることができます。切り替えは瞬時です。導入はすべて過去のものになりました。ダウンタイム枠はありません。ユーザーは新しい環境にアクセスするために何もする必要はありません。
  • 問題が発生した場合には、迅速なロールバックが必要になります。これにより、ソフトウェアの新しいバージョンで問題が発生した場合でもダウンタイムが最小限に抑えられ、アプリケーションの可用性が維持されます。
  • 自動テストは、Blue-Green 導入の重要な側面です。これにより、ソフトウェアの新しいバージョンがアクティブな環境に展開される前に徹底的にテストされるようになります。
  • この展開は継続的デリバリー パイプラインの一部であり、最終的にはソフトウェアの実稼働環境へのリリースがより速く、より頻繁になることを意味します。導入はすでに完了しており、トラフィックの切り替え自体を実行するだけでよいため、これを毎日行うことができるほど高速です。あなたがテスト活動を迅速に行っていると仮定します。

カナリア展開: 概要

出典: cncf.io
プロジェクトのさまざまな段階を示す図。
プロジェクトのさまざまな段階を示す図。

カナリア展開では、ユーザー ベース全体に展開する前に、一部のユーザーに対して新機能や更新の段階的なリリースを実行します。

このアプローチには、ソフトウェアの新しいバージョンを作成して小規模なグループに展開し、残りのユーザーに対して古いバージョンを実行し続けることが含まれます。開発チームは、新しいバージョンが安定しており、期待どおりに動作することを確認するために注意深く監視しています。

すべてがうまくいけば、新しいバージョンはより多くのユーザーに展開され、最終的にはユーザー ベース全体に到達します。このようにして、プロジェクト チームは、すべてのユーザーに一度に影響を与える可能性のあるバグやその他の問題が発生するリスクを最小限に抑えます。

目的は、大規模なユーザー ベースに新機能を導入するリスクを軽減することです。したがって、新しいバージョンへの移行がよりスムーズに行われます。

こちらもお読みください: Canary デプロイメントと DevOps におけるその役割の説明

主な機能と利点

以下は、Canary デプロイメント プロセスの固有の機能です。

  • 新しいバージョンを最初は少数のユーザーに展開し、その後、時間をかけて徐々により多くのユーザーに展開します。すべてのユーザーに一度に影響を与える可能性のあるバグやその他の問題が発生するリスクを最小限に抑えます。
  • 新しいバージョンを注意深く監視して、安定しており、期待どおりに動作していることを確認します。開発者は新しいバージョンに関するフィードバックをより迅速に受け取ることができるため、ユーザー ベース全体に展開する前に必要な調整を行うことができます。
  • 問題が発生した場合は、デプロイメントを以前のバージョンに迅速かつ簡単にロールバックできます。これにより、ユーザー エクスペリエンスに影響を与える可能性のある問題が発生するリスクが軽減されるため、展開プロセスにおける開発者や関係者の信頼が高まります。
  • 人的エラーのリスクを軽減するために、展開プロセスを可能な限り自動化します。

概要: Blue-Green デプロイメントと Canary デプロイメント

特徴 ブルーグリーン展開 カナリア展開
データ同期 ブルー環境とグリーン環境の間での継続的なデータ同期。 ユーザーまたはサーバーのサブセットが新しいバージョンを受け取ります。残りは現在のバージョンで続行します。
アクティベーションプロセス 新しいバージョンの準備ができたら、アクティブ環境から非アクティブ環境に切り替えます。 新しいバージョンを積極的にテストするユーザーの定義されたサブセットに段階的にロールアウトします。
本番環境のユーザーエクスペリエンス 生産のダウンタイムはありません。アクティブな環境間のシームレスな切り替え。 運用ユーザーの一部は新しいバージョンを積極的にテストします。このグループの潜在的な問題。
高可用性とフィードバック速度の比較 高可用性を優先します。 より迅速なフィードバックと制御されたロールアウトを優先します。
リスクの軽減 一部のユーザーに段階的にリリースすることで、問題の可能性を低減します。 主に非アクティブな環境でテストします。テスターは現実世界の問題をすべて把握できるわけではありません。
テストアプローチ 主に非アクティブな環境でテストします。テスターは現実世界の問題をすべて把握できるわけではありません。 実稼働ユーザーはテスターとして機能し、現実の問題を早期に発見します。
注目すべき使用例 Netflix、Amazon、Etsy、LinkedIn、IBM はブルーグリーンを使用しています。 Netflix と Google は、自動テストと段階的なロールアウトとともに Canary を使用しています。

Blue-Green デプロイメントと Canary デプロイメント: 機能

導入

ブルーグリーン展開とは、2 つの環境 (ブルーとグリーン) を意味します。しかし同時に、2 つの環境はデータに関して常に同期されています。これにより、2 つの環境間での永続的なデータ同期プロセスの需要が増加します。

新しいバージョンがテストされ、準備ができているとみなされると、トラフィックがアクティブ環境から非アクティブ環境に切り替えられ、それが新しいアクティブ環境になります。

新しいコードのデプロイに時間を費やす必要はなく、本番環境のダウンタイムも発生しません。すべての実稼働ユーザーは、現在アクティブな環境で常に作業しており、切り替えにさえ気づきません。

出典: aws.amazon.com
アマゾンの csc がどのように機能するかを示す図。
アマゾンの csc がどのように機能するかを示す図。

カナリア展開では、ほとんどのユーザーまたはサーバーが現在のバージョンを使用し続ける一方で、ソフトウェアの新しいバージョンを少数のユーザーに展開することが含まれます。これは完全な切り替えではなく、段階的な展開です。この場合、テスターは、定義されたサブセットにすぎませんが、直接の運用ユーザーです。このグループは実稼働プロセスで新しいバージョンを積極的にテストしており、最終的に安定すると、新しいバージョンは残りのユーザーに普及します。

高可用性が優先される場合は、Blue-Green デプロイメントを選択してください。より迅速なフィードバックとより制御された (ただし遅い) ロールアウトを希望する場合は、カナリア デプロイメントを優先できます。

リスク差の軽減

Blue-Green デプロイメントでは、安定した以前のバージョンにすぐに切り替えることで、リリース失敗のリスクが軽減されます。すべてのユーザーに、そして即座に。明らかに、ロールバックの場合にユーザーへの新機能の提供が遅れるリスクは依然としてありますが、少なくとも、新しいリリースによるいくつかの重大な問題によってブロックされるユーザーは一人もいません。

カナリア展開のリスク軽減戦略は、問題の可能性を段階的に減らすことにあります。新機能は運用ユーザーのサブグループにリリースされるため、リリースがすべてのユーザーに配布される前に、ユーザーはすでにそのソフトウェア バージョンを使用しています。初期ユーザーがそのような問題をすぐに発見する可能性は非常に高くなります。

テストアプローチの違い

Blue-Green デプロイメントでは、テスト プロセスは非アクティブな環境のみに残ります。ここでは、開発者、テスター、さまざまな関係者が望むものを何でもテストできます。テストがアクティブな運用環境で直接実行されているかのように、常に同様の動作が期待できます (データと構成が 2 つの環境間で常に同期されているため)。

したがって、テスターはテスト ショーを実行していますが、実際の運用ユーザーが行うであろうすべての問題を検出できない可能性がまだあります。ただし、非アクティブな環境とアクティブな環境の間の切り替えは常に迅速であるため、これは実際には問題ではありません。その後、開発者に問題を修正してもらい、再度切り替えることができます。

出典: IBM.com
ビジネスプロセスのプロセスを示す図。
ビジネスプロセスのプロセスを示す図。

Canary デプロイメントでは、実稼働ユーザーをテスターとして使用できます。このようなユーザーは通常、より短時間でより多くの問題を発見する傾向があります。日々のビジネス プロセスを完全なエンドツーエンドで実行するだけです。

そのようなテストシナリオやケースを構築したからというだけでなく、とにかくそれを実行しなければならないからです。グループのメンバーがしばらくの間、深刻な問題を抱えてしまう危険性があります。しかし、大多数のユーザーには影響がなく、開発チームは現実世界の最も深刻な問題にすぐに集中できます。

経験と使用例

このようなデプロイメントがすでに正常に実行されている既知のユースケースのいくつかを以下に示します。

  • Netflix は、Blue-Green 導入を使用して、ストリーミング サービスの新しいバージョンを導入します。
  • Amazon と Etsy は、Blue-Green デプロイメントを使用して、e コマース プラットフォームの新しいバージョンをデプロイします。
  • LinkedIn は、Blue-Green デプロイメントを使用して、ソーシャル ネットワーキング プラットフォームの新しいバージョンをデプロイします。
  • IBM は、Blue-Green デプロイメントを使用して、クラウド プラットフォームの新しいバージョンをデプロイします。
  • Netflix は、Canary Deployment を使用して、ストリーミング サービスへの変更をロールアウトします。同社は、自動テスト、機能フラグ、A/B テストを組み合わせて、変更をゆっくり展開しています。
  • Google は Canary Deployment を使用して、クラウド サービスへの変更をロールアウトします。同様に、同社は自動テスト、トラフィック分割、監視の組み込みの利点を利用して、変更をすべてのユーザーに展開する前に、一部のユーザーに段階的に展開しています。

自動化が鍵であり、DevOps パイプラインは間違いなくデプロイメント プロセスの未来です。これらは、次のようなステップを含む完全に自動化されたプロセスです。

  • サービス、データ、ユーザー、権限に関するターゲット環境の作成または更新。
  • コード リポジトリから直接ソース コードのフル/デルタ バージョンを自動展開します。
  • データベース スキーマのアップグレードとデータの更新。
  • 導入アクティビティ中に直接テストを自動実行します。
  • 重要なテスト ケースが正常に完了しなかった場合の自動ロールバック プロセス。
  • 手動介入ステップをゼロにします。

このようなデプロイメント パイプラインを作成したら、Canary プロセスや Blue-Green プロセス、あるいはその他の任意のプロセスを接続できます。これらは、すでにうまく機能することが証明されている 2 つの例にすぎません。しかし、これらは展開活動に関するほとんどの問題を解決するための哲学的な枠組みにすぎません。時間の経過とともにそれらを切り替えたり、両方を組み合わせて使用​​したりすることも難しくありません。

最後の言葉

手動の導入手順に固執することは、成熟していない開発プロセス、さらにはチームの目に見えます。あるいは、特定の企業がソフトウェア配信に関していかに柔軟性に欠け、一枚岩であるかを暴露する可能性もあります。どちらの場合も、現状を修正するには多大な労力がかかります。したがって、上記の展開戦略をプロジェクトに実装してみてください。

次に、Kubernetes にアプリケーションをデプロイする方法を確認してください。

「 Blue-Green デプロイメントと Canary デプロイメント: 主な違い」についてわかりやすく解説!絶対に観るべきベスト2動画

【Official】 Red & Blue, Green & White / JiLL-Decoy association (ジルデコ)
Blue In Green