[ ] 앞전 페이지 내용에 대한 의문을 여기서 보완해주기 여기서 예리하신 분들은 질문하실 겁니다. '인스턴스 3개가 동시에 돌면 순서가 꼬이지 않나요?' 맞습니다. 이게 분산 시스템의 가장 큰 함정이죠.

분산 환경의 영원한 숙제: 순서 보장 전략

1. 문제 상황 시각화: "큐 그룹의 배신?"

먼저 독자들에게 왜 문제가 생기는지 그림으로 보여줘야 합니다.

• 상황: 한 명의 유저(User A)가 0.1초 간격으로 2개의 이벤트를 발생시킴.
  1. 이벤트 ①: "채팅방 입장" (Msg 1)
  2. 이벤트 ②: "메시지 전송" (Msg 2)
• NATS 큐 그룹의 작동: 로드 밸런싱(Round Robin) 때문에 각각 다른 인스턴스로 배달됨.
  • 인스턴스 A: 이벤트 ① 처리 시작 (조금 느림)
  • 인스턴스 B: 이벤트 ② 처리 시작 (빠름)
• 결과: DB에는 **"메시지 전송"**이 먼저 저장되고, 그 뒤에 **"채팅방 입장"**이 기록됨. (순서 역전 = 논리적 오류 발생)

2. 해결책 A: "NATS 레벨에서 해결" (Subject Partitioning)

가장 아키텍처적인 해결법입니다. **"같은 유저의 이벤트는 무조건 같은 인스턴스로 보내자"**는 전략입니다. (Kafka의 파티션 키와 비슷한 개념을 NATS로 구현하는 법)

• Subject 설계 변경: user.event -> user.event.{UserID}
• 구독(Subscribe) 전략: 큐 그룹 전체가 모든 걸 다 받는 게 아니라, **담당구역(Shard)**을 나눕니다.
  • 인스턴스 1: user.event.1* 구독 (ID가 1로 시작하는 유저 전담)
  • 인스턴스 2: user.event.2* 구독 (ID가 2로 시작하는 유저 전담)
  • 인스턴스 3: user.event.3* 구독
• 효과: 특정 유저의 이벤트는 항상 특정 인스턴스로만 가기 때문에, 인스턴스 내부에서 순서대로 처리됩니다.
• 단점: 오토 스케일링(Auto-scaling)할 때 설정이 복잡해집니다.

3. 해결책 B: "애플리케이션 레벨에서 해결" (Optimistic Locking) ⭐추천

가장 현실적이고 유연한 방법입니다. (아까 우리가 이야기했던 그 주제와 연결됩니다!)

"순서가 섞여서 들어오는 건 어쩔 수 없다. 하지만 DB에 저장할 때 순서가 맞는지 검사하자."

• 전략: NATS는 그냥 마구잡이로 뿌리게 둡니다(최대 성능). 대신 처리할 때 **버전(Version)**을 체크합니다.
• 시나리오:
  1. 이벤트 ② (버전 2)가 먼저 도착함.
  2. 로직: "어? 내 현재 DB 버전은 0인데, 왜 버전 2가 왔지? 버전 1은 어디 감?"
  3. 처리: **Nack(Negative Acknowledgement)**을 날려서 NATS에게 "나 이거 지금 처리 못 해. 나중에 다시 줘."라고 거부함.
  4. 잠시 후 이벤트 ① (버전 1)이 도착 → 정상 처리 (버전 0 → 1 업데이트).
  5. 아까 거부했던 이벤트 ②가 재전송됨 → 정상 처리 (버전 1 → 2 업데이트).
• 효과: 인프라 설정 복잡도 없이 데이터 정합성 100% 보장.

문제 상황

이벤트 메세지 → nats jetstream → consumer → Database Jobs(INSERT, UPDATE, DELETE …) 의 흐름에서 부하 분산을 위해 2개 이상의 consumer를 배치하는 경우,

이벤트 메세지를 누적해서 얻은 대상의 최종 status와 데이터베이스에 반영된 최종 status 값이 불일치할 수 있는 문제.

