🚀 사용자가 늘어나면, 서버는 어떻게 확장할까?
서비스 운영 중 서버는 몇 대가 필요할까?
✅ 사용자가 적다면 1대의 서버로도 충분하지만,
✅ 사용자가 증가하면 서버의 부하가 커지고, 심하면 서버가 다운될 수도 있다.
이럴 때 "스케일 업(Scale-Up)" 또는 "스케일 아웃(Scale-Out)"을 통해 서버를 확장해야 한다.
🏗️ 서버 확장 방법
1️⃣ 스케일 업 (Scale-Up)
✔ 현재 서버의 성능을 업그레이드하는 방법
✔ CPU, 메모리, 디스크 추가하여 처리 능력 향상
✔ (수직 확장, Vertical Scaling)
2️⃣ 스케일 아웃 (Scale-Out)
✔ 서버 개수를 늘려 부하를 분산하는 방법
✔ 여러 대의 서버가 동일한 요청을 처리
✔ (수평 확장, Horizontal Scaling)
💡 스케일 아웃 시 "로드 밸런서(Load Balancer)"가 필요
🔀 로드 밸런서(Load Balancer)란?
로드 밸런싱 : 트래픽을 여러 서버로 분산하여 서버의 부하를 줄이고 안정성을 높이는기술.
로드 밸런서 : 로드 밸런싱을 수행하는 하드웨어 또는 소프트웨어 장비.
✅ 로드 밸런서 주요 역할
1️⃣ 요청 분산
사용자 요청을 여러 서버로 분산 →
✔ 부하 분산 : 특정 서버 과부하 방지
✔ 확장성 : 성능 및 속도 최적화
2️⃣ 헬스 체크 (Health Check)
로드 밸런서는 백엔드 서버의 상태를 주기적으로 확인하는 헬스 체크를 수행함.
✔ 정상적인 응답이 없으면 해당 서버 제외
✔ 장애 감지 시 다른 서버로 트래픽 전환
3️⃣ SSL 처리
✔ HTTPS를 통해 암호화된 데이터 송수신 가능
✔ 로드 밸런서가 암호화 처리 → 웹 서버 부담 감소
4️⃣ 부정 요청 대응
✔ 부정 요청(DoS, DDoS 공격 등) 차단
✔ 웹 서버가 아닌 로드 밸런서에서 먼저 필터링
🔹로드 밸런서 유형
✅ L4 vs L7 로드 밸런서
| 기준 | L4 (Transport Layer) | L7 (Application Layer) |
| 속도 | 빠름 | 상대적으로 느림 |
| 트래픽 분산 기준 | IP, 포트, 프로토콜 | URL, 쿠키, 헤더, 요청 내용 |
| 세부 트래픽 제어 | 불가능 | 가능 |
| 주요 활용 | TCP/UDP 서비스, 게임 서버 | API, 마이크로서비스, 웹 서비스 |
현재 L7 로드 밸런서(ALB 등)를 선호하는 추세
세션 유지, 정교한 트래픽 제어가 필요한 서비스에 적합
🔹 AWS 로드 밸런서 종류
AWS에서는 ELB(Elastic Load Balancing) 서비스를 통해 다양한 로드 밸런서를 제공.
로드 밸런서 특징 사용 사례
| 로드 밸런서 유형 | 특징 | 이용사례 |
| ALB (Application Load Balancer) | L7 기반 HTTP/HTTPS 트래픽 최적화, 고급 라우팅 기능 제공 |
웹 애플리케이션, API 서버 |
| NLB (Network Load Balancer) | L4 기반 초고성능, 저지연, TCP/UDP 지원 |
게임 서버, 금융 시스템 |
| CLB (Classic Load Balancer) | 예전 방식, 현재는 거의 사용되지 않음 보안 및 네트워크 가상 어플라이언스용 |
기존 AWS 시스템과 호환 필요 시 |
🎯 요청 라우팅(Request Routing)
로드 밸런서는 요청을 내부 서버로 전달할 때 포트나 프로토콜을 변환할 수 있다.
예시:
✅ 클라이언트 → HTTPS 80 포트 요청
✅ 로드 밸런서 → 내부 서버로 HTTP 8080 변환
(SSL 처리 부담을 로드 밸런서에서 처리하기 때문!)
🎃 AWS에서 ALB 생성하기
1️⃣ 가용 영역 설정
✔ 요청을 분산할 가용 영역 선택
✔ Public Subnet에 연결 필수!
2️⃣ 보안 그룹 설정
✔ HTTP/HTTPS 요청을 받을 보안 그룹 설정
3️⃣ 대상 그룹 생성
✔ 로드 밸런서를 연결할 웹 서버 그룹 생성
✔ 포트(예: 8080) 설정
✔ 헬스 체크(Health Check) 경로 입력 → 정기적인 서버 상태 검사
4️⃣ 리스너 및 라우팅 설정
✔ 리스너 생성 (예: HTTP 80)
✔ 생성한 대상 그룹과 연결
✅ ALB 생성 후, DNS 주소를 사용해 접속 가능!
🔄 오토스케일링 ( Auto Scaling)
✅ 오토 스케일링 개념
✔ 트래픽이 증가하면 자동으로 EC2(서버) 인스턴스를 확장하고,
✔ 트래픽이 감소하면 불필요한 인스턴스를 줄여 비용 절감이 가능.
✔ AWS 오토 스케일링 그룹(ASG) 활용 가능
✅ 오토 스케일링 장점
✔ 트래픽 증가 시 자동으로 서버 추가
✔ 서버 과부하 방지
✔ 트래픽 감소 시 자동으로 불필요한 서버 삭제 (비용 절감)
✔ 로드 밸런서(ALB)와 함께 사용하면 트래픽을 자동으로 분산 가능
🔥 로드 밸런싱 vs 오토 스케일링
기능 설명
| 로드 밸런싱 | 트래픽을 여러 서버로 분산 |
| 오토 스케일링 (Auto Scaling) | 서버를 자동으로 추가/삭제하여 확장 |
✅ 트래픽 증가 → 서버 자동 추가
✅ 트래픽 감소 → 서버 자동 삭제 (비용 절감!)
✅ AWS 오토 스케일링 그룹(ASG) 활용 가능
🛠️ NestJS에서 로드 밸런싱 적용 방법
1️⃣ Nginx Reverse Proxy 활용
http {
upstream nest_servers {
server 127.0.0.1:3000;
server 127.0.0.1:3001;
server 127.0.0.1:3002;
}
server {
listen 80;
location / {
proxy_pass http://nest_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
✔ 클라이언트 요청을 자동으로 여러 NestJS 서버로 분산
2️⃣ AWS ALB + 오토 스케일링 활용
✔ 트래픽 증가 시 EC2 자동 확장
✔ 로드 밸런서와 연계하여 부하 분산
3️⃣ PM2 클러스터 모드 활용
npm install pm2 -g
pm2 start dist/main.js -i max
✔ 단일 서버 내에서도 멀티 프로세스로 트래픽 분산 가능
🎯 결론
✅ 사용자가 많아진다면? → 로드 밸런싱 + 오토 스케일링 적용 필수!
✅ 트래픽 증가 시 자동 확장? → AWS 오토 스케일링 그룹(ASG) 활용!
✅ 세션 유지 필요? → Sticky Session or 세션 클러스터링 고려!
💡 AWS ALB + 오토 스케일링 적용 시 자동 운영 가능 🚀
1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣ 6️⃣ 7️⃣ 8️⃣ 9️⃣ 🔟
참고
https://chunsubyeong.tistory.com/106
https://kchanguk.tistory.com/146
https://sjh9708.tistory.com/98
https://dev.classmethod.jp/articles/load-balancing-types-and-algorithm/
https://www.smileshark.kr/post/what-is-a-load-balancer-a-comprehensive-guide-to-aws-load-balancer
대용량 트레픽 처리방법
https://hs-backend.tistory.com/228
nestjs 적용
https://andongmin.com/docs/nest/ch9/ch9-3
https://guti-coding.tistory.com/197?category=1195671
aws 설정
https://aws.amazon.com/ko/elasticloadbalancing/?did=ft_card&trk=ft_card
로드벨런서 컨트롤러
https://docs.aws.amazon.com/eks/latest/userguide/aws-load-balancer-controller.html
가비아 도메인으로 인증서 발급
정리중
로드 밸런싱( 대용량 트래픽 처리 )
유형 선택 : Application Load Balancer (ALB)
1. 로드 밸런싱 (Load Balancing)
✅ 로드 밸런싱 개념
로드 밸런싱은 여러 서버(인스턴스)에 트래픽을 분산하여 특정 서버에 과부하가 걸리지 않도록 하는 기술이다.✔️ 서버 부하 감소✔️ 성능 및 속도 최적화✔️ 서버 장애 시 자동 트래픽 전환
로드 밸런서 (Load Balancer)란?로드 밸런싱을 수행하는 하드웨어 또는 소프트웨어 장비
✅ 로드 밸런싱 주요 목적
부하 분산: 요청을 여러 서버로 나누어 병목 현상 방지
고가용성: 서버 장애 시 자동으로 다른 서버가 요청 처리
확장성: 트래픽 증가 시 서버 추가 가능
안정성: 장애 감지 후 정상 서버로 자동 전환
✅ 헬스 체크 (Health Check)
로드 밸런서는 백엔드 서버의 상태를 주기적으로 확인하는 헬스 체크를 수행함.✔️ 정상적인 응답이 없으면 해당 서버 제외✔️ 장애 감지 시 다른 서버로 트래픽 전환
2. 로드 밸런서 유형
✅ L4 vs L7 로드 밸런서
기준
L4 (Transport Layer)
L7 (Application Layer)
속도
빠름
상대적으로 느림
트래픽 분산 기준
IP, 포트, 프로토콜
URL, 쿠키, 헤더, 요청 내용
세부 트래픽 제어
불가능
가능
주요 활용
TCP/UDP 서비스, 게임 서버
API, 마이크로서비스, 웹 서비스
현재 L7 로드 밸런서(ALB 등)를 선호하는 추세세션 유지, 정교한 트래픽 제어가 필요한 서비스에 적합
3. AWS 로드 밸런서 선택
로드 밸런서 유형
특징
사용 사례
ALB(Application Load Balancer)
L7 기반, HTTP/HTTPS 트래픽 처리
API 서버, 마이크로서비스, 웹 애플리케이션
NLB(Network Load Balancer)
L4 기반, 초고성능, 저지연
WebSocket 서버, 게임 서버, 금융 시스템
GLB(Gateway Load Balancer)
보안 및 네트워크 가상 어플라이언스용
방화벽, 침입 탐지 시스템
4. 오토 스케일링 (Auto Scaling)
✅ 오토 스케일링 개념
트래픽이 증가하면 자동으로 EC2(서버) 인스턴스를 확장하고,트래픽이 감소하면 불필요한 인스턴스를 줄여 비용 절감이 가능.✔️ AWS 오토 스케일링 그룹(ASG) 활용 가능
✅ 오토 스케일링 장점
트래픽 증가 시 자동으로 서버 추가
서버 과부하 방지
트래픽 감소 시 자동으로 불필요한 서버 삭제 (비용 절감)
로드 밸런서(ALB)와 함께 사용하면 트래픽을 자동으로 분산 가능
5. Sticky Session (세션 유지)
기본적으로 로드 밸런서는 요청을 여러 서버에 랜덤하게 분배하지만,로그인 유지와 같은 세션이 필요한 경우 같은 사용자의 요청을 동일한 서버로 보내야 함.
✅ Sticky Session 방식
1️⃣ 로드 밸런서에서 처리 (AWS ALB에서 Sticky Session 설정 가능)✔️ 쿠키를 이용하여 특정 사용자의 요청을 동일한 서버로 유지
2️⃣ 세션 클러스터링✔️ 서버 간 세션을 공유하는 방식✔️ 서버 장애 시에도 세션 유지 가능✔️ 단점: 새로운 서버 추가 시 기존 서버 설정 업데이트 필요
Sticky Session 적용 추천 사례
로그인 상태 유지가 필요한 웹 서비스
특정 사용자의 세션 데이터가 특정 서버에 종속될 경우
6. NestJS에서 로드 밸런싱 & 오토 스케일링 적용
✅ 1) Nginx Reverse Proxy 활용
📌 Nginx 설정 예시
// /etc/nginx/nginx.conf
http {
upstream nest_servers {
server 127.0.0.1:3000;
server 127.0.0.1:3001;
server 127.0.0.1:3002;
}
server {
listen 80;
location / {
proxy_pass http://nest_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
✔️ 결과: 클라이언트 요청이 자동으로 여러 NestJS 인스턴스로 분산됨
✅ 2) AWS 로드 밸런서 & 오토 스케일링 활용
AWS ALB + ASG (Auto Scaling Group) 조합 추천
요청량에 따라 EC2 인스턴스 자동 증감
트래픽 증가 시 서버 자동 추가 → 과부하 방지
트래픽 감소 시 불필요한 서버 자동 삭제 → 비용 절감
✅ 3) PM2 클러스터 모드 활용 (단일 서버 내 멀티 프로세스)
📌 NestJS 클러스터링 실행 방법
npm install pm2 -g
pm2 start dist/main.js -i max
✔️ 단일 서버에서도 여러 개의 NestJS 프로세스를 실행하여 트래픽 분산 가능
7. 결론
✅ 서버가 2개 이상이라면? → 로드 밸런싱 + 오토 스케일링 적용 필수✅ 트래픽 증가 시 자동 확장? → AWS 오토 스케일링 그룹(ASG) 활용✅ 세션 유지 필요? → Sticky Session or 세션 클러스터링 고려
✔️ 지웅님과 조율하여 CRCD를 통해 모든 인스턴스 업데이트 필수✔️ AWS 로드 밸런서(ALB) + 오토 스케일링 적용 시 자동 운영 가능 🚀
로드 밸런싱 (Load Balancing) 개념
로드 밸런싱은 여러 서버에 트래픽을 분산하여 특정 서버에 과부하가 걸리지 않도록 하는 기술이다. 대용량 트래픽을 처리할 때 성능과 안정성을 유지하는 핵심 요소다.
로드밸런싱(Load Balancing)이란 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율을 증가, 부하량, 속도저하등 고려하여 분산처리하여 해결해주는 서비스이다.
로드밸런싱(Load Balancing)을 해주는 소프트웨어 혹은 하드웨어 장비를 로드밸런서(Load Balancer)라고 한다.
로드 밸런싱의 주요 목적
- 부하 분산 (Load Distribution) : 요청을 여러 서버로 나눠 병목 현상을 방지
- 고가용성 (High Availability) : 특정 서버가 다운되더라도 다른 서버가 요청을 처리하도록 보장. 트래픽 양에 따라서 서버를 추가하거나 제거하는 것이 가능함.
- 확장성 (Scalability) : 서버를 추가하여 트래픽 증가에 대응 가능.
- 안정성 (Reliability) : 특정 서버 장애 시 다른 서버로 자동으로 요청을 전환
헬스체커
로드밸런서는 백엔드 서버에 대한 헬스 체크를 수행한다. 주기적으로 백엔드 서버에 요청을 보내서 서버 상태를 확인하고, 문제가 있는 경우 해당 서버에 트래픽을 전송하지 않는다. 문제가 있는 친구가 있으면 감지하여 다른 친구에게 보내서 처리한다는 뜻이다.
_________________________________________________________________________
사용할 로드밸런서 선택
로드 밸러서의 종류 : L4 로드 밸런서 vs L7 로드 밸런서
'OSI 7 Layer를 기준으로 부하를 어떻게 분산할지'에 따라 종류가 나뉜다.
2, 3계층을 기준으로 부하를 분산하면 각 L2, L3인 방식이다.
상위 계층은 하위 계층의 데이터를 모두 가지기 때문에, 상위 계층일수록 섬세한 로드 밸런싱이 가능하고 하위 계층일수록 간단한 로드 밸런싱만 가능하다.
상위 계층일수록 가격이 비쌌지만 현재 점점 가격차이가 줄어드는 추세여서 L7을 주로 사용한다.
한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드 밸런서 이상을 사용해야만 한다.
L7 로드 밸런서는 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. 패킷의 내용을 확인해서 그 내용에 따라 트래픽을 특정 서버에 전송하는 것이 가능한 것이다. URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있다. 또, L7 로드밸런서는 서버의 응답까지도 알고 분석할 수 있다. 서버들로부터 필요한 정보를 응답 받아 클라의 요청을 전달하기 전에 서버의 상태를 파악한 후 로드밸런싱을 진행할 수 있다.
로드밸런싱 종류와 방법
L4 Load Balancing
L4 Load Balancer는 L4계층에서 동작하는 Load Balancer이므로 네트워크 계층이나 트랜스포트 계층의 정보를 바탕으로 로드를 분산한다. 즉, IP주소나 포트번호, MAC주소, 전송 프로토콜 등에 따라 트래픽을 나누고 분산처리 하는 것이 가능하다. 이런 이유로 L4 Load Balancer를 CLB(Connection Load Balancer) 혹은 SLB(Session Load Balancer)라고 부르기도 한다.
L4 Load Balancing 방법
라운드 로빈(Round Robin)기반 : 세션을 각 서버에 순차적으로 맺어주는 방식이다.
단순히 순서에 따라 세션을 할당하기 때문에 경웨 따라 경로별로 같은 처리량이 보장되지 않는다.
가중치 및 비율 할당 방식 : 서버마다 비율을 설저앻두고 해당 비율 만큼 세션을 맺어주는 방식이다.
특정 서버의 성능이 월등히 뛰어나다면 해당 서버로 세션을 많이 맺어주도록 가중치를 설정하고 나머지 로우급의 서버들은 적은 세션이 맺어질 수 있도록 가중치를 설정한다.
최소 연결(Least Connection)기반 : 가장 적은 세션을 가진 서버로 트래픽을 보내는 방식이다.
가장 많이 사용되는 방식
응답 시간(Response Time)기반 : 가장 빠른 응답 시간을 보내는 서버로 트래픽을 우선 보내주는 방식이다.
각 서버들의 가용 가능한 리소스와 성능, 처리중인 데이터 양이 다를 경우 적합한 방식이다.
해시(Hash)기반 : 특정 클라이언트는 특정 서버로만 할당시키는 방식이다.
특정 IP주소 또는 Port의 클라이언트들은 특정 서버로만 세션이 맺어지도록 한다. 경로가 보장되며 접속자 수가 많을수록 분산 및 효율이 뛰어나다.
대역폭(Bandwidth)기반 : 서버들과의 대역폭을 고려하여 트래픽을 분산시키는 방법이다.
L7 Load Balancing
L7 Load Balancer는 위와 같은 L4 Load Balancer의 기능을 포함하는 것 뿐만 아니라 OSI 7계층의 프로토콜을 바탕으로도 분산 처리가 가능하다.
L7 Load Balancing 방법
URL Switching : 특정 하위 URL들은 특정 서버로 처리하는 방식이다.
예를 들어 ‘…/limjunho/test1’ 또는 ‘…/limjunho/test2’와 같은 특정 URL을 가진 주소들은 서버가 아닌 별도의 스토리지에 있는 객체 데이터로 바로 연결되도록 구성할 수 있다.
Context Switching : 클라이언트가 요청한 특정 리소스에 대해 특정 서버 등으로 연결을 해줄 수 있다.
예를 들어 이미지 파일에 대해서는 확장자를 참조하여 별도로 구성된 이미지 파일이 있는 서버/스토리지로 직접 연결해줄 수 있다.
쿠키 지속성(Persistence with Cookies) : 쿠키 정보를 바탕으로 클라이언트가 연결 했었던 동일한 서버에 계속 할당해주는 방식이다.
특히 사설 네트워크에 있던 클라리언트의 IP주소가 공인 IP주소로 치환되어 전송(X-Forwarded-For Header에 클라이언트 IP주소를 별도 기록)하는 방식을 지원한다.
장점
로드밸런싱을 이용하면 한 서버가 다운되더라도 이중화시킨 다른 서버에서 서비스를 지속하여, 사용자들이 문제를 인지하지 못하게 할 수 있다.
단지 노드를 추가하는 것만으로 서비스가 확장성을 가질 수 있다.
단점
로드밸런서를 사용할 때 어려운 문제 중 하나는 세션 데이터를 관리하는 것이다.
클라이언트의 연결 정보를 저장하는 세션이 로드밸런싱을 통해 하나의 서버 장비에 저장이 되는 경우, 추후 다른 서버로 접속하게 되면, 해당 클라이언트의 세션이 유지되지 않는다는 것이다. 즉, 서버에 액세스 할 때마다 다른 세션을 사용한다면 특정 사용자의 정보를 일관성있게 유지할 수 없게 된다.
이러한 문제를 해결하기 위해 세션을 고정(session sticky)한다. 하지만 고정된 세션의 노드에 장애가 발생하면 고정한 의미가 없어진다.
L4/L7 Load Balancer의 성능 지표
초당 연결 수(Connections per second)
최대 처리 가능한 초당 TCP 세션의 개수를 의미
동시 연결 수(Concurrent connections)
동시에 최대로 세션을 유지할 수 있는 개수를 의미
처리용량(Throughput)
UDP Protocol에 대한 Load Balancing 성능 지표이며 단위는 bps(bit per second) 또는 pps(packet per second)를 사용
클러스터링(Clustering)
Clustering이란 여러 대의 컴퓨터를 똑같은 구성의 서버군을 병렬로 연결한 시스템으로 마치 하나의 컴퓨터처럼 사용하는 것을 말한다.
Clustering 환경에서는 특정 장비에 문제가 생기거나 애플리케이션에 문제가 생기더라도, 전체적인 서비스에는 영향을 주지 않게 제어할 수 있다.
Clustering은 Virtual IP(가상 IP) 기반으로 구현되는데, 서비스를 제공하는 실제 장비는 Physical IP를 가지고, 데이터의 처리는 Virtual IP를 통해 처리한다. 이렇게 내부의 시스템은 철저하게 가려 추상화하는 것이 원칙이다.
로드밸런서에 의해 각 Clustering된 서버에 의해 서비스가 진행이 된다.
정리
Load Balancing은 L4 or L7이 여러대의 서버에 패킷을 부하분산시켜주는 것이고 Clustering은 여러대의 서버를 하나의 서버로 만들어 주는 것이다.
Load Balancing - 여러대의 서버에 패킷을 분산
Clustering - 서비스를 제공하는 여러개의 서버를 하나로 묶어 성능을 높여 많은양의 패킷을 처리하는 것
로드 밸런싱 방법
로드 밸런싱은 네트워크 트래픽을 여러 서버에 분산시키는 기술로, 트래픽 부하를 균등하게 나누어 서버의 과부하를 방지하고, 고가용성을 제공합니다. 로드 밸런싱 방법은 다음과 같습니다.
- 라운드 로빈 (Round Robin): 순서대로 각 서버에 요청을 배분합니다.
라운드 로빈 방식
라운드 로빈(Round Robin Method)은 클라이언트로부터 받은 요청을 로드밸런싱 대상 서버에 순서대로 할당받는 방식입니다. 첫 번째 요청은 첫 번째 서버, 두 번째 요청은 두 번째 서버, 세 번째 요청은 세 번째 서버에 할당합니다. 로드밸러닝 대상 서버의 성능이 동일하고 처리 시간이 짧은 애플리케이션의 경우, 균등하게 분산이 이루어지기 때문에 이 방식을 사용합니다.
가중 라운드 로빈 방식
가중 라운드 로빈 방식(Weighted Round Robin Method)은 실제 서버에 서로 다른 처리 용량을 지정할 수 있습니다. 각 서버에 가중치를 부여할 수 있으며, 여기서 지정한 정숫값을 통해 처리 용량을 정합니다.
최소 연결 방식
최소 연결 방식은 연결 수가 가장 적은 서버에 네트워크 연결방향을 정합니다. 동적인 분산 알고리즘으로 각 서버에 대한 현재 연결 수를 동적으로 카운트할 수 있고, 동적으로 변하는 요청에 대한 부하를 분산시킬 수 있습니다.
- 최소 연결 (Least Connections): 현재 연결이 가장 적은 서버에 요청을 배분합니다.
- IP 해시 (IP Hash): 사용자의 IP 주소를 해싱하여 특정 서버에 요청을 배분합니다.
로드 밸런싱 방법
1⃣ DNS Load Balancing
• DNS 서버에서 여러 IP를 반환하여 트래픽을 나누는 방식
• 단점: 클라이언트 캐싱 문제로 인해 부하가 완벽히 분산되지 않을 수 있음
2⃣ Reverse Proxy Load Balancing
• Nginx, HAProxy 등을 이용하여 프록시 서버가 클라이언트 요청을 적절한 서버로 라우팅
• 대표적인 로드 밸런서 : Nginx, HAProxy, Traefik
3⃣ L4 (Layer 4) Load Balancing
• TCP/UDP 레벨에서 부하를 분산 (IP 및 포트 기반)
• 대표적인 서비스 : AWS ELB (Elastic Load Balancer), F5 Big-IP
4⃣ L7 (Layer 7) Load Balancing
• HTTP(S) 요청의 URL, 쿠키, 헤더 등을 기반으로 부하 분산
• REST API 서버나 NestJS 같은 웹 서버에서는 L7 방식이 일반적
• 대표적인 서비스 : Nginx, HAProxy, AWS ALB (Application Load Balancer)
NestJS에서 로드 밸런싱 적용하기
NestJS에서 로드 밸런싱을 적용하려면 여러 가지 방법이 있다.
1⃣ Nginx Reverse Proxy 사용
가장 일반적인 방법은 Nginx를 Reverse Proxy로 사용하여 트래픽을 여러 인스턴스로 분산하는 것이다.
📌 설정 방법
1. NestJS 서버를 여러 개 실행 (PORT 3000, PORT 3001, PORT 3002 등)
2. Nginx를 설정하여 여러 서버로 트래픽을 분배
🔹 Nginx 설정 예시 (/etc/nginx/nginx.conf)
nginx 파일
http {
upstream nest_servers {
server 127.0.0.1:3000;
server 127.0.0.1:3001;
server 127.0.0.1:3002;
}
server {
listen 80;
location / {
proxy_pass http://nest_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
🚀 이렇게 하면, 클라이언트의 요청이 3000, 3001, 3002 포트로 자동 분산됨!
2⃣ 클라우드 로드 밸런서 사용 (AWS ELB, GCP, Azure)
• AWS ALB (Application Load Balancer)
• AWS NLB (Network Load Balancer)
• GCP Load Balancer
• Azure Load Balancer
👉 NestJS 서버를 여러 대 띄우고, 로드 밸런서를 앞에 두면 자동으로 트래픽을 분배함
3⃣ PM2 Cluster 모드 활용 (싱글 머신 내 멀티 프로세스)
단일 서버에서 멀티 프로세스로 NestJS를 실행하여 부하 분산하는 방법이다.
📌 PM2를 사용한 NestJS 클러스터링
sh 파일
npm install pm2 -g
pm2 start dist/main.js -i max
• -i max : 가능한 모든 CPU 코어를 사용하여 여러 개의 NestJS 프로세스를 실행
• 하나의 서버에서 여러 개의 NestJS 인스턴스를 띄워 트래픽을 나눌 수 있음
📌 결론: NestJS에서 로드 밸런싱 적용 방법 추천
1. 트래픽이 많다면? → Nginx Reverse Proxy + 여러 NestJS 인스턴스
2. 클라우드 환경(AWS, GCP)에서 운영? → 로드 밸런서(AWS ALB, GCP LB) 사용
3. 단일 서버에서 성능 최적화? → PM2 클러스터 모드 사용
aws의 로드 밸런서 유형 정리
1. Application Load Balancer (ALB)
• 특징: HTTP 및 HTTPS 트래픽을 처리하는 애플리케이션에 적합 (API 서버)
• 작동 방식: 요청(Request) 수준에서 작동
• 적용 대상:
• 마이크로서비스
• 컨테이너 기반 애플리케이션
• 고급 라우팅 기능 필요 시
• 다이어그램: (Application Load Balancer 구조 포함)
• 생성 가능
2. Network Load Balancer (NLB)
• 특징: 초고성능, 저지연 네트워크 트래픽 처리에 적합(WebSocket 서버)
• 작동 방식: 연결(Connection) 수준에서 작동
• 적용 대상:
• 초당 수백만 개의 요청 처리
• 대규모 TLS 오프로딩
• 중앙 집중화된 인증서 배포
• UDP 트래픽 지원
• 고정 IP 주소가 필요한 서비스
• 다이어그램: (Network Load Balancer 구조 포함)
• 생성 가능
3. Gateway Load Balancer (GLB)
• 특징: 서드파티 가상 어플라이언스 관리에 적합
• 작동 방식: GENEVE 프로토콜 지원
• 적용 대상:
• 보안 및 규정 준수 강화를 위한 네트워크 어플라이언스
• 정책 기반 트래픽 제어
• 다이어그램: (Gateway Load Balancer 구조 포함)
• 생성 가능
__________________________________________________
인스턴스가 2개 이상.
지웅님이랑 조율해야함(crcd맡음 - 다 업데이트 해줘야함)
로드 벨러싱은 오토 스케일링 적용해야함
오토 스케일링 : 트레픽이 많으면 Ec2를(서버를) 자동으로 늘려서 리퀘스트 자동 분배해줌(인스턴스가 늘어남). aws에도 있음
트래픽이 증가하면 EC2(서버) 인스턴스를 자동으로 확장하여 요청을 분배하는 기능이다.
트래픽이 줄어들면 불필요한 인스턴스를 줄여 비용을 절감할 수 있다.
AWS에도 오토 스케일링 기능이 있으며, 이를 활용하면 서버 운영을 자동화할 수 있다.
_____________________________________
Sticky Session
https://kchanguk.tistory.com/146
각 WAS들은 세션을 각각 가지고 있지만, 이를 하나로 묶어 하나의 클러스터로 관리하는 방법이 있습니다. 이 상태에서 하나의 WAS가 fail이 발생하면 해당 WAS가 들고 있던 세션은 다른 WAS로 이동되어 관리됩니다. 다만, 각 서버마다 세션 클러스터링 방식이 다르고 지원하는 방식이 다르기 때문에 현재 사용하고 있는 WAS의 session clusturing 부분을 보고 확인해야 합니다. 그리고 이 방식은 새로운 서버가 하나 추가될 때마다 기존에 존재하던 WAS에 새로운 서버의 IP/PORT를 입력해서 클러스터링 해줘야 하는 단점이 있습니다.
👥 사용자가 늘어나면?
서비스를 운영할 때 서버는 몇대나 있어야할까요?사용자가 많이 없는 경우에는 1대의 서버만으로도 요청을 처리할 수 있지만 사용자가 늘어나면 늘어날수록 요청을 깔끔하게 처리하기 어려워지며 서버가 터지는 상황까지 발생할 수 있습니다..!
이럴 때에는 스케일 아웃혹은 스케일 업을 통해 인프라를 확장할 필요가 있습니다!
스케일업 (scale-up)
스케일업은 현재 사용 중인 서버의 성능을 향상시키는 것입니다. 예를 들어 서버에 디스크를 추가하거나 CPU나 메모리를 추가하는 것을 의미하죠!(수직 스케일링 - vertical scaling 이라고도 부릅니다)
스케일아웃 (scale-out)
스케일아웃은 현재 사용 중인 서버의 개수를 증가시키는 것입니다. 서버의 성능은 그대로 가져가고 요청을 처리할 수 있는 서버의 수를 증가시키는 방법입니다.(수평 스케일링 - horizontal scaling 이라고도 부릅니다)
🔀 로드밸런서
로드밸런서란?
로드 밸런서는 스케일아웃을 수행하는 방법 중 하나입니다.
로드밸런서의 주요 역할
(1) 요청 분산
인터넷으로부터 들어온 요청을 여러 웹 서버에 균등하게 분산시켜 줍니다. 앞에서 말한 스케일 아웃 기능이죠!!
(2) SSL 처리
로드 밸런서를 사용하면 송수신하는 데이터를 암호화하는 SSL 처리가 가능합니다.
인터넷으로부터의 접근 중 안전하게 정보를 보내기 위해 HTTPS라는 프로토콜로 통신을 할 때가 있는데 이 통신에서 SSL을 사용하게 됩니다. https 를 사용하면 브라우저와 서비스 사이를 흐르는 데이터는 암호화되며 이때 암호 관련 처리를 빠르게 수행하는 전용 시스템을 로드밸런서가 제공해주어 웹 서버에서 암호를 처리하는 것보다 빠른 속도로 처리할 수 있어요!
(3) 부정 요청 대응
로드 밸런서 없이 웹 서버가 직접 브라우저와 데이터를 교환하는 상태라면? 예상치 못한 작동을 일으키는 부정한 요청에 대한 처리는 웹 서버에 과부화를 일으킬 수 있으며 그로 인해 웹 서버 자체가 다운될 가능성이 있습니다.
로드 밸런서는 이러한 부정 접근에 대응하는 전용 시스템을 제공하여 더 효율적으로 부정한 접근에 대응할 수 있습니다.
AWS에서 제공하는 로드 밸런서 종류
AWS에서는 ELB(Elastic Load Balancing)이라는 서비스로 로드 밸런서를 제공합니다.
(1) Application Load Balancer (ALB)
ALB는 HTTP나 HTTPS 를 이용한 접근을 분산하는데 최적화된 로드 밸런서 입니다. SSL 처리를 수행하거나 URL 패턴과 같은 복잡한 조건에서 분산 대상자를 바꾸는 등 고도의 기능을 제공합니다.
(2) Network Load Balancer
기본적인 분산처리 기능만을 제공하지만 다양한 통신 프로토콜에 대응하는 로드 밸런서입니다.
(3) Classic Load Balancer
앞선 두개의 로드 밸런서가 등장하기 전에 쓰이던 로드 밸런서이며 기존 AWS 시스템을 사용해야 하는 특별한 경우를 제외하고는 거의 사용되지 않습니다.
요청 라우팅
로드 밸런서를 사용할 때에는 외부에 공개한 프로토콜과 포트 번호의 조합을 내부의 웹 서버가 받는 프로토콜과 포트 번호로 변환하는 기능을 제공하는데, 이를 요청 라우팅(request routing) 이라고 합니다.
예를 들어 HTTPS 80 포트로 외부 요청을 받고 내부 웹 서버에 전달할 때에는 HTTP 8080 으로 변환하여 전달할 수 있도록 설정해주는 것이죠!(HTTPS를 HTTP로 변환하는 이유는 HTTPS를 이용한 암호 및 복호 처리는 웹 서버가 아니라 로드 밸런서가 수행하기 때문입니다.)
🎃 AWS에서 ALB 생성하기
가용 영역 설정
요청을 분산할 가용 영역을 선택하고 가용 영역에 생성한 Public Subnet을 선택해 줍니다! (반드시 public subnet에 연결해주어야 합니다!!!)
보안 그룹 설정
보안 그룹은 vpc의 default 보안 그룹과 http/https 접근을 받을 수 있는 보안 그룹을 설정해 줍니다.
대상 그룹 생성
로드 밸런서를 적용할 대상 그룹을 만들어봅시다!여기서 포트를 설정해줍니다. 이미지와 같이 설정해준다면 로드밸런서를 통해 들어온 요청은 웹 서버의 8080 포트로 들어가게 됩니다.
상태 검사를 할 경로를 작성해 줍니다. 로드 밸런서는 해당 URL로 요청을 보내 웹 서버의 상태를 주기적으로 검사합니다.
실제로 트래픽을 분산할 인스턴스들을 선택하여 로드 밸런서의 대상으로 등록해줍니다!
리스너 및 라우팅
앞서 생성한 대상 그룹을 '리스너 및 라우팅' 메뉴에서 설정해 줍니다. 이렇게 설정해주면 HTTP 80 포트로 들어온 요청은 설정한 대상 그룹으로 분산되게 됩니다!
이렇게 하면 ALB를 생성할 수 있으며 생성한 로드 밸런서의 DNS 이름으로 접근이 가능합니다!
참고https://aws.amazon.com/ko/what-is/load-balancing/ https://tecoble.techcourse.co.kr/post/2021-10-12-scale-up-scale-out/
___________________________
참고
https://chunsubyeong.tistory.com/106
https://kchanguk.tistory.com/146
https://sjh9708.tistory.com/98
https://dev.classmethod.jp/articles/load-balancing-types-and-algorithm/
대용량 트레픽 처리방법
https://hs-backend.tistory.com/228
nestjs 적용
https://andongmin.com/docs/nest/ch9/ch9-3
https://guti-coding.tistory.com/197?category=1195671
aws 설정
https://velog.io/@chaerim1001/AWS%EB%A1%9C-%EC%8B%9C%EC%9E%91%ED%95%98%EB%8A%94-%EC%9D%B8%ED%94%84%EB%9D%BC-%EA%B5%AC%EC%B6%95%EC%9D%98-%EC%A0%95%EC%84%9D-Ch07.-%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C-%EC%A4%80%EB%B9%84%ED%95%98%EA%B8%B0
'내일배움 정리 > TIP' 카테고리의 다른 글
| mysql 비번 바꾸기(cmd창) (0) | 2025.01.23 |
|---|---|
| 로케일 코드 (Locale code) - 특정 언어 및 지역을 나타내는 표준 (0) | 2025.01.11 |
| 브라우저(크롬)에서 토큰 확인하기 (0) | 2024.12.29 |
| INSOMNIA 내보내기 (0) | 2024.12.26 |
| 설명하는 글에 종종 보이는 줄인말 뜻 (0) | 2024.12.23 |
