A/B 테스트 및 기능 출시에 Varnish를 어떻게 활용합니까?

A/B 테스트 및 기능 출시에 Varnish를 어떻게 활용합니까?

오늘날 우리는 웹 레이어를 세상에 공개했습니다. 웹 레이어 앞에 Varnish를 추가하여 사이트 속도를 높이고 백엔드에 대한 호출을 줄이고 싶습니다. 그러나 우리에게는 몇 가지 우려 사항이 있으며 대부분의 사람들이 이에 대해 어떻게 접근하는지 궁금합니다.

  1. A/B 테스트 - 각 페이지의 두 "버전"을 어떻게 테스트하고 비교합니까? 내 말은, 바니시는 어떤 페이지를 제공해야 할지 어떻게 알 수 있다는 거죠? 각 페이지에 별도의 버전을 저장하는 경우와 방법은 무엇입니까?

  2. 기능 출시 - 간단한 기능 출시 메커니즘을 어떻게 설정하시겠습니까? 트래픽의 10%에만 새 기능/페이지를 열고 나중에 이를 20%로 늘리고 싶다고 가정해 보겠습니다.

  3. 코드 배포를 어떻게 처리합니까? 배포할 때마다 전체 바니시 캐시를 제거합니까? (매일 배포가 있습니다). 아니면 TTL을 사용하여 천천히 만료되게 하시겠습니까?

이러한 문제에 관한 아이디어와 예는 다음과 같습니다.매우감사합니다!

답변1

A/B 테스트 - 각 페이지의 두 "버전"을 어떻게 테스트하고 비교합니까? 내 말은, 바니시는 어떤 페이지를 제공해야 할지 어떻게 알 수 있다는 거죠? 각 페이지에 별도의 버전을 저장하는 경우와 방법은 무엇입니까?

여러 가지 선택 사항이 있습니다:

  • 간단히 다른 URL에 노출하십시오.
  • 특정 URL에 대한 캐시를 우회합니다. pass로 돌아와서 이 작업을 수행할 수 있습니다 vcl_recv. 이 같은:

    sub vcl_recv {
        if (req.url ~ "^/path/to/document") {
            return (pass);
        }
    }
    
  • 새 버전을 공개할 때 캐시를 명시적으로 제거합니다.

기능 출시 - 간단한 기능 출시 메커니즘을 어떻게 설정하시겠습니까? 트래픽의 10%에만 새 기능/페이지를 열고 나중에 이를 20%로 늘리고 싶다고 가정해 보겠습니다.

이 작업을 수행하는 "간단한" 방법이 있는지 잘 모르겠습니다. 파일 C에 임의의 코드를 넣을 수 있으므로 .vcl임의의 숫자를 선택한 다음 결과에 따라 적절한 백엔드 경로를 선택하는 로직을 추가할 수 있습니다.

코드 배포를 어떻게 처리합니까? 배포할 때마다 전체 바니시 캐시를 제거합니까? (매일 배포가 있습니다). 아니면 TTL을 사용하여 천천히 만료되게 하시겠습니까?

주요 변경 사항의 경우 캐시를 제거하고, 작은 변경 사항의 경우 만료되도록 놔둡니다.

관련 정보