[배포] 🚀 무중단 배포를 위한 3가지 아키텍처

📚시작하기 전에

🤔 1. 먼저, "무중단 배포"가 뭘까?

핵심은 배포 중에도 서비스는 멈추지 않고 계속 동작해야 한다는 것이다!
유저 입장에선 "어? 배포했어?" 싶을 정도로 티 안 나야 성공이라고 할 수 있다.

 

🤔 2. ALB란?

ALB = Application Load Balancer
트래픽(요청)을 여러 서버로 똑똑하게 분산해주는 친구이다.
쉽게 말해, "인터넷 앞에 있는 문지기" 같은 느낌!

 

📦 3. 그래서 ALB가 무슨 일을 하는데?

1. 유저가 myservice.com에 접속하면
2. 👉 ALB가 받아서
3. 👉 뒤에 있는 서버 중 하나한테 요청을 전달해준다.
4. 서버가 많아도 걱정 없다. ALB가 자동으로 분산해주니까!

🧑‍⚕️ 4. Health Check란?

말 그대로 서버가 "건강한지" 확인하는 검사!
ALB가 "이 서버 지금 잘 돌아가?"라고 주기적으로 물어보는 것이라고 할 수 있다.

 

Health Check가 더 궁금하다면 ? 👇👇👇

💬 어떻게 물어보냐면?

• 예를 들어 /health 같은 특정 URL을 정해둔다.
• ALB가 5초마다 http://EC2서버주소/health 로 요청을 보냄
• 서버가 응답을 잘 하면 👉 "오케이, 이 서버 건강하네~"
• 응답이 없거나 500 에러 나면 👉 "얘 아픈가봐! 일단 빼자"

🎯 무중단 배포에서의 역할

• 새 서버(예: EC2 2)에 배포 완료했을 때 👉 Health Check에 통과해야만 ALB가 트래픽 보내줌
• 배포 중 오류 나면? 🚨 헬스 체크 실패 → ALB가 트래픽 안 넘김
• 덕분에 사용자 입장에선 서비스 끊김 없이 계속 잘 동작한다.

📌 중요한 설정들

• Health check path: 보통 /health, /actuator/health 같은 것
• Interval: 몇 초마다 검사할지 (예: 5초)
• Threshold: 몇 번 실패하면 "아프다"고 판단할지 (예: 3번 실패)

---

1. Blue/Green 배포 (with AWS CodeDeploy + EC2)

1. 둘 이상의 독립된 환경(Blue, Green)을 준비해서
2. 하나(Blue)는 현 서비스, 다른 하나(Green)에는 새 버전을 배포
3. 준비 완료 후 ALB나 DNS를 통해 트래픽을 Green으로 스위칭
4. 맘에 안 들면? 다시 Blue로 트래픽 돌릴 수 있다.

📊 아키텍처 요약

• EC2 2개 (Blue, Green)
• ALB로 트래픽 스위칭 (ALB가 둘 사이에서 트래픽을 왔다갔다 해줌)
• 예시: AWS CodeDeploy에서 Blue/Green 전략 사용

👍 장점

• 완전 무중단임
• 문제 생기면 바로 되돌릴 수 있음(롤백)

👎 단점

• 서버 두 대니까 비용이 더 든다.
• 설정이 좀 귀찮다.

---

2. Nginx + 포트 스위칭 방식 (단일 EC2에서 무중단)

1. 서버는 한 대지만, 애플리케이션을 서로 다른 포트로 번갈아 띄운다.
2. Nginx가 “어느 포트에 연결할지”만 실시간으로 바꿔주는 방식
3. (예: 지금 8081에서 돌고 있으면, 8082에서 새로 띄움)
4. 기존 프로세스는 종료하지 않고, 새 프로세스가 헬스체크를 통과하면 트래픽만 슬쩍 돌려주는 방식.
5. (8082로 새 앱 실행 후 헬스체크 → Nginx가 8082로 라우팅 변경)

📊 아키텍처 요약

• EC2 한 대
• Nginx + systemd + health check
• deploy.sh에서 포트 감지 + Nginx 리로드

👍 장점

• 서버 한 대니까 비용이 저렴하다.
• 생각보다 간단하게 무중단 배포 가능

👎 단점

• 포트 관리 & Nginx 리로드 스크립트 직접 작성해야 함
• 만약 프로세스가 포트를 제대로 해제하지 않으면 꼬일 수 있음
• 복잡한 로드 분산/스케일링에는 부적합

---

3. ALB + Auto Scaling Group (EC2 여러 대) 방식

1. 서버 여러 대가 있고, 한 대씩 순서대로 업데이트
2. ALB가 자동으로 트래픽을 업데이트 안 된 서버로만 보내줌
3. 다 바뀔 때까지 순서대로 돌리는 방식

이렇게 롤링 배포는 애플리케이션의 새 버전을 배포할 때, 한 번에 모든 인스턴스를 교체하는 것이 아니라, 순차적으로 인스턴스들을 업데이트하여 배포하는 방식이다. 이렇게 하면 배포 중에도 서비스 중단 없이 애플리케이션을 업데이트할 수 있다.

 

📊 아키텍처 요약

• ALB + Launch Template + Auto Scaling Group
• 새 인스턴스 생성 후 배포

👍 장점

• 대규모 서비스에 좋음
• 자동화도 잘 됨
• 진짜 클라우드스러운 방식

👎 단점

• 처음 세팅이 어려움
• 서버 많으면 비용도 많이 듬.

---

참고

• https://hudi.blog/zero-downtime-deployment/
• https://soojong.tistory.com/entry/nginX-%EB%AC%B4%EC%A4%91%EB%8B%A8-%EB%B0%B0%ED%8F%AC-%EC%8B%A4%EC%8A%B5