AWS DVA 항해기 - ELB + ASG - ELB

로드 밸런싱(Load Balancing)

❓ 로드 밸런서

❔ 로드 밸런서(Load Balancer)가 하는 일

“트래픽 분배기 + 보안관 + 건강검진기” 역할을 함

1. 트래픽 분배

   • 사용자의 요청(HTTP, HTTPS, TCP 등)을 받아서

   뒤에 있는 여러 EC2 인스턴스(= Target/Backend)에게 나눠줌

2. Health Check (헬스 체크)

   • 인스턴스 상태를 주기적으로 체크

   • 죽어 있으면 그 서버로는 더 이상 트래픽 안 보냄 => 한 서버가 죽어도 서비스는 계속 동작 (고가용성)

3. 스케일링과 궁합

   • Auto Scaling Group이 인스턴스를 늘리거나 줄이면,

   • 로드 밸런서가 그 인스턴스들을 자동으로 붙였다 떼었다 하면서 트래픽 분배

4. 단일 진입점 (Single Point of Access)

   • 사용자는 로드 밸런서의 DNS 이름 하나만 알고 접속 => 사용자는 본인이 어떤 인스턴스에 연결되었는지 알 수 ❌

   • 그 뒤에 서버가 몇 대든, 어떤 AZ에 있든 상관 없음
     → IP 바뀌는 개별 EC2 대신, 고정된 접점이 되어 줌

5. 보안/암호화 처리 역할 → SSL 종료

   클라이언트와 HTTPS 연결을 로드 밸런서에서 종료

   = SSL/TLS Termination / Offloading

   • 인증서를 로드 밸런서에서 관리하고,
     백엔드에는 HTTP로 넘기거나 다시 HTTPS로 재암호화해서 넘김

   • 효과:

     개별 서버에서 TLS 설정/인증서 관리 안 해도 됨

     암복호화 부담을 LB가 떠안아서 백엔드 부담↓

     필요하다면 end-to-end 암호화도 구성 가능 (LB ↔ 백엔드도 HTTPS)
     
     

❔ 로드 밸런서가 필요한 이유

• 부하를 다수의 다운스트림 인스턴스로 분산하기 위해

• 하나의 액세스 포인트를 노출하기 위해

• 다운스트림 인스턴스의 오류를 핸들링하기 위해 & 헬스체크

• SSL 종료를 제공

• 쿠키로 고정도 강화
  고정도(affinity / stickiness) => 같은 클라이언트(브라우저)에서 오는 요청을 계속 같은 백엔드 인스턴스로 보내 주는 정도

  고정도를 만드는 방법은 여러 가지인데, 대표적으로:

  1. IP 기반: 같은 클라이언트 IP면 같은 서버로 보내기
  2. 쿠키 기반: 브라우저에 심어둔 쿠키 값으로 같은 서버로 보내기
     => “쿠키로 고정도를 강화할 수 있다”는 말은
     → IP만 믿지 말고, 쿠키를 사용해서 더 안정적으로 “같은 서버로 묶어라” 라는 의미
     

  Why❓

  ➡️ IP는 바뀔 수 있음
  모바일, 4G/5G, 회사 프록시, NAT 뒤에 있을 때

  여러 사용자가 같은 공인 IP를 공유하기도 함

  반면 쿠키는 브라우저 단위로 저장됨

  그 브라우저에서 오는 요청엔 항상 같은 쿠키가 딸려옴
  → 훨씬 “누가 누군지”를 안정적으로 구분 가능

  “고정도(affinity)를 강화한다 = 한 사용자를 더 정확하게 같은 서버에 붙여준다”

  ---

  Example)

  예를 들어 ALB + EC2 구조에서:

  사용자가 브라우저로 https://example.com 접속

  로드 밸런서(ALB) 가 첫 요청을 서버 A로 보냄

  이때 ALB가 특정 쿠키(예: AWSALB, AWSALBTG 같은 LB 쿠키) 를 응답에 실어 브라우저에 내려줄 수 있어

  이후 요청에서 브라우저는 항상 그 쿠키를 붙여서 요청함

  ALB는 쿠키를 보고 “아, 이 쿠키는 서버 A로 붙어 있던 애네?” 하고
  → 계속 서버 A로 라우팅

• 영역에 걸친 고가용성을 가짐
• 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리 가능

ELB를 사용하는 이유?

1. 운영 부담 줄어드는 AWS 관리형 서비스

   직접 로드 밸런서(Nginx, HAProxy, keepalived 등)를 구축하면:

   설치, 설정, 패치, 모니터링, 장애 대응, 스케일링까지 전부 내가 해야 함

   ELB는 fully managed:

   OS, 소프트웨어 패치, 스케일링, 고가용성 설계 등을 AWS가 맡음
   → 운영(운영 인력·시간) 비용이 줄어든다
   → 시험 키워드: “undifferentiated heavy lifting을 AWS가 대신해준다”

2. ELB가 다른 AWS 서비스들이랑 붙어서 ‘세트로’ 동작하도록 설계돼 있다
   • EC2, EC2 Auto Scaling Groups, Amazon ECS
   • AWS Certificate Mananger(ACM), CloudWatch
   • Route 53, AWS WAF, AWS Global Accelerator

ELB의 Health Check

실제 애플리케이션 레벨로 두드려 보는 것

1. 포트

   타겟 인스턴스(EC2 등)에서 어느 포트로 요청을 보낼 건지

• EC2가 80포트에서 웹 서버 실행 중이면

  => Health Check Port = 80

• 앱 서버가 8080포트에서만 떠 있으면

  => Health Check Port = 8080

• traffic port 로 하면

  => Target Group에 설정된 포트(예: 80, 443 등)를 그대로 따라감

  그래서 “포트로 Health Check를 한다” =

  “ELB가 각 타겟의 지정된 포트에 직접 접속해서 확인한다”는 뜻
  

2. 라우트

   특정 URL 경로(라우트)”로 GET을 날려 보고 응답 코드로 판별

   예시:

• Health check path: /

• Health check path: /health

• Health check path: /status

• Health check path: /actuator/health (Spring Boot 같은 거)

http://타겟IP:포트/health

 http://10.0.1.23:8080/health

응답값이 200~399 → Healthy / 500, 타임아웃 등 → Unhealthy

AWS의 관리형 로드 밸런서 종류

1. CLB(2009) - v1
   • HTTP, HTTPS, TCP, SSL, secure TCP 지원

2. ALB(2016) -v2

   • HTTP, HTTPS, WebSocket 프로토콜 지원

3. NLB(2017) - v2

   • TCP, TLS(secure TCP), UDP 프로토콜 지원

4. GWLB(Gateway Load Banlancer: 2020)

   • 3계층(네트워크 레이어에서 동작) - IP 프로토콜에서 작동

Load Balancer Security Groups

EC2의 Security Groups Rule은 포트 80 HTTP 트래픽 & 소스는 IP 범위가 아닌 LB의 SG가 된다.

→ EC2 인스턴스는 Load Balancer에서 온 트래픽만을 허용하게 되는 강화된 보안 메커니즘이 되는 것