요약
- least outstanding requests(LOR)는 처리 중인 요청 수로 라우팅하므로, 타깃별 요청 수가 지연의 원인이 아니라 결과가 된다.
- 그래서 "이 타깃이 요청을 많이 받아서 느려졌다"와 "느려서 요청을 덜 받았다"를 관측만으로 못 가린다. 라운드로빈에서는 요청 수가 외생 변수라 이 혼동이 없었다.
- 부하가 균등하다는 전제를 쓰는 기법도 같이 깨진다. 같은 타깃그룹 동시 카나리의 지분 M/(N+M)이 성립하지 않는다.
본문
요청 수가 외생 변수에서 내생 변수로 바뀐다
라운드로빈에서는 타깃별 요청 수가 거의 같으므로, 지연 차이는 타깃 쪽 사정(CPU 세대, 워밍업, 프로세스 상태)으로 해석할 수 있었다. 요청 수가 원인 쪽에 고정돼 있었기 때문이다.
LOR을 켜면 요청 수가 지연의 함수가 된다. 느린 타깃은 요청을 덜 받고, 요청을 덜 받으면 큐 대기가 줄어 지연이 다시 내려간다. 관측 값 두 개가 서로를 결정하므로 한쪽을 원인으로 지목할 수 없다.
구체적으로 흐려지는 판단
- 꼬리 사고 원인 지목. 꼬리를 만든 타깃 하나를 골라 "이 타깃이 느렸다"고 말할 때, 그 타깃이 급증분을 많이 받아서 느려진 건지 원래 느려서 적게 받고도 느렸던 건지 구분이 안 된다. 요청 수를 같이 봐도 방향을 못 정한다.
- 불균등 지표의 임계값. 특정 호스트 집중도(최다 요청 호스트의 비중) 같은 지표는 LOR에서 정상 범위가 재정의된다. 관찰 사례에서 이 값이 27%로 내려갔는데(기준선 33~85%), 낮아진 게 좋아진 것인지 판정 기준 자체가 바뀐 것인지는 이 지표만으로 말할 수 없다.
- CPU 균등화 기대. LOR이 균등하게 만드는 것은 처리 중인 요청 수이지 CPU가 아니다. 타깃 간 CPU 편차는 남는다. 오토스케일링이 평균 CPU를 보고 있다면 그 관계 자체는 유지되지만, "요청 수는 비슷한데 CPU만 다른 타깃" 같은 이상 탐지 규칙은 못 쓴다.
같은 타깃그룹 동시 카나리의 전제가 깨진다
변수 하나만 바꾼 카나리를 같은 타깃그룹에 동시 투입하면 부하 교란 없이 회귀 원인을 격리한다는 기법은 ALB가 prod N대와 카나리 M대에 균등 분배해서 카나리 지분이 M/(N+M)이 된다는 데 의존한다. LOR에서는 이 지분이 카나리의 응답시간에 따라 정해진다.
방향이 하필 최악이다. 느린 카나리는 요청을 덜 받고, 요청을 덜 받으면 부하 의존적 지연(예: 동시성에 비례해 부풀는 I/O 측정값)이 줄어 회귀가 실제보다 작게 보인다. 즉 검증하려는 회귀를 LOR이 가려준다. 카나리를 돌릴 때는 알고리즘을 라운드로빈으로 두거나, 별도 타깃그룹에 가중 forward로 지분을 고정해야 한다.
정리
LOR은 사용자가 겪는 지연을 줄이는 대신, 타깃 단위 비교로 원인을 좁히는 능력을 내놓는다. 원인 조사가 필요한 구간에서는 알고리즘을 되돌리는 것도 선택지다. 대상 그룹 속성 하나라 무중단으로 오간다.
관련 노트
- 처리 속도가 제각각인 서버에는 round robin 대신 least outstanding requests를 쓴다
- 변수 하나만 바꾼 카나리를 같은 타깃그룹에 동시 투입하면 부하 교란 없이 회귀 원인을 격리한다
- LOR은 워밍업 중인 새 타깃을 먼저 고르는데 slow start로 막을 수 없다
- Fargate ARM64 전환은 평균 CPU가 아니라 태스크 간 편차를 줄인다
- 동시 처리 요청 수를 응답시간으로 계산했다면 응답시간을 두 번 센 것이다