[Apache Kafka] 카프카(Kafka) 맛보기!

 

카프카(Kafka)란?!

Apache Kafka는 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 오픈 소스 분산 이벤트 스트리밍 플랫폼입니다. 여러 소스에서 데이터 스트림을 처리하고 여러 사용자에게 전달하도록 설계되었습니다.

 

간단히 말해 A지점에서 B지점까지 이동하는 것뿐만 아니라 A지점에서 Z지점을 비롯해 필요한 모든 곳에서 대규모 데이터를 동시에 이동할 수 있습니다.

 

카프카의 탄생 배경

카프카는 비즈니스 소셜 네트워크 서비스인 링크드인(linked-in)에서 개발했으며 아래는 카프카 개발 전 링크드인의 데이터 처리 시스템입니다.

 

각 애플리케이션과 DB가 end-to-end 로 연결되어 있고 요구사항이 늘어남에 따라 데이터 시스템 복잡도가 높아지면서 다음과 같은 문제가 발생하게 되었습니다. 

 

1. 시스템 복잡도 증가(Complexity)

통합된 전송 영역이 없어 데이터 흐름을 파악하기 어렵고, 시스템 관리가 어렵고, 특정 부분에서 장애 발생 조치 시간 증가합니다.

 

2. 데이터 파이프라인 관리의 어려움

각 애플리케이션과 데이터 시스템 간의 별도의 파이프라인이 존재하고, 파이프라인 마다 데이터 포맷과 처리 방식이 다릅니다. 또한 새로운 파이프라인 확장이 어려워지면서, 확장성 및 유연성이 떨어지며, 데이터 불일치 가능성이 있어 신뢰도가 감소할 수 있습니다.

 

이러한 문제들을 해결하기 위해 모든 이벤트/데이터의 흐름을 중앙에서 관리하는 카프카가 탄생하게 되었습니다!

 

카프카 적용 후

아래는 카프카를 적용한 후 링크드인의 데이터 처리 시스템입니다.

 

 

카프카를 적용함으로써 모든 이벤트/데이터의 흐름을 중앙에서 관리할 수 있게 되었고, 새로운 서비스/시스템이 추가되더라도 카프카가 제공하는 표준 포멧으로 연결하면 되므로 확장성과 신뢰성이 증가하였으며, 개발자는 각 서비스간의 연결이 아닌, 서비스들의 비즈니스 로직에 더욱 집중할 수 있게 되었습니다.

 

Kafka의 동작 방식

카프카는 기본적으로 메시징 서버로 동작합니다.

메시지라고 불리는 데이터 단위를 보내는 측(Publisher ▶ Producer)에서 카프카에 토픽이라는 각각의 메시지 장소에 데이터를 저장하면, 가져가는 측(Subscriber 또는 Consumer)이 원하는 토픽에서 데이터를 가져가게 되어있습니다.

 

Kafka가 아닌 일반적인 형태의 네트워크 통신은 아래와 같이 구성됩니다. 전송 속도와 결과를 신속하게 알 수 있는 장점이 있는 반면, 특정 개체에 장애가 발생한 경우 메시지를 보내는 쪽에서 대기 처리 등을 개별적으로 해주지 않으면 장애가 발생할 수 있습니다. 또한 통신에 참여하는 개체가 많아질수록 서로 일일이 다 연결하고 데이터를 전송해야하기 때문에 확장성이 좋지 않습니다.

 

일반적인 메시지 시스템 네트워크 통신 방식

 

이런 형태의 단점을 극복하고자 나온 통신모델이 Pub/Sub 모델입니다.

 

Pub/Sub 형태의 네트워크 통신

 

프로듀서가 메시지를 컨슈머에게 직접 전달하는게 아니라 중간의 메시징 시스템에 전달합니다. 이 때 메시지 데이터와 수신처 ID를 포함시킵니다.

 

메시징 시스템의 교환기가 메시지의 수신처 ID 값을 확인한 다음 컨슈머들의 큐에 전달합니다. 컨슈머는 자신들의 큐를 모니터링하고 있다가 큐에 메시지가 전달되면 이 값을 가져갑니다.

 

