A/B 테스트
개요
A/B 테스트 또는 카나리 배포 기술을 통해 개발자는 두 가지 이상의 웹 페이지 변형을 실험할 수 있습니다. 무작위로 변형을 사용자에게 보여준 다음 통계 분석을 통해 특정 비즈니스 목표에 더 잘 맞는 변형을 결정합니다. 예를 들어 제품 판매 증대를 목표로 제품 페이지의 UI 변형을 테스트할 수 있습니다.
아키텍처 관련 결정
기술 및 비즈니스 요구 사항에 따라 다양한 방식으로 A/B 테스트를 구현할 수 있습니다. 주요 기술적 결정 중 하나는 클라이언트 측, 엣지 서버 측(CDN 레벨) 또는 오리진 서버 측에서 변형 선택 로직을 실행할 위치입니다.
오리진 서버 측 변형 선택. 이 접근 방식에서는 A/B 선택이 웹 애플리케이션을 호스팅하는 오리진 서버에서 직접 실행됩니다. 이 접근 방식은 CDN에 구애받지 않지만 CDN 캐싱이나 정적 파일 호스팅과는 호환되지 않습니다. 완전히 동적인 서버 측 렌더링 웹 애플리케이션을 위한 옵션입니다.
엣지 서버 측 변형 선택. 이 접근 방식에서는 CDN 수준에서 변형 선택 결정을 내립니다. 이 접근 방식은 애플리케이션을 최소한으로 변경하거나 전혀 변경하지 않아도 되며 CDN 캐싱과 호환됩니다. CloudFront에서는 엣지 함수를 사용하여 A/B 테스트 로직을 구현할 수 있습니다. 엣지 함수는 외부 A/B 테스트 API 외에도 요청 속성(국가, 쿠키 등)을 사용하여 변형 중 하나를 선택하고 CloudFront가 캐시에서 이를 처리하도록 할 수 있습니다.
클라이언트 측 변형 선택. 이 접근 방식에서는 프런트엔드가 먼저 A/B 테스트 API에 요청하여 제공할 변형을 결정한 다음 응답에 따라 변형을 다운로드하고 브라우저에서 렌더링합니다. 이 접근 방식에서는 A/B 테스트가 CDN에 구애받지 않지만 애플리케이션과 밀접하게 연결되어 있으며 클라이언트 측의 추가 단계로 인해 추가 지연 시간이 발생합니다. 또한 정적으로 생성된 사이트(SSG)의 A/B 테스트와 같이 항상 사용할 수 있는 것이 아닙니다. 클라이언트 측 A/B 테스트를 구현하려면 CloudWatch Evidently를 사용할 수 있습니다. A/B 테스트 실험을 제어할 수 있는 클라이언트 SDK와 UI를 제공합니다. CloudWatch Evidently에 대한 실습 자습서를 보려면 이 워크숍을 살펴보세요.
엣지 서버측 A/B 테스트에 중점으로 보겠습니다. 비즈니스에 가장 적합한 구현을 설계하려면 다음과 같은 추가 질문을 고려해 보세요.
- 고정성이 필요한가요(예: 동일한 사용자에게 항상 동일한 변형이 적용되는 경우)? 고정성은 일반적으로 쿠키를 사용하여 구현됩니다.
- 사용자를 위한 변형을 선택하는 데 사용되는 차원은 무엇인가요? 국가, 사용자 ID 등
- A/B 테스트를 얼마나 자주 수행하나요? 여러 팀이 동시에 많은 실험을 실행하며 A/B 테스트를 많이 사용하려면 단순하고 가끔씩 실행되는 A/B 테스트에 비해 좀 더 정교한 구현이 필요합니다.
CloudFront의 엣지 함수를 사용한 A/B 테스트의 일부 엣지 서비스 측 구현에 대해 알아보려면 이 워크숍을 실습해 보세요. 다음 섹션에서는 앞서 언급한 워크숍에서 CloudFront를 사용하여 A/B 테스트의 두 가지 일반적인 구현을 공유합니다.
엣지 서버 측 A/B 테스트를 사용하는 일반적인 사용 사례
간헐적 A/B 테스트
기관 웹 사이트의 분기별 설계 개선과 같이 간헐적 A/B 테스트가 필요한 경우 실험 기간 동안 CloudFront Functions 기반 솔루션을 사용할 수 있습니다. 이 솔루션은 A/B 테스트를 실행하려는 페이지와 일치하는 페이지를 찾는 캐시 동작에 함수 2개를 구성합니다.
- 최종 사용자 요청 함수는 수신 요청의 실험 쿠키 값을 검사한 후 이를 기반으로 선택된 페이지 변형으로 URL을 다시 작성합니다. 쿠키가 없는 경우 이 함수는 사용자가 지정한 로직을 기반으로 변형을 선택합니다(예: 프랑스에서 오는 요청에 대해서만 변형 A의 경우 60%, 변형 B의 경우 40%).
- 최종 사용자 응답 함수는 쿠키가 아직 없는 경우 선택한 변형을 기반으로 클라이언트에 쿠키를 설정합니다. 이 실험 쿠키는 한 명의 사용자에게 항상 동일한 버전의 페이지가 수신되도록 하여 끊김 없는 웹 경험을 보장하는 데 사용됩니다.
변형 B의 백분율을 높이는 등 변형 선택 로직을 변경하려면 최종 사용자 이벤트의 함수 코드를 업데이트해야 하며, 일반적으로 완료하는 데 몇 초 정도 걸립니다. A/B 테스트 실험을 마친 후에는 엣지 함수를 제거하여 비용을 절감할 수 있습니다.
빈번한 A/B 테스트
매일 실험을 수행하여 웹 사이트에서 A/B 테스트를 지속적으로 수행하는 경우에도 이전의 CloudFront Function 기반 솔루션을 계속 사용할 수 있습니다. 하지만 변형 선택 파라미터(예: 변형 가중치)를 함수 코드에서 분리하는 것이 좋습니다. CloudFront KeyValueStore를 사용하여 함수 코드 외부에 이러한 파라미터를 저장할 수 있습니다. KeyValueStore는 글로벌(모든 PoP), 저지연 읽기,
대규모 키 값 데이터 스토어(초당 수백만 요청)에 적합합니다.
참고로 사용 사례에서 최대 크기(5MB) 또는 초당 몇 개의 API 직접 호출이라는 변경 속도 제한과 같은 KeyValueStore 할당량을 준수해야 합니다.
고급 A/B 테스트
CloudFront Function 기반 솔루션으로 A/B 테스트 요구 사항이 충족되지 않는 경우 (예: 사용 사례에서 KeyValueStore 할당량이 제한되는 경우) Lambda@Edge 기반 솔루션을 고려하는 것이 좋습니다. 대규모 전자 상거래 웹 사이트를 운영할 때 웹 사이트의 여러 부분에서 빠른 속도로 동시 실험을 실행하는 경우가 여기에 해당합니다. 이 시나리오에서는 CloudFront Function 대신 Lambda@Edge를 외부 데이터 소스(예: DynamoDB 글로벌 테이블)에 사용하여 A/B 테스트 파라미터를 저장합니다. LaunchDarkly와 같은 특성 관리 도구는 DynamoDB와 통합되므로 A/B 테스트 파라미터가 유지됩니다.
