[Spring] 데이터 정합성을 맞추기 위해 Outbox로 수정해보자. + CDC, Kafka 등 다양한 방법 알아보기

 

현재 코드에는 해결하지 못한 문제가 있었다.
Elasitcsearch와 keycloakd은 외부에서 돌아가는데
하나의 트랜잭션에서 관리하려다 보니
DB와 각 프로그램 속 데이터가 어긋날 가능성이 있었다.
그래서 이번엔 이 코드를 수정해 볼 것이다.

 

 

 

1. 문제

 

데이터 정합성 문제를 알고 있었다. 그래서 그때 당시 내가 할 수 있는 방법인 수동 동기화로 전체 동기화 메서드(syncAllToElasticsearch)를 만들었다.

 

Q. 데이터 정합성이란?

A. 서로 연관된 데이터가 정해진 규칙에 맞게 일치하는 상태를 말한다.

도커로 돌리는 중

 

일단 가장 첫 번째로 발생했던 문제를 이야기해 보겠다. Elasticsearch(검색용)와 Keycloak(로그인용)은 DB와 같은 공간이 아닌 외부에 존재하는 시스템이다. 그래서 DB와 Elasticsearch(혹은 Keycloak)는 따로 관리를 해야 한다. (Keycloak은 다음 포스팅에서...)

 

그러다 보니 대표적인 문제인 데이터 정합성이 깨지는 일이 발생할 수 있다. 예를 들어서 사용자가 고객의 이름을 수정했다고 가정하자. 그런데 어떤 이유로 DB는 수정을 실패했다. DB는 알아서 롤백을 하고 이전 값으로 돌아간다. 그런데 Elasticsearch와 Keycloak은 롤백이란 개념이 없기 때문에 수정된 값을 그대로 가지게 된다. 그래서 DB와 Elasticsearch(혹은 Keycloak)가 서로 들고 있는 데이터들이 어긋나는 문제가 발생하게 된다. 

 

 

[Elasticsearch]

 

처음에 이 문제를 해결하기 위해 syncAllToElasticsearch() 전체 동기화 메서드를 만들었다. DB와 Elasticsearch가 서로 가지고 있는 데이터들이 똑같은지 확인하는 것이다.

수정 전 흐름

1. 사용자가 고객 이름을 수정

2. CustomerService.update( ) 실행

3. MySQL 고객 저장 요청

4. Elasticsearch 고객 저장 요청

5. MySQL 트랜잭션 커밋

 

이 메서드는 MySQL 고객 목록을 읽어서 Elasticsearch에 다시 저장하는 기능이다. 물론 이 정도 안전장치를 해둬도 현 프로젝트에 염려한 문제가 일어나진 않는 것 같다. (발생하지 않았을 뿐, 발생 가능성은 있다) 그런데 공부를 더 하면서 생각보다 이 방법이 썩 좋은 방법이 아니라는 걸 알게 되었다.

 

이 수동 동기화도 처리하지 못하는 두 번째 문제가 있다. 해당 동기화 메서드는 MySQL 고객 목록을 읽어서 Elasticsearch에 다시 저장하는 기능이라고 설명했었다. 즉, 삭제된 고객은 제거하지 못한다. 101번 고객과 102번 고객이 없는 것을 알게 되면 다시 ES(Elasticsearch)에 저장한다. 그러나 103번 고객이 MySQL에 없는 경우 ES에만 데이터가 남아있을 수 있다. 이런 데이터를 고아문서라고 부른다.

 

그리고 세 번째 문제가 더 있다. 이 문제가 방금의 문제보다 중요하다. 동시에 두 가지 작업이 진행되는 상황이라고 가정하자. A작업은 전체 동기화 중이고 B 작업은 관리자의 고객 이름을 수정하고 있는 중이다. 

1. 전체 동기화 A가 MySQL에서 홍길동을 읽어 메모리에 보관한다. (8시)

2. 관리자 B가 이름을 청길동으로 수정하고 MySQL과 ES에 반영한다. (8시 1초)

3. 동기화 A가 앞서 읽었던 홍길동을 ES에 저장한다. (8시 2초)

4. MySQL은 청길동, ES는 홍길동으로 저장된다. (8시 3초)

 

