Kafka의 등장 배경 및 특징

카프카의 등장 배경

링크드인에서 초기에 파편화된 데이터 수집 및 분배를 처리하기 위해 데이터를 생성하는 source application과 데이터가 최종 적재되는 target application을 단방향 연결을 함

⬇️

시간이 갈수록 애플리케이션의 개수가 늘어나고 데이터 전송 파이프라인이 늘어나기 시작하면서 아키텍쳐가 복잡해짐

⬇️

이는 서비스를 운영하는데 치명적이므로 링크드인 데이터팀은 다양한 데이터프레임워크와 오픈소스를 아키텍쳐에 녹여내어 개선하기 시작하지만 데이터 파이프라인의 복잡도를 개선하기엔 어려움을 겪음

⬇️

중앙집중화 시스템인 카프카라는 신규 시스템을 만들어내고 카프카는 기업의 대용량 데이터를 수집하고 사용자들이 이를 실시간 스트림으로 소비할 수 있게 해줌

---

카프카의 등장

 

카프카는 이렇게 소스 애플리케이션과 타켓 어플리케이션의 중앙에 위치하여 둘의 의존도를 최소화하였고 카프카에선 소스 어플리케이션은 데이터를 보내는 프로듀서 역할을 하게 되고 타겟 어플리케이션은 데이터를 가져가는 컨슈머 역할을 하게 되었다.

카프카 내부는 여러 개의 토픽으로 구성되어 있고 토픽 안에는 또 여러 개의 파티션으로 구성되어 있다 파티션은 우리가 아는 큐라는 자료구조와 비슷하면 동작 방식도 FIFO 방식이다.

카프카에서는 사실상 데이터 포맷에 제한이 없고 직렬화, 역직렬화를 통해 ByteArray로 통신하기 때문에 자바에서 선언 가능한 모든 객체를 지원한다.

상용 환경에서는 카프카는 최소 3대 이상의 서버(=브로커)에서 분산 운영하여 프로듀서를 통해 받은 데이터를 파일 시스템에 기록하고 3대 이상의 서버로 이루어진 클러스터 중 일부 서버에 장애기 발생하더라도 데이터를 지속적으로 복제하기 때문에 안전하게 운영이 가능해졌다.

# 참고 내용

카프카 클러스터를 구축할 때 브로커 개수 제한은 없지만 3대 이상으로 구성해야 하는 이유는 브로커 간에 데이터가 복제될 때 시간 차이로 인해 일부 데이터가 유실될 가능성이 있다. 그래서 min.insync.replicas 옵션을 2로 설정하고 사용하는데 이는 최소 2개 이상의 브로커에 데이터가 완전히 복제됨을 보장한다. 하지만 2 옵션을 사용할 때 브로커를 3대 이상으로 운영할 필요성이 있고 이는 3개 중 1개의 브로커에 장애가 나더라도 지속적으로 데이터를 처리할 수 있기 때문이다.

3개 이상의 브로커 중에서 프로듀서로부터 데이터를 받는 파티션을 leader 파티션이라고 부르고 복제되는 나머지 파티션을 follow 파티션이라고 부른다. 이렇게 원본 파티션과 복제된 파티션을 묶어서 ISR(In Sync Replica)라고 부른다.

프로듀서는 다음과 같이 세가지 ack옵션을 통해 데이터의 유실을 관리할 수 있다. 먼저 0 옵션은 leader파티션에 데이터를 보내기만 하는 옵션이고 1 옵션은 데이터를 보내고 잘 받았으니 확인까지 받아서 데이터가 유실됐는지 알 수 있지만 복제 과정중에서 유실됐는지 알순 없다. 하지만 all옵션을 통해 follow 파티션까지 resp를 받아서 데이터의 유실을 확인할 수 있다.

---

카프카의 특징

카프카의 특징에 들어가기 앞서 데이터 파이프라인과 데이터 레이크의 개념을 알고 가야하는데 먼저 데이터 레이크는 데이터를 모으는 공간의 개념으로서 데이터 웨어하우스와 다르게 필터링되거나 패키화되지 않은 데이터가 저장된다. 데이터 레이크에 데이터를 저장하는 방식을 단순하게 생각해보면 엔드투엔드 방식으로 저장할 수 있는데 이 방식은 서비스가 많아지면 복잡해진다는 문제점이 있다

