아파치 카프카란 무엇일까?

백엔드 아키텍처에서 자주 보였던 플랫폼인 아파치 카프카가 무엇인지 궁금했다.

포춘 100대 기업에서 80개 기업 이상이 도입할 정도이고, 국내 서비스 기업들도 많이 사용하고 있다.

 

카프카가 나오기 전, 링크드인 개발자들이 대용량·대규모 데이터를 처리하기 위해 여러 플랫폼을 조합해서 사용했지만 실패하였다.

그 후 최초로 배치성 데이터와 실시간 이벤트 스트리밍 데이터를 혼합하여 처리하는 독특한 로직의 플랫폼을 만들어 냈는데,

이것이 "아파치 카프카"의 탄생이다.

 

아파치 카프카는 이벤트 스트리밍뿐만 아니라, 빅데이터 아키텍처에 있어서 중요한 역할을 하는 만큼 대용량·대규모 데이터 처리에 이를 대체할 플랫폼이 없을 정도이다.

 

아파치 카프카는 실시간 스트리밍 데이터 처리를 하는 데에 있어
가장 주목받는 프레임워크이자 오픈소스 도구이다

 

 

공식문서에서는 이렇게 소개하고 있다.

Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.

아파치 카프카(Apache Kafka)는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합, 미션 크리티컬 애플리케이션을 위해 수천개의 기업에서 사용하는 오픈소스 분산 이벤트 스트리밍 플랫폼(open-source distributed event streaming platform)입니다.

 

🧐 이벤트 스트리밍이란?
인체의 중추 신경계에 해당하는 디지털 방식이다. 기술적으로는 DB, 센서, 클라우드 서비스 및 소프트웨어 애플리케이션과 같은 이벤트 소스에서 이벤트 스트림의 형태로 실시간으로 데이터를 캡처하는 방식을 말함.

---

1. 카프카의 탄생

2011년, 링크드인(LinkedIn)에서는 파편화된 데이터 수집 및 분배 아키텍처를 운영하는 데에 어려움을 겪고 있었다.

데이터를 생성 및 적재하려면 소스 애플리케이션과 타깃 애플리케이션을 연결해야 한다.

소스 애플리케이션 : 데이터를 생성
타깃 애플리케이션 : 데이터가 최종 적재
앞으로는 애플리케이션을 줄여서 앱 이라고 말하겠습니다.

 

초기 운영 시

• 단방향 통신으로 소스 앱 -> 타깃 앱 연동하는 소스 코드 작성
• 아키텍처가 복잡하지 않아서 운영이 힘들지 않음

시간이 지날수록

• 아키텍처는 거대해지면서 소스 앱과 타깃 앱 증가
• 증가함에 따라 데이터를 전송하는 라인이 기하급수적 O(n^2)으로 복잡해짐
• 앱끼리 연결하는 파이프라인 개수가 많아지면서 소스코드 및 버전 관리 이슈 발생
• 타깃 앱에 장애 발생 시 소스 앱에도 영향이 미침

카프카 도입 이전 아키텍처, O(N^2)개의 파이프라인

이 같은 단점을 해결하기 위해 신규 시스템을 만들었고, 그 결과물이 "아파치 카프카"이다.

아파치 카프카는 각각의 앱끼리 연결하여 데이터를 처리하는 것이 아닌, 한 곳에 모아 처리할 수 있도록 중앙집중화했다.

• 웹사이트, 애플리케이션, 센서 등에서 취합한 데이터 스트림을 한 곳에서 실시간 관리 가능해짐
• 대용량 데이터를 수집하고 사용자에게 실시간 스트림으로 소비할 수 있게 만들어주는 일종의 중추 신경으로 동작함

카프카가 적용된 이후의 파이프라인 아키텍처

• 카프카를 중앙에 배치함으로써, 소스 앱과 타깃 앱사이의 의존도를 최소화하여 커플링 완화
  • 기존 1:1 매칭의 데이터 파이프라인은 커플링으로 한쪽의 이슈가 다른 한쪽에 영향을 주었음
• 소스 앱에서 생성되는 데이터는 어디로 보낼 것인지 고민하지 않고 카프카로 넣으면 됨

카프카 프로듀서, 컨슈머, 토픽 모식도

카프카 내부에 데이터가 저장되는 파티션 동작은 FIFO 방식의 큐 자료구조와 유사하다.

프로듀서 : 큐에 데이터를 보내는 것
컨슈머 : 큐에서 데이터를 가져가는 것

