一般に、サーバー側アプリケーションをアップグレードするには、アプリケーションのソース コードまたはプログラム パッケージをサーバーにアップロードし、古いバージョンのサービスを停止してから、新しいバージョンを開始する必要があります。しかし、この単純な公開方法には 2 つの問題があります。
(1) 新バージョンへのアップグレード作業中は、サービスが一時的に停止されます。
(2) 新バージョンにバグがあるとアップグレードに失敗し、ロールバックが非常に面倒となり、サービスが長期間利用できなくなる可能性が高くなります。
(3) 新機能のエクスペリエンスが悪く、バージョンアッププロセスによってもたらされるトラフィックが損傷し、ユーザーが失われることになります。
これらの問題を解決するために、いくつかの一般的なサービス公開戦略が研究されてきました。以下に 1 つずつ紹介します。
ブルーグリーンリリース
上図に示すように、いわゆる Blue-Green デプロイとは、2 つのバージョンのアプリケーションを同時に実行することを指します。Blue-Green リリースをデプロイする場合は、サービスの新しいバージョンを冗長デプロイする必要があります。一般に、新しいバージョンのマシンの仕様と数量が古いバージョンと一致するということは、現時点では古いバージョンのみが外部にサービスを提供していることを除き、サービスに 2 つの同一のデプロイメント環境があることを意味します。新しいバージョンはホットスタンバイとして使用されます。サービスのバージョンがアップグレードされた場合、すべてのトラフィックを新しいバージョンに切り替えるだけでよく、古いバージョンはホット スタンバイとして使用されます。冗長展開により、新しいバージョンがオンラインになった後に重大なプログラムのバグが発生した場合、すべてのトラフィックを古いバージョンに戻すだけで済み、復旧時間が大幅に短縮されます。新しいバージョンがバグの修復を完了して再デプロイすると、古いバージョンのトラフィックが新しいバージョンに切り替わります。ブルーグリーン リリースでは、追加のマシン リソースを使用することで、サービス リリース中の可用性の問題を解決し、新しいバージョンのサービスに障害が発生した場合には、トラフィックをすぐに古いバージョンに戻すこともできます。
もちろん、Blue-Green リリースは、システムのアイドル期間中にアップグレードすることもできます。既存のクラスタ サーバーを 2 つに分割し、半分はアップグレードされ、残りの半分は予約されて分離されます。新しいシステムが安定した後、残りの半分のサーバーはアップグレードされ、隔離が解除されます。したがって、既存のサーバー リソースを最大限に活用できます。
ブルーグリーン出版の利点:
- シンプルな展開構造と便利な操作とメンテナンス。
- サービスのアップグレードプロセスは操作が簡単で、サイクルも短いです。
ブルーグリーンリリースの欠点:
- リソースの冗長性を確保するには、2 つの実稼働環境の展開が必要です。
- 新しいバージョンには広範囲にわたる欠陥があります。
ローリングリリース
ローリング リリースでは、Blue-Green デプロイ中にハードウェア要件が 2 倍になるという問題を解決できます。
いわゆるローリング アップグレードとは、アップグレード プロセス中にすべての新しいバージョンが一度に開始されるのではなく、最初に新しいバージョンが開始され、次に古いバージョンが停止され、次に新しいバージョンが開始され、古いバージョンが停止されることを意味します。アップグレードが完了するまで、この場合、毎日 10 台のサーバーが必要な場合、アップグレード プロセス中に必要なサーバーは 11 台だけです。
ただし、ローリング アップグレードには問題があります。ローリング アップグレードの開始後、トラフィックは起動された新しいバージョンに直接流れます。現時点では、新しいバージョンは利用できない可能性があります。たとえば、さらなるテストが必要です。確認するために。そして、ローリングアップグレード期間中は、システム全体が非常に不安定な状態となり、問題が見つかった場合でも、その問題の原因が新しいバージョンにあるのか、古いバージョンにあるのかを判断することが困難になります。これを修正するには、ローリング アップグレードのフロー制御を実装する必要があります。
グレースケール リリース (カナリア リリース)
注释：矿井中的金丝雀
17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。
空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；
当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。
当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，
以便在危险状况下紧急撤离。
グレースケール リリースが開始された後、アプリケーションの新しいバージョンが最初に起動されますが、トラフィックは直接カットされませんが、テスターは新しいバージョンに対してオンライン テストを実施し、起動されたアプリケーションの新しいバージョンがカナリアになります。新しいバージョンが期待を満たしていることを確認した後、トラフィックの重み付け比率を段階的に調整し、トラフィックが古いバージョンから新しいバージョンにゆっくりと移行されるようにします。この期間中、設定されたトラフィック比率に従って新バージョンのサービスを拡張できます。古いバージョンのサービスは縮小でき、基礎となるリソースは最大化されます。前の 2 つのリリース戦略と比較して、グレースケール リリースの考え方は、少数のリクエストを新しいバージョンに転送することであるため、新しいバージョンのサービスをデプロイするために必要なマシンの数は非常に少数です。
グレースケール パブリッシングは、ユーザーがリクエストしたメタ情報に基づいてトラフィックを新しいバージョンにルーティングできます。これは、リクエスト コンテンツの一致に基づくグレースケール パブリッシング戦略です。特定のルールに一致するリクエストのみが新しいバージョンに転送されます。一般的な方法には、HTTP ヘッダーと Cookie に基づくものが含まれます。たとえば、HTTP ヘッダー メソッドの例に基づくと、User-Agent の値が Android の場合、リクエストは新しいバージョンにアクセスできますが、他のシステムは引き続き古いバージョンにアクセスします。Cookie メソッドの例に基づくと、Cookie には通常、ビジネス セマンティクスを伴うユーザー情報が含まれています。たとえば、VIP は新しいバージョンにアクセスでき、一般ユーザーは引き続き古いバージョンにアクセスできます (またはその逆)。
図に示すように、サービスの現在のバージョンは v1 ですが、現在は新しいバージョン v2 がオンラインになっています。サービス アップグレード プロセス中にトラフィックが安定し、損傷を受けないことを保証するために、カナリア リリース スキームが採用され、トラフィックが古いバージョンから新しいバージョンに徐々に移行されます。
グレースケールリリースでは、新バージョンの実行状況を観察し、さまざまな実行時データを収集しますが、このとき新旧バージョン間で各種データを比較するのが、いわゆる A/B テストです。監視プラットフォーム上で旧バージョンと新バージョンの成功率とRTの比較を観察することで、新バージョンのサービス全体が期待できる場合には、すべてのリクエストを新バージョンに切り替えることができます。
グレースケール パブリッシングの利点:
1. 特定のリクエストまたはユーザーに対して新しいバージョンのサービスを提供でき、新しいバージョンの障害の範囲が小さい 2.
リリース期間中に、新しいバージョンの容量が徐々に拡張され、古いバージョンは同時に削減され、リソース使用率が高くなります。
3. 異なるバージョン間のリクエストステータスの違いを比較するには、完全な監視プラットフォームを構築する必要があります (A/B テストを実行します)。
グレースケール出版の欠点:
1. リクエスト容量を正確に見積もることができないため、リソースの冗長性が依然として存在する可能性がある;
2. トラフィックが無差別に新しいバージョンに送信されると、ユーザー エクスペリエンスに影響を与える可能性がある;
3. リリース サイクルが長い。
概要: 次の図は、いくつかの展開方法の進化を示しています。
アプリケーションの新しいバージョンがリリースされるとき、ダウンタイムなしでサーバーをアップグレードし、影響を最小限に抑えるために、グレー リリース戦略が使用されます。
グレースケール リリースの開始時に、HTTP ヘッダーなどの戦略を使用して、指定されたテスターのトラフィックを新しいバージョンに一致させます。
その後、新しいバージョンの内部テストに合格した後、パーセンテージやホワイトリストなどに従って、ユーザー トラフィックを少しずつ新しいバージョンにインポートし、すべてのトラフィックが新しいバージョンにインポートされ、最終的にアップグレードが完了します。 。
期間中に問題が発見された場合、アップグレードは直ちにキャンセルされ、トラフィックは古いバージョンに戻されます。
グレースケールリリースを使用すると、ダウンタイムアップグレードのために深夜まで残業する必要がなく、日中に大胆かつ安全に新しいバージョンをリリースできます。
参照文書