개요

Message Queue(MQ)는 현대의 시스템 아키텍처에서 Producer와 Consumer로 논리적으로 나누어진 두 시스템의 메시지 전달을 위한 인터페이스를 구현한다. MQ Scheme에서 주의할 점은 참여자들은 서로에게 detached 되어 있다는 특징으로 인해 Producer에서 출발한 메시지가 무조건 Consumer에 도착한다는 보장은 없다는 점이다. 심지어 Producer에서 출발한 어떤 메시지는 MQ Broker 까지도 못가는 경우가 있을 수 있다. 이러한 약점을 보완하기 위해 여러 Delivery Semantics가 제시되었지만, 대부분의 IT 요소들이 그렇듯 정확도 및 사용성을 개선할 수록 성능 및 복잡도를 희생해야 한다. 오늘은 유명한 MQ 구현체인 Apache Kafka에서 제공하는 At Most Once, At Least Once 그리고 Exactly Once 총 세가지의 MQ Delivery Semantics에 대해 간단하게 알아보고 각 Semantics 마다 시스템 자원의 사용이 최적일 수 있는 상황을 제시할 것이다.

At Most Once

말 그대로 Producer가 딱 한번 메시지를 발송하는 상황을 말하는 것으로, 모든 메시지는 Consumer에게 무조건 최대 한번만 전달되는 것을 보장한다. 전송된 메시지가 중간에 소멸되거나 무결성이 훼손되더라도 Producer의 책임이 없다. 넓게 봤을 때 일방적으로 한번만 보내면 되는 방식으로 구현이 가능하기 때문에 Producer의 자원을 다른 전략에 비해 적게 사용하기 때문에 성능이 비교적 좋다는 장점이 있다.

이러한 특징으로 인해 At Most Once 전략은 소량의 데이터를 잃거나 변경되더라도 본연의 서비스 제공에 문제가 없는 모니터링이나 Metric 데이터를 수집에 사용하면 좋다.

At Least Once

Consumer가 메시지를 무조건 한번 이상 받는 것을 허용하지만, 그 과정에서 여러번 동일한 메시지를 받는 것 역시 허용한다. At Most Once에 비해 메시지 전달에 대한 신뢰도가 더 높지만, 중복된 메시지로 인한 오류를 제어해야 하기 때문에 성능 및 복잡도에 대한 추가적인 고려가 필요하다.

만약 MQ를 사용하는 시스템이 중복 요청으로 인한 오류 방지가 사전에 잘 되어 있거나 그렇지 않더라도 서비스 제공에 큰 문제가 없는 상황이라면 At Least Once는 At Most Once에 비해 좀 더 신뢰도 높은 시스템을 설계할 수 있도록 도와준다. 추가적으로 Consumer 시스템에서 메시지를 수신하는 모듈이 멱등성을 지원하고 각 메시지가 유일성을 식별할 수 있는 구조로 설계되어 있다면 사실 상 아래에서 소개할 Exactly Once 전략을 쓰는 것과 같은 효과를 볼 수 있다.

Exactly Once

하나의 메시지가 Producer부터 Broker, Consumer까지 단 한번만 수신되는 것을 보장하는 전달 전략이다. 유저 사용성이 제일 좋은 전략이지만, 전체적인 시스템의 성능 및 복잡도를 고려하면 구현하기 위한 비용이 매우 크다.

이 전략은 신뢰도가 매우 중요한 도메인, 요컨대 금융이나 회계 등에서 사용하는 전략으로, MQ 인터페이스로 논리적으로 연결된 두 시스템이 Exactly Once에 대한 지원이나 구현이 없어도 정확하게 한번만 특정 메시지를 보낼 수 있도록 지원한다. 설계 및 구현 단계에서 큰 비용이 소모되지만, 도입에 성공하면 추후 MQ에 연결할 다른 시스템은 메시지 송수신 신뢰도에 대한 고려를 하지 않아도 되며, 제 3자 솔루션이 멱등성을 보장하지 않아도 MQ가 정확하게 동작할 것을 보장할 수 있다.

참고할 만한 자료

https://blog.bytebytego.com/p/at-most-once-at-least-once-exactly