TIP

대용량 트레픽 처리 - 로드 밸런싱 개념 정리

GREEN나무 2025. 2. 5. 17:46

728x90

🚀 사용자가 늘어나면, 서버는 어떻게 확장할까?

서비스 운영 중 서버는 몇 대가 필요할까?
✅ 사용자가 적다면 1대의 서버로도 충분하지만,
✅ 사용자가 증가하면 서버의 부하가 커지고, 심하면 서버가 다운될 수도 있다.

이럴 때 "스케일 업(Scale-Up)" 또는 "스케일 아웃(Scale-Out)"을 통해 서버를 확장해야 한다.

🏗️ 서버 확장 방법

1️⃣ 스케일 업 (Scale-Up)

✔ 현재 서버의 성능을 업그레이드하는 방법
✔ CPU, 메모리, 디스크 추가하여 처리 능력 향상
✔ (수직 확장, Vertical Scaling)

2️⃣ 스케일 아웃 (Scale-Out)

✔ 서버 개수를 늘려 부하를 분산하는 방법
✔ 여러 대의 서버가 동일한 요청을 처리
✔ (수평 확장, Horizontal Scaling)

💡 스케일 아웃 시 "로드 밸런서(Load Balancer)"가 필요

🔀 로드 밸런서(Load Balancer)란?

로드 밸런싱 : 트래픽을 여러 서버로 분산하여 서버의 부하를 줄이고 안정성을 높이는기술.

로드 밸런서 : 로드 밸런싱을 수행하는 하드웨어 또는 소프트웨어 장비.

✅ 로드 밸런싱(Load Balancing) 주요 역할

1️⃣ 요청 분산

사용자 요청을 여러 서버로 분산 →

✔ 부하 분산 : 특정 서버 과부하 방지

✔ 확장성 : 성능 및 속도 최적화

2️⃣ 헬스 체크 (Health Check)

로드 밸런서는 백엔드 서버의 상태를 주기적으로 확인하는 헬스 체크를 수행함.
✔ 정상적인 응답이 없으면 해당 서버 제외
✔ 장애 감지 시 다른 서버로 트래픽 전환

3️⃣ SSL 처리

✔ HTTPS를 통해 암호화된 데이터 송수신 가능

✔ 로드 밸런서가 암호화 처리 → 웹 서버 부담 감소

4️⃣ 부정 요청 대응

✔ 부정 요청(DoS, DDoS 공격 등) 차단

✔ 웹 서버가 아닌 로드 밸런서에서 먼저 필터링

🔹로드 밸런서 유형

✅로드 밸런서는 'OSI 7 Layer를 기준으로 부하를 어떻게 분산할지'에 따라 종류가 나뉜다.
2, 3계층을 기준으로 부하를 분산하면 각 L2, L3인 방식이다.

상위 계층은 하위 계층의 데이터를 모두 가지기 때문에, 상위 계층일수록 섬세한 로드 밸런싱이 가능하고 하위 계층일수록 간단한 로드 밸런싱만 가능하다.

✅ 주로 사용되는 로드 밸런서 : L4 vs L7 로드 밸런서

기준	L4 (Transport Layer)	L7 (Application Layer)
속도	빠름	상대적으로 느림
트래픽 분산 기준	IP, 포트, 프로토콜	URL, 쿠키, 헤더, 요청 내용
세부 트래픽 제어	불가능	가능
주요 활용	TCP/UDP 서비스, 게임 서버	API, 마이크로서비스, 웹 서비스

현재 L7 로드 밸런서(ALB 등)를 선호하는 추세. 세션 유지, 정교한 트래픽 제어가 필요한 서비스에 적합

✅ L4 로드 밸런서는 빠르고 단순한 분산을 수행하고, L7 로드 밸런서는 HTTP 요청을 세밀하게 분석하여 트래픽을 최적화한다.
✅ 트래픽 패턴과 서비스 요구사항에 따라 L4 또는 L7 로드 밸런서를 선택하여 사용하면 된다.

L4 로드 밸런싱 방법

L4 Load Balancer = CLB(Connection Load Balancer), SLB(Session Load Balancer)

네트워크 계층이나 트랜스포트 계층의 정보를 바탕으로 로드를 분산한다.

