250207 - 로드 밸런싱

윤예원 - 대용량트래픽처리 - 로드 밸런싱

🚀 1️⃣ 왜 로드 밸런싱을 구현하는가?  
  • 앞으로 대량의 트래픽을 처리하는 프로젝트를 맡을 때를 대비해 이 프로젝트에서 구현하고자 
  했다.  
  • 단일 서버는 트래픽 증가 시 부하로 인해 응답 속도가 느려지거나 다운될 위험이 있다.  
  • 이를 방지하기 위해 로드 밸런서를 사용해 여러 서버로 트래픽을 분산시킬 수 있다.  
  • AWS ALB(Application Load Balancer)를 사용하여 트래픽을 효율적으로 분산하고자 한다.  
______________________________________________________________________________________
🔎 2️⃣ Nginx 대신 AWS를 선택한 이유   
 AWS는 Fully Managed 서비스로 관리 부담을 줄일 수 있다는 점이 강점.  

✅ 1. 인프라 관리 부담 감소 
  • AWS는 자동화된 관리가 가능.  
  • Nginx는 로드 밸런서를 수동으로 구성한 후 원하는 형태로 보조해야 함.  

✅ 2. 그룹 배포가 편리함  
  • AWS ALB는 Auto Scaling Group 과 연동되어 배포를 자동화.  
  • Nginx의 경우, 배포 시 수동적인 결정이 필요.  

✅ 3. 보안 강화   
  • AWS WAF, AWS Shield 등의 보안 서비스와 ALB를 연동할 수 있음.  
  • Nginx의 경우, 보안 복잡도가 더 높음.  

✅ 4. L7(Application Layer) 기반의 HTTP/HTTPS 최적화   
  • ALB는 L7 기반 으로 동작하여, URL 경로(Path-based), 호스트(Host-based)라우팅을 제공 
  • Nginx도 가능하지만 수동 설정이 필요하며, 관리 복잡성이 증가. 
 ______________________________________________________________________________________
🔎 3️⃣ ALB vs. NLB vs. CLB - 왜 ALB를 선택했는가? 
💡 현재 프로젝트는 HTTP/HTTPS 기반의 API 서비스 이므로 ALB가 가장 적합.   

기능 ALB (Application Load Balancer) NLB (Network Load Balancer) CLB (Classic Load Balancer)

레이어	L7 (Application Layer)	L4 (Transport Layer)	L4 & L7 혼합
트래픽 타입	HTTP, HTTPS, gRPC	TCP, UDP	HTTP, HTTPS, TCP
라우팅 기능	✔ 경로(Path), 호스트(Host) 기반 라우팅 지원	❌ 단순 IP 기반 라우팅	❌ 제한적
SSL/TLS 종료	✔ 지원	❌ 불가 (EC2에서 직접 처리해야 함)	✔ 지원
Auto Scaling
연동	✔ 완벽 지원	✔ 지원 (하지만 헬스 체크 기능이 제한적)	❌ 지원 X
헬스 체크 (Health Check)	✔ 세밀한 HTTP 상태 코드 기반 헬스 체크	✔ TCP 기반 헬스 체크	❌ 제한적
보안 및 인증	✔ WAF, IAM 인증, AWS Shield와 연동 가능	❌ 직접 설정 필요	❌ 직접 설정 필요
주요 사용 사례	REST API, 웹 애플리케이션, 마이크로서비스	게임 서버, 메시지 큐, TCP 기반 서비스	기존 레거시 서비스 유지보수

✅ ALB를 선택한 이유  
1️⃣ HTTP/HTTPS 기반의 API 트래픽 처리에 적합  
  • API 서버를 운영하는 환경에서는 L7 계층의 라우팅 기능이 필수적.  
  • ALB는 URL 경로(Path-based), 호스트(Host-based) 라우팅을 지원하여 API 서비스 확장에 
   유리함.  

2️⃣ SSL/TLS Termination 지원 (서버 부하 감소) 
  • ALB에서 SSL을 해석(terminate)한 뒤, 백엔드 서버에 HTTP로 전달 가능.  
  • API 서버에서 직접 SSL을 처리하지 않아도 되어, 서버 부하를 줄이고 응답 속도를 개선할 수
   있음.  

3️⃣  Auto Scaling로 자동화 가능 
  • 트래픽 증가 시 자동으로 인스턴스를 추가하고, 감소하면 제거 가능.  
  • NLB는 L4 기반이라 단순 TCP 연결만 관리하므로, API 요청을 효과적으로 분배하기 어려움.  

4️⃣  세밀한 헬스 체크 및 오류 감지 
  • HTTP 상태 코드(2xx, 3xx, 4xx, 5xx) 기반으로 비정상적인 서버를 자동으로 제외.  
  • NLB는 TCP 헬스 체크만 제공**하여, 애플리케이션 레벨의 장애 감지 기능이 부족함.  

5️⃣ 보안 기능이 강력함 
  • AWS WAF, IAM 인증, AWS Shield** 등과 연동 가능.  
  • API 서버를 운영할 때 웹 방화벽(WAF)을 적용하여 악의적인 공격을 방어할 수 있음.   
 _____________________________________________________________________________________ 
🔎 4️⃣ 어떻게 구현할 것인가?  

✅ 필요 서비스 목록  
  • EC2 : API 서비스 배포, 로드 밸런서 추가(앱 서버 만들기)  
  • RDS  : 데이터베이스  
  • Certificate Manager : SSL/TLS 인증서 관리  
  • Route 53 : DNS 로드 밸런싱 설정  
     (구매한 도메인의 관리를 Gabia → AWS 로 이전)  
  • VPC : 네트워크 보안  
  • IAM : 권한 관리  

✅ 구현 환경 
1️⃣ AWS ALB 설정 
  • HTTP API 요청을 여러 서버로 분산.  
  • 리스너(Listener) 설정을 통해 트래픽을 적절한 서버 그룹(Target Group)으로 라우팅.  

2️⃣ Auto Scaling Group 연동  
  • 트래픽 증가 시 자동 확장, 감소 시 자동 축소.  

3️⃣ API 서버 구성  
  • NestJS 기반 API 서버 여러 대를 배포.  
  • 세션 유지(Session Persistence) 전략 고려.  
  • PM2 클러스터 모드 활용 가능.  

4️⃣ Nginx Reverse Proxy 활용 (필요 시)  
  • 특정 경로에 따라 다른 서비스로 라우팅 가능