1. 概要

このチュートリアルでは、最も一般的な6つの展開戦略について説明します。

2. 展開戦略

アプリケーションをデプロイするときは常に、プロセスを慎重に計画する必要があります。 さまざまな側面と、それがユーザーエクスペリエンスにどのように影響するかを考慮する必要があります。 デプロイメントは、ダウンタイムなしで、ユーザーエクスペリエンスを妨げることなく、アプリケーションをインストールまたはアップグレードすることを目的としています。

展開戦略は、これらのアップグレードを実行する方法のプロセスを説明します。

3. 展開戦略を再作成する

ここで説明する最も基本的な戦略は、「再作成」展開戦略と呼ばれます。 名前が示すように、アプリケーションを停止してから再作成します。 新しく作成されたデプロイメントは、更新されたバージョンのアプリケーションを実行します。

新しいバージョンが実行される前にアプリケーションを停止する必要があるため、ユーザーはダウンタイムを経験します。元のバージョンがシャットダウンされ、新しいバージョンが開始されている間、アプリケーションは使用できません。

一方、この戦略は簡単に設定できます。2つの異なるバージョンのアプリケーションを同時に管理する必要はありません。 このアプローチを選択すると、更新されたアプリケーションはすべてのユーザーがすぐに利用できるようになります。 ただし、これには欠点があります。これは、新しいバージョンではアプリケーションにバグが発生する可能性があり、ユーザーにもバグが表示されるためです。

以前の作業バージョンに完全にロールバックする必要がある場合もあります。 残念ながら、ロールバックによってダウンタイムも発生します。デプロイメントを元に戻すには、更新されたアプリケーションを停止して、元のアプリケーションを再作成する必要があります。

結論として、この展開戦略はセットアップと管理が非常に簡単ですが、使用する前にその欠点を考慮する必要があります。

4. ブルーグリーン展開

次に説明する展開戦略は、「ブルーグリーン」展開と呼ばれます。 この場合、異なるアプリケーションバージョンに異なる色を割り当てます。 それが名前の由来です。 元の古いバージョンは青い環境と呼ばれ、新しい更新されたバージョンは緑の環境と呼ばれます。

この戦略がどのように機能するか見てみましょう。 まず、青い環境があります。 これは、すべてのユーザートラフィックを処理する既存のアプリケーションです。 ダウンタイムなしでアプリケーションを更新したいと思います。 これを実現するために、ほぼ同じ環境を作成します。 ただし、違いがあります。 新しい環境には、更新されたアプリケーションバージョンが含まれます。 現在、両方の環境でアプリケーションが実行されていますが、ユーザーは引き続き古いバージョンを使用しています:

上の画像は、新しいバージョンをすでに開始したときの状態を示していますが、ユーザーはまだ青い環境を使用しています。 次のステップは、すべてのユーザートラフィックを環境に転送することにより、環境に配慮した環境に切り替えることです。 この切り替えは非常に迅速に発生する可能性があるため、ユーザーはダウンタイムを経験しません。 さらに、以前と同じようにアプリケーションを使用でき、更新されたアプリケーションによってリクエストが処理されていることを知りません。

変更をロールバックする必要がある場合は、トラフィックを元の青い環境にルーティングすることですぐに実行できます。 展開が終了し、ロールバックしたくない場合は、古い青い環境を削除できます。 次に、更新されたバージョンの名前を緑から青に変更します。 次のリリースでも同じ手順に従うことができます。

このプロセスは、稼働時間とロールバックの観点から好ましいことがわかります。 ただし、欠点もあります。 2つのほぼ同一の環境を作成するため、より多くのリソースが必要になります。これは、セットアップに費用と時間がかかる可能性があります。 次に、新しいバージョンで下位互換性のない変更が行われた場合、ロールバックで問題が発生する可能性があります。 たとえば、データベースの変更。

5. ローリングアップデート

次の戦略は「ローリングアップデート」と呼ばれます。 アプリケーションのインスタンスが複数ある場合にのみ適用されます。

最初は、すべてのインスタンスが古いバージョンを実行しており、すべてのインスタンスがユーザーリクエストを処理できます。 プロセスによってインスタンスが削除され、残りのインスタンスはダウンタイムを防ぐためにユーザーにサービスを提供できる必要があるため、これはここで重要です。

最初に、更新されたバージョンを実行する新しいインスタンスを作成します。この新しいインスタンスが開始されると、アプリケーションの一部と見なされるため、ユーザーリクエストはすでに処理されている可能性があります。

この後、古いバージョンを実行しているインスタンスから1つを削除します。このようにして、古いバージョンを実行している2つのインスタンスと、更新されたバージョンを実行している1つのインスタンスがあります。 これは、この展開戦略を使用する場合は、同時に異なるバージョンをサポートできる必要があることを示しています。 そうしないと、古いインスタンスまたは新しいインスタンスが期待どおりに機能しない可能性があります。