이 문제를 경쟁 상태라고 부른다. 여러 작업이 동시에 실행되면서 어떤 작업이 먼저 끝나는지에 따라 결과가 달라지는 현상을 말한다. 이 현상은 저장에서만 발생하는 것이 아니라 삭제도 일어난다. 전체 동기화가 고객을 읽은 시점에서 관리자가 해당 고객을 삭제한 후 전체 동기화가 마저 임무를 수행했다면 MySQL은 삭제되었어도 ES에는 남아있게 되는 것이다.

 

결론적으로 전체 동기화 API를 스케줄러로 주기적으로 실행해도 정합성 문제는 해결되지 않는다!

 

이 내막을 자세히 알고 나니 안 고칠 수가 없었다. 사실 이 프로젝트는 내가 직접 코드를 찾아보며 작성했었다. 물론 후반부터는 AI 도움을 받았지만 마구마구 사용하는 것이 아닌 최대한 내가 스스로 공부하고 코드를 작성한 뒤 계속해서 작동이 실패되면 AI에게 뭐가 문제인지 물어보는 방식으로 진행했었다. 그러다 보니 요새 면접 준비를 하면서  옛 코드의 문제점을 하나둘씩  발견하는 중이다.

 

 

 

---

 

 

 

2. 다양한 해결 방법 

 

이 문제를 해결하기 위해 고려해야 할 것들이 있다. 첫 번째는 MySQL과 ES 작업 성공을 모두 보장할 것. 그리고 두 번째는 최대한 추가하는 인프라 없이 문제를 해결할 것이다. 인프라를 추가하지 않고 해결하고자 하는 이유는, 이 프로젝트가 다수의 사용자를 위해 만든 프로그램이 아니기 때문이다. 

 

처음 프로젝트를 만든 당시 나름대로 스토리라인이 있었다. 만약 내가 어느 브랜드를 만들었고 그 브랜드가 나름 커져서 VIP 이상 고객을 위해 연말 이벤트를 연다는 것이었다. 그래서 고객을 관리하고 각 고객의 등급에 맞는 사이트를 연결해서 쇼핑을 할 수 있도록 진행하는 것이었다. 물론 만들다 보니 DB에 관련된 프로젝트를 진행하고 싶은 마음이 생겨 약간의 방향이 수정되었지만 어쨌든 이 프로젝트는 사용자 규모가 크지 않다. 그래서 굳이 다른 인프라를 추가하면서까지 관리하지 않아도 되지 않을까라고 생각했다.

 

 

• 알고 가면 좋을 개념들

Q. 이중 쓰기(Dual Write)란?

A. 하나의 비즈니스 작업을 수행하면서 서로 다른 두 시스템에 데이터를 기록하는 것을 말한다.

현재 프로젝트에서는 관리자가 고객의 이름을 홍길동에서 청길동으로 변경한 것에 있다. 변경 요청에 의해 MySQL의 고객 정보는 수정되고 ES의 검색 데이터도 수정될 것이다. 이렇게 하나의 요청에서 두 저장소에 쓰기 작업이 발생한 것을 이중 쓰기라고 한다. 

 

 

Q. flush( )와 commit의 차이는?

A. flush( )는 SQL을 DB에 전달하는 동작이다. commit( )은 트랜잭션의 변경 내용을 최종 확정하는 것을 말한다.

여기서 헷갈리면 안 되는 것은 flush( )는 전달만 하고 최종 확정은 하지 않기 때문에 롤백(커밋이 되지 않은 트랙잭션을 변경 취소)이 가능하다. commit은 당연히 최종 확정이 되기 때문에 롤백이 되지 않는다. 

 

 

Q. @Transactional이란?

A. @Transactional은 스프링 프레임워크(Spring Framework)에서 선언적 트랜잭션(Transaction)을 관리하기 위해 클래스나 메서드에 붙이는 어노테이션이다. 현재 프로젝트에서 일반적으로 MySQL의 로컬 트랜잭션을 관리하는 역할을 한다.

 

 

• 요청 안에서 직접 동기화 (현재 방법)
  수정 요청이 들어오면 MySQL과 ES에 차례로 데이터를 저장한다. 