요악하자면, 기존 메시지 시스템에서는 브로커가 consumer에게 메시지를 publish 해주는 방식 것에 비해, Kafka는 consumer가 브로커로부터 직접 메시지를 가지고 가는 pull 방식으로 동작합니다. 따라서 consumer는 자신의 처리 능력만큼의 메시지만 가져오기 때문에 최적의 성능을 낼 수 있습니다.

 

 

카프카의 메시지 전달 순서

카프카의 메시지 전달 순서에 대해 이해하려면 우선 토픽(Topic)과 파티션(Partition)에 대한 이해가 필요합니다.

 

토픽(Topic)

카프카에서 데이터는 토픽이라는 이름의 카테고리에 저장됩니다. 각 토픽은 파티션으로 나뉘며, 이는 메시지를 분산 저장하는 역할을 합니다.

 

파티션(Partition)

파티션이란 토픽을 구성하는 하위 단위로, 각각의 파티션은 독립적으로 메시지를 저장합니다. 메시지는 파티션에 추가될 때마다 고유한 오프셋(Offset)을 부여받아 순서가 지정됩니다.

 

이제 메시지 전달 순서에 대해 설명해보겠습니다!

 

① 프로듀싱

데이터 소스에서 발생하는 이벤트는 프로듀서(Producer)에 의해 카프카로 전송됩니다. 프로듀서는 이벤트를 생성하여 특정 토픽의 특정 파티션에 전달합니다.

 

② 스토어링

프로듀서가 메시지를 토픽의 파티션에 전송하면, 카프카는 이 메시지를 파티션 끝에 추가합니다. 메시지는 고유한 '오프셋(Offset)'이라는 식별 번호와 함께 저장되며, 이 번호는 파티션 내에서 메시지 순서를 결정합니다.

 

③ 컨슈밍

컨슈머(Consumer)는 카프카 토픽의 파티션에서 메시지를 읽어 처리합니다. 컨슈머는 각 파티션에서 읽은 마지막 오프셋을 추적하여, 다음에 읽을 메시지의 위치를 알 수 있습니다.

 

④ 처리

컨슈머는 읽어온 메시지를 처리하며, 처리 방식은 컨슈머의 역할에 따라 다릅니다. 예를 들어, 데이터를 데이터베이스에 저장하거나, 다른 시스템에 전달하거나, 데이터 분석을 수행할 수 있습니다.

 

⑤ 커밋

메시지가 성공적으로 처리되면, 컨슈머는 커밋(Commit)을 수행하여 해당 메시지를 처리했다는 사실을 카프카에 알립니다. 이는 컨슈머가 다음에 데이터를 읽을 때, 마지막으로 커밋한 오프셋 다음의 메시지부터 읽어들일 수 있게 합니다.

 

 

이렇게 카프카는 프로듀서로부터 메시지를 받아 저장하고, 컨슈머가 메시지를 읽어 처리하고 커밋하는 과정을 거쳐 데이터를 처리합니다. 이 과정을 통해 실시간 데이터 스트리밍이 가능하게 됩니다!

 

 

 

 

 

 

출처

뜨뜨미지근한 물 - https://tjsals7825.medium.com/%EB%A9%94%EC%8B%9C%EC%A7%80-%EB%B8%8C%EB%A1%9C%EC%BB%A4-3-kafka-e0b51005c472

busybean3.log - https://velog.io/@busybean3/%EC%95%84%ED%8C%8C%EC%B9%98-%EC%B9%B4%ED%94%84%EC%B9%B4Apache-Kafka%EC%9D%98-%EB%8F%99%EC%9E%91-%EB%B0%A9%EC%8B%9D%EA%B3%BC-%EC%9B%90%EB%A6%AC-2

인생을 코딩하다 - https://junghyungil.tistory.com/190

Dragony.log - https://velog.io/@holicme7/Apache-Kafka-%EC%B9%B4%ED%94%84%EC%B9%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

Kafka - https://kafka.apache.org/

REDHAT - https://www.redhat.com/ko/topics/integration/what-is-apache-kafka

GYMCODING - https://gymcoding.github.io/2020/09/16/kafka-what/