배포 방식 종류
목차
Big Bang
한 번에 전체 서비스를 새 버전으로 교체하는 방식으로 기존 환경을 중단하고 새로운 릴리스를 한꺼번에 적용하는 방식
| 장점 | 단점 |
|---|---|
| 1. 구현이 간단하고 절차가 단순하다 | 1. 배포 중 다운타임이 발생할 가능성이 높다 |
| 2. 모든 사용자가 동시에 동일한 버전을 사용하므로 일관성 유지가 용이하다 | 2. 문제가 생기면 전체 사용자에게 영향을 주며 롤백이 어렵다 |
| 3. 별도의 인프라 중복이 필요 없어 운영 비용이 낮다 | 3. 대규모 릴리스 리스크로 변경 실패 시 복구에 많은 시간이 소요된다 |
Blug/Green
두 개의 동일한 환경(Blue, Green)을 운영하고 새 버전 배포 시 비활성 환경(Green)에 적용 후 트래픽만 전환하는 방식
| 장점 | 단점 |
|---|---|
| 1. 다운타임 없이 신속하게 트래픽 전환이 가능하다 | 1. 두 세트의 인프라를 운영해야 해 비용이 두 배로 든다 |
| 2. 문제가 있을 경우 즉시 이전 환경으로 롤백할 수 있다 | 2. 데이터베이스 마이그레이션 관리가 복잡해질 수 있다 |
| 3. 배포 전 비활성 환경에서 충분한 검증이 가능하다 | 3. 환경 동기화를 항상 유지해야 하므로 설정 관리가 번거롭다 |
Rolling
기존 인스턴스를 순차적으로 교체하면서 새로운 버전을 점진적으로 적용해 나가는 방식
| 장점 | 단점 |
|---|---|
| 1. 다운타임 없이 배포가 가능하다 | 1. 구버전과 신버전이 혼재된 상태가 일정 시간 유지된다 |
| 2. 인스턴스 단위로 교체하므로 롤백 시 영향을 받는 범위가 작다 | 2. 롤백이 완전히 되돌아갈 때까지 시간이 더 걸릴 수 있다 |
| 3. 인프라 리소스를 효율적으로 사용할 수 있다 | 3. 단계별 테스트가 어렵고, 중간 단계에서의 오류가 발견되기 어렵다 |
Canary
전체 중 극소수의 사용자에게만 먼저 새 버전을 적용해보고 안정성이 확인되면 점진적으로 확대하는 방식
| 장점 | 단점 |
|---|---|
| 1. 실제 사용자 환경에서 소규모로 검증해 큰 사고를 방지할 수 있다 | 1. 소규모 트래픽으로는 모든 시나리오를 테스트하기 어려울 수 있다. |
| 2. 문제 발생 시 영향 범위가 작아 빠른 대응이 가능하다 | 2. 구버전과 신버전을 동시에 지원해야 하므로 복잡성이 증가한다. |
| 3. 모니터링 데이터를 기반으로 리스크를 수치화할 수 있다. | 3. 트래픽 분산 및 라우팅 설정이 추가로 필요하다. |
AB Test
두 개 이상의 버전을 동시에 일부 사용자에게 할당해 기능, UI 등을 비교·검증하는 방식
| 장점 | 단점 |
|---|---|
| 1. 사용자 행동 데이터를 기반으로 객관적인 결정을 내릴 수 있다 | 1. 사용자 그룹 분류·관리 및 통계 분석이 필요해 구현 복잡도가 높다 |
| 2. 다양한 실험을 병행하며 최적화된 버전을 선정할 수 있다 | 2. 데이터 수집과 분석 인프라가 추가로 필요하다. |
| 3. 리스크 없이 새로운 아이디어를 검증할 수 있다 | 3. 사용자 경험이 일관되지 않을 수 있다. |
Shadow
실제 트래픽을 새로운 버전으로 미러링해서 보내고 응답은 기존 버전만 사용자가 보도록 하는 방식
| 장점 | 단점 |
|---|---|
| 1 실제 트래픽 기반으로 사전 검증이 가능해 높은 신뢰성을 확보할 수 있다 | 1 트래픽 복제 및 동기화 시스템 구현이 복잡하다 |
| 2 사용자에게 영향을 주지 않고 부하 테스트 및 성능 검증이 가능하다 | 2 복제된 요청에 대한 모니터링·로깅이 별도로 필요하다 |
| 3 장애 발생 시 운영 환경에 전혀 영향을 주지 않는다 | 3 두 버전이 동시을 동시에 실행하기 때문에 비용 부담이 발생한다 |
개인적으로 리소스 부담이 적고, 상대적으로 롤백이 쉽고, 구현 난이도가 낮은 Rolling 배포 방식을 선호하는 것 같다.