즉, IP주소나 포트번호, MAC주소, 전송 프로토콜 등에 따라 트래픽을 나누고 분산처리 수행.

라운드 로빈(Round Robin)
- 서버에 순차적으로 트래픽을 분배
- 균등 배분이 가능하지만 서버 성능은 고려하지 않음
가중치 기반(Weighted Round Robin)
- 성능이 높은 서버에 더 많은 요청을 배정
최소 연결(Least Connection)
- 현재 연결 수가 가장 적은 서버로 트래픽을 전달
- 실시간 부하를 고려할 수 있어 효율적
응답 시간 기반(Response Time)
- 응답 시간이 빠른 서버에 우선적으로 트래픽을 전달
해시(Hash) 기반
- 특정 클라이언트(IP 등)는 특정 서버에만 연결
대역폭(Bandwidth) 기반
- 서버의 네트워크 대역폭을 고려하여 트래픽 분산

L7 로드 밸런싱 방법

L4 Load Balancer의 기능을 포함하며 OSI 7계층의 프로토콜을 바탕으로도 분산 처리가 가능하다.
HTTP 헤더, 쿠키 등 사용자의 요청을 분석해 정교한 분산 가능

URL Switching
- 특정 URL 패턴에 따라 다른 서버로 연결
- 예) /images/* 요청은 이미지 서버로 전달
Context Switching
- 요청된 리소스 유형에 따라 서버를 다르게 연결
- 예) .jpg, .png 요청은 미디어 서버로 전달
쿠키 기반 지속성(Persistence with Cookies)
- 클라이언트가 이전에 연결했던 서버로 지속적으로 연결

로드 밸런서 장점 & 단점

✅ 장점

✔ 서버 다운 시 자동으로 다른 서버로 요청을 전달하여 안정성 확보
✔ 트래픽을 효율적으로 분산해 성능 향상
✔ 확장성(Scale-out) 용이

❌ 단점

✖ 세션 관리 문제 (Sticky Session 필요)

로드밸런서를 사용할 때 어려운 문제 중 하나는 세션 데이터를 관리하는 것이다.
클라이언트의 연결 정보를 저장하는 세션이 로드밸런싱을 통해 하나의 서버 장비에 저장이 되는 경우, 추후 다른 서버로 접속하게 되면, 해당 클라이언트의 세션이 유지되지 않는다. 즉, 서버에 액세스 할 때마다 다른 세션을 사용한다면 특정 사용자의 정보를 일관성있게 유지할 수 없게 된다.
이러한 문제를 해결하기 위해 세션을 고정(session sticky)한다. 하지만 고정된 세션의 노드에 장애가 발생하면 고정한 의미가 없어진다.

✖ 로드 밸런서 자체가 단일 장애점(SPOF, Single Point of Failure)이 될 수 있음
✖ 높은 성능을 원할 경우 비용 증가

L4/L7 로드 밸런서의 성능 지표

초당 연결 수 (CPS: Connections per Second)
- 초당 처리 가능한 TCP 연결 수
동시 연결 수 (Concurrent Connections)
- 유지할 수 있는 최대 동시 세션 수
처리 용량 (Throughput)
- 초당 처리 가능한 데이터량 (bps 또는 pps 단위)

🔹 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 시스템과 호환 필요 시

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 구조 포함)
• 생성 가능

🎯 요청 라우팅(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 + 오토 스케일링 적용 시 자동 운영 가능 🚀

참고

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://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

https://jforj.tistory.com/278

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

가비아 도메인으로 인증서 발급

https://rimiyeyo.tistory.com/entry/Route53%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%B4-%EB%8F%84%EB%A9%94%EC%9D%B8%EA%B3%BC-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B3%A0-ACM%EC%9D%B8%EC%A6%9D%EC%84%9C-%EB%A7%8C%EB%93%A4%EC%96%B4%EB%B3%B4%EA%B8%B0

정리중

1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣ 6️⃣ 7️⃣ 8️⃣ 9️⃣ 🔟

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) + 오토 스케일링 적용 시 자동 운영 가능 🚀

_________________________________________________________________________

클러스터링(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 클러스터 모드 사용

__________________________________________________
인스턴스가 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/

저작자표시 (새창열림)