로드 밸런싱 패턴을 알기 위해서는 로드 밸런싱이 무엇인지 알고 넘어가야 한다.
로드 밸런싱이란?
사용자의 요청을 받아 해당 요청에 대해 응답할 수 있는 서버에게 전달(라우팅)하는 것
그렇다면,
로드 밸런싱 패턴이란?
프론트엔드에서 백엔드로 직접 요청을 하는 것이 아닌, 로드 밸런서로 전달되도록 하고, 트래픽량에 따라 서버의 수를 조절하는 구조를 뜻한다.
사용자가 요청이 로드 밸런서를 거쳐 백엔드로 전송된다.
왜 프론트엔드에서 백엔드로 직접 요청을 전달하면 문제가 생기는 것일까?
단일 서버일 경우 사용자의 요청이 CPU 메모리나 네트워크의 용량을 넘어서면 성능이 저하되거나 장애가 발생할 수 있다.
→ 그렇다면 메모리나 용량을 늘리면 되는 거 아닌가?(Scale up)라고 할 수 있는데, 스케일 업하기 위해서는 인스턴스가 실행 중일 때는 할 수 없기 때문에 사용자들이 서비스를 제공받지 못한다.
가장 대표적인 로드 밸런싱 패턴 사용 사례는 프론트엔드에서 백엔드로 가는 HTTP 요청을 서버로 전달하는 것!
N-tier(다층 구조) 아키텍처나 마이크로서비스 아키텍처와 같이 다중 서비스 아키텍처의 경우에는 각 서비스를 동일한 애플리케이션 인스턴스에 그룹으로 배포하고, 각 그룹의 모든 통신은 각각의 로드 밸런서를 사용하여 트래픽을 전달받는다. → 각 서비스를 독립적으로 확장할 수 있다!!!
아래의 사진을 기반으로 예를 들면,
마이크로서비스1, 2에 요청이 갑자기 증가하게 되면 두 서비스만 확장하면 된다. 나중에 트래픽이 감소하게 된다면 다시 축소할 수도 있다.
로드 밸런싱 패턴 구축 방법
- 클라우드 로드 밸런싱 서비스 이용하기
- 메시지 브로커 또는 분산된 메시지 대기열 이용하기
1. 클라우드 로드 밸런싱 서비스
클라우드 로드 밸런싱 서비스의 목적은 수많은 네트워크 요청을 수신하여 백엔드 서버로 라우팅하는 것이다.
서비스 인스턴스를 여러 가용 영역(AZ)에 배포하게 되면, 로드 밸런서 인스턴스를 그룹으로 실행하여 라우팅한다.
클라우드의 로드 밸런서 인스턴스는 모니터링 기능이 있어 문제가 발생하면 자동으로 재시작되기 때문에 성능 병목 현상을 피할 수 있다.
2. 메시지 브로커 또는 분산된 메시지 대기열
메시지 브로커란 송신자의 메시지 프로토콜 형식을 수신자의 메시지 프로토콜 형식으로 변환하는 중간 장치이다.
메시지 브로커의 정의를 살펴보면 본래 목적은 로드 밸런싱이 아니라는 것을 알 수 있는데, 이런 메시지 브로커를 적절하게 사용하면 메시지 로드가 많은 서비스를 로드 밸런싱하는 데 유용하게 사용될 수 있다.
메시지 브로커는 메시지를 보내는 퍼블리셔를 하나 이상 둘 수 있는데, 로드 밸런서처럼 메시지의 볼륨에 따라 인스턴스를 확장하거나 축소할 수 있다.
인스턴스를 확장함으로써 수신하는 메시지의 속도를 향상할 수 있다.
메시지 브로커는 단방향이거나 비동기식일 때 활용하면 아주 유용하다.
* 메시지 브로커는 내부적으로만 사용되어야 한다.
로드 밸런싱 패턴 설계 시 고려 사항
로드 밸런싱 패턴을 설계할 때 단지 로드 밸런서만 배치한다고 좋은 설계 방법이 되는 것이 아니다.
로드 밸런서가 수신한 요청을 어떤 식으로 서버에 전달할 것인지, 만일 서버가 부족하거나 필요하지 않다면 이 서버의 수를 어떤 식으로 조절할 것인지 정해야 된다.
[로드 밸런싱 패턴 설계 고려 사항]
- 라우팅 알고리즘 선택
- 스케일링 방법 선택
라우팅 알고리즘 선택
첫 번째로는 어떤 라우팅 알고리즘을 사용해야 하는지 고민해볼 필요가 있다.
라우팅 알고리즘은 여러가지가 있지만, 딱 3가지만 살펴보려고 한다.
- 라운드 로빈 알고리즘
- 고정 세션(세션 선호도)
- 최소 연결 알고리즘
1. 라운드 로빈 알고리즘
각 수신 요청을 다음 인스턴스에 라우팅하는 기법으로 기본 동작 방식이다.
요청이 총 6번 들어오면
첫 번째 서버부터 차례대로 요청을 전송한다.
하지만 하나의 서버에 대용량 파일을 여러 번의 요청으로 나누어서 업로드하게 된다면 라운드 로빈 방식으로 동작할 수 있을까?
라운드 로빈은 차례대로 한 요청씩 다른 서버에 전송하기 때문에 제대로 파일이 업로드되지 않을 것이다.
그렇다면 이런 문제는 어떤 알고리즘을 써야 하는 것일까?
2. 고정 세션(세션 선호도)
특정 클라이언트로부터 받은 트래픽을 특정 서버로 전송하는 방식이다.
로드 밸런서로 전송하는 모든 요청에 대한 쿠키 또는 클라이언트 IP 주소를 이용하여 각 요청의 속성을 식별하여 같은 서버로 전송한다.
하지만 이 방법은 세션이 짧을 경우에만 효과적으로 작동하게 된다. → 한 서버에 요청이 몰리게 되므로 성능이 나빠질 수 있음!
3. 최소 연결 알고리즘
요청이 가장 적은 서버로 새로운 요청을 라우팅하는 알고리즘으로, 장시간 연결을 요구하는 태스크에서 유용하게 사용된다. (예: SQL, LDAP 등)
이외에도 많은 라우팅 알고리즘이 존재하므로 애플리케이션의 동작과 특징에 따라 라우팅 알고리즘을 선택해야 한다.
스케일링 방법 선택
클라우드 환경에서는 오토 스케일링(Auto Scaling)이라는 기능을 제공하고 있다.
Auto Scaling이란 메모리 소비, CPU 사용률에 관한 데이터를 수집하여 이를 지표삼아 서버의 수를 확장하거나 축소하는 정책이다.
이 오토 스케일링 정책을 로드 밸런싱 서비스에 연결하여 백엔드 서버를 동적으로 조정할 수 있다.
트래픽이 높으면 서버를 증가하고, 낮으면 감소하는 방식으로 진행된다. → 비용 절감이 가능하다.
요약
- 로드 밸런싱 패턴은 각 요청을 부하 분산하는 기능을 하는 소프트웨어 아키텍처다.
- 로드 밸런싱 패턴을 구현하는 방법은 1. 클라우드 로드 밸런싱 서비스, 2. 메시지 브로커이다.
- 애플리케이션의 특징에 따라 라우팅 전략을 달리 세워야 한다. (스테이트리스 애플리케이션인지? 스테이트풀 애플리케이션인지? 연결 시간은 얼마나 되는지? 등)
- 클라우드 서비스에서는 오토 스케일링 정책을 사용하여 동적으로 백엔드 서비스의 크기를 조정할 수 있다.
'클라우드 컴퓨팅 > SW 아키텍처' 카테고리의 다른 글
| 확장성 패턴 3 - 스캐터 게더 패턴(Scatter Gather Pattern) (0) | 2024.12.12 |
|---|---|
| 확장성 패턴 2 - 파이프-필터 패턴(Pipe And Filter Pattern) (0) | 2024.12.06 |