カナリアリリース戦略対ブルー/グリーン

カナリアリリースについての私の理解は、スティッキーセッションがオンになっている運用ノードのサブセットへの部分的なリリースであるということです。そうすることで、最終的に悪いバグをリリースした場合に影響を受けるユーザー/顧客の数を制御し、最小限に抑えることができます。

青/緑のリリースについての私の理解は、2つのミラーリングされた本番環境（「青」と「緑」）があり、変更を青または緑のいずれかのすべてのノードに一度にプッシュし、ネットワークマジックを使用して制御することです。ユーザーがDNS経由でルーティングされる環境。

だから、始める前に、これまでに言ったことに誤りがある場合は、まず訂正してください！

私が多かれ少なかれ順調に進んでいると仮定すると、2つの戦略についていくつか質問があります。

• カナリアが青/緑よりも優先されるシナリオ、またはその逆のシナリオはありますか？
• 展開モデルが両方の戦略を同時に実装できるシナリオはありますか？

青緑色のリリースは、よりシンプルで高速です。

あなたはできますが、テスト環境で新しいバージョンをテストし、新しいバージョンが本番で正しく機能することを非常に確信しているしている場合は青緑色のリリースを行います。新しいバージョンは、誰かが機能トグルを切り替えるまで、以前とまったく同じように機能するため、常に機能トグルを使用することは、新しいバージョンの信頼性を高めるための良い方法です。テストする必要が少なく、壊れる可能性が少ないため、アプリケーションを独立して解放可能な小さなサービスに分割することも別の方法です。

あなたはする必要がありますが、新しいバージョンが本番で正しく機能することを完全に一定でないならカナリアリリースを行います。あなたが完全なテスターであっても、インターネットは大きくて複雑な場所であり、常に予期しない課題を抱えています。機能トグルを使用しても、正しく実装されない場合があります。

展開の自動化には労力がかかるため、ほとんどの組織は、常にいずれかの戦略を使用する予定です。

そのため、自信を持って実践できるように取り組んでいる場合は、青緑色の展開を行ってください。それ以外の場合は、カナリアを送信します。

ブルーグリーンの本質はすべてを同時に展開し、カナリア展開の本質は段階的に展開するので、ユーザーの単一のプールを考えると、両方を同時に実行するプロセスとは言えません。ユーザーの複数の独立したプールがある場合（たとえば、異なる地域のデータセンターを使用している場合）、各データセンター内で青緑を実行し、データセンター間でカナリアを作成できます。データセンター内でカナリアデプロイメントが必要なかったとしても、データセンター全体でカナリアデプロイメントはおそらく必要ありません。

このトピックに関する詳細なエッセイをここに書きました：http : //blog.itaysk.com/2017/11/20/deployment-strategies-defined

私の意見では、違いは、新しい「グリーン」バージョンが実際のユーザーに公開されるかどうかです。もしそうなら、私はそれをカナリーと呼びます。Canaryを実装する一般的な方法は、新しいバージョンに特定のユーザーのスマートルーティングを追加した通常のBlue / Greenです。詳細な比較については、投稿を読んでください

青/緑：

カナリア：

これらの用語はどちらも非常に似ていますが、微妙な違いがあります。1つは機能リリースに信頼を置き、もう1つはリリース方法に信頼を置きます。

カナリア

1. カナリアリリースは、インフラストラクチャ全体にロールアウトする前に、変更を小さなユーザーのサブセットにゆっくりロールアウトすることにより、本番環境に新しいソフトウェアバージョンを導入するリスクを軽減する手法です。

2. 新しいバージョンがどのように動作するかを理解しようとしています（他のアプリ、CPU、メモリ、ディスク使用量などと統合します）。

青/緑：

1. 停止時間ゼロの展開を備えた予測可能なリリースの詳細です。
2. 失敗した場合の簡単なロールバック。
3. 完全に自動化された展開プロセス

ここにいくつかのインライン定義があります-

• 青緑色の配備 -アプリケーションの新しいバージョンを配備すると、2番目の環境が作成されます。新しい環境がテストされると、古いバージョンから引き継がれます。その後、古い環境をオフにすることができます。

   

• A / Bテスト -アプリケーションの2つのバージョンが同時に実行されています。リクエストの一部はそれぞれに送られます。その後、開発者はバージョンを比較できます。  
• カナリアリリース -新しいバージョンのマイクロサービスが古いバージョンとともに開始されます。その新しいバージョンはリクエストの一部を取得でき、チームはこの新しいバージョンがシステム全体とどのように相互作用するかをテストできます。

定義の良いスタート。「リリース」の定義を「デプロイ」と「リリース（機能）」に分割すると、戦略の決定にも役立つと思います。

デプロイ（バイナリ）

（本番）システムへの製品のバイナリ展開のアクション。

リリース（機能）

ユーザー（のグループ）が利用できる機能を管理するアクション。

どうして？通常、「リリース」する際には（複数の）2つの懸念があります。1）バグ/下位互換性/ etc 2）新機能の有効性/使いやすさの確認

次に、カナリア、ブルー/グリーン、またはグレー/混合モードの戦略を選択する前に、自問してみてください。新しいバージョンをリリース/デプロイするときに、どのような懸念がありますか？そして、あなたが懸念を知っている場合にのみ、戦略を選択してください。

さらに、より複雑な展開/リリース戦略を実行することも可能です。たとえば、一部のクラウド/インフラストラクチャでは、複数の本番サーバーを使用し、異なるサーバーや製品のバージョンに異なる比率で負荷を中継し、リリース/デプロイをすべてのユーザーに拡大する前に健全性を監視できます。

機能のフラグ付け

ユーザーのどの（グループ）に対してどの機能が（利用できない）かを（構成する）（コールド、またはホットにする）ためのアクション

「機能のフラグ設定」のようなことも行う場合は、最初に展開し、下位互換性/バグの観点でリリースの健全性を測定し、新しい機能を異なるユーザーに徐々にリリースするか、またはその逆（スケールダウンまたはロールバック機能やバイナリ） ）。機能のフラグ付けにより、機能の可用性をバイナリの展開から分離でき、「展開/ロールバック」のみの場合よりもはるかに詳細な意思決定が可能になります。