• 카프카를 통해 전달할 수 있는 데이터 포맷은 제한이 없음
  • 직렬화, 역직렬화를 통해 ByteArray로 통신하기에 자바에서 선언 가능한 모든 객체 지원
  • 카프카 클라이언트에서는 ByteArray, ByteBuffer, Double, Long, String타입에 대응한 직렬화 및 역직렬화 기본 제공
  • 카프카에서 제공하는 커스텀 직렬화/역직렬화 클래스를 상속받아 개발 및 사용 가능
• 실 서비스 환경에서 카프카는 최소 3대 이상의 서버(브로커)에서 분산 운영하여 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록함
• 서버가 3대 이상으로 이루어진 카프카 클러스터 중 일부 서버에 장애가 발생하더라도 데이터를 지속적으로 복제하기에 안전하게 운영 가능함
• 데이터를 묶음 단위로 처리하는 배치 전송을 통해 낮은 지연과 높은 데이터 처리량도 가지고 있음

 

이렇게 카프카는 대용량 데이터를 안전하고 빠르게 처리하는 강점을 가지고 있기에 많은 IT 기업이 사용하고 있다.

(SK, 카카오, 네이버, 삼성, 넷플릭스, 우버, 월마트, 에어비엔비 등)

각 기업들의 사용 사례도 테크 블로그를 통해 찾아볼 수 있다.

이 중 대표적으로 가장 잘 활용하는 회사는 넷플릭스이다.

넷프릭스는 36개 이상의 카프카 클러스터를 운영하고 있고, 클러스터를 구성하는 브로커는 4,000개가 넘는다.

즉, 하나의 클러스터에 100개 이상의 브로커를 운영하는 것이다.

 

---

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

현대의 IT 서비스는 다음과 같은 디지털 정보로 기록되는 모든 것을 저장한다.

• 쇼핑몰 결제내역
• 방문한 위치정보
• 소셜사이트에 남긴 댓글 등

과거 비즈니스를 수행하기 위한 최소한의 정보만 저장하던 것과 다른 양상인데, 이것을 우리는 "빅데이터"라고 부른다.

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

• 데이터베이스의 스키마(schema)기반의 정형 데이터
• 일정한 규격이나 형태를 지니지 않은 비정형 데이터 (e.g. 그림, 영상, 음성 등)

이런 대용량 데이터를 기존의 데이터베이스로 관리하는 것은 불가능에 가깝다.

빅데이터를 저장 및 활용하기 위해서는 생성되는 데이터를 모두 모으는 것이 중요한데, 이것을 "데이터 레이크"라고 한다.

 

🧐 데이터 레이크(data lake)란?
호수(lake)라는 이름처럼 데이터가 모이는 저장 공간을 의미한다.
데이터 웨어하우스(data warehouse)와 다르게 필터링 또는 패키지화되지 않은 데이터가 저장되는 것이 특징이다.
해당 데이터를 토대로 서비스에 활용할 수 있는 인사이트를 찾을 수 있다.

 

서비스에서 발생하는 데이터를 데이터 레이크로 모으려면 어떻게 해야할까?

웹, 앱, 서버 등에서 발생하는 데이터를 데이터 레이크에 직접 엔드 투 엔드(end-to-end)방식으로 넣을 수 있다.

→ 서비스하는 애플리케이션 개수와 트래픽이 적을 때는 문제가 없음

→ 링크드인처럼 서비스가 커질수록 파편화되고 복잡도가 올라가는 문제점이 발생함

이를 해결하려면 데이터를 추출(extracting), 변경(transforming), 적재(loading)하는 과정을 묶은 데이터 파이프라인을 구축해야 한다.

 

🧐 데이터 파이프라인이란?
end-to-end 방식의 데이터 수집 및 적재를 개선하고 안정적이고 유연하고 확장 가능하게 자동화한 것

 

안정적이고 확장성이 높은 데이터 파이프라인을 구축하는 것은 빅데이터 기업에서 필수적이다.

데이터 파이프라인을 구축하지 않고, 일회성으로 구축한 데이터 수집은 결국 데이터 흐름의 파편화로 이어진다.

→ 반복적인 유지보수를 필요로 하기 때문에 기술 부채(technical debt)로 남게됨

 

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

 

아파치 카프카의 장점

높은 처리량

• 많은 양의 데이터를 송수신할 때 맺어지는 네트워크 비용은 크다
  • 따라서 동일한 양의 데이터를 보낼 때 네트워크 통신 횟수를 최소한으로 줄이면 동일 시간 내에 더 많은 데이터를 전송할 수 있다