장점	• 구현이 단순하다 •  외부 인프라 없이 구현 가능하다
단점	•  이중 쓰기 문제가 발생한다 •  ES가 중단되면 고객 수정 요청까지 실패할 수 있다 •  MySQL 커밋 전에 ES 변경이 성공하면 저장소 사이의 불일치가 생길 수 있다
결론	•  구현은 간단하다 •  그러나 장애 상황에서 데이터 정합성을 안정적으로 복구하기 어렵다

 

 

• 커밋 후 이벤트리스너
  ES 반영 시점을 바꿔서 MySQL에 고객 정보를 커밋한 다음 ES 저장 요청을 실행하는 방법이다. Spring에서 @TransactionalEventListener를 사용할 수 있다.

장점	• DB 커밋 후 처리가 가능하다 • MySQL이 롤백됐을때 ES에 변경이 반영되는 문제를 줄일 수 있다.
단점	• 이벤트 리스너 실행 전 서버 종료가 될 경우 ES 동기화 작업이 유실되는 가능성이 있다. • 기본적으로 Spring의 내부 이벤트 매커니즘은 인메모리 방식으로 동작하기 때문에 메모리에 있던 이벤트가 영구적으로 유실될 수 있다. • 서버 종료 후 복구하기 위해 별도 장치가 필요하다. • 장애 재시도를 위한 추가 구현을 해줘야한다.
결론	• ES 반영 시점을 변경하여 문제를 줄일 수 있다. • 그러나 장애 상황에서의 데이터 정합성 보장이나 자동 복구 기능까지 제공하지 않는다.

 

 

 

• Transactional Outbox (채택! 구체적인 설명은 밑에)
  Outbox는 데이터베이스 트랜잭션과 메시지 브로커(Kafka, RabbitMQ 등) 간의 원자성을 보장하여, 이벤트 기반 아키텍처에서 데이터 유실이나 정합성 깨짐을 방지하는 디자인 패턴을 말한다. 물론 이 프로젝트에서는 메시지 브로커는 제외할 것이다. 고객 정보 변경과 변경 사실의 기록을 하나의 MySQL 트랜잭션에서 처리하는 방식이다.
  
  고객 이름 수정 요청이 들어오면 하나의 트랜잭션이 시작한다. customers 테이블 수정이 이뤄지고 outbox 테이블에 동기화 작업을 저장한다. 그 후 commit이 되면 스케줄러가 Outbox 작업을 확인해 ES에 반영한다.
  
  여기서 중요한 것은 MySQL과 ES를 하나의 트랜잭션으로 묶었다는 뜻이 아니라는 점이다. 하나의 트랜잭션으로 묶인 것은 MySQL 고객 데이터 변경과 MySQL Outbox 작업 기록이다. ES가 잠시 고장 나더라도 고객을 검색 인덱스에 반영해야 한다는 사실은 MySQL에 남게 된다.
  
  물론 단순히 Transactional Outbox만 사용한다고 문제가 해결되진 않는다. 그랬다면 진작에 사용했을 것이다. Transactional Outbox는 비즈니스 데이터와 이벤트를 동일한 DB 트랜잭션으로 안전하게 저장하는 역할만 담당한다. 완전한 데이터 정합성을 달성하려면 별도의 처리기와 추가적인 안전장치들이 있어야 한다.

장점	• 인프라 구축 및 운영 비용이 따로 들지 않는다. • 데이터 유실을 방지하여 원자성을 확보한다.
단점	• 트래픽이 많아지면 데이터베이스에 지속적인 I/O 부하와 락 경합을 유발한다. • 여러 대의 서버가 동시에 폴링(하나의 장치나 프로그램이 다른 장치나 서버의 상태를 주기적으로 검사)을 돌릴 때 같은 이벤트를 중복으로 처리하지 않도록 배타 락 로직을 DB별로 구현해야한다.
결론	• 트래픽이 폭증하지 않는 환경에서 인프라 추가 없이 간단하고 확실하게 이벤트 유실만 막을 수 있다. • 그러나 대규모 트래픽이나 복잡한 마이크로서비스 구조로 확장되면 DB 부하와 폴링 한계 때문에 Kafka나 CDC 기반으로 전환해야한다.

 

 

