测验：背压

큐 시스템의 안정 조건은?

• λ < μ — 유입률이 처리율보다 작을 것
• 큐 깊이 < 1000
• 워커 수 > 4
• 메모리 여유 > 50%

큐 깊이 3,000, 처리율 초당 50건일 때 지금 들어온 메시지의 예상 대기 시간은?

• 대기 3초
• 대기 15초
• 대기 150초
• 대기 60초

이용률 ρ 를 0.95 로 운영하면?

• 노는 자원이 없어 하드웨어를 효율적으로 쓴다
• 순간 변동을 흡수할 여유가 없어 대기 시간이 폭발적으로 커진다
• 도착과 처리가 맞물려 큐 깊이가 0 에 수렴한다
• 같은 시간에 더 많이 처리해 처리율이 올라간다

큐 상한을 넘었을 때 429 를 주는 것이 무한히 받는 것보다 나은 이유는?

• 상한 검사만 하면 되어 코드가 간단해서
• 큐에 쌓이지 않아 브로커 메모리를 아껴서
• 지금 못 받는다고 말해야 클라이언트가 대응할 수 있어서
• HTTP 규격이 429 를 쓰도록 정하고 있어서

429 에 Retry-After 를 함께 주는 이유는?

• 클라이언트의 조기 재시도를 억제해 재시도 파도가 겹치는 것을 막으려고
• HTTP 규격이 429 에 이 헤더를 요구해서
• 재시도가 줄어 서버 로그 양이 줄어서
• 재시도 시각을 숨겨 공격을 어렵게 하려고

워커를 4배로 늘렸는데 처리율이 1.5배밖에 안 올랐다면 가장 먼저 확인할 것은?

• 큐 구현이 초당 전달 한계에 걸렸는지
• 네트워크 대역폭이 포화됐는지
• 메시지 크기가 커져 역직렬화가 느려졌는지
• 워커 뒤의 DB 나 외부 API 가 새 병목이 됐는지