1. 카프카의 탄생
카프카는 LinkedIn에서 파편화된 데이터 수집 및 분배 아키텍처를 다루기 위해 개발되었다
기존의 시스템은 소스 어플리케이션에서 타겟 어플리케이션 연동하여 데이터를 단방향으로 전송했다
소스 어플리케이션이 타겟 어플리케이션을 직접적으로 알고 있어야 했다
하지만 시스템이 커지면서 소스 어플리케이션과 타겟 어플리케이션의 수는 기하급수적으로 증가하였다
그로인해 다음과 같은 문제가 발생했다
- 데이터를 전송할 타겟을 모두 알아야 되므로 복잡도가 증가
- 파이프라인 개수가 많아지면서 소스코드 및 버전관리에 이슈
- 타겟 어플리케이션에 장애가 생기면 영향이 소스 어플리케이션으로 이어짐
이를 해결하기 위해 LinkedIn 데이터팀은 아파치 카프카를 만들었다
각 어플리케이션끼리 연결하는 것이 아니라 한 곳에 모아 데이터를 처리하도록 하였다
기업의 대용량 데이터를 한곳에 수집하고 사용자들이 실시간 스트림으로 소비할 수 있게 만들어주었다
이렇게 되면 소스 어플리케이션과 타겟 어플리케이션은 서로에 대해서 알 필요없이
한곳에 데이터를 보내고 소비하기만 하면 된다
즉, 카프카는 소스 어플리케이션과 타겟 어플리케이션 간의 의존성을 낮추고 디커플링의 역할을 수행한다
타겟 어플리케이션의 영향이 소스 어플리케이션으로 미치지 않으며
소스 어플리케이션은 어느 타겟 어플리케이션으로 보낼지 알 필요없이 카프카로 보내기만 하면 된다
데이터를 전송하는 것을 프로듀서라 부르고 데이터를 소비하는 것을 컨슈머라 부른다
프로듀서가 보낸 데이터는 카프카 내부의 토픽이라는 공간의 파티션에 적재된다
파티션은 FIFO 방식의 Queue 자료구조와 유사하다
파티션은 서버 내의 파일 시스템에 로그 형식으로 데이터를 저장한다
카프카로 전달되는 데이터 포멧은 제한이 없다
직렬화, 역직렬화를 통해 ByteArray로 통신하기 때문에 자바의 모든 객체를 지원한다
기본적으로 ByteArray, ByteBuffer, Double, Long, String 타입의 직렬화, 역직렬화 클래스를 제공한다
필요하다면 Serializer, Deserializer를 상속받아 커스터마이징 할 수 있다
카프카는 최소 3대 이상의 서버 (= 브로커)로 분산 운영해야 한다
카프카에 전달된 데이터는 다른 카프카 서버로 지속적으로 복제하여 안전하게 운영할 수 있다
그래서 일부 서버에서 장애가 나더라도 데이터를 보존할 수 있다
2. 빅데이터 파이프라인에서 카프카의 역할
현대 IT에서는 가능한 모든 기록들을 저장하려고 한다.
과거의 최소한의 정보만 저장하는 것과 다른 양상으로 이를 빅데이터라고 부른다
빅데이터로 적재되는 데이터의 종류는 다양하다
- 데이터베이스의 스키마 기반의 정형 데이터
- 일정한 규격이나 형태가 없는 비정형 데이터
이런 방대한 빅데이터들을저장하고 활용하기 위해 모으는 공간을 데이터 레이크라고 부른다
데이터웨어 하우스와 다르게 필터링되지 않은 데이터가 저장되는 것이 특징이다
해당 데이터들을 통해서 인사이트를 찾을 수 있다
기존에 데이터 레이크에 데이터를 저장하는 방식은 서버 간 엔드 투 엔드 방식을 사용할 수 있다
하지만 LinkedIn의 사례처럼 서비스가 복잡해지면 문제점이 발생한다
이를 해결하기 위해 데이터를 추출하고 변경, 적재하는 데이터 파이프 라인을 구축해야한다
안정적이고 유연하고 확장 가능하도록 자동화 한 것을 데이터 파이프 라인이라 부른다
안정적이고 확장성이 높은 데이터 파이프라인은 빅데이터 기업에서 필수적이다
이때, 아파치 카프카가 데이터 파이프 라인을 안정적이고 확장성 높게 운영하기 위해 좋은 방법이다
아파치 카프카의 장점은 다음과 같다
높은 처리량
- 카프카는 프로듀서가 데이터 보낼 때, 컨슈머가 데이터를 받을 때 묶어서 전송한다
- 많은 데이터를 송수신할 때 맺어지는 네트워크 비용은 무시할 수 없다
- 그러므로 네트워크 비용을 줄여준다
- 배치로 처리할 수 있기 때문에 대용량 실시간 로그 데이터를 처리하는데 적합하다
- 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬처리할 수 있다
- 파티션 개수만큼 컨슈머 개수를 늘려서 동일 시간당 데이터 처리량을 늘릴 수 있다
확장성
- 데이터 파이프 라인에서 데이터를 모을 떄 데이터가 얼마나 들어올지 예측하기 어렵다
- 1,000건의 로그가 이벤트로 100만건이 될 수도 있다
- 카프카 클러스터는 데이터가 적을 때 브로커를 최소한으로 운영한다
- 데이터가 많아지면 스케일 아웃을 한다
- 반대로 데이터 개수가 적어지면 스케일 인 한다
영속성
- 데이터를 생성한 프로그램이 종료해도 데이터가 사라지지 않는다
- 카프카는 다른 메세징 시스템과 다르게 데이터를 메모리에 저장하지 않고 파일 시스템에 저장한다
- 카프카는 운영체제 레벨에서 파일 시스템을 최대한 활용하는 방법을 적용했다 (보통의 파일 시스템은 메모리보다 느리다)
- 운영체제에서 파일 I/O 성능을 위해 페이지 캐시 영역을 메모리에 따로 생성한다
- 페이지 캐시 메모리로 한번 읽은 파일은 메모리에 저장했다 다시 사용하는 방식이다
- 브로커 어플리케이션에 장애가 발생해서 종료해도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다
고가용성
- 3개 이상의 브로커로 운영되는 카프카 클러스터는 무중단으로 안전하게 데이터를 처리할 수 있다
- 데이터의 복제(replication)을 통해 고가용성의 특징을 가진다
- 전달받은 데이터는 여러 브로커에 저장된다
3대 이상의 브로커를 사용하는 이유
- 1대의 브로커 : 서비스 장애가 발생할 수 있다
- 2대의 브로커 : 브로커간 데이터 복제되는 시간 차이로 일부 데이터가 유실될 수 있다
min.insync.replicas를 2로 두면 2대 이상의 브로커에서 데이터가 완전히 복제됨을 보장할 수 있다min.insync.replicas가 2이면 3대 이상의 브로커를 운영해야 한다
3. 데이터 레이크 아키텍처와 카프카의 미래
데이터 레이크 아키텍처의 역사를 먼저 알아야 한다
데이터 레이크 아키텍처는 2가지 종류가 있다
- 람다 아키텍처
- 카파 아키텍처
람다 아키텍처
람다 아키텍처는 레거시 데이터 수집 플랫폼을 개선하기 위해 구성한 아키텍처이다
배치 레이어는 배치 데이터를 모아서 특정 시간 타이밍 마다 일괄처리한다
서빙 레이어는 가공된 데이터를 서비스가 사용하도록 저장된 공간이다
스피드 레이어는 서비스에서 생성된 원천 데이터를 실시간으로 분석하는 용도로 사용된다
스피드 레이어에서 가공, 분석된 결과는 직접 사용할 수 있다
필요한 경우 서빙 레이어로 데이터를 보내서 저장하고 사용할 수 있다
카프카는 람다 아키텍처에서 스피드 레이어에 해당한다
어플리케이션들의 실시간 데이터를 짧은 지연시간으로 처리, 분석할 수 있기 때문이다
카프카 스트림즈와 같은 스트림 프로세스 도구는 윈도우 함수, 상태 기반 프로세싱, 무상태 기반 프로세싱 등 다양한 기능을 제공해준다
배치 레이어와 스피드 레이어를 분리한 단점도 가진다
데이터를 분석, 처리하는데 필요한 로직이 각 레이어에 중복으로 존재하기 때문이다
또한 배치 데이터와 실시간 데이터를 융합할 때는 다소 유연하지 못하다
카파 아키텍처
람다 아키텍처의 단점을 해소하기 위해 Jay Kreps 는 카파 아키텍처를 제안했다
차이점은 배치 레이어를 없애고 모든 데이터를 스피드 레이어에 넣어 처리한다
하나의 스피드 레이어에서 모든 데이터를 처리하므로 엔지니어는 효율적으로 개발을 할 수 있다
그런데 스피드 레이어에서 모든 데이터를 처리하므로 서비스에서 생성되는 모든 종류의 데이터는 스트림 처리해야 한다
배치 데이터를 어떻게 스트림으로 처리할 수 있게 된 것일까?
배경은 데이터의 집합으로 데이터를 로그로 바라본다 (로깅의 로그가 아니다)
데이터는 지속적으로 추가 가능하며 데이터는 일정한 번호가 붙는다
로그는 배치 데이터를 스트림으로 표현하기 적합하다
데이터 플랫폼에서 배치 데이터를 표현할 때는 시점의 전체 데이터를 백업한 스냅샷 데이터를 뜻했다
배치 데이터를 로그로 표현하면 시점의 배치 데이터의 변환 기록(change log)을 시간 순서대로 기록한다
로그로 배치 데이터와 스트림 데이터를 사용하기 위해서는 변환 기록이 일정 기간동안 삭제 안되고 계속 추가되어야 한다
스피드 레이어에 모든 데이터가 들어오기 때문에 SPOF (Single Point Of Failure)가 될 수 있으므로 내결함성 (High Availability)와 장애 허용 특성(Fault Tolerant)을 지녀야 한다
카프카는 파티션, 레코드, 오프셋이 로그의 데이터 구현체로 볼 수 있다
카프카의 미래
카프카는 서빙 레이어를 제거한 스트리밍 데이터 레이크를 제안했다
기존의 서빙 레이어는 하둡(HDFS), 오브젝트 스토리지(S3)와 같이 데이터 플랫폼에서 사용되는 저장소이다
카프카로 분석하고 프로세싱한 데이터를 서빙 레이어의 저장소에 저장할 필요가 없다
카프카에서 분석과 프로세싱을 완료한 큰 용량의 데이터를 오래기간 저장하고 사용할 수 있으므로 서빙 레이어는 제거될 수 있다
스피드 레이어에서 데이터를 분석, 프로세싱, 저장하므로 단일 진실 공급원(SSOT, Single Source Of Truth)이 된다
아직은 카프카를 스트리밍 데이터 레이크로 사용하기 위해 개선할 부분은 있다
- 자주 접근하지 않는 데이터는 비싼 자원 (메모리, 디스크)에 유지할 필요없이 S3와 같은 스토리지에 저장할 수도 있다
- 데이터를 사용하는 서비스에서 카프카 데이터를 쿼리할 데이터 플랫폼이 필요하다
정리
카프카는 데이터 처리양이 많은 대기업 뿐만 아니라 데이터 양이 적은 스타트업에서도 유용하게 사용될 수 있다
스타트업은 안정성과 확장성이 중요하다.
카프카를 사용하면 빠른 성장 속에서도 데이터 관련 작업을 안정적으로 확장할 수 있다
작은 규모의 스타트업이 우리 회사도 카프카를 사용하고 있다
현재는 인공지능 변환모델에 데이터를 전송하고 받는 역할 및 서비스간 간단한 데이터 전송의 역할만 하고 있지만
추후 로그 처리 등의 작업에도 사용할 예정이다