クイズ: 失敗・リトライ・予算

노드에 RetryPolicy(max_attempts=3) 을 붙였는데 ValueError 를 물려받은 예외가 나도 시도 기록이 한 줄뿐이다. 원인은?

• max_attempts 는 추가 재시도 횟수라서 3 이면 네 번 시도한다
• 기본 retry_on 이 ValueError 계열을 다시 하지 않는 쪽으로 판정한다
• add_node 의 retry 인자는 비동기로 돌 때만 쓰인다
• 체크포인터를 주지 않으면 재시도 정책이 무시된다

max_attempts=3 인 정책 아래에서 일시 실패가 다섯 번 예정된 호출을 돌렸다. 무엇이 일어나는가?

• 시도가 다섯 번 일어난 뒤 성공한다
• 시도가 세 번 일어나고 재시도 정보가 담긴 새 예외가 올라온다
• 시도가 세 번 일어나고 마지막 예외가 그대로 올라온다
• 정책이 상한을 자동으로 늘려 성공할 때까지 반복한다

어떤 실패를 다시 해도 되는지 가르는 기준으로 이 실습이 내세우는 것은?

• 같은 요청을 그대로 다시 보내면 다른 답이 나올 가능성이 있는가
• 예외가 표준 라이브러리에서 온 것인가 우리가 만든 것인가
• 그 실패가 지난 한 주 동안 몇 번이나 일어났는가
• 그 호출이 그래프에서 몇 번째 노드에서 일어났는가

영구 실패에 넓은 retry_on 을 걸어 두었을 때 생기는 비용을 이 실습은 어떻게 확인하게 하는가?

• 재시도가 끝날 때까지 걸린 시간을 재어 견준다
• 예외 메시지에 붙은 재시도 표시를 읽는다
• 정책 객체의 max_interval 값을 계산해 본다
• 같은 실패를 두 정책으로 돌려 도구가 돈 횟수를 견준다

멱등 열쇠를 정할 때 옳은 것은?

• 받는 쪽이 요청마다 새로 만들어 붙인다
• 재시도할 때마다 새 값을 만들어 요청을 구분한다
• 보내는 쪽이 그 일 하나를 가리키는 값으로 정하고 재시도해도 같은 값을 쓴다
• 현재 시각을 밀리초까지 담아 충돌하지 않게 만든다

한 예산 안에서 여러 건을 처리하는데 뒷건들이 시도조차 되지 않았다. 가장 흔한 원인은?

• 예산을 건수가 아니라 호출 수로 세어서 계산이 틀렸다
• 앞 건들의 재시도가 호출을 먹어 남은 예산이 없어졌다
• 예산 초과 예외에도 재시도가 걸려 예산이 두 배로 줄었다
• 배치의 건 순서가 뒤집혀 뒤쪽이 먼저 처리됐다