서론
로드 밸런싱에 관한 지식들을 공부하고, 정리했던 내용을 바탕으로 글을 작성해 보았습니다
혹시나 틀린 내용이 있다면 지적해 주시면, 바로 반영하도록 하겠습니다
배경 및 기본 지식
Proxy
- “대리” 라는 뜻으로 생각하면 됨
- 무슨 일을 대신 처리하는 것
Proxy Server
- 특정 작업을 대신 처리해주는 서버
- 클라이언트 - 서버 사이의 중계 서버로, 통신을 대리 수행하는 서버
- 캐싱, 보안, 트래픽 분산 등 여러 장점을 가진다
- 종류로는 Forward Proxy, Reverse Proxy 가 있다
Reverse Proxy
- Reverse Proxy는 서버 앞단에 존재하며, 서버로 오는 요청을 대신 받아서 각 서버로 대신 전송해주는 역할을 한다
- 이를 통해 캐싱, 보안(서버의 IP주소를 클라이언트는 알 수 없음), 로드 밸런싱 등을 얻을 수 있음
본문
Load Balancing 이란?
- 작업(들어오는 요청들)을 적절하게 나누어서 각 서버의 부하를 분산시키는 것
- 다양한 로드 밸런싱 알고리즘을 통하여 요청을 적절히 분배한다
- 다양한 Layer 기반으로 로드 밸런싱을 하지만, 대표적으로 L4와 L7 로드 밸런싱을 많이 이용한다
Load Balancing 방식?
L4 Load Balancing
- L4 부터 Port 를 다룰 수 있기 때문에, L4를 많이 이용한다
- IP, Port 를 기준으로 부하를 분산함
- 클라이언트에서 Load Balancer(DNS)로 요청을 보냈을 때, 최적의 서버로 요청을 전송하고 결과를 클라이언트에게 보내줌
경험
- 실제로 우리는 아래와 같이, L4 기반 로드밸런싱을 통하여 front 서버를 구성하였다.
- DNS 로 요청을 보내면, 해당 로드 밸런싱을 통하여 선택된 알고리즘으로 요청을 분산한다(Round Robin)
L7 Load Balancing
- L7 위에서 동작하기 때문에, IP, Port 이외에도 URI, Payload, Http Header, Cookie 등의 내용을 기준으로 부하를 분산함
- 콘텐츠 기반 스위칭 이라고도 함
- L4 Load Balancer가 단지 부하를 분산시키는 것이라면, L7 Load Balancer 는 요청의 세부적인 사항을 두고 결제만 담당하는 서버, 회원가입만 담당하는 서버 등으로 분리하여 가볍고 작은 단위로 여러 개의 서비스를 운영하고, 요청을 각 서버로 분산시킬 수 있음
경험
- Spring Cloud Eureka 를 통하여 L7 기반 로드 밸런싱(API Gateway)을 구축하여 여러 api server로의 요청을 분산하였다
- 요청의 URI 를 기준으로 적절한 서버를 선택하여 요청을 분산한다
- API Server의 경우에는 2개의 서버가 운용되고 있고, 이는 Round Robin 방식을 채택하여 요청을 분산한다
Load Balancing이 나오게 된 배경
운용하던 서버에서 수용할 수 있는 요청이 제한되어 있고, 이 이상의 요청(Traffic)이 들어오게 되어 이를 적절히 대응할 방안이 강구되었다
- Vertical-Scale-Up
- Horizontal-Scale-Out
Vertical-Scale-Up
- 단일 서버의 성능을 증가시켜(CPU,RAM…) 해당 서버가 받는 Traffic 을 더 많이 수용할 수 있도록 구성
- 서버 자체의 퍼포먼스를 늘려서 더 많은 요청을 받도록 하는 것
- 다만, 기술적인 한계가 존재한다
- 업그레이드 할수 있는 한계치가 분명 존재한다
Horizontal-Scale-Out
- 서버를 추가하여 서비스로 오는 요청을 각 서버로 분산할 수 있도록 구성한다
- 단일 서버가 받는 트래픽 부담을 줄여줄 수 있다
- 업그레이드하는 것보다 더 많은 비용이 발생할 수 있다
서버를 추가한다면, 요청을 적절히 분산시킬 수 있는 장치 혹은 소프트웨어가 필요하다
이를 Load Balancer 라고 하며, 아래와 같은 적절한 알고리즘을 사용하여 각 서버로 요청을 분산한다
Load Balancing Algorithm
Round Robin(RR)
- 들어오는 Request(요청) 을 각 서버에 순차적으로 보낸다
- 서버가 5개 존재한다면, 서버1 → 서버2 → 서버3 → 서버4 → 서버5 로 들어오는 요청을 전송한다
- 이를 통해, 각 서버가 요청을 골고루 분산하여 가져갈 수 있음
- 다만, 각 서버마다 처리 속도가 다를 수 있기 때문에 특정 서버의 부하가 발생할 수 있다
Random Select
- 들어오는 요청을 랜덤하게 아무 서버로 보내는 방식이다
- 운이 나쁘면, 한 서버가 더 많이 선택되어 부하가 생길 수는 있지만 많이 발생하지는 않는다
- 생각과는 다르게 거의 Uniform 하게 분산된다
- 다만 RR 과 비슷하게, 각 서버의 상태를 고려하지는 않는다
Least Connection
- 각 서버의 상태를 고려하여, 부하가 적은 서버로 요청을 분산한다
- 각 서버가 역으로 얼마만큼의 트래픽을 감당하고 있으며, Connection 의 개수는 얼마인지 등에 대한 정보를 Load Balancer 에게 주기적으로 알려준다
- 이러한 정보를 바탕으로, Load Balancer 가 어떤 서버로 보낼 지를 결정한다 (Dynamic 방식)
- 실시간 통신이 이루어져야 하기 때문에 로직이 복잡해질 수 있다
- 하지만 스마트한 방식 중 하나이다
Ratio
- 서버의 스펙을 고려하여, 가중치를 설정하고 가중치에 따라 요청을 분산한다
- 성능이 좋은 서버는 더 높은 가중치를 설정받아 더 많은 요청을 분배하고, 성능이 낮은 서버는 더 낮은 가중치를 설정받고 더 적은 요청을 분배한다
- 분산 시스템에서 서버의 성능을 동일하게 맞추는 것은 쉽지 않기 때문에 위와 같은 방식이 고려되었다
- 서로 다른 처리 능력을 가진 서버들에게 동일한 양의 트래픽을 분배하게 되면, 특정 서버가 요청을 감당하지 못하여 다운되는 경우가 생긴다
- 다운된 서버가 처리하지 못한 트래픽은 고스란히 다른 서버로 분산된다
- 각 서버의 부하가 점차 증가하게 되면서, 이를 처리하지 못하는 다른 서버들까지 다운될 수 있다
Load Balancer 구현 방식
- Software로 Load Balancer를 구현하는 방식
- Hardware로 Load Balancer를 구현하는 방식
Software 로 구현하는 방식
- 소프트웨어 로직을 구현하여 트래픽을 분산시킨다
- HAProxy, Reverse Proxy(Nginx, Apache …)
- 로직만 구현하면 되기 때문에 비용이 저렴하다
- Scale-Out 하는 상황에서 서버가 추가되었을 때 Configuration 만 변경하면 되어 간편함
Hardware 로 구현하는 방식
- L4, L7 스위치를 많이 이용한다
- 물리적인 방법으로 서버를 묶어서 트래픽을 분산시킨다
- 물리적인 방식을 사용하기 때문에 비용이 비싸다
- 반대로, 안정성이 높고 보안적인 측면에서도 우수하다
추가적으로 생각해야 할 점
우리는 Load Balancer 를 통하여 분산 환경을 구축했다
여러 서버를 두어 각 서버의 부하를 분산하고, 원활한 서비스를 구축하였다
다만, Load Balancer가 다운되면?
- 각 요청을 알맞게 분산시켜 줄 Load Balancer가 존재하지 않으면 서비스도 다운된다
- 이처럼, 특정 포인트에서 Failure(실패) 가 발생했을 때 전체 시스템이 다운되는 경우를 Single-Point-Of-Failure(SPOF) 라고 한다
- Load Balancer 를 한 서버에만 구축하여 서비스하게 되면, Load Balancer 가 다운되면 모든 서비스가 함께 다운된다
이처럼, Load Balancer 자체도 Scale Out 을 할 필요가 있다
- Master-Slave 구조를 사용하는 등의 방식이 존재한다
- Master 가 예상치 못한 이유로 다운되는 경우, Slave 가 Master 가 되어 서비스가 정상적으로 이루어질 수 있도록 구축 등..
댓글