분산 시스템 면접 질문

분산 시스템은 여러 대의 컴퓨터가 네트워크를 통해 연결되어 하나의 시스템처럼 동작하는 것을 말합니다. 단일 시스템과 비교했을 때 몇 가지 중요한 장점이 있습니다.

첫째, 확장성이 뛰어납니다. 트래픽 증가에 따라 서버를 추가하여 성능을 쉽게 확장할 수 있습니다.

둘째, 고가용성을 확보할 수 있습니다. 한 서버에 장애가 발생해도 다른 서버들이 역할을 대신하여 서비스 중단을 최소화할 수 있습니다.

셋째, 내결함성이 높습니다. 일부 서버에 문제가 생겨도 전체 시스템은 계속 작동할 수 있도록 설계할 수 있습니다.

마지막으로, 작업을 여러 서버에 분산하여 병렬 처리함으로써 전체 처리량을 향상시킬 수 있습니다. 이러한 장점 덕분에 대규모 서비스나 복잡한 연산에 분산 시스템이 널리 사용됩니다.

CAP 이론은 분산 시스템이 동시에 만족할 수 없는 세 가지 속성, 즉 일관성(Consistency), 가용성(Availability), 그리고 파티션 내성(Partition Tolerance)을 설명하는 이론입니다.

일관성은 모든 노드가 항상 최신 데이터를 읽을 수 있음을 의미합니다. 가용성은 시스템이 요청에 응답할 수 있음을 의미하며, 파티션 내성은 네트워크 분할이 발생해도 시스템이 계속 작동함을 의미합니다.

분산 시스템에서는 네트워크 장애로 인해 파티션이 발생할 가능성이 높으므로, 파티션 내성은 필수적으로 고려해야 합니다. 따라서 시스템 설계 시에는 일관성과 가용성 중 하나를 선택해야 합니다. 예를 들어, 일관성을 우선시하는 시스템은 파티션 발생 시 일부 요청에 응답하지 않을 수 있고, 가용성을 우선시하는 시스템은 파티션 발생 시 일관성이 깨진 데이터를 반환할 수도 있습니다.

분산 시스템에서 데이터 복제가 필요한 주요 이유는 크게 세 가지입니다.

첫째, 가용성을 높이기 위해서입니다. 데이터를 여러 곳에 복제해두면, 일부 서버에 장애가 발생하더라도 다른 서버에서 데이터를 계속 제공할 수 있습니다.

둘째, 내결함성을 확보하기 위해서입니다. 데이터 손실을 방지하고 시스템이 예상치 못한 오류에도 안정적으로 작동하도록 돕습니다.

셋째, 성능 향상을 위해서입니다. 사용자와 가까운 곳에 데이터를 복제해두면 읽기 요청에 대한 응답 시간을 줄일 수 있습니다. 예를 들어, 전 세계 사용자를 대상으로 하는 서비스라면 각 지역에 데이터 복제본을 두어 사용자 경험을 개선할 수 있습니다.

물론 데이터 복제는 데이터 일관성 유지라는 과제를 동반하지만, 시스템의 안정성과 성능을 높이는 데 필수적인 기술입니다.

로드 밸런싱은 분산 시스템에서 서버에 가해지는 부하를 분산시켜 시스템의 가용성과 응답 시간을 향상시키는 중요한 역할을 합니다. 트래픽을 여러 서버에 균등하게 분배함으로써 특정 서버에 과부하가 걸리는 것을 방지하고, 전체 시스템의 안정성을 높입니다.

가장 기본적인 로드 밸런싱 알고리즘으로는 다음과 같은 것들이 있습니다.

• 라운드 로빈(Round Robin): 서버들을 순차적으로 돌아가면서 요청을 할당하는 방식입니다. 구현이 간단하지만, 서버의 성능 차이를 고려하지 못한다는 단점이 있습니다.

• 최소 연결 방식(Least Connections): 현재 연결 수가 가장 적은 서버에 요청을 할당하는 방식입니다. 서버의 현재 부하를 고려하여 분배하므로 라운드 로빈보다 효율적일 수 있습니다.

• 가중치 방식(Weighted): 서버의 성능에 따라 가중치를 부여하여 요청을 분배하는 방식입니다. 성능이 좋은 서버에는 더 많은 요청을 할당할 수 있습니다.

분산 시스템에서 서비스 디스커버리는 서비스들이 서로를 찾고 통신할 수 있게 해주는 핵심적인 메커니즘입니다. 왜냐하면 분산 환경에서는 서비스 인스턴스의 IP 주소나 포트가 동적으로 변할 수 있기 때문입니다.

