시스템 간 연동 (EAI) · 오류 처리와 재처리 설계 · 퀴즈
퀴즈: 오류 처리와 재처리
문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
게이트웨이·서비스A·서비스B 가 각각 4회씩 재시도할 때 사용자 클릭 한 번이 최종 시스템에 만드는 최대 요청 수는?
- 4회 — 마지막 계층의 재시도만 최종 시스템에 닿는다
- 64회 — 4 × 4 × 4
- 12회 — 4 + 4 + 4
- 16회 — 4 × 4, 게이트웨이는 세지 않는다
지수 백오프에 지터(jitter)를 넣지 않으면 발생하는 문제는?
- 대기 시간이 계속 두 배로 늘어 마지막 재시도가 지나치게 늦어진다
- 간격 계산에 상한이 없어져 재시도가 사실상 무한히 이어진다
- 여러 클라이언트가 같은 순간에 재시도해 회복 중인 서버를 다시 쓰러뜨린다
- 대기 중인 요청 객체가 쌓여 클라이언트 메모리 사용량이 늘어난다
HTTP 429(Too Many Requests)를 받았을 때 올바른 대응은?
- 즉시 재시도한다
- 재시도하지 않고 즉시 DLQ 로 보낸다
- Retry-After 헤더를 존중해 그 시간 이후에 재시도한다
- 요청 크기를 줄여 재전송한다
DLQ 에 원본 메시지만 저장하고 사유·시도횟수·최초실패시각을 빠뜨리면 생기는 문제는?
- 같은 메시지가 여러 번 쌓이면서 저장 공간을 불필요하게 쓰게 된다
- 보관 기간을 판단할 근거가 없어 정리 배치가 메시지를 지워 버린다
- 재처리 대상이 계속 쌓여 원래 큐의 처리까지 밀리게 된다
- 나중에 재처리 여부를 판단할 근거가 없어 사실상 조용히 버린 것과 같아진다
멱등성(idempotency)을 가장 정확히 설명한 것은?
- 같은 요청에 항상 같은 응답을 반환하는 성질
- 같은 요청을 여러 번 처리해도 부수 효과가 한 번만 발생하는 성질
- 요청이 반드시 한 번만 전달되는 성질
- 요청을 순서대로 처리하는 성질
중복 방어를 `SELECT 로 조회 후 없으면 INSERT` 로 구현했을 때의 문제는?
- 조회와 삽입을 두 번 왕복하므로 처리량이 눈에 띄게 떨어진다
- 두 문장을 한 트랜잭션으로 묶을 수 없어 부분 실패가 남는다
- 조회 조건이 인덱스를 타지 못해 건수가 늘수록 급격히 느려진다
- 조회와 삽입 사이에 틈이 있어 동시에 두 건이 들어오면 둘 다 통과한다
멱등 이력 테이블의 보관 기간을 정할 때 기준으로 삼아야 할 것은?
- 디스크 용량
- 감사 로그 보존 기간과 동일하게
- 현실적으로 재전송이 들어올 수 있는 최대 기간보다 길게
- 테이블 행 수 상한