로드밸런서 헬스 체크가 성공한 서버가 실제 요청을 실패할 수 있고, 배포 중 기존 연결도 실패할 수 있는 이유는 무엇인가요?

헬스 체크 성공은 정해진 시점에 정해진 경로가 성공했다는 의미이지 다음 실제 요청의 성공을 보장하지 않습니다. 프로세스가 살아 있는지 확인하는 liveness와 새 요청을 받을 준비가 됐는지 확인하는 readiness를 나눕니다. 예를 들어 프로세스가 응답해도 DB 연결 풀이 모두 고갈됐다면 실제 주문 요청은 실패할 수 있으므로, DB·큐 같은 의존성을 어디까지 검사할지 정해야 합니다. 외부 의존성을 모두 포함하면 공통 장애가 모든 서버를 동시에 제외할 수 있고, 너무 얕으면 실제 요청 처리의 장애를 놓칩니다.

종료할 서버는 먼저 readiness를 실패시켜 새 연결 유입을 막고, 로드밸런서와 endpoint에 상태가 전파될 시간을 둡니다. 이미 유지 중인 TCP·HTTP/2·스트리밍 연결은 헬스 체크 변화만으로 즉시 다른 서버로 이동하지 않으므로 preStop(종료 직전 실행할 정리 단계), connection draining(새 요청을 막고 기존 요청을 끝내는 과정), termination grace period(강제 종료 전 대기 시간), 클라이언트 재시도를 함께 설계합니다. 이 순서를 생략하면 체크는 실패했는데 기존 연결이 종료되어 배포 중 오류가 생깁니다. 드레이닝 중 긴 요청이 끝나지 않으면 무한 대기하지 않고 취소·재개·재시도 계약을 적용합니다.

테스트는 체크 경로 성공과 실제 DB 장애, readiness 전파 지연, 짧은 요청과 장기 스트리밍, 종료 제한 시간 초과를 분리해 재현합니다. 지표는 체크 응답만이 아니라 배포 중 오류율·재시도 폭증·완료율·연결 종료 결과를 봅니다. 헬스 체크를 깊게 만드는 것이 항상 안전한 것이 아니라, 기능별 격리와 종료 순서가 함께 맞아야 합니다.

헬스 신호를 기능별로 해석합니다

liveness는 프로세스 생존, readiness는 새 요청 수용 가능성을 나타냅니다. DB 풀이 고갈돼 주문을 처리할 수 없으면 주문 기능의 준비 상태는 실패할 수 있지만, 추천 API 하나의 장애로 로그인 서버까지 모두 제외하지 않게 의존성을 분리합니다. 헬스 경로가 별도 캐시나 연결을 사용하면 실제 요청과 다른 상태를 보고할 수 있으므로 검사 비용과 범위를 정합니다. 체크 성공률만으로 사용자 성공을 추정하지 않겠습니다.

연결 단위로 drain합니다

readiness를 내린 뒤에도 이미 열린 TCP·HTTP/2·WebSocket·스트림은 다른 서버로 이동하지 않습니다. 상태 전파 시간을 기다리고 새 연결을 막은 다음 남은 요청을 끝내거나 취소하며, 클라이언트는 재연결 후 마지막 위치나 멱등 키로 재시도합니다. 긴 스트림이 grace period를 넘으면 부분 결과·재개 지점을 계약으로 둡니다. DB 장애 중 체크 성공, readiness flapping, 전파 지연, drain 기한 초과를 나누어 오류율·연결 종료·재시도 결과를 확인하겠습니다.

구체적인 경계 사례

상태 전파 시간은 고정 sleep 하나로 증명하지 않습니다. 로드밸런서의 endpoint 제거 시각, 마지막 신규 요청 시각, 진행 중 요청 수를 관측하고 종료 상한 안에서 조정합니다. HTTP/2에서는 GOAWAY 등 프로토콜이 지원하는 종료 신호로 새 스트림의 재연결을 유도할 수 있지만 처리된 요청의 재시도 안전성은 별도입니다. WebSocket은 재연결 뒤 세션과 수신 위치를 복구하는 애플리케이션 절차가 필요합니다.

준비 상태가 경계에서 계속 바뀌면 남은 인스턴스에 부하가 몰렸다가 다시 돌아오는 진동이 생깁니다. 실패·성공 연속 횟수나 복귀 지연을 두되 실제 장애 탐지를 지나치게 늦추지 않습니다. 시작 직후 캐시가 빈 인스턴스에 트래픽을 한 번에 몰지 않도록 점진적인 가중치 증가도 검토하겠습니다.