4.4.5. A/B 배포
A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다.
각 버전에 대한 요청 분배를 사용자가 제어하므로 테스트를 진행하면서 새 버전에 대한 요청 비율을 늘려 결국 이전 버전의 사용을 중지할 수 있습니다. 각 버전에 대한 요청 부하를 조정할 때 필요한 성능을 제공하기 위해 각 서비스의 Pod 수도 스케일링해야 할 수 있습니다.
소프트웨어 업그레이드 외에도 이 기능을 사용하여 사용자 인터페이스의 버전을 실험할 수 있습니다. 일부 사용자는 이전 버전을 보유하고 있고 일부는 새 버전을 보유하고 있기 때문에 다양한 버전에 대한 사용자의 반응을 평가하여 설계 결정을 알릴 수 있습니다.
이 배포가 효과적이려면 이전 버전과 새 버전이 동시에 실행될 수 있을 정도로 충분히 유사해야 합니다. 버그 수정 릴리즈 및 새 기능이 이전 기능을 방해하지 않는 경우 일반적으로 사용됩니다. 버전이 제대로 작동하려면 N-1 호환성이 필요합니다.
OpenShift Container Platform은 웹 콘솔과 CLI를 통해 N-1 호환성을 지원합니다.
4.4.5.1. A/B 테스트의 부하 분산
사용자는 다양한 서비스를 통해 경로를 설정합니다. 각 서비스는 애플리케이션의 버전을 처리합니다.
각 서비스에는 weight
가 할당되고 각 서비스에 대한 일부 요청에는 service_weight
을 sum_of_weights
으로 나눈 값이 할당됩니다. 각 서비스의 weight
는 서비스 끝점에 분배되므로 끝점 가중치
의 합계는 서비스 weight
입니다.
이 경로는 최대 4개의 서비스를 제공할 수 있습니다. 서비스 weight
는 0
~256
사이일 수 있습니다. weight
가 0
인 서비스는 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다. 서비스 weight
가 0
이 아닌 경우 각 끝점의 최소 weight
는 1
입니다. 이로 인해 끝점이 많은 서비스는 weight
가 의도한 것보다 높을 수 있습니다. 이 경우 Pod 수를 줄이면 예상되는 부하 분산 weight
를 얻을 수 있습니다.
프로세스
A/B 환경을 설정하려면 다음을 수행합니다.
애플리케이션 두 개를 생성하고 서로 다른 이름을 지정합니다. 각각
Deployment
오브젝트를 생성합니다. 두 애플리케이션은 동일한 프로그램의 버전에 해당합니다. 하나는 일반적으로 현재 프로덕션 버전이며 다른 하나는 제안된 새 버전입니다.첫 번째 애플리케이션을 생성합니다. 다음 예제에서는
ab-example-a
라는 애플리케이션을 생성합니다.$ oc new-app openshift/deployment-example --name=ab-example-a
두 번째 애플리케이션을 생성합니다.
$ oc new-app openshift/deployment-example:v2 --name=ab-example-b
두 애플리케이션 모두 배포되고 서비스가 생성됩니다.
경로를 통해 외부에서 애플리케이션을 사용할 수 있도록 설정합니다. 이 시점에서는 둘 중 하나를 노출할 수 있습니다. 현재 프로덕션 버전을 먼저 노출하고 나중에 경로를 수정하여 새 버전을 추가하는 것이 편리합니다.
$ oc expose svc/ab-example-a
ab-example-a.<project>.<router_domain>
에서 애플리케이션을 검색하여 예상 버전이 표시되는지 확인합니다.경로를 배포할 때 라우터는 서비스에 지정된
weights
에 따라 트래픽을 분산합니다. 이 시점에는 기본값이weight=1
인 단일 서비스가 있으므로 모든 요청이 해당 서비스로 이동합니다. 기타 서비스를alternateBackends
로 추가하고weights
를 조정하면 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 ...
4.4.5.1.1. 웹 콘솔을 사용하여 기존 경로의 가중치 관리
프로세스
-
네트워킹
경로 페이지로 이동합니다. - 편집할 경로 옆에 있는 작업 메뉴 를 클릭하고 경로 편집을 선택합니다.
-
YAML 파일을 편집합니다. 다른 대상 참조 오브젝트에 대한 대상의 상대적 가중치를 지정하는
weight
값을0
에서256
사이의 정수가 되도록 업데이트합니다. 값0
은 이 백엔드에 대한 요청을 비활성화합니다. 기본값은100
입니다. 옵션에 대한 자세한 내용을 보려면oc explain routes.spec.alternateBackends
를 실행합니다. - 저장을 클릭합니다.
4.4.5.1.2. 웹 콘솔을 사용하여 새 경로의 가중치 관리
-
네트워킹
경로 페이지로 이동합니다. - 경로 생성을 클릭합니다.
- 경로 이름을 입력합니다.
- 서비스를 선택합니다.
- 대체 서비스 추가를 클릭합니다.
-
가중치 및 대체 서비스 가중치 값을 입력합니다. 다른 대상과 비교했을 때 상대적 가중치를 나타내는
0
에서255
사이의 숫자를 입력합니다. 기본값은100
입니다. - 대상 포트를 선택합니다.
- Create를 클릭합니다.
4.4.5.1.3. CLI를 사용하여 가중치 관리
프로세스
경로에서 부하를 분산하는 서비스와 해당 가중치를 관리하려면
oc set route-backends
명령을 사용합니다.$ 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 ab-example ab-example-a=198 ab-example-b=2
즉 99%의 트래픽은 서비스
ab-example-a
로 전송되고 1%는 서비스ab-example-b
로 전송됩니다.이 명령에서는 배포를 스케일링하지 않습니다. 요청 부하를 처리할 수 있는 Pod를 충분히 확보하기 위해서는 스케일링해야 할 수 있습니다.
플래그 없이 명령을 실행하여 현재 구성을 확인합니다.
$ oc set route-backends ab-example
출력 예
NAME KIND TO WEIGHT routes/ab-example Service ab-example-a 198 (99%) routes/ab-example Service ab-example-b 2 (1%)
자체 또는 기본 서비스에 대한 개별 서비스의 가중치를 변경하려면
--adjust
플래그를 사용합니다. 백분율을 지정하면 기본 또는 첫 번째 대체(기본을 지정하는 경우)를 기준으로 서비스가 조정됩니다. 다른 백엔드가 있는 경우 해당 가중치는 변경된 값에 비례하여 유지됩니다.다음 예제에서는
ab-example-a
및ab-example-b
서비스의 가중치를 변경합니다.$ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10
또는 백분율을 지정하여 서비스 가중치를 변경합니다.
$ oc set route-backends ab-example --adjust ab-example-b=5%
백분율 선언 앞에
+
를 지정하면 현재 설정을 기준으로 가중치를 조정할 수 있습니다. 예를 들면 다음과 같습니다.$ oc set route-backends ab-example --adjust ab-example-b=+15%
--equal
플래그는 모든 서비스의weight
를100
으로 설정합니다.$ oc set route-backends ab-example --equal
--zero
플래그는 모든 서비스의weight
를0
으로 설정합니다. 그러면 모든 요청에서 503 오류가 반환됩니다.참고일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다.
4.4.5.1.4. 하나의 서비스, 여러 Deployment
오브젝트
절차
새 애플리케이션을 생성하여 모든 shard에 공통된 라벨
ab-example=true
를 추가합니다.$ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA $ oc delete svc/ab-example-a
애플리케이션이 배포되고 서비스가 생성됩니다. 이것이 첫 번째 shard입니다.
경로를 통해 애플리케이션을 사용 가능하게 하거나 서비스 IP를 직접 사용합니다.
$ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true $ oc expose service ab-example
-
ab-example-<project_name>.<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" --as-deployment-config=true $ oc delete svc/ab-example-b
이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지하여) 및 라우터(기본적으로 쿠키를 통해)에서 백엔드 서버에 대한 연결을 유지하려고 하기 때문에 두 shard가 반환되지 않을 수 있습니다.
브라우저를 하나 또는 다른 shard에 강제 적용하려면 다음을 수행합니다.
oc scale
명령을 사용하여ab-example-a
의 복제본 수를0
으로 줄입니다.$ oc scale dc/ab-example-a --replicas=0
브라우저를 새로고침하여
v2
및shard B
(빨간색)를 표시합니다.ab-example-a
를 복제본 수1
로,ab-example-b
를0
으로 스케일링합니다.$ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
브라우저를 새로고침하여
v1
및shard A
(파란색)를 표시합니다.
둘 중 하나의 shard에서 배포를 트리거하면 해당 shard의 Pod만 영향을 받습니다.
Deployment
오브젝트에서SUBTITLE
환경 변수를 변경하여 배포를 트리거할 수 있습니다.$ oc edit dc/ab-example-a
또는
$ oc edit dc/ab-example-b