서비스 디스커버리가 없으면, 각 서비스는 다른 서비스의 정확한 위치를 미리 알 수 없어서 통신이 불가능해집니다. 서비스 디스커버리는 서비스가 시작될 때 자신의 정보를 등록하고, 다른 서비스가 필요할 때 등록된 정보를 검색하여 통신할 수 있도록 해줍니다.

이를 통해 로드 밸런싱, 장애 극복, 그리고 시스템의 확장성을 높일 수 있습니다. 예를 들어, 서비스 A가 서비스 B를 호출할 때, 서비스 디스커버리를 통해 서비스 B의 여러 인스턴스 중 하나를 선택하여 요청을 보낼 수 있습니다. 또한, 헬스 체크 기능을 통해 비정상적인 인스턴스를 자동으로 제외하고 정상적인 인스턴스만 연결해줄 수 있습니다.

분산 시스템의 확장성이란, 시스템이 증가하는 사용자 요청이나 데이터 처리량과 같은 부하를 얼마나 잘 감당할 수 있는지를 의미합니다. 즉, 시스템이 성능 저하 없이 더 많은 작업을 처리할 수 있는 능력을 말합니다.

확장성에는 크게 두 가지 방법이 있습니다. 첫 번째는 수평 확장(Horizontal Scaling)으로, 기존 서버에 더 많은 서버를 추가하여 부하를 분산시키는 방식입니다. 마치 여러 대의 작은 트럭으로 짐을 옮기는 것과 같습니다. 이 방식은 유연하고 비용 효율적이며, 단일 실패 지점을 줄여 탄력성을 높이는 데 유리합니다.

두 번째는 수직 확장(Vertical Scaling)으로, 기존 서버의 성능을 향상시키는 방식입니다. CPU를 더 좋은 것으로 교체하거나 메모리를 늘리는 것처럼, 단일 서버의 사양을 높이는 것입니다. 이는 마치 더 크고 강력한 트럭 한 대로 짐을 옮기는 것과 같습니다. 수직 확장은 구현이 비교적 간단할 수 있지만, 하드웨어 업그레이드에는 물리적인 한계와 비용이 따릅니다.

분산 트랜잭션은 여러 데이터베이스나 시스템에 걸쳐 수행되는 트랜잭션입니다. ACID 속성 중 특히 원자성을 보장하는 것이 중요하며, 모든 참여자가 트랜잭션을 커밋하거나 롤백해야 합니다.

2단계 커밋(2PC)은 이를 위한 대표적인 프로토콜입니다. 기본적으로 트랜잭션 코디네이터라는 중재자가 참여합니다.

1단계(준비 페이즈)에서는 코디네이터가 모든 참여자에게 트랜잭션 준비를 요청합니다. 각 참여자는 트랜잭션을 수행할 준비를 마치고 결과를 코디네이터에게 알립니다.

2단계(커밋 페이즈)에서는 코디네이터가 모든 참여자가 준비되었다면 커밋을 요청하고, 하나라도 실패했다면 롤백을 요청합니다. 모든 참여자는 코디네이터의 결정에 따라 트랜잭션을 커밋하거나 롤백합니다.

CAP 이론은 분산 시스템 설계 시 일관성, 가용성, 분할 내성 중 최대 두 가지만 만족할 수 있다는 이론입니다. 분할 내성은 필수적이므로, 결국 일관성과 가용성 사이의 트레이드오프가 발생합니다.

예를 들어, 은행 계좌 시스템을 생각해 봅시다. 네트워크 분할이 발생했을 때, 일관성을 선택하면 (CP) 분할된 네트워크 중 한쪽에서는 계좌 업데이트를 막아 데이터 불일치를 방지할 수 있습니다. 하지만 이 경우 해당 네트워크에서는 계좌 잔액 확인이나 이체 등의 가용성이 떨어지게 됩니다.

반대로 가용성을 선택하면 (AP) 분할된 네트워크 양쪽에서 계좌 업데이트가 가능하도록 허용할 수 있습니다. 이 경우 네트워크가 다시 연결되었을 때 데이터 충돌이 발생할 수 있으며, 데이터 일관성을 보장하기 위한 추가적인 메커니즘이 필요합니다. NoSQL 데이터베이스 중 일부는 이러한 AP 전략을 채택하여 높은 가용성을 확보합니다.

분산 시스템에서 강한 일관성과 결과적 일관성의 가장 큰 차이는 데이터의 최신성 보장 여부입니다.

