요약
- least outstanding requests(LOR)가 세는 것은 처리 중인 요청의 개수다. 몇 분 열려 있는 요청 하나와 수십 ms 요청 하나가 같은 무게다.
- 그래서 업로드·SSE·롱폴링이 섞인 타깃그룹에서는 CPU가 한가한 타깃을 회피하고, 짧은 요청으로 CPU를 태우는 타깃은 회피하지 않는다.
- WebSocket은 LOR로 타깃을 한 번 고른 뒤 모든 메시지를 그 커넥션으로 보내므로, 잘못 고른 판정이 커넥션 수명 내내 고정된다.
본문
개수를 처리 능력의 대리 지표로 쓰는 것
LOR의 전제는 "요청들이 대체로 비슷하게 걸린다"다. 그러면 처리 중인 개수가 많다는 건 처리가 느리다는 뜻이 된다. 요청 시간 분포가 이봉(bimodal)이면 이 대리 지표가 깨진다. 파일 업로드 5개를 물고 있는 타깃과 짧은 조회 5개를 물고 있는 타깃이 같은 점수를 받는다.
방향은 양쪽 다 틀린다. 오래 열린 요청을 든 타깃은 CPU가 남아도 회피 대상이 되고, 짧고 무거운 CPU 작업을 처리하는 타깃은 개수가 안 쌓이니 계속 선택된다.
문서에 명시된 두 가지 카운트 규칙
- HTTP/2를 지원하는 로드밸런서가 HTTP/1.1만 지원하는 타깃에 붙으면 요청을 여러 개의 HTTP/1.1 요청으로 변환하는데, "the least outstanding requests algorithm will treat each HTTP/2 request as multiple requests." 즉 프로토콜 조합에 따라 카운트 단위 자체가 달라진다.
- WebSocket에서는 "the target is selected using the least outstanding requests algorithm. After the target is selected, the load balancer creates a connection to the target and sends all messages over this connection."
한 번의 선택이 오래 고정되는 트래픽
WebSocket이 그렇고, sticky session을 켠 경우도 같다. 문서는 "If you enable sticky sessions, the selected routing algorithm is used for the initial target selection. Future requests from the same client will be forwarded to the same target, bypassing the selected routing algorithm."라고 한다.
LOR의 장점은 매 요청마다 재판정한다는 데서 나온다. 판정이 한 번뿐인 트래픽에서는 그 장점이 사라지고, 초기 선택 시점의 편향만 남는다. 워밍업 중인 신규 타깃이 초기 선택을 많이 받는 것과 겹치면 나쁜 조합이 된다 — LOR은 워밍업 중인 새 타깃을 먼저 고르는데 slow start로 막을 수 없다.
진단과 대응
타깃별 요청 수와 타깃별 CPU가 반대로 움직이면 카운트가 오염됐다고 본다(요청은 적게 받는데 CPU는 낮은 타깃이 있는 식). 대응은 알고리즘 쪽이 아니라 경로 분리다. 오래 열리는 엔드포인트를 별도 타깃그룹이나 별도 서비스로 빼면 카운트가 짧은 요청만으로 채워진다.
관련 노트
- 처리 속도가 제각각인 서버에는 round robin 대신 least outstanding requests를 쓴다
- LOR은 워밍업 중인 새 타깃을 먼저 고르는데 slow start로 막을 수 없다
- 동시 처리 요청 수를 응답시간으로 계산했다면 응답시간을 두 번 센 것이다
- Gunicorn 워커 수가 많아지면 thundering herd로 인해 일부 워커만 요청을 받는다