7.4. 경로 기반 배포 전략 사용
배포 전략에서는 애플리케이션을 개발하는 방식을 제공합니다. 일부 전략에서는 Deployment
오브젝트를 사용하여 애플리케이션으로 확인되는 모든 경로의 사용자가 확인할 수 있는 변경을 수행합니다. 이 섹션에 설명된 것과 같은 기타 고급 전략에서는 Deployment
오브젝트와 함께 라우터 기능을 사용하여 특정 경로에 영향을 미칩니다.
가장 일반적인 경로 기반 전략은 Blue-Green 배포를 사용하는 것입니다. 테스트 및 평가를 위해 새 버전(Green 버전)이 제공되지만 사용자는 여전히 안정적인 버전(Blue 버전)을 사용합니다. 사용자는 준비가 되면 Green 버전으로 전환합니다. 문제가 발생하면 Blue 버전으로 다시 전환할 수 있습니다.
일반적인 대체 전략은 동시에 활성 상태인 A/B 버전을 사용하는 것입니다. 즉 일부 사용자는 한 버전을 사용하고 나머지 사용자는 다른 버전을 사용합니다. 이 전략은 사용자 인터페이스 변경 및 기타 기능을 실험하여 사용자 피드백을 받는 데 사용할 수 있습니다. 또한 문제가 제한된 수의 사용자에게 영향을 미치는 프로덕션 컨텍스트에서 작업이 적절한지 확인하는 데 사용할 수도 있습니다.
카나리아 배포는 새 버전을 테스트하지만 문제가 발견되면 신속하게 이전 버전으로 대체합니다. 이는 위의 두 전략 모두에서 수행할 수 있습니다.
경로 기반 배포 전략에서는 서비스의 Pod 수를 확장하지 않습니다. 원하는 성능 특성을 유지 관리하려면 배포 구성을 확장해야 할 수 있습니다.
7.4.1. 프록시 shard 및 트래픽 분할
프로덕션 환경에서는 특정 shard에 전달되는 트래픽 분배를 정확하게 제어할 수 있습니다. 많은 수의 인스턴스를 처리할 때는 개별 shard의 상대적 스케일을 사용하여 백분율 기반 트래픽을 구현할 수 있습니다. 이는 수신하는 트래픽을 다른 곳에서 실행되는 별도의 서비스 또는 애플리케이션으로 전달하거나 분할하는 프록시 shard와 잘 결합합니다.
가장 간단한 구성에서 프록시는 변경되지 않은 요청을 전달합니다. 더 복잡한 설정에서는 들어오는 요청을 복제하여 애플리케이션의 로컬 인스턴스와 별도의 클러스터에 보내 결과를 비교할 수 있습니다. 기타 패턴에는 DR 설치 캐시를 준비 상태로 유지하거나 분석을 위해 들어오는 트래픽을 샘플링하는 작업이 포함됩니다.
모든 TCP(또는 UDP) 프록시는 원하는 shard에서 실행할 수 있습니다. oc scale
명령을 사용하여 프록시 shard에서 요청을 처리하는 상대적 인스턴스 수를 변경합니다. 더 복잡한 트래픽 관리에는 비례 분산 기능을 사용하여 OpenShift Container Platform 라우터를 사용자 정의하는 것이 좋습니다.
7.4.2. N-1 호환성
새 코드와 이전 코드가 동시에 포함된 애플리케이션에서는 새 코드에서 작성한 데이터를 이전 버전의 코드에서 읽고 처리(또는 정상적으로 무시)할 수 있도록 주의해야 합니다. 이는 스키마 진화라고도 하며 복잡한 문제에 해당합니다.
디스크, 데이터베이스, 임시 캐시에 저장된 데이터 또는 사용자 브라우저 세션의 일부 등 다양한 형태를 취할 수 있습니다. 대부분의 웹 애플리케이션에서는 롤링 배포를 지원할 수 있지만 이를 처리할 수 있도록 애플리케이션을 테스트하고 설계하는 것이 중요합니다.
일부 애플리케이션의 경우 이전 코드와 새 코드가 나란히 실행되는 기간이 짧기 때문에 버그 또는 일부 실패한 사용자 트랜잭션이 허용됩니다. 다른 애플리케이션의 경우 실패 패턴으로 인해 전체 애플리케이션이 작동하지 않을 수 있습니다.
N-1 호환성을 검증하는 한 가지 방법은 A/B 배포를 사용하는 것입니다. 즉 테스트 환경에서 제어되는 방식으로 이전 코드와 새 코드를 동시에 실행한 후 새 배포로 이동하는 트래픽으로 인해 이전 배포가 실패하지 않는지 확인하는 것입니다.
7.4.3. 정상적인 종료
OpenShift Container Platform 및 Kubernetes는 부하 분산 순환 작업에서 애플리케이션 인스턴스를 제거하기 전에 종료할 시간을 제공합니다. 그러나 애플리케이션은 종료하기 전에 사용자 연결을 명확하게 종료해야 합니다.
종료 시 OpenShift Container Platform은 컨테이너의 프로세스에 TERM
신호를 보냅니다. 애플리케이션 코드는 SIGTERM
을 수신하면 새 연결을 허용하지 않습니다. 이로 인해 로드 밸런서에서 트래픽을 활성 상태의 다른 인스턴스로 라우팅합니다. 그러면 애플리케이션 코드는 열려 있는 모든 연결이 닫힐 때까지 기다리거나 종료되기 전 다음 기회에 개별 연결을 정상적으로 종료합니다.
정상 종료 기간이 만료된 후 종료되지 않은 프로세스에는 KILL
신호가 전송되어 프로세스가 즉시 종료됩니다. Pod 또는 Pod 템플릿의 terminationGracePeriodSeconds
속성은 정상 종료 기간(기본값 30초)을 제어하고 필요에 따라 애플리케이션별로 사용자 지정할 수 있습니다.
7.4.4. Blue-Green 배포
Blue-Green 배포에는 두 가지 버전의 애플리케이션을 동시에 실행하고 프로덕션 내 버전(Blue 버전)에서 최신 버전(Green 버전)으로 트래픽을 이동하는 작업이 포함됩니다. 롤링 전략 또는 전환 서비스를 경로에서 사용할 수 있습니다.
대다수의 애플리케이션이 영구 데이터에 의존하기 때문에 N-1 호환성을 지원하는 애플리케이션이 있어야 합니다. 그러면 데이터 계층 복사본을 두 개 생성하여 데이터를 공유하고 데이터베이스, 저장소 또는 디스크 간 실시간 마이그레이션을 구현할 수 있습니다.
새 버전을 테스트하는 데 사용되는 데이터를 떠올려 보십시오. 데이터가 프로덕션 데이터라면 새 버전의 버그로 인해 프로덕션 버전에 장애가 발생할 수 있습니다.
7.4.4.1. Blue-Green 배포 설정
Blue-Green 배포에서는 두 개의 Deployment
오브젝트를 사용합니다. 둘 다 실행되고 프로덕션의 항목은 경로에서 지정하는 서비스에 따라 달라지며 각 Deployment
오브젝트는 다른 서비스에 노출됩니다.
경로는 웹(HTTP 및 HTTPS) 트래픽을 위한 것이므로 이 기술은 웹 애플리케이션에 적합합니다.
새 버전의 새 경로를 생성하고 테스트할 수 있습니다. 준비되었을 때 새 서비스를 가리키도록 프로덕션 경로의 서비스를 변경하면 새(Green) 버전이 활성화됩니다.
필요한 경우 서비스를 이전 버전(Blue)으로 전환하여 롤백할 수 있습니다.
프로세스
독립된 애플리케이션 구성 요소 두 개를 생성합니다.
example-blue
서비스에서v1
이미지를 실행하는 예제 애플리케이션의 복사본을 생성합니다.$ oc new-app openshift/deployment-example:v1 --name=example-blue
example-green
서비스에서v2
이미지를 사용하는 두 번째 복사본을 생성합니다.$ oc new-app openshift/deployment-example:v2 --name=example-green
이전 서비스를 가리키는 경로를 생성합니다.
$ oc expose svc/example-blue --name=bluegreen-example
-
bluegreen-example-<project>.<router_domain>
에서 애플리케이션을 검색하여v1
이미지가 표시되는지 확인합니다. 경로를 편집하고 서비스 이름을
example-green
으로 변경합니다.$ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}'
-
경로가 변경되었는지 확인하려면
v2
이미지가 표시될 때까지 브라우저를 새로 고칩니다.
7.4.5. A/B 배포
A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다.
각 버전에 대한 요청 분배를 사용자가 제어하므로 테스트를 진행하면서 새 버전에 대한 요청 비율을 늘려 결국 이전 버전의 사용을 중지할 수 있습니다. 각 버전에 대한 요청 부하를 조정할 때 필요한 성능을 제공하기 위해 각 서비스의 Pod 수도 스케일링해야 할 수 있습니다.
소프트웨어 업그레이드 외에도 이 기능을 사용하여 사용자 인터페이스의 버전을 실험할 수 있습니다. 일부 사용자는 이전 버전을 보유하고 있고 일부는 새 버전을 보유하고 있기 때문에 다양한 버전에 대한 사용자의 반응을 평가하여 설계 결정을 알릴 수 있습니다.
이 배포가 효과적이려면 이전 버전과 새 버전이 동시에 실행될 수 있을 정도로 충분히 유사해야 합니다. 버그 수정 릴리즈 및 새 기능이 이전 기능을 방해하지 않는 경우 일반적으로 사용됩니다. 버전이 제대로 작동하려면 N-1 호환성이 필요합니다.
OpenShift Container Platform은 웹 콘솔과 CLI를 통해 N-1 호환성을 지원합니다.
7.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 ...
7.4.5.1.1. 웹 콘솔을 사용하여 기존 경로의 가중치 관리
프로세스
-
네트워킹
경로 페이지로 이동합니다. - 편집할 경로 옆에 있는 작업 메뉴 를 클릭하고 경로 편집을 선택합니다.
-
YAML 파일을 편집합니다. 다른 대상 참조 오브젝트에 대한 대상의 상대적 가중치를 지정하는
weight
값을0
에서256
사이의 정수가 되도록 업데이트합니다. 값0
은 이 백엔드에 대한 요청을 비활성화합니다. 기본값은100
입니다. 옵션에 대한 자세한 내용을 보려면oc explain routes.spec.alternateBackends
를 실행합니다. - 저장을 클릭합니다.
7.4.5.1.2. 웹 콘솔을 사용하여 새 경로의 가중치 관리
-
네트워킹
경로 페이지로 이동합니다. - 경로 생성을 클릭합니다.
- 경로 이름을 입력합니다.
- 서비스를 선택합니다.
- 대체 서비스 추가를 클릭합니다.
-
가중치 및 대체 서비스 가중치 값을 입력합니다. 다른 대상과 비교했을 때 상대적 가중치를 나타내는
0
에서255
사이의 숫자를 입력합니다. 기본값은100
입니다. - 대상 포트를 선택합니다.
- Create를 클릭합니다.
7.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 오류가 반환됩니다.참고일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다.
7.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