지난주 express에서 multer 모듈을 활용해 프론트에서 보내준 사진을 내 로컬 데이터베이스 공간에 저장하고, 해당 사진을 다시 프론트엔드에 보내는 작업을 수행했다.
하지만 이러한 단일 서버로 운영하는 방식은 당연히 여러 문제가 있다.
서비스를 사용하는 사용자가 셀 수 없이 많아진다면, 점차 받는 데이터 양이 광범위해질 것이고 그러면 비효율적인 요청과 응답, 취약한 보안 등 여러 문제에 직면할 것이다.
게다가, 서버의 갯수를 여러 개로 늘리는 scale-out 방식으로 전환되려면 많은 복제 작업이 진행될 것이고, 그 사이 서버의 문제가 생길 수도 있다. 설령 내 서버의 하드웨어 성능을 높이는 scale-up 방식을 활용하더라도 말이다..
그리고 데이터베이스와 백엔드 어플리케이션 서버를 분리하더라도 단일 서버의 문제를 완벽히 해결할 수 없고, 여전히 하나의 서버만 있기 때문에 scale-out으로 전환이 어렵다.
Load Balancing
로드벨런싱은 백엔드 서버 그룹에 들어오는 네트워크 트래픽을 효율적으로 분산하는 것이다.
브라우저를 통해 에플리케이션 서버에 접근한 사용자의 데이터 요청이 서버에 바로 오지 않게 하는 방식이 바로 로드밸런싱이다.
즉, 로드밸런서가 하는 일은
1. 수많은 요청을 먼저 받은 로드밸런서는 서버에 최대한 부담이 가지 않도록 여러 서버에 요청을 나눠준다.
2. 요청 수행이 불가한 서버에는 전송하지 않음으로써 여러 서버들을 효율적으로 활용한다.
3. scale-out 방식을 접목해 수요에 따라 서버를 추가하거나 제거할 수 있는 유연성을 제공한다.
Load Balancing Algorithms
로드밸런싱은 여러 알고리즘을 통해 다양한 방식으로 서버에 요청을 제공한다.
Round Robin
클라이언트에서 요청이 오면, 서버 그룹 전체에 순차적으로 분산시키는 방식.Least Connections
요청을 받은 시점에서 클라이언트와 연결이 가장 적은 서버에 요청을 전송하는 방식. 트래픽으로 인해 작업 시간이 길어지는 경우 권장되는 방식이라고 한다.Least Time
가장 빠른 응답 시간과 가장 적은 활성 연결을 결합한 공식을 활용해 선택한 서버에 요청을 제공.Hash
사용자의 IP 혹은 요청 URL를 hash하여 서버에 분배하는 방식. 사용자는 항상 같은 서버로 연결될 수 있다.Random with Two Choices
무작위로 두 개의 서버를 선택하고 최소 연결 또는 시간 알고리즘으로 처리할 수 있는 서버에 요청을 보내는 방식.
Load Balancer 종류
로드밸런서는 OSI 7계층을 기준으로 분산하는지에 따라 종류가 나뉜다. L 뒤에 숫자가 붙고 그 숫자에 해당하는 계층이 이름 붙여지는 방식으로 분류할 수 있다. 그리고 상위 계층으로 갈수록 섬세한 부하 분산이 가능하지만 가격이 비싸다.
L2Data link 계층을 사용, Mac주소 기반 부하 분산L3Network 계층을 사용, IP주소 기반 부하 분산L4Transport 계층을 사용, Port 기반 부하 분산 TCP, UDPL7Application 계층을 사용, 요청(URL) 기반 부하 분산 HTTP, HTTPS 등
HTTP
X-Forwarded-For
HTTP 또는 HTTPS 사용 시 클라이언트의 IP 주소를 식별하게 함.X-Forwarded-Proto
클라이언트가 로드 밸런서 연결에 사용한 프로토콜(HTTP 또는 HTTPS) 식별하게 함.X-Forwarded-Port
클라이언트가 로드 밸런서 연결에 사용한 포트를 식별하게 함.
Load Balancer 기능
NAT(Network Address Translation)
Private IP를 Public IP로 바꾸는 통신망의 주소 변조기 기능.Tunneling
임의의 통로를 만들어 통신하는 개념.
데이터를 캡슐화해서 연결된 노드만 캡슐화된 패킷을 해제 가능.DSR(Dynamic Source Routing protocol)
요청에 대한 응답 시 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념.
로드 벨런서를 공부하며 곧 다가올 클라우드 데이터베이스, AWS의 기반을 다질 수 있었다!!
참조
