무중단 배포 (Zero-Downtime Deployment)

[9ga0]

🗓️ 2026년 9월 7일 월요일

💡오늘의 질문?

서비스 운영 중 새로운 버전을 배포할 때 발생할 수 있는 다운타임(서비스를 사용할 수 없는 시간)을 최소화하기 위해 다양한 무중단 배포 전략을 사용할 수 있습니다. 대표적인 무중단 배포 방식인 Blue-Green, Rolling, Canary 배포에 대해 알아봅시다.

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

핵심 키워드와 꼬리 질문

핵키: 무중단 배포, 다운타임, 로드 밸런서, 트래픽 분산, Scale Out
꼬질: 서버가 한 대뿐이라면 무중단 배포가 어려운 이유는 무엇인가요?

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

핵심 키워드와 꼬리 질문

핵키: Blue-Green, Rolling, Canary, 트래픽 전환, 점진적 배포, 롤백
꼬질: Rolling 배포 중 구버전과 신버전이 동시에 실행될 때 어떤 문제가 발생할 수 있나요?

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

핵심 키워드와 꼬리 질문

핵키: 안정성, 장애 대응, 롤백, 트래픽 제어, 모니터링
꼬질: 선택한 배포 전략의 단점은 무엇이며, 이를 어떻게 보완할 수 있을까요?

참고자료: https://yeunever.tistory.com/62

