안정적인 서비스 배포 - (롤링, 블루그린, 카나리)

배포와 서비스의 안정성

백엔드 개발자에게 배포와 관련된 역량은 필수적이라고 생각합니다. 특히 무중단 배포와 배포 안정성 확보는 작은 기업부터 큰 기업까지 반드시 필요한 부분이라고 생각합니다. 이번 글에서는 배포 안정성에 초점을 맞추고, 장애 예방 및 해결 방안, 다양한 배포 전략, 배포 시 유의사항 등을 알아보겠습니다.

 

배포 과정에서 여러 대의 서버에 수동으로 배포하는 방식은 효율성이 떨어지고 실수로 이어질 가능성이 큽니다. 반면 애자일 방식으로 잦은 배포가 이루어지면서 자동화된 배포 도구(예: 젠킨스, GitLab CI/CD 등)를 활용하는 사례가 늘어나고 있습니다.

 

 

---

배포 중 발생할 수 있는 장애

운영 중인 서비스에서 장애가 발생하는 주요 원인은 다음과 같습니다.

1. 트래픽 폭증: 예상치 못한 사용자 증가.
2. 서버나 네트워크의 물리적 장애: 하드웨어 문제, 네트워크 단절.
3. 잘못된 코드나 설정 배포: 배포 과정에서 발생한 오류.

이번 글에서는 잘못된 코드 배포로 인한 장애를 해결하는 방법에 대해 다룹니다. 이러한 상황에 대한 해결 방안은 예방과 해결로 나눌 수 있습니다. 대표적인 해결 방안으로는 롤백이 있으며, 이를 최소화하기 위해 다양한 예방 조치를 함께 사용합니다

 

---

 

주요 배포 전략

무중단 배포를 전제로, 서비스의 안정성을 확보하기 위한 세 가지 주요 배포 전략을 소개합니다.

 

롤링 배포 (Rolling Deployment)

개념:

• 기존 애플리케이션 인스턴스를 하나씩 교체하는 방식입니다.
• 새로운 버전의 애플리케이션을 배포하면서 점진적으로 트래픽을 이전합니다.

특징:

• 배포 대상 그룹 전체를 순차적으로 업데이트.
• 하나의 인스턴스 업데이트가 완료되면 다음 인스턴스를 업데이트.
• 배포 중에도 사용자는 서비스를 이용할 수 있음.

장점:

• 전체 시스템의 처리 능력을 대부분 유지 할 수 있다. (인스터스 4대중 1대에 배포 하더라도 3대는 가용이 가능하다.)
• 점진적인 적용을 통해 리스크를 최소화 할 수 있다. (장애 발생시 배포된 서버에 트래픽을 요청한 일부 사용자만 영향을 받는다.)

단점:

• 배포시간이 오래 걸린다. 대규모 서비스에서 긴급적으로 배포한다면 시간이 오래 걸린다는 단점이 있다.
• 동시에 서로 다른 버전으로 서비스를 제공하는 문제가 있다. (ex) 디비 스키마 변경, api 호환이 되지 않는 등 장애가 발생할 수 있는 케이스가 있다.)

---

 

블루그린 배포 (Blue-Green Deployment)

개념:

• 현재 운영 중인 버전(Blue)과 새 버전(Green)을 동시에 두고, 새 버전이 준비되면 트래픽을 한 번에 전환하는 방식.

특징:

• 두 개의 동일한 환경(Blue와 Green)을 필요로 함.
• 새 버전이 충분히 테스트된 후 트래픽을 전환.

장점:

• 완벽한 롤백 가능 (트래픽만 이전 환경으로 다시 전환).
• 즉각적인 트래픽 전환과 롤백이 가능하다.
• 트래픽 전환 전에 개발자들이 테스트를 수행할 수 있다. 또한 성능 테스트를 수행할 수 있는 환경도 가능하다. 
• 사용자에게 일관된 환경 제공.

단점:

• 추가 리소스가 필요하고 리소스가 거의 2배로 필요하다. 대규모 환경에서는 부담이 될 수 있다. (두 환경을 동시에 유지해야 한다. 장애로 인해 롤백을 할 수 있기 때문에 롤백을 위해 남겨두어야 한다.)
• 장애 발생시 모든 사용자가 영향을 받을 수 있다.
• 배포 할때마다 서버 세팅을 신경써야 한다는 단점이 있다. 네트워크 구성 , 모니터링 시스템, 자동화 시스템을 따로 유지 보수를 해야 할 경우도 필요하다. (AWS에서는 이러한 부분을 서비스로 제공하고 있어 부담을 덜어 줄 수도 있다.) 

---

 

카나리 배포 (Canary Deployment)

개념:

• 새로운 버전을 전체 사용자에게 적용하기 전에 일부 사용자(카나리 그룹)에게만 배포하는 방식.
• 문제 발견 시 카나리 사용자만 영향을 받음.

특징:

• 초기에는 소수의 인스턴스 또는 사용자에게 배포 후 점진적으로 확대.
• 안정성을 점검하면서 단계적으로 트래픽을 증가시킴. (5%-> 10% -> 50% -> 100%) 
  안정적 배포 및 모니터링 시스템을 통해 안전하게 배포 가능

