이 글은 책 내용을 토대로 작성하였습니다.
목차
DB와 스트림
-
앞선 글에서 이야기했듯이
이벤트란 특정 시점에 발생한 사건을 기록한 레코드다.
-
그러면 DB에 어떤 데이터를 저장한다는 것을 상세히 쪼개어 보면
DB에 뭔가를 기록한다는 것은
저장할 데이터를 캡처해서 저장하고 처리할 수 있는 하나의 이벤트라고 볼 수 있다.
시스템 동기화 유지하기
-
대부분의 어플리케이션은 요구사항을 만족하기 위해 n개의 시스템을 사용한다.
그러므로 이러한 n개의 시스템들은 서로 동기화된 데이터를 갖고있어야한다.
-
예를 들어 DB에 데이터를 갱신한다고 하면
캐시, 인덱스, 데이터 웨어하우스도 같이 갱신해야 한다.
-
데이터 웨어하우스에서는 이 동기화 과정을 ETL 과정에서 수행한다.
ETL(Extract, Transform, Load) 이란?
- DB 전체를 복사하고 변환 후 데이터 웨어하우스로 벌크 로드 한다.
이중 기록 (Dual Write)
-
ETL과 같은 DB 전체를 덤프하는 작업이 부담스럽다면
그 대안으로 사용하는 방법으로 이중 기록(Dual Write)가 있다.
-
이중 기록을 사용하면 데이터가 변할 때마다
어플리케이션 코드에서 명시적으로 각 시스템이 요청을 보낸다.
ex) DB에 기록 -> 검색 인덱스 갱신 -> 캐시 업데이트
이중 기록의 단점
- 이중 기록의 단점으로는 경쟁 조건이 있다.
- 두 클라이언트는 동시에 아이템 X에 대해 업데이트 시도한다.
- 클라1 : A / 클라2 : B
- 각 클라이언트는 먼저 DB에 새 값을 추가 후 Search Index를 업데이트한다.
- 그런데 여기서 어떠한 이유로 요청이 서로 교차하는 상황이 발생한다.
1. 클라1이 DB에 값 수정 (X=A)
2. 클라2가 DB에 값 수정 (X=B)
3. DB의 최종 값은 B이다.
4. 인덱스는 클라2가 먼저 수정 (X=B)
5. 클라1이 이 후 인덱스 수정 (X=A)
6. 인덱스의 최종 값은 A이다.
- 두 시스템은 오류가 발생하지 않았음에도 일치하지 않는다.
변경 데이터 캡처
-
변경 데이터 캡처(Change Data Capture, CDC)는
DB에 기록하는 모든 데이터의 변화를 관찰해
다른 시스템으로 데이터를 복제할 수 있는 형태로 추출하는 과정이다.
-
CDC는 데이터가 기록되자마자 변경 내용을 스트림으로 제공할 수 있으면 특히 유용하다.
-
예를 들면 DB 변경 사항을 캡처해
같은 변경 사항을 검색 인덱스에 꾸준히 반영할 수 있다.
같은 순서로 로그 변경이 반영된다면 DB의 데이터와 인덱스는 일치할 것이다.
-
아래 그림을 보면 검색 인덱스뿐만 아니라
다른 파생 데이터 시스템도 변경 스트림의 소비자가 될 수 있다.
변경 데이터 캡처의 구현
-
CDC는 로그를 소비하는 시스템(=파생 데이터 시스템)이
DB(=레코드 시스템)의 정확한 데이터 복제본을 가지게 하기 위해
레코드 시스템에 발생하는 모든 변경 사항을
파생 데이터 시스템에 반영하는 것을 보장하는 메커니즘이다.
// 용어가 너무 낯설어서 그렇지 어렵지 않은 문장이다.
-
CDC는 변경 사항을 캡처할 DB 하나를 리더로 하고 나머지를 팔로워로 한다.
-
로그 기반 메시지 브로커는 원본 DB에서 변경 이벤트를 전송하기 적합하다.
왜냐면 로그 기반 메시지 브로커는 이미 메시지 순서를 유지하기 때문이다.
-
CDC는 메시지 브로커와 같게 비동기 방식으로 동작한다.
= DB의 변경 사항을 커밋하기 전에 변경 사항이 소비자에게 적용될 때까지 기다리지 않는다.
DB 트리거
-
CDC를 구현하는데 DB 트리거를 사용하기도 한다.
DB의 모든 변화를 관찰하는 트리거를 등록하고
변화가 발생 시 트리거는 변경 로그 테이블(=Log of data changes)에 해당 항목을 추가한다.
ex) 링크드인의 데이터버스(Databus), 페이스북의 웜홀(Wormhole)