요약
- ALB 기본 동작은 타깃이 등록되고 첫 헬스체크를 통과하면 곧바로 전량 몫을 받는 것이고, 그걸 선형 증가로 바꿔주는 기능이 slow start다.
- 그런데 slow start는 least outstanding requests(LOR)와 같이 켤 수 없고, 갓 등록된 타깃은 처리 중인 요청이 0이라 LOR이 오히려 먼저 고른다.
- 워밍업에 10~15분 걸리는 앱에서는 스케일아웃 직후가 위험 구간이 되고, 남는 완화책은 등록 시점을 늦추거나 앱이 스스로 예열하거나 스케일아웃을 급증보다 앞당기는 것뿐이다.
본문
문서에 있는 두 문장
AWS 문서에 각각 따로 적혀 있는 사실이다.
- "By default, a target starts to receive its full share of requests as soon as it is registered with a target group and passes an initial health check." — slow start를 안 쓰면 신규 타깃은 통과 즉시 전량 몫을 받는다.
- "You can't enable slow start mode when using the least outstanding requests or weighted random routing algorithms." — LOR에서는 그 완화 기능을 켤 수 없다.
둘을 합치면 신규 타깃이 흡입구가 된다
LOR은 처리 중인 요청이 가장 적은 타깃을 고른다. 방금 등록된 타깃은 처리 중인 요청이 0이므로 판정 기준상 가장 한가한 타깃이다. 즉 아직 예열되지 않은 타깃이 등록 직후 한동안 우선 선택된다. 문서에 이 결합을 명시한 문장은 없고, 위 두 사실에서 나오는 추론이다.
자기교정은 돈다. 새 타깃이 실제로 느리면 요청이 물려서 처리 중인 개수가 올라가고, 그러면 LOR이 곧 덜 보낸다. 문제는 "곧"이 오기까지 이미 들어간 요청들이다. 즉 LOR은 신규 타깃 앞에서 한 번 오버슈트한 뒤 수렴한다.
라운드로빈보다 나쁠 수 있는 지점
라운드로빈에서 신규 타깃이 받는 몫은 1/N로 묶여 있다. LOR에는 그런 상한이 없다. 워밍업 중 몰릴 수 있는 양의 상한이 사라지는 것이 이 알고리즘 교체의 실질적 대가다.
워밍업이 긴 앱에서만 문제다
관찰 사례에서 새로 뜬 태스크는 첫 응답 329ms → 236ms → 209ms를 거쳐 정상 70100ms에 도달했고, 정상화까지 1015분 걸렸다(관찰됨, 원인 분해는 안 함). 커넥션 풀 채우기, 캐시 프리로드, 인터프리터 예열이 섞인 구간이다.
위험이 실제로 커지는 조건은 스케일아웃 시점과 트래픽 급증 시점이 겹칠 때다. 푸시 알림 발송처럼 유입이 계단식으로 뛰는 구간에서 오토스케일링이 그때야 태스크를 띄우면, 예열이 안 된 타깃이 급증분을 먼저 받는다.
slow start가 막히니 남는 수단 세 가지
- 앱이 스스로 예열한다. 헬스체크를 통과시키기 전에 커넥션 풀과 캐시를 채운다. 등록 시점을 앱이 통제하는 방식이라 가장 근본적이다.
- 등록 시점을 늦춘다. 헬스체크 통과 기준(간격·연속 횟수)이나 컨테이너 헬스체크 유예를 늘려 예열 뒤에 등록되게 한다. 대신 진짜 장애 복구도 같이 늦어진다.
- 스케일아웃을 급증보다 앞당긴다. 예약 스케일링을 워밍업 소요시간만큼 먼저 띄워 예열이 한가한 시간에 끝나게 한다. 실무에서는 이게 제일 확실한데, 여유 태스크를 그만큼 더 오래 켜두는 비용을 낸다.
관련 노트
- 처리 속도가 제각각인 서버에는 round robin 대신 least outstanding requests를 쓴다
- 업무시간의 빈번한 autoscaling을 어떻게 해결할 것인가?
- Fargate는 물리 CPU 세대를 고를 수 없어 같은 태스크 정의라도 성능이 1.5~2배 갈린다
- 커넥션 풀 대기는 프로세스당 실사용량으로 풀 고갈과 재연결 churn을 가른다