epicblues
commented
7 months ago 이벤트 소싱
vs 변경 데이터 캡처
- 변경 데이터 캡처는 데이터베이스의 레코드의 쓰기 작업들을 순서대로 추출한 것
- 애플리케이션은 레코드를 자유롭게 조작할 수 있음
- 로그는 레코드 쓰기 작업으로 부터 파생된 저수준 데이터
- 해당 로그에 대한 해석을 별도로 진행해야 함
- 이벤트 소싱은 이벤트를 애플리케이션이 직접 입력
- 이벤트를 고수준에서 다룰 수 있음
- DB 세부 사항에 제약을 받지 않음
현재 상태 파생
- 모든 이벤트를 순서대로 불러와야함
- 최적화 이슈
- 로그 컴팩션이 불가능
- 뒤에 발생한 이벤트가 앞서 발생한 이벤트를 덮어쓰지 않음
- 스냅샷으로 보완
- 로그 컴팩션이 불가능
명령과 이벤트
- 반드시 구분해야 한다.
- 사용자 요청(명령) ≠ 이벤트
- 명령 → 실행 가능 여부 확인 → 실행 → 이벤트
- 따라서
모든 유효성 검사는 이벤트가 되기 전에 이루어져야 한다.
상태와 스트림 그리고 불변성
- 이벤트들을 적분하면 상태가 된다
- 상태는 변경 로그의 부분 집합 캐시
- = 로그 컴팩션
이벤트 로그의 장점
- 하나의 이벤트 로그로부터 다양한 읽기 전용 뷰 생성 가능
- 기존 읽기 뷰의 수정 없이 새로운 읽기 전용 뷰를 병행에서 운용할 수 있음
- 스키마 마이그레이션보다 훨씬 쉽다
- CQRS
- 데이터 쓰기 형식 ≠ 읽기 형식
- ex) 쓰기는 이벤트 로그 방식, 읽기는 Document DB (일대다 조회 쉬움)
- 데이터 쓰기 형식 ≠ 읽기 형식
- 기존 읽기 뷰의 수정 없이 새로운 읽기 전용 뷰를 병행에서 운용할 수 있음
동시성 제어
- 읽기 뷰 갱신 - 이벤트 추가 작업 동기화
- 이벤트 소싱
- 파티셔닝
- 이벤트 로그 - 애플리케이션 상태 저장소를 동일 파티셔닝에 두기
- 단일 스레드로 한 번에 하나의 로그만 처리
불변성의 한계
- 데이터 크기가 커지면 성능 이슈
- 요구사항에 따라 해당 이벤트 자체를 삭제해야 하는 경우
- 복제본 많음
- 히스토리를 새로 작성해야 함
스트림 처리
vs 일괄 처리
- 동일
- 파티셔닝, 데이터 조인, 입력 불변성 등
- 다른점
- 끝이 없는 데이터 → 정렬 불가능
- sort merge join 불가능
- 내결함성
- 오랜 시간 실행된 스트림 작업을 다시 시작할 수 있을까?
복잡한 이벤트 처리
- 각 이벤트 스트림에 정적 질의가 붙음
- 기존 데이터베이스와 다른 방식
- 질의가 영원하고 데이터는 계속 변한다.
- 기존 데이터베이스와 다른 방식
스트림 분석
- 특정 윈도우 안에서 발생된 이벤트들을 집계해서 분석
시간 논쟁
- 이벤트 발생 시점≠ 처리 시점 불일치
- 네트워크, 호스트 장비 이슈 등
- 타임 스탬프 정하기
- 실제 사용자가 상호 작용한 시간을 타임스탬프로
- 장치 시계 불일치 해결하기
- 세 가지 타임스탬프
- 이벤트 발생 시간(장치 시계)
- 이벤트 서버 보낸 시간(장치 시계)
- 서버에서 이벤트를 받은 시간 (서버 시계)
- 2와 3의 차이로 서버와 장치의 시간 차이 offset을 구하고 실제 이벤트 발생 시간을 추정한다.
- 세 가지 타임스탬프
- 장치 시계 불일치 해결하기
- 실제 사용자가 상호 작용한 시간을 타임스탬프로
- 윈도우 유형
- 고정 윈도우(텀블링 윈도우)
- 홉핑 윈도우
- 고정 크기
- 윈도우 중첩 허용
- 슬라이딩 윈도우
- 시간 흐름에 따라 윈도우를 벗어난 이벤트 제거
- 세션 윈도우
- 각 사용자 별로 발생한 이벤트를 짧은 시간 단위로 보관
스트림 조인
스트림 스트림 조인
- 윈도우 기반으로 조인
- 해당 윈도우 안에서 상태 관리
- 새로 발생한 이벤트의 key값을 통해 기존 이벤트와 조인
- 해당 윈도우 안에서 상태 관리
스트림 테이블 조인(스트림 강화)
- 스트림으로 들어오는 이벤트들을 고정된 테이블에 조인 질의
- 각 이벤트들에 추가 정보가 붙는 방식(강화)
- 테이블 주기적으로 최신으로 갱신해야 함
- CDC로 보완 가능
테이블 테이블 조인(구체화 뷰 유지)
- 각 입력 스트림들은 테이블로 변환
- 변환된 테이블을 join 연산
- 테이블을 반환(다른 스르림 조인은 레코드를 반환_
내결함성
- 마이크로 일괄 처리
- 작은 단위의 윈도우(ex: 1초)로 나눠서 일괄 처리
- 응답 시간 낮아짐
- 복구 시 중복 부수 효과 발생 가능
- 이메일 중복 전송 등
- 원자적 커밋 재검토
- 처리가 성공했을 때만 출력/부수 효과 발생
- 동기화 이슈 있을 수 있음(분산 트랜잭션 ㄷ ㅇ)
- 멱등성
- 여러 번 수행해도 한 번 수행한 것과 같은 효과
- 멱등하지 않은 연산은 각 이벤트에 대한 오프셋으로 순서 보장
- 갱신이 이미 적용된 연산은 대상 오프셋이 변경됐기 때문에 해당 연산을 버린다.
실패 후 상태 재구축
- 상태 복제
- 주기적인 스냅숏 캡쳐
- 입력 스트림 재실행
일괄 처리와 이벤트 스트림
이벤트
메시징 시스템
전통적인 방법(파일, DB)으로도 스트림 처리는 가능하다
하지만 polling 오버헤드가 너무 크다
→ 이벤트를 메시징 시스템으로 전달하자!
구현 방식
if 생산자 속도 > 소비자 속도변경 데이터 캡쳐
DB의 복제 로그는 이벤트의 성질을 가짐 ⇒ 활용해보자
변경 스트림 전용 API
복제 로그는 raw하다
⇒ 데이터 변경 사항 이벤트를 구성해서 구독자들에게 직접 전달