문제 상황을 잘 설명하는 사례

채팅 메세지 발생 (a) → 채팅 메세지 내용을 ‘1’ 로 수정 (b) → 채팅 메세지 내용을 ‘123’ 로 수정 (c)

• ws 로 받아보는 실시간 메세지는 delta 값을 누적해서 최종 상태값인 ‘123’ 을 사용자에게 보여줌
• db에는 consumer 2대가 접근 중이므로 메세지 (b), 메시지 (c) 가 동시에 database에 UPDATE 요청을 보낸다. 두 SQL 쿼리 중 (c) 가 먼저 적용되고, 그 후 (b) 가 적용되면 데이터베이스에는 최종 상태값이 ‘1’ 로 적용됨

해결 방법

1. 이벤트 메세지에, 직전 이벤트 메세지의 updatedAt, 즉 업데이트 된 타임스탬프 값을 기재한다.

   채팅 메세지 발생 (a, updatedAt = ‘’) 
   
   → 채팅 메세지 내용을 ‘1’ 로  수정 
   
   (b, updatedAt = ‘20260102111520123’, previousUpdatedAt = ‘’) 
   
   → 채팅 메세지 내용을 ‘123’ 로  수정 
   
   (c, updatedAt = ‘20260102111550123’, previousUpdatedAt = ‘20260102111520123’)
   

   • 데이터베이스에 b, c 메세지에 의한 SQL 쿼리 실행이 동시에 접근한다.
   • c가 먼저 접근하는 경우 다음과 같이 정합성을 체크한다.
   • SELECT * FROM Message WHERE UpdatedAt = ‘20260102111520123’;
   • 만약 어떠한 row도 찾을 수 없다면 잘못된 순서로 DB 반영을 시도하는 것이므로 NackWtihDelay를 사용하여 jetstream으로 해당 메세지를 다시 돌려보낸다.
   • 다시 돌려보낸 동안 다른 컨슈머 또는 이 컨슈머가 UpdatedAt = ‘20260102111520123’에 해당하는 메세지를 DB에 반영시킨다.
   • 다시 UpdatedAt = ‘20260102111520123’ 에 해당하는 메세지가 돌아오면 row를 찾을 수 있게 되고 올바른 순서로 DB에 반영된다.
   • 17자리 숫자 문자열이 완전히 같은 이벤트가 발생할 경우는 실생활에서 희박할 수 있겠지만, 장기적인 관점에서 보았을 때는, 시각 정보보다는 version 넘버링이 더 확장성이 좋고 엄격하게 정합성 보장이 가능하다.

또 다른 문제(더 구체적인 문제)

• 사례:

  채팅 메세지 테이블과 첨부파일 테이블로 분리가 된 상황을 가정하자.

  채팅 메세지에 첨부 파일을 첨부하고 나서, 채팅 메세지를 수정할 때 첨부파일 리스트도 같이 수정을 하는 경우는 어떻게 데이터 정합성을 보장할 수 있을까?

  채팅 메세지 + 첨부파일(1,2,3) 작성 (a) 
  → 채팅 메세지 내용을 ‘1’ 로 수정 + 첨부파일에서 1번파일 제거 (b) 
  → 채팅 메세지 내용을 ‘123’ 로 수정 + 첨부파일에 4번파일 추가 (c)
  → 첨부파일에서 3번 파일 제거(d)
  → 채팅 메세지 내용을 'abderer' 로 수정(e)
  
  기대하는 최종 상태값: 
  - 채팅 메세지 내용: 'abderer' 
  - 첨부파일 목록: (2,4)
  

