[내일배움캠프] 무중단 배포

무중단 배포(Zero-Downtime Deployment)는 서비스가 중단되지 않은 상태(= 다운타임 없이) 새로운 버전을 사용자들에게 배포하는 것을 의미한다.

무중단 배포의 장점

• 고가용성: 서비스 중단 없이 새로운 기능을 배포할 수 있어 사용자 경험이 유지된다.
• 빠른 롤백: 문제 발생 시 신속하게 이전 버전으로 롤백할 수 있어 서비스의 안정성이 높아진다.
• 연속적인 업데이트: 빈번한 배포와 업데이트가 가능해 빠른 기능 추가와 버그 수정을 지원한다.

무중단 배포의 단점

• 복잡성 증가: 동시 운영 환경, 트래픽 전환, 모니터링 등 관리가 복잡해질 수 있다.
• 리소스 요구: 무중단을 위해 v2를 위한 서버가 최소 한대 이상은 추가로 필요하므로 리소스와 비용이 증가할 수 있다.
• 인프라 요구: 무중단 배포를 지원하는 인프라와 도구가 필요하다. (그래서 큰 회사에서는 DevOps가 따로 있음)

로드 밸런서

• 로드 밸런서(Load Balancer)란?
  • 서버에 가해지는 트래픽을 여러대의 서버로 고르게 분배하여 특정 서버의 부하를 덜어준다.
  • 문제 있는 서버를 감지해서 (5~30초마다 health check) 요청을 보내지 않음으로써 가용성을 늘려준다.
  • 트래픽에 따라 서버를 추가/제거하는 Scale out/in을 담당한다.
• AWS 로드 밸런서 종류
  1. CLB (Classic Load Balancer) #
  2. ALB (Application Load Balancer) #
     • L7 (HTTP/HTTPS)
     • 설정한 전략대로 요청을 전달하고 HTTP 패킷 분석을 통해 요청을 보낼 대상을 선택함
     • 웹 애플리케이션 배포 + 카나리 등에서 트래픽 배분을 하려면 ALB가 가장 적절함
  3. NLB (Network Load Balancer) #
     • L4 (TCP/UDP)
     • 내부적으로 클라이언트 IP, 포트, 프로토콜 등을 기반으로 해시값을 계산해서 대상 인스턴스를 고름
     • NLB 동작이 상대적으로 ALB 보다 단순하기 때문에 속도도 빠름
  4. GWLB (Gateway Load Balancer) #

🧩 배포 종류

Rolling 배포

• 점진적으로 새로운 버전을 배포하는 방식
• 배포할 대상 서버는 로드밸런서에서 떼어내어 해당 서버에 v2를 배포하고, 완료 후 다시 붙이는 과정을 반복한다.
• 서버 가용성이 줄어드는 상황을 위해, 추가 서버를 준비해 v2를 배포하고 v1 과 교체하는 방법도 있다.
• EKS(Kubernetes) 환경에서 배포하는 Default 설정이지만 Rollback이 어렵다는 문제가 있다. (잘 쓰이지는 않음)

Blue/Green 배포

• 현재 운영중인 프로덕션 환경을 Blue, 새로 배포할 환경을 Green으로 정의한다.
  
  • 배포할 때만 Green을 만들어서 전환 후에 Blue(v1)는 다 끄는 방식 (서버 비용 우선)
  • 두 환경을 모두 상시 운영하며, 로드 밸런서 연결을 전환하는 방식 (복구 비용 우선)
• Green 환경에 먼저 v2를 배포하고, 문제 발생시 빠르게 Blue 환경으로 롤백이 가능하다.
• 단점: 서버 비용 2배, 스키마 변경이 발생한 경우 하위호환 방식으로 먼저 배포하는 방식으로 진행해야 함

Canary 배포

• 새 버전의 인스턴스는 일부 사용자에게만 서비스 되고 점진적으로 전체 사용자에게 제공되게 하는 방식
• 오류를 조기에 감지해 큰 위험을 방지할 수 있다.
• A/B 테스트 시 사용 될 수 있다: 기존 요소로 구성된 A안과 특정 요소를 변형한 B안을 비교해 어느 것이 더 나은 성과를 나타내는지 측정하는 실험
• 단점: 트래픽 분배를 세부적으로 조절할 수 있는 로드밸런서와 견고한 모니터링 체계 구축 필요

보통은 Blue/Green과 Canary를 혼용해서 사용한다고 한다.

배포 중 v1, v2 가 공존할 시 발생할 수 있는 문제

• 카나리 배포 또는 롤링 배포 중에 v1, v2 가 공존할 때 양쪽 모두 Redis를 통해 세션값을 조작한다고 가정해보자.
• v2가 직렬화한 객체를 Redis에 저장한 v1이 Redis에서 해당 데이터를 읽어 저장된 데이터의 구조와 코드 상 클래스 구조가 달라서 역직렬화(byte → 객체)하려고 할 때 문제가 발생할 수 있다.

// v1
class UserSession {
    private String userId;
    private String token;
}

// v2
class UserSession {
    private String userId;
    private String token;
    private String deviceType; // 신규 필드 추가
}

• 따라서 아래와 같이 버저닝을 하든 새로운 키를 사용해서 양쪽을 모두 활용할 수 있게 해야 한다.
  • v1:UserSession:{userId}
  • v2:UserSession:{userId}

---

[참고자료]

• 내일배움캠프 무중단 배포 강의자료