LabHub

시스템 간 연동 (EAI) · 비동기 큐 연동과 재처리 · 퀴즈

퀴즈: 비동기 큐 연동

LabHub 에서 이어서 보기

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

  1. 'exactly-once(정확히 한 번)' 를 가장 정확하게 설명한 것은?

    1. '적어도 한 번 전달' 과 '수신측의 중복 제거' 를 합쳐 결과적으로 한 번 처리된 것처럼 보이게 하는 것
    2. 브로커가 메시지를 한 번만 전달하도록 보장하는 기능
    3. 네트워크가 안정적일 때만 성립하는 전달 방식
    4. 메시지를 동기로 전송하면 자동으로 달성된다
  2. 메시지 브로커에서 순서 보장에 대한 올바른 이해는?

    1. 토픽 전체에서 전역 순서가 보장된다
    2. 순서는 소비자 수에 따라 결정된다
    3. 타임스탬프로 정렬하면 항상 원래 순서가 복원된다
    4. 파티션(또는 큐) 안에서만 순서가 보장되므로, 순서가 중요한 단위를 파티션 키로 써야 한다
  3. JSON 형식이 깨진 메시지를 재시도 로직에 태우면 발생하는 문제는?

    1. 재시도 중에 브로커가 원본을 다시 보내 주면서 저절로 복구된다
    2. 재시도 한도를 넘기면 브로커가 그 메시지를 자동으로 지워 준다
    3. 재시도할 때마다 파싱 객체가 쌓여 소비자 메모리가 늘어난다
    4. 그 메시지가 계속 실패하며 뒤의 정상 메시지 처리를 막는다
  4. 소비자에서 '업무 처리'와 '처리 이력 기록'을 같은 트랜잭션에 넣어야 하는 이유는?

    1. 한 번의 커밋으로 끝나 왕복이 줄고 처리량이 올라가기 때문에
    2. 두 작업을 묶으면 트랜잭션 로그에 한 번만 남아 크기가 줄기 때문에
    3. 따로 하면 '업무는 처리했는데 이력은 못 남긴' 상태가 생겨 재시도에서 중복되기 때문에
    4. 이력 테이블을 나중에 건드리면 잠금이 길어져 다른 소비자가 밀리기 때문에
  5. 디렉터리 기반 큐에서 `inbox → processing` 으로 `mv` 하는 방식이 동시 소비를 막아 주는 원리는?

    1. mv 를 실행할 때 커널이 대상 파일에 잠금을 자동으로 걸어 주기 때문에
    2. OS 가 같은 파일에 대한 요청을 도착 순서대로 하나씩 처리하기 때문에
    3. 이동과 동시에 파일 권한이 바뀌어 다른 프로세스가 열 수 없게 되기 때문에
    4. 같은 파일시스템 안에서 rename 은 원자적이라 성공한 프로세스만 그 메시지를 갖기 때문에
  6. 송신측이 파일을 다 쓰기 전에 소비자가 집어 가는 문제를 막는 표준적 방법은?

    1. 소비자 실행 주기를 넉넉히 잡아 전송이 끝날 시간을 벌어 준다
    2. 파일 크기를 미리 정해 두고 그 크기에 도달했을 때만 집어 간다
    3. 임시 이름으로 쓰고 다 쓰면 이름을 바꾸거나, 완료 플래그(.ok)를 함께 만든다
    4. 송신측이 압축해서 보내면 파일이 완성된 뒤에야 열리므로 문제가 없어진다
  7. 큐 적체(consumer lag) 경보를 '1000 건 초과' 같은 절대값보다 '10분 연속 증가' 로 거는 것이 나은 이유는?

    1. 배치성 유입이 있으면 순간 적체가 큰 것이 정상이라, 추세가 이상을 더 잘 나타내서
    2. 절대값 기준은 파티션 수가 바뀔 때마다 다시 계산해야 해서 관리가 어려워서
    3. 임계 초과 경보가 자주 울리면 경보 시스템 자체의 부하가 커지기 때문에
    4. 브로커가 보고하는 적체 수치는 오차가 커서 절대값으로 쓰기 어렵기 때문에