강한 일관성은 모든 노드에서 항상 최신 데이터를 보장합니다. 즉, 어떤 노드에서 데이터를 읽든 항상 가장 최근에 쓰여진 값을 얻게 됩니다. 이는 ACID 트랜잭션과 유사하며, 금융 거래나 재고 관리처럼 데이터 정합성이 매우 중요한 애플리케이션에 적합합니다. 하지만 모든 노드의 동기화가 필요하기 때문에 성능 저하와 가용성 문제가 발생할 수 있습니다.

반면 결과적 일관성은 데이터가 결국에는 일관성을 갖게 되지만, 특정 시점에는 노드 간 데이터 불일치가 발생할 수 있습니다. 이는 BASE 원칙과 관련 있으며, 소셜 미디어 피드나 추천 시스템처럼 실시간 최신성이 크게 중요하지 않고 높은 가용성과 성능이 우선시되는 애플리케이션에 적합합니다. 데이터 불일치 기간이 존재한다는 단점이 있습니다.

CAP 이론 관점에서 보면, 강한 일관성은 일관성(Consistency)과 가용성(Availability)을 동시에 만족시키기 어렵고, 결과적 일관성은 가용성을 높이는 대신 일관성을 일부 포기하는 경향이 있습니다.

분산 트랜잭션을 처리하는 2단계 커밋(2PC)은 여러 참여 노드에 걸쳐 트랜잭션의 ACID 속성을 보장하는 프로토콜입니다. 먼저, 트랜잭션 매니저가 모든 참여자에게 준비(Prepare) 요청을 보내고, 각 참여자는 트랜잭션을 준비하고 결과를 응답합니다. 모든 참여자가 준비에 성공하면 커밋(Commit) 요청을 보내 트랜잭션을 완료하고, 하나라도 실패하면 롤백(Rollback) 요청을 보냅니다.

2PC는 단순하지만 단일 장애점과 블로킹 문제가 있습니다. 트랜잭션 매니저가 다운되면 전체 시스템이 멈출 수 있고, 특정 참여자가 응답하지 않으면 다른 참여자들도 무한정 기다려야 합니다.

이러한 단점을 보완하기 위해 Saga 패턴을 사용할 수 있습니다. Saga 패턴은 각 서비스가 로컬 트랜잭션을 수행하고, 실패 시 보상 트랜잭션을 통해 롤백하는 방식으로 분산 트랜잭션을 관리합니다. 2PC와 달리 모든 참여자가 동시에 합의할 필요가 없어 가용성이 높지만, 데이터 정합성을 완벽하게 보장하기는 어렵습니다.

분산 메시징 시스템에서 멱등성은 메시지가 여러 번 전달되더라도 시스템 상태가 한 번 처리된 것과 동일하게 유지되도록 보장하는 중요한 속성입니다. 네트워크 오류나 시스템 장애로 인해 메시지가 중복 전달될 수 있는데, 멱등성이 없으면 동일한 메시지가 여러 번 처리되어 데이터 불일치나 예상치 못한 부작용이 발생할 수 있습니다.

멱등성을 보장하는 일반적인 방법으로는 고유한 메시지 ID를 사용하는 것입니다. 메시지를 처리할 때마다 해당 메시지 ID가 이미 처리되었는지 데이터베이스나 캐시 등을 통해 확인하고, 이미 처리된 메시지라면 무시하는 방식입니다. 예를 들어, 주문 생성 메시지에 고유한 order_id가 있다면, 해당 order_id로 이미 주문이 생성되었는지 확인하고 중복 생성을 방지할 수 있습니다. 또 다른 방법은 상태 기반 연산을 사용하는 것입니다. 예를 들어, 특정 상태로 업데이트하는 연산은 여러 번 수행해도 결과가 동일하므로 멱등성을 가집니다.

분산 시스템에서 합의 알고리즘은 여러 서버가 장애가 발생하더라도 데이터 일관성을 유지하고, 단일한 결정에 도달하도록 보장하는 데 필수적입니다. 만약 합의 알고리즘이 없다면, 각 서버가 서로 다른 정보를 가질 수 있고, 이는 데이터 불일치와 시스템 오류로 이어질 수 있습니다.

