문제 상황
수만명의 고객에게 뉴스를 전송하는 간단한 웹 애플레이케이션이 있다. 고객은 웹 브라우저나 모바일 앱에서 뉴스를 읽거나 시청을 한다.
어느 시점부터 대용량의 트래픽이 인입되고 있고 정상적으로 처리를 못하고 있다. 특정 CPU 사용량이나 네트워크 트래픽을 감당을 못하는 상황이다. 이러한 상황에서 서버를 좀 더 강력한 가상머신으로 업그레이드 하는 건 문제 해결을 늦출 뿐이다.
로드 밸런싱 패턴 소개
로드 밸런싱 패턴은 소스 데이터와 워커 사이에 해당 데이터를 처리하고 응답을 전송하는 워커 사이에 디스패처를 배치한다. 디스패처는 각 클라이언트의 요청을 가용 워커로 라우팅한다. 부하가 많은 상황에서는 더 많은 워커를 추가하여 로드를 분산하는 역할을 한다.
[일반적인 형태] 프런트에서 백엔드로의 HTTP 요청
가장 일반적인 사용 사례는 프런트에서 백엔드로 가는 HTTP 요청이다.
마이크로서비스에 적용
마이크로서비스 아키텍처에서도 동일하게 적용할 수 있다. 또한 트래픽과 워크로드에 따라 독립적으로 확장을 할 수 있다.
프런트에서 백엔드로의 HTTP 요청
부하 상황에 따라 확장 또는 축소하여 비용을 절감할 수 있다.
구현 기술
1. 클라우드 로드 밸런싱 서비스
- 클라우드 서비스 회사의 로드밸런싱을 쓰는 것
- 필요에 따라 여러 대로 확장할 수 있다.
- 문제 발생 시 자동 재시작
2. 메시지 브로커 / 분산 메시지 큐
- 메시지를 통해 로드밸런싱을 구현
- 필요에 따라 확장/축소를 할 수 있다.
- 메시지 브로커의 주요 목적은 로드밸런싱은 아니다.
로드밸런싱 패턴 – 라우팅 알고리즘
1) Round-Robin
2) Sticky Session / Session Affinity
3) Least Connections
라우팅 알고리즘 – 1. Round-Robin
각 수신 요청을 연속적으로 다음 워커 인스턴스에 라우팅한다.
- 기본 로드밸런싱 알고리즘
- 애플리케이션이 stateless할 때 잘 동작한다.
- 클라이언트와 서버 간에 세션유지가 필요할 때는 사용하지 못한다.
라우팅 알고리즘 – 2. Sticky Session
클라이언트에 Cookie를 추가하거나 클라이언트의 IP주소를 사용하여 매번 동일한 서버로 요청한다.
- 라운드 로빈은 서버세션 및 대용량 파일 분할전송에는 사용하지 못한다.
- 클라이언트의 세션동안 동일한 서버로 요청할 수 있다.
- 이 알고리즘은 비교적 짧은 세션에서 효과적으로 작동
- 특정 기간에 특정서버에 과도하게 요청이 몰릴 때는 사용하면 안된다.
라우팅 알고리즘 – 3. Least Connection
가장 적은 요청을 처리하고 있는 서버로 새로운 요청을 라우팅한다.
- 부하가 많은 상황일 때 골고루 요청이 라우팅되게 분배한다.
- SQL, LDAP 등 장시간 연결이 필요한 작업에서 유용하게 사용할 수 있다.
오토 스케일링 (Auto Scaling)
참고
반응형