• Kafka와 RabbitMQ
  메시지브로커는 시스템 사이에서 메시지를 전달하고 보관하는 역할을 하는 소프트웨어다. 
  
  예를 들어서 관리자가 고객 정보를 수정하면 고객 서비스는 다음과 같은 메시지를 보낸다. 
  
  {
     "event": "CUSTOMER_UPDATED",
     "customerId": 101
  }
  
  다른 프로그램은 이 메시지를 받아서 ES에 고객 데이터를 저장한다. 물론 Kafka와 RabbitMQ는 모두 메시징을 지원하지만 내부 구조와 사용 방식은 서로 다르다. 다만 단순하게 둘 다 애플리케이션의 작업을 다른 처리기로 전달할 수 있는 기술이라는 것만 알고 넘어가면 될 것 같다.
  
  그러면 메시지 브로커를 활용하면 모든 문제가 해결될까? 아니다. 놀랍게도 여전히 이중 쓰기 문제가 남는다. 고객 수정의 커밋이 이뤄지고 그 후 메시지 전송을 시도했다고 하더라도 Kafka에 메시지가 도착하지 않을 수 있다. 그러면 ES를 수정해야 한다는 사실을 Consumer(메시지를 받아 처리하는 프로그램)가 알 수 없다. 반대로 메시지를 먼저 보냈는데 MySQL 커밋이 실패한다면 실제 확정되지 않은 변경이 다른 서비스에 전달될 수도 있다.
  
  결론적으로 메시지 브로커가 있다고 해서 MySQL 트랜잭션과 메시지 발행이 자동으로 하나의 원자적 작업이 되는 것이 아니다. 
  
  그래서 많은 기업과 프로그램에서 Kafka와 OutBox를 함께 사용한다. Kafka는 메시지의 전달과 분배 및 비동기 처리 역할을 담당한다. Outbox는 전달해야 할 작업의 유실 방지 역할을 맡는다. 

장점	• OutBox 테이블에 남은 데이터를 기반으로 안전한 재시도가 가능하다. • 장애 상황에서도 데이터 정합성을 보장한다. • 안정적인 DB 트랜잭션 위에 Kafka의 강력한 대용량 처리, 파티셔닝, 확장성을 결합할 수 있다.
단점	• 추가 인프라와 운영 복잡도가 커지며 개발 비용이 올라간다. • 모든 이벤트 발생마다 DB 쓰기 작업이 추가로 발생하여 데이터베이스에 가중 부하를 줄 수 있다. • 네트워크 재시도 등으로 인해 이벤트 중복 수신할 수 있어 Consumer 측에 멱등성 로직 구현이 필수적이다.
결론	• 데이터 정합성과 유실 방지에서 가장 신뢰할 수 있는 표준 아키텍처 패턴이다. • 구현 복잡도와 인프라 비용이라는 트레이드오프가 존재하므로 금전 거래나 주문 등 정합성이 생명인 핵심 도메인에 집중적으로 적용하는 것이 바람직하다.

 

 

• CDC
  CDC는 Change Data Capture, 즉 데이터 변경 사항을 감지하는 기술이다. 데이터베이스에서 발생한 변경 기록을 읽어 어떤 데이터가 수정되었는지 감지할 수 있다. MySQL에는 binlog라는 기능이 있다. binlog(Binary Log)는 MySQL에서 발생한 데이터 변경 등을 기록하는 로그이다.
  
  쉽게 말해서 DB가 수행한 변경 이력을 다른 시스템에서 활용할 수 있도록 기록해 두는 장치라고 생각하면 된다. 예를 들어서 id가 101번의 이름을 청길동으로 UPDATE 하는 SQL이 실행되었다고 가정하자. (이 가정은 MySQL에서 일어난 것이다) CDC 도구는 MySQL의 변경 로그를 읽어 고객 101의 변경을 감지할 수 있다. 이때 대표적인 도구는 Debezium이다. Debezium의 MySQL 커넥터는 binlog를 읽어 INSERT, UPDATE, DELETE 등 행 단위 변경 이벤트를 생성할 수 있다. 
  
  CDC는 애플리케이션을 거치지 않고 실행된 SQL 변경도 감지할 수 있다. 꼭 CustomerService가 아닌, 개발자가 직접 UPDATE SQL을 실행하거나 다른 프로그램이 DB를 수정해도 MySQL  CDC는 이를 감지할 수 있다. 물론 CDC가 감지한 변경을 올바른 ES 문서 변경을 변환하는 로직은 별도로 필요하다. 
  
  다만 CDC를 안정적으로 운영하려면 추가로 고려한 내용이 많다. binlog 설정, CDC 도구가 로그를 읽을 수 있도록 권한 설정, 장애 중 로그가 사라지지 않도록 보존 기간 관리, Debezium 등의 도구 실행 및 관리, 변경 데이터를 ES에 적합한 형태로 변환, 기존 DB 데이터로부터 동기화하기 위한 절차, CDC 중단 후 읽던 위치부터 다시 처리하는 장애 복구 등이 있다. 

