1장 - 들어가며

카프카의 탄생

---

데이터를 생성하고 적재하기 위해서는 데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타깃 애플리케이션을 연결해야 한다.

초기 운영 시에는 단방향 통신을 통해 소스 → 타깃 애플리케이션으로 연동하는 소스코드를 작성

하지만, 아키텍처가 거대해지고 소스, 타깃 애플리케이션이 증가하면서 문제가 발생

 

문제

• 소스 애플리케이션과 타깃 애플리케이션을 연결하는 파이프라인 개수가 많아지면서 소스코드 및 버전 관리에서 이슈 발생
• 타깃 애플리케이션에 장애가 생길 경우 그 영향이 소스 애플리케이션에 전달

아파치 카프카

카프카는 각각의 애플리케이션끼리 연결하여 데이터를 처리하는 것이 아니라

한 곳에 모아 처리할 수 있도록 중앙 집중화 했다.

• 취합한 데이터 스트림을 한 곳에서 실시간으로 관리 가능
• 기업의 대용량 데이터를 수집하고 이를 사용자들이 실시간 스트림으로 소비할 수 있게 만들어주는 일종의 중추 신경

카프카를 중앙에 배치해 소스, 타깃 애플리케이션 사이의 의존도를 최소화하여 커플링을 완화

• 카프카는 의존도를 타파함.

❗이제 소스 애플리케이션에서 생성되는 데이터는 어느 타깃 애플리케이션으로 보낼지 고민하지 않고 일단 카프카에 넣으면 된다.

• 카프카 내부에 데이터가 저장되는 파티션의 동작은 Queue 자료구조와 유사
• 큐에 데이터를 보내는 것 : 프로듀서
• 큐에서 데이터를 가져가는 것 : 컨슈머
• 카프카를 통해 전달할 수 있는 데이터 포맷은 사실상 제한이 없다.
  • 직렬화, 역직렬화를 통해 ByteArray로 통신하기 때문에 자바에서 선언가능한 모든 객체를 지원
  • 커스텀 가능

카프카는 상용 환경에서 최소 3대 이상의 서버(브로커)에서 분산 운영하여 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록

• 일부 서버에 장애가 생겨도 데이터를 지속적으로 복제하기 때문에 안전하게 운영 가능
• 데이터를 묶음 단위로 처리하는 배치 전송을 통해 낮은 지연과 높은 데이터 처리량을 가지게 됨

카프카는 엄청난 양의 데이터를 안전하고 빠르게 처리하는 강점을 가진다.

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

---

빅데이터로 적재되는 데이터의 종류는 다양하다.

• 스키마 기반의 정형 데이터
• 비정형 데이터

데이터 레이크(data lake)

• 빅데이터 레이크는 빅데이터를 관리하고 사용하는 측면에서 중요하다.
• 운영되는 서비스로부터 수집 가능한 모든 데이터를 모은다.

ETL

• 데이터를 추출(exchange), 변경(transforming), 적재(loading)하는 과정을 묶은 것.

데이터 파이프라인

• 엔두 투 엔드방식의 데이터 수집 및 적재를 개선하고 안정성을 추구하며, 유연하면서도 확장 가능하게 자동화 한것.

데이터 파이프라인을 안정적이고 확장성 높게 운영하기 위한 좋은 방법 중 하나가 아파치 카프카를 활용하는 것이다.

❓왜 아파키 카프카가 왜 데이터 파이프라인으로 적합

높은 처리량

카프카는 프로듀서가 브로커로 데이터를 보낼때, 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송한다.

동일한 양의 데이터를 보낼 때 네트워크 통신 횟수를 최소한으로 줄인다면 동일 시간 내에 더 많은 데이터를 전송할 수 있다.

• 많은 양의 데이터를 묶음 단위로 처리하는 배치로 빠르게 처리 ⇒ 대용량 실시간 로그데이터 처리에 적합

파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬처리할 수 있다.

확장성

카프카는 가변적인 환경에서 안정적으로 확장 가능하도록 설계되었다.

카프카의 스케일 아웃, 스케일 인 과정은 클러스터의 무중단 운영을 지원하므로

• 365일 24시간 데이터를 처리해야 하는 커머스나 은행 같은 비즈니스 모델에서도 안정적인 운영이 가능

영속성

데이터를 생성한 프로그램이 종료되더라도 사라지지 않은 데이터의 특성

다른 메시징 플랫폼과 다르게 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장

• 디스크 기반의 파일 시스템을 활용해 브로커 애플리케이션이 장애 발생으로 인해 종료되어도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다.

페이지 캐시 메모리 영역을 사용하여 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식

• 카프카가 파일 시스템에 저장하고 데이터를 저장, 전송하더라도 처리량이 높다.

고가용성

3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리할 수 있다.

• 복제된 데이터가 나머지 브로커에 저장되어 있음.

