ポリマーウェブコンポーネントでA/Bテストを実行するには？

Question

私は顧客の状況に遭遇しています。彼らはA/Bテストを行いたいと考えています。

私が知る限り、このほとんどの時間はLoadBalancerレベル（Kubernetes）で特定のバージョンのアプリケーションにリダイレクトされます（たとえば、新しいバージョンのGmailで、リリースが公開されています）。

ウェブコンポーネントでは、この顧客はコンポーネントで特定の要件が満たされていると機能が有効になる「dom-if」のような状況を望んでいます。もちろんこれはオーバーヘッドを増やします。

私はこれが行く方法であるかと思います。この顧客の主張は、コンポーネントを100種類のアプリケーションで使用し、ビルドを作成して作業することが面倒であり、マイクロレベル（コンポーネントのINのように）が最善の方法であるということです。彼らはLinkedin/AirBnBに従っています。

私の知る限り、これらの企業はWebコンポーネントを使用していません。

質問は：お勧めですか？マイクロレベルまたはアプリケーションレベルでA/Bテストを行います（そして、kubernetesのようなロードバランサを使用します）。

Answer 1

これがあなたの完全な質問を網羅しているのかどうかはわかりませんが、Microserviceアーキテクチャ内では各サービス内で自分自身でテストします。

あなたのサービスをホストするplattformとしてKubernetesと言えば、別のDeploymentsからPodsを選択する1つのLoadBalancerサービスを持つことができます。各Deploymentは、異なるコンテナ/アプリケーションバージョンを提供することができ、または同じコンテナを提供することができるが、異なる設定を提供することができる。

ここには小さな例があります。単一のサービスには、両方の配備のポッドに一致するセレクタ（app: testme）があります。デプロイメントは同じイメージ（yourcontainerimage:version）からコンテナを定義しますが、環境変数は異なります。また、レプリカの量が異なると、1つまたは他のオプションにルーティングされるトラフィックの割合を異ならせることができます。

apiVersion: v1 
kind: Service 
metadata: 
    name: app 
spec: 
    ports: 
    - name: http 
     port: 8080 
    selector: 
    app: testme 
--- 
apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
    name: app-deployment-a 
spec: 
    replicas: 2 
    template: 
    metadata: 
     labels: 
     app: testme 
     ab: on 
    spec: 
     containers: 
     - name: app 
     image: yourcontainerimage:version 
     env: 
     - name: FEATURE_TOGGLE 
      value: true 
     ports: 
     - containerPort: 8080 
--- 
apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
    name: app-deployment-b 
spec: 
    replicas: 1 
    template: 
    metadata: 
     labels: 
     app: testme 
     ab: off 
    spec: 
     containers: 
     - name: app 
     image: yourcontainerimage:version 
     env: 
     - name: FEATURE_TOGGLE 
      value: false 
     ports: 
     - containerPort: 8080 

アプリケーションやテストする機能のタイプによっては、サービスを調整したい場合があります。サービスのSessionAffinityを有効または無効にします。詳細はofficial docsにあります。

Answer 2

Variantには、分散サーバー側のケース（例：マイクロサービス）が明確に記述されています。 （免責事項：私はそこで働く）。どちらのコンポーネントが最初に実験に触れるかにかかわらず、（ホストアプリケーションが持つ可能性のあるセッションの概念（HTTP Sessionなど）に関係なく）Variantセッションを作成し、セッションハンドルを次のコンポーネントに渡します。実験はVariantサーバーのデータに関連しています。唯一の捉え方は、現時点ではJavaコンポーネントのみをサポートしていることです。

また、ロードバランサなどの展開インフラストラクチャを使用すると、A/Bテストなどのアプリケーションの懸案事項はさまざまなレベルで悪い考えであり、放棄する必要があります。