M

MLOG

한국어

메시지 순서를 보장하는 메시지 큐 설계에 대한 종합 가이드. 다양한 전략, 장단점, 글로벌 애플리케이션을 위한 실용적인 고려 사항을 살펴봅니다.

메시지 큐 설계: 메시지 순서 보장하기

메시지 큐는 현대 분산 시스템의 기본 구성 요소로, 서비스 간의 비동기 통신을 가능하게 하고 확장성을 개선하며 복원력을 향상시킵니다. 그러나 메시지가 전송된 순서대로 처리되도록 보장하는 것은 많은 애플리케이션에서 중요한 요구 사항입니다. 이 블로그 게시물에서는 분산 메시지 큐에서 메시지 순서를 유지하는 것의 어려움을 살펴보고 다양한 설계 전략과 장단점에 대한 포괄적인 가이드를 제공합니다.

메시지 순서가 중요한 이유

메시지 순서는 이벤트의 순서가 데이터 일관성 및 애플리케이션 로직을 유지하는 데 중요한 시나리오에서 매우 중요합니다. 다음 예시를 고려해 보세요:

메시지 순서를 유지하지 못하면 데이터 손상, 부정확한 애플리케이션 상태 및 사용자 경험 저하로 이어질 수 있습니다. 따라서 메시지 큐 설계 중에 메시지 순서 보장을 신중하게 고려하는 것이 필수적입니다.

메시지 순서 유지의 어려움

분산 메시지 큐에서 메시지 순서를 유지하는 것은 여러 요인으로 인해 어렵습니다:

메시지 순서 보장 전략

분산 메시지 큐에서 메시지 순서를 보장하기 위해 여러 전략을 사용할 수 있습니다. 각 전략은 성능, 확장성 및 복잡성 측면에서 고유한 장단점을 가집니다.

1. 단일 큐, 단일 컨슈머

가장 간단한 접근 방식은 단일 큐와 단일 컨슈머를 사용하는 것입니다. 이는 메시지가 수신된 순서대로 처리될 것을 보장합니다. 그러나 이 접근 방식은 한 번에 하나의 컨슈머만 메시지를 처리할 수 있으므로 확장성과 처리량을 제한합니다. 이 접근 방식은 소규모 금융 기관의 전신 송금을 한 번에 하나씩 처리하는 것과 같이 처리량이 적고 순서가 중요한 시나리오에 적합합니다.

장점:

단점:

2. 순서 지정 키를 사용한 파티셔닝

보다 확장 가능한 접근 방식은 순서 지정 키를 기반으로 큐를 파티셔닝하는 것입니다. 동일한 순서 지정 키를 가진 메시지는 동일한 파티션으로 전달되는 것이 보장되며, 컨슈머는 각 파티션 내에서 순서대로 메시지를 처리합니다. 일반적인 순서 지정 키는 사용자 ID, 주문 ID 또는 계좌 번호가 될 수 있습니다. 이를 통해 각 키 내에서 순서를 유지하면서 서로 다른 순서 지정 키를 가진 메시지를 병렬로 처리할 수 있습니다.

예시:

특정 주문과 관련된 메시지를 순서대로 처리해야 하는 전자 상거래 플랫폼을 생각해 보세요. 주문 ID를 순서 지정 키로 사용할 수 있습니다. 주문 ID 123과 관련된 모든 메시지(예: 주문 접수, 결제 확인, 배송 업데이트)는 동일한 파티션으로 라우팅되어 순서대로 처리됩니다. 다른 주문 ID(예: 주문 ID 456)와 관련된 메시지는 다른 파티션에서 동시에 처리될 수 있습니다.

Apache Kafka 및 Apache Pulsar와 같은 인기 있는 메시지 큐 시스템은 순서 지정 키를 사용한 파티셔닝을 기본적으로 지원합니다.

장점:

단점:

3. 시퀀스 번호

또 다른 접근 방식은 메시지에 시퀀스 번호를 할당하고 컨슈머가 시퀀스 번호 순서대로 메시지를 처리하도록 하는 것입니다. 이는 순서에 맞지 않게 도착한 메시지를 버퍼링하고 이전 메시지가 처리되었을 때 해제함으로써 달성할 수 있습니다. 이를 위해서는 누락된 메시지를 감지하고 재전송을 요청하는 메커니즘이 필요합니다.

예시:

분산 로깅 시스템은 여러 서버에서 로그 메시지를 수신합니다. 각 서버는 로그 메시지에 시퀀스 번호를 할당합니다. 로그 수집기는 메시지를 버퍼링하고 시퀀스 번호 순서대로 처리하여 네트워크 지연으로 인해 순서에 맞지 않게 도착하더라도 로그 이벤트가 올바르게 정렬되도록 보장합니다.

장점:

단점:

4. 멱등성 컨슈머

