ブルーグリーンデプロイメント、A/B テスト、Lark リリース

近年、「DevOps」が非常に人気になっています。最近、私たちのチームでは、デプロイメントのベストプラクティス、ホットデプロイメント、ロールバックなどについて話し合いました。ブルーグリーンデプロイメントに関しては、全員が大きな関心を示しました。

ブルーグリーンデプロイメントは、Amazon などの場所で 10 年以上にわたって実践されてきました。これらは安全で、実証された方法です。ブルーグリーンデプロイメントは万能薬ではありませんが、用途はあります。

A/B テストや Canary テストもあります。マイクロサービス、DevOps、クラウド ネイティブに関する会話では、これらについて多くの議論が行われているので、ここではそれらの違いを簡単にまとめます。

ブルーグリーンデプロイメント

Blue Green Deployment の詳細な紹介については、Martin Fowler の Blue Green Deployment に関するリンク (http://martinfowler.com/bliki/BlueGreenDeployment.html) を参照してください。全体的な要点がわかります。

これは基本的に、リリースに関連するダウンタイムを削減することを目的として、予測可能な方法でアプリケーションをリリースする手法です。これは、リリース前にアプリを準備する簡単な方法であり、問​​題が発見された場合にすぐにロールバックすることもできます。

簡単に言えば、2 つの同一の環境 (インフラストラクチャ) があり、「グリーン」環境で現在の本番アプリケーション (例: app1 version1、app2 version1、app3 version1) をホストします。

写真

ここで、app2 に変更を加えて v2 にアップグレードする準備ができたら、「blue 環境」で実行します。この環境では、アプリケーションの新しいバージョンをデプロイし、スモーク テストやその他のテスト (OS、キャッシュ、CPU などの実行/起動を含む) を実行します。問題がなければ、ロード バランサー/リバース プロキシ/ルーターをブルー環境を指すように変更します。

写真

リリースによる障害や異常を監視します。すべてが問題なければ、最終的にグリーン環境をオフにして、新しいリリースに使用できます。そうでない場合は、ロード バランサーを元に戻すことで、すぐにグリーン環境にロールバックできます。

理論的には良さそうです。しかし、注意すべき点がいくつかあります。

• グリーン環境での長期にわたる取引。ブルーに切り替えると、未処理のトランザクションと新しいトランザクションを適切に処理する必要があります。データベースのバックエンドがこれを処理できない場合は、面倒になることもあります (以下を参照)。

• エンタープライズ デプロイメントは、通常、「マイクロサービス」スタイルのデプロイメントには適していません。つまり、マイクロサービス スタイルのアプリケーションと、従来の変更が難しいアプリケーションが混在している可能性があります。ブルーグリーン デプロイメントのために 2 つを調整すると、依然としてダウンタイムが発生する可能性があります。

• データベースの移行は複雑になる可能性があり、アプリケーションのデプロイメントと一緒に移行/ロールバックする必要があります。これを行うには優れたツールとテクニックがありますが、従来の RDBMS、NoSQL、およびファイル システムでバックアップされたデータベースのコンテキストでは、これらのことを事前に検討する必要があります。盲目的にブルーグリーンデプロイメントを実行していると言っても役に立ちません。実際、害を及ぼす可能性があります。

• これを実行するにはインフラストラクチャが必要です。

• 分離されていないインフラストラクチャ (VM、Docker など) でこれを実行しようとすると、ブルー環境とグリーン環境の両方が壊れるリスクがあります。

前述したように、継続的なデプロイメント パイプラインへのプラグインなど、これらの課題を克服し、このスタイルのデプロイメントを非常に効果的にするための優れたテクニックがいくつかありますが、軽々しく導入しないでください。

A/Bテスト

A/B テストは、一部の人が混同しているように、ブルーグリーンデプロイメントではありません。 A/B テストは、使いやすさ、人気、注目度などさまざまな理由でアプリケーションの機能をテストし、これらの要素が最終的な収益にどのように影響するかを調べる方法です。これは通常、アプリケーションの UI 部分に関連付けられますが、もちろんこれを行うにはバックエンド サービスが必要です。これは、アプリケーション レベルのスイッチ (つまり、特定の UI コントロールをいつ表示するかを認識するスマート ロジック)、静的スイッチ (アプリ内)、および Canary ビルド (以下で説明) を使用して実行できます。

写真

ブルーグリーンデプロイメントと A/B テストの違いは、A/B テストはアプリケーションの機能を測定するために使用されることです。ブルーグリーンデプロイメントとは、新しいソフトウェアを安全にリリースし、期待どおりにロールバックすることです。もちろん、これらを組み合わせることもできます。ブルーグリーン デプロイメントを使用して、A/B テストに使用できる新しい機能をアプリケーションにデプロイします。

スカイラークリリース

最後に、カナリア リリースは、アプリケーションの新しいバージョンを本番環境に送信する方法であり、そのパフォーマンス (他のアプリケーションとの統合、CPU、メモリ、ディスク使用量など) を確認するための「試し」として機能します。これは、下位環境でテストをどの程度実行しても、運用環境では依然としてバグが発生するという事実を軽減する別のリリース戦略です。 Skylark バージョンでは、トリガーを完全に放す前に水をテストできます。

写真

フィードバックを早く得られるほど、失敗したデプロイメントや慎重なデプロイメントをより早く展開できます。ブルーグリーンデプロイメントの場合と同じ理由から、上記には注意が必要です。つまり、データベースの変更によって、依然として問題が発生する可能性があります。

まとめ

これらの戦略はすべて、特定のクラウド テクノロジを使用するかどうかに関係なく実装できます。しかし、ご想像のとおり、Docker や Kubernetes などのテクノロジーは、これらのポリシーの適用に非常に役立ちます (そのための規定が組み込まれていない場合でも)。たとえば、OpenShift と Fabric8 は、基盤となる詳細を気にすることなくこれらのテクノロジーを使用するために必要なツールを提供することで、Docker と Kubernetes の使用を大幅に簡素化します。

オリジナルリンク: https://blog.christianposta.com/deploy/blue-green-deployments-ab-testing-and-canary-releases/