장점:

• 리스크 최소화 (소규모 사용자 그룹 테스트).
• 단계별로 피드백 반영 가능.

단점:

• 배포 설정이 복잡하다. 
• 사용자 경험이 일관되지 않음. 
• 장시간 테스트가 필요할 수 있음.

---

정리

서비스의 중요성과 리소스 제약에 따라 배포 전략을 선택해야 합니다. 일반적인 서비스에서는 롤링배포를 사용하는 것이 좋을것 같습니다. 롤링 배포는 배포시 서비스 버전과의 차이를 염두해야 한다는 단점이 있습니다. 하지만 블루-그린 배포는 추가 리소스가 최대 2배로 필요하며, 서버 세팅을 블루와 그린 환경 둘다 신경을 써야 하기에 복잡한 부분이 많이 있습니다. 따라서 처음 롤링 배포를 적용해 보고 운영을 하다 배포시에 바로 트래픽을 전환해야 하는 서비스라면 블루-그린 배포 방식으로 넘어가는 것도 좋은 전략이 될것 같습니다. 카나리 전략은 일부 사용자들을 대상으로 테스트를 원하는 경우 필요한 전략이며, 대부분의 경우 롤링배포 혹은 블루-그린이 추천 될것 같습니다.

• 빠르고 간단한 배포가 필요하면 롤링 배포.
• 추가 리소스가 필요하더라도 트래픽 전환시 안정성이 중요하다면 블루그린 배포.
• 점진적 검증과 일부 인스턴스, 일부 사용자에 대한 배포가 필요하다면 카나리 배포.

 

 

---

 

배포 안정성을 위한 기타 고려사항

배포 타이밍

일반적으로 배포는 트래픽이 피크(peek)인 시점보다 비교적 트래픽이 적은 시점에 배포 한다면, 장애가 발생하더라도 영향을 최소화 할 수 있다. 또한 일반적으로 유관 부서들이 대응하기 힘든 시간은 피하는 것이 좋다. 금요일, 연휴 기간에는 장애 발생에 대응할 수 있는 환경이 아니기 때문에 배포를 자제 하는 것이 좋다. 제가 다니던 회사 역시 금요일은 부서장의 승인 없이는 배포를 할 수 없었으며, 연휴기간 2일 전에는 최대한 배포를 자제하였다.

 

또한 배포 이후에는 모니터링을 통해 장애 발생 여부를 확인 하는 것이 필수적이다. 장애는 크고 작든 정말 민감한 사항이다. 데이터 정합성이 무너지고 회사의 금전적 손실로 이어질 수 있는 부분이기 때문에 항상 민감하게 대응해야 한다. 배포 직후에는 모니터링 툴을 지속적으로 확인해야 하고, 짧게는 1~2시간 길게는 서비스 특성에 맞게 지속적으로 장애 여부를 신경 쓰는 것이 중요하다. 따라서 배포 일시를 결정할때 모니터링 시간도 포함하여 결정하는 것이 중요하다. 

• 사용자가 적은 시간대에 배포.
• 금요일, 연휴 전날, 주요 이벤트 직전 배포 지양.
• 배포 후 모니터링 시간이 확보되도록 배포 일정 조정.

 

웜업

대용량 트래픽의 서비스에서는 웜업은 필수적이라고 생각한다. 웜업을 하지 않고 처음 서버를 띄웠을때 버스트 트래픽이 들어온다면 장애가 분명 발생할 것이다. 처음 트래픽이 들어오면 데이터베이스 커넥션 연결, 캐싱 정보등 초기화 되지 않은 자원들연결을 위해 성능 지연이 발생할 수 있다. 제가 다니던 회사에서는 일반적으로 서버가 띄어질때 디비 조회 쿼리 혹은 캐싱 데이터를 생성하도록 하여 웜업을 진행하였다. 

 

Java의 JIT(just in time)컴파일러는 자주 사용되는 코드에 대해서 최적화를 진행한다. 이를 웜업에 활용한다면 사전에 API 호출 스크립트를 설정해서 트래픽이 유입되기 전 부하를 준다면 웜업에 도움이 될 것 같다. K6를 활용한다면 API 호출에 대한 스크립트를 작성할 수 있고, 초당 희망하는 트래픽 량을 결정할 수 있다. (K6사용은 따로 기회가 된다면 글을 작성 하겠습니다.)

 

 

---

알람 모니터링 환경 구축 

배포는 서비스의 안정성과 직결된다. 장애가 발생하면 최대한 빠르게 대응하는게 중요하다. 이를 위해 장애 발생시 알람 메세지를 통해서 빠르게 파악할 수 있도록 환경을 구축하는 것이 중요하다. 슬랙, 팀즈 등 회사에서 사용하는 메신저를 이용해 빠르게 쉽게 파악할 수 있는 것이 중요하다고 생각합니다.

 

장애 발생 메세지에는 젠킨스 배포 실패 로그 링크, 혹은 빌드 번호 , 장애 배포 추적에 필요한 정보가 담겨져 있다면 장애 파악에 더 용이할 것이라고 생각한다.