☁️ 클라우드

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에 등록되는 데 약간 시간이 걸릴 수 있어요."

이 주제로 모의면접 보기 → WIA SOOM AI 면접 · 무료로 시작

⚠️ 흔한 실수 & 주의사항

❌
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에 저장하여 트래픽 분석이 가능하게 하세요.

🔗 관련 용어

📚 더 배우기