강의 메모 #
아파치 카프카의 탄생과 기본 구조 #
카프카의 탄생
- 각각의 애플리케이션끼리 연결하여 데이터를 처리하는게 아닌, 한 곳에 모아 처리할 수 있도록 중앙집중화했다.
메시지 큐 구조를 그대로 살린 카프카 내부 구조 #
- 카프카 내부에 데이터가 저장되는 파티션의 동작은 FIFO(First In First Out) 방식의 큐 자료구조와 유사하다.
- 큐에 데이터를 보내는 것이 프로듀서
- 큐에서 데이터를 가져가는 것이 컨슈머
- 적재된 데이터를 하나하나 가져가더라도 파티션 내의 데이터는 삭제되지 않는다.
- 데이터를 읽는것 : 커밋 (데이터를 어디까지 읽었는지를 기록)
카프카가 데이터 파이프라인으로 적합한 4가지 이유 #
1. 높은 처리량 #
카프카는 프로듀서가 브로커로 데이터를 보낼때와 컨슈머가 브로커로부터 데이터를 받을때 모두 묶어서 전송한다. 동일한 양의 데이터를 보낼때 네트워크 통신 횟수를 최소한으로 줄인다면 동일 시간 내에 더 많은 데이터를 전송할 수 있다. 데이터를 묶음 단위로 처리하는 배치로 빠르게 처리할 수 있다. (대용량 실시간 데이터 처리에 적합) 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬 처리할 수 있다. 파티션 개수만큼 컨슈머 개수를 늘려서 동일 시간당 데이터 처리량을 늘리는 것이다. (sacle-out : 인스턴스 개수를 늘림 (컨슈머 개수를 늘림))
2. 확장성 #
데이터가 얼마나 들어올지 예측하기 어렵다. 이러한 가변적인 환경에서도 안정적으로 확장 가능하다. 데이터가 적을때는 카프카 클러스터의 브로커를 최소한의 개수로 운영하다가 데이터가 많아지면 클러스터의 브로커 개수를 자연스럽게 늘려 scale-out할 수 있다.
클러스터개념으로 운영하는데, 1개의 클러스터는 여러개의 브로커를 가지고있고, 각각의 브로커는 카프카 프로세서다. 데이터를 전송하면 각각의 브로커에 데이터가 저장된다. 각 브로커가 처리할 수 있는 데이터 처리량의 한계가 있고 데이터 처리량이 있을때 브로커를 추가하면 된다.
반대로 데이터 개수가 적어지고 추가 서버들이 더는 필요없어지면 브로커 개수를 줄여 스케일 인(scale-in)할 수 있다. 카프카의 스케일 아웃, 스케일 인 과정은 클러스터의 무중단 운영을 지원한다.
3. 영속성 #
영속성 : 데이터를 생성한 프로그램이 종료되더라도 사라지지 않은 데이터의 특성
카프카는 데이터를 파일 시스템에 저장한다. 이는 보편적으로 느리다고 생각하겠지만, 카프카는 운영체제 레벨에서 파일 시스템을 최대한 활용하는 방법을 적용했다. 페이지 캐시(page cache) 영역을 메모리에 따로 생성하여 사용한다. 페이지 캐시 메모리 영역을 사용하여 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식이다. 카프카가 파일 시스템에 저장하고 데이터를 저장, 전송하더라도 처리량이 높은 것이다. 디스크 기반의 파일 시스템을 사용하므로 급작스럽게 종료되더라도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다.
4. 고가용성 #
3개 이상의 서버들로 운영되는 카프카 클러스터 : 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리할 수 있다.
클러스터 브로커1, 브로커2, 브로커3 (3개 이상 운영) -> Producer 에서 데이터를 보냈을때 브로커1에서 브로커2,3으로 복제하여 저장한다. 여러 브로커에 데이터를 모두 저장함으로써 1대의 브로커에 장애가 발생하더라도 복제된 데이터가 나머지 브로커에 있으므로 지속적으로 데이터 처리가 가능하다. 이 적재된 데이터를 바탕으로 컨슈머가 각 브로커들의 데이터를 지속적으로 가져갈 수 있다.
빅데이터 아키텍처의 종류와 카프카의 미래 #
초기 빅데이터 플랫폼
각 서비스 애플리케이션으로부터 데이터를 배치로 모았다. 이런 방식은 end-to-end로 운영 데이터를 배치로 모으는 구조는 유연하지 못했고, 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못했다. 원천 데이터로부터 파생된 데이터의 히스토리 파악도 어려웠다.
람다 아키텍처 #
- 배치 레이어 : 배치 데이터를 모아서 특정 시간, 타이밍마다 일괄 처리
- 서빙 레이어 : 가공된 데이터를 데이터 사용자, 서비스 애플리케이션이 사용할 수 있도록 데이터가 저장된 공간
- 스피드 레이어 : 서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용
배치 데이터에 비해 낮은 지연으로 분석이 필요한 경우는 스피드 레이어를 통해 데이터를 분석한다.
한계 #
- 레이어가 2개로 나눠져서 불편함 존재
- 데이터를 분석, 처리하는데에 필요한 로직이 2벌로 각각의 레이어에 따로 존재해야한다.
- 배치 데이터, 실시간 데이터를 융합하여 처리할 때는 다소 유연하지 못한 파이프라인을 생성해야한다.
- 데이터를 분석, 처리하는데에 필요한 로직이 2벌로 각각의 레이어에 따로 존재해야한다.
카파 아키텍처 #
스피드 레이어, 서빙 레이어로 구성된다. 람다 아키텍처의 단점으로 부각되었던 로직의 파편화, 디버깅, 배포, 운영 분리에 대한 이슈를 제거하기 위해 배치 레이어를 제거했다. 스피드 레이어에서 데이터를 모두 처리하여, 더욱 효율적으로 개발과 운영에 임할 수 있게되었다.
카파 아키텍처의 활용 #
배치 데이터를 스트림으로 표현한다. 각 시점의 배치 데이터의 변환 기록(change log)을 시간 순서대로 기록함으로써 각 시점의 모든 스냅샷 데이터를 저장하지 않고도 배치 데이터를 표현할 수 있게 되었다.
배치 데이터 vs 스트림 데이터 #
- 배치 데이터
- 한정된(bounded) 데이터 처리 (분/시간 단위 처리 등)
- 대규모 배치 데이터를 위한 분산 처리 수행
- 복잡한 키 조인 수행
- 분, 시간, 일 단위 처리를 위한 지연 발생
- 스트림 데이터
- 무한(unbounded) 데이터 처리
- 지속적으로 들어오는 데이터를 위한 분산 처리 수행
- 분 단위 이하 지연 발생
- 단순한 키 조인 수행
배치 데이터를 처리하는 방법 (in 하둡) #
- block 단위로 데이터를 저장하고, 이것을 각 데이터 노드에서 메모리로 올리는 방식으로 데이터를 처리하고, 다시 HDFS에 저장
스트림 데이터를 배치로 사용하는 방법 (in 카프카) #
스트림 데이터를 배치 데이터로 사용하는 방법은 로그에 시간을 남기는 것이다. 로그에 남겨진 시간을 기준으로 데이터를 처리하면 스트림으로 적재된 데이터도 배치로 처리할 수 있게 된다. 카프카는 로그에 시간(timestamp)를 남기기 때문에 이런 방식의 처리가 가능하다.
스트리밍 데이터 레이크 #
카파 아키텍처랑 별개로 보면된다. 카파 아키텍처는 데이터를 사용하는 고객을 위해 스트림 데이터를 서빙 레이어에 저장하는 것을 알 수 있다. 스피드 레이어를 사용되는 카프카 분석과 프로세싱을 완료한 거대한 용량의 데이터를 오랜 기간 저장하고 사용할 수 있다면, 서빙 레이어는 제거되어도 된다. -> 서빙 레이어와 스피드 레이어가 이중으로 관리되는 운영 리소스를 줄일 수 있다. 달성하기에는 어렵다. (자주 사용하는 데이터, 자주 사용하지않은 데이터를 구분하는게 쉽지 않다.)
개선을 위한 노력 (현재는 제공되고있지 않음) 카프카 클러스터에서 자주 접근하지 않는 데이터는 오브젝트 스토리지와 같이 저렴하면서도 안전한 저장소에 옮겨 저장하고, 자주 사용하는 데이터만 브로커에서 사용하는 구분 작업이 필요하다.
오픈소스 아파치 카프카 생태계 #
카프카 생태계
- 프로듀서 -> 토픽으로 데이터를 넣는다.
- 토픽 <- 컨슈머가 데이터를 가져간다.
- 토픽에 저장된 데이터를 처리하고, 다시 토픽에 넣고 싶을때는 카프카 스트림즈라는 라이브러리를 사용한다.
- JAVA 라이브러리로 제공한다.
- 3rd party library (Go, js 등)
- 카프카에서 제공되는 여러 기능들을 완벽하게 쓴다는 보장이 없다.
- 3rd party library (Go, js 등)
- 오픈소스 카프카에 포함된 툴 (기본적인 release된 구조)
- 커넥트 : 데이터 파이프라인을 운영하는 툴
- 커넥트(싱크) : 컨슈머 역할 (타겟 애플리케이션으로 데이터를 보내는 역할)
- 커넥트(소스) : 프로듀서 역할 (특정 데이터베이스가 사용)
- 위 2개를 각 프로듀서, 컨슈머로 운영하면 되지않나?
- 템플릿 형태로 반복적으로 여러번 생성할 수 있고, 함께 운영하는게 특징이다.
- 커넥트에서 REST API로 보내게되면 파이프라인을 반복적으로 만들 수 있다.
- 위 2개를 각 프로듀서, 컨슈머로 운영하면 되지않나?