장점	• DB 로그를 직접 읽어 처리하므로 코드 복잡도가 낮아진다. • DB 변경 사항을 거의 실시간으로 감지하며 애플리케이션이나 DB에 추가적인 쿼리 부하를 주지 않는다. • 트랜잭션 로그를 기바능로 동작하므로 데이터베이스에 커밋된 변경 사항은 누락 없이 안전하게 캡처된다.
단점	• Debezium, Kafka Connect 등 별도의 CDC 솔루션을 구축하고 모니터링해야 하므로 초기 도입 및 운영 비용이 큰 편이다. • 데이터베이스의 Binlog 활성화 등 데이터베이스 설정 및 제약이 있다. • 스트림 파이프라인 장애, 오프셋 관리, 네트워크 단절 시 복구 등 분산 시스템 수준의 트러블 슈팅 지식을 알아야한다.
결론	• 아웃박스 패턴과 결합하면 가장 이상적인 스트리밍할 수 있는 현대적인 표준 아키텍쳐이다. • 그러나 구축과 운영 난이도가 높기 때문에 트래픽이 많고 데이터 실시간 동기화나 이벤트 유실 방지가 필수적인 대규모 엔터프라이즈 환경에 적합하다.

 

 

Q. Kafka + OutBox / CDC + OutBox 이렇게 따로따로 사용해야 하는 건가? 

A. (이 내용은 확실하지 않다) 아니다. 실제 기업들은 OutBox + Kafka + CDC 세 가지를 하나의 완전한 파이프라인으로 합셔서 사용한다. 대표적으로 쿠팡, 배달의 민족, 당근마켓이 세가지 모두를 사용한다.

예로 쿠팡을 찾아보면, 하루 수천만 건의 주문 트랜잭션이 발생하는 상황에서 메인 DB에 주는 부담을 최소하하며 이벤트 유실을 0%로 만들기 위해 해당 조합을 핵심 아키텍처로 사용한다. 

Kafka + Outbox는 토스에서 사용하고 있다. 금융 데이터의 특성상 매우 엄격한 정합성이 필요하여 Outbox 패턴을 적극 활용한다. CDC의 DB 로그 의존성이나 스키마 변경 위험을 피하고 비즈니스 제어를 명확히 하기 위해 애플리케이션 레벨의 폴러나 메시지 Relay 프로세스를 두어 Kafka로 이벤트를 안전하게 넘기는 형태를 선호한다.

OutBox 없이 Kafka + CDC 조합도 있다. 이는 주로 단순한 DB 변경사항 스트리밍인 경우 사용한다. 기존 메인 데이터베이스의 테이블 자체에 발생하는 CUD(생성, 수정, 삭제)를 CDC가 직접 감지하여 Kafka에 보낸다. 

 

 

 

---

 

 

 

3. Transactional Outbox Pattern

• 알아두면 좋을 개념

Q. Polling이란?

A. 아웃박스 테이블에 쌓인 이벤트를 주기적으로 조회하는 것을 Polliong이라고 한다. 컴퓨터 과학과 네트워크에서 폴링은 어떤 상태나 데이터가 변경되었는지 확인하기 위해 주기적으로 요청을 보내는 방식이라고도 한다.

보통은 Transactional Outbox Pattern을 Kafka 같은 메시지 브로커와 함께 사용한다. 그렇기 때문에 아웃박스 테이블에 쌓인 이벤트를 주기적으로 조회하여 메시지 브로커로 전송하는 방식을 폴링이라고 많이 사용하는 것 같다. 물론 정확한 명칭은 Polling Publishing인 것 같다. Publishing은 조회해 온 데이터를 Kafka 같은 메시지 브로커에 쏘거나 다른 시스템에 전달하는 행위라고 한다.

 

 