• 카프카는 프로듀서가 브로커로 데이터 보낼때와 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송한다
  • 많은 양의 데이터를 묶음 단위로 처리하는 배치로 빠르게 처리할 수 있다 (대용량 실시간 로그 데이터 처리 적합)
• 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬 처리 가능하다
  • 파티션 개수만큼 컨슈머 개수를 늘려서 동일 시간당 데이터 처리량을 늘리는 것

 

확장성

• 데이터 파이프라인에서 데이터를 모을 때 얼마나 들어올지 예측하기 어렵다
  • e.g. 하루 1,000건이었다가 이벤트로 100만건이 들어오는 경우
• 카프카는 이러한 가변적인 환경에서 안정적으로 확장 가능하도록 설계되었다
• 데이터가 적을 때 카프카 클러스터의 브로커를 최소한의 개수로 운영
• 데이터가 많아지면 클러스터의 브로커 개수를 늘려 스케일 아웃(scale-out)한다
• 데이터가 다시 적어지면 브로커 개수를 줄여 스케일 인(scale-in)한다
• 스케일 아웃, 스케일 인 과정은 클러스터의 무중단 운영을 지원하므로 365일 24시간 데이터 처리를 해야하는 비즈니스 모델에서도 안정적으로 운영이 가능하다

 

영속성

• 영속성은 데이터를 생성한 프로그램이 종료되더라도 사라지지 않은 데이터의 특성을 의미한다
• 카프카는 다른 메시징 플랫폼과 다르게 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장한다
• 카프카는 운영체제 레벨에서 파일 시스템을 최대한 활용하는 방법을 적용했다 (보통 파일 시스템은 메모리보다 느림)
• 운영체제에서는 파일 I/O성능 향상을 위해 페이지 캐시 영역을 메모리에 따로 생성하여 사용한다
• 페이지 캐시 메모리 영역을 사용하여 한번 읽은 파일 내용은 메모리에 저장했다가 다시 사용하는 방식이다
  • 따라서 카프카가 파일 시스템에 데이터를 저장 및 전송하더라도 처리량이 높은 것
• 디스크 기반의 파일 시스템 덕분에 브로커 앱이 장애 발생으로 종료되더라도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다

 

고가용성

• 3개 이상의 서버로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터 처리 가능
• 클러스터로 이루어진 카프카는 데이터의 복제(replication)를 통해 고가용성의 특징을 가짐
• 전달 받은 데이터를 여러 브로커에 저장하는 것
• 한 브로커에 장애 발생해도 다른 브로커에도 복제된 데이터가 있어서 저장된 데이터 기준으로 지속적인 데이터 처리 가능

 

카프카 생태계 모식도

 

카프카 클러스터를 3대 이상의 브로커로 구성해야하는 이유

1대로 운영할 경우

• 브로커의 장애는 서비스의 장애로 이어짐

2대로 운영할 경우

• 한 대의 브로커가 장애 발생해도 나머지 한 대로 안정적으로 데이터 처리 가능
• 브로커 간에 데이터가 복제되는 시간 차이로 데이터 일부 유실 가능
• 데이터 유실을 막기 위해 min.insync.replicas 옵션 사용함
  • 옵션을 2로 설정하면 최소 2개 이상의 브로커에 데이터가 완전히 복제됨을 보장
  • 하지만 2로 설정하려면 최소 3대 이상의 브로커로 운영해야함

 

---

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

3.1 레거시 데이터 플랫폼 아키텍처

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

• 초기 빅데이터 플랫폼은 end-to-end 방식으로 각 서비스 앱으로부터 데이터를 배치로 모음
• 이 구조의 단점
  • 유연성 X
  • 실시간 데이터들에 대한 인사이트를 서비스 앱에 빠르게 전달 X
  • 원천 데이터로부터 파생된 데이터의 히스토리 파악 힘듬
  • 지속적인 데이터 가공으로 데이터가 파편화되면서 데이터 거버넌스를 지키기 힘듬

데이터 거버넌스(data governance) : 데이터 표준 및 정책을 의미함

 

이런 단점을 해결하기 위해 기존의 배치 데이터를 처리하는 부분 외에 스피드 레이어를 만들었다.

스피드 레이어(speed layer) : 실시간 데이터 ETL(추출,변환,로드)작업 영역을 정의한 아키텍처

 