Paxos나 Raft 같은 알고리즘은 분산된 환경에서 특정 값에 대해 합의를 이룹니다. Raft를 예로 들면, 리더 선출을 통해 하나의 리더를 선출하고, 이 리더가 로그를 복제하여 다른 서버들에게 전파합니다. 만약 리더에 문제가 생기면 새로운 리더를 선출하여 시스템이 계속 작동하도록 합니다. 이러한 과정을 통해 Raft는 모든 서버가 동일한 로그를 갖도록 보장하며, 이는 데이터 일관성을 유지하는 핵심적인 역할을 합니다.

라운드 로빈과 최소 연결 방식은 분산 시스템에서 트래픽을 분산하는 대표적인 로드 밸런싱 알고리즘입니다.

라운드 로빈은 요청을 서버에 순서대로 할당하는 가장 단순한 방식입니다. 구현이 간단하고 균등하게 트래픽을 분산한다는 장점이 있지만, 서버의 성능 차이를 고려하지 못한다는 단점이 있습니다. 만약 서버 성능이 다르다면, 성능이 낮은 서버에 과부하가 걸릴 수 있습니다.

최소 연결 방식은 현재 연결 수가 가장 적은 서버에 요청을 할당합니다. 서버의 현재 부하를 고려하여 트래픽을 분산하기 때문에, 서버 성능이 다르거나 요청 처리 시간이 불균등한 경우에 더 효과적입니다. 하지만 연결 수를 추적해야 하므로 라운드 로빈보다 복잡도가 높고, 세션 유지(sticky session)가 필요한 경우 추가적인 고려가 필요할 수 있습니다.

따라서, 서버 성능이 비슷하고 요청 처리 시간이 균등하다면 라운드 로빈이 적합하고, 서버 성능이 다르거나 요청 처리 시간이 불균등하다면 최소 연결 방식이 더 적합합니다.

마이크로서비스 아키텍처에서는 서비스 인스턴스가 동적으로 생성되고 소멸되기 때문에, 각 서비스의 IP 주소와 포트가 계속 변합니다. 서비스 디스커버리는 이러한 변화에 맞춰 서비스들이 서로를 찾아 통신할 수 있도록 해주는 핵심 메커니즘입니다.

클라이언트 측 디스커버리는 클라이언트가 서비스 레지스트리에서 직접 서비스 인스턴스 목록을 조회하고, 로드 밸런싱을 수행하여 통신합니다. 장점은 유연성이 높고, 클라이언트가 로드 밸런싱 전략을 직접 제어할 수 있다는 점입니다. 단점은 클라이언트에 디스커버리 로직이 추가되어 복잡성이 증가하고, 각 언어별로 구현해야 한다는 점입니다.

서버 측 디스커버리는 로드 밸런서가 서비스 레지스트리에서 서비스 인스턴스 목록을 조회하고, 클라이언트 요청을 적절한 인스턴스로 라우팅합니다. 장점은 클라이언트가 디스커버리 로직을 알 필요가 없어 단순해지고, 중앙 집중적인 관리가 가능하다는 점입니다. 단점은 로드 밸런서에 의존성이 생기고, 클라이언트 측에 비해 유연성이 떨어진다는 점입니다.

Raft/Paxos를 프로덕션에 적용할 때 이론과 현실의 괴리는 큽니다. 가장 큰 도전은 네트워크 파티션입니다. 쿼럼을 유지하기 어렵고, 잘못된 리더 선출로 인해 데이터 불일치가 발생할 수 있습니다. 이를 위해 정교한 장애 감지 메커니즘과 타임아웃 기반의 리더십 선출을 사용합니다.

노드 장애 복구 시에는 로그 복제 지연이 문제입니다. 복구된 노드가 최신 상태를 따라잡는 데 시간이 걸리므로, 강력한 일관성을 유지하기 위한 추가적인 동기화 전략이 필요합니다.

리더십 변경은 필연적으로 오버헤드를 발생시킵니다. 리더가 자주 바뀌면 성능 저하로 이어지므로, 리더의 수명 주기 관리와 안정적인 리더 선출이 중요합니다.

운영 측면에서는 지속적인 모니터링이 필수적입니다. 네트워크 상태, 노드 건강, 로그 복제 지연 등을 실시간으로 추적하고, 사전 정의된 임계값에 따라 알람을 설정해야 합니다. 또한, 성능 튜닝을 위해 복제 지연, 타임아웃 값 등을 주기적으로 조정해야 합니다.

결론적으로, 이론적 이해를 넘어 견고한 장애 처리, 효율적인 복구, 그리고 세심한 운영 및 모니터링이 분산 합의 알고리즘의 성공적인 프로덕션 적용을 위한 핵심입니다.

