MSA 마이그레이션 : 데이터 해방

모놀리식 기반의 레거시 시스템을 이벤트 기반 아키텍처로 전환하는 것은 여러 기업이 성장하면서 새로운 비즈니스 요건을 충족해야 하거나 규모를 늘릴 때 많이 거쳐가는 단계이다.

 

오늘은 이 과정에서 이벤트 기반 마이크로서비스 아키텍처로 마이그레이션할 때 필요한 "데이터 해방"에 대해 얘기해보려고 한다.

 

0. 데이터 해방이란?

데이터해방(data liberation)은 교차 도메인 데이터 세트(cross-domain data set)를 식별하여 각 이벤트 스트림에 발행하는 이벤트 기반 아키텍처의 마이그레이션 전략이다.

 

나는 '해방'의 의미를 '놓아주다'로 해석했는데, 기존(레거시) 비즈니스 도메인에 묶여있는 데이터들을 다른 서비스가 소비(이벤트 등)할 수 있도록 데이터를 소싱하는 과정이라고 해석했다.

 

데이터를 해방하면 단일 진실 공급원(factor)을 제공하고, 시스템 간 직접 결합을 방지할 수 있다.

 

데이터 해방 이후 워크플로

 

당연한 얘기지만, 레거시 시스템의 데이터 세트와 이벤트 스트림은 완전히 동기화 되어야 한다.

 

이벤트 발행 중 찰나의 순간에는 데이터가 다를 수 있지만, 최종 일관성(eventual consistency)으로 결국 동기화가 될 것이다.

 

가장 우선적으로 해방시켜야 할 데이터는 가장 연관성이 많고 자주 사용하는 데이터이다.

 

1. 데이터 해방 패턴

데이터를 해방한다는 것은 결국 새로운 단일 진실 공급원을 만든다는 것이다.

 

따라서 DB의 전체 데이터 세트를 담아야 하고, 이후로 데이터를 삽입, 수정, 삭제하면서 최신 상태로 유지해야 한다.

 

쿼리 기반(query-based)

하부 데이터 저장소를 쿼리하여 데이터를 추출한다.

 

DB의 종류와 상관없이 작업이 가능하다.

 

로그 기반(log-based)

하부 데이터 구조의 변경 내용을 기록한 로그를 기준으로 데이터를 추출한다.

 

데이터 변경 로그를 지원하는 DB만 가능하다.

 

테이블 기반(table-based)

출력 큐로 사용할 테이블에 데이터를 푸시하고, 다른 스레드나 프로세스가 테이블을 쿼리하여 데이터를 이벤트로 발행한다.

 

DB가 트랜잭션 및 출력 큐 메커니즘을 모두 지원하는 경우에만 가능하다.

 

세 가지 패턴은 모두 최근 업데이트 시간(created_at) 컬럼을 이용하여 순서대로 생산한다는 공통점이 있다.

 

 

2. 데이터 해방 프레임워크

데이터 해방을 위한 여러 프레임워크는 아래와 같다.

• 카프카 커넥트 (Kafka Connect)
• 아파치 고블린 (Apache Gobblin)
• 아파치 나이파이 (Apache NiFi)

반드시 전용 프레임워크가 있어야 데이터 해방 프로세스가 가능한 것은 아니고, 직접 생산하는 것이 적합한 시스템도 많다.

 

실제로 프레임워크는 안티 패턴을 조장할 수도 있고, 데이터 모델을 노출시켜 결합도를 증가시키는 경우도 있다.

 

따라서 웬만하면 팀에서 직접 데이터 해방 프로세스를 직접 구현하는게 낫다.

 

 

3. 쿼리 기반 데이터 해방

DB 쿼리 결과를 이벤트로 발행하는 패턴이다.

 

클라이언트가 API, SQL 언어 등을 이용하여 원하는 데이터 세트를 요청하면, 데이터 세트는 최초 1회 벌크 쿼리한 후 주기적으로 업데이트 하여 출력 이벤트 스트림에 생산한다.

 

3-1. 벌크 로딩

벌크 쿼리를 실행하여 전체 데이터를 로드하고 주기적으로 폴링하며 전체 테이블을 로드하는 방식이다.

 

벌크 로드는 전체 데이터 세트를 가져오기 때문에 비용이 많이 든다.

 

 

3-2. 증분 타임스탬프 로딩

이전 쿼리 결과의 최종 타임스탬프(updated_at)을 기준으로 필요한 데이터만 쿼리하여 적재하는 방식이다.

 

3-3. 자동 증가 ID 로딩

타임스탬프 로딩과 비슷하게, 자동 증가 ID (AutoIncreament ID)를 이용하여 마지막으로 쿼리된 ID를 기준으로 적재하는 방법이다.

 

자동증가 정수 또는 Long 타입 필드가 필요하다.

 

불변 레코드가 있는 테이블을 쿼리할 때 자주 사용하는 방법이다.

 