(카나리vs블루그린 이미지 출처: https://xn--jaenung-9k94a.net/tree/43432)

[k9425mino]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드밸런서는 어떤 역할을 하나요?

무중단 배포란 서비스를 중단하지 않고 새 버전의 애플리케이션을 배포하는 방식이다. 사용자가 서비스를 이용할 수 없는 시간인 다운타임을 없애는 것이 목적이다.

이때 로드 밸런서는 여러 서버로 요청을 나누는 트래픽 분산 역할을 한다. 배포할 때는 특정 서버로 들어가는 신규 요청을 차단하고, 나머지 서버가 요청을 처리하도록 한다. 해당 서버의 기존 요청 처리가 끝나면 새 버전을 배포하고, 정상 동작을 확인한 뒤 다시 트래픽을 보낸다. 이 과정을 서버별로 반복하면 서비스를 유지하며 배포할 수 있다.

따라서 서버 수를 늘리는 Scale Out으로 여러 서버를 확보하면 무중단 배포가 쉬워진다. 다만 일부 서버가 배포 중이어도 나머지 서버가 전체 트래픽을 감당할 수 있어야 한다.

서버가 한 대 뿐이라면 왜 어려울까요?

애플리케이션을 종료하고 새 버전을 실행하는 동안 요청을 대신 처리할 서버가 없기 때문이다. 로드 밸런서가 있어도 트래픽을 보낼 정상 서버가 없다면 다운타임이 발생한다.

다만 물리 서버 한 대에서도 기존 버전과 새 버전을 서로 다른 포트나 컨테이너로 동시에 실행하고 트래픽을 전환하면 무중단 배포가 가능하다. 이 경우 두 버전을 실행할 자원이 필요하며, 서버 자체의 장애나 재부팅에는 대응할 수 없다.

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

세 방식의 핵심 차이는 신버전을 얼마나 넓은 범위에, 어떤 순서로 적용하고 트래픽을 전환하느냐이다.

[ Blue-Green ] : 현재 버전인 Blue와 별도 환경인 Green에 신버전을 준비한 뒤, 트래픽을 Green으로 한꺼번에 전환

• 장점: 전환이 빠르고, Blue를 유지하면 트래픽을 되돌려 빠르게 롤백 가능
• 단점: 두 환경을 동시에 유지할 자원이 필요하며 , 전환 후 전체 사용자가 오류에 노출될 수 있음

[ Rolling ] : 기존 서버를 일부씩 신버전으로 교체하는 점진적 배포

• 장점: 전체 환경을 복제하지 않아 추가 자원 부담이 비교적 작고, 서비스를 유지하며 배포 가능
• 단점: 구버전·신버전이 공존해 호환성이 필요하며, 롤백도 서버를 순차적으로 되돌려야 해 시간이 걸림

[ Canary ] : 신버전에 소량의 트래픽만 보내 검증한 뒤, 이상이 없으면 비율을 점차 확대

• 장점: 실제 트래픽으로 검증하면서 장애 영향을 제한하고, 문제가 생기면 시버전 트래픽을 차단하기 쉬움
• 단점: 정교한 트래픽 제어와 모니터링이 필요하며, 적은 트래픽으로는 일부 오류를 발견하기 어려움

예를 들어 서버가 10대라면, Rolling은 서버를 1~2대씩 교체하는 방식이고, Canary는 신버전에 트래픽을 1% → 10% → 50% → 100%로 늘리는 방식이다. Rolling도 신버전 노출이 점차 늘어나지만, Canary는 일부 사용자에게 노출한 결과를 평가해 확대 여부를 결정하는 것이 핵심이다.

Rolling 배포 중 구버전과 신버전이 동시에 실행되면 어떤 문제가 생기나요?

• API 호환성 문제: 신버전이 필드 이름이나 응답 형식을 바꾸면 구버전 클라이언트나 다른 서버가 이를 처리하지 못할 수 있다.
• DB 스키마 호환성 문제: 신버전 배포와 함께 컬럼을 삭제하거나 변경하면, 해당 컬럼을 사용하는 구버전 서버에서 오류가 발생할 수 있다.
• 세션·캐시 호환성 문제: 두 버전의 데이터 저장 형식이 다르면 세션이나 캐시를 읽지 못해 로그인 상태가 풀리거나 오류가 발생할 수 있다.
• 동작 불일치: 같은 사용자의 요청이 서로 다른 버전으로 전달되면서 계산 결과나 기능 동작이 달라질 수 있다.

따라서 두 버전이 함께 동작할 수 있도록 하위 호환성을 유지해야 한다. DB 변경은 보통 새 구조를 먼저 추가하고, 코드를 전환한 뒤, 구버전이 완전히 제거된 후 기존 구조를 삭제하는 순서로 진해한다. 또한 어떤 방식이든 이미 변경된 데이터까지 트래픽 전환만으로 롤백되지 않는다는 점을 고려해야 한다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

(GPT6-Astra의 판단) 결제 시스템이라면 Canary 배포를 선택할 것이다. 장애가 발생했을 때 영향을 받는 결제 요청을 제안하면서, 실제 트래픽으로 신버전의 안정성을 확인할 수 있기 때문이다.

구체적으로는 다음과 같이 운영할 것이다.

1. 트래픽 제어: 신버전에 소량의 트래픽만 보내고, 검증 결과에 따라 비율을 단계적으로 늘린다. 동일한 결제 흐름은 가능한 같은 버전에서 처리되도록 라우팅한다.
2. 모니터링: 에러율·응답 시간뿐 아니라 결제 승인 성공률, 중복 결제, 결제 상태 불일치 같은 업무 지표를 함께 확인한다.
3. 장애 대응과 롤백: 지표가 기준을 벗어나면 배포 확대를 중단하고, 신규 트래픽을 구버전으로 되돌린다. 처리 중인 결제는 갑자기 종료하지 않고 완료하거나 상태를 확인하도록 한다.

다만 코드를 롤백해도 이미 발생한 결제가 취소되는 것은 아니다. 따라서 중복 요청에도 결제가 한 번만 실행되도록 하는 멱등성, 결제 이력 기록, 결제사와 내부 상태를 대조하는 절차도 필요하다.

선택한 배포 전략의 단점은 무엇이며, 이를 어떻게 보완할 수 있을까요?

단점	보완 방법
트래픽 분배와 모니터링 구성이 복잡함	배포·트래픽 전환을 자동화하고, 중단 기준과 대응 절차를 미리 정해 훈련
적은 트래픽으로는 드문 장애를 발견하기 어려움	충분한 관찰 시간과 요청 수를 확보하고, 결제 수단별 지표 및 사전 테스트로 보완
구버전과 신버전이 공존해 호환성 문제가 발생할 수 있음	API·DB·이벤트 형식의 하위 호환성을 유지하고, 파괴적인 DB 변경은 나중에 수정
문제가 생기면 일부 실제 사용자에게 영향이 발생함	초기 노출 범위를 작게 제한하고, 이상 징후 감지 시 즉시 트래픽을 회수

핵심은 트래픽을 조금씩 늘리는 것과 함께, 확대를 멈출 기준과 빠르게 복구할 수단을 준비하는 것이다.

[JM-220]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

서버에 올려 사용자들에게 실제 배포가 된 프로그램의 경우를 보자. 만약 서비스 관련 기능에 업데이트가 생긴다면 이걸 사용자들에게 보여주기 위해 기존에 올려둔 프로그램을 종료시키고 다시 프로그램을 실행한다. 이게 가볍게 생각해볼 수 있는 수순이다. 서버 한대를 운용하고 그 위에 프로그램을 올려서 사용하는 것. 중단배포라고 한다. 근데 서비스를 종료시키기 어려운 서비스가 있을 수 있다. 예를 들어서 유튜브(유튜브가 404가 뜨는 걸 본적 있는 사람? 일단 난 아님)의 경우가 그러하다. 그러면 어떻게 해야할까? 업데이트는 해야하는데 서비스를 종료시키기 어려운 상황에서. 이 때 고려해야하는 것이 무중단 배포이다. 대략적인 원리는 이렇다

서버를 n대 운용한다. A서버에서 v1 으로 배포된 서비스를 v2로 업데이트한다고 하자. 이 경우 서버 B에 업데이트를 적용하고 A서버로 가던 트래픽을 로드 밸런서가 스위칭해서 서버 B로 보내면 된다. 기존에 A서버에서 작업하던 사람들의 작업이 끝나면 A서버에도 업데이트를 적용하면 된다.

1-1. 서버가 한 대뿐이라면 무중단 배포가 어려운 이유는 무엇인가요?

불가능은 아니다. 생각해보니 포트가 여러개니까 프로그램을 두개 띄워서 업데이트 된 프로그램을 새 포트에 옮기면 된다. 근데 그러면 전제가 사실상 서버 한대의 리소스를 대략 절반 이하로 사용하고 있는 상황이었어야 하는 것이다. cpu, mem 등…

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

Blue-Green : 이전 버전 혹은 수정이 필요한 프로그램이 있다고 할 때, 이전 버전에 남겨둘 서버를 Blue 서버, 먼저 수정을 적용시킬 서버를 Green 서버라고 한다. 두 서버가 마련이 되면 Blue 로 가던 트래픽을 Green 으로 바로 옮기는 방식이 Blue-Green 방식이다

장점	단점
다운타임 없이 업데이트 가능	인프라 비용 증가
빠른 롤백 가능	서버 간 공유 자원 간의 상태 충돌 가능성
운영 상태 분리 가능	데이터 마이그레이션 복잡
배포 리스크 최소화	트래픽 전환 시 타이밍과 헬스체크가 중요

Rolling : 운용하는 서버 수에 초점을 맞춘 무중단 배포 방식이다. 서버를 한번에 다 무중단 배포로 수정을 해버리는 게 아니라 하나씩 순차적으로 적용시키는 것.

장점	단점
점진적 배포 : 배포 중에 문제가 발생하면 배포를 중단하고 영향 범위를 제한할 수 있음.	롤백이 복잡함
	전 후 버전간 호환성 문제가 발생할 수 있음
	배포 시간 증가
	사용자 경험 불일치

Canary : Rolling 이 서버 수에 초점을 맞췄다면 Canary 는 사용자 비율에 초점을 맞춘다. 사용자 일부를 업데이트 적용된 서버로 옮겨가면서 점차 트래픽을 올리는 것이다. Rolling 과 방식은 다르지만 겉보기에는 유사한 방식이다.

장점	단점
리스크 최소화 : 소수의 사용자가 문제를 조기 탐지해줄 수 있다	운영 복잡도 증가
A/B 테스트 활용이 가능하다	롤링과 마찬가지로 호환성 문제가 발생할 수 있음
	롤백 설계가 필요함

2-2 Rolling 배포 중 구버전과 신버전이 동시에 실행될 때 어떤 문제가 발생할 수 있나요?

업데이트 적용 전 후 서버를 동시 운용할 때에도, 두 서버가 DB, 캐시, 메시지 시스템은 함께 사용하는데 두 서버가 서로가 만든 데이터를 이해하지 못하면 호환성 문제가 발생한다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

솔직히 둘다 상관 없을 것 같긴하다. 그래도 한다면 카나리로 할 것 같다. 왜냐하면 카나리는 A/B 테스트의 사용자 비중을 극도로 줄여서 업데이트된 서비스를 전체 사용자의 12% 정도로도 조정이 가능할 것 같은데 롤링에서 이렇게 하려면 서버가 50100 대를 운영해야 동일한 효과를 볼 것 같기 때문이다. 소규모 사용자(12%)로 테스트 해보고 잘 되면 늘리면 되니까… 망해도 12퍼만 망하는 거니까

3-2. 선택한 배포 전략의 단점은 무엇이며, 이를 어떻게 보완할 수 있을까요?

2번에서 적은 것처럼 카나리의 경우 운영 복잡도가 증가한다. 소수의 A/B 테스트를 계속 모니터링해봐야 하고 테스트 실패 시, 롤백과 같은 과정을 거쳐야 한다. 카나리 비율을 잘 조절해보면서 보완하자!

[eunji719]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

무중단 배포란 새 버전을 배포하는 동안에도 서비스가 중단되지 않고 사용자 요청을 계속 처리할 수 있도록 하는 배포 방식이다. 기존에는 서버를 내리고 새 버전을 올린 뒤 다시 켜는 방식이었다면, 무중단 배포는 신/구 버전이 공존하는 시점을 만들어 트래픽을 자연스럽게 전환한다.

이때 로드밸런서는 여러 서버 인스턴스 중 어디로 요청을 보낼지 결정한다. 새 버전 서버가 준비되면 로드 밸런서가 트래픽을 점진적으로 또는 즉시 새 서버로 돌린다. 또한 각 인스턴스의 상태를 주기적으로 확인하여, 준비되지 않았거나 장애가 난 서버로는 트래픽을 보내지 않는다. 기존 서버를 내리기 전에 이미 연결된 요청은 마무리하도록 유예 시간을 주고 새 요청만 새 서버로 보내고 Canary나 Rolling배포에서 트래픽 비율을 점진적으로 조절하는 주체가 바로 로드 밸런서이다.

로드 밸런서가 없다면 신구 버전 간 트래픽 전환 자체가 불가능 하여, 무중단 배포의 기술적 기반이라고 할 수 있다.

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

• Blue-Green 배포

  기존 환경(Blue)과 동일한 새 환경(Green)을 통째로 하나 더 만들고, 검증이 끝나면 밸런서의 트래픽을 한번에 Green으로 전환하는 방식이다. 전환이 즉각적이라 배포 시간이 짧고 문제가 발생하면 트래픽을 다시 Blue로 돌리기만 하면 돼서 롤백이 매우 빠르고 간단하다. 또한 신구 버전이 섞이지 않아 상태 일관성 문제가 적다는 장점이 있다. 하지만 두 환경이 있는 만큼 인프라를 두 개 유지해야 해서 비용도 2배이고 db스키마 변경이 있으면 양쪽 버전이 같은 db를 써야 해서 호환성 설계도 까다롭다. 또한 전체가 한 번에 전환되므로, 일부 사용자에게만 미리 테스트 해보는 것이 어렵다.

• Rolling배포

  여러 서버 인스턴스를 한 번에 몇 대씩 순차적으로 새 버전으로 교체해나가는 방식이다. 예를 들어 서버 10대 중 2대씩 순서대로 내리고 새 버전으로 교체한다. 이 방법은 추가 인프라가 거의 필요 없어 비용이 효율적이고 점진적으로 진행되므로 급격한 부하 변화가 적다. 배포 중간에는 신구 버전이 동시에 트래픽을 처리하므로 api호환성이 깨지면 문제가 생기고 롤백이 Blue-Green방식보다 느리다. 배포 완료까지 시간이 상대적으로 오래 걸린다.

• Canary배포

  신버전을 소수의 인스턴스에만 먼저 배포해서 실제 사용자 트래픽으로 검증한 뒤, 문제가 없으면 점진적으로 비율을 늘리는 방식이다. 실제 트래픽 기반으로 검증 가능해 위험이 낮고 문제가 발생하면 소수의 사용자에게 영향이 제한된다. 또 에러율,응답시간이 적힌 모니터링 지표를 보면서 배포 속도를 조절 가능하다. 하지만 트래픽 분배/모니터링/자동롤백 등 구현이 복잡하고 신구버전이 오래 공존할 수 있어 데이터 일관성 관리가 필요하다. 또한 배포까지 시간이 가장 오래 걸린다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

결제 시스템은 장애에 매우 민감하다. 오류가 나면 안된다. 이런 민감한 시스템에서는 작게 시작해서 지표를 보며 넓혀가고, 문제가 생기면 즉시 되돌릴 수 있는 능력이 가장 중요하여 Cannary배포가 가장 적합하다고 한다. 상황에 따라 빠른 롤백이라는 장점을 가진 Blue-Green과 결합하여도 좋다. 그러나 Rolling 방식은 신구 버전이 동시에 살아있는 동안 api나 데이터 스키마 호환성이 깨지면 결제 데이터 정합성 문제로 이어질 수 있기 때문에 리스크가 크다.

[9ga0]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

무중단 배포는 서비스를 중단하지 않고 새로운 버전을 배포하는 방식입니다.
쉽게 비유하면 식당이 영업을 계속하면서 주방만 새로 교체하는 것과 비슷합니다. 손님은 계속 식사를 하고 있지만, 뒤에서는 새로운 주방을 준비하고 준비가 끝나면 그쪽에서 음식을 만들기 시작하는 것입니다. 이 과정에서 로드 밸런서는 식당의 안내 직원 역할을 합니다. 손님이 어느 주방에서 음식을 받을지 결정하듯이, 로드 밸런서는 사용자 요청을 어떤 서버로 보낼지 결정하고 트래픽을 분산합니다. 새로운 서버가 준비되면 기존 서버에서 새로운 서버로 트래픽을 전환하고, 문제가 발생하면 다시 기존 서버로 보내 빠르게 롤백할 수 있습니다.

꼬질: 서버가 한 대뿐이라면 무중단 배포가 어려운 이유는 무엇인가요?

식당이 하나뿐인데 주방을 교체하려면 잠시라도 문을 닫아야 하는 것과 같습니다. 서버도 하나뿐이라면 새로운 버전을 설치하는 동안 서비스를 대신 제공할 서버가 없기 때문에 다운타임이 발생합니다.

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

세 가지 모두 무중단 배포 방식이지만 새 버전을 사용자에게 적용하는 방식이 다릅니다.

Blue-Green은 식당을 두 개 운영하는 것과 비슷합니다. 기존 식당에서는 계속 영업을 하고, 옆 식당에서 새로운 메뉴를 모두 준비합니다. 준비가 끝나면 손님을 한 번에 새 식당으로 안내합니다. 장점은 전환이 매우 빠르고 문제가 생기면 다시 기존 식당으로 안내하면 되기 때문에 롤백이 가장 쉽다는 점입니다. 단점은 식당을 두 개 운영해야 하듯이 서버도 두 세트가 필요해 비용이 많이 듭니다.

Rolling은 식당의 주방을 하나씩 교체하는 방식과 비슷합니다. 예를 들어 주방이 4개라면 하나를 새 버전으로 바꾸고, 안정적인 것을 확인한 뒤 다음 주방을 교체합니다. 장점은 서버를 추가로 준비하지 않아도 되어 비용이 적습니다. 단점은 교체하는 동안 구버전과 신버전이 함께 운영되므로 버전 간 호환성을 고려해야 합니다.

Canary는 새로운 메뉴를 모든 손님에게 주지 않고 일부 손님에게만 먼저 제공하는 것과 같습니다. 반응이 좋고 문제가 없으면 점점 더 많은 손님에게 제공하고, 문제가 생기면 바로 기존 메뉴로 되돌릴 수 있습니다. 장점은 장애가 발생하더라도 영향을 받는 사용자가 적고, 실제 운영 환경에서 안정성을 검증할 수 있다는 점입니다. 단점은 트래픽 비율을 조절하고 지속적으로 모니터링해야 하므로 운영이 가장 복잡합니다.

꼬질: Rolling 배포 중 구버전과 신버전이 동시에 실행될 때 어떤 문제가 발생할 수 있나요?

예를 들어 신버전에서는 회원 정보에 age 컬럼을 추가했는데, 구버전은 그 컬럼을 모른다면 일부 요청은 정상 처리되고 일부는 오류가 발생할 수 있습니다.

즉, 두 버전이 동시에 실행되기 때문에 데이터베이스나 API가 서로 호환되지 않으면 문제가 발생할 수 있습니다. 그래서 Rolling 배포에서는 하위 호환성을 고려한 설계가 중요합니다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

저는 Canary 배포를 선택하겠습니다. 결제 시스템은 장애가 발생하면 금전적인 손실과 사용자 신뢰도 하락으로 이어질 수 있기 때문입니다. Canary 배포는 새로운 버전을 먼저 일부 사용자에게만 적용해 실제 운영 환경에서 안정성을 확인한 뒤 점진적으로 확대할 수 있습니다. 식당으로 비유하면 새 메뉴를 손님 5명에게 먼저 제공해 보고 문제가 없으면 20명, 50명, 마지막에는 모든 손님에게 제공하는 방식​입니다. 만약 문제가 발견되면 전체 고객이 아니라 일부 고객에게만 영향을 주기 때문에 위험을 크게 줄일 수 있습니다.

꼬질: 선택한 배포 전략의 단점은 무엇이며, 이를 어떻게 보완할 수 있을까요?

Canary 배포는 트래픽 비율을 조절하고 실시간으로 모니터링해야 하기 때문에 운영이 복잡합니다. 이를 보완하기 위해 모니터링 도구를 활용해 오류율과 응답 시간을 지속적으로 확인하고, 일정 기준 이상 오류가 발생하면 자동으로 이전 버전으로 되돌리는 자동 롤백(Auto Rollback) 기능을 함께 사용하는 것이 좋습니다. 또한 Feature Flag를 활용하면 특정 기능만 선택적으로 활성화하거나 비활성화할 수 있어 위험을 더욱 줄일 수 있습니다.

요약

Blue-Green = "미리 준비하고 한 번에 교체." / 새 식당을 다 준비해놓고 한 번에 바꾼다.
Rolling = "하나씩 교체." / 식당을 하나씩 바꾼다.
🐤 Canary = "일부 사용자에게 먼저 배포." / 손님 몇 명에게만 먼저 먹여보고 괜찮으면 모두에게 준다.

[paiwhy]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

→ 무중단 배포(Zero-downtime Deployment)는 서비스를 새로운 버전으로 교체하는 동안에도 중단하지 않으며 사용자에게 서비스 중단이나 에러 없이 지속적으로 응답을 제공방식입니다

→ 로드 밸런: 여러 대의 서버 앞에서 트래픽을 분산시켜주는 장치입니다
무중단 배포에서는 이 트래픽 분산 기능을 이용해 새 버전이 준비된 서버로만 트래픽을 흘리고 구버전 서버는 트래픽을 차단한 뒤 안전하게 내리는 흐름을 가능하게 합니다.

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

→ Blue-Green: 기존 환경과 완전히 동일한 새 환경을 하나 더 만들어 배포하며 로드밸런서의 트래픽을 한번에 Green으로 전환하는 방식입니다.

• 장점: 롤백이 즉각적이고 간단
• 단점: 두 배의 인프라 리소스가 필요해서 비용듦

→ Rolling: 인스턴스를 한 번에 하나씩 순차적으로 새 버전으로 교체해나가는 방식입니다.

• 장점: 추가 인프라가 거의 필요 없어 비용 효율적.
• 단점: 배포도중에 신/구 버전이 공존하는 시간이 생기고 문제가 생기면 롤백에 시간이걸림.

→ Canary: 새 버전을 일부 트래픽에 먼저 노출시켜 문제가 없는지 확인한 뒤 점진적으로 트래픽 비율을 늘려가는 방식입니다.

• 장점: 문제 발생 시 영향 범위가 최소화됨(일부 사용자만).
• 단점: 모니터링/자동화 체계가 잘 갖춰져 있어야 하고, 신/구 버전 공존 기간이 길어 관리가 복잡함.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

Canary 배포를 선택할것같습니다 결제 시스템은 장애가 발생했을 때의 피해가 매우 커 문제가 있는 버전을 전체 사용자에게 한번에 노출시키는 것 자체가 리스크라고 생각합니다. Canary는 극소수 트래픽에만 먼저 새 버전을 태워보고 에러율/응답시간 등 지표를 모니터링하면서 점진적으로 비율을 늘리기 때문에 문제가 생겨도 영향받는 사용자와 거래 건수를 최소화하며 롤백할 수 있습니다.
Blue-Green처럼 즉각적인 전체 롤백 능력을 같이 갖추면 더 안전합니다

[dnnals]

기본 질문

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

핵심 키워드: 무중단 배포, 다운타임, 로드 밸런서, 트래픽 분산, Scale Out

무중단 배포란 새로운 버전을 배포할 때, 서비스를 끄지 않고 정상 작동을 유지하면서 배포하는 기법입니다. 무중단 배포는 최소 2대 이상의 서버 혹은 컨테이너가 요구됩니다. 2대 이상의 서버 중에서 업데이트 전의 구 버전으로 정상 서비스를 진행하며 서비스 외 서버에 버전을 업데이트하고 준비 후 신 버전으로 서비스를 변경하는 방식을 사용하고 이때 로드 밸런서가 트래픽을 옮겨주는 역할을 합니다. 이때 배포 전략에 맞게 구버전 신버전 간의 트래픽 비중을 조절합니다.

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

핵심 키워드: Blue-Green, Rolling, Canary, 트래픽 전환, 점진적 배포, 롤백

새 방식에 대해 설명하기 위해 하나의 서비스가 A, B, C의 세 서버로 운영한다고 가정하겠습니다. Blue-Green은 A, B, C로 정상 운영을 하고 따로 D, E, F에 신 버전을 업데이트한 서버를 띄우고 한 번에 100% 트래픽을 D, E, F로 옮겨서 배포합니다. 신 버전을 업데이트할 서버가 기존 운영 서버보다 더 요구되기에 인프라 비용이 단점이지만 버전 혼재 없이 업데이트가 가능하고 신 버전에 버그가 존재하면 다시 구 버전으로 트래픽만 100% 옮기는 롤백이 빠르다는 장점이 있습니다. Rolling은 A, B, C 서버에서 A에 대한 트래픽을 잠시 제한하고 A를 업데이트하고 그 동안 B, C로만 서비스하다 A가 업데이트 완료되면 다시 트래픽을 열고 같은 방식으로 B, C도 업데이트를 진행을 합니다. Blue-Green처럼 다른 서버에 신 버전을 준비하는 것이 아니라 인프라 비용 부담이 없다는 장점이 있지만 배포 중 잠시 제한한 트래픽 때문에 다른 서버에 순간적으로 과부하가 생길 수도 있다는 단점이 존재합니다. 마지막으로 Canary는 Blue-Green과 같이 D, E, F에 신 버전을 준비해두고 신 버전에 트래픽을 점진적으로 옮기며 에러를 모니터링 하며 배포하는 방식입니다. Canary는 모니터링하며 버전 업데이트를 하기에 위험을 극소화 가능하다는 장점이 있지만 모니터링 체계가 필수적으로 요구되며 높은 기술적 복잡도가 존재하는 단점이 존재합니다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

핵심 키워드: 안정성, 장애 대응, 롤백, 트래픽 제어, 모니터링

결제 시스템과 같은 장애에 민감한 서비스를 배포할 땐 Blue-Green과 Canary 혼재하는 방식을 선택합니다. 이유로는 먼저 장애에 민감해서 모니터링 검증의 방식이 요구됩니다. 그래서 Canary를 사용하는데 Canary로만 한다면 5%, 10%, 20% 이런식으로 점진적으로 하면 두 버전이 섞인채 운영되는 비중이 높아지기에 Canary 방식으로 5% 정도 소수로 모니터링해서 에러를 확인하고 정상적이라면 남은 95%를 한번에 옮기는 방식으로 두 버전이 섞여 운영되는 비중을 줄입니다. 이렇게 Canary, Blue-Green 방식을 섞어 사용합니다. 이 방식은 장애 대응에도 유리합니다. 두 방식 모두 트래픽 전환만으로 구 버전으로 롤백이 빠르기 때문에 만약 소수를 모니터링하다 장애가 생긴다면 그 즉시 구 버전으로 롤백해 장애에 대응하기에 유리합니다.