[Kafka] 아파치 카프카 애플리케이션 1장

카프카의 탄생

파편화된 데이터 수집 및 분배 아키텍처 운영을 위해 탄생함

 

기존 카프카 도입 이전

• 데이터를 생성하고 적재하기 위해 데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타깃 애플리케이션을 연결해야 함
• 아키텍처가 거대해짐 -> 소스 애플리케이션과 타깃 애플리케이션 개수가 점점 많아짐, 데이터를 전송하는 라인이 기하급수적으로 복잡해지기 시작함
• 파이프라인 개수가 많아지면서 소스코드 및 버전 관리에서 이슈가 생김
• 타깃 애플리케이션 장애 -> 소스 애플리케이션으로 바로 전달됨
• 기존에 링크드인은 오픈소스와 ETL 툴을 적용해 변경하려고 노력했지만 해결은 못함

도입 이전 아키텍처

 

기존 카프카 도입 이후

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

카프카 도입 이후 파이프라인 아키텍처

• 카프카 내부 데이터 저장 방식은 FIFO 방식의 큐 자료구조와 유사함
• 큐에 데이터를 보내는 것 -> 프로듀서
• 큐에 데이터를 가져가는 것 -> 컨슈머
• 전달할 수 있는 데이터 포맷의 제한이 없음
• 직렬화, 역직렬화로 ByteArray로 통신함
  • 자바에서 선언 가능한 모든 객체를 지원함
• 카프카는 최소 3대 이상의 서버(브로커)에서 분산 운영해 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록함
• 일부 서버에 장애가 발생하더라도 데이터를 지속적으로 복제하기 떄문에 안전
• 묶음 단위로 처리도 가능해 낮은 지연과 높은 데이터 처리량도 가지게 됨

---

카프카의 역할 (빅데이터 파이프라인에서)

• 빅데이터를 저장하고 활용하기 위해서 생성되는 데이터를 모두 모으는 것이 중요
  • 데이터 레이크다.
    • 빅데이터를 관리하고 사용하는 측면에서 중요한 용어다.
    • 필터링, 패키지화되지 않은 데이터가 저장됨
• 추출 -> 변경 -> 적재하는 과정을 묶은 데이터 파이프라인을 구축해야함
• 안정적이고 확장성이 높은 데이터 파이프라인을 구축하는 것이 중요 (빅데이터에서)

높은 처리량

• 데이터를 보낼 때(프로듀서가), 데이터를 받을 때(컨슈머가) 모두 묶어서 전송함
• 많은 양의 데이터를 송수신할 때 맺어지는 네트워크 비용은 무시할 수 없는 규모임
• 동일한 양 데이터 보낼 때 통신 횟수를 줄이면 동일 시간 내 더 많은 데이터를 전송 가능
• 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬처리할 수 있음
• 파티션 개수만큼 컨슈머 개수를 늘려서 동일 시간당 데이터 처리량을 늘리는 것

확장성

• 가변적 환경에서 안정적으로 확장 가능
• 데이터 적을 때 -> 클러스터 브로커를 최소한의 개수로 운영
• 데이터 많을 때 -> 브로커 개수를 자연스럽게 늘려 스케일 아웃
• 다시 데이터 적어지면 -> 브로커 개수 줄여 스케일 인

영속성

• 프로그램이 종료되어도 사라지지 않은 데이터의 특성
• 카프카는 데이터를 파일 시스템에 저장함
• 페이지 캐시 영역을 메모리에 따로 생성하여 사용함
• 급작스럽게 종료되더라도 프로세스를 재시작해 다시 처리 가능

고가용성

• 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터 처리가능
• 데이터 복제를 통해 이러한 특징을 가지게 됨
• 1대의 브로커에만 저장하는 것이 아니라 다른 브로커에도 저장하는 것
• 온프레미스 환경의 서버 랙 또는 퍼블릭 클라우드의 리전 단위 장애에도 데이터를 안전하게 복제할 수 있는 옵션들이 있음
• min.insync.replicas 옵션으로 데이터 유실 가능성을 막을 수 있음
  • ex. 2로 설정하고 브로커를 3대 이상 운영하면 1개의 브로커에 장애가 나더라도 지속적으로 처리가능
• 생태계 지탱하는 애플리케이션들이 도와줌

https://ssdragon.tistory.com/117

 

 

---

카프카의 미래 (데이터 레이크 아키텍처)

람다 아키텍처 & 카파 아키텍처

 

기존의 레거시 데이터 플랫폼 아키텍처

• 각 서비스 어플리케이션으로부터 데이터를 배치로 모았다.
• 유연하지 못하고 실시간 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못했다.
• 히스토리 파악 어려움 및 파편화로 데이터 표준 및 정책(데이터 거버넌스)를 지키기 어려웠음

람다 아키텍처

• 스피드 레이어라고 실시간 데이터 ETL 작업 영역을 정의한 아키텍처를 만듦

https://velog.io/@rolroralra/gd7vc5tk

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

카파 아키텍처

https://velog.io/@rolroralra/gd7vc5tk

 

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

가운데 로그 왼쪽: 처음 들어온 레코드, 오른쪽 : 가장 마지막에 추가된 레코드

 

•  카프카 내부에서 사용되는 파티션, 레코드, 오프셋은 제이 크렙스가 정의한 로그의 데이터 플랫폼 구현체라고 볼 수 있음

 

 

참고 링크 : https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

The Log: What every software engineer should know about real-time data's unifying abstraction