마이크로서비스 환경에서 ACID 속성을 보장하기 위해 Saga 패턴을 사용하는 이유는 2PC의 성능 및 가용성 문제 때문입니다. Saga 패턴은 크게 Choreography와 Orchestration 두 가지 방식이 있습니다.

Choreography는 각 서비스가 이벤트를 발행하고 구독하여 다음 단계를 진행하는 방식입니다. 장점은 서비스 간 결합도가 낮고 유연하다는 점이지만, 단점은 전체 워크플로우 파악이 어렵고 디버깅이 복잡해질 수 있다는 것입니다.

Orchestration은 중앙 Orchestrator가 각 서비스의 트랜잭션을 관리하는 방식입니다. 장점은 워크플로우 관리가 용이하고 중앙 집중적인 오류 처리가 가능하다는 점입니다. 단점은 Orchestrator에 의존성이 생기고 복잡도가 증가할 수 있다는 것입니다.

Saga 구현 시 보상 트랜잭션 설계는 매우 중요합니다. 각 트랜잭션에 대한 역연산을 정의하고, 실패 시 이를 실행하여 이전 상태로 되돌려야 합니다. 보상 트랜잭션은 멱등성을 보장해야 합니다. 즉, 여러 번 실행해도 동일한 결과를 내야 합니다. 실패 처리 전략으로는 재시도, 데드레터 큐(Dead-Letter Queue) 활용, 수동 복구 등이 있습니다. 재시도는 일시적인 오류에 효과적이며, 데드레터 큐는 처리 불가능한 메시지를 격리하여 분석하고 복구할 수 있도록 합니다.

면접관님, 분산 시스템에서 일관성 모델을 선택하는 것은 단순히 CAP 이론만을 고려할 문제는 아니라고 생각합니다. 비즈니스 요구사항, 시스템 성능, 개발 복잡성 등 다양한 요소를 종합적으로 고려해야 합니다.

예를 들어, 은행 계좌 이체 시스템처럼 높은 정확성이 요구되는 경우에는 강한 일관성을 선택해야 합니다. 약간의 지연이나 가용성 저하가 발생하더라도 데이터의 정확성을 보장하는 것이 중요하기 때문입니다. 반면, 소셜 미디어의 게시물 좋아요 수와 같이 상대적으로 중요도가 낮은 데이터는 결과적 일관성을 선택할 수 있습니다. 사용자 경험을 위해 빠른 응답 속도를 유지하고, 데이터 불일치 기간은 감수할 수 있습니다.

중간 단계의 일관성 모델도 유용하게 활용될 수 있습니다. 예를 들어, "Read-Your-Writes" 일관성은 사용자가 자신의 글을 게시한 직후에는 항상 최신 글을 볼 수 있도록 보장합니다. 이는 사용자 경험을 향상시키는 데 도움이 됩니다. "Causal Consistency"는 인과 관계가 있는 이벤트는 순서대로 보이도록 보장하여 데이터의 논리적인 흐름을 유지합니다. 이러한 중간 단계의 일관성 모델은 강한 일관성과 결과적 일관성의 장점을 절충하여 시스템의 요구사항에 맞게 적용할 수 있습니다.

분산 시스템에서 캐시 무효화는 데이터 일관성을 유지하는 데 매우 중요합니다. 기본적인 Read-through, Write-through, Write-back 외에도 몇 가지 전략이 있습니다.

Cache-aside with TTL은 가장 간단합니다. 캐시에 데이터를 저장할 때 TTL을 설정하고, TTL이 만료되면 캐시에서 데이터를 삭제합니다. 구현은 간단하지만, TTL 설정에 따라 데이터가 stale해질 수 있습니다.

Publisher/Subscriber 모델은 데이터 변경 시 발행자가 캐시 서버에 무효화 메시지를 보내고, 구독자가 이를 받아 캐시를 업데이트하는 방식입니다. 실시간성이 높지만, 메시지 전달 실패 시 일관성이 깨질 수 있습니다.

Versioning은 데이터에 버전을 부여하고, 데이터 변경 시 버전을 업데이트하는 방식입니다. 캐시된 데이터와 원본 데이터의 버전을 비교하여 일치하지 않으면 캐시를 갱신합니다. 복잡하지만, 강력한 일관성을 보장합니다.

각 전략은 일관성, 성능, 구현 복잡도 면에서 트레이드오프가 있습니다. TTL은 읽기 빈도가 높은 데이터에, Pub/Sub은 실시간성이 중요한 데이터에, Versioning은 높은 일관성이 필요한 데이터에 적합합니다.