❗높은 처리량, 확장성, 영속성, 고가용성 특징을 가진 카프카는 데이터 파이프라인을 안전하고 확장성 높게 운영할 수 있도록 설계되었다.

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

---

데이터 레이크 아키텍처의 종류

1. 람다 아키텍처
2. 카파 아키텍처

람다 아키텍처

레거시 데이터 수집 플랫폼을 개선하기 위해 구성한 아키텍처

초기 빅데이터 플랫폼은 엔드 투 엔드로 각 서비스 애플리케이션으로부터 데이터를 배치로 모았다.

• 유연하지 못함
• 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못함
• 원천 데이터로부터 파생된 데이터의 히스토리 파악하기 어려움
• 계속되는 데이터의 가공으로 인해 데이터가 파편화됨

이런 문제점들을 해결하기 위해 기존 배치 데이터를 처리하는 부분 외에 스피드 레이어라고 불리는 실시간 데이터 ETL 작업 영역을 정의한 아키텍처를 만듬

 

배치 레이어

배치 데이터를 모아서 특정 시간, 타이밍 마다 일괄 처리

 

서빙 레이어

가공된 데이터를 데이터 사용자, 서비스 애플리케이션이 사용할 수 있도록 데이터가 저장된 공간

 

스피드 레이어

서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용

• 배치 데이터에 비해 낮은 지연으로 분석이 필요한 경우에 스피드 레이어를 통해 데이터를 분석

스피드 레이어에서 가공, 분석된 실시간 데이터는 사용자 또는 서비스에서 직접 사용할 수 있지만 필요한 경우에는 서빙 레이어로 데이터를 보내서 저장하고 사용할 수 있다.

람다 아키텍처에서 카프카는 스피드 레이어에 위치한다.

• 실시간 데이터를 짧은 지연시간으로 처리(process), 분석(analyysis)할 수 있기 때문

데이터를 배치 처리하는 레이어와 실시간 처리하는 레이어를 분리한 람다 아키텍처는

• 데이터 처리 방식을 명확히 나눌 수 있었지만 레이어가 2개로 나뉘기 때문에 생기는 단점이 존재

단점

1. 데이터를 분석, 처리하는데 필요한 로직이 2벌로 각각의 레이어에 따로 존재
2. 배치 데이터와 실시간 데이터를 융합하여 처리할 때는 다소 유연하지 못한 파이프라인을 생성해야 한다.

이런 단점을 해소하기 위해 카파 아키텍처를 제안

카파 아키텍처

람다 아키텍처와 유사하지만 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리한다.

 

배치 레이어를 제거

람다 아키텍처에서 단점으로 부각되었던

• 로직의 파편화
• 디버깅
• 배포, 운영 분리에 대한 이슈

를 제거하기 위해 배치 레이어를 제거한 카파 아키텍처는 스피드 레이어에서 데이터를 모두 처리할 수 있었으므로 더욱 효율적으로 개발, 운영에 임할 수 있었다.

하지만, 스피드 레이어에서 모든 데이터를 처리하므로 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리해야 한다.

 

배치 데이터 와 스트림 데이터

배치 데이터

• 초, 분, 시간, 일 등으로 한정된 기간 단위 데이터
• 일괄처리하는 것이 특징
• 인터넷 쇼핑몰에서 지난 1분간 주문한 제품 목록, 2021년 신입생 목록…등

스트림 데이터

• 한정되지 않은 데이터, 시작 데이터와 끝 데이터가 명확히 정해지지 않은 데이터
• 각 지점의 데이터는 보통 작은 단위(KB 단위)로 쪼개져 있다.
• 웹 사용자의 클릭로그, 주식 정보 등

❓배치 데이터를 어떻게 스트림 프로세스로 처리할 수 있게 되었나

• 모든 데이터를 로그(log)로 바라보는 것에서 시작
  • 여기서 로그는 데이터의 집합을 의미
• 로그는 배치 데이터를 스트림으로 표현하기 적합

로그로 배치 데이터와 스트림 데이터를 저장하고 사용하기 위해서는

• 변환 기록이 일정기간 동안 삭제되어서는 안되고 지속적으로 추가되어야 한다.

서비스에서 생성된 모든 데이터가 스피드 레이어에 들어오는 것을 감안하면 스피드 레이어를 구성하는 데이터 플랫폼은 SPOF가 될 수 있다

• 따라서 반드시 내결함성(High Availability)과 장애 허용(fault tolerant) 특징을 지녀야 했다.

스피드 레이어로 사용되는 카프카에 분석과 프로세싱을 완료한 거대한 용량의 데이터를 오래동안 저장하고 사용할 수 있다면 서빙레이어는 제거되도 된다.

정리

---

데이터 파이프라인이 복잡한 레거시 아키텍처를 가지고 있는 기업이더라도 손쉽게 카프카와 연동할 수 있고 고도화 할 수 있다.

 

참고

• http://www.yes24.com/Product/Goods/99122569

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