[학습 테스트로 배워보는 kafka] 1. 카프카 핵심 빠르게 훑어보고 아는체하기

---

해당 시리즈에서 제공하는 모든 소스코드는 github repository 에서 제공됩니다. 자세한 코드와 테스트 케이스는 github repository 에서 확인해주세요.

GitHub - my-research/kafka: apache kafka docs & practical usages(with spring) that i composed

이번 [학습 테스트로 배워보는 kafka] 시리즈는 아래 순서대로 챕터가 구성되고, 시리즈 외로 kafka 관련하여 더욱 많은 학습 정보는 kafka 심화 세션 에서 확인할 수 있습니다.

시리즈 목차

1. 시리즈를 시작하며
2. kafka 빠르게 훑어보고 아는체하기 <-- 현재 글
3. kafka 컨셉과 용어 정리
4. 학습테스트 준비하기
5. 학습 테스트로 kafka producer 알아보기
6. 학습 테스트로 kafka consumer 알아보기
7. 학습 테스트로 partitioning 알아보기
8. 학습 테스트로 consumer group 과 rebalancing 알아보기

학습의 단계별 순서로 목차가 구성되어있으므로 선행되어야 하는 챕터가 존재합니다

---

 

이번 챕터는 시리즈의 시작이며 카프카에 대해 이야기하는 첫번째 시간이다.

 

이번에는 빠르게 카프카의 컨셉과 내용들을 훑어볼 예정이다.

 

이번 시간의 목표는 카프카를 사용한다면 알아야할 내용들을 한 페이지에서 끝내는 것을 목표로 한다.

 

이번 시간의 이야기는 어디가서 아는척 할 수 있도록 하는것이 목표다. 부록 느낌으로 봐주면 좋을것 같고 당장 학습을 원한다면 넘어가도 좋다

 

kafka 가 왜 필요할까?

 

카프카가 무엇인지 ChatGPT 에게 물어보면 다음과 같은 말을 한다

 

 

이 말은 당신이 카프카를 배우기 위해서 이 글을 찾아 들어오기 전부터 익히 들어왔을 말이다.

 

실시간 데이터 스트리밍 처리 라고 표현하는데, 일반적으로 일괄 작업을 지원하는 배치 처리와 반대되는 개념이다.

 

현대 아키텍처의 흐름상 단일 서버 자원만으로 복잡해진 서비스를 지탱하기 어렵다.

 

그래서 일반적으로 여러 자원(서버, 컴퓨팅 엔진)을 분산시켜 각각을 고도화하는 방식 일명 마이크로서비스 아키텍처를 적용하는 곳이 많아졌고 성공 사례가 많아졌다.

 

분산된 서버간에 발생하는 이벤트나 로그 데이터, 일명 스트리밍 데이터라고 불리는 것들을 실시간으로 처리해야하는 요구사항이 점점 늘어나게 되었는데, 이에 반해 기존의 아키텍처에서는 이런 실시간 스트리밍 데이터에 대한 처리가 쉽지 않았다.

 

confluent.io - 복잡한 현대의 웹 아키텍처

 

위의 그림은 복잡한 현대 웹 아키텍처를 잘 보여준다.

 

위 그림에서도 알 수 있듯 하나의 앱/서비스에서 발생한 데이터들이 (일명 스트리밍 데이터) 시스템 전반에 걸쳐서 사용되는것을 볼 수 있다.

 

이런 복잡한 아키텍쳐에서 많은 사람들은 다음 3가지에 피로를 느꼈다

 

• 거짓된 데이터
• 실시간 트랜잭션에 의한 성능 저하
• 준수하지 못한 메시징 시스템의 성능

 

피로감 1. 거짓된 데이터

 

위의 복잡한 아키텍처를 잘 보면 user side 에서 발생한 데이터가 여러 시스템 컴포넌트를 거쳐서 재가공되는 것을 볼 수 있다.

 

 

이러한 상황에서 메시지 자체가 점점 본래의 의미를 잃게되고 시스템 이곳 저곳에서 서로 다른 정보로서 사용되는 것이다.

 

시간의 흐름에 따라 몇몇은 데이터의 본연의 의미를 보존하고 증명하는 무언가가 필요하다고 주장했다

 

우리는 이를 Single Source of Truth, 단일 진실 공급원 이라고 부르는데, 결국 단일진실공급원의 역할을 수행할 누군가가 필요했다.

 

