클러스터로 인입되는 모든 트래픽의 관문인 인그레스(Ingress)를 교체했습니다. 개발 환경과 운영 환경에 각각 다른 전략을 적용했습니다.
동일한 작업임에도 환경에 따라 왜 서로 다른 접근법을 취했는지, 그리고 어떻게 다운타임 없이 안전하게 전환했는지 정리했습니다.
인그레스 교체가 유독 까다로운 이유
일반 애플리케이션 파드는 배포에 문제가 생기면 이전 버전으로 즉시 롤백하면 됩니다. 하지만 인그레스는 다릅니다.
롤백을 진행하는 동안에도 실시간 트래픽이 계속 유입되며, 설정 누락이나 라우팅 결함은 배포 직후에 곧바로 드러나지 않는 경우가 많습니다. 웹소켓 장시간 연결, 커스텀 헤더 라우팅, 복잡한 리다이렉트 룰, cert-manager 인증서 자동 갱신 등은 며칠 혹은 몇 주 뒤에야 이상 징후가 나타납니다.
따라서 인그레스 교체 작업의 난이도는 '어떻게 교체하는가'가 아니라, '문제를 발견했을 때 얼마나 빠르고 안전하게 이전 상태로 되돌아갈 수 있는가'에 달려 있습니다.
두 가지 무중단 전환 전략
인그레스를 전환하는 방식은 크게 두 가지가 있습니다.
- 새 인그레스 로드밸런서를 생성하고 DNS 레코드를 변경하는 방식: 새 인프라를 완전히 검증한 뒤 도메인 DNS를 새 IP로 전환합니다. 롤백이 비교적 간단합니다(DNS를 원복).
- 단점: DNS 전파 지연(Propagation Delay)이 발생합니다. 캐시를 오래 유지하는 클라이언트는 구 주소로 계속 요청을 보내며, 롤백 시에도 똑같은 지연 시간을 감수해야 합니다. 즉각적인 원복이 불가능합니다.
- 기존 고정 IP를 새 인그레스가 그대로 승계하는 방식: 클라우드 고정 외부 IP를 새 로드밸런서로 이전합니다. 클라이언트 입장에서는 IP가 동일하므로 DNS 전파 지연이 전혀 없습니다.
- 단점: 두 인그레스를 나란히 띄우고 동일한 라우팅 규칙을 맞춘 뒤 세밀하게 전환해야 하므로 사전 준비와 검증 과정이 까다롭습니다.
개발 환경은 DNS 전환, 운영 환경은 IP 승계
- 개발 환경에는 첫 번째 방식(DNS 전환)을 적용했습니다. 설정이 빠르고 직관적이며, 잠시 DNS 전파가 지연되더라도 사내 개발진만 영향을 받기 때문입니다.
- 운영 환경에는 두 번째 방식(고정 IP 승계)을 적용했습니다. 이미 외부 파트너사와 클라이언트에 알려진 고정 IP였고, 트래픽이 양쪽으로 파편화되는 과도기 상태를 피해야 했기 때문입니다.
목표가 같더라도 환경별 리스크 특성이 다르면 최적의 엔지니어링 해법도 달라야 합니다. 개발계에서 성공한 방식을 운영계에 무비판적으로 복제하는 것은 위험합니다.
개발 완료 후 5일간 운영 적용을 기다린 이유
개발계 전환을 마친 뒤 운영계에 적용하기까지 5일간의 관찰 기간을 두었습니다.
기술적으로는 당장 다음 날 운영계에 적용하는 것도 가능했습니다. 하지만 앞서 언급했듯이 인그레스의 결함은 즉시 드러나지 않습니다. 며칠 동안 개발 트래픽을 흘려보내며 웹소켓 끊김 여부, 특수 엔드포인트 응답, 백그라운드 인증서 갱신 주기 등이 정상 동작하는지 충분히 확인해야 했습니다.
언제든 되돌릴 수 있는 상태를 길게 유지하는 것 자체가 가장 확실한 안전장치였습니다. 실제 전환 스위칭은 몇 시간 만에 끝나지만, 성공적인 전환의 8할은 대기와 검증에 있습니다.
작업 마무리 시 주의할 점
전환이 안정화되면 구 인그레스 리소스를 정리합니다. 이때 반드시 지켜야 할 원칙이 있습니다.
- 삭제 순서 준수: DNS 레코드를 먼저 정리한 후 로드밸런서 IP를 해제해야 합니다. 로드밸런서를 먼저 지우면 도메인이 존재하지 않는 IP를 가리키게 되고, 그 사이 클라우드 IP가 타인에게 재할당되면 서브도메인 탈취 공격에 노출될 수 있습니다.
요약
무중단 인그레스 전환의 본질은 화려한 기술이 아니라, "실패했을 때 어디로, 얼마나 신속하게 복구할 수 있는가"에 대한 명확한 설계입니다.