Health와 적응형 동시성은 모두 “현재 상태를 측정해 다음 요청을 조절하는 제어 문제”입니다. probe가 성공했다는 사실, 새 요청을 받을 용량, 이미 실행 중인 작업의 수명은 서로 다른 상태이므로 하나의 boolean으로 합치면 장애 때 오판합니다.
Health 경로 성공과 주문 경로 실패
별도 연결로 응답하는 probe는 200인데 실제 주문 DB pool이 고갈됐을 수 있습니다.
상태 trace를 예로 들면 probe=200, 주문 pool 사용=100/100, queue=120일 때 instance는 생존하지만 주문을 더 받을 준비가 되지 않은 상태입니다. 이때 readiness를 무조건 유지하면 새 유입이 queue를 키우고, 모든 dependency를 readiness에 묶으면 공통 DB 장애에서 전체가 동시에 빠집니다. 기능별 필수 경로와 수락 한도를 함께 정의해야 어느 신호를 바꿀지 결정할 수 있습니다. liveness는 재시작으로 회복할 생존 문제, readiness는 새 일을 수용할 준비의 신호로 구분합니다. 특정 시점의 제한된 검사가 다음 모든 요청 성공을 보장하지 않습니다.
모든 외부 dependency를 readiness에 묶으면 공통 DB 장애에서 모든 instance가 동시에 제외될 수 있습니다. 너무 얕으면 실제 기능 장애를 놓칩니다. 기능별 필수/선택 의존·검사 비용·pool·queue·실제 사용자 성공을 함께 보고 범위를 정합니다.
Instance 제외와 잔여 Instance 부하 악화
10개 중 3개를 제외하면 같은 유입이 7개에 몰립니다. 부하 때문에 그 7개도 readiness를 잃으면 악순환입니다. 실패 연속 횟수·성공 연속 횟수·복귀 지연·서로 다른 임계값의 hysteresis로 짧은 잡음을 완화할 수 있지만 실제 용량 부족을 긴 임계로 숨기면 사용자 오류만 늦게 보입니다.
cold cache인 새 instance는 가중치를 점진적으로 올릴 수 있습니다. 복귀 때 유입량·오류·queue가 안정되는지 확인하고 이미 열린 연결은 별도 drain해야 합니다. readiness 변경만으로 TCP·HTTP/2·WebSocket이 다른 server로 이동하지 않습니다.
그림을 글로 읽기
- latency·in-flight·queue·오류
- 관측 창·신선도·hysteresis
- 변경률 제한·최소/최대 한도
- 실제 유입·작업 완료·회복
- latency·in-flight·queue·오류 → 관측 창·신선도·hysteresis: 노이즈·지연 확인
- 관측 창·신선도·hysteresis → 변경률 제한·최소/최대 한도: 제한된 조정
- 변경률 제한·최소/최대 한도 → 실제 유입·작업 완료·회복: 용량 변화
적응형 한도의 피드백 안정성
동시성 한도를 100에서 200으로 올려도 그 효과가 10초 뒤에 관측된다고 가정합니다. 이때 매초 낮은 지연만 보고 다시 한도를 올리면 이전 조정의 결과가 오기 전에 과부하에 도달할 수 있으므로, 관측 창·smoothing·최소 표본·변경률 상한·cooldown·min/max·안전한 고정 fallback을 함께 둡니다. 지표가 빠졌을 때는 지연 0으로 계산하지 않고 안전한 fallback을 사용합니다.
지연이 오르면 먼저 원본 포화인지 외부 API 장애·network·GC인지 나눠 봅니다. 예를 들어 현재 in-flight가 100인데 새 limit을 50으로 낮췄다고 해서, 이미 실행 중인 100개 중 50개가 즉시 종료된 것으로 계산하면 안 됩니다. 새 작업 수락만 줄이고 기존 작업은 실제 완료할 때까지 자원을 점유하게 해야 합니다. 따라서 controller가 겨냥하는 limit과 실제 남아 있는 실행 수를 별도 상태로 기록합니다.
| 상황 | 확인할 판단 |
|---|---|
| 지연만 상승 | 실제 병목·오류·queue와 대조 |
| 지표 오래됨 | 안전한 fallback·조정 중지 |
| limit 감소 | 새 수락 차단·기존 실제 완료 대기 |
| readiness 복귀 | cold capacity·점진 유입 |
| 공통 dependency 실패 | 전체 제외의 영향·기능 저하 정책 |
전파와 연결 종료의 측정
endpoint 제외 시각·마지막 신규 요청·활성 연결·종료 기한을 기록합니다. 고정 sleep 하나로 LB 전파가 끝났다고 증명하지 않습니다. GOAWAY·재연결·cursor·멱등 key 계약으로 진행 중 요청을 보호하고 내부 정리 기한을 외부 유예보다 짧게 둡니다.
계단 부하·burst·지표 누락·공통 장애·cold start·회복을 분리해 수렴·진동·성공 처리율·p99·재시도·제외 비율을 봅니다. 이 노트는 제어 설계이며 실제 적응형 controller의 안정성을 실험한 결과는 아닙니다.