[AWS] ELB, Auto Scaling

탄력성과 고가용성의 핵심, ELB와 Auto Scaling

이 두 서비스는 고가용성과 탄력성이라는 클라우드의 핵심 가치를 구현하는 "단짝"입니다. 덤프 문제에서 "트래픽 급증에 대비하고..." 또는 "인스턴스 장애에도 서비스를..." 같은 시나리오가 나온다면 100% 이 두 서비스를 묻는 문제입니다.

---

1. Load Balancer (ELB): 트래픽 분산의 "교통 경찰"

ELB(Elastic Load Balancing)는 이름 그대로 트래픽(Load)을 여러 대상(주로 EC2 인스턴스)에 분산(Balancing)시켜주는 서비스입니다. 왜 필요할까요?

1. 고가용성: 하나의 EC2 인스턴스가 장애로 다운되어도, 로드 밸런서가 정상적인 다른 인스턴스로만 트래픽을 보내주어 서비스 중단을 방지합니다.
2. 부하 분산: 대량의 트래픽을 여러 인스턴스에 골고루 나눠주어 한 서버가 과부하되는 것을 막습니다.
3. 단일 진입점: 클라이언트는 수십 대의 서버 IP를 알 필요 없이, 로드 밸런서의 대표 DNS 주소 하나로만 접근하면 됩니다.

SAA 시험에서는 특히 ALB와 NLB의 차이를 명확히 구분해야 합니다.

ALB (Application Load Balancer) - L7

• 계층: Layer 7 (HTTP/HTTPS)
• 특징: 애플리케이션 계층에서 작동하여 HTTP 헤더, URL 경로 등 "콘텐츠(내용)"를 보고 트래픽을 분산합니다.
• 핵심 기능:
  • 경로 기반 라우팅: example.com/api는 A 서버 그룹으로, example.com/images는 B 서버 그룹으로 분산
  • 호스트 기반 라우팅: api.example.com과 blog.example.com 요청을 다른 서버 그룹으로 분산
• 언제 사용하나?
  • 일반적인 웹사이트, MSA 아키텍처.
  • 덤프 문제에서 "URL 경로에 따라 다른 서버로..."라는 말이 나오면 100% ALB입니다.

NLB (Network Load Balancer) - L4

• 계층: Layer 4 (TCP/UDP)
• 특징: 네트워크 계층에서 작동합니다. IP 주소와 포트만 보고 트래픽을 매우 빠른 속도로 pass-through 합니다.
• 핵심 기능:
  • 초고성능 및 낮은 지연 시간: ALB보다 훨씬 빠르고 수백만 건의 요청을 처리할 수 있습니다.
  • 고정 IP(Elastic IP) 할당 가능: 로드 밸런서에 고정 IP를 부여할 수 있습니다.
• 언제 사용하나?
  • 성능이 매우 중요한 실시간 게임 서버, IoT 데이터 수집, 금융권 통신.
  • 덤프 문제에서 "극단적인 성능", "수백만 건의 요청", "낮은 지연 시간", "고정 IP"가 필요하다고 하면 NLB가 정답입니다.

---

2. Auto Scaling: 수요에 맞춘 "고무줄" 서버

Auto Scaling은 정의된 조건에 따라 EC2 인스턴스 수를 자동으로 늘리거나(Scale-Out) 줄여주는(Scale-In) 서비스입니다.

• 탄력성 및 비용 효율: 트래픽이 몰리면 서버를 늘려 대응하고, 트래픽이 없으면 서버를 줄여 비용을 절감합니다.
• 고가용성 및 자가 치유: EC2 인스턴스가 비정상 상태가 되면, Auto Scaling 그룹이 이를 자동으로 감지하여 종료시키고 새 인스턴스를 다시 시작시켜 항상 원하는 수의 건강한 인스턴스를 유지합니다.

핵심 구성 요소

1. 시작 템플릿 (Launch Template)

   • "무엇을" 시작할지에 대한 정의서입니다. (AMI, 인스턴스 유형, 보안 그룹, 키 페어 등)
   • (참고: 과거에는 '시작 구성(Launch Configuration)'을 썼지만, 현재는 '시작 템플릿' 사용이 권장됩니다.)

2. Auto Scaling Group (ASG)

   • "어디서", "몇 개를" 관리할지에 대한 그룹입니다.
   • Min (최소): 아무리 트래픽이 없어도 유지할 최소 인스턴스 수.
   • Max (최대): 아무리 트래픽이 많아도 늘어날 최대 인스턴스 수. (비용 상한선)
   • Desired (원하는 용량): 현재 유지하려는 인스턴스 수. ASG는 이 숫자를 맞추기 위해 노력합니다.

3. 조정 정책 (Scaling Policies)

   • "언제" 늘리고 줄일지에 대한 규칙입니다.
   • 대상 추적 조정 (Target Tracking): 가장 많이 쓰입니다. (예: "그룹의 평균 CPU 사용률이 50%가 되도록 인스턴스 수를 조절해줘")
   • 예약된 조정 (Scheduled Scaling): 예측 가능한 트래픽에 사용합니다. (예: "매주 금요일 오후 6시에 인스턴스를 5대로 늘려줘")

---

3. ELB + Auto Scaling:

이 두 서비스는 항상 함께 작동하여 완벽한 아키텍처를 만듭니다.

[사용자] → [ELB] → [Auto Scaling Group (EC2 인스턴스들)]

이 조합이 어떻게 작동하는지 시나리오로 이해하면 덤프 문제 풀이가 쉬워집니다.

• 시나리오 1: 트래픽 급증 (Scale-Out)

  1. 사용자 트래픽이 몰려 EC2 인스턴스들의 평균 CPU가 70%를 넘습니다.
  2. CloudWatch가 이를 감지하고 경보를 울립니다.
  3. ASG의 조정 정책(예: CPU 50% 대상 추적)이 트리거됩니다.
  4. ASG가 시작 템플릿을 기반으로 새 EC2 인스턴스를 시작합니다.
  5. 새 인스턴스가 부팅되면, ASG가 자동으로 이 인스턴스를 ELB에 등록시킵니다.
  6. ELB가 새 인스턴스에 대한 Health Check를 통과하면, 트래픽을 분산하기 시작합니다.

• 시나리오 2: 인스턴스 장애 (Fault-Tolerance)

  1. EC2 인스턴스 3대 중 1대가 갑자기 다운됩니다.
  2. ELB가 헬스 체크를 실패하고, 다운된 인스턴스로 트래픽 전송을 즉시 중단합니다. (서비스 중단 방지)
  3. ASG도 헬스 체크를 통해 인스턴스 장애를 감지합니다.
  4. ASG가 Desired 용량(예: 3대)을 맞추기 위해, 장애가 난 인스턴스를 종료하고 새 인스턴스를 자동으로 시작합니다.
  5. 새 인스턴스가 부팅되면 ELB에 등록되고 다시 트래픽을 받기 시작합니다.

이처럼 ELB는 트래픽을 분산하고, ASG는 서버의 수(탄력성)와 건강 상태(자가 치유)를 책임집니다.