LabHub

시스템 간 연동 (EAI) · 오류 처리와 재처리 설계 · 퀴즈

퀴즈: 오류 처리와 재처리

LabHub 에서 이어서 보기

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. 게이트웨이·서비스A·서비스B 가 각각 4회씩 재시도할 때 사용자 클릭 한 번이 최종 시스템에 만드는 최대 요청 수는?

    1. 4회 — 마지막 계층의 재시도만 최종 시스템에 닿는다
    2. 64회 — 4 × 4 × 4
    3. 12회 — 4 + 4 + 4
    4. 16회 — 4 × 4, 게이트웨이는 세지 않는다
  2. 지수 백오프에 지터(jitter)를 넣지 않으면 발생하는 문제는?

    1. 대기 시간이 계속 두 배로 늘어 마지막 재시도가 지나치게 늦어진다
    2. 간격 계산에 상한이 없어져 재시도가 사실상 무한히 이어진다
    3. 여러 클라이언트가 같은 순간에 재시도해 회복 중인 서버를 다시 쓰러뜨린다
    4. 대기 중인 요청 객체가 쌓여 클라이언트 메모리 사용량이 늘어난다
  3. HTTP 429(Too Many Requests)를 받았을 때 올바른 대응은?

    1. 즉시 재시도한다
    2. 재시도하지 않고 즉시 DLQ 로 보낸다
    3. Retry-After 헤더를 존중해 그 시간 이후에 재시도한다
    4. 요청 크기를 줄여 재전송한다
  4. DLQ 에 원본 메시지만 저장하고 사유·시도횟수·최초실패시각을 빠뜨리면 생기는 문제는?

    1. 같은 메시지가 여러 번 쌓이면서 저장 공간을 불필요하게 쓰게 된다
    2. 보관 기간을 판단할 근거가 없어 정리 배치가 메시지를 지워 버린다
    3. 재처리 대상이 계속 쌓여 원래 큐의 처리까지 밀리게 된다
    4. 나중에 재처리 여부를 판단할 근거가 없어 사실상 조용히 버린 것과 같아진다
  5. 멱등성(idempotency)을 가장 정확히 설명한 것은?

    1. 같은 요청에 항상 같은 응답을 반환하는 성질
    2. 같은 요청을 여러 번 처리해도 부수 효과가 한 번만 발생하는 성질
    3. 요청이 반드시 한 번만 전달되는 성질
    4. 요청을 순서대로 처리하는 성질
  6. 중복 방어를 `SELECT 로 조회 후 없으면 INSERT` 로 구현했을 때의 문제는?

    1. 조회와 삽입을 두 번 왕복하므로 처리량이 눈에 띄게 떨어진다
    2. 두 문장을 한 트랜잭션으로 묶을 수 없어 부분 실패가 남는다
    3. 조회 조건이 인덱스를 타지 못해 건수가 늘수록 급격히 느려진다
    4. 조회와 삽입 사이에 틈이 있어 동시에 두 건이 들어오면 둘 다 통과한다
  7. 멱등 이력 테이블의 보관 기간을 정할 때 기준으로 삼아야 할 것은?

    1. 디스크 용량
    2. 감사 로그 보존 기간과 동일하게
    3. 현실적으로 재전송이 들어올 수 있는 최대 기간보다 길게
    4. 테이블 행 수 상한