Kafka와 RabbitMQ 선택 기준

메시지를 흐름으로 다루는지, 작업으로 다루는지로 갈립니다.

선택 기준입니다.

흔한 실수: 처리량만 보고 고르는 것. 대부분의 서비스는 어느 쪽으로도 충분합니다. 재처리가 필요한지, 라우팅이 복잡한지가 실제 판단을 가르는 지점입니다.

Kafka 는 메시지를 지우지 않고 로그에 남겨 두고, 소비자는 자기가 어디까지 읽었는지를 기록만 합니다.

그래서 오프셋을 되돌리면 그 지점부터 다시 읽습니다. 일반 큐는 소비 시점에 메시지를 제거하므로 이것이 불가능합니다.

두 번째가 특히 유용합니다. 새 집계 서비스를 만들 때 과거 이벤트를 처음부터 읽어 현재 상태를 구성할 수 있습니다.

흔한 실수: 재처리를 무제한으로 여기는 것. 보관 기간이 지나면 삭제되므로 그 이전 데이터는 없습니다. 재처리를 전제한다면 보관 기간을 그만큼 길게 잡아야 합니다.

Kafka 는 순서 있는 로그라서, 개별 작업을 따로 다루는 일이 어렵습니다.

두 번째가 가장 아픕니다. 작업 큐에서는 하나가 실패해도 다른 작업은 계속 처리돼야 하는데, Kafka 는 순서를 지키므로 그 메시지를 넘기지 않으면 뒤가 멈춥니다.

우회 방법은 있습니다.

우회가 많아지면 그것이 신호입니다. 작업 큐가 필요한 것이면 작업 큐를 쓰는 편이 낫습니다.

흔한 실수: 이미 Kafka 가 있으니 작업 큐도 그것으로 처리하는 것. 운영 대상을 하나로 유지하는 이점이 있지만, 위 우회들을 직접 구현하는 비용이 그것을 넘는 경우가 많습니다.

큐 하나에 소비자가 하나이고 재시도가 없을 때만 순서가 지켜집니다. 그 조건이 깨지는 경우들입니다.

첫 번째와 두 번째가 흔합니다. 처리량을 올리려고 소비자를 늘리거나 미리 받는 개수를 키우는 것이 순서를 포기하는 선택임을 놓치기 쉽습니다.

세 번째도 실무에서 자주 봅니다. 실패한 메시지를 되돌려 넣으면 그 뒤에 온 메시지들이 이미 처리된 상태입니다.

순서를 지켜야 한다면 이렇게 합니다.

흔한 실수: 큐가 FIFO 라서 순서가 보장된다고 답하는 것. 큐에 들어가는 순서는 지켜지지만 처리 완료 순서는 소비자 구성에 달려 있습니다.