무중단 배포 검증: ALB 연결 종료·긴 요청·롤백까지 시험하기

AI Editter

ALB 뒤에 서버 두 대가 있다고 배포 중 오류가 자동으로 사라지는 것은 아닙니다. 새 서버가 준비되기 전에 트래픽을 받거나, 기존 요청이 끝나기 전에 프로세스를 종료하면 짧은 장애 구간이 생길 수 있습니다.

무중단 배포를 확인하려면 상태 검사 성공과 실제 사용자 요청 성공을 나눠 봅니다. /health만 반복 호출한 결과로 로그인·조회·업로드·긴 연결까지 정상이라고 결론 내리지 않습니다.

배포 성공률을 실제 요청 기준으로 본다

새 버전 프로세스가 켜지고 헬스체크가 통과했다는 것만으로 무중단을 증명할 수는 없습니다. 배포 시각 전후에 일반 조회, 긴 다운로드, 파일 업로드, 로그인 세션을 각각 시험하고 오류율과 응답 지연을 기록합니다. 기존 버전과 새 버전이 동시에 살아 있는 동안 DB 스키마를 둘 다 읽을 수 있는지도 확인하세요. 아래 ALB 절차는 이 검증을 통과시키기 위한 연결 전환 설계입니다.

배포 순서를 요청의 흐름으로 정리

새 버전 기동
→ 초기화와 의존성 준비
→ 대상 등록·건강 상태 확인
→ 실제 요청 시험
→ 이전 대상 등록 해제
→ 진행 중 요청 종료 확인
→ 이전 프로세스 종료

환경에 따라 등록과 준비 단계의 구현은 달라질 수 있지만, 새 요청을 받을 준비와 기존 요청을 마칠 시간을 분리해야 한다는 원칙은 같습니다.

상태 검사에는 서비스 준비 의미가 있어야 한다

프로세스가 살아 있다는 것과 요청을 처리할 수 있다는 것은 다릅니다. 필요한 설정과 초기 데이터, 연결 준비가 끝나기 전에 상태 검사에서 성공을 반환하지 않도록 설계합니다.

반대로 공유 DB의 잠깐 지연 때문에 모든 서버가 동시에 상태 검사에 실패하도록 만들면 영향이 커질 수 있습니다. 검사 범위와 실패 시 동작을 업무 구조에 맞게 정합니다.

ALB의 상태·이유 코드는 대상 상태 검사 문서를 확인합니다. 모든 대상이 비정상인 경우의 라우팅 동작도 알아 두어야 하며, unhealthy 표시만으로 요청이 완전히 차단됐다고 가정하지 않습니다.

deregistration delay와 앱 종료 시간을 맞춘다

대상을 등록 해제하면 진행 중인 요청을 마칠 시간을 줍니다. ALB의 deregistration delay와 앱의 graceful shutdown, 프로세스 관리자의 종료 제한시간이 서로 맞아야 합니다.

가령 파일 생성 요청이 최대 90초 걸리는데 앱이 종료 신호 후 10초 만에 강제 종료된다면, ALB에서 더 오래 기다리더라도 요청이 끊길 수 있습니다. 실제 최대 작업 시간과 허용 정책에 맞춰 설정합니다.

AWS는 대상이 등록 해제 지연이 끝나기 전에 연결을 종료하면 클라이언트가 500대 응답을 받을 수 있다고 설명합니다. 대상 그룹 속성 문서의 동작을 기준으로 확인합니다.

서버 한 대를 빼도 남은 용량이 충분한가

평소 두 대가 각각 높은 부하를 처리한다면 한 대를 빼는 동안 나머지가 버티지 못할 수 있습니다. 배포 중 최소 정상 대상 수, 실제 처리량, 오류율을 기준으로 임시 추가 용량이나 배포 단위를 정합니다.

고정 세션과 서버 메모리에 저장한 세션도 점검합니다. 특정 서버를 제거했을 때 로그인이 풀리거나 작업 상태가 사라진다면 상태 저장 구조를 개선하거나 그 영향을 배포 계획에 반영해야 합니다.

DB 변경은 별도 제약입니다. 새 코드가 바꾼 스키마를 이전 코드가 읽지 못하면 서버만 롤백할 수 없습니다. 구·신 버전이 잠시 공존할 수 있는 확장 후 전환 방식 등을 설계합니다.

대표 요청을 계속 보내며 배포한다

운영에 영향을 주지 않는 시험 환경에서 다음 요청을 배포 전부터 종료 후까지 반복합니다. 단순 성공률 외에 지연과 응답 내용도 기록합니다.

요청	확인할 항목
공개 조회	상태 코드·응답 내용·지연
로그인 후 조회	세션 유지·권한
긴 처리 요청	중간 연결 종료 여부
업로드	파일과 DB 기록 일치
WebSocket 등	재연결·메시지 연속성
쓰기 시험	중복·누락·재시도 결과

쓰기 시험에는 테스트 데이터와 고유한 요청 ID를 사용합니다. 실패 응답 후 재시도했을 때 같은 거래가 두 번 생기지 않는지도 확인합니다.

ALB 오류와 대상 오류를 나눠 본다

ALB가 생성한 오류와 대상 애플리케이션이 반환한 오류를 관련 지표와 접근 로그에서 구분합니다. 대상 상태가 healthy인데도 앱 경로가 실패할 수 있으므로 서버 로그·배포 버전·요청 ID를 함께 대조합니다.

배포 시각 주변만 보고 판단하지 말고, 초기 캐시가 채워지고 정기 작업이 한 번 실행될 때까지 관찰할 필요가 있습니다. 지연 통계는 표본 수와 기간을 함께 기록합니다.

롤백 기준은 배포 전에 숫자로 정한다

서비스가 허용하는 오류율·지연·정상 대상 수를 기준으로 확대 중단과 롤백 조건을 정합니다. 이 글의 임의 숫자를 모든 서비스에 적용하지 않습니다.

롤백 시에는 이전 코드 재투입, 새 대상 분리, DB 호환성, 전환 이후 쓰기 데이터를 확인합니다. 이전 서버가 남아 있다는 사실만으로 데이터까지 안전하게 되돌아가는 것은 아닙니다.

배포 기록에는 버전, 대상 목록, 등록·해제 시각, 대표 요청 결과, 오류와 조치, 최종 상태를 남깁니다. 이런 기록이 있어야 다음 배포에서 같은 무중단 조건을 재현할 수 있습니다.