9.4.3. A/B 배포
A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다. 각 버전에 대한 요청 부분을 제어하므로 테스트가 진행됨에 따라 새 버전에 대한 요청 비율을 늘리고 궁극적으로 이전 버전 사용을 중지할 수 있습니다. 각 버전의 요청 부하를 조정할 때 예상되는 성능을 제공하기 위해 각 서비스의 포드 수를 확장해야 할 수 있습니다.
소프트웨어 업그레이드 외에도 이 기능을 사용하여 사용자 인터페이스의 버전을 실험할 수 있습니다. 일부 사용자는 이전 버전을 보유하고 있고 일부는 새 버전을 보유하고 있기 때문에 다양한 버전에 대한 사용자의 반응을 평가하여 설계 결정을 알릴 수 있습니다.
이를 위해서는 이전 버전과 새 버전이 동시에 실행될 수 있을 정도로 충분히 유사해야 합니다. 버그 수정 릴리즈 및 새 기능이 이전 기능을 방해하지 않는 경우 일반적으로 사용됩니다. 버전이 제대로 작동하려면 N-1 호환성이 필요합니다.
OpenShift Container Platform은 웹 콘솔과 명령줄 인터페이스를 통해 N-1 호환성을 지원합니다.
9.4.3.1. A/B 테스트에 대한 부하 분산
사용자는 여러 서비스를 사용하여 경로를 설정합니다. 각 서비스는 애플리케이션의 버전을 처리합니다.
각 서비스에는 weight가 할당되고 각 서비스에 대한 일부 요청에는 service_weight을 sum_of_weights으로 나눈 값이 할당됩니다. 각 서비스의 weight는 서비스 끝점에 분배되므로 끝점 가중치의 합계는 서비스 weight입니다.
이 경로는 최대 4개의 서비스를 제공할 수 있습니다. 서비스 weight는 0~256 사이일 수 있습니다. weight가 0인 서비스는 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다. 서비스 weight가 0이 아닌 경우 각 끝점의 최소 weight는 1입니다. 이로 인해 끝점이 많은 서비스는 원하는 것보다 높은 가중치 로 끝날 수 있습니다. 이 경우 Pod 수를 줄여 원하는 부하 분산 가중치 를 가져옵니다. 자세한 내용은 대체 백엔드 및 가중치 섹션을 참조하십시오.
웹 콘솔을 통해 사용자는 가중치를 설정하고 그 사이에서 균형을 표시할 수 있습니다.
A/B 환경을 설정하려면 다음을 수행합니다.
애플리케이션 두 개를 생성하고 서로 다른 이름을 지정합니다. 각각 배포 구성을 생성합니다. 애플리케이션은 동일한 프로그램의 버전입니다. 하나는 일반적으로 현재 프로덕션 버전이며 다른 하나는 제안된 새 버전입니다.
$ oc new-app openshift/deployment-example1 --name=ab-example-a $ oc new-app openshift/deployment-example2 --name=ab-example-b
서비스를 생성하기 위해 배포 구성을 노출합니다.
$ oc expose dc/ab-example-a --name=ab-example-A $ oc expose dc/ab-example-b --name=ab-example-B
이 시점에서 두 애플리케이션이 모두 배포되며 실행 중이며 서비스가 있습니다.
경로를 통해 외부에서 애플리케이션을 사용할 수 있도록 설정합니다. 이 시점에서 두 서비스를 노출할 수 있으며, 현재 프로덕션 버전을 노출하는 것이 편리할 수 있으며 후자는 경로를 수정하여 새 버전을 추가하는 것이 편리합니다.
$ oc expose svc/ab-example-A
ab-example.<project>.<router_domain>에서 애플리케이션을 검색하여 원하는 버전이 표시되는지 확인합니다.경로를 배포할 때 라우터는 서비스에 지정된
가중치에 따라 트래픽을 분산합니다. 이 시점에는 기본값이weight=1인 단일 서비스가 있으므로 모든 요청이 해당 서비스로 이동합니다. 기타 서비스를alternateBackends로 추가하고가중치를 조정하면 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 ...
9.4.3.1.1. 웹 콘솔을 사용하여 Weights 관리
- 경로 세부 정보 페이지(Application/Routes)로 이동합니다.
- 작업 메뉴에서 편집 을 선택합니다.
- 여러 서비스에서 트래픽 분할 을 확인합니다.
Service Weights resume 는 각 서비스에 전송되는 트래픽의 백분율을 설정합니다.
두 개 이상의 서비스 간 트래픽 분할의 경우 상대 가중치는 각 서비스에 대해 0에서 256 사이의 정수로 지정됩니다.
트래픽 가중치는 분할되는 트래픽 간 애플리케이션의 확장 행에 있는 개요 에 표시됩니다.
9.4.3.1.2. CLI를 사용하여 Weights 관리
이 명령은 서비스를 관리하고 경로에 의해 부하를 분산하는 해당 가중치를 관리합니다.
$ oc set route-backends ROUTENAME [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]
예를 들어, 다음은 ab-example-A 를 weight=198 인 기본 서비스로 설정하고 ab-example-B 를 weight=2 인 첫 번째 대체 서비스로 설정합니다.
$ oc set route-backends web ab-example-A=198 ab-example-B=2
즉, 99%의 트래픽이 서비스 ab-example-A 로 전송되고 1%는 서비스 ab-example-B 로 전송됩니다.
이 명령은 배포 구성을 확장하지 않습니다. 요청 로드를 처리하기에 충분한 Pod가 있어야 할 수 있습니다.
플래그가 없는 명령은 현재 구성을 표시합니다.
$ oc set route-backends web NAME KIND TO WEIGHT routes/web Service ab-example-A 198 (99%) routes/web Service ab-example-B 2 (1%)
--adjust 플래그를 사용하면 자체 또는 기본 서비스에 대한 개별 서비스의 가중치를 변경할 수 있습니다. 백분율을 지정하면 기본 또는 첫 번째 대체(기본을 지정하는 경우)에 상대적인 서비스가 조정됩니다. 다른 백엔드가 있는 경우 해당 가중치는 변경된 항목에 비례하여 유지됩니다.
$ oc set route-backends web --adjust ab-example-A=200 ab-example-B=10 $ oc set route-backends web --adjust ab-example-B=5% $ oc set route-backends web --adjust ab-example-B=+15%
--equal 플래그는 모든 서비스의 weight 를 100으로 설정합니다.
$ oc set route-backends web --equal
--zero 플래그는 모든 서비스의 weight 를 0으로 설정합니다. 모든 요청은 503 오류와 함께 반환됩니다.
일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다.
9.4.3.1.3. 서비스 1개, 다중 배포 구성
라우터가 설치된 경우 경로를 통해 애플리케이션을 사용할 수 있도록 설정합니다(또는 서비스 IP를 직접 사용).
$ oc expose svc/ab-example
ab-example.<project>.<router_domain> 에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
첫 번째 shard와 동일한 소스 이미지를 기반으로 두 번째 shard를 생성하고 고유한 값을 설정합니다.
$ oc new-app openshift/deployment-example:v2 --name=ab-example-b --labels=ab-example=true SUBTITLE="shard B" COLOR="red"
새로 생성된 shard를 편집하여 모든 shard에 공통된 레이블
ab-example=true를 설정합니다.$ oc edit dc/ab-example-b
편집기에서 기존
deploymentconfig=ab-example-b레이블과 함께spec.selector및spec.template.metadata.labels아래의ab-example: "true"행을 추가합니다. 편집기를 저장하고 종료합니다.두 번째 shard의 재배포를 트리거하여 새 레이블을 가져옵니다.
$ oc rollout latest dc/ab-example-b
이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지함) 및 라우터(기본적으로 쿠키를 통해)는 백엔드 서버에 대한 연결을 유지하려고 시도하므로 두 shard가 반환되지 않을 수 있습니다. 브라우저를 하나 또는 다른 shard에 강제 적용하려면 scale 명령을 사용합니다.
$ oc scale dc/ab-example-a --replicas=0
브라우저를 새로 고침하면 v2 및 shard B (빨간색)가 표시됩니다.
$ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
브라우저를 새로 고치면 v1 및 shard A (파란색)가 표시됩니다.
두 shard에서 배포를 트리거하는 경우 해당 shard의 Pod만 영향을 받습니다. 배포 구성
oc edit dc/ab-example-a또는oc edit dc/ab-example-b에서SUBTITLE환경 변수를 변경하여 배포를 쉽게 트리거할 수 있습니다. 5-7 단계를 반복하여 shard를 추가할 수 있습니다.참고이러한 단계는 향후 OpenShift Container Platform 버전에서 단순화됩니다.
