폴리머 웹 컴포넌트에서 A/B 테스트를 수행하는 방법은 무엇입니까?

Question

나는 고객에게 A/B 테스트를 원한다.

내가 아는 한, 대부분의 경우 LoadBalancer 레벨 (Kubernetes)에서 사용자를 특정 버전의 응용 프로그램으로 리디렉션합니다 (예 : 새 버전의 Gmail과 릴리스가 출시 됨).

이제 웹 구성 요소를 사용하면이 고객은 구성 요소에서 특정 요구 사항이 충족 될 경우 기능이 켜지는 "dom-if"종류의 상황을 원합니다. 물론 오버 헤드가 추가됩니다.

이것이 길인지 궁금합니다. 이 고객에 대한 그들의 추론은 구성 요소가 100 개의 응용 프로그램에서 사용될 수 있고 빌드를 작성하고 이에 대한 작업을 수행하는 것이 너무 번거롭고 마이크로 레벨에서 (구성 요소 에서처럼) 가장 좋은 방법이라고 생각할 수 있습니다. 그들은 Linkedin/AirBnB를 따르고 있습니다.

내가 아는 한이 회사는 웹 구성 요소를 사용하지 않습니다.

질문은 : 무엇이 바람직합니까? 마이크로 레벨 또는 응용 프로그램 수준에서 A/B 테스트를 수행합니다 (그리고 kubernetes와 같은로드 밸런서 사용).

Answer 1

이 질문이 전체 질문을 다루는 지 확실하지 않지만 Microservice 아키텍처에서는 자체적으로 각 서비스 내에서 테스트 할 것입니다.

귀하의 서비스를 호스팅하기 위해 귀하의 플랫폼으로 Kubernetes를 말하면 LoadBalancer 서비스는 Deployments에서 Pods을 선택할 수 있습니다. 각 Deployment은 다른 컨테이너/응용 프로그램 버전을 제공하거나 동일한 컨테이너를 제공하지만 설정이 다를 수 있습니다.

단일 서비스는 두 배포의 포드와 일치하는 선택 자 (app: testme)를 가지고 있습니다. 배포는 동일한 이미지()에서 컨테이너를 정의하지만 환경 변수는 다릅니다. 또한 다른 양의 복제본을 사용하면 하나 또는 다른 옵션으로 라우팅되는 트래픽의 비율을 다르게 지정할 수 있습니다.

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 테스트와 같은 응용 프로그램 문제를 해결하는 것은 여러 단계에서 좋지 않은 아이디어이므로 포기해야합니다.