Kafka 역사와 소개

 

 

3. Kafka 소개

Kafka가 무엇인지 소개하는 시간을 가져보자

 

 

 

 

 

 

 

Contents

1. Kafka 역사
2. Kafka 소개
3. Kafka 아키텍처
4. Kafka 중요 개념
5. Kafka 설치
6. Kafka Python 프로그래밍

 

 

 

 

 

 

 

 

 

 

Kafka 역사

Kafka의 탄생에 대해 알아보자

 

 

 

 

 

 

 

Kafka의 탄생

2008년 LinkedIn에서 내부 실시간 데이터 처리를 위해 개발한 소프트웨어 플랫폼

Scala와 Java로 작성

 

2011년 초에 오픈소스화 (Apache)

https://kafka.apache.org/

 

현재 포춘지 선정 100대 기업 중 80% 이상이 Kafka를 사용

 

 

 

 

 

 

 

 

 

 

 

Kafka의 발전

 

2014년 Kafka 개발자들이 LinkedIn에서 나와서 Confluent라는 회사 창업

2021년 미국 나스닥 상장

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kafka 소개

Kafka가 구체적으로 어떤 서비스인지 소개해보자

 

 

 

 

 

 

 

 

 

 

Kafka란 무엇인가?

 

실시간 데이터를 처리하기 위해 설계된 오픈소스 분산 스트리밍 플랫폼

○ 데이터 재생이 가능한 분산 커밋 로그 (Distributed Commit Log)

○ 커밋 로그란 어떤 데이터가 입력되기 전에 이 데이터가 write된다는 사실을 로그형태의 기록으로 남기는 것을 말합니다. 커밋 로그는 Immutable하고 항상 타임스탬프가 붙습니다.

○ 커밋 로그가 있는 덕분에 추후에 데이터를 replay할 수 있습니다. 즉 복구를 할 수 있습니다.

 

Scalability와 Fault Tolerance를 제공하는 Publish-Subscription 메시징 시스템

○ Producer-Consumer (Publish-Subscription와 동의어)

 

High Throughput과 Low Latency 실시간 데이터 처리에 맞게 구현됨

 

분산 아키텍처를 따르기 때문에 Scale Out이란 형태로 스케일 가능

○ 서버 추가를 통해 Scalability 달성 (서버 = Broker)

 

정해진 보유기한 (retention period) 동안 메시지를 저장

○ 디폴트는 일주일입니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

기존 메시징 시스템 및 데이터베이스와의 비교

 

기존 메시징 시스템과 달리, 카프카는 메시지를 보유 기간 동안 저장

○ 소비자가 오프라인 상태일 때에도 내구성과 내결함성을 보장
○ 기본 보유 기간은 일주일

○ 후발주자인 AWS의 Kinesis, Google Cloud의 Pub/Sub들도 이 기능을 카피

○ 기간뿐만 아니라 토픽이 가질 수 있는 최대 데이터 크기를 지정하는 형태로도 지정 가능합니다.

 

Kafka는 메시지 생산과 소비를 분리

○ 생산자와 소비자가 각자의 속도에 맞춰 독립적으로 작업이 가능하도록 함
○ 시스템 안정성을 높일 수 있음

 

Kafka는 높은 처리량과 저지연 데이터 스트리밍을 제공

○ Scale-Out 아키텍처

 

한 파티션 내에서는 메세지 순서를 보장해줌

○ 다수의 파티션에 걸쳐서는 “Eventually Consistent”
○ 토픽을 생성할 때 지정 가능 (Eventual Consistency vs. Strong Consistency)

 

사내 내부 데이터 버스로 사용되기 시작

○ 워낙 데이터 처리량이 크고 다수 소비자를 지원하기에 가능

 

 

 

 

 

 

 

Eventual Consistency vs. Strong Consistency

 

In distributed systems like Kafka, consistency models define how and when changes made to data on one node are visible to other nodes. Here's a brief explanation of Eventual Consistency and Strong Consistency:

1. Eventual Consistency: In an eventually consistent system, updates to a data item will be propagated to all replicas eventually. This means that there could be a delay during which the replicas could be inconsistent - some replicas might have the update while others do not. Over time, however, all replicas will become consistent. This model allows for higher availability and tolerance to network partitions, but at the cost of consistency. In other words, you might read stale data sometimes.
2. Strong Consistency: In a strongly consistent system, updates to a data item are instantaneously visible to all nodes. Once an update is made, any subsequent access (read/write) will reflect that update. This means that a read operation will always return the value of the most recent write operation. Strong consistency is harder to achieve and often comes at the cost of availability and performance, especially in the presence of network partitions.

In the context of Kafka, it provides strong consistency within a partition of a topic (all messages sent by a producer to a particular topic partition will be appended in the order they are sent), but only eventual consistency across different partitions. This is because Kafka allows configuring replication for topic partitions, and these replicas eventually synchronize to have the same data, achieving eventual consistency.

 

 

 

 

 

 

 

잠깐! Eventual Consistency란? (1)

100대 서버로 구성된 분산 시스템에 레코드를 하나 쓴다면 그 레코드를 바로 읽을 수 있을까?

○ 내가 쓴 레코드가 리턴이 될까?
○ 보통 하나의 데이터 블록은 여러 서버에 나눠 저장됨 (Replication Factor)

    - 그래서 데이터를 새로 쓰거나 수정하면 이게 전파되는데 시간이 걸림
○ 보통 읽기는 다수의 데이터 카피 중에 하나를 대상으로 일어나기 때문에 앞서 전파 시간에 따라 데이터가 있을 수도 있고 없을 수도 있음

 

Strong Consistency vs. Eventual Consistency

○ 보통 데이터를 쓸때 복제가 완료될 때까지 기다리는 구조라면 Strong Consistency
○그게 아니라 바로 리턴한다면 Eventual Consistency

 

 

 

 

 

 

 

 

 

 

 

 

 

잠깐! Eventual Consistency란? (2)

 

 

새로운 데이터를 북미의 노드 A에 Write했을 때 가까운 노드 B는 새로운 데이터가 거의 동시에 보일 확률이 높지만 싱가포르의 노드 C는 새로운 데이터가 아닌 이전 데이터가 보일 확률이 높습니다.

 

만약 이와 같은 Eventual Consistency를 피하고 싶다면 Strong Consistency를 사용하면 됩니다. 비록 Write에는 시간이 다소 걸리겠지만 어떤 노드에서는 옛날 데이터 어떤 노드에서는 새로운 데이터가 보이는 상황이 아닌 모든 노드에서 새로운 데이터를 동시에 읽을 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

Kafka의 주요 기능 및 이점

 

스트림 처리

○ Kafka는 실시간 스트림 처리를 목표로 만들어진 서비스
○ ksqlDB를 통해 SQL로도 실시간 이벤트 데이터 처리 가능

 

High Throughput (높은 처리량)

○ Kafka는 초당 수백만 개의 메시지 처리 가능

 

Fault Tolerance (내결함성)

○ Kafka는 데이터 복제 및 분산 커밋 로그 기능을 제공하여 장애 대응이 용이

 

Scalability (확장성)

○ Kafka의 분산 아키텍처는 클러스터에 브로커를 추가하여 쉽게 수평 확장 가능

 

풍부한 생태계의 존재

○ Kafka는 커넥터와 통합 도구로 구성된 풍부한 에코시스템을 갖추고 있어 다른 데이터 시스템 및 프레임워크와 쉽게 연동 가능
○ Kafka Connect, Kafka Schema Registry