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