피로감 2. 실시간 트랜잭션에 의한 성능 저하

 

영속화 과정에서 업데이트 연산을 안전하게 수행하기 위해서 일반적으로 hold and wait 방식을 사용한다.

 

https://www.geeksforgeeks.org/deadlock-in-dbms/

 

대부분의 복잡한 비즈니스 상황은 특정 데이터에 대한 점유와 그 데이터를 원하는 다른 경쟁자들의 대기로 안전성을 보장한다.

 

이 과정에서 대기시간이 늘어나게 되며 그에 대한 여파로 서비스 응답 시간의 저하가 발생하여 사용자에게 불편한 경험을 제공하게 되었다.

 

이러한 상황은 실시간 트랜잭션 (OLTP, OnLine Transaction Process) 이 동기적으로 발생하기 때문에 문제가 되는 것이다.

 

문제를 해결하기 위해서는 동기 방식의 트랜잭션을 없애고 비동기 방식의 처리 프로세스를 지원하기 위해서 메시징 인프라가 필요하게 되었다.

 

피로감 3. 준수하지 못한 메시징 시스템의 성능

 

메시징 인프라는 앞선 동기 방식의 트랜잭션 저하를 회피할 수 있는 좋은 기술이다.

 

messaging pub/sub infra - aws

 

이러한 메시징 인프라는 데이터 상호작용을 위한 컴포넌트가 직접 연결을 하는것이 아니라 중간에 위치한 message exchange 가 실제 메시지를 교환해주는 역할을 수행했다.

 

메시징 시스템 내부의 exchanger 들은 시스템 내에서 통신이라는 중요한 역할을 수행하기 때문에 신뢰성에 집중하여 설계되었다.

 

결국 신뢰성에 집중하다보니 성능에 대해서는 큰 관심사가 아니었는데, 메시지 인프라에 대한 책임이 커지며 부하가 많아져 결국 좋지 않은 사용 경험을 사용자에게 제공하였다.

 

이 상황에서 등장한 카프카

 

복잡해진 현대 웹 아키텍처를 해결하기 위해 linkedin 에서는 Jay Kreps 와 여러 엔지니어들을 필두로 사내에서 사용할 중앙 집중형 메시징 인프라인 kafka 를 개발하였다.

 

그리고 앞서 말한 3가지의 문제를 멋지게 해결하며 linkedin 의 핵심 infrastructure 로 자리잡게 되었고 앞선 아키텍처를 다음과 같은 형태로 간소화하게 되었다고 한다

 

confluent.io - linkedin with kafka

 

카프카가 다른 메시징 인프라와 차별점을 가지며 현존하는 최강의 데이터 플랫폼 인프라로 자리잡았다.

 

그 특성을 한 번 살펴보자.

 

log based architecture

 

카프카를 설명하기 위해 가장 적합한 단어는 로그 시스템이다.

 

로그는 append only 와 seeking by offset 이라는 특성이 있는데, 카프카 역시 이벤트 메시지들을 로그로 취급한다.

 

카프카는 로그 지향 시스템이기 때문에 특정 시점에 발생한 로그를 변경하거나 중간 삽입을 지원하지 않는다.

 

 

카프카는 휘발성 메모리에만 임시로 저장하여 특정 클라이언트가 소비하게되면 사라지도록 설계된 다른 메시징 인프라와 다르게, 메시지를 전부 저장한다

 

메시지를 전부 저장하는 특성덕에 추후 컨슈머 파트에서 이야기하겠지만 카프카를 사용한다면 메시지를 언제든지 다시, 어느 시점이든 읽어올 수 있다.

 

high availability & high scalability

 

카프카는 일반적으로 zookeeper 라는 분산 코디네이터와 함께 동작한다.

 

분산되어있는 카프카 인스턴스들을 클러스터링하는 것을 기조로 하기 때문에 이 특성을 활용하여 zero downtime 을 지원하는 scaling 이 가능하다.

 

또한 카프카는 현대의 다른 메시징 인프라의 장점들과 마찬가지로 producer 와 consumer 가 명확히 분리되어있다.

 

결국 과거 messaging infra 에서 볼 수 있는 과중한 일을 처리하는 exchanger 보다 빠른 성능을 제공한다.

 

Refs

• https://docs.confluent.io/kafka/introduction.html