プロセスは、新しいバージョンを実行しているインスタンスを追加し続け、それらのペアを削除します。

最後のインスタンスが更新されたインスタンスに置き換えられたときにデプロイが終了し、アプリケーションが期待どおりに機能することを確認しました。もちろん、更新中にテストすることもできます。 問題が見つかった場合は、すべての変更をロールバックできます。

この展開戦略は、ニーズに合わせてパラメーター化できます。 通常、一度に更新するインスタンスの数を設定できます。 複数の場合があります。 簡単にするために、この例ではこの値を使用しました。

6. カナリアの展開

私たちが検討する次の展開方法は、「カナリア展開」と呼ばれます。 主なアイデアは、更新をより多くのユーザーに繰り返し展開することです。

最初は、ごく一部のユーザーのみが更新を受け取ります。この手順の後、システムをテストして、変更後にアプリケーションが正しく機能していることを確認します。 このようにして、リスクを減らすことができ、システムにバグを導入したとしても、一部のユーザーだけがそれを見ることができます。

更新が成功したことを確認したら、すべてのユーザーへのロールアウトを続行できます。これも段階的に発生する可能性があります。つまり、更新は徐々に多くのユーザーに届きます。 たとえば、25%、50%、75%、そして100%です。 各増分の間にシステムを再テストすることもできます。

テスト中に、アプリケーションが正しく機能していないことに気付く場合があります。 この場合、前の例と同様に変更をロールバックする必要があります。

カナリア展開は高度な制御を提供しますが、これを実装するのは難しい場合があります。限られた数のユーザーのみが更新を受信するようにする必要があります。 ある環境から別の環境にトラフィックを切り替える必要があるだけの青緑色の展開と比較すると、これはより困難です。 一方で、柔軟性が高まり、リスクが軽減されます。

環境を複製していないため、このプロセスは青緑色のデプロイメントほど多くのリソースを必要としません。ただし、新しいアプリケーションバージョンでデータベースに重大な変更が加えられた場合も、同じ問題が発生します。

カナリア展開戦略には、もう1つの興味深い側面があります。 最初に更新を取得するターゲットオーディエンスを選択する必要があります。理想的には、更新に問題が見つかった場合に報告するターゲットグループです。 ただし、人口統計、物理的な場所、デバイスの種類などに基づいてユーザーを選択できます。

7. A/Bテスト

A / Bテストは、カナリアの展開と非常によく似ています。 それはその変種と見なすことができます。 このプロセスは、カナリア展開と同様に、更新をユーザーのサブセットに展開します。 ただし、A / Bテストは主に、変更に関するユーザーからのフィードバックを取得することを目的としています。 ユーザーの一部はアプリケーションの「バージョンA」を使用し続け、別の部分は「バージョンB」を使用します。

私たちの目標は、すべてのユーザーに更新を公開するかどうかを決定することです。 これは複雑なプロセスになる可能性があります。 アプリケーションのパフォーマンスなどの技術的な側面を考慮する必要がありますが、ユーザーが変更を気に入ったかどうかにかかわらず、ユーザーからフィードバックを受け取りたい場合もあります。 たとえば、A / Bテストでは、ボタンのテキストを置き換えた場合に、ユーザーがボタンをクリックする可能性が高いかどうかを測定できます。

8. シャドウ展開

シャドウ展開は、2つの同一の環境を使用するという意味で、青緑色の展開に似ています。そのうちの1つは、元の実稼働環境です。 もう1つは影です。

ただし、これは以前の展開戦略とは異なります。 これまでのすべてのアプローチでは、ユーザー要求は更新された環境によって処理されていました。 シャドウデプロイメントを使用すると、両方の環境がリクエストを受信しますが、レスポンスは元のアプリケーションバージョンから取得されます:

このように、負荷がかかった状態で新しいバージョンを監視およびテストできる間、システムにバグが発生するリスクはありません。

一方、2つの展開を行うと、コストがかかり、管理が困難になる可能性があります。 さらに、新しいバージョンに副作用がないことを確認する必要があります。 たとえば、支払いを処理する場合、ユーザーに2回請求されないように、新しい環境で支払いサービスをモックする必要があります。

更新されたバージョンが安定していることが確認されると、古いバージョンを置き換えることができ、ユーザートラフィックをそのバージョンにリダイレクトできます。

9. 結論

この記事では、展開戦略とは何かを説明し、6つの異なる戦略を比較しました。

システムで何を使用するかを選択する前に、多くの側面を検討し、可能な展開戦略を比較する必要があります。