멱등성은 초기 적용을 넘어서 결과를 변경하지 않고 여러 번 적용할 수 있는 작업의 속성입니다. 컨슈머가 멱등성을 갖도록 설계되면 불일치를 유발하지 않고 안전하게 메시지를 여러 번 처리할 수 있습니다. 이는 메시지가 최소 한 번은 전달되지만 두 번 이상 전달될 수 있는 '최소 한 번 전달(at-least-once delivery)' 의미론을 허용합니다. 이것이 엄격한 순서를 보장하지는 않지만, 메시지가 처음에 순서에 맞지 않게 도착하더라도 최종적 일관성을 보장하기 위해 시퀀스 번호와 같은 다른 기술과 결합될 수 있습니다.

예시:

결제 처리 시스템에서 컨슈머는 결제 확인 메시지를 받습니다. 컨슈머는 데이터베이스를 쿼리하여 결제가 이미 처리되었는지 확인합니다. 결제가 이미 처리된 경우 컨슈머는 메시지를 무시합니다. 그렇지 않으면 결제를 처리하고 데이터베이스를 업데이트합니다. 이렇게 하면 동일한 결제 확인 메시지가 여러 번 수신되더라도 결제는 한 번만 처리됩니다.

장점:

단점:

5. 트랜잭셔널 아웃박스 패턴

트랜잭셔널 아웃박스 패턴은 데이터베이스 트랜잭션의 일부로 메시지가 메시지 큐에 안정적으로 게시되도록 보장하는 디자인 패턴입니다. 이는 데이터베이스 트랜잭션이 성공하는 경우에만 메시지가 게시되고, 애플리케이션이 메시지를 게시하기 전에 충돌하더라도 메시지가 손실되지 않도록 보장합니다. 주로 안정적인 메시지 전달에 초점을 맞추지만, 특정 엔티티와 관련된 메시지의 순서 있는 전달을 보장하기 위해 파티셔닝과 함께 사용될 수 있습니다.

작동 방식:

  1. 애플리케이션이 데이터베이스를 업데이트하고 메시지를 게시해야 할 때, 데이터 업데이트와 동일한 데이터베이스 트랜잭션 내에서 "아웃박스" 테이블에 메시지를 삽입합니다.
  2. 별도의 프로세스(예: 데이터베이스 트랜잭션 로그 테일러 또는 스케줄된 작업)가 아웃박스 테이블을 모니터링합니다.
  3. 이 프로세스는 아웃박스 테이블에서 메시지를 읽어 메시지 큐에 게시합니다.
  4. 메시지가 성공적으로 게시되면, 프로세스는 아웃박스 테이블에서 해당 메시지를 전송됨으로 표시하거나 삭제합니다.

예시:

새로운 고객 주문이 접수되면, 애플리케이션은 `orders` 테이블에 주문 세부 정보를 삽입하고, 동일한 데이터베이스 트랜잭션 내에서 `outbox` 테이블에 해당 메시지를 삽입합니다. `outbox` 테이블의 메시지에는 새 주문에 대한 정보가 포함됩니다. 별도의 프로세스가 이 메시지를 읽어 `new_orders` 큐에 게시합니다. 이렇게 하면 주문이 데이터베이스에 성공적으로 생성된 경우에만 메시지가 게시되고, 애플리케이션이 게시하기 전에 충돌하더라도 메시지가 손실되지 않도록 보장합니다. 또한, 메시지 큐에 게시할 때 고객 ID를 파티션 키로 사용하면 해당 고객과 관련된 모든 메시지가 순서대로 처리되도록 보장합니다.

장점:

단점:

올바른 전략 선택하기

메시지 순서를 보장하기 위한 최상의 전략은 애플리케이션의 특정 요구 사항에 따라 달라집니다. 다음 요소를 고려하세요:

올바른 전략을 선택하는 데 도움이 되는 결정 가이드는 다음과 같습니다:

메시지 큐 시스템 고려 사항

다양한 메시지 큐 시스템은 메시지 순서에 대해 다양한 수준의 지원을 제공합니다. 메시지 큐 시스템을 선택할 때 다음을 고려하세요:

일부 인기 있는 메시지 큐 시스템의 순서 보장 기능에 대한 간략한 개요는 다음과 같습니다:

실용적인 고려 사항

올바른 전략과 메시지 큐 시스템을 선택하는 것 외에도 다음과 같은 실용적인 고려 사항을 고려하세요:

결론

분산 메시지 큐에서 메시지 순서를 보장하는 것은 다양한 요소를 신중하게 고려해야 하는 복잡한 과제입니다. 이 블로그 게시물에서 설명한 다양한 전략, 장단점 및 실용적인 고려 사항을 이해함으로써 애플리케이션의 순서 요구 사항을 충족하고 데이터 일관성과 긍정적인 사용자 경험을 보장하는 메시지 큐 시스템을 설계할 수 있습니다. 애플리케이션의 특정 요구에 따라 올바른 전략을 선택하고, 시스템이 순서 요구 사항을 충족하는지 철저히 테스트하는 것을 잊지 마세요. 시스템이 발전함에 따라 변화하는 요구 사항에 적응하고 최적의 성능과 안정성을 보장하기 위해 메시지 큐 설계를 지속적으로 모니터링하고 개선하세요.

메시지 큐 설계: 메시지 순서 보장하기 | MLOG