블루-그린 배포와 DNS 컷오버

블루-그린 배포는 두 개의 완전한 프로덕션 환경을 동시에 운영합니다. 하나는 현재 서비스 중인 환경(“블루”)이고, 다른 하나는 대기 중이지만 완전히 배포되어 준비를 마친 환경(“그린”)입니다. 롤링 업데이트와 달리 두 환경 사이의 트래픽을 한 번에 빠르게 전환합니다. 특히 인프라나 제공업체가 서로 분리된 경우 이 전환을 구현하는 흔한 방법이 DNS 변경입니다. 그린 환경이 정상임을 확인한 뒤 도메인의 레코드가 그린 환경의 주소를 가리키도록 갱신하는 것입니다.

단순한 방식이 한계를 드러내는 지점

DNS 기반 컷오버는 로드 밸런서의 대상 그룹을 바꾸는 것처럼 즉각적이지 않습니다. 이전(블루) 응답을 캐시한 모든 리졸버는 해당 레코드의 TTL이 만료될 때까지 계속 그 응답을 제공합니다. 즉 TTL에 비례하는 시간 동안에는 일부 트래픽이 방금 벗어나려던 환경으로 여전히 들어옵니다. TTL이 1시간이라면 컷오버가 모든 곳에서 완전히 끝나기 전까지 최대 1시간 동안 두 환경에 트래픽이 나뉠 수 있습니다.

• 계획한 컷오버보다 충분히 앞서 TTL을 낮추세요. 이상적으로는 기존 TTL 주기 하나 이상 앞서 낮춰, 컷오버 시점에는 모든 리졸버가 이미 새로운 짧은 TTL로 다시 캐시하도록 합니다.
• 컷오버 후 적어도 TTL 시간 동안은 이전(블루) 환경을 완전히 가동하고 정상 상태로 유지하세요. 바로 폐기하면 안 됩니다. 그 시간 동안에도 실제 트래픽을 받고 있습니다.
• 애플리케이션 로그만 확인하지 말고 DNS를 직접 질의해 컷오버를 검증하세요. 트래픽이 얼마나 따라왔는지와 무관하게 레코드 자체가 바뀌었는지 확인할 수 있습니다.
• 컷오버가 완료되어 안정적이라고 확신한 뒤에야 TTL을 원래 값으로 되돌리세요.

점진적 대안: 가중치 기반 DNS

모든 리졸버를 한꺼번에 전환하고 그린 환경이 전체 프로덕션 부하를 곧바로 견뎌 주기를 바라는 대신, 여러 DNS 제공업체는 가중치(또는 비율) 기반 라우팅 정책을 지원합니다. 응답의 95%는 블루를, 5%는 그린을 가리키게 하고, 새 환경에 대한 확신이 커질수록 80/20, 50/50 등으로 비율을 점진적으로 옮깁니다.

깔끔하고 단순한 전환을 포기하는 대신, 트래픽 일부에만 영향을 주는 단계에서 문제를 포착할 수 있고, 그린이 준비되지 않았다면 몇 초 안에 블루 100%로 되돌릴 수 있습니다. 압박 속에서 전체 컷오버를 되돌릴 필요가 없습니다.

어떤 방식이든 같은 방법으로 검증하기

어떤 전략을 쓰든 검증 단계는 동일합니다. 둘 이상의 관측 지점에서 도메인을 반복해서 조회하고, 실제로 관측된 분배가 설정한 값과 일치하는지 확인하세요. 10%의 트래픽만 그린으로 보내려 했는데 실제로는 40%가 가고 있다면, 가중치 설정 오류나 일부 리졸버의 캐시 때문에 분배가 예상만큼 자주 다시 계산되지 않아서일 수 있습니다. 이런 편차는 DNS 제공업체의 대시보드가 현실을 완벽하게 반영한다고 믿는 대신 실제로 확인된 응답을 점검해야만 드러납니다.