로드 밸런싱
네트워크 또는 서버에 가해지는 부하 트래픽을 분산시켜주는 기술
사용 이유
- 과거에는 한 대의 서버로 클라이언트의 요청을 다 처리하는 방식
- 현대 웹은 상당히 무거운 웹 애플리케이션으로 변화되었고, 클라 수도 기하급수적으로 상승
-> 서버 부하 심각
서버 확장 방법
1. Scale UP
서버 자체의 사양 높이기
- 서버에 디스크 추가하거나 CPU나 RAM 자원 업그레이드
- 서버의 성능을 높이기 대문에 Vertical Scaling 이라고도 부름
장점
- 수평 확장 방식보다 관리 비용이나 운영 이슈 적고, 확장 방식이 간단하다.
단점
- 하드웨어 비용 부담, 업그레이드의 한계 존재
- 서버 한대를 다 사용하므로, 해당 서버 장애시 서비스 장애
2. Scale Out
서버의 갯수를 늘리는 것
- 비슷한 사양의 서버 추가 연결해 트래픽 분산시켜 기존 서버 부하를 줄이는 로드밸런싱 수행
- 서버의 갯수를 늘리기 때문에 Horizontal Scaling이라고도 부름
장점
- 유연한 확장성, 서버 다운시 다른 서버로 서비스 유지 가능
단점
- 병렬 컴퓨팅 환경이므로 관련 아키텍쳐의 높은 이해도 요구
- 여러 서버 사용해 데이터 일관성 깨질 수 있음
- 로드 밸런서 요구
로드 밸런서
- 클라이언트와 서버pool(서버 그룹)사이에서 서버 부하를 분산시키는 하드웨어나 소프트웨어
- 네트워크 트래픽과 클라 요청을 적절히 분산시켜줌
- 정상적으로 운영되는 서버에게만 요청 점송 (서버 장애 감지)
- 서비스 중단 없이 서버 추가 및 제거 가능
L4 스위치(로드밸런서)
-
L4 스위치는 OSI 4계층(전송 계층)에서 동작하며, 패킷의 IP 주소 및 TCP/UDP 포트 정보를 기반으로 트래픽을 분산함.
-
패킷의 포트 및 프로토콜 정보(TCP/UDP)를 분석하여 로드 밸런싱을 수행하지만, 애플리케이션 계층의 데이터를 검사하지 않음.
-
가상 IP(VIP)와 여러 실제 서버(Real Server)를 매핑하는 테이블을 유지하며, 이를 기반으로 트래픽을 특정 서버에 전달함.
-
VIP로 들어오는 요청을 라운드 로빈, 최소 연결, 가중치 기반 등의 부하 분산 알고리즘을 사용해 여러 서버에 분산 처리함.
L7 스위치(로드 밸런서)
-
L7 스위치는 애플리케이션 계층(OSI 7계층)에서 동작하며, HTTP 헤더, URL, 쿠키 등의 정보를 기반으로 트래픽을 분산합니다.
-
HTTP/HTTPS 트래픽을 처리하는 데 최적화되어 있으며, 특정 설정을 통해 다른 프로토콜도 일부 지원할 수 있습니다.
-
서버의 응답 상태를 모니터링하여 장애가 발생한 서버를 감지하고 요청을 다른 정상 서버로 전달하는 기능을 수행할 수 있습니다.
-
페이로드(데이터)를 분석하기 때문에 리소스 소모가 크며, 고부하 환경에서는 성능 저하가 발생할 가능성이 있습니다.
-
일부 보안 기능(웹 방화벽 등)과 결합하면 악성 요청을 필터링하여 보안성을 강화할 수 있습니다.
L4 스위치와 L7 스위치 차이점
L4 스위치의 역할
-
가상 IP(VIP)를 통해 클라이언트 요청을 여러 실제 서버(Real Server)로 분산
-
IP 주소 및 TCP/UDP 포트 기반으로 부하를 분산하며, 애플리케이션 데이터는 분석 안함.
-
즉, 서버 중 어떤 서버에 트래픽을 보낼지 결정하는 것이 L4 스위치의 역할.
L7 스위치의 역할
-
L4 스위치를 거쳐 특정 서버로 분배된 요청을 애플리케이션 계층에서 HTTP 헤더, URL, 쿠키 등의 정보를 분석하여 내부적으로 요청을 최적화.
-
L7 로드 밸런서는 서버로 들어온 요청을 더 정밀한 기준으로 처리.
-
예를 들어,
특정 API 요청은 서버 내 특정 백엔드 서비스로 전달,
사용자의 쿠키 정보를 보고 로그인한 사용자는 특정 서버에 우선적으로 할당 등
즉, L4 스위치는 서버를 선택하는 역할을, L7 스위치는 서버가 요청을 세부적으로 처리할 수 있도록 돕는 역할.
또한 모든 스위치는 기본적으로 자신의 하위 계층 동작까지 전부 지원
로드 밸런싱 알고리즘
1. 라운드 로빈
- 클라이언트의 요청을 여러대의 서버에 순차적으로 분배
→ 들어온 요청을 빠르게 서버로 분산하는 작업에 포커스
→ 모든 서버의 부하 상태를 고려하지 않고 요청을 순차적으로 분배하므로,
서버 간 부하가 균등하지 않을 수 있음
(모든 서버의 스펙이 동일하거나 비슷할 때 사용)
2. 가중(weighted) 라운드 로빈
- 가중치가 높은 서버부터 클라이언트의 요청을 우선적으로 전달하는 방식
보통 가중치는 CPU 성능, 네트워크 대역폭, 서버의 실제 처리량 등을 고려하여 설정할 수 있음.
(특정 서버의 스펙이 더 좋을 경우 가중 라운드 로빈 알고리즘 사용)
예시)
A 서버의 가중치 3
B 서버의 가중치 1
8개의 request 받으면 A서버로 6개 B서버로 2개 보냄
3. IP 해시 (IP Hash)
- 클라이언트의 요청이 클라이언트의 IP 주소에 따라 어떤 서버로 전달될지 결정하는 방식
클라이언트 ip 주소 변경되지 않으면 보통 같은 서버로 처리
-> IP 해싱 방식은 같은 IP를 가진 요청을 동일한 서버로 처리하는 특성이 있지만, 특정 서버에 부하가 집중될 위험 존재
(서버쪽의 세션 클러스터링이 설정안되어있다면 보통 이 알고리즘 사용)
세션 클러스터링
2대 이상의 WAS 또는 서버를 사용할 때, 로드 밸런싱 , 장애 대비 등 세션을 공유하는 것을 의미.
여러대의 WAS를 사용할때의 문제점
- 서버 A에서 로그인해 세션 생성하고 세션 ID 발급후 클라이언트는 쿠키에 저장.
- 이 세션을 통해 요청을 했는데 서버 B로 전달되면 로그인이 풀리는 현상 발생함.
따라서 세션 클러스터링을 사용. → 여러 서버 간에 세션을 공유하는 방식
세션은 사용자 정보 또는, 방문 기록을 was 메모리에 저장해
어떤 서버든 클라이언트, 서버 간 고유한 세션 id에 접근 가능
4. 최소 연결
- 요청 들어왔을 때 가장 적게 연결되어있는 서버로 요청 전송
-> 현재 활성화된 연결 수를 기준으로 요청을 분산하지만, 개별 요청의 처리 시간이 길다면 서버 간 부하가 균형적이지 않을 수 있음."
(서버에 분배된 트래픽이 일정하지 않다면 사용)
5. 최소 응답시간
서버의 연결 수와 응답 시간 모두 고려해 가장 적은 연결 수와 가장 짧은 응답 시간 가지는 서버에 요청 보냄.
-> 실시간으로 서버 응답 시간을 측정해야 하므로, 추가적인 네트워크 오버헤드가 발생할 수 있음
