요약
- 시스템 설계시 반드시 tail latency를 고려한느게 중요하다.
본문
- p99 스파이크는 뭐때문에 발생하는가?
- 가비지 컬렉션
- resource contention: 몇몇 요청이 lock, thread, slow network call에 갇힘
- queueing delays: 트래픽이 과도하게 몰려 몇몇 요청이 뒤쪽에 밀려 있음
- I/O or Disk Slowness: 특정 요청이 cold cache에 맞거나 느린 디스크 블록을 hit 함
- 이 post에서는 resource contention 이슈를 시뮬레이션함
- production에서는 p99 여도 엄청나게 많은 요청들이 영향을 받고 있는 것임
The Tail at Scale
- 시스템의 꼬리 부분의 지연이 전체 시스템 지연에 큰 영향을 줌
- 대규모 시스템에서는 평균 지연 시간보다는 tail latency가 전체 응답 시간을 정함
- 이 논문에서는 구글 검색의 분산 샤딩에서 확률적인 관점에서 이런 일이 왜 발생하는지 설명함
percentile latency 개념
- p50: 50%의 요청이 해당 값보다 빠름
- p90: 90%의 요청이 해당 값보다 빠름
- p99: 99%의 요청이 해당 값보다 빠름
p50: 20ms, p95: 80ms, p99 350ms
- 절반 요청은 20ms
- 대부분의 요청은 80ms 이하
- 1% 요청은 350Ms 이상
평균 latency만 보면 시스템이 건강해보임
- 99개 요청이 10ms, 1개 요청이 2000ms이면 평균이 약 30ms
- 평균만 보면 빠른 시스템으로 보임
Google의 fan out 구조
- 검색 인덱스가 너무 커서 샤딩되어 있고, 검색 요청이 여러 샤드로 동시에 fan out해서 검색 프론트 엔드에서 결과를 모아 최종 응답을 보냄
왜 1%의 느린 서버가 전체 문제로 커지는가?
- 가정: 각 서버가 99% 확률로 정상, 1%확률로 느림
- 전체 요청이 느려질 확률:
- 10대의 경우: 1 - (0.99)^10 => 9.6%
- 100대의 서버의 경우: 1 - (0.99)^100 => 63.4%
- 1000대의 서버의 경우: 1 - (0.99)^1000 => 99.9995%
- 개별 서버의 작은 불안정성이 fan out 구조에서 시스템 전체 문제로 증폭됨
- Tail Latency Amplification, 분산 환경에서 응답속도는 가장 느린 서버에 의존적임
Tail Latency는 항상 발생함
- 서버 내부 요인
- GC Pause, CPU contention, Lock Contention
- 시스템 환경
- Network jitter, Disk I/O, Cache miss
- 운영 환경
- Background job, Resource contention, 일시적인 부하 편차
Tail latency 대응 전략
- Hedged Requests: 동일 요청을 여러 복제본에 보내고 먼저 오는 응답을 사용
- Backup Requests: 조금 기다린뒤 느리면 추가 요청을 발사
- Cancellation: 빠른 응답이 오면 나머지 요청 취소
추가 트래픽을 유발하지만 p99 안정성은 개선됨
설계 포인트
- 평균 보다 p99
- 호출수를 줄인다.
- 느린 요청을 전제로 설계