Kafka란?
데이터파이프라인 구축에서 꼭 들어가는 친구 입니다.
그런데 아직 경험해보지 못했습니다...!!
경험할 기회가 있다면...꼭! 경험해보고 싶습니다:)
그 날을 위해 Study~!! GoGo!
어색한 용어들과 개념들부터 정리해보도록 합니다.
우선 데이터 파이프라인(Data Pipeline)이란?
데이터의 흐름을 자동화하는 프로세스를 의미합니다.
다양한 출처에서 데이터를 수집하고 변환하고 처리한 후에 저장하거나 분석 도구에 전달하는 일련의 단계를 포함 합니다.
데이터 파이프라인의 유형은
배치 처리와 실시간 처리가 있습니다.
요 근래에 Airflow라는 친구를 알게 되었는데 데이터 파이프라인 도구 중 하나 입니다.
또한 kafka 역시 실시간 스트리밍 데이터 처리를 위한 데이터 파이프라인 도구 중 하나 입니다.
그런데 데이터 파이프라인에서 다루는 데이터들은 바로 빅데이터 입니다.
이런 빅데이터를 저장하고 활용하기 위해서는 일단 생성되는 데이터를 모두 모으는 것이 중요한데
이때 사용되는 개념이 "데이터 레이크(Data Lake)" 입니다.
Data Warehouse라는 개념도 있는데 이 친구는 정형화된 데이터를 저장하는데 반면
Data Lake는 정형, 비정형 데이터 모두 저장합니다.
데이터 레이크에 데이터를 모으려면 온갖 서비스에서 end-to-end방식으로 데이터를 수집하면 되는데
이런 방식이 바로 데이터 파이프라인 입니다.
데이터를 추출하고 변경하고 적재하는 과정이죠!
그렇다면 데이터 파이프라인을 구축하는데 있어서 안정적이고 확장성 높게 운영하기 좋은 방법은 뭐다?
바로 Apache Kafka를 활용 하는 것 입니다.
활용하기 전에 어떤 특징이 있기에 많은 회사들이 사용하는걸까요?
Kafka 특징
1. 높은 처리량
카프카는 프로듀서가 브로커로 데이터를 보낼 때와 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송 합니다.
많은 양의 데이터를 송수신할 때 맺어지는 네트워크 비용은 무시할 수 없죠!
동일한 양의 데이터를 묶음 단위로 처리하여 네트워크 통신 횟수를 줄인다면 동일 시간 내에 더 많은 데이터를 전송할 수 있습니다.
카프카뿐만 아니라 이런 처리는 SQL에서도 있었고 대량의 데이터일 경우에 모아서 처리하는 경우가 많습니다.
청크라는 단위로 모아서 처리했었는데 카프카는 어떤 용어를 사용할지 궁굼하군요! ㅎㅎ
2. 확장성
카프카는 어느정도의 데이터가 들어올지 모르는 상황에서 가변적으로 scale-out이나 scale-in을 할 수 있습니다.
이런 과정들은 클러스터의 무중단 운영을 지원하므로 365일 24시간 데이터를 처리해야하는 커머스나 은행 같은 비즈니스 모델에서도
안정적인 운영이 가능 합니다.
3. 영속성
데이터를 생성한 프로그램이 종료되거나 시스템이 재시작하더라도, 데이터가 사라지지 않고 유지되는 특성을 의미합니다.
카프카는 다른 메시징 플랫폼과 다르게 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장 합니다.
파일 시스템에 데이터를 적재하고 사용하는것은 보편적으로 느리다고 생각하겠지만, 카프카는 OS레벨에서 파일 시스템을
최적화하는 방법으로 파일 I/O 성능 향상을 위해 페이지 캐시(Page Cache) 영역을 메모리에 따로 생성하여 사용합니다.
페이지 캐시 메모리 영역을 사용하여 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식이기에 성능상 문제가
없습니다. 또한 디스크 기반의 파일 시스템을 활용하기 때문에 장애로 인해 갑작스런 종료에도 프로세스를 재시작하여
안전하게 데이터를 다시 처리할 수 있습니다.
4. 고가용성(HA)
3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를
처리할 수 있습니다. 클러스터로 이루어진 카프카는 데이터의 복제(Replica)를 통해 HA특징을 가지게 됩니다.
프로듀서로 전송받은 데이터를 여러 브로커 중 1대의 브로커에만 저장하는것이 아니라 또 다른 브로커에도 저장합니다.
한 브로커에 장애가 발생하더라도 복제된 데이터가 나머지 브로커에 저장되어 있으므로 저장된 데이터를 기준으로 지속적으로
데이터 처리가 가능 합니다.
또한, 서버를 직접 운영하는 온프레미스(on-pemise) 환경의 서버 랙 또는 퍼블릭 클라우드(public cloud)의 리전 단위 장애에도
데이터를 안전하게 복제할 수 있는 브로커 옵션들이 있습니다.
데이터 레이크 아키텍처에는 2가지 아키텍처가 있습니다.
1. 람다 아키텍처(lambda architecture)
2. 카파 아키텍처(kappa architecture)
우선 옛날부터 사용하는 데이터 수집은 원천데이터를 크롤링해서 정형화된 데이터로 만든다음에 DB에 저장하는 방식이였습니다.
- 원천 데이터 -> 파생 데이터 -> 서빙 데이터(DB)
원천 데이터로부터 파생된 데이터의 히스토리를 파악하기 어렵고, 계속되는 데이터의 가공으로 인해 데이터가 파편화되면서
데이터 거버넌스(Data Governance: 데이터 표준 및 정책)를 지키기 어려웠습니다.
이를 해결하기 위해서 기존의 배치 데이터를 처리하는 부분 외에 스피드 레이어(Speed Layer)라고 불리는 실시간 데이터 ETL 작업영역을
정의한 아키텍처를 만들었습니다.
바로 람다 아키텍처 입니다.
- 배치 레이어 -> 서빙 레이어
- 스피드 레이어 -> 서빙 레이어
배치 데이터 : 초, 분, 시간, 일 등으로 한정된 기간 단위의 데이터를 뜻 합니다.
스트림 데이터: 한정되지 않은 데이터로 시작 데이터와 끝 데이터가 명확히 정해지지 않은 데이터를 뜻 합니다.
마치 검색엔진에서 데이터를 수집해서 색인할 때 쓰는 방식과 비슷합니다.
데이터를 수집 시 정적색인과 동적색인이 있습니다. 정적은 전체를 색인하는 방식이고 동적색인은 동적으로 데이터를 색인하는 방식으로 실시간으로 데이터를 색인 합니다.
람다 아키텍처에서 카프카는 스피드 레이어에 속합니다.
데이터를 배치 처리하는 레이어와 실시간 처리하는 레이어로 분리한 람다 아키텍처!
이렇게 2개로 나눠져서 생기는 단점이 있습니다. 데이터를 분석, 처리하는 데에 필요한 로직이 2벌로 각각의 레이어로 존재해야함으로
배치 데이터와 실시간 데이터를 융합하여 처리할 때는 다소 유연하지 못한 파이프라인을 생성 해야한다는 점 입니다.
이러한 람다 아키텍처의 단점을 해소하기 위해 제이 크랩스(Jay Kreps: 카프카를 최초로 고안한 개발자 형님)는 카파 아키텍처를 제안 했습니다.
카파 아키텍처는 람다 아키텍처와 유사하지만 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리합니다.
- 스피드 레이어(Real-Time Layer) -> 서빙 레이어(Storage)
람다 아키텍처에서 단점으로 부각된 로직의 파편화와 디버깅, 배포, 운영 분리에 대한 이슈를 제거하기 위해 배치 레이어를 제거!
카파 아키텍처는 스피드 레이어에서 모든 데이터를 처리하므로 서비스에서 생성되는 모든 종류의 데이터를 스트림 처리 해야 합니다.
서비스에서 생성되는 모든 데이터가 스피드 레이어에 들어오게 되므로 스피드 레이어를 구성하는 플랫폼은 SPOF(Single Point Of Failure)가 될 수 있으므로 반드시 내결함성(HA)과 장애 허용(fault tolerant)의 특징을 가져야 합니다.
이런 특징을 가진 플랫폼은 카프카 입니다.
출처 : Kafka Summit APAC 2021에서 발표자료에서 가져왔습니다.
우버에서 사용하고 있는 카파 아키텍처 입니다!
2020년 카프카 서밋에서 제이 크랩스는 카파 아키텍처에서 서빙 레이어를 제거한 이카텍처인 스트리밍 데이터 레이크를 제안 했습니다.
스트리밍 데이터 레이크(Streaming Data Lake) Architecture
- 스피드 레이어
서빙 레이어는 하둡 파일 시스템, 오프젝트 스토리지(S3, minio 등)와 같이 데이터 플랫폼에서 흔히 사용되는 저장소 입니다.
굳이 카프카를 통해 분석하고 프로세싱한 데이터를 다시 서빙 레이어의 저장소에 저장할 필요가 있을까요? 라는 관점에서 나온거 같습니다.
스피드 레이어로 사용되는 카프카에 분석과 프로세싱을 완료한 거대한 용량의 데이터를 오랜 기간 저장하고 사용할 수 있다면 서빙 레이어는 제거하여 운영 리소스를 줄일 수 있습니다만 제 소견으로는 하둡 플랫폼쪽 생태계에서 많은 오픈소스들이 있을텐데 카프카가 만능이 되거나 주변 오픈소스들이 나와줘야 제대로된 스트리밍 데이터 레이크 아키텍처를 구현할 수 있을것 같습니다.
아직까지 주변 지인들에게 물어보면 하둡 플랫폼을 사용하고 있는걸 보면 아직까진 서빙 레이어를 걷어낸 아키텍처를 사용하고 있는것 같지는 않습니다. 하지만 끊임없이 발전하는 아키텍처들을 보면서 뭔가 모를 자극받고 포스팅을 마칩니다:)
- 출처 : 1) 아파치 카프카 애플리케이션 프로그래밍 with 자바 Book
2) webSite , Kafka Summit APAC 2021
끝!