💡 증분 업데이트의 경우, 폴링 빈도와 업데이트 지연 시간을 잘 정해야 한다.
업데이트를 자주하면 업데이트 지연이 줄어들지만 저장소에 걸리는 부하량이 늘어나고,
폴링 빈도가 높아지면 앞 쿼리 로드 중 다시 쿼리를 실행하며 새 데이터를 덮어쓰는 race condition이 발생한다.

 

3-4. 맞춤 쿼리

클라이언트 쿼리 언어로 제한하여 대용량 데이터 중 일부만 필요하거나 데이터 모델의 노출을 막을때 여러 테이블을 조인하고 반정규화 할때 사용한다.

 

각 제휴사별 필요한 데이터만 필터링해서 보내는 경우 알맞는 방식이다.

 

쿼리 기반 업데이트의 장점

• 맞춤성
  • 모든 데이터 저장소를 쿼리할 수 있고, 클라이언트가 마음껏 쿼리 옵션을 지정할 수 있음.
• 독립적 폴링 주기
  • SLA가 엄격한 쿼리는 실행 빈도를 높이고, 그 외는 낮추는 식으로 리소스를 전략적으로 절약할 수 있음.
• 내부 데이터 모델 격리
  • RDB내 뷰 객체를 이용하여 내부 데이터 모델과 분리할 수 있음. 민감한 데이터 모델의 노출을 막을 수 있음.

 

SLA(Service Level Agreement)
서비스 수준 계약(SLA) : 서비스 제공업체와 고객 간의 계약으로, 제공될 서비스와 예상되는 성능 수준을 뜻한다.
SLA가 엄격하다는 것은 빠른 응답과 가능한 최신 데이터를 제공해야 함을 뜻한다고 할 수 있겠다.

 

쿼리기반 업데이트의 단점

• 타임스탬프 필수
  • 테이블에 반드시 타임스탬프가 있어야 함.
• 하드 삭제 추적 불가
  • 하드 삭제(hard delete)는 쿼리 결과에 들어나지 않음. 플래그 기반의 soft delete만 추적 가능함.
• 데이터 세트 스키마 - 이벤트간 취약한 의존 관계
  • 이벤트의 스키마가 호환되지 않는 방식으로 데이터 스키마가 변경될 가능성이 존재함.
• 간헐적 캡쳐
  • 일정 주기로 폴링되기 때문에 동일한 레코드에 대한 일련의 변경들은 각자 개별적 이벤트로만 보임.
• 생산 리소스 낭비
  • 쿼리 사용시 시스템 리소스 사용하므로 지연시간이 커질 수 있음.
  • 읽기 전용 replica로 해소할 순 있지만 추가 비용과 복잡도가 증가
• 데이터 변경에 의한 쿼리 성능 가변성
  • 쿼리 결과의 데이터가 일정하지 않기 때문에 쿼리 성능도 일정하지 않음
  • 폴링 주기에 의해 이전 쿼리 완료 전 다음 쿼리가 실행되면서 race condition이 발생할 수 있음.

 

4. 로그 기반 데이터 해방 - CDC

해당 내용은 이미 몇 번 다뤘던 내용이다.

 

DB에 내장된 CDC 로그 기능을 활용하는 방법이다.

 

DB내에서 발생하는 모든 일이 전용 로그 형태로 남겨지면, 해당 기록을 이용하여 이벤트로 발행하는 것이다.

 

모든 DB가 지원하는 기능은 아니지만, MySQL(binlog), PostgreSQL(write-ahead log) 등 몇몇 많이 쓰는 RDB에서는 지원한다.

 

마이그레이션 하는 과정에서는, 처음부터 발생한 변경 기록을 모두 포함하고 있지 않기 때문에 시작 전 기존 데이터의 스냅샵을 찍어야 한다.

 

이 과정을 부트스트래핑(bootstrapping)이라고 한다.

 

체인지 로그(change log)로부터 데이터를 소싱하는 툴로는 Debezium이 유명하다.

 

데이터 저장소 로그의 장점

• 삭제 추적
  • 쿼리 기반과 달리 로그에 레코드 삭제가 포함되기 때문에 삭제 이벤트도 변환할 수 있다.
• DB영향 최소화
  • 선행 기입 로그, 바이너리 로그는 DB 성능에 별 영향 없이 수행할 수 있다.
• 저지연 업데이트 (low-latency updates)
  • 로그에 기록되면 바로 업데이트를 전파한다. 다른 데이터 해방 패턴보다 지연시간이 아주 짧다.

 

데이터 저장소 로그의 단점

• 내부 데이터 모델 노출
  • 내부 데이터 모델이 체인지 로그에 의해 완전히 노출된다.
• DB 외부에서의 반정규화
  • 대부분 DB 외부에서 반정규화가 일어난다. 따라서 정규화한 이벤트를 생성해야 할 수 있는데, 그를 위해 외래키 조인 및 반정규화를 처리해야 한다.
