개념
- 여러 대의 Server에게 균등하게 Traffic을 분산
- 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것이 목적
- 기존의 서버만으로 원활한 서비스 동작이 불가능하게 될때, 대처 방법은 크게 두 가지가 존재.
- 기존의 서버 성능을 확장하는 Scale-up 방식
- 기존의 서버와 동일하거나 낮은 성능의 서버를 증설하는 Scale-out 방식
- 이 때 Scale-out 방식을 통해 증가한 트래픽에 대처하기로 했다면, 여러 대의 서버로 트래픽을 균등하게 분산해주는 로드 밸런싱이 반드시 필요
**로드 밸런싱 기법**
- 라운드로빈 방식(Round Robin Method)
- 서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식
- 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합
- 가중 라운드로빈 방식(Weighted Round Robin Method)
- 각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분
- 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식
- 예를 들어 A라는 서버가 5라는 가중치를 갖고 B라는 서버가 2라는 가중치를 갖는다면, 로드 밸런서는 라운드로빈 방식으로 A 서버에 5개 B 서버에 2개의 요청을 전달한다.
- IP 해시 방식(IP Hash Method)
- 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식
- 사용자의 IP를 해싱해(Hashing, 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수) 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장
- 최소 연결 방식(Least Connection Method)
- 요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 배분
- 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합한 방식
- 최소 응답 시간 방식(Least Response Time Method)
- 서버의 현재 연결 상태와 응답 시간(Response Time, 서버에 요청을 보내고 최초 응답을 받을 때까지 소요되는 시간)을 모두 고려하여 트래픽을 배분
- 가장 적은 연결 상태와 가장 짧은 응답 시간을 보이는 서버에 우선적으로 로드를 배분하는 방식
기본 기능
- Health Check (상태 확인)
- 서버들에 대한 주기적인 Health Check를 통해 서버들의 장애 여부를 판단하여, 정상 동작 중인 서버로만 트래픽을 보내는 기능
- L3 체크 : ICMP를 이용하여 서버의 IP 주소가 통신 가능한 상태인지를 확인
- L4 체크 : TCP는 3 Way-Handshaking (전송 - 확인/전송 - 확인) 를 기반으로 통신하는데, 이러한 TCP의 특성을 바탕으로 각 포트 상태를 체크하는 방식.
- L7 체크 : 어플리케이션 계층에서 체크를 수행. 실제 웹페이지에 통신을 시도하여 이상 유무를 파악.
- Tunneling (터널링)
- 데이터 스트림을 인터넷 상에서 가상의 파이프를 통해 전달시키는 기술로, 패킷 내에 터널링할 대상을 캡슐화시켜 목적지까지 전송. 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제하게 함.
- NAT (Network Address Translation)
- 내부 네트워크에서 사용하는 사설 IP 주소와 로드밸런서 외부의 공인 IP 주소 간의 변환 역할.
- 로드밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP 주소(VLAN or VIP)를 통해 접속하는 것이 주 목적.
- SNAT (Source Network Address Translation) : 내부에서 외부로 트래픽이 나가는 경우. 내부 사설 IP 주소 -> 외부 공인 IP 주소로 변환.
- DNAT (Destination Network Address Translation) : 외부에서 내부로 트래픽이 들어오는 경우.외부 공인 IP 주소 -> 내부 사설 IP 주소로 변환.
- DSR (Destination Network Address Translation)
- 서버에서 클라이언트로 트래픽이 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음, 네트워크 장비나 로드밸런서를 거치지 않고 바로 클라이언트를 찾아가는 방식. 이 기능을 통해 로드밸런서의 부하를 줄여줄 수 있음.
- ICMP : Internet Control Message Protocol. 패킷 전송에 실패했을 때 에러가 났음을 알림과 동시에, 해결 가능한 힌트를 제공하는 메시징 프로토콜. TCP/IP의 IP 계층에서 동작.
종류
-
계층 기반
-
L2(Mac 주소 기반) / L3(IP주소 기반)
-
L4(IP/Port(Transport layer)에서, TCP/UDP)
-
L7(Application layer에서, HTTP,HTTPS,FTP -> 패킷내용까지 보고 분배)
L4 로드밸런서 vs L7 로드밸런서
-
L4 로드 밸런서
-
4 계층 - 네트워크 계층(IP, IPX)이나 3 계층 - 전송 계층(TCP, UDP) 의 정보를 바탕으로 로드를 분산.
-
즉, IP 주소, 포트번호, MAC 주소, 전송 프로토콜 등에 따라 트래픽을 분산하는 것이 가능.
-
장점
- 패킷의 내용을 확인하지 않고 로드를 분산하므로 속도가 빠르고 효율이 높음.
- 데이터의 내용을 복호화할 필요가 없기에 안전.
- L7 로드밸런서보다 가격이 저렴.
-
단점)
- 패킷의 내용을 살펴볼 수 없으므로, 섬세한 라우팅 불가.
- 사용자의 IP가 수시로 바뀌는 경우라면, 연속적인 서비스를 제공하기 어려움.
-
L7 로드 밸런서
-
7 계층 - 어플리케이션 계층(HTTP, FTP, SMTP 등)에서 로드를 분산하기 때문에, HTTP 헤더, 쿠키 등과 같은 사용자 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능.
-
L4 로드밸런서의 기능에 더하여, 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능
-
특정한 패턴을 지닌 바이러스를 감지해 네트워크 보호 가능.
-
Dos/DDos와 같은 비정상적인 트래픽 필터링 가능
-
방식)
- URL 스위칭(URL Switching) 방식 : 특정 하위 URL들은 특정 서버로 처리하는 방식. ex) '.../steven/image' => 이미지 처리 서버 / '.../steven/video' => 동영상 처리 서버
- 컨텍스트 스위칭(Context Switching) 방식 : 클라이언트가 요청한 특정 리소스에 대해 특정 서버로 연결 가능.ex) 이미지 파일에 대해서는 확장자를 참조하여, 별도로 구성된 이미지 파일이 있는 서버 or 스토리지로 직접 연결.
- 쿠키 지속성(Persistence with Cookies) : 클라이언트가 연결했었던 동일한 서버에 계속 할당해 주는 방식. 특히, 사설 네트워크에 있던 클라이언트의 IP 주소가 공인 IP 주소로 치환되어 전송하는 방식을 지원.ex) X-Forwarded-For 헤더에 클라이언트 IP 주소를 별도로 기입장점)
-
장점
- 상위 계층에서 로드를 분산하기 때문에 훨씬 더 섬세한 라우팅 가능.
- 캐싱(Cashing) 기능을 제공.
- 비정상적인 트래픽을 사전에 필터링할 수 있어 서비스 안정성 높음.
-
단점
- L4 로드밸런서에 비해 비쌈.
- 패킷의 내용을 복호화하여야 하므로 더 높은 비용을 지불해야 함.
- 클라이언트가 로드밸런서와 인증서를 공유해야 하기 때문에, 공격자가 로드밸런서를 통해 클라이언트의 데이터에 접근할 수 있는 보안상의 위험성 존재.
-
ELB 종류
- Classic Load Balancer
- 가장 기본적인 형태(현재는 잘 쓰이지 않는 추세)
- L4부터 L7계층까지 로드밸런싱 가능
- 하나의 url만 가질 수 있음.
- Network Load Balancer
- L4계층에서 작동
- tcp/udp 트래픽을 로드밸런싱
- 고정 ip주소 지원
- Application Load Balancer
- L7계층에서 작동
- http/https 트래픽을 처리하는 로드밸런싱에 최적화
- path-based routing 지원 → 연결된 각각의 인스턴스들이 여러개의 url과 path를 가질수 있음
출처
https://pearlluck.tistory.com/114
https://bluese05.tistory.com/51
https://potato-yong.tistory.com/131
https://tecoble.techcourse.co.kr/post/2021-11-07-load-balancing/
백엔드 개발자