Quiz: Asynchronous Queue Integration

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

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

메시지 브로커에서 순서 보장에 대한 올바른 이해는?

• 토픽 전체에서 전역 순서가 보장된다
• 순서는 소비자 수에 따라 결정된다
• 타임스탬프로 정렬하면 항상 원래 순서가 복원된다
• 파티션(또는 큐) 안에서만 순서가 보장되므로, 순서가 중요한 단위를 파티션 키로 써야 한다

JSON 형식이 깨진 메시지를 재시도 로직에 태우면 발생하는 문제는?

• 재시도 중에 브로커가 원본을 다시 보내 주면서 저절로 복구된다
• 재시도 한도를 넘기면 브로커가 그 메시지를 자동으로 지워 준다
• 재시도할 때마다 파싱 객체가 쌓여 소비자 메모리가 늘어난다
• 그 메시지가 계속 실패하며 뒤의 정상 메시지 처리를 막는다

소비자에서 '업무 처리'와 '처리 이력 기록'을 같은 트랜잭션에 넣어야 하는 이유는?

• 한 번의 커밋으로 끝나 왕복이 줄고 처리량이 올라가기 때문에
• 두 작업을 묶으면 트랜잭션 로그에 한 번만 남아 크기가 줄기 때문에
• 따로 하면 '업무는 처리했는데 이력은 못 남긴' 상태가 생겨 재시도에서 중복되기 때문에
• 이력 테이블을 나중에 건드리면 잠금이 길어져 다른 소비자가 밀리기 때문에

디렉터리 기반 큐에서 inbox → processing 으로 mv 하는 방식이 동시 소비를 막아 주는 원리는?

• mv 를 실행할 때 커널이 대상 파일에 잠금을 자동으로 걸어 주기 때문에
• OS 가 같은 파일에 대한 요청을 도착 순서대로 하나씩 처리하기 때문에
• 이동과 동시에 파일 권한이 바뀌어 다른 프로세스가 열 수 없게 되기 때문에
• 같은 파일시스템 안에서 rename 은 원자적이라 성공한 프로세스만 그 메시지를 갖기 때문에

송신측이 파일을 다 쓰기 전에 소비자가 집어 가는 문제를 막는 표준적 방법은?

• 소비자 실행 주기를 넉넉히 잡아 전송이 끝날 시간을 벌어 준다
• 파일 크기를 미리 정해 두고 그 크기에 도달했을 때만 집어 간다
• 임시 이름으로 쓰고 다 쓰면 이름을 바꾸거나, 완료 플래그(.ok)를 함께 만든다
• 송신측이 압축해서 보내면 파일이 완성된 뒤에야 열리므로 문제가 없어진다

큐 적체(consumer lag) 경보를 '1000 건 초과' 같은 절대값보다 '10분 연속 증가' 로 거는 것이 나은 이유는?

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