분산 트레이싱 시스템 구축은 마이크로서비스 환경에서 필수적입니다. OpenTelemetry를 활용하면 표준화된 방식으로 트레이싱 데이터를 수집, 처리, 분석할 수 있습니다.

핵심 구성 요소는 Span, Trace, Context Propagation입니다. Span은 개별 작업 단위를 나타내고, Trace는 전체 요청 흐름을 나타냅니다. Context Propagation은 서비스 간 호출 시 Trace ID와 Span ID를 전달하여 연관 관계를 유지하는 역할을 합니다.

데이터 수집 시 오버헤드를 줄이기 위해 샘플링 전략이 중요합니다. 항상 모든 트레이스를 수집하는 대신, 일정 비율로 샘플링하거나 특정 조건에 따라 필터링할 수 있습니다. 데이터 저장 시에는 대용량 데이터를 효율적으로 처리할 수 있는 데이터베이스를 선택해야 합니다. 상관관계 분석 시에는 Trace ID를 기반으로 서비스 간 호출 관계를 시각화하고, 병목 지점을 파악할 수 있도록 대시보드를 구축해야 합니다. 이러한 과정에서 발생하는 기술적 난관들을 해결하기 위해 지속적인 모니터링과 성능 테스트가 필요합니다.

분산 시스템에서 리더 선출은 시스템의 안정성과 가용성을 확보하는 데 매우 중요합니다. 리더는 특정 작업을 조정하고, 데이터 일관성을 유지하는 역할을 담당합니다.

리더 선출 알고리즘 중 하나인 Bully 알고리즘은 가장 높은 ID를 가진 노드가 리더가 되는 방식입니다. 노드가 리더가 다운되었다고 판단하면, 자신보다 높은 ID를 가진 노드들에게 선출 메시지를 보냅니다. 응답이 없으면 자신이 리더가 됩니다.

실제 프로덕션 환경에서 리더 장애 발생 시 가용성과 데이터 일관성을 빠르게 복구하기 위해 쿼럼 기반의 접근 방식을 사용할 수 있습니다. 예를 들어, ZooKeeper나 Etcd를 사용하여 쿼럼을 구성하고, 리더 노드에 문제가 생기면 쿼럼 내에서 새로운 리더를 선출합니다.

또한, Watchdog 프로세스를 통해 주기적으로 리더의 상태를 확인하고, 응답이 없으면 리더 장애로 판단하여 선출 과정을 시작할 수 있습니다. 펜싱은 이전 리더가 더 이상 시스템에 영향을 주지 못하도록 격리하는 기술입니다. 예를 들어, 이전 리더의 권한을 제거하거나 네트워크 접근을 차단하여 데이터 손상을 방지할 수 있습니다.

분산 시스템에서 멱등성은 중복 요청에도 불구하고 시스템 상태가 한 번만 변경되도록 보장하는 핵심 원칙입니다. 이를 위해 여러 기법을 활용할 수 있습니다.

메시지 큐 환경에서는 Producer와 Consumer 양측에서 멱등성을 보장하는 것이 중요합니다.

Producer 측에서는 각 요청에 고유한 멱등키(Idempotency Key)를 생성하여 함께 전송합니다. 이 키는 클라이언트가 생성하거나 서버 측에서 생성 후 응답으로 반환받아 재시도 시 활용할 수 있습니다.

Consumer 측에서는 메시지를 처리하기 전에 해당 멱등키를 사용하여 이미 처리된 요청인지 확인합니다. 이를 위해 멱등키와 처리 상태를 저장하는 저장소(예: Redis, 데이터베이스)를 사용합니다. 만약 멱등키가 저장소에 존재하고 이미 처리 완료 상태라면, 해당 메시지는 중복으로 간주하여 무시합니다. 처리되지 않은 멱등키라면, 메시지를 처리하고 멱등키와 처리 완료 상태를 저장소에 기록합니다.

데이터베이스의 UNIQUE 제약 조건을 활용하는 것도 좋은 방법입니다. 예를 들어, 주문 생성 시 멱등키를 주문 테이블의 UNIQUE 컬럼으로 설정하면, 동일한 멱등키로 두 번 이상 삽입 시도 시 데이터베이스 레벨에서 중복을 막을 수 있습니다.

이러한 기법들을 통해 네트워크 지연, 타임아웃, 서비스 재시작 등의 상황에서도 시스템의 상태 변경을 한 번으로 제한하고 항상 동일한 결과를 보장할 수 있습니다.