Zettelkasten

처리 속도가 제각각인 서버에는 round robin 대신 least outstanding requests를 쓴다

·수정 1회
albawsload-balancingperformance

요약

  • round robin은 요청 "개수"만 똑같이 나눈다. 서버들의 처리 속도가 다르면 느린 서버에도 같은 양이 계속 들어간다.
  • least outstanding requests(LOR)는 처리 중인 요청이 가장 적은 서버를 고른다. 느린 서버는 요청이 오래 물려 있으니 알아서 덜 받는다.
  • LOR은 느린 서버를 빠르게 만들지 않는다. 느린 응답을 받는 사용자 수를 줄일 뿐이다.

본문

언제 round robin이 안 맞나

AWS 문서는 round robin을 "요청들이 비슷하게 무겁고, 서버들의 처리 능력이 비슷할 때" 쓰라고 한다. 둘 중 하나라도 깨지면 안 맞는다.

깨졌는지 보는 법은 간단하다. 서버별 요청 수와 서버별 평균 응답시간을 같이 뽑는다. 요청 수는 거의 똑같은데(관찰 사례에서 편차 0.04%) 평균 응답시간이 1.5~2배씩 벌어져 있으면 처리 능력이 다른 것이다.

LOR이 하는 일

처리 중인 요청이 가장 적은 서버로 보낸다. 느린 서버는 요청을 오래 붙들고 있으니 처리 중인 개수가 많고, 그래서 덜 받는다. 결과적으로 처리 능력에 비례해 나눠주게 된다.

적용하고 나면 서버별 요청 수가 불균등해지는 게 정상이다. 여전히 균등하면 안 먹은 것이다.

LOR은 치료가 아니라 우회다

느린 서버가 빨라지는 게 아니다. 그 서버로 가는 요청 수가 줄 뿐이다. 느린 응답을 겪는 사용자가 줄어드는 것이지 원인이 사라지는 게 아니다.

AWS 제약 세 가지

  • LOR과 slow start는 같이 못 쓴다. 문서에 "least outstanding requests나 weighted random을 쓸 때는 slow start를 켤 수 없다"고 명시돼 있다. 빠뜨린 기능이 아니라, 처리 중인 요청 수를 보는 방식이 slow start 역할을 대신하기 때문이다. 새로 뜬 서버가 느리면 요청이 금방 물리고, 그러면 LOR이 알아서 덜 보낸다.
  • ATW anomaly mitigation은 weighted random에서만 된다. 이상한 타깃을 자동으로 빼주는 기능인데 LOR과 같이 못 쓴다.
  • 그런데 ATW는 이 문제에 애초에 안 듣는다. anomaly detection이 보는 건 HTTP 5xx와 연결 실패뿐이다. "에러는 안 나는데 그냥 느린" 서버는 감지 대상이 아니다.

한 가지 위험

즉시 에러를 뱉는 서버는 처리 중인 요청이 0에 가깝다. 그래서 LOR이 오히려 그쪽을 우선 고른다. 블랙홀이라고 부른다.

적용 전에 확인해야 하는데, 이게 APM으로는 안 보인다. 앱이 죽어서 로드밸런서가 대신 만든 에러라서다. CloudWatch로 따로 봐야 한다. 자세한 건 APM에는 로드밸런서가 대신 만든 5xx가 안 잡힌다.

바꾸는 방법

대상 그룹 속성 하나다. 타깃을 다시 등록하지 않으므로 무중단이다.

aws elbv2 modify-target-group-attributes \
    --target-group-arn <arn> \
    --attributes "Key=load_balancing.algorithm.type,Value=least_outstanding_requests"

관련 노트

참고

이 문서를 참조하는 노트 (7)

함께 읽기 좋은 글