그래서 데이터를 추출하고 변경하고 적재할 데이터 파이프라인을 구축할 필요성이 있는데 이러한 데이터 파이프라인을 안정적이고 확장성 높게 운영하기 위해서는 다음과 같은 특징을 갖는 아파치 카프카를 활용해야 한다.

• 높은 처리량 → 카프카는 프로듀서에서 브로커든 브로커에서 컨슈머든 데이터 송수신간 데이터를 모두 묶어서 전송함. 또한, 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬 처리를 함.

 

• 확장성 → 데이터가 적을 때 카프카 클러스터의 브로커 갯수를 최소한으로 운영하다가 데이터가 많아질 때 브로커 개수를 늘려 scale-out할 수 있음.

 

• 영속성 → 다른 메시징 플랫폼과는 다르게 데이터를 파일 시스템에 저장하고 컨슈머가 데이터를 읽어가도 사라지지 않음.

 

• 고가용성 → 3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 data replication을 통해 안전하고 지속적으로 데이터를 처리할 수 있음

---

데이터 레이크 아키텍쳐

데이터 레이크 아키텍쳐는 다음과 같은 순으로 변천되었다.

레거시 데이터 플랫폼 아키텍처 -> 람다 아키텍처 -> 카파 아키텍처 -> 스트리밍 데이터 레이크 아키텍처

람다 아키텍처

초기 레거시 데이터 플랫폼 아키텍처는 실시간 데이터를 서비스 애플리케이션에 빠르게 전달하지 못했고, 데이통의 가공으로 인해 데이터가 파편화되면서 데이터 거버넌스(데이터표준 및 정책)를 지키지 못했다.

그래서 기존의 배치 데이터를 처리하는 부분 외에 스피드 레이어라고 불리는 실시간 데이터 ETL(extract transform load) 작업 영역을 정의한 람다 아키텍처가 등장하게 되었다.

람다 아키텍처에서는 배치 레이어는 배치 데이터를 모아서 특정 타이밍마다 일괄 처리했고 서빙 레이어에서는 가공된 데이터를 데이터의 사용자가 사용할 수 있도록 데이터가 저장되는 공간으로 사용되었고 스피드 레이어에서는 실시간 데이터를 분석하는 용도로 사용되었다.

람다 아키텍처에서 카프카는 스피드 레이어에 위치하는데 이는 서비스 애플리케이션들의 실시간 데이터를 짧은 지연시간으로 처리 및 분석할 수 있기 때문이다.

하지만 람다 아키텍처도 데이터 분석 및 처리 로직이 두개로 나뉘어있다는 점과 배치 데이터와 실시간 데이터를 융합하여 처리할 때 다소 유연하지 못한 파이프라인이 생성된다는 점 때문에 새로운 아키텍처가 나오게 된다.

카파 아키텍처

그 다음 아키텍처의 이름은 제이 크렙스가 고안한 카파 아키텍처이다. 카파 아키텍처는 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리하는 구조로 바뀌었는데 이는 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리해야 한다는 문제점이 있었다. 그래서 제이 크렙스는 데이터를 로그로 바라보고 로그(데이터의 변환 기록을 저장)로 배치 데이터와 스트림 데이터를 저장하고 사용했다. 이는 스피드 레이어가 SPOF가 될 수 있으므로 High availability와 fault tolerant라는 특징을 지녀야 하는데 아파치 카프카가 딱 이 특징에 부합하는 플랫폼이다.

이후 제이 크렙스는 카파 아키텍처에서 서빙 레이어를 뺀 아키텍처인 스트리밍 데이트 레이크 아키텍처 방식을 고안하게 된다.

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

이 아키텍처는 스피드 레이어에서 데이터를 분석, 처리, 저장까지 다 담당함으로써 데이터가 필요한 사용자가 데이터 레이크의 스피드 레이어만 참조함으로써 데이터의 중복, 비정합성 같은 문제를 해결할 수 있게 되었다.