아파치 카프카 - 애플리케이션 프로그래밍 with 자바 (1)

1.1 카프카 탄생

• 탄생 배경
  소스 애플리케이션과 타깃 애플리케이션을 연결하는 개수가 많아짐.
  → 장애 발생 시, 소스 애플리케이션에 그대로 전달.
• 해결
  애플리케이션 끼리 연결이 아니라, 한곳에 모아 처리할 수 있도록 중앙 집중화.
  → 의존도 최소화 (어느 타깃 애플리케이션에 넣을지 고민 없이 카프카에 넣기)
• 파티션 동작
  파티션 내에서는 FIFO 방식의 큐 자료구조와 유사.
  다른 파티션끼리는 순서 보장은 되지 않음.
• 데이터 형식
  직렬화, 역직렬화로 통신하여 사실상 제한 없음.
• 기술 용어
  • 프로듀서 : 큐에 데이터를 보냄
  • 컨슈머 : 큐에서 데이터를 가져감.
  • 브로커(서버) : 메시지를 전송하고 관리하는 역할.
  • 데이터 레이크 : 생성되는 데이터를 모두 모으는것
  • 데이터 파이프 라인
    데이터 수집 → 변경 → 적재의 자동화한 것.
• 높은 처리량
  데이터를 보낼때와 받을 떄 모두 데이터 묶음으로 받아, 빠르게 처리.
• 확장성
  데이터가 많을때/적을때 스케일 아웃과 스케일 인이 가능.
  → 브로커의 개수 변화
• 고가용성
  3대 이상의 브로커들의 복제를 통해서 무중단으로 안전하고 지속적인 데이터 처리 가능
  • 온프레미스 환경의 서버랙 & 퍼블릭 클라우드 모두 브로커 옵션 구비
  • 3대 이상의 브로커가 필요한 이유?
    브로커간의 복제되는 시간차이로 인해 유실 가능성 있어서.

1.3 데이터 레이크 아키텍처와 카프카의 미래

• 데이터 레이크 아키텍처
  1. 람다 아키텍처
     디버깅
     배포, 운영 분리에 대한 이슈
     로직의 파편화
  2. 카파 아키텍처.
     배치 레이어 제거, 스피드 레이어에서 데이터 모두 처리
     → 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리 해야함

- 배치 데이터
일반적으로 배치 데이터는 각 시점의 전체 데이터의 스냅샷
배치 데이터를 로그로 표현할때에는 변환 기록을 시간 순서대로 기록함으로써 스트림 처리 가능