본 글은 로드 밸런싱에 대해 알아보자, 로드 밸런싱이란?, Spring Cloud Ribbon - 개념과 실습편, Ribbon을 사용해보자, spring cloud loadbalancer 설정 및 테스트 소스, L4 로드밸런서 vs L7 로드밸런서, Spring Cloud LoadBalancer를 참고했습니다.
도움이 되어주셔서 감사합니다 🐳
1. 로드밸런싱이란?
매우 많은 트래픽이 발생하고 있는 상황에서, 아무리 성능이 뛰어난 서버라고 하더라도 서버 단 한대만으로는 그 모든 트래픽을 감당할 수 없습니다.
따라서 기업들은 서버를 추가로 구비하여 여러 대의 서버에 동일한 데이터를 저장해 수많은 트래픽을 효과적으로 분산하여 처리하는 기법을 채택하고 있습니다.
이를 위해서는 쏟아지는 트래픽을 여러 대의 서버로 분산 시켜주는 기술이 필요합니다.
이것이 바로 로드 밸런싱인 것입니다.
서버에 가해지는 부하(로드)를 분산(밸런싱) 해주는 기술인 로드 밸런싱은 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해서 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것을 목표로 합니다.
2. 기법
Load Balancer가 분산할 서버를 선택하는 기법은 아래와 같습니다.
서버의 능력을 고려하여 분배해야하므로, 서버의 상황에 맞춰 적절한 방법을 선택해야 합니다.
(1) Round Robin 방식
: 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식입니다.
: 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결이 오래 지속 되지 않는 경우에 적합합니다.
(2) Weighted Round Robin 방식
: 가중 라운드 로빈 방식입니다.
: 각 서버마다 가중치를 매기고, 가중치가 높은 서버에 우선적으로 요청을 배분합니다.
: 이는 각 서버의 스펙이 상이한 경우 주로 사용하는 방식입니다.
(3) IP Hash 방식
: 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식입니다.
: 이는 사용자가 항상 동일한 서버로 연결되는 것을 보장한다는 특징을 갖고 있습니다.
(4) Least Connection 방식
: 최소 연결 방식입니다.
: 요청이 들어온 시점에, 연결 개수가 가장 적은 서버를 선택하여 트래픽을 배분합니다.
: 서버와의 연결(세션)이 길어지는 경우 권장되는 방식입니다.
(5) Least Response Time 방식
: 서버의 현재 연결 상태와 응답 시간을 모두 고려하여 트래픽을 분산하는 방식입니다.
: 가장 적은 연결 상태 + 가장 짧은 응답 시간을 보이는 서버에 우선적으로 로드를 배분합니다.
3. 종류
L2 ~ L7과 같은 종류의 로드밸런싱이 존재하지만, L4와 L7이 가장 많이 사용됩니다.
로드밸런서의 종류를 나누는 기준은 OSI 7계층을 기준으로 어떻게 부하를 분산하는지입니다. 상위 계층으로 갈수록 섬세한 부하 분산이 가능해지지만, 가격이 비싸집니다.
(1) L4 로드밸런싱
네트워크 계층 (4계층, IP, IPX) 이나 전송 계층 (3계층, TCP, UDP)의 정보를 바탕으로 로드를 분산합니다. 즉, IP 주소, Port 번호, MAC 주소, 전송 프로토콜 등에 따라 트래픽을 분산하는 것입니다.
장점
- 패킷의 안을 들여다보지 않고 로드를 분산하기 때문에 속도가 빠르고, 효율이 높습니다.
- 데이터의 내용을 복호화할 필요가 없으므로 안전합니다.
- L7보다 저렴합니다.
단점
- 패킷의 내용을 보지 못하므로 섬세한 라우팅이 불가능합니다.
- 사용자의 IP가 수시로 바뀌는 경우면 연속적인 서비스 제공이 어려워집니다.
(2) L7 로드밸런싱
어플리케이션 계층 (7계층, HTTP, FTP, SMTP 등)에서 로드를 분산하므로 HTTP헤더, 쿠키 등과 같은 사용자 요청을 기준으로 특정 서버에 트래픽을 분산합니다.
L4 로드밸런서의 기능에 더하여, 패킷의 내용을 확인하고 내용에 따라 load를 특정 서버에 분배할 수 있습니다. 특정한 패턴을 지닌 바이러스를 감지해서 네트워크를 보호할 수 있고 비정상적인 트래픽 필터링도 가능합니다.
방식
- URL 스위칭 = 특정 하위 URL들은 특정 서버로 처리하는 방식입니다.
- Context Switching 방식 = 클라이언트가 요청한 특정 리소스에 대해 특정 서버로 연결하는 방식입니다.
(이미지 파일에 대해서는 확장자를 참조하여 별도로 구성된 이미지 파일이 있는 서버로 직접 연결) - 쿠키 지속성 : 쿠키 정보를 바탕으로 클라이언트가 연결했었던 동일한 서버에 계속 할당해주는 방식입니다. 특히 사설 네트워크에 있던 클라이언트이 IP 주소가 공인 IP주소로 치환되어 전송하는 방식을 지원합니다.
장점
- 더 섬세한 라우팅이 가능합니다.
- 캐싱 기능을 제공합니다.
- 비정상적인 트래픽을 사전에 필터링할 수 있으므로 서비스 안정성이 높습니다.
단점
- 가격이 비쌉니다.
- 패킷의 내용을 복호화해야하므로 더 높은 비용이 듭니다.
- 클라이언트가 로드밸런서와 인증성를 공유해야하므로, 공격자가 로드밸런서를 통해 클라이언트의 데이터에 접근할 수 있는 보안상의 위험성이 존재합니다.
정보를 조사한 후, 실제 로드밸런싱을 적용한 예제 프로젝트를 찾아보고 싶어 여러 곳에 검색을 하다가 Spring Boot Ribbon에 대해 알게 되었습니다.
해당 개념을 설명하기 위해선 다른 관점에서의 로드밸런싱에 대한 설명이 필요합니다.
4. 서버사이드 ? 클라이언트사이드?
L4, L7 계층에서 Switch라는 비싼 HW 장비를 두는, 위에서 설명한 방식을 서버 사이드 로드 밸런싱이라 칭합니다.
이러한 방식은 서버를 증설하기만 하면 되므로 간단히 조치할 수 있지만
별도의 스위칭 장비가 필수적이고, 비용이 비싸고 설치 및 세팅이 복잡하다는 단점을 갖고 있습니다. 그리고 서버 목록의 추가가 보통 수동으로 이뤄지기 때문에 유연성이 떨어집니다.
따라서 이러한 단점을 보완하고자 등장한 것이 바로 클라이언트 사이드 로드 밸런서 입니다.
즉, 스위치를 클라이언트로 옮기면서 서비스를 직접 선택하도록 SW로 구성하는 것입니다.
5. Spring Ribbon
MSA 구성을 지원하는 Spring Boot 기반 프레임워크인 Spring Cloud에서는 클라이언트 사이드 로드밸런서로 Ribbon을 채택합니다.
Ribbon은 아래와 같은 기능을 제공합니다.
- SW로만 로드 밸런싱이 가능
- 서버 목록의 동적 변경
- 로드밸런싱 설정 자유롭게 구성 가능
- Retry 기능이 내장
구성 요소
(1) Server list
: 로드 밸런싱 대상 서버 목록 입니다.
: Configuration을 통해 static하게 설정할 수도 있고, Eureka 등을 기반으로 dynamic하게 설정할 수도 있습니다.
참조 블로그 클라우드 호나경의 다수 서비스들의 로드 밸런싱 및 장애 조치 목적을 가진 미들웨어 서버
(2) Rule
: 요청을 보낼 서버를 선택하는 논리입니다.
: 위의 기법과 비슷한 의미를 갖습니다.
: Round Robbin(순서대로 돌아가면서), Available Filtering(에러가 많은 서버 제외), Weighted Response Time 의 기법이 있습니다.
(3) Ping
: 서버 List가 모두 살아있는지 체크하는 논리입니다.
6. Spring LoadBalancer
Ribbon과 비슷하지만 차별점이 존재하는 Spring Cloud LoadBalancer를 마지막으로 설명드리겠습니다.
SCL도 Ribbon과 동일하게 Client-side Load Balancer입니다.
하지만 Ribbon은 RestTemplate만 지원하고 SCL은 Spring WebClient도 지원한다는 점에서 차이가 있습니다.
그리고 Ribbon은 위에서 설명드린 세 가지 기법이자 정책을 제공하지만, SCL은 Round Robbin 정책과 Random 정책만 지원합니다.
다음에는 실습으로 적용해보는 것도 정리해봐야할 것 같습니다 :)
