검색

9.4.3. A/B 배포

download PDF

A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다. 각 버전에 대한 요청 부분을 제어하므로 테스트가 진행됨에 따라 새 버전에 대한 요청 비율을 늘리고 궁극적으로 이전 버전 사용을 중지할 수 있습니다. 각 버전의 요청 부하를 조정할 때 예상되는 성능을 제공하기 위해 각 서비스의 포드 수를 확장해야 할 수 있습니다.

소프트웨어 업그레이드 외에도 이 기능을 사용하여 사용자 인터페이스의 버전을 실험할 수 있습니다. 일부 사용자는 이전 버전을 보유하고 있고 일부는 새 버전을 보유하고 있기 때문에 다양한 버전에 대한 사용자의 반응을 평가하여 설계 결정을 알릴 수 있습니다.

이를 위해서는 이전 버전과 새 버전이 동시에 실행될 수 있을 정도로 충분히 유사해야 합니다. 버그 수정 릴리즈 및 새 기능이 이전 기능을 방해하지 않는 경우 일반적으로 사용됩니다. 버전이 제대로 작동하려면 N-1 호환성이 필요합니다.

OpenShift Container Platform은 웹 콘솔과 명령줄 인터페이스를 통해 N-1 호환성을 지원합니다.

9.4.3.1. A/B 테스트에 대한 부하 분산

사용자는 여러 서비스를 사용하여 경로를 설정합니다. 각 서비스는 애플리케이션의 버전을 처리합니다.

각 서비스에는 weight가 할당되고 각 서비스에 대한 일부 요청에는 service_weightsum_of_weights으로 나눈 값이 할당됩니다. 각 서비스의 weight는 서비스 끝점에 분배되므로 끝점 가중치의 합계는 서비스 weight입니다.

이 경로는 최대 4개의 서비스를 제공할 수 있습니다. 서비스 weight0~256 사이일 수 있습니다. weight0인 서비스는 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다. 서비스 weight0이 아닌 경우 각 끝점의 최소 weight1입니다. 이로 인해 끝점이 많은 서비스는 원하는 것보다 높은 가중치 로 끝날 수 있습니다. 이 경우 Pod 수를 줄여 원하는 부하 분산 가중치 를 가져옵니다. 자세한 내용은 대체 백엔드 및 가중치 섹션을 참조하십시오.

웹 콘솔을 통해 사용자는 가중치를 설정하고 그 사이에서 균형을 표시할 수 있습니다.

웹 콘솔에서 대체 백엔드 시각화

A/B 환경을 설정하려면 다음을 수행합니다.

  1. 애플리케이션 두 개를 생성하고 서로 다른 이름을 지정합니다. 각각 배포 구성을 생성합니다. 애플리케이션은 동일한 프로그램의 버전입니다. 하나는 일반적으로 현재 프로덕션 버전이며 다른 하나는 제안된 새 버전입니다.

    $ oc new-app openshift/deployment-example1 --name=ab-example-a
    $ oc new-app openshift/deployment-example2 --name=ab-example-b
  2. 서비스를 생성하기 위해 배포 구성을 노출합니다.

    $ oc expose dc/ab-example-a --name=ab-example-A
    $ oc expose dc/ab-example-b --name=ab-example-B

    이 시점에서 두 애플리케이션이 모두 배포되며 실행 중이며 서비스가 있습니다.

  3. 경로를 통해 외부에서 애플리케이션을 사용할 수 있도록 설정합니다. 이 시점에서 두 서비스를 노출할 수 있으며, 현재 프로덕션 버전을 노출하는 것이 편리할 수 있으며 후자는 경로를 수정하여 새 버전을 추가하는 것이 편리합니다.

    $ oc expose svc/ab-example-A

    ab-example.<project>.<router_domain> 에서 애플리케이션을 검색하여 원하는 버전이 표시되는지 확인합니다.

  4. 경로를 배포할 때 라우터는 서비스에 지정된 가중치 에 따라 트래픽을 분산합니다. 이 시점에는 기본값이 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 관리
  1. 경로 세부 정보 페이지(Application/Routes)로 이동합니다.
  2. 작업 메뉴에서 편집 을 선택합니다.
  3. 여러 서비스에서 트래픽 분할 을 확인합니다.
  4. Service Weights resume 는 각 서비스에 전송되는 트래픽의 백분율을 설정합니다.

    Service Weights

    두 개 이상의 서비스 간 트래픽 분할의 경우 상대 가중치는 각 서비스에 대해 0에서 256 사이의 정수로 지정됩니다.

    정수로 지정된 가중치

    트래픽 가중치는 분할되는 트래픽 간 애플리케이션의 확장 행에 있는 개요 에 표시됩니다.

9.4.3.1.2. CLI를 사용하여 Weights 관리

이 명령은 서비스를 관리하고 경로에 의해 부하를 분산하는 해당 가중치를 관리합니다.

$ oc set route-backends ROUTENAME [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

예를 들어, 다음은 ab-example-Aweight=198 인 기본 서비스로 설정하고 ab-example-Bweight=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 이미지가 표시되는지 확인합니다.

  1. 첫 번째 shard와 동일한 소스 이미지를 기반으로 두 번째 shard를 생성하고 고유한 값을 설정합니다.

    $ oc new-app openshift/deployment-example:v2 --name=ab-example-b --labels=ab-example=true SUBTITLE="shard B" COLOR="red"
  2. 새로 생성된 shard를 편집하여 모든 shard에 공통된 레이블 ab-example=true 를 설정합니다.

    $ oc edit dc/ab-example-b

    편집기에서 기존 deploymentconfig=ab-example-b 레이블과 함께 spec.selectorspec.template.metadata.labels 아래의 ab-example: "true" 행을 추가합니다. 편집기를 저장하고 종료합니다.

  3. 두 번째 shard의 재배포를 트리거하여 새 레이블을 가져옵니다.

    $ oc rollout latest dc/ab-example-b
  4. 이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지함) 및 라우터(기본적으로 쿠키를 통해)는 백엔드 서버에 대한 연결을 유지하려고 시도하므로 두 shard가 반환되지 않을 수 있습니다. 브라우저를 하나 또는 다른 shard에 강제 적용하려면 scale 명령을 사용합니다.

    $ oc scale dc/ab-example-a --replicas=0

    브라우저를 새로 고침하면 v2shard B (빨간색)가 표시됩니다.

    $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0

    브라우저를 새로 고치면 v1shard A (파란색)가 표시됩니다.

    두 shard에서 배포를 트리거하는 경우 해당 shard의 Pod만 영향을 받습니다. 배포 구성 oc edit dc/ab-example-a 또는 oc edit dc/ab-example-b 에서 SUBTITLE 환경 변수를 변경하여 배포를 쉽게 트리거할 수 있습니다. 5-7 단계를 반복하여 shard를 추가할 수 있습니다.

    참고

    이러한 단계는 향후 OpenShift Container Platform 버전에서 단순화됩니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.