☁️ 클라우드

ALB

Application Load Balancer

AWS의 L7 로드 밸런서. HTTP/HTTPS 트래픽을 경로, 호스트 기반으로 분산.

📖 상세 설명

ALB(Application Load Balancer)는 AWS에서 제공하는 OSI 7계층(애플리케이션 레이어) 로드 밸런서입니다. HTTP/HTTPS 프로토콜의 내용을 이해하고, URL 경로(/api/*, /images/*), 호스트 헤더(api.example.com, www.example.com), HTTP 메서드, 쿼리 스트링 등을 기반으로 지능적인 트래픽 라우팅이 가능합니다.

2016년 AWS re:Invent에서 발표되어 기존 Classic Load Balancer(CLB)를 대체하고 있습니다. ALB는 하나의 로드 밸런서로 여러 애플리케이션을 호스팅할 수 있어, 마이크로서비스 아키텍처에 최적화되어 있습니다. Target Group 개념을 통해 EC2, ECS, Lambda, IP 주소 등 다양한 백엔드로 트래픽을 분산할 수 있습니다.

WebSocket과 HTTP/2를 기본 지원하며, gRPC 프로토콜도 지원합니다. AWS Certificate Manager(ACM)와 연동하여 무료 SSL/TLS 인증서를 자동 갱신하고, HTTPS 종단(SSL Termination)을 로드 밸런서에서 처리하여 백엔드 서버의 부하를 줄일 수 있습니다.

실무에서 ALB는 ECS Fargate, EKS와 함께 컨테이너 기반 애플리케이션의 진입점으로 가장 널리 사용됩니다. 고정 응답, 리다이렉트, 인증(OIDC/Cognito) 등의 기능을 로드 밸런서 레벨에서 처리할 수 있어 애플리케이션 코드를 단순화할 수 있습니다.

💻 코드 예제

# ALB + Target Group + Listener 전체 구성
resource "aws_lb" "main" {
  name               = "my-app-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = aws_subnet.public[*].id

  enable_deletion_protection = true

  tags = {
    Environment = "production"
  }
}

# Target Group - ECS/EC2 대상
resource "aws_lb_target_group" "app" {
  name        = "my-app-tg"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.main.id
  target_type = "ip"  # Fargate의 경우 ip, EC2는 instance

  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    matcher             = "200"
    path                = "/health"
    timeout             = 5
    unhealthy_threshold = 3
  }
}

# HTTPS Listener (443)
resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.main.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
  certificate_arn   = aws_acm_certificate.main.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app.arn
  }
}

# 경로 기반 라우팅 규칙
resource "aws_lb_listener_rule" "api" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api.arn
  }

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

🗣️ 실무에서 이렇게 말하세요

💬 아키텍처 회의에서
"ALB에서 경로 기반 라우팅으로 /api/*는 백엔드 서비스로, /는 프론트엔드 서비스로 분기하면 하나의 도메인에서 여러 서비스를 운영할 수 있어요. SSL 인증서도 ACM에서 무료로 발급받아 ALB에 붙이면 됩니다."
💬 면접에서
"ALB와 NLB의 차이점을 말씀드리면, ALB는 L7에서 HTTP 콘텐츠를 파싱하여 라우팅하고, NLB는 L4에서 TCP/UDP 연결을 그대로 전달합니다. 마이크로서비스처럼 경로 기반 라우팅이 필요하면 ALB, 게임 서버나 고성능 TCP가 필요하면 NLB를 선택합니다."
💬 장애 대응에서
"5xx 에러가 급증했는데 ALB 타겟 그룹 헬스체크 보니까 healthy host가 0이네요. 백엔드 컨테이너 로그 확인해보고, 헬스체크 경로(/health)가 제대로 응답하는지 먼저 확인합시다. ECS 태스크가 새로 뜨면서 ALB에 등록되는 데 약간 시간이 걸릴 수 있어요."

⚠️ 흔한 실수 & 주의사항

Security Group 설정 실수

ALB의 Security Group에서 0.0.0.0/0 443만 열고, Target(EC2/ECS)의 Security Group에서 ALB Security Group을 소스로 허용해야 합니다. Target에 0.0.0.0/0을 열면 ALB를 우회한 직접 접근이 가능해져 보안 위험이 발생합니다.

헬스체크 미스매치

ALB 헬스체크 경로와 애플리케이션의 실제 헬스체크 경로가 다르면 healthy host가 0이 되어 503 에러가 발생합니다. 헬스체크 interval, threshold 값도 애플리케이션 시작 시간을 고려해서 설정하세요.

올바른 구성

ALB는 최소 2개 이상의 가용 영역(AZ)에 서브넷을 배치하세요. Cross-Zone Load Balancing을 활성화하면 AZ 간 트래픽 분산이 균등해집니다. 프로덕션에서는 반드시 Access Log를 S3에 저장하여 트래픽 분석이 가능하게 하세요.

🔗 관련 용어

📚 더 배우기