로드 밸런싱 (Load Balancing)
Fly Proxy는 앱에 지정된 동시성(concurrency) 설정, 현재 부하, 그리고 근접도(closeness)를 조합해 앱의 개별 Machine으로 요청을 라우팅해요. 이 페이지에서는 Fly.io에서 앱으로 트래픽을 로드 밸런싱하는 과정의 세부 사항을 설명해 드릴게요.
출처: 문서
본문
Fly Proxy는 앱에 지정된 동시성 설정, 현재 부하, 그리고 근접도의 조합을 사용해 앱의 개별 Machine으로 요청을 라우팅해요. 이 페이지에서는 Fly.io에서 앱으로 트래픽을 로드 밸런싱하는 과정의 세부 사항을 설명해요.
로드 밸런싱 전략
기본 로드 밸런싱 전략은:
- 부하가 가장 적고 가장 가까운 Machine으로 트래픽 보내기
- 여러 Machine의 부하와 근접도가 동일하면 하나를 무작위로 선택
부하
Fly Proxy는 앱에 구성된 동시성 설정과 해당 설정에 대한 현재 트래픽을 사용해 부하를 결정해요.
아래 표는 구성된 soft_limit과 hard_limit 값에 따라 트래픽이 Machine으로 라우팅될 수도 있고 안 될 수도 있는 방식을 설명해요.
| Machine load | What happens |
|---|---|
Above hard_limit |
No new traffic will be sent to the Machine |
At or above soft_limit, below hard_limit |
Traffic will only be sent to this Machine if all other Machines are also above their soft_limit |
Below soft_limit |
Traffic will be sent to the Machine when it is the closest Machine that is under soft_limit |
근접도
근접도는 연결이나 요청을 받는 Fly.io 엣지 서버와 Machine이 실행되는 워커 서버 사이의 RTT(왕복 시간)로 결정돼요. 같은 리전 안에서도 우리는 RTT가 다른 서로 다른 데이터센터를 사용해요. 이 RTT는 모든 서버 사이에서 지속적으로 측정돼요.
우리의 RTT 앱을 사용해 Fly.io 리전 사이의 실시간 RTT 값을 관찰할 수 있어요.
웹 서비스의 로드 밸런싱 예시
구성된 CPU와 메모리 설정으로 25개의 동시 요청을 처리할 수 있다고 알려진 가상의 웹 서비스가 있다고 해봐요. fly.toml에 다음 값을 설정해요:
[services.concurrency]
type = "requests"
hard_limit = 25
soft_limit = 20
type = "requests"로 설정해서 Fly.io가 동시 HTTP 요청을 사용해 부하를 언제 조정할지 결정하게 해요. 우리는 type = "connections"보다 이것을 선호하는데, 웹 서비스가 각 요청에 대해 작업을 수행하고 사용자가 단일 연결에서 여러 요청을 할 수 있기 때문이에요(예: HTTP/2). Fly Proxy는 type = "requests"를 사용할 때 앱에 대한 연결을 자주 여닫지 않도록 Machine에 대한 연결을 짧은 시간(약 4초) 동안 풀링하기도 해요.
soft_limit을 20으로 설정해서 Fly Proxy가 트래픽을 더 고르게 분산하기 전에 같은 리전 내에서 부하가 적은 Machine을 선호할 수 있는 여유(headroom)를 확보해요. 소프트 한도는 리전 내 라우팅에만 영향을 줘요. 프록시가 다른 리전으로 트래픽을 옮기게 하지 않아요.
ams(암스테르담), nrt(도쿄), sjc(샌호세), sin(싱가포르) 네 개 리전에 10개의 Machine을 배포하고, 그중 세 개는 ams에 있다고 해볼게요.
이 인위적인 예시에서 모든 사용자가 현재 암스테르담에 있으므로 트래픽은 암스테르담의 Fly.io 엣지 중 하나에 도착해요. 암스테르담 사용자의 동시 HTTP 요청 수가 증가함에 따라 일어나는 일은 다음과 같아요:
- 동시 요청 60개: 요청이
ams리전의 3개 Machine에 고르게 나눠져요. 워커와 엣지의 근접도가 각 요청이 3개 Machine 중 어디로 갈지 결정해요. - 동시 요청 61개 이상:
ams의 세 Machine 모두soft_limit위지만hard_limit아래라면 Fly Proxy는 계속 그쪽으로 라우팅해요. 소프트 한도만으로는 다른 리전으로 트래픽을 옮기지 않아요. - 동시 요청 200개 이상: 모든 Machine이
soft_limit에 있으므로 Fly Proxy는amsMachine으로 요청을 다시 라우팅하기 시작해요. 예를 들어 201번째 동시 요청은 현재soft_limit에 있는ams리전의 Machine으로 가요. - 동시 요청 250개: 모든 Machine이
hard_limit에 있어요. 251번째 동시 요청은 Machine이hard_limit아래로 내려갈 때까지 Fly Proxy가 대기열에 넣어요.
트래픽이 오랫동안 hard_limit을 크게 넘으면, Fly Proxy가 Machine으로 라우팅할 수 없는 요청에 대해 503 Service Unavailable 응답을 반환하기 시작할 수 있어요.