• 데이터 스키마 - 출력 이벤트 스키마 간 취약한 의존 관계
  • 보통 데이터 해방 프로세스가 저장소 애플리케이션 외부에 존재하므로 데이터 스키마 변경 시 이벤트 스키마와 호환되지 않을 수 있다.

 

5. 테이블 기반 데이터 해방 - 아웃박스 테이블

아웃박스 테이블에 DB 데이터 업데이트가 로우 단위로 삽입되고, 데이터가 변경될 때 마다 새로 발행되는 방식.

 

내부 테이블 업데이트와 아웃박스 테이블 업데이트를 단일 트랜잭션으로 묶어 이벤트와 DB 트랜잭션의 정합성을 보장하는 방법이다.

 

이벤트의 적어도 한 번 전달 (at-least-once)를 보장할 수 있다.

 

해당 패턴은 짧은 시간동안 같은 레코드가 여러번 업데이트 될 가능성이 있기 때문에 PK가 명확해야 한다.

 

또한, 자동 증가 ID를 활용하여 발행 순서를 보장할 수도 있다.

 

Outbox vs CDC

아웃박스 패턴은 새로운 엔티티를 정의하고, 이벤트 저장/발행 모두 DB에 부하를 준다.

 

데이터 양이 적으면 정합성을 보장하는 좋은 방법이지만, 데이터 양이 많다면 CDC 로그 파싱 전략을 고려하는 등 프로젝트마다 비용에 따라 선택하는 것이 중요할 것이다.

 

스키마 호환성 보장

아웃박스 테이블에 스키마를 보장할 수 있는 가장 강력한 방법은 아웃박스 테이블 트랜잭션 전 직렬화를 하는 것이다.

 

직렬화가 실패하면 결국 트랜잭션도 실패하니 내부 테이블을 모두 롤백시켜 아웃박스 테이블과 내부 테이블을 동기화할 수 있다.

 

이를 통해 내부 상태와 이벤트 간의 데이터 정합성이 안 맞을 가능성을 줄일 수 있다.

 

이벤트 스키마의 호환성을 보장하는 방법 : 트랜잭션 전 직렬화

 

아웃박스 테이블의 장점

• 다수 언어 지원
• 사전 스키마 강화
  • 아웃박스 테이블 삽입 전 직렬화로 스키마 호환 확인 가능
• 내부 데이터 모델 격리
  • 아웃박스 테이블 필드에 원하는 필드만 넣음으로써 발행할 데이터를 고를 수 있음
• 반정규화
  • 아웃박스 테이블 저장 전 필요한 만큼 반정규화 가능

 

아웃박스 테이블의 단점

• 코드 변경 필수
  • 애플리케이션 내 코드를 필수적으로 변경해야 함
• 비즈니스 프로세스 성능에 영향
  • 특히 직렬화를 통한 스키마 유효성 검증 과정에서 비즈니스 프로세스에 영향을 줄 수 있음.
  • 또는 트랜잭션 실패 시 비즈니스 작업 중단됨
• DB 성능 영향

 

6. 번외 - 트리거

DB내에서 트리거 기능을 활용하여 아웃박스 테이블에 적재하는 방법이다.

 

트리거는 오래 전부터 사용해왔던 기술로, 구형 RDB는 대부분 감사 테이블 생성 수단으로 트리거를 사용한다.

 

정해진 조건에서 자동 실행되도록 설정하며, 실패 시 트리거를 일으킨 커맨드도 실패하여 원자적 업데이트가 보장된다.

 

트리거는 DB 내부에서 실행되므로 지원하지 않거나 제한된 언어로 사용되는 경우가 많다.

 

또한 각 트리거가 독립적으로 작동하며 데이터, 스키마, 검증 로직을 담아두는 오버헤드가 크고 로드하는 비용도 크다.

 

보통 오래된 기술이 적용된 레거시 시스템에서 잘 작동하며, CDC 메커니즘을 구현하기 알맞은 기술이다.

MySQL 5.0.2부터 트리거를 지원한다.

 

트리거의 장점

• 대부분의 DB가 지원
• 데이터 규모가 작을 경우 오버헤드가 작음
• 맞춤 로직 가능

 

트리거의 단점

• 큰 성능 오버헤드
• 복잡한 변경 관리
• 낮은 확장성
• 사후 스키마 강화
  • 발행할 수 없는 이벤트가 아웃박스 테이블에 섞일 수 있음.

 

---

 

성공적인 이벤트 기반 아키텍처로 전향하기 위해서는 트레이드 오프를 고려하여 프로젝트에 맞는 전략을 잘 선택하고, 중요한 데이터가 깨끗하고 일관되게 담길 수 있도록 하는 것이 중요하다.

 

실제로 스키마의 변경으로 인해 컨슈머가 오류를 일으키는 일이 많음으로 변경을 최소화하고, 웬만하면 중앙화된 프레임워크에 의존하지 않고 팀 스스로 CDC를 구현하는 것이 좋다.

 

참고
Building Event-Driven Microservices: Leveraging Organizational Data at Scale, 애덤 벨메어