서론

카프카의 탄생

기존에는 단방향 통신을 통해 소스 애플리케이션에서 타깃 애플리케이션으로 연동하는 소스코드를 작성했고, 아키텍처가 복잡하지 않았다.
- 데이터를 생성하는 소스 애플리케이션, 데이터가 최종 적재되는 타깃 애플리케이션
그러나 시간이 지날수록 아키텍처는 거대해지고, 데이터를 전송하는 라인이 복잡해지기 시작했다. 파이프라인 갯수도 많아져 소스코드 및 버전 관리에서 이슈가 생겼다.
- 파이프라인은 산술적인 단계가 병렬처리되는 것으로, 프로세서의 산술연산 부분이 쉬지 않음으로 동일 시간에 더 많은 연산을 수행할 수 있는 장점이 있다.
링크드인에서, 자사에서 발생하는 이슈를 해결하고자 개발된 기술이다. 링크드인에서 사용하던 기존 아키텍처에서는 1) 통합된 데이터 전송 영역의 부재로 데이터 처리의 복잡도가 증가했고, 2) 데이터 파이프라인의 관리가 어려웠다는 문제점이 있었다. 때문에 특정 부분을 수정해야 할 때도 연관된 부분을 모조리 찾아 수정해야 하는 경우도 있었다.

카프카는 각각의 애플리케이션끼리 연결하여 데이터를 처리하는 것이 아니라 한 곳에 모아 처리할 수 있도록 중앙집중화했다. 그래서 소스 및 타깃 애플리케이션 사이의 의존도를 최소화했다.

카프카에서 리더와 팔로워 노드가 확인했는데, 이들 간의 데이터 동기화 작업을 매우 중요하게 처리하고 있다.
리더는 Read/Write를 하고, 팔로워는 주기적으로 리더의 데이터를 보며 복제만 한다. 리더가 있는 브로커가 장애가 난다면 팔로워는 새로운 리더가 될 수 있다.
이런 개념으로 ISR는 현재 리플리케이션이 되고 있는 복제 그룹을 의미한다.

많은 양의 데이터를 묶음 단위로 처리하는 배치로 빠르게 처리할 수 있다.
파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬처리 할 수 있다. 즉, 파티션 개수만큼 컨슈며 개수를 들려서 동일 시간당 데이터 처리량을 늘릴 수 있다.

클러스터로 이루어진 카프카는 데이터의 복제를 통해 고가용성의 특징을 갖는다.
프로듀서→클러스터(토픽)→컨슈머의 구조를 갖는데, 프로듀서로 전송받은 데이터를 여러 브로커 중 1대의 브로커에만 저장하는 것이 아니라 또 다른 브로커에도 저장하기에 장애가 한 곳에 발생했더라도 저장된 데이터가 또 다른 브로커에도 존재하므로 지속적으로 데이터 처리가 가능하다.

웹 사이트에 접속하여 페이지 이동, 특정 컨텐츠 조회 등을 수행하면 이것에 관한 메시지 데이터를 생성하는 프론트엔드 앱이 동작한다. 페이지 뷰와 클릭 기록 등을 카프카로 보내면 백엔드에서 리포트를 생성하거나, 머신 러닝 시스템에 제공하는 등의 작업을 한다.

사용자에게 알림 메시지(이메일 등)를 전송하는 애플리케이션에 유용하다. 각 애플리케이션에서 전송될 모든 메시지를 카프카로 보내서 카프카에서 알림 메시지로 애플리케이션으로 보내 사용자가 원하는 수신방법을 적용하여 사용자에게 보낸다.

애플리케이션과 시스템의 메트릭과 로그 데이터를 모으는데 이상적이다. 각 애플리케이션에서 카프카 토픽으로 저장한 후 모니터링과 보안 시스템이나 하둡 등에서 사용될 수 있다. 또는 ElasticSearch에서도 사용될 수 있다.

카프카는 커밋 로그를 기반으로 한다. 커밋 로그는 데이터가 변경된 내역을 로그 메시지로 모아둔 것을 말한다.
데이터베이스의 변경 사항이 카프카 메시지 스트림으로 생성될 수 있다. 애플리케이션에서는 해당 스트림을 모니터링하여 발생 시점의 최신 변경 데이터를 받을 수 있으며 **변경 로그 스트림(changelog stream)**이라고 한다.
변경 데이터를 원격 시스템에 복제하거나, 여러 애플리케이션의 변경 데이터를 하나의 데이터베이스 뷰로 통합할 수 있다.
변경 데이터를 모아두는 버퍼를 카프카의 메시지 보존 기능으로 사용할 수 있다.

cf: