Load Balancer(로드밸런서)와 LB 알고리즘 간략 정리

애플리케이션을 위한 서버가 여러대 있다고 생각해보자. 무조건 서버만 많다고 성능이 극대화되는 것이 아니고, 이를 잘 분산시켜 서버에 분배해야 성능이 극대화 될 것이다. 이런 서버들에게 요청들을 밸런스있게 분산시켜주는 역할을 하는 중간자가 필요할텐데, 이게 로드밸런서다. 

• LB는 어떤 분산 시스템에서든 또다른 매우 중요한 컴포넌트임
• 트래픽을 여러 서버로 분산시켜줘서 responsiveness 와 db와 애플리케이션의 가용성을 올려주는 역할을 한다.
• 또한, LB는 요청들을 분산시키면서, 모든 자원들의 상태를 계속 트래킹 한다. 예를 들면, 어떤 서버가 지금 요청 처리를 못하는 상태에 있으면, LB에서 이 상태를 알아둬서 해당 서버로의 트래픽 분산을 막을 수 있다.
• LB는 크게 3가지 위치에 둠
  • 1. 유저와 웹서버 사이, 2. 웹서버와 내부 플랫폼 레이어(애플리케이션 서버나, 캐시 서버) 사이, 3. 내부 플랫폼 레이어와 database 사이
  • Client - LB1 - Web Servers - LB2 - Application Servers - LB3 - DB Servers 순임
• Load Balancing 의 이점
  • 더 빠르고, 유저는 더 이상 하나의 서버에 대해서만 응답을 기다릴 필요가 없어짐
  • 서비스 제공자 관점(개발자 관점이겠지..)에서는 less downtime, 스루풋은 더 높이는 효과
  • 스마트한 LB는 트래픽 병목 구간을 사전에 예측해서 분석해주기도 한다.
• Load Balancing Algorithms
  • 그럼 어떤 원리로 로드밸런싱 시스템이 적절한 서버를 골라주는지가 궁금할 것이므로 알아보자.
  • 크게 LB는 백엔드 서버로 리퀘스트를 포워딩하기 전에 2가지 팩터를 고려한다. 첫번째로 실제로 적절하게 요청에 대한 응답을 할 수 있는 서버 set을 선택하고, 두번째로 이 서버 set 들 중 가장 healthy? 한 서버를 고르기 위해 알고리즘을 사용한다. 아래 알고리즘을 정리해보자.
    • Health Checks: 규칙적으로 백엔드 서버에 연결을 시도하여 서버가 listening 상태임을 확인하는 것이다.(즉, 응답을 받을 준비가 되어있는 서버인지를 체크)
    • Least Connection Method: 트래픽을 가장 Active connection이 적은 서버를 고르는 로직
    • Least Bandwidth Method: 서버 중 현재 단위 시간 당 측정되는 트래픽 megabits의 양이 가장 적은 서버를 고르는 로직
    • Round Robin Method: 서버를 순회하고, 그 다음 서버에 새로운 요청을 보내면서 순회하며 서버를 고르는 방식임. 서버 리스트의 마지막을 돌면, 다시 처음 서버로 요청이 가면서 루프를 돈다. 주로, 동일 스펙의 서버들이 있을 때 유용하고, 지속적 연결상태가 없을 때 유용하다.
    • Weighted Round Robin Method: 위랑 차이점은 각 서버당 가중치를 설정하여,(이 가중치는 보통 processing capacity를 상대적으로 나타내는 정수값으로 주어진다.) 서버를 선택한다. 예로들면, 커넥션이 적고, 가중치가 높은 서버가 가장 1순위가 될 것이다.
    • IP Hash: 클라이언트의 ip 주소의 해쉬값을 이용하여, 이 해쉬값에 따라 계산을 해서 서버를 고른다. (서버를 리다이렉트 해준다.)
• Redundant Load Balancers
  • LB도 결국 장애가 일어날 수 있으므로, 여러 대를 붙여서 장애에 대비한다. 가령 2대라고 하면, LB 2대는 서로 연결 되어, 하나의 클러스터를 이룬다. 만약 메인 LB 가 죽으면, 두번째 LB가 이를 떠맡게 된다.