3.2 람다 아키텍처(lambda architecture)

람다 아키텍처

• 레거시 데이터 수집 플랫폼을 개선하기 위해 구성한 아키텍처
• 람다 아키텍처에서 카프카는 스피드 레이어에 위치함
  • 서비스 앱들의 실시간 데이터를 짧은 지연시간으로 처리, 분석 할 수 있기 때문
• 스피드 레이어
  • 서비스에서 생성되는 원천 데이터를 실시간 분석
  • 배치 레이어에 비해 낮은 지연을 가지며, 분석이 필요한 경우에 스피드 레이어를 통해 데이터 분석
  • 가공, 분석된 실시간 데이터는 사용자 또는 서비스에서 직접 사용 가능
  • 필요에 따라 서빙 레이어로 데이터를 보내서 저장 및 사용 가능
• 배치 레이어
  • 배치 데이터를 모아서 특정 기간, 타이밍마다 일괄 처리
• 서빙 레이어(serving layer)
  • 가공된 데이터를 사용자, 서비스 앱이 사용할 수 있도록 데이터가 저장된 공간

 

이런 람다 아키텍처에도 단점이 있습니다. 바로 배치 레이어와 스피드 레이어로 분리된 것입니다.

• 데이터 처리 방식은 명확히 나눴지만 다음 2가지 단점이 생김
• 데이터 분석, 처리하는 데에 필요한 로직이 2개로 각각의 레이어에 따로 존재해야 함
• 배치 데이터와 실시간 데이터를 융합하여 처리할 때는 유연하지 못한 파이프라인을 생성해야 함

 

결국 람다 아키텍처의 단점을 해결하기 위해 카파 아키텍처가 나왔습니다.

카파 아키텍처는 제이 크렙스(Jay Kreps)가 제안한 아키텍처입니다.

 

3.3 카파 아키텍처(kappa architecture)

카파 아키텍처

• 람다 아키텍처와 유사하지만, 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리함
• 람다 아키텍처의 단점인 로직의 파편화, 디버깅, 배포, 운영 분리에 대한 이슈를 제거하기 위해 배치 레이어 제거
• 카파 아키텍처는 스피드 레이어에서 데이터를 모두 처리
  • 따라서 엔지니어들은 효율적으로 개발 및 운영 가능
• 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리해야 함
  • 왜냐하면 스피드 레이어에서 모든 데이터를 처리하므로

 

배치 데이터는 초, 분, 시간, 일 등으로 한정된(bounded) 기간 단위 데이터를 의미함
- 일괄 처리(batch processing)이 특징
- 쇼핑몰에서 지난 1분간 주문한 제품 목록, 21년 신입생 목록을 배치 데이터로 볼 수 있음

스트림 데이터는 한정되지 않은(unbounded) 데이터로 시작과 끝 데이터가 명확히 정해지지 않은 데이터를 의미함
- 각 지점의 데이터는 작은 단위(KB)로 쪼개져 있으며 웹 사용자의 클릭 로그, 주식 정보, 사물 인터넷의 센서 데이터를 스트림 데이터라 볼 수 있음

 

배치 데이터를 어떻게 스트림 프로세스로 처리할 수 있을까?

제이 크렙스가 고안한 로그

• 모든 데이터를 로그(log)로 바라보는 것
  • 여기서 로그는 앱을 로깅하는 텍스트 로그가 아니라, 데이터의 집합을 의미한다
• 데이터는 지속적으로 추가가 가능하며, 각 데이터에는 일정한 번호가 붙는다

기존 스냅샷으로 배치 데이터를 표현한 모습과 로그로 배치 데이터를 표현한 모습

• 로그는 배치 데이터를 스트림으로 표현하기에 적합함
• 일반적으로 데이터 플랫폼에서 배치 데이터를 표현할 때
  • 각 시점(시간별, 일자별 등)의 전체 데이터를 백업한 스냅샷 데이터를 의미함
• 배치 데이터를 로그로 표현할 때
  • 각 시점의 배치 데이터의 변환 기록을 시간순으로 기록함
  • 시간순이기에 각 시점의 모든 스냅샷 데이터를 저장하지 않고도 배치 데이터 표현 가능함
• 로그로 배치 데이터와 스트림 데이터를 저장 및 사용하려면 변환 기록이 일정 기간동안 삭제되면 안되고 지속적으로 추가되어야 함
• 스피드 레이어를 구성하는 데이터 플랫폼은 SPOF(Single Point Of Failure)가 될 수 있으므로 내결함성(High Availability)과 장애 허용(Fault Tolerant) 특징을 지녀야 함
  • 아파치 카프카는 이런 특징에 정확히 부합하는 플랫폼이다
