测验：超时预算

상대의 응답이 200ms 에서 30초로 느려졌다. 우리 타임아웃이 60초일 때 우리 쪽에서 벌어지는 일은?

• 우리 워커가 30초씩 묶여 처리량이 떨어지고, 우리를 부르는 쪽에서는 우리가 느려진 것으로 보인다
• 타임아웃이 넉넉하므로 우리 쪽에는 영향이 없고 상대가 회복하면 원래대로 돌아온다
• 연결이 60초 동안 유지되므로 커넥션 풀이 오히려 효율적으로 재사용된다
• 상대가 30초에 응답하므로 우리 타임아웃 값은 아무 역할도 하지 않는다

연결 타임아웃과 읽기 타임아웃을 나눠 잡는 이유로 가장 정확한 것은?

• 두 값을 나누면 라이브러리가 커넥션 풀을 더 잘 재사용하기 때문이다
• 연결은 닿는 시간이라 오래 걸리면 느린 것이 아니라 안 되는 것이고, 읽기는 상대가 일하는 시간이라 업무마다 다르기 때문이다
• 연결 실패는 재시도해도 되고 읽기 실패는 재시도하면 안 되기 때문이다
• 한 값으로 주면 라이브러리가 그 값을 연결에만 적용하고 읽기에는 적용하지 않기 때문이다

총 예산 2000ms 의 요청에서 앞의 호출들이 1800ms 를 썼다. 평소 400ms 걸리는 다음 호출을 어떻게 해야 하는가?

• 남은 200ms 를 읽기 상한으로 주고 걸어 본다. 운이 좋으면 성공할 수도 있다
• 예산을 200ms 늘려 잡고 건다. 한 번의 초과는 사용자가 느끼지 못한다
• 걸지 않고 곧바로 실패로 처리한다. 걸어도 실패를 200ms 뒤로 미룰 뿐이다
• 읽기 상한 없이 걸되 응답이 오면 버린다. 상대 쪽 캐시가 데워지는 이득이 있다

재시도 대기에 무작위를 섞는(jitter) 가장 큰 이유는?

• 난수를 쓰면 서버 쪽 캐시 적중률이 올라가 전체 지연이 줄기 때문이다
• 대기 시간이 매번 달라야 로그에서 재시도를 구별할 수 있기 때문이다
• 지수 증가만으로는 대기가 너무 길어져 예산을 넘기기 때문이다
• 같은 순간에 실패한 클라이언트들이 같은 순간에 한꺼번에 다시 몰리는 것을 막기 때문이다

상위 요청에 1200ms 가 남았는데 하위 서비스는 자기 기준으로 5초를 기다리도록 만들어져 있다. 무엇이 문제인가?

• 하위 서비스가 3800ms 동안 아무도 보지 않을 답을 만드느라 자원을 쓴다
• 하위 서비스의 상한이 더 길므로 상위가 먼저 끊어도 응답은 정상적으로 전달된다
• 상위가 1200ms 에 끊으면 하위 요청도 커널이 함께 취소하므로 자원 낭비는 없다
• 하위 서비스가 5초를 기다리는 동안 상위가 자동으로 재시도해 중복 요청이 생긴다

앱 설정의 타임아웃은 30초인데 실제 실패는 127초에 났다. 가장 먼저 의심할 것은?

• 상대 서버가 127초 만에 응답을 보냈고 그 값이 로그에 그대로 찍혔다
• 설정한 타임아웃이 적용되지 않아 커널의 재전송이 소진될 때까지 기다렸다
• 재시도가 4회 돌면서 30초씩 쌓여 127초가 됐다
• 네트워크가 느려져 30초 상한이 자동으로 늘어났다