카프카(Kafka)란?
카프카(Kafka)는 Apache 소프트웨어 재단에서 개발한 분산형 스트리밍 플랫폼이다. 주로 대용량의 실시간 로그 데이터를 처리하는 데 사용된다. 카프카는 데이터를 여러 프로듀서에서 생성하여 여러 컨슈머에서 소비할 수 있는 효율적인 방법을 제공한다.
기존 데이터 시스템의 구조는 각 애플리케이션과 데이터베이스가 end-to-end로 직접 연결되어 있었다. 이러한 구조는 간단하지만 각각의 데이터 파이프라인이 분리되어 있어, 요구사항이 증가함에 따라 시스템의 복잡도를 높이는 결과를 가져왔고, 아래와 같은 문제점들이 발생했다.
시스템 복잡도의 증가
- 중앙화된 데이터 전송 영역이 없어, 데이터의 흐름을 파악하기 어렵고, 시스템 관리가 복잡함.
- 시스템의 일부분에 문제가 발생하면, 연결된 모든 애플리케이션들을 확인해야 함.
데이터 일관성 유지의 어려움
- 데이터가 여러 시스템과 데이터베이스에 분산되어 있는 경우, 한 시스템에서 변경된 데이터가 다른 시스템에 즉시 반영되지 않아 데이터의 일관성을 유지하기 어려움.
데이터 실시간 처리의 어려움
- 전통적인 메시지 큐 시스템이나 데이터베이스는 대부분 배치 처리 방식을 사용함.
- 이는 데이터를 실시간으로 처리하는 것이 어렵다는 것을 의미.
확장성 제한
- 대부분의 전통적인 메시지 큐 시스템은 한정된 리소스 내에서 작동하므로, 대량의 데이터를 처리하는 데 제한이 있음.
- 데이터의 양이 증가하면서 시스템을 확장해야 하는 상황에서 이런 제한이 큰 문제가 될 수 있음.
아파치 카프카(Apache Kafka)는 이런 문제점들을 해결하기 위해 링크드인에서 개발되었고, 현재는 Apache Software Foundation의 오픈 소스 프로젝트로 유지 관리되는 분산 스트리밍 플랫폼이다.
카프카의 기본 구조
1. 프로듀서(Producer)
프로듀서는 Kafka에 메시지를 발행하는 역할을 하는 컴포넌트이다. 프로듀서는 다양한 데이터 소스로부터 데이터를 가져와 Kafka의 특정 토픽에 메시지를 발행한다.
2. 브로커(Broker)
브로커는 Kafka의 핵심 서버 컴포넌트로, 프로듀서로부터 메시지를 받아서 저장하고, 컨슈머에게 메시지를 전달하는 역할을 한다.
Kafka 클러스터는 여러 브로커들로 구성되며, 각 브로커는 하나 이상의 토픽의 메시지를 저장하고 관리한다.
3. 토픽(Topic)
토픽은 Kafka에서 데이터를 분류하는 단위다.
프로듀서는 메시지를 특정 토픽에 발행하고, 컨슈머는 토픽을 구독하여 메시지를 소비한다. 토픽은 여러 파티션으로 나뉘어질 수 있고, 이를 통해 데이터를 병렬로 처리할 수 있다. 각 파티션은 순서가 보장된 메시지 스트림을 제공하며, 브로커가 클러스터 내에서 파티션을 분산하여 저장한다.
4. 컨슈머(Consumer)
컨슈머는 Kafka의 특정 토픽을 구독하고, 해당 토픽의 메시지를 소비하는 역할을 하는 컴포넌트이다.
컨슈머는 하나 이상의 토픽을 구독할 수 있으며, 토픽의 파티션을 동시에 소비할 수 있다.
주키퍼(zookeeper)란?
코디네이션 서비스 시스템
분산 처리 시스템의 가장 큰 고민거리는 분산된 시스템끼리 어떻게 정보를 공유할 것인가? 이다. 쿠버네티스, 카프카 등 분산 시스템 자체는 클러스터를 중심으로 하위 노드들이 집결 되어 있는 형태가 보통인데 클러스터에서 하위 노드를 관리하기 위해 해야할 일은 아래와 같다.
- 각 하위 노드들의 Healthcheck
- 리소스 Lock Processing
분산된 서버들끼리 통신할 때 서로 리소스를 공유하려다 보면 자원 점유 문제가 발생하는데, 이를 처리하기 위한 대표적인 해결책으로는 바로 리소스 락(Lock)이 있다. 이 리소스를 Lock, Unlock하는데도 관리해주는 시스템이 필요하다.
이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템이라고 하며 이에 대표적인 오픈 소스 솔루션에는 바로 Zookeeper가 있다.
코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보 등을 유지하기 때문에 코디네이션 시스템의 장애는 전체 시스템 장애로 이어지는 장애 전파 특성을 지니고 있다. 따라서 이중화 등을 이용하여 고가용성을 제공하는 것이 필수다.
주키퍼
주키퍼는 분산 시스템 설계를 위해 필요한 코디네이션 서비스 시스템이 잘 구현되어 있는 오픈 소스 소프트웨어로서 코디네이션 서비스 시스템을 고가용성(HA)이 용이하도록 구현되어 있어 유명한 분산 솔루션에서 많이 사용되고 있다.
- Apache HBase (NoSQL)
- Apache Kafka
분산 시스템을 코디네이션 하는 용도로 디자인 되어 있기 때문에 다음과 같은 사항을 고려해야 한다.
- Data Access 속도가 빨라야 함.
- 자체적인 장애 대응 솔루션 필요 (예: 클러스터링)
Zookeeper는 자체적으로 클러스터링 기능을 지원하고 있어, 이러한 코디네이션 서비스 시스템 디자인에 있어 아주 쉽게 적용이 가능하다는 장점을 지니고 있으며 기능은 아주 단순하다.
설정관리 (Configuration Management)
- 클러스터의 설정 정보를 최신으로 유지하기 위한 시스템
클러스터 관리 (Cluster Management)
- 클러스터의 서버(브로커)가 추가되거나 제외될 때 그 정보를 클러스터 내 서버(브로커)들이 공유하기 위한 시스템
리더 채택 (Leader selection)
- 다중 애플리케이션 중 어떤 노드를 리더로 산출할 지 정하는 로직을 만드는 시스템
락, 동기화 (Locking and syncronization Service)
- 클러스터에서 쓰기 연산이 빈번할 경우 클러스터 전체를 동기화를 통해 데이터 불일치를 방지하는 시스템
분산 시스템에서 어떤 노드에게 연산을 시킬지 결정하는 것도 하나의 역할이다. 여러 노드들 중 유휴 상태인 노드를 찾는 로직을 어떤식으로 할지 정하는 리더 채택이 그 역할을 한다.
주키퍼 구조
주키퍼는 성을 확보하기 위해 다수의 Server를 사용하는 서버 클러스터 구조를 이용한다.서버 클러스터는 1개의 Leader와 N개의 Follower로 구성되어 있고, 이를 키퍼 앙상블(Zookeeper Ensemble)라고도 한다.
Client(Kafka)가 어떤 설정값 혹은 메타데이터를 주키퍼에 쓸 때 아래와 같이 동작한다.
- 클라이언트가 특정 서버에 접속하여 서버 데이터 업데이트
- 해당 서버는 Leader 서버에 데이터가 업데이트 되었음을 전송
- Leader 서버는 업데이트 신호를 받고, 다른 Follower 서버들에게 브로드캐스트(Broadcast) 형식으로 전송
- 나머지 Follower 서버들도 데이터 업데이트
위 4가지 과정을 통해 주키퍼는 데이터를 항상 일관성 있게 유지한다.
카프카와 주키퍼
카프카의 주키퍼 클라이언트는 카프카의 브로커를 관리하고 조정하는 데 사용된다.
카프카도 분산 처리 플랫폼이지만 메시지를 주고 받는 Pub/Sub 외에는 아무것도 하지 않는다. 따라서 브로커 상태를 저장하지 않기 때문에 상태 관리를 위한 주키퍼를 사용하는 것이다.
이 때 Producer와 Consumer는 카프카의 브로커 정보를 가지고 있다. 만약 동적으로 브로커의 상태가 변경(스케일 아웃 되는 등)되는 경우 이를 주키퍼가 Producer와 Consumer에게 알려준다.
일반적으로 카프카 메시지 브로커와 Zookeeper는 1:1로 구성되며 만약 Producer가 특정 카프카 브로커로 메시지를 생산했을 때 이를 실패하면 주키퍼가 다른 정상 서버로 Producer와 Consumer에게 브로커를 알리는 방식으로 운영된다.
참고:
