나는 개발보다 빅데이터플랫폼,데이터파이프라인 이런 데이터엔지니어쪽을 공부하고 싶다.
하지만 막상 너무 막연해서 매번 무료강의임에도 미뤄뒀는데 갑자기 어느순간 배우고 싶어서 강의를 들었다.
오늘이라도 가끔 시간날때마다 한번씩 보려고 한다...
한번 들어본거랑 아예 모르는거랑은 다르니까.....한번이라도 들어두면 나중에 볼때 다르겠지..
아래의 내용 및 이미지는 [데브원영] 아파치 카프카 for begineers 강의 요약 및 추가 공부한 내용입니다.
자세한 강의는 위의 연관링크 참고부탁드립니다. 감사합니다.
정의 | 아파치 카프카(Apache Kafka)란?
대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 분산 메시징 플랫폼
즉, 카프카는 어플리케이션간에 메세지를 교환하기 위해 사용되는 메세징 시스템
링크드인(LinkedIn)에서 개발해 2011년 초 오픈소스로 공개되었다.
아파치 카프카는 빅데이터를 분석할 때 여러 스토리지와 분석 시스템에 데이터를 연결하기 위한 필수도구로 인식
데이터 파이프라인 구성시 주로 사용되는 오픈소스 솔루션
카프카의 기본개념을 이해하기 쉽게 '메일'에 비교한 설명을 발견했다.
우리가 잘 알고 있는 메일의 경우 보내는 사람은 받는 사람과 상관 없이 메일 서버로 메시지를 보낼 수 있다.
보낸 메시지는 메일서버에 저장되어 있고, 받는 사람은 자기가 원하는 시간에 언제든지 메일을 볼 수 있게 된다.카프카도 비슷하다.
프로듀서는 카프카로 메시지를 보내게 되고, 해당 메시지는 카프카에 저장되어 보관중이다.
그리고 컨슈머는 카프카에 저장되어 있는 메시지를 필요로 할때, 가져갈 수 있다.
배경 | 아파치 카프카를 왜 쓰는가?
소스어플리케이션 : 데이터전송, 타겟어플리케이션 : 데이터받음 -> 단방향이였지만 소스/타겟들이 점점 많아짐
- 실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이루어지지만 통합된 전송 영역의 부재로 복잡도가 증가
- 파이프라인 관리가 어려움. 특정 부분을 수정해야할 때, 앞단부터 다 수정해야 할 수 있음
그러니까 카프카가 발신자와 수신자를 연결해준다.
- 발신자 (Publish) : 카프카에게 데이터를 전송하기만 하면 된다. 누가받을지는 신경안씀.
- 수신자 (Subscribe) : 수신자는 카프카에 원하는 토픽을 구독한다.
그래서 누가 보냈는지 신경안쓰고, 필요한 메세지만 구독하는 방식.
이전 point to point구조에 비해 매우 단순해지고 유지보수,에러발생,네트워크 트래픽의 장점까지 얻음
구조 | 카프카 아키텍쳐
카프카도입 전 (Point to Point 방식)
Point to Point 방식은 큐를 통해서 전달할 메세지를 전달하면 받는 사람이 큐에서 메세지를 사용한다
FIFO 큐처럼 받는 사람들은 모두 하나씩 큐를 가지고 있고, 보내는 사람들이 목적지 큐에 전달하면 받는사람이 꺼내읽음
->데이터연동의 복잡성이 증가
기존엔 데이터 스토어 백엔드관리, 백엔드에 따라 포맷, 별도의 앱개발 필요했음
즉, 데이터전송라인이 많아짐 -> 배포/장애대응 어려워짐->데이터포맷의 변경사항이 생길때 유지보수어려워짐
카프카도입 후(Pub/Sub 방식)
중간에 Topic이 있다.
구독자가 특정 토픽이나 이벤트에 구독을 해 놓으면 해당토픽이나 이벤트에 대한 통지를 비동기 방식으로 받는다.
즉, Publisher가 Topic에 메세지를 보내면 해당 topic을 구독해돊은 모든 사용자들에게 메세지가 전송된다.
->프로듀서와 컨슈머를 분리해서 높은처리량 가능, 스케일아웃 가능
차이점
- Point to Point방식은 메세지를 각각 1명의 사용자만 받을 수 있지만,
Pub/Sub방식은 토픽을 구독한 많은 사용자가 메세지를 받을 수 있다.
- Point to Point방식은 메세지를 받는 사람이 큐에서 꺼내읽는 방식이지만,
Pub/Sub방식은 토픽에서 꺼내오는게 아니라 토픽에서 BroadCast 되는 방식. 사용자들에게 메세지가 통보되는 개념
Pub/Sub방식 장점
카프카에만 데이터를 전달하면 필요한 곳에서 각자 가져갈 수 있음
카프카가 제공해주는 표준 포맷으로 연결되서 데이터를 주고받는게 부담이 덜해짐
용어 | 아파치 카프카 구성요소
간단하게 소스에서 카프카를 걸쳐 타겟으로 데이터를 전송하는 flow라고 볼 수 있다
소스어플리케이션(클릭로그,결제로그)--> 데이터전송->카프카--> 데이터전송 ->타겟어플리케이션(로그적재,로그처리)
이 과정을 아파치 카프카의 구성요소에 따라서 다시 구체화하면
프로듀서가 레코드를 생성하여 브로커로 전송하면,
전송된 레코드를 파티션에 신규오프셋과 함께 기록이 되고,
컨슈머가 브로커로부터 레코드를 요청하며 가져가는 flow가 된다.
일단 이 강의에선 3가지만 간단하게 보고, 나중에 더 구체적으로 찾아봐야겠다
1. Topic
일종의 '큐', 카프카안에 topic가 있다.
즉, 프로듀셔와 컨슈머들이 카프카로 보낸 자신들의 메세지를 구분하기 위한 이름.
다수의 프로듀서, 컨슈머들이 동일한 카프카를 사용하면 메세지들이 뒤섞이기 때문에 토픽으로 구분한다.
2. Producer
큐에 데이터를 넣는다.
메세지를 생산해서 브로커의 토픽이름으로 보내는 서버 또는 어플
3. Consumer
큐안에 데이터를 가져온다.
브로커의 토픽 이름으로 저장된 메세지를 가져가는 서버 또는 어플
특징 | 아파치 카프카 특징
- Pub/Sub 방식 (publish-subscribe 모델)
- Producer, publisher : 데이터 단위를 보내는 부분
- Consumer, subscriber : 토픽이라는 메시지 저장소에 저장된 데이터를 가져가는 부분
- 중앙에 메세지 시스템 서버를 두고 메세지를 보내고(publish) 받는(subscribe) 형태의 통신모델
각각의 서버/서비스들은 모니터링이나 분석시스템의 상태 유무와 상관없이
카프카로 메세지를 보내는 역할만, 카프카에 저장된 메시지를 가져오는 역할만 하면 됨
즉, 역할이 완벽하게 분리가 되어 어느한쪽 시스템에서 문제가 발생해도 다른 시스템에 영향을 미칠 확률이 낮아짐
서버가 추가되더라도 카프카로만 보내면 되기 때문에 서버추가에 대한 부담감도 줄일 수 있음
참고로, pub/sub구조는 아파트 택배시스템과 유사하다고 참고한 자료에서 읽었따.
모든 택배원들이 동과 호수를 방문해서 택배를 직접 놓으면 오래걸리고, 택배기사님들도 힘듦
하지만 특정장소에 택배를 모아두는 방식은 택배기사는 장소에 보내기만하고, 주민들은 받기만 하니까 더 간단
- 디스크에 메세지를 저장하고 유지가능
컨슈머가 메세지를 읽어도 정해져 있는 보관주기 동안 저장
그래서 트래픽이 일시적으로 많거나 컨슈머에 오류가 있떠라고 메세지 손실이 없음
- 하나의 토픽에 여러 프로듀서, 여러 컨슈머 접근가능
- 확장용이
하나의 카프카 클러스터에 3대의 브로커로 시작해서 수십대의 브로커로 무중단 확장가능
- 고가용성
서버이슈에도 데이터를 손실없이 복구 가능
낮은 지연과 높은처리량으로 대용량 데이터 처리 가능
기존 메세징시스템(ActiveMQ, RabbitMQ) | 아파치 카프카 |
대용량의 실시간 로그 처리에 특화되어 설계 | |
분산 시스템을 기본으로 설계 -> 분산 및 복제구성 쉬움 | |
Producer가 broker에게 다수의 메시지를 전송할 때 각 메시지를 개별적으로 전송 | 다수의 메시지를 batch형태로 broker에게 한 번에 전달 가능 |
메시지를 기본적으로 메모리에 저장 | 메세지를 파일 시스템에 저장 |
broker가 consumer에게 메시지를 push해 주는 방식 |
consumer가 broker로부터 직접 메시지를 가지고 가는 pull 방식 |
참고
zzsza.github.io/data/2018/06/15/apache-kafka-intro/
'Book & Lesson' 카테고리의 다른 글
[책정리] 빅데이터를 지탱하는 기술 목차 (0) | 2021.06.16 |
---|---|
kafka강의6 | 카프카 버로우(Burrow) (0) | 2021.03.25 |
kafka강의5 | 컨슈머 랙(Consumer Lag)이란? (0) | 2021.03.25 |
kafka강의4 | 파티셔너(Partitioner)란? (0) | 2021.03.24 |
kafka강의3 | 브로커, 복제, ISR(in-sync-replication) (0) | 2021.03.24 |
kafka강의2 | Topic이란? Pub/Sub 구조 (0) | 2021.03.22 |