동블

그래프 뷰

03. Load Balancer와 Health Check 상세

9 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • Load Balancer는 백엔드 운영에서 어떤 장애를 줄이는가?
  • Health Check path는 Spring 애플리케이션 상태와 어떻게 맞춰야 하는가?
  • target이 healthy인데 API가 실패할 때 무엇을 확인해야 하는가?

개요

Load Balancer는 사용자 요청을 여러 target으로 나누고 비정상 target을 트래픽에서 제외한다.

단일 VM에 직접 트래픽을 보내면 VM 하나의 장애가 서비스 전체 장애가 된다.

Load Balancer를 두면 target 교체, 점진적 배포, 포트 분리, TLS 종료, access log 수집이 쉬워진다.

하지만 Load Balancer는 애플리케이션이 실제로 요청을 처리할 수 있는지 완벽히 알지 못한다.

그래서 Health Check를 Spring 애플리케이션의 준비 상태와 맞추는 일이 중요하다.

요청 흐름

client
  DNS
    Load Balancer listener :443
      target group :8080
        Spring application

Load Balancer는 listener와 target group을 가진다.

  • listener는 외부에서 받을 protocol과 port를 정한다.
  • rule은 host, path, header 기준으로 target group을 고를 수 있다.
  • target group은 실제 요청을 받을 VM이나 IP와 port를 가진다.
  • Health Check는 target group에 속한 target을 유지할지 제외할지 판단한다.

백엔드 개발자는 자신의 애플리케이션이 어떤 port와 path로 트래픽을 받는지 설명해야 한다.

Health Check 설계

Health Check는 너무 얕아도, 너무 깊어도 문제다.

너무 얕으면 JVM process만 살아 있는데 핵심 API는 실패하는 target을 정상으로 본다.

너무 깊으면 DB나 외부 API의 작은 지연 때문에 모든 target이 동시에 제외될 수 있다.

Spring Boot에서는 다음처럼 목적을 나눠 생각한다.

  • 단순 살아 있음: process가 응답 가능한지 확인
  • 요청 처리 준비: DB migration, connection pool, 필수 설정이 준비됐는지 확인
  • 비핵심 의존성: 장애가 있어도 degrade mode로 처리 가능한지 분리

Load Balancer가 볼 path는 보통 “요청을 받아도 되는가”에 가까워야 한다.

설정 예시

resource "aws_lb_target_group" "order_api" {
  name     = "order-api-prod"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id
 
  health_check {
    path                = "/actuator/health/readiness"
    matcher             = "200"
    healthy_threshold   = 2
    unhealthy_threshold = 3
    timeout             = 3
    interval            = 10
  }
}

이 예시는 Load Balancer가 Spring readiness endpoint를 기준으로 target 상태를 판단하게 한다.

중요한 것은 path, timeout, interval이 애플리케이션 기동 시간과 의존성 상태에 맞는지다.

장애 신호

  • target은 healthy인데 특정 API만 실패한다.
  • target이 자주 unhealthy와 healthy 사이를 반복한다.
  • 배포 직후 target이 너무 빨리 트래픽을 받아 초기 요청이 실패한다.
  • Health Check path는 200을 반환하지만 DB 조회 API는 timeout 된다.
  • 특정 target만 5xx가 높다.
  • Load Balancer access log에는 502/504가 증가하지만 애플리케이션 로그가 적다.
  • TLS 인증서 만료나 listener rule 오류로 요청이 애플리케이션까지 도달하지 못한다.

이 신호는 Load Balancer와 Spring 상태 기준을 함께 봐야 한다.

관찰 명령

aws elbv2 describe-target-health --target-group-arn "$TG_ARN"
aws elbv2 describe-listeners --load-balancer-arn "$LB_ARN"
curl -I https://api.example.com/orders
curl -I http://10.0.10.15:8080/actuator/health/readiness

Load Balancer를 거친 요청과 target에 직접 보내는 요청을 비교하면 문제 구간을 좁힐 수 있다.

직접 요청이 성공하고 Load Balancer 경유만 실패하면 listener, rule, security group, target registration을 본다.

직접 요청도 실패하면 Spring process나 VM 상태를 먼저 본다.

안전한 완화 조치

  • 문제 target만 target group에서 제외한다.
  • Health Check timeout을 늘리기 전에 애플리케이션 응답 지연 원인을 확인한다.
  • 배포 직후 실패가 반복되면 startup 대기와 readiness 조건을 조정한다.
  • 특정 path rule이 문제면 영향 host/path만 임시 우회한다.
  • 502/504가 늘면 target port, security group, idle timeout, 애플리케이션 thread 상태를 함께 확인한다.
  • 인증서 문제가 있으면 새 인증서 적용 후 listener와 domain을 검증한다.

완화는 전체 트래픽 차단보다 영향 target이나 rule을 좁혀 적용하는 편이 안전하다.

하지 말아야 할 대응

  • Health Check 실패를 없애려고 항상 200을 반환하는 path로 바꾸지 않는다.
  • target이 unhealthy인 원인을 모른 채 모든 target을 강제로 등록하지 않는다.
  • Load Balancer idle timeout만 늘려 애플리케이션 지연을 숨기지 않는다.
  • Spring 기동이 끝나기 전 트래픽을 받게 두지 않는다.
  • access log와 애플리케이션 로그의 시간대를 맞추지 않고 판단하지 않는다.

인프라 담당자와 공유할 자료

  • Load Balancer arn 또는 이름, listener port, target group
  • Health Check path, interval, timeout, threshold
  • target id, private IP, port, 상태 변화 시각
  • 문제 host/path와 HTTP status
  • access log 샘플과 애플리케이션 로그 샘플
  • 최근 배포 시각과 target 등록/제외 시각

공유 자료는 “LB 문제”가 아니라 “어느 listener가 어느 target으로 보낸 요청이 어떤 상태가 됐는지”로 정리해야 한다.

운영 체크리스트

  • Health Check path가 요청 처리 준비 상태를 반영하는가?
  • target port와 애플리케이션 server port가 일치하는가?
  • Load Balancer access log가 보관되는가?
  • 배포 직후 target 등록과 트래픽 시작 사이 대기 시간이 있는가?
  • target별 오류율을 볼 수 있는가?
  • TLS 인증서 만료와 listener rule 변경이 점검되는가?

확인 질문

확인 질문

  • Load Balancer가 줄이는 대표 장애는 무엇인가?
    • 특정 target 장애가 전체 서비스 장애로 번지는 상황이다.
  • Health Check가 너무 얕으면 어떤 문제가 생기는가?
    • 실제 요청 처리가 불가능한 target도 정상으로 판단되어 트래픽을 받을 수 있다.
  • target이 healthy인데 API가 실패하면 무엇을 비교해야 하는가?
    • Load Balancer 경유 요청과 target 직접 요청, access log와 애플리케이션 로그를 비교해야 한다.

리뷰 체크포인트

  • listener, rule, target group, target port가 구분되어 있는가?
  • Health Check 설정이 Spring 준비 상태와 연결되는가?
  • 502/504와 애플리케이션 로그를 함께 보는가?
  • target 제외와 되돌림 절차가 있는가?
  • 인증서와 access log 운영 기준이 있는가?

관련 문서

백링크