Deployment
- Deployment는 Pod 와 ReplicaSet 에 대한 선언적 업데이트 제공하며, 배포에 대한 세분화된 기능 제공
- Deployment 에 의도하는 상태를 기술하면, Deployment Controller는 현재 상태에서 의도하는 상태로 비율을 조정
- Pod 에 대한 롤링 업데이트 및 롤백 기능 제공
Deployment Strategy
• Recreate - native
• Ramped - native
• Blue/Green - extra step needed
• Canary - extra step needed
• A/B Testing - require additional component
• Shadow - require additional component
1. Recreate
서비스 중단 → 배포 생성 → 새로운 배포로 서비스 시작
장점 :
1. 설정이 쉬움
단점 :
1. 서비스 영향이 큼. 어플리케이션의 종료/시작 간격에 따라 서비스 다운타임이 결정
2. Ramped (Rolling Update)
maxSurge, maxUnavailable을 선언해 유연한 무중단 서비스 배포
장점 :
1. 설정 및 사용이 쉬움
2. 전체 인스턴스들에 신규 버전이 천천히 배포
3. 데이터 Rebalancing이 진행되는 상태 유지가 필요한 애플리케이션에 유리
단점 :
1. 롤아웃 / 롤백 시간이 오래 걸림
2. 트래픽에 대한 통제가 어려움
3. Blue/Green
서비스를 새로 배포 후, 트래픽 라우팅 전환
장점 :
1. 간단한 롤아웃 / 롤백
2. 버전이 자주 변경되는 프론트엔드 서비스에 적합
3. 응용 프로그램 종속성 지옥을 수정하는 더러운 방법
단점 :
1. 2배의 리소스가 필요하므로 비용이 비쌈
2. 프로덕션에 릴리즈 하기 전에 전체 플랫폼에 대한 테스트 수행 필수
4. Canary
서비스를 새로 배포 후, 트래픽 라우팅의 비율을 점차 변경
장점 :
1. 일부 사용자를 위해 출시된 버전을 사용할 경우 적합
2. 오류율 및 성능 모니터링에 유리
3. 비교적 빠른 롤백
단점 :
1. 느린 롤아웃 (일부 트래픽에 대해 검증해야 하기 때문)
2. sticky sessions 필요
3. 정확한 트래픽 이동에는 Istio 또는 Linkerd와 같은 추가 도구 필요
5. A/B Testing
여러 버전을 동시에 서비스하면서 비교
장점 :
1. 여러가지 버전의 어플리케이션을 동시에 서비스
2. 트래픽 분배에 대한 완전한 제어 가능
3. 전환율 개선을 위해 비즈니스 목적으로 사용할 수 있는 장점
단점 :
1. 지능형 로드 밸런서 필요 (Istio, Linkerd ..)
2. 세션에 대한 오류를 해결하기 어렵기 때문에 분산 추적 기술이 필수
6. Shadow (Mirrored)
사용 중인 배포의 트래픽을 복사해 테스트
장점 :
1. 운영계 트래픽에 대한 어플리케이션 성능 테스트에 적합
2. 사용자 영향이 없음
3. 애플리케이션의 안정성과 성능이 요구 사항을 충족할 때까지 롤아웃 없음
단점 :
1. 설정이 다소 복잡
2. 2배의 리소스가 필요하므로 비용이 비쌈
3. 특정 서비스에 대한 (결제, 외부 채널 연동) mocking/stubbing 서비스가 필요
결론
-
다운타임을 허용해도 된다면 Recreate
-
recreate 와 ramped 는 Deployment 기능에 설정으로 포함되어 있음 (kubectl apply 로 충분)
-
ramped 와 blue/green 배포는 일반적으로 사용성이 좋고 적용하기 쉬움
-
blue/green 배포는 동일한 서버에서 버전이 변경되는 어플리케이션을 로드하는 프론트엔드에 적합
-
blue/green 와 shadow 는 추가적인 인스턴스를 필요로 하기 때문에 비용이 비쌈
-
canary 와 A/B Testing 릴리즈에 대한 확신이 없거나, 대규모 업데이트일 때 사용하기 좋음
-
canary, A/B Testing, shadow 모두 Istio 와 같은 추가적인 컴포넌트가 필요
