クイズ: リトライと部分的な失敗
한국어 원문으로 표시합니다.
재시도 반복문 전체를 스팬 하나로 감싸면 덤프에서 가장 먼저 사라지는 것은?
- 감싸는 스팬의 전체 소요 시간
- 그 요청에 붙은 트레이스 아이디
- 시도마다 걸린 시간과 각 시도가 실패한 사유
- 상류 서비스의 이름이 담긴 리소스 속성
세 번 시도해 세 번째에 성공한 요청을 그릴 때 상태를 어떻게 두는 것이 이 모듈의 규칙인가?
- 실패한 두 시도 스팬만 ERROR 로 두고 감싸는 스팬은 OK 로 둔다
- 감싸는 스팬과 실패한 시도 스팬을 모두 ERROR 로 둔다
- 감싸는 스팬만 ERROR 로 두고 시도 스팬의 상태는 건드리지 않는다
- 시도가 하나라도 실패했으므로 모든 스팬을 UNSET 으로 남긴다
스팬 13개 가운데 7개가 ERROR 이고 그중 루트 스팬은 4개 중 1개가 ERROR 다. 두 오류율의 차이가 뜻하는 것은?
- 루트 기준이 더 낮게 나온 것은 샘플링이 시도 스팬을 버렸기 때문이다
- 두 숫자가 다르면 계측이 잘못된 것이므로 스팬 기준으로 통일해야 한다
- 시도 스팬은 상태가 없으므로 스팬 기준 오류율은 계산할 수 없다
- 스팬을 세면 재시도가 분자와 분모에 함께 들어가 실패가 부풀려진다
대기(backoff)로 보낸 시간은 덤프에서 어떻게 드러나는가?
- 마지막 시도 스팬의 길이에 더해져 그 시도가 길게 보인다
- 감싸는 스팬의 길이에서 시도 스팬들이 덮은 구간을 뺀 빈틈으로 남는다
- SDK 가 자동으로 backoff 스팬을 만들어 자식으로 붙인다
- 대기는 CPU 를 쓰지 않으므로 어느 시간에도 포함되지 않는다
재시도 횟수·마지막 실패 사유·멱등 키를 속성으로 남길 때 자리를 고르는 기준은?
- 카디널리티가 낮은 값은 시도 스팬, 높은 값은 감싸는 스팬에 둔다
- 값이 문자열이면 감싸는 스팬, 정수면 시도 스팬에 둔다
- 그 값이 논리적 요청 하나마다 정해지는가, 시도마다 달라지는가로 가른다
- 모든 속성을 두 층에 똑같이 복사해 두어야 어느 쪽에서도 질의할 수 있다
반복문이 라이브러리 안에 있어 고칠 수 없는 두 번째 서비스에 같은 규칙을 적용하려면?
- 라이브러리를 포크해 반복문에 직접 스팬을 넣는 것 말고는 방법이 없다
- 라이브러리가 열어 둔 훅에서 스팬을 만들고 끝내 같은 속성 규칙을 남긴다
- 감싸는 스팬만 만들고 시도는 세지 않는 예외를 그 서비스에만 둔다
- 그 서비스의 재시도는 전파기 설정으로 자동 계측되므로 손댈 것이 없다