대상 그룹은 정상인데 사용자는 로그인에 실패합니다. 이때 정상 표시가 틀렸다고 보기보다, 헬스 체크가 확인한 범위와 로그인 요청이 실제로 지나가는 경로를 나눠 보는 편이 빠릅니다. 이 글은 ALB와 애플리케이션을 운영하는 담당자가 두 경로의 차이를 좁혀 가는 기준을 정리합니다.
정상 표시가 보장하는 범위
ALB는 대상 그룹에 설정된 경로와 포트로 주기적으로 헬스 체크를 보냅니다. 응답이 설정된 성공 코드와 횟수 등의 조건을 충족하면 해당 대상을 정상으로 판단합니다. 이 결과는 확인 시점의 지정된 요청에 대한 판정이며, 모든 업무 기능이 정상이라는 뜻은 아닙니다.
예를 들어 /health가 프로세스의 응답만 확인한다면 DB나 외부 인증 서비스 연결이 끊겨도 정상 응답을 줄 수 있습니다. 반대로 해당 엔드포인트가 의존성까지 실제로 점검하도록 구현됐다면 그 범위는 달라집니다. 정확한 의미는 URL 이름이 아니라 구현과 성공 코드 설정에서 확인해야 합니다.
로그인 요청과 다른 경로 찾기
먼저 실패한 요청의 시각, 호스트, 경로, HTTP 메서드, 응답 코드와 리디렉션 위치를 확인합니다. 비밀번호, 토큰, 세션 쿠키는 기록하거나 공유하지 않습니다. 같은 시각의 정상 요청과 비교하면 어디서 경로가 갈라지는지 살펴보기 쉽습니다.
리스너 규칙에서 호스트·경로 등 조건과 우선순위를 확인하고, 로그인 요청이 실제로 어느 대상 그룹으로 전달되는지 살펴봅니다. 헬스 체크를 확인한 그룹과 로그인 요청이 도착한 그룹이 다를 수 있습니다. ALB 자체 인증을 사용하는 구성이라면 인증 액션과 인증 제공자(IdP) 경로도 별도로 확인합니다.
대상에 도착한 뒤에는 애플리케이션 로그와 연결해 인증 서비스, 사용자 저장소, 세션 저장소 등 실제 구성된 의존성의 오류와 지연을 확인합니다. 브라우저에서는 리디렉션 반복이나 쿠키 설정을 함께 살펴보되, 어느 한 현상만으로 원인을 확정하지 않습니다.
로그를 읽는 순서와 판단
ALB 액세스 로그를 활성화해 두었다면 실패 시각의 요청에서 actions_executed, elb_status_code, target_status_code, target 처리 시간을 함께 봅니다. 대상 응답 코드가 기록됐다면 대상이 응답했다는 단서입니다. 값이 하이픈이면 대상 응답 코드가 기록되지 않은 것이며, 그 자체만으로 네트워크 장애라고 단정할 수 없습니다.
가령 /health는 정상이고 로그인 POST에 대상의 500 응답이 기록됐다면, 같은 시각 애플리케이션 오류와 인증 의존성을 먼저 확인하는 가상 사례를 생각할 수 있습니다. 반면 ALB가 504를 반환하고 대상 응답이 없다면 연결·응답 지연 등 여러 가능성을 조사해야 합니다. 502나 504는 원인 자체가 아니라 조사 범위를 좁히는 단서입니다.
액세스 로그는 기본적으로 비활성화되어 있고 전달이 지연될 수 있으며 모든 요청의 완전한 기록을 보장하지 않습니다. 로그가 없다면 현재 시점부터 설정하고, 기존 애플리케이션·모니터링 자료와 함께 확인합니다. 쿼리 문자열 등 로그에 민감정보가 들어갈 수 있으므로 접근 권한과 보관 범위를 점검합니다.
헬스 체크와 실제 로그인 검증의 역할
헬스 체크에 모든 외부 의존성을 넣으면 공유 인증 서비스 장애 때 여러 대상이 동시에 비정상으로 바뀔 수 있습니다. AWS 문서상 대상 그룹의 등록된 대상이 모두 비정상이면 ALB는 해당 대상들로 요청을 보내는 fail-open 동작을 합니다. 실제 동작은 대상 그룹의 상태 임계값 설정과 구성도 함께 확인해야 합니다.
운영 관점에서는 가벼운 대상 상태 확인과 별도의 로그인 경로 검증을 목적에 맞게 나누는 방식을 검토할 수 있습니다. 후자는 전용 테스트 계정과 최소 권한, 안전한 비밀 관리, 알림 기준을 갖추고 실제 로그인 및 세션 확인 범위를 명시합니다. 어느 방식이든 정상 표시가 무엇을 보장하는지 운영 문서에 적어두는 것이 출발점입니다.
자주 묻는 질문
헬스 체크 URL을 로그인 URL로 바꾸면 해결되나요?
반드시 그렇지는 않습니다. 로그인은 인증 정보나 세션이 필요할 수 있고 반복 요청이 계정 잠금이나 외부 서비스 부하를 일으킬 수 있습니다. 점검의 목적과 부작용을 검토하고 별도의 안전한 합성 검증을 고려합니다.
정상 대상이 하나라도 있으면 로그인은 성공하나요?
그렇지 않습니다. 해당 요청의 라우팅 대상, 인증 의존성, 세션 처리와 클라이언트 상태에 따라 실패할 수 있습니다. 대상 상태와 실제 로그인 성공 여부를 따로 확인합니다.
모든 대상이 비정상이면 ALB가 요청을 무조건 차단하나요?
아닙니다. AWS는 대상 그룹의 등록 대상이 모두 비정상일 때 fail-open으로 요청을 보낼 수 있다고 설명합니다. 임계값 등 실제 설정을 함께 살펴봐야 합니다.
결론
장애가 생기면 헬스 체크를 곧바로 바꾸기보다 실패한 로그인 요청이 어떤 규칙과 대상을 거쳐 어디까지 처리됐는지 먼저 확인하세요. 그 결과를 바탕으로 대상 상태 확인과 로그인 기능 감시를 분리하거나 범위를 조정하면, 정상 표시의 의미를 더 분명하게 운영할 수 있습니다.