Lewis's Tech Keep
[Kafka] 아파치 카프카 애플리케이션 1장 본문
카프카의 탄생
파편화된 데이터 수집 및 분배 아키텍처 운영을 위해 탄생함
기존 카프카 도입 이전
- 데이터를 생성하고 적재하기 위해 데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타깃 애플리케이션을 연결해야 함
- 아키텍처가 거대해짐 -> 소스 애플리케이션과 타깃 애플리케이션 개수가 점점 많아짐, 데이터를 전송하는 라인이 기하급수적으로 복잡해지기 시작함
- 파이프라인 개수가 많아지면서 소스코드 및 버전 관리에서 이슈가 생김
- 타깃 애플리케이션 장애 -> 소스 애플리케이션으로 바로 전달됨
- 기존에 링크드인은 오픈소스와 ETL 툴을 적용해 변경하려고 노력했지만 해결은 못함

기존 카프카 도입 이후
- 각각 애플리케이션끼리 연결해 데이터 처리하지 않고 한 곳에 모아 처리하도록 중앙집중화함
- 소스 애플리케이션과 타깃 애플리케이션 사이 의존도를 최소화, 커플링 완화
- 한쪽의 이슈가 다른 한쪽 애플리케이션에 영향을 미치곤 했지만 그러한 의존도를 타파함
- 데이터 스트림을 한 곳에서 실시간 관리

- 카프카 내부 데이터 저장 방식은 FIFO 방식의 큐 자료구조와 유사함
- 큐에 데이터를 보내는 것 -> 프로듀서
- 큐에 데이터를 가져가는 것 -> 컨슈머
- 전달할 수 있는 데이터 포맷의 제한이 없음
- 직렬화, 역직렬화로 ByteArray로 통신함
- 자바에서 선언 가능한 모든 객체를 지원함
- 카프카는 최소 3대 이상의 서버(브로커)에서 분산 운영해 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록함
- 일부 서버에 장애가 발생하더라도 데이터를 지속적으로 복제하기 떄문에 안전
- 묶음 단위로 처리도 가능해 낮은 지연과 높은 데이터 처리량도 가지게 됨
카프카의 역할 (빅데이터 파이프라인에서)
- 빅데이터를 저장하고 활용하기 위해서 생성되는 데이터를 모두 모으는 것이 중요
- 데이터 레이크다.
- 빅데이터를 관리하고 사용하는 측면에서 중요한 용어다.
- 필터링, 패키지화되지 않은 데이터가 저장됨
- 데이터 레이크다.
- 추출 -> 변경 -> 적재하는 과정을 묶은 데이터 파이프라인을 구축해야함
- 안정적이고 확장성이 높은 데이터 파이프라인을 구축하는 것이 중요 (빅데이터에서)
높은 처리량
- 데이터를 보낼 때(프로듀서가), 데이터를 받을 때(컨슈머가) 모두 묶어서 전송함
- 많은 양의 데이터를 송수신할 때 맺어지는 네트워크 비용은 무시할 수 없는 규모임
- 동일한 양 데이터 보낼 때 통신 횟수를 줄이면 동일 시간 내 더 많은 데이터를 전송 가능
- 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬처리할 수 있음
- 파티션 개수만큼 컨슈머 개수를 늘려서 동일 시간당 데이터 처리량을 늘리는 것
확장성
- 가변적 환경에서 안정적으로 확장 가능
- 데이터 적을 때 -> 클러스터 브로커를 최소한의 개수로 운영
- 데이터 많을 때 -> 브로커 개수를 자연스럽게 늘려 스케일 아웃
- 다시 데이터 적어지면 -> 브로커 개수 줄여 스케일 인
영속성
- 프로그램이 종료되어도 사라지지 않은 데이터의 특성
- 카프카는 데이터를 파일 시스템에 저장함
- 페이지 캐시 영역을 메모리에 따로 생성하여 사용함
- 급작스럽게 종료되더라도 프로세스를 재시작해 다시 처리 가능
고가용성
- 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터 처리가능
- 데이터 복제를 통해 이러한 특징을 가지게 됨
- 1대의 브로커에만 저장하는 것이 아니라 다른 브로커에도 저장하는 것
- 온프레미스 환경의 서버 랙 또는 퍼블릭 클라우드의 리전 단위 장애에도 데이터를 안전하게 복제할 수 있는 옵션들이 있음
- min.insync.replicas 옵션으로 데이터 유실 가능성을 막을 수 있음
- ex. 2로 설정하고 브로커를 3대 이상 운영하면 1개의 브로커에 장애가 나더라도 지속적으로 처리가능
- 생태계 지탱하는 애플리케이션들이 도와줌

카프카의 미래 (데이터 레이크 아키텍처)
람다 아키텍처 & 카파 아키텍처
기존의 레거시 데이터 플랫폼 아키텍처
- 각 서비스 어플리케이션으로부터 데이터를 배치로 모았다.
- 유연하지 못하고 실시간 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못했다.
- 히스토리 파악 어려움 및 파편화로 데이터 표준 및 정책(데이터 거버넌스)를 지키기 어려웠음
람다 아키텍처
- 스피드 레이어라고 실시간 데이터 ETL 작업 영역을 정의한 아키텍처를 만듦

- 배치 레이어
- 배치 데이터를 모아서 특정 시간에 처리
- 서빙 레이어
- 데이터를 데이터 사용자, 서비스 애플리케이션이 사용할 수 있도록 데이터가 저장된 공간
- 스피드 레이어
- 서비스에서 생성되는 원천 데이터를 실시간으로 분석
- 낮은 지연으로 분석이 필요한 경우에 사용
- 람다 아키텍처에서 카프카의 위치
- 람다 아키텍처 단점
- 데이터 분석, 처리하는 데 필요한 로직이 2벌로 각각의 레이어에 따로 존재함
- 배치 데이터 & 실시간 데이터를 융합해 처리할 때 유연하지 못한 파이프라인을 생성해야 한다는 점
- 카파 아키텍처가 나옴
카파 아키텍처

- 카파 아키텍처가 나옴
- 배치 레이어를 제거함
- 카파 아키텍처 단점
- 스피드 레이어에서 모든 데이터를 처리하므로 모든 종류의 데이터를 스트림 처리해야 함
- 모든 데이터를 로그로 바라보는 것으로 시작
- 로그 = 데이터의 집합

- 카프카 내부에서 사용되는 파티션, 레코드, 오프셋은 제이 크렙스가 정의한 로그의 데이터 플랫폼 구현체라고 볼 수 있음
The Log: What every software engineer should know about real-time data's unifying abstraction
I joined LinkedIn about six years ago at a particularly interesting time. We were just beginning to run up against the limits of our monolithic, centralized database and needed to start the transition to a portfolio of specialized distributed systems. This
engineering.linkedin.com
'kafka > kafka 스터디' 카테고리의 다른 글
[Kafka] 아파치 카프카 애플리케이션 3.5장 & 관련 내용 발표 검색 (2) | 2024.01.01 |
---|