[DB] 로드 밸런싱, 로드 밸런싱 알고리즘

주제에 대해서 정리를 하다 보니 개인적인 궁금증 위주로 자료조사를 한듯하다..🤪

Load Balancing

정의 & 사용 이유

💡정의

로드 밸런싱은 네트워크 트래픽을 여러 서버에 분배하여 서버 과부화를 방지하고, 시스템의 안정성을 높이는 기술

🤷로드 밸런싱의 이점(사용 이유)

• 장애가 발생하면 다른 서버로 트래픽을 전환하여 중단 시간을 줄여줍니다
• 트래픽을 예측하고, 필요한 경우 서버를 늘리거나 줄일 수 있습니다
• 트래픽을 모니터링하고 이에 맞는 보안을 적용할 수 있습니다
• 네트워크 지연 시간을 줄여 애플리케이션의 성능을 향상시킬 수 있습니다

원리

💡 클라이언트의 요청 → 로드 밸런서가 각 서버의 상태를 모니터링 → 트래픽 분배

✅(의문점) 어떤 상태들을 모니터링할까?

• 헬스 체크: 주기적으로 각 서버에 헬스 체크를 보내어 점검하고, 상태가 좋지 않으면 일시적으로 해당 서버로의 트래픽을 차단합니다.
• 서버의 부하 상태: 서버가 처리 중인 연결 수, CPU 사용량, 메모리 사용량을 실시간으로 수집.
• 응답 시간: 서버가 헬스 체크 요청을 처리하는 데 걸리는 시간을 확인

🤿[Deep Dive] 헬스 체크 데이터와 클라이언트 요청 사이에 시간 갭이 생긴다면?

보통 헬스 체크는 수초 단위로 설정한다고 함(생각보다 자주 안 해서 놀랐다)

헬스 체크는 주기적으로 서버의 상태를 점검하고, 주기적인 체크 사이에 발생한 상태 변화는 즉시 반영되지 않는다. 예를 들어, 서버가 헬스 체크 요청 시점에는 정상적이었지만, 그 후 헬스 체크가 다시 실행되기 전에 서버가 비정상 상태로 바뀐다면, 로드밸런서는 이 상태를 즉시 감지하지 못함

 

고급 로드밸런서는 실시간으로 헬스체크를 하는 것도 있다고 함

수초 정도의 차이는 엄청난 성능 저하로 이어지지 않는 것 같다

 

역시나 비용차이.. 인생은 trade-off.. 시간 부족 이슈ㅠㅠ 이 내용은 조금 더 찾아보자.

Load Balancing Algorithm

🔥(중점) 알고리즘 별로 적합한 서비스를 생각하면서 자료 조사 해보자🔥

1. Round Robin (RR)

• 가장 기본적인 알고리즘으로, 요청을 순차적으로 서버에 분배하는 알고리즘.
• 서버의 상태나 부하와는 관계없이 요청을 분배함.
• 정적인 웹사이트에 적합
• 연결 유지가 중요한 서비스에는 적합하지 않다. 

✅(의문) 연결 유지가 중요한 서비스?

• 온라인 게임 서버: 게임의 진행 상태나 플레이어의 상태 정보가 서버에 저장되어야 함
• 전자상거래 사이트: 결제 정보 같은 중요한 상태 정보를 유지해야 하는 경우
• 실시간 통신 애플리케이션(예: 채팅 시스템, 화상 회의): 실시간으로 연결 상태를 유지하며 통신하는 서비스는 세션이 끊어지지 않도록 동일 서버에 연결을 유지하는 것이 중요

2. Sticky RR

• RR 방식에 세션 유지 기능을 추가한 알고리즘.
• 세션 정보를 통해, 특정 클라이언트는 항상 동일한 서버에 요청을 보내도록 함.

3. Weighted RR

• 각 서버는 가중치를 가지고 있고, 그 가중치에 비례하는 양의 요청을 보내는 알고리즘.
• 고성능과 저성능 서버를 동시 운용할 때, 적합 → 영상 스트리밍

4. IP/URL Hash

• 클라이언트의 IP 또는 요청 URL을 해싱하여 해싱값에 매칭되는 서버로 분배하는 알고리즘.
• IP 해싱은 Sticky RR과 유사하지만, 세션 정보 없이 클라이언트가 일정한 서버에 요청 가능
• URL 해싱 알고리즘은 API 서버에 적합, 즉 url 패턴에 따라 특정 서버에만 가도록 할 수 있음

5. Least connections

 

• 현재 연결된 클라이언트의 수가 가장 적은 서버에 요청을 보내는 알고리즘.
• 서버의 처리 능력이 유사
• Weighted Least Connection

(예시)

1. 서버 A는 최대 100개의 연결을 처리할 수 있고, 서버 B는 최대 2개의 연결만 처리할 수 있음
2. 현재 서버 A는 3개의 연결을 처리 중, 서버 B는 2개의 연결을 처리 중

(결과)

• Least Connection: B 서버로 요청을 보냄
• Weighted LC: A 서버로 요청을 보냄

Least Connection + 각 서버의 성능을 추가로 고려

6. Least time

• 각 서버의 응답 시간이 가장 빠른 서버에 요청을 보내는 알고리즘.
• 응답 시간이 짧은 서버를 선택함으로써 성능을 최적화.
• 실시간 스트리밍 등

🤿 [Deep Dive] 알고리즘 선택 기준?

본인 서비스의 특징과 트래픽 패턴을 잘 트래킹 해서 적합한 걸 골라야 합니다.

(예시)

• Youtube Live와 같이 실시간성이 중요 → 가장 빠른 응답 필요 → Least Time
• 4K 스트리밍이 포함되어 있다 → 고성능 & 저성능 → Weighted Round Robin
• Netflix서버 간의 부하를 고르게 분배 → Least Connection

🔥(의문점) 아앍!!!!!!!!! 두 개를 같이 하는 서비스라면? like YouTube….

로드밸런서는 실시간 스트리밍 요청이 들어오면 Least Time 알고리즘을 적용하고, VOD 요청이 많을 경우에는 Least Connections 또는 Weighted Round Robin을 사용하여 서버 부하를 분산합니다.

어떤 알고리즘이 많이 사용될까?

몇 개의 클라우드 플랫폼 기업의 Docs를 읽어보니 다음과 같습니다.

클라우드 서비스	사용 알고리즘
aws ec2	RR
ncp	RR, Least Connection, IP Hash
KT	RR, Hashing (Source IP/Source IP+Port),  Least Connection, Least Response