• 카프카 내부에서 사용되는 파티션, 레코드, 오프셋은 제이 크렙스가 정의한 로그의 데이터 플랫폼 구현체로 볼 수 있음

 

---

4. 카프카의 미래

제이 크렙스는 카파 아키텍처에서 서빙 레이어를 제거한 아키텍처인 스트리밍 데이터 레이크를 제안했다.

 

4.1 스트리밍 데이터 레이크(streaming data lake)

스트리밍 데이터 레이크 아키텍처

카파 아키텍처에서는 데이터 사용자를 위해 스트림 데이터를 서빙 레이어에 저장했었다.

서빙 레이어는 하둡(HDFS), 오브젝트 스토리지(S3) 등 데이터 플랫폼에서 흔히 사용되는 저장소이다.

이 서빙 레이어가 하는 기능을 스피드 레이어가 그대로 한다면 이중으로 관리되는 운영 리소스를 줄일 수 있게 된다.

• 스피드 레이어에서 데이터를 분석, 프로세싱, 저장함으로써 단일 진실 공급원(SSOT)가 되는 것
• 데이터가 필요한 사용자 및 앱은 스트리밍 데이터 레이크의 스피드 레이어만 참조함으로써 데이터 중복, 비정합성과 같은 문제에서 벗어날 수 있음

 

스피드 레이어로 사용되는 카프카에 분석과 프로세싱을 완료한 대용량 데이터를 오랜 기간 저장하고 사용할 수 있으면 서빙 레이어를 제거해도 된다. 그렇다면 문제점은 무엇인가?

단계별 저장소를 가진 카프카 클러스터 모식도

• 자주 접근하지 않는 데이터를 비싼 자원(브로커 메모리, 디스크)에 유지할 필요 X
• 카프카 클러스터에서 자주 접근하지 않는 데이터는 오브젝트 스토리지와 같이 저렴하면서 안전한 저장소에 저장하고, 자주 사용하는 데이터만 브로커에서 사용하는 구분 작업이 필요함
• 카프카의 데이터를 쿼리할 수 있는 주변 데이터 플랫폼 필요

 

이런 문제점 때문에 아직 사용하진 않지만, 스피드 레이어 + 오브젝트 스토리지를 붙여서 보조적으로는 사용할 수 있을 것 같다.

 

---

5. 나의 생각

링크드인처럼 거대한 아키텍처가 아닌, 스타트업에서 사용하는 작은 아키텍처에서는 도입하는 것이 더 비용이 크지 않을까?

• 데이터 파이프라인의 복잡도를 해결 (대기업 > 스타트업)
• 데이터를 묶음 단위로 처리하는 배치 전송으로 높은 처리량 (대기업 > 스타트업)
• 장애 발생시 데이터 유실을 방지하는 영속성 (대기업 = 스타트업)
• 일부 서버가 장애 발생해도 무중단으로 안전하게 데이터를 처리하는 고가용성 (대기업 = 스타트업)

여러 장점을 생각해보았지만 지금 당장은 효과를 볼 수 없는 특징들도 있겠지만, 자신의 기업에 대한 비즈니스 성장성을 생각하고 빠르게 개발해야하는 것이 아니라면 괜히 도입하지 않고 기술부채를 만드는것보다는 안정적으로 빠른 확장을 위해 도입하는게 좋아보인다.

결국 폭발적으로 성장한다면 갑작스럽게 데이터 파이프라인이 늘어날 것이고, 네트워크 트래픽량도 많아지면서 데이터 유실도 생각해야 한다.

당장의 서비스 개발과 자금, 시간이 부족한게 아니라면 미래를 위해서 하는게 맞지 않을까?

 

지금껏 살펴봤을 때 데이터 처리량이 많은 기업만 쓸 것 같지만, 오히려 데이터가 적은 스타트업에서도 유용하게 사용되는 부분도 있다.

스타트업은 안정적인 운영과 빠른 확장성이 중요한데, 카프카를 도입하는 것이 안정적으로 확장을 할 수 있다고 본다.

카프카는 많은 기업에서도 사용하고, 오픈소스이기에 지속적으로 발전하며 현재도 활용이 많이 되고 있다.

 

 

 

---

 

 

아파치 카프카 공식홈페이지

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