• Outbox
  Outbox는 작업 목록을 기록하는 것이다. 고객 정보를 MySQL에 저장할 때 나중에 ES로 보내야 할 작업도 MySQL에 함께 저장한다. 만약 문제가 생겨서 ES의 작업 처리가 제대로 이뤄지지 않더라도 ES에 보내야 할 작업을 저장하고 있기 때문에 처리하지 못한 작업부터 처리하면 된다.
  
  
  
• 기존 vs 개선
  기존 방식 : MySQL 저장 - ES 직접 저장 - DB 커밋
  개선 방식 : MySQL 저장 + Outbox 기록 - 하나의 MySQL 트랜잭션으로 커밋 - 스케줄러가 미처리 작업 확인 - ES 반영 후 완료 
  
  고객을 등록하는 시점에 ES에 반영해야 한다는 사실을 기록하고 실제 ES 저장은 별도의 처리기가 담당하도록 개선할 것이다. 이렇게 하면 ES에 문제가 발생해도 고객 데이터와 작업 기록은 MySQL에 남게 된다. 여기서 반드시 중요한 점은, 고객 저장과 Outbox 기록이 같은 트랜잭션 내에서 저장되어야 한다는 것이다. 왜 그럴까? 너무 당연한 이야기겠지만, 같은 공간에 없으면 갑자기 서버가 종료되는 경우 MySQL에는 고객이 존재하고 Outbox는 다른 트랜잭션에 있으니 작업이 어떻게 되었는지 알 수 없게 된다. 다른 트랜잭션에 있으면 이렇게 개선하는 의미가 사라진다.
  
  
  
• 전체 흐름
  관리자가 ID 20인 고객의 이름을 홍길동에서 청길동으로 변경했다고 가정하자.
  
  1) 관리자가 고객 이름을 변경 (홍길동 →청길동)
  2) MySQL 트랜잭션
    2-1) 고객 이름을 청길동으로 수정
    2-2) Outbox에 작업 추가
    2-3) 두 변경을 함께 COMMIT
  3) 스케줄러 실행 (처리 가능한 Outbox 조회)
  4) 고객 ID 20의 현재 DB 상태 확인 (현재 이름은 청길동)
  5) Elasticsearch에 청길동 반영
  6) Outbox 작업 완료 (status = DONE)

 

Q. 이제 여기서 ES 서버에 중단되어 저장에 실패하는 문제가 생긴다면 어떻게 될까?

A. Outbox에는 실패한 작업을 지우지 않고 그대로 보관하게 된다. 예를 들어 상태에 RETRY라고 적혀있을 것이다. ES 서버가 다시 정상화되면 스케줄러가 작업을 가져와 다시 처리하면 된다. 장애가 복구되면 자동으로 DB와 ES가 일치하도록 만든 것이다. 

 

 

