검색

4.4.5. A/B 배포

download PDF

A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다.

각 버전에 대한 요청 분배를 사용자가 제어하므로 테스트를 진행하면서 새 버전에 대한 요청 비율을 늘려 결국 이전 버전의 사용을 중지할 수 있습니다. 각 버전에 대한 요청 부하를 조정할 때 필요한 성능을 제공하기 위해 각 서비스의 Pod 수도 스케일링해야 할 수 있습니다.

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

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

OpenShift Container Platform은 웹 콘솔과 CLI를 통해 N-1 호환성을 지원합니다.

4.4.5.1. A/B 테스트의 부하 분산

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

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

이 경로는 최대 4개의 서비스를 제공할 수 있습니다. 서비스 weight0~256 사이일 수 있습니다. weight0인 서비스는 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다. 서비스 weight0이 아닌 경우 각 끝점의 최소 weight1입니다. 이로 인해 끝점이 많은 서비스는 weight가 의도한 것보다 높을 수 있습니다. 이 경우 Pod 수를 줄이면 예상되는 부하 분산 weight를 얻을 수 있습니다.

프로세스

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

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

    1. 첫 번째 애플리케이션을 생성합니다. 다음 예제에서는 ab-example-a라는 애플리케이션을 생성합니다.

      $ oc new-app openshift/deployment-example --name=ab-example-a
    2. 두 번째 애플리케이션을 생성합니다.

      $ oc new-app openshift/deployment-example:v2 --name=ab-example-b

      두 애플리케이션 모두 배포되고 서비스가 생성됩니다.

  2. 경로를 통해 외부에서 애플리케이션을 사용할 수 있도록 설정합니다. 이 시점에서는 둘 중 하나를 노출할 수 있습니다. 현재 프로덕션 버전을 먼저 노출하고 나중에 경로를 수정하여 새 버전을 추가하는 것이 편리합니다.

    $ oc expose svc/ab-example-a

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

  3. 경로를 배포할 때 라우터는 서비스에 지정된 weights에 따라 트래픽을 분산합니다. 이 시점에는 기본값이 weight=1인 단일 서비스가 있으므로 모든 요청이 해당 서비스로 이동합니다. 기타 서비스를 alternateBackends로 추가하고 weights를 조정하면 A/B 설정이 활성화됩니다. 이 작업은 oc set route-backends 명령을 실행하거나 경로를 편집하여 수행할 수 있습니다.

    oc set route-backend0으로 설정하면 서비스가 부하 분산에 참여하지 않지만 기존 영구 연결은 계속 제공합니다.

    참고

    경로를 변경하면 다양한 서비스에 대한 트래픽 부분만 변경됩니다. 예상되는 부하를 처리하기 위해 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. 웹 콘솔을 사용하여 기존 경로의 가중치 관리

프로세스

  1. 네트워킹 경로 페이지로 이동합니다.
  2. 편집할 경로 옆에 있는 작업 메뉴 kebab 를 클릭하고 경로 편집을 선택합니다.
  3. YAML 파일을 편집합니다. 다른 대상 참조 오브젝트에 대한 대상의 상대적 가중치를 지정하는 weight 값을 0에서 256 사이의 정수가 되도록 업데이트합니다. 값 0은 이 백엔드에 대한 요청을 비활성화합니다. 기본값은 100입니다. 옵션에 대한 자세한 내용을 보려면 oc explain routes.spec.alternateBackends를 실행합니다.
  4. 저장을 클릭합니다.
4.4.5.1.2. 웹 콘솔을 사용하여 새 경로의 가중치 관리
  1. 네트워킹 경로 페이지로 이동합니다.
  2. 경로 생성을 클릭합니다.
  3. 경로 이름을 입력합니다.
  4. 서비스를 선택합니다.
  5. 대체 서비스 추가를 클릭합니다.
  6. 가중치대체 서비스 가중치 값을 입력합니다. 다른 대상과 비교했을 때 상대적 가중치를 나타내는 0에서 255 사이의 숫자를 입력합니다. 기본값은 100입니다.
  7. 대상 포트를 선택합니다.
  8. Create를 클릭합니다.
4.4.5.1.3. CLI를 사용하여 가중치 관리

프로세스

  1. 경로에서 부하를 분산하는 서비스와 해당 가중치를 관리하려면 oc set route-backends 명령을 사용합니다.

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

    예를 들어 다음 명령은 ab-example-aweight=198인 기본 서비스로 설정하고 ab-example-bweight=2인 첫 번째 대체 서비스로 설정합니다.

    $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2

    즉 99%의 트래픽은 서비스 ab-example-a로 전송되고 1%는 서비스 ab-example-b로 전송됩니다.

    이 명령에서는 배포를 스케일링하지 않습니다. 요청 부하를 처리할 수 있는 Pod를 충분히 확보하기 위해서는 스케일링해야 할 수 있습니다.

  2. 플래그 없이 명령을 실행하여 현재 구성을 확인합니다.

    $ 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%)

  3. 자체 또는 기본 서비스에 대한 개별 서비스의 가중치를 변경하려면 --adjust 플래그를 사용합니다. 백분율을 지정하면 기본 또는 첫 번째 대체(기본을 지정하는 경우)를 기준으로 서비스가 조정됩니다. 다른 백엔드가 있는 경우 해당 가중치는 변경된 값에 비례하여 유지됩니다.

    다음 예제에서는 ab-example-aab-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 플래그는 모든 서비스의 weight100으로 설정합니다.

    $ oc set route-backends ab-example --equal

    --zero 플래그는 모든 서비스의 weight0으로 설정합니다. 그러면 모든 요청에서 503 오류가 반환됩니다.

    참고

    일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다.

4.4.5.1.4. 하나의 서비스, 여러 Deployment 오브젝트

절차

  1. 새 애플리케이션을 생성하여 모든 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입니다.

  2. 경로를 통해 애플리케이션을 사용 가능하게 하거나 서비스 IP를 직접 사용합니다.

    $ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true
    $ oc expose service ab-example
  3. ab-example-<project_name>.<router_domain>에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
  4. 첫 번째 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
  5. 이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지하여) 및 라우터(기본적으로 쿠키를 통해)에서 백엔드 서버에 대한 연결을 유지하려고 하기 때문에 두 shard가 반환되지 않을 수 있습니다.

    브라우저를 하나 또는 다른 shard에 강제 적용하려면 다음을 수행합니다.

    1. oc scale 명령을 사용하여 ab-example-a의 복제본 수를 0으로 줄입니다.

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

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

    2. ab-example-a를 복제본 수 1로, ab-example-b0으로 스케일링합니다.

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

      브라우저를 새로고침하여 v1shard A(파란색)를 표시합니다.

  6. 둘 중 하나의 shard에서 배포를 트리거하면 해당 shard의 Pod만 영향을 받습니다. Deployment 오브젝트에서 SUBTITLE 환경 변수를 변경하여 배포를 트리거할 수 있습니다.

    $ oc edit dc/ab-example-a

    또는

    $ oc edit dc/ab-example-b
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.