4.4.5. A/B デプロイメント
A/B デプロイメントストラテジーでは、新しいバージョンのアプリケーションを実稼働環境での制限された方法で試すことができます。実稼働バージョンは、ユーザーの要求の大半に対応し、要求の一部が新しいバージョンに移動されるように指定できます。
各バージョンへの要求の割合を制御できるので、テストが進むにつれ、新しいバージョンへの要求を増やし、最終的に以前のバージョンの使用を停止することができます。各バージョン要求負荷を調整する際に、期待どおりのパフォーマンスを出せるように、各サービスの Pod 数もスケーリングする必要が生じる場合があります。
ソフトウェアのアップグレードに加え、この機能を使用してユーザーインターフェイスのバージョンを検証することができます。以前のバージョンを使用するユーザーと、新しいバージョンを使用するユーザーが出てくるので、異なるバージョンに対するユーザーの反応を評価して、設計上の意思決定を知らせることができます。
このデプロイメントを有効にするには、以前のバージョンと新しいバージョンは同時に実行できるほど類似している必要があります。これは、バグ修正リリースや新機能が以前の機能と干渉しないようにする場合の一般的なポイントになります。これらのバージョンが正しく連携するには N-1 互換性が必要です。
OpenShift Container Platform は、Web コンソールと CLI で N-1 互換性をサポートします。
4.4.5.1. A/B テスト用の負荷分散
ユーザーは複数のサービスでルートを設定します。各サービスは、アプリケーションの 1 つのバージョンを処理します。
各サービスには weight が割り当てられ、各サービスへの要求の部分については service_weight を sum_of_weights で除算します。エンドポイントの weights の合計がサービスの weight になるように、サービスごとの weight がサービスのエンドポイントに分散されます。
ルートにはサービスを最大で 4 つ含めることができます。サービスの weight は、0 から 256 の間で指定してください。weight が 0 の場合は、サービスはロードバランシングに参加せず、既存の持続する接続を継続的に提供します。サービスの weight が 0 でない場合は、エンドポイントの最小 weight は 1 となります。これにより、エンドポイントが多数含まれるサービスでは、最終的に weight は意図される値よりも大きくなる可能性があります。このような場合は、予想される負荷分散の weight を得るために Pod の数を減らします。
手順
A/B 環境を設定するには、以下を実行します。
2 つのアプリケーションを作成して、異なる名前を指定します。それぞれが
Deploymentオブジェクトを作成します。これらのアプリケーションは同じプログラムのバージョンであり、通常 1 つは現在の実稼働バージョンで、もう 1 つは提案される新規バージョンとなります。最初のアプリケーションを作成します。以下の例では、
ab-example-aという名前のアプリケーションを作成します。$ oc new-app openshift/deployment-example --name=ab-example-a
2 番目のアプリケーションを作成します。
$ oc new-app openshift/deployment-example:v2 --name=ab-example-b
どちらのアプリケーションもデプロイされ、サービスが作成されます。
ルート経由でアプリケーションを外部から利用できるようにします。この時点でサービスを公開できます。現在の実稼働バージョンを公開してから、後でルートを編集して新規バージョンを追加すると便利です。
$ oc expose svc/ab-example-a
ab-example-a.<project>.<router_domain>でアプリケーションを参照して、予想されるバージョンが表示されていることを確認します。ルートをデプロイする場合には、ルーターはサービスに指定した
weightsに従ってトラフィックを分散します。この時点では、デフォルトのweight=1と指定されたサービスが 1 つ存在するので、すべての要求がこのサービスに送られます。他のサービスをalternateBackendsとして追加し、weightsを調整すると、A/B 設定が機能するようになります。これは、oc set route-backendsコマンドを実行するか、ルートを編集して実行できます。oc set route-backendを0に設定することは、サービスがロードバランシングに参加しないが、既存の持続する接続を提供し続けることを意味します。注記ルートに変更を加えると、さまざまなサービスへのトラフィックの部分だけが変更されます。デプロイメントをスケーリングして、必要な負荷を処理できるように Pod 数を調整する必要がある場合があります。
ルートを編集するには、以下を実行します。
$ oc edit route <route_name>
出力例
... metadata: name: route-alternate-service annotations: haproxy.router.openshift.io/balance: roundrobin spec: host: ab-example.my-project.my-domain to: kind: Service name: ab-example-a weight: 10 alternateBackends: - kind: Service name: ab-example-b weight: 15 ...
4.4.5.1.1. Web コンソールを使用した既存ルートの重みの管理
手順
-
Networking
Routes ページに移動します。 -
編集するルートの横にある
Actions メニューをクリックし、Edit Route を選択します。
-
YAML ファイルを編集します。
weightを0から256の間の整数になるように更新します。これは、他のターゲット参照オブジェクトに対するターゲットの相対的な重みを指定します。値0はこのバックエンドへの要求を抑制します。デフォルトは100です。オプションについての詳細は、oc explain routes.spec.alternateBackendsを実行します。 - Save をクリックします。
4.4.5.1.2. Web コンソールを使用した新規ルートの重みの管理
-
Networking
Routes ページに移動します。 - Create Route をクリックします。
- ルートの Name を入力します。
- Service を選択します。
- Add Alternate Service をクリックします。
-
Weight および Alternate Service Weight の値を入力します。他のターゲットとの相対的な重みを示す
0から255の間の数字を入力します。デフォルトは100です。 - Target Port を選択します。
- Create をクリックします。
4.4.5.1.3. CLI を使用した重みの管理
手順
サービスおよび対応する重みのルートによる負荷分散を管理するには、
oc set route-backendsコマンドを使用します。$ oc set route-backends ROUTENAME \ [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]たとえば、以下のコマンドは
ab-example-aにweight=198を指定して主要なサービスとし、ab-example-bにweight=2を指定して 1 番目の代用サービスとして設定します。$ oc set route-backends ab-example ab-example-a=198 ab-example-b=2
つまり、99% のトラフィックはサービス
ab-example-aに、1% はサービスab-example-bに送信されます。このコマンドでは、デプロイメントはスケーリングされません。要求の負荷を処理するのに十分な Pod がある状態でこれを実行する必要があります。
フラグなしのコマンドを実行して、現在の設定を確認します。
$ oc set route-backends ab-example
出力例
NAME KIND TO WEIGHT routes/ab-example Service ab-example-a 198 (99%) routes/ab-example Service ab-example-b 2 (1%)
--adjustフラグを使用すると、個別のサービスの重みを、それ自体に対して、または主要なサービスに対して相対的に変更できます。割合を指定すると、主要サービスまたは 1 番目の代用サービス (主要サービスを設定している場合) に対して相対的にサービスを調整できます。他にバックエンドがある場合には、重みは変更に比例した状態になります。以下の例では、
ab-example-aおよびab-example-bサービスの重みを変更します。$ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10
または、パーセンテージを指定してサービスの重みを変更します。
$ oc set route-backends ab-example --adjust ab-example-b=5%
パーセンテージ宣言の前に
+を指定すると、現在の設定に対して重み付けを調整できます。以下に例を示します。$ oc set route-backends ab-example --adjust ab-example-b=+15%
--equalフラグでは、全サービスのweightが100になるように設定します。$ oc set route-backends ab-example --equal
--zeroフラグは、全サービスのweightを0に設定します。すべての要求に対して 503 エラーが返されます。注記ルートによっては、複数のバックエンドまたは重みが設定されたバックエンドをサポートしないものがあります。
4.4.5.1.4. 1 サービス、複数の Deployment オブジェクト
手順
すべてのシャードに共通の
ab-example=trueラベルを追加して新規アプリケーションを作成します。$ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA $ oc delete svc/ab-example-a
アプリケーションがデプロイされ、サービスが作成されます。これは最初のシャードです。
ルートを使用してアプリケーションを利用できるようにしてください (または、サービス IP を直接使用してください)。
$ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true $ oc expose service ab-example
-
ab-example-<project_name>.<router_domain>でアプリケーションを参照し、v1イメージが表示されることを確認します。 1 つ目のシャードと同じソースイメージおよびラベルに基づくが、別のバージョンがタグ付けされたバージョンと一意の環境変数を指定して 2 つ目のシャードを作成します。
$ oc new-app openshift/deployment-example:v2 \ --name=ab-example-b --labels=ab-example=true \ SUBTITLE="shard B" COLOR="red" --as-deployment-config=true $ oc delete svc/ab-example-bこの時点で、いずれの Pod のセットもルートで提供されます。しかし、両ブラウザー (接続を開放) とルーター (デフォルトでは cookie を使用) で、バックエンドサーバーへの接続を維持しようとするので、シャードが両方返されない可能性があります。
1 つのまたは他のシャードに対してブラウザーを強制的に実行するには、以下を実行します。
oc scaleコマンドを使用して、ab-example-aのレプリカを0に減らします。$ oc scale dc/ab-example-a --replicas=0
ブラウザーを更新して、
v2およびshard B(赤) を表示させます。ab-example-aを1レプリカに、ab-example-bを0にスケーリングします。$ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
ブラウザーを更新して、
v1およびshard A(青) を表示します。
いずれかのシャードでデプロイメントをトリガーする場合、そのシャードの Pod のみが影響を受けます。どちらかの
DeploymentオブジェクトでSUBTITLE環境変数を変更してデプロイメントをトリガーできます。$ oc edit dc/ab-example-a
または
$ oc edit dc/ab-example-b