• 예외 상황
  Outbox를 사용했다고 해서 모든 것이 다 해결된 것은 아니다. 더 안정적이기 위해 고려해야 할 부분들이 있다.
  
  첫 번째는 고객 ID를 ES 문서 ID로 사용해야 한다. ES 저장까지 성공했는데 Outbox에 DONE 상태를 저장하기 전에 서버가 종료되는 경우 Outbox는 여전히 미완료 상태가 된다. 그러면 ES는 고객을 두 번 저장하게 되는데 이때 ID로 사용하게 해서 기존 문서를 덮어쓰도록 하는 것이다. 여기서 조건은 같은 ID에 저장하는 데이터는 올바른 최신 데이터여야 한다는 것이다. 오래된 데이터를 다시 저장한다면 중복 문서는 생기지 않더라도 최신 데이터가 덮어써질 수 있다.
  
  두 번째는 처리 시점에 MySQL의 현재 데이터를 조회하도록 해야 한다. 이 이유는 앞의 문제에 있다. 재시도를 하는 경우 오래된 정보를 덮어써질 수 있다. 그래서 처리 시점에 ID 20인 고객의 이름을 조회하도록 해야한다. 그러면 고객의 최신 데이터가 제대로 유지가 되는 걸까?
  
  세 번째는 작업자를 하나 추가한다. 예를 들어서 두 작업자가 동시에 실행되고 B가 먼저 ES에 저장한 뒤 A가 뒤늦게 저장한다면, 마지막에는 오래된 이름이 남을 수 있다. 이런 경우를 동시성 문제라고 한다. 이 동시성 문제가 최신 데이터를 덮어쓸 수 있다. DB에서 최신 데이터를 다시 조회한다는 것과 ES 쓰기 순서를 보장한다는 것은 서로 다른 문제다. 그래서 작업자를 하나만 추가하는 것이다. 작업자가 하나면 ES에 쓰기 작업을 순차적으로 처리하기 쉬워진다. 작업 A가 끝난 후에 작업 B를 실행하도록 구성할 수 있다. 이렇게 하면 여러 작업자가 ES에 서로 다른 값을 동시에 저장하면서 발생하는 순서 충돌을 줄일 수 있다.
  
  다만 중요한 조건들이 있다. 다른 서비스나 API에서 ES에 직접 쓰면 안 된다. 스케줄러 실행이 중첩되지 않아야 한다. 그리고 이전 작업의 실패와 재시도 처리 순서도 고려해야 한다. 그래서 현재 고객 ES 변경 경로를 Outbox 처리기로 통일하는 방식의 이유이다. 물론 작업자가 하나여도 아주 완벽하게 문제를 막는 것은 아니다. 
  
  네 번째는 Elasticsearch의 외부 버전을 사용하는 것이다. 홍길동이 청길동으로 변경되는 경우를 버전 2, 청길동에서 홍길동으로 변경되는 경우를 버전 3이라고 가정하자. 버전 3이 먼저 ES에 저장되고 뒤늦게 버전 2가 ES에 저장된다면 버전 검증을 통해 현재 저장된 버전보다 오래된 변경은 저장되지 않는다. (또 다른 동시성 문제를 버전을 통해 해결할 수 있다)
  
  여기서 중요한 점은 JPA의 @Version과 ES의 외부 버전 제어가 자동으로 연결되는 것이 아니라는 사실이다. JPA의 버전은 DB에서 발생하는 동시 수정 충돌을 감지하는 데 사용되며, ES에도 버전을 적용하려면 저장 요청에 해당 번호를 전달해야 한다. 
  
  다섯 번째는 삭제 표식(Tombstone)을 남기는 것이다. 이 부분은 외부 버전 관리와 연결된다. 고객 ID 20의 버전 3 데이터가 존재하는 상황에서 해당 고객을 삭제하여 버전 4가 되었다고 가정하자. 그런데 ES에서 고객을 삭제한 후 오래된 버전 3의 수정 작업이 뒤늦게 실행된다면 어떻게 될까? ES는 삭제된 문서의 버전 정보를 영구적으로 보관하지 않는다. 따라서 과거 작업이 삭제된 고객을 다시 생성하는 문제가 발생할 수 있다. 이를 방지하기 위해 고객이 삭제되었다는 사실과 삭제 당시의 버전 번호를 기록해야 한다. 물론 표식을 저장하는 것만으로 해결되는 것은 아니다. 동기화 처리기가 삭제 기록을 확인하고 오래된 작업을 거부할 수 있도록 구성해야 한다.
  
  여섯 번째는 실패한 작업을 관리하고 재시도하는 것이다. PENDING(아직 완료하지 않은 작업), DONE(정상적으로 처리된 작업), FALIED(재시도 한도에 도달 혹은 별도 조치가 필요한 작업) 이렇게 세자기로 작업 상태를 둔다. 여기서 중요한 점은 백오프(Backoff)다. 실패가 반복될수록 재시도 간격이 늘려 장애가 발생한 서버에 불필요한 요청이 계속 전달되지 않도록 하는 방식이다.
  
  

 

