AWS 블루-그린 배포 원리: EC2와 로드밸런서로 무중단 배포 구현하기

핵심 메시지

• 블루-그린 배포는 한낮 피크 트래픽에도 점검 페이지나 오류 없이 새 버전을 내보내는 무중단 배포 기법이다.
• 구버전(블루)을 그대로 둔 채 동일한 신버전 서버(그린)를 따로 띄워, 두 버전을 나란히 운영하는 것이 핵심이다.
• VPC를 두 가용 영역(AZ)에 걸쳐 구성해 데이터센터 하나가 죽어도 서비스가 계속되도록 한다.
• 트래픽은 서버가 아니라 타깃 그룹(레인)을 가리키는 로드밸런서가 라우팅하므로 서버 교체에 유연하다.
• 전체를 한 번에 전환하지 않고 리스너 가중치를 80/20처럼 조금씩 돌리는 카나리 방식으로 위험을 줄인다.

쉽게 이해하기

가장 붐비는 사이트들은 한낮 피크 시간에도 사용자가 눈치채지 못하게 새 코드를 배포한다. '점검 중' 페이지도, 심야 배포 창도 없다. 이를 가능하게 하는 것이 블루-그린 배포이며, 영상은 이를 AWS 위에서 어떻게 구성하는지 부품별로 풀어낸다.

출발점은 네트워크다. 모든 것은 하나의 Amazon VPC, 즉 AWS 안의 사설 공간 안에 있고 인터넷 게이트웨이가 외부와의 출입문이 된다. 단일 건물의 정전이 전체 서비스를 멈추지 않도록 VPC를 서로 떨어진 두 가용 영역에 걸쳐 펼치고, 각 영역에 퍼블릭 서브넷을 둔다. 한 영역을 잃어도 앱은 계속 서비스된다.

그 위에서 앱은 EC2 인스턴스로 돌아간다. 사용자가 지금 접속하는 버전 1이 '블루' 서버이고, 사용 중인 서버의 코드를 바로 바꾸는 것은 위험하므로 동일한 두 번째 EC2에 버전 2를 올린 '그린' 서버를 따로 세운다. 블루는 라이브, 그린은 테스트를 마친 채 대기한다. 두 서버는 80번 포트의 웹 트래픽만 허용하는 단일 규칙의 시큐리티 그룹으로 함께 보호한다.

트래픽은 기계를 직접 가리키지 않는다. 서버는 생겼다 사라지므로, 각 서버를 TG 블루·TG 그린이라는 타깃 그룹(라벨이 붙은 레인)에 넣고 라우터는 레인하고만 대화한다. 그 라우터가 두 서브넷에 걸친 애플리케이션 로드밸런서로, 단일 장애점이 없고 응답하지 않는 서버를 헬스 체크로 걸러낸다. 처음 리스너 규칙은 '블루로 100%'로, 모두 버전 1을 쓰고 그린은 조용히 대기한다.

핵심은 전환 방식이다. 모두를 한 번에 그린으로 넘기면 숨은 버그 하나가 사이트 전체를 무너뜨릴 수 있으니, 스위치를 누르는 대신 다이얼을 돌린다. 리스너 가중치를 블루 80·그린 20으로 옮겨 다섯 명 중 한 명만 신버전에 보내고 관찰한다. 문제가 있으면 다시 블루 100으로 되돌리면 아무도 눈치채지 못하고, 이상이 없으면 그린 100으로 완전히 넘긴다. 영상은 이 구성을 직접 실습해볼 수 있는 무료 핸즈온 랩과 캡스톤도 안내한다.

주요 인사이트

• 무중단 배포의 본질은 '교체'가 아니라 '병렬 운영 후 점진 전환'이다. 구버전을 살려둔 채 신버전을 띄우고 트래픽만 옮긴다.
• VPC를 두 가용 영역에 걸치는 것은 단순한 권장이 아니라 단일 데이터센터 장애에 대비한 복원력의 핵심 설계다.
• 트래픽을 서버가 아닌 타깃 그룹에 연결하는 추상화 덕분에, 서버가 교체되거나 사라져도 라우팅이 흔들리지 않는다.
• 로드밸런서의 리스너 가중치를 조금씩 조정하는 카나리 배포는 문제 발견 시 즉시 롤백할 수 있어 위험을 크게 낮춘다.
• 헬스 체크로 응답 없는 서버를 자동으로 제외하기 때문에, 장애가 사용자에게 노출되기 전에 걸러진다.

자주 묻는 질문

관련 AI 소식