https://tech.kakao.com/posts/632

해결해야 할 문제:

• 서비스 팀들의 데이터를 취합하여 일단위의 지표를 추출하고 제공
• 지표 추출을 목적으로 서비스 조직의 데이터베이스에 접근하여 데이터를 가져오는 방식은 실 서비스의 운영에 부담
• 별도의 데이터베이스에서 지표 추출을 목적으로 데이터를 가져와야 하고, 이를 위해 **두 DB간 실시간 연동(CDC)**이 되야함.

Apache Flink란:

• 스트리밍 데이터를 처리하기 위해 만들어진 오픈소스 분산 처리 프레임워크
• 분산 처리를 지원합니다. 이 기능은 가용할 수 있는 자원이 충분하다면, 사용하는 자원에 비례하여 성능을 향상할 수 있는 이점이 있음 (예시: 실시간으로 처리하는 메시지의 양)
• Job Manager가 Flink job을 요청받고 분산 환경에서 실행할 수 있는 실행 그래프(Execution Graph)로 변환 -> Task Manager에게 생성된 Tasks 할당
• Task Manager에는 Task Slot이 있음. 태스크 슬롯을 간단하게 태스크를 수행하는 하나의 프로세스로 이해. CPU의 코어 수와 동일하게 태스크 슬롯을 할당하는 것을 권장.

CDC: 데이터의 변화와 변경을 추적하여 이를 실시간으로 반영하는 소프트웨어의 디자인 패턴

• 첫 단계: 최초 1회 데이터베이스의 테이블을 타겟 시스템에 덤프 또는 복사하는 스냅샷(Snapshot) 단계
• 두번째 단계: 데이터베이스의 **바이너리 로그(Binary log)**를 실시간으로 읽어 변화분을 타겟 시스템에 반영하는 빈로그 스트림(Binlog Stream) 단계

GTIDs:

• 데이터베이스 서버의 유니크한 식별자(UUID)와 데이터베이스 트랜잭션의 아이디(Transaction ID) 또는 구간(Range)으로 구성

• GTIDs는 소스 데이터베이스 서버 바이너리 로그의 특정 위치를 가리킴

  Debezium: DB의 변경 사항을 실시간으로 캡처하고 이를 메시지 시스템(Kafka 등)을 통해 스트리밍 방식으로 전달하는 (CDC) 플랫폼

• Snapshotting

  • 증분 스냅샷 (Incremental Snapshot) 기능 지원 (병렬로 수행 가능)
  • 일반적인 스냅샷은 db에 lock이 걸리는 문제, but 증분 스냅샷은 부분부분 chunk단위로 스냅샷 떠서 db에 lock을 안걸어도 됨

• Change Streaming

  • 변경 로그(예: MySQL의 binlog, PostgreSQL의 WAL, MongoDB의 Oplog)를 모니터링하여 변경 이벤트를 캡쳐

• Commit Log Monitoring

  • DB의 커밋 로그(Transaction Log)를 지속적으로 모니터링
  • 변경 사항이 커밋될 때만 이를 캡처하여 메시지로 전송하기 때문에 데이터 일관성과 무결성을 유지