• 데이터 정합성 보호
  Outbox는 고객 변경이 발생할 때 애플리케이션에서 동기화 작업을 함께 기록하는 방식이라고 설명했다. 그렇다면 개발자가 MySQL에 직접 SQL을 실행해서 고객 정보를 수정한다면 어떻게 되는 걸까? CustomerService를 거치지 않았기 때문에 Outbox 작업이 생성되지 않을 수 있다. 또한 ES의 인덱스가 손상되거나 일부 문서가 사라진다면 Outbox에는 복구해야 할 작업이 남아 있지 않을 수도 있다.
  
  그래서 이런 경우를 위해 정기적인 정합성 점검을 추가해야 한다. MySQL과 ES에 저장된 고객 데이터를 주기적으로 비교한다. 이때 단순히 전체 고객 수만 비교해서는 안 된다. 데이터가 다를 수 있기 때문에 고객 ID와 검색에 사용하는 필드를 비교하고 문제가 발견되면 MySQL을 기준으로 복구해야 한다.
  
  다음은 전체 재구축을 할 수 있도록 해야한다. 정기적인 정합성 점검은 일부 데이터가 잘못된 경우에 유용하다. 하지만 ES 인덱스 전체가 손상되거나 검색 설정을 변경해야 하는 경우라면 새로운 인덱스를 만드는 방법이 더 적절할 것이다. 이때 Alias를 이용하면 된다. Alias는 ES 인덱스를 가리키는 별칭이다. 실제 인덱스 이름이 변경되더라도 애플리케이션에서는 같은 Alias를 이용해 검색할 수 있다. 다만 새로운 인덱스를 구성할 때는 기존 필드 매핑과 nori 같은 한국어 분석기 설정을 고려해야 한다.
  
  
  
• 단점
  이렇게 설정한 Outbox는 완벽한 걸까? 물론 아니다. 실제 서비스를 제공한다면 이보다 더 많은 문제들을 고려해야 한다. 
  
  먼저 첫 번째로 데이터가 즉시 일치하지 않는다는 점이 있다. 현재 방식은 최종 일관성이라고 한다. 두 저장소가 항상 동시에 일치하는 것은 아니지만 정상적인 동기화와 장애 복구를 통해 최종적으로 같은 상태가 되도록 하는 것이다. 따라서 고객 수정 직후 검색하면 이전 데이터가 나타날 수 있다.
  
  두 번째는 구현 복잡도와 DB 부하가 증가한다는 것이다. 기존에는 MySQL과 ES에 직접 저장하면 됐지만 이제는 Outbox 테이블, 처리기, 재시도, 작업 상태, 버전 등 별도로 관리해야 한다. 고객을 수정할 때마다 Outbox에도 데이터를 저장해야 하며 스케줄러가 지속적으로 작업을 조회하기 때문에 MySQL에 추가적인 부하가 발생한다.
  
  세 번째는 작업이 중복 실행될 수 있다는 점이다. ES 저장이 성공한 뒤 Outbox의 완료 처리를 하기 전에 서버가 종료되면 같은 작업이 다시 실행될 수 있다. 따라서 고객 ID와 버전 관리 등을 이용해 중복 실행이 발생하더라도 올바른 최종 상태를 유지해야 한다.
  
  네 번째는 모든 장애를 자동으로 복구하지 못한다는 점이다. ES 연결 장애처럼 일시적인 문제는 재시도로 해결할 수 있지만 매핑 오류처럼 설정을 수정해야 하는 문제는 자동 재시도만으로 해결되지 않는다. 따라서 실패 작업을 확인하고 다시 처리할 수 있는 관리 기능이 필요하다.
  
  다섯 번째는 Outbox 기록이 계속 쌓인다는 점이다. 고객 변경이 발생할 때마다 작업을 기록하므로 시간이 지날수록 테이블의 데이터가 증가한다. 일정 기간이 지난 완료 작업을 정리하는 정책이 필요하지만, 아직 처리하지 않은 작업이나 삭제 버전 보호에 필요한 기록을 무작정 삭제해서는 안된다. 
  
  
  
• 결론
  Outbox는 데이터 동기화 문제를 완벽하게 없애진 못한다. 대신 데이터 변경 사실을 안전하게 보관하고 장애가 발생했을 때 이를 복구할 수 있도록 만드는 방법이다. 현재 프로젝트는 사용자 규모가 크지 않기 때문에 메시지 브로커나 CDC 시스템보다 해당 방법을 선택한 것이다. 만약 프로젝트가 더 방대하고 처리해야 할 데이터 규모가 크다면 이 방법보다 메시지 브로커, CDC 시스템을 활용하는 게 더 알맞을 것이다.