• 내가 생각했던 해결책

  • 이벤트 메세지 페이로드에 채팅메세지와 첨부파일을 하나로 묶어준다.

  • 채팅 메세지와 첨부파일 관련 SQL 쿼리를 하나의 트랜잭션으로 묶어준다.

  • 채팅메세지와 첨부파일 테이블 모두 각각 version 칼럼을 배치한다.

  • 하나의 트랜잭션이 성공하면 채팅메세지와 첨부파일 테이블의 버전을 모두 같은 값으로 업데이트한다. 즉 사례에 적용해보면 다음과 같이 풀어볼수 있겠다.

    채팅 메세지 + 첨부파일(1,2,3) 작성 (a) 
    -- 채팅메세지 버전 0, 첨부파일 버전 0
    
    채팅 메세지 내용을 ‘1’ 로 수정 + 첨부파일에서 1번파일 제거 (b)
    -- 채팅메세지 버전 1, 첨부파일 버전 1
    select * from message where version = 0 (채팅메세지 row = 0개면 돌려보낸다)
    
    채팅 메세지 내용을 ‘123’ 로 수정 + 첨부파일에 4번파일 추가 (c)
    -- 채팅메세지 버전 2, 첨부파일 버전 2
    select * from message where version = 1 (채팅메세지 row = 0개면 돌려보낸다)
    
    첨부파일에서 3번 파일 제거(d)
    -- 채팅메세지 버전 3, 첨부파일 버전 3
    (첨부파일 버전이 올라갈때 채팅메세지 버전도 같이 올려준다)
    select * from message where version = 2 (채팅메세지 row = 0개면 돌려보낸다)
    
    채팅 메세지 내용을 'abderer' 로 수정(e)
    -- 채팅메세지 버전 4, 첨부파일 버전 4
    (채팅메세지 버전이 올라갈때 첨부파일 버전도 같이 올려준다)
    select * from message where version = 3 (채팅메세지 row = 0개면 돌려보낸다)
    

  • (그런데 사장님께선 실무에서 진짜 트랜잭션을 써야할만큼의 데이터 정합이 깨지는 문제는 드물다고 했는데… 이 말은 내가 어떻게 받아들여야 할지 정말모르겠다. 트랜잭션 때문에 데이터베이스에 락이 걸리는 문제를 우려하셨던 걸까. ? 내가 이렇게 이해도가 낮았나ㅠ?)

• 결론: **동시 수정 확률이 낮으니 트랜잭션 비용보다는 낙관적 락(Optimistic Lock)이나 이벤트 순서 보장으로 가볍게 풀라'는 뜻으로 이해해야 한다.

  • 나의 해결책에서 발생할 수 있는 문제점:
    • 첨부파일만 지워도 메시지 테이블에 Lock을 걸어야 합니다. 트래픽이 몰리면 DB 성능 저하(Contention)가 발생할 수 있습니다.
    • 메신저 시스템에서 메시지 수정과 파일 수정이 밀리초(ms) 단위로 동시에 일어나는 빈도가 얼마나 될까요? 사장님 말씀은 "그 빈도가 극히 낮으니, 굳이 그렇게 빡빡하게(트랜잭션 비용을 쓰면서) 막을 필요가 있나?"라는 뜻일 확률이 높음.
    • 따라서, 실무, 특히 고트래픽 환경에서는 아래 3가지 이유로 님의 방식(Strict Transaction)을 피하기도 합니다.

      • ① Aggregate Root 패턴 (DDD 관점)

        채팅 시스템에서 첨부파일은 독자적인 존재가 아니라, 메시지의 **부속품(Value Object)**입니다.

        • 즉, Message가 **Aggregate Root(주인)**이고 Attachment는 그냥 속성입니다.
        • 실무적 해결: 요즘은 RDBMS(MySQL/PostgreSQL)도 JSON 타입을 잘 지원합니다. 굳이 Attachment 테이블을 따로 나누지 않고, Message 테이블의 **attachments 컬럼(JSON)**에 [{"id":1}, {"id":2}] 이렇게 박아버리는 경우가 많습니다.
        • 결과: 조인(Join)도 필요 없고, 트랜잭션도 필요 없습니다. Message 행 하나만 업데이트하면 원자성(Atomicity)이 자연스럽게 보장됩니다.

      • 낙관적 락 (Optimistic Locking)만으로 충분