[Kafka] 아파치 카프카란?

 

이번 학기에 아파치 카프카에 대해서 스터디를 하게 되었는데 공부하면서 한번 정리를 해보려합니다!

혹시나 틀린 정보가 있다면 말씀해주세요!

 

현재 백엔드에서 빅데이터 처리시에 가장 많이 쓰이고 있는 플랫폼은 카프카인데요.

시작하기에 앞서, 우선 먼저 카프카를 한마디로 소개를 먼저 하자면 다음과 같습니다.

실시간 스트리밍 대용량, 대규모 데이터 처리에 특화된 프레임워크

 

이를 먼저 기억해주시고,  아래 글을 읽어주세요!

 

 

아파치 카프카(Kafka)의 시작

 

과거, 기존의 백엔드 서버에서 데이터를 수집하기위해 직접 데이터를 카테고리화 해서 저장을 하였습니다.
즉, 직접 1대1 매핑을 통해 데이터와 앱을 연결하여 카테고리처럼 저장하는 방식이였습니다.
초기에는 이러한 방식이 운영이 어렵지 않았고, 아키텍처도 복잡하지 않아서 운영이 힘들진 않았습니다.

하지만, 점점 서버는 발전을 하게 되었고, 그에 따라 서버의 아키텍처도 점점 복잡하게 발전을 했습니다.
이렇게 아키텍처가 점점 복잡해지면서 직접 1대1 매핑하는 방식은 다양한 불편함과 버그가 발생하는 이슈가 있었습니다.

 

과거의 1대1 매핑 방식의 아키텍처는 다음과 같습니다.

 

지금 얼핏봐도 굉장히 많이 복잡해 보이는 아키텍처입니다.
1대1 매핑 방식이다보니, 하나의 서비스에서 여러개의 연결고리가 생기고, 이에 따라 버전관리의 어려움도 생겼으며,
하나의 서비스에서 버그 발생시, 연결된 모든 곳에서 오류가 발생한다는 어려움도 생겼습니다.

이를 어떻게 해결하면 좋을까요?
바로 메세지큐 방식으로 중간에 하나의 '중앙 집중 장치'를 둬서 한곳에서 실시간 관리를 하는 것입니다.
이 중앙 집중 장치가 위에서 말한 카프카 입니다.
이를 통해 각각 1대1 매핑하여 데이터 처리를 하는 것이 아닌, 한 곳에 모아 간편하게 처리를 할 수 있게 되었습니다.
카프카가 적용된 아키텍처는 다음과 같습니다.

 

위의 사진을 보면, 모든 서비스는 카프카와 연결되어 있고, 이를 통해 아키텍처가 매우 간편해 진것을 확인할 수 있습니다.

즉, 카프카를 중앙에 배치함으로써, 서비스간의 의존도를 낮추며, 아키텍처를 매우 간편하게 구축할 수 있습니다.

 

 

 

 

 

 

 

 

카프카의 특징

 

카프카의 특징은 다음과 같습니다.

• 높은 데이터 처리량
  • 브로커가 데이터를 송수신 할때, 한번에 묶어 전송하기 때문에 네트워크 오버헤드가 적어 속도가 빠름.
  • 파티션 개수만큼 컨슈머의 개수를 늘려서 병렬처리로 데이터 처리가 빠름.
• 높은 확장성
  • 클러스터 및 브로커가 존재하여, 쉽게 스케일 아웃(Scale-Out)이 가능함.
  • 스케일 아웃 및 스케일 인 과정에서 무중단 운영을 지원하므로 안정적으로 확장이 가능함.
• 데이터 영속성
  • 다른 메세지 큐와 다르게 메모리에 저장하는게 아닌, 디스크 파일 시스템에 저장함.
  • 디스크 I/O 성능 향상을 위해 페이지 캐시 기능을 활용함.
• 고가용성
  • 클러스터 복제를 활용해 데이터 유실시에 복구 가능함.
  • 최소 3개 이상의 클러스터를 구성하여 장애 발생 시에도 안정적으로 데이터 처리 가능.

 

카프카의 특징은 위와 같습니다. 이러한 특징을 통해 대규모의 데이터를 처리를 빠르고 안정적이게 할 수 있어, 
요새 서버 아키텍처에서 대부분 카프카를 활용하고 있습니다.

위의 특징을 보면 브로커, 클러스터 등의 카프카 개념들이 나오는데요.
이제 카프카의 기본 구조 및 개념을 한번 알아보겠습니다.

 

 

 

 

 

 

 

 

 

카프카의 구조

 

 

카프카의 구조는 위의 사진과 같습니다. 카프카는 다양한 구성장치들을 포함하고 있으며,
해당 구성장치들을 활용해 대용량 데이터를 처리하고 있습니다.
이제 각 구성장치들을 자세히 알아보도록 하겠습니다.

 

• 주키퍼(Zookeeper)
  
  • 여러 브로커들의 상태를 모니터링하고 조정하는데 사용되는 분산 코디네이션임
  • 여러 서버를 클러스터로 구성하며, 해당 정보들을 지노드(znode)에 key-value 형태로 저장함
  • 주키퍼는 한개의 Leader와 나머지의 Follower로 구성되어 데이터 동기화를 진행함.
    
    (다만, 현재 카프카 측에서는 주키퍼 없이 관리할 수 있는 방향으로 개발이 진행되고 있다고 합니다...!)
    
    
• 카프카 브로커(Broker)
  
  • 여러대의 브로커와 주키퍼가 하나의 클러스터를 구축함.
  • Producer로부터 메세지를 받아들이고, Consumer에게 메세지를 전달하는 역할을 함.
  • 1개의 대표 브로커가 Controller가 되어, 나머지 브로커들의 상태를 확인하고 관리함.
  • 데이터 복제(Replication)을 통해 각 파티션들을 가용성있게 관리할 수 있음.
    (이 경우엔 각 브로커가 동일한 파티션을 가지고 있는 경우임)
• 토픽(Topic)
  • 카프카에서 카테고리처럼 데이터를 구분하기위한 단위
  • 한 토픽에 여러개의 파티션으로 구성되어 속도를 늘림.
  • 브로커가 데이터를 Push 및 Pull 하는 논리적 단위 (실제 데이터는 파티션에 저장됨)
• 파티션(Partition)
  
  • 실제 데이터가 저장되는 공간임
  • 각 파티션은 독립적으로 관리되어, 서로 독립적으로 데이터를 가지고 있음.
  • 한개의 Leader와 나머지의 Follower로 구성하여, Follower들은 Leader의 데이터를 복제 한 후, 읽기 작업을 병렬로 처리가능함
  • 파티션을 늘려 병렬처리를 함으로써, 처리 속도를 높일 수 있음.
• 프로듀서(Producer)
  • 카프카 브로커로 데이터를 전송하는 역할을 수행함.
• 컨슈머(Consumer)
  • 카프카 브로커로부터 데이터를 전달받는 역할을 수행함.
  • 컨슈머가 데이터를 받는다 해도, 해당 데이터가 없어지지않음.
• 세그먼트(Segment)
  • 실제 디스크에 저장되는 단위 (기본 값은 1GB)
  • Key-Value형태로 저장되며, 이진데이터 형태로 저장됨.
  • 일정 크기까지 모은 후, 한번에 Disk I/O를 진행함.

 

이렇게 카프카는 각 구성요소들이 함께 실행되며 이루어진 프로그램입니다.

 

이렇게 토픽을 기준으로 파티션을 구분하여, 실제 데이터를 카테고리화 하여 저장한다 라는 것을 알았습니다.

그럼 이제 좀 더 자세하게 카프카만의 특징에 대해서 알아보겠습니다.

 

 

브로커의 데이터 복제

 

위에서 카프카는 여러개의 브로커를 가질 수 있다고 하였습니다. 기본적으론, 이 브로커들끼리는 서로 다른 토픽과 파티션을 가지고 있어 독립적인 데이터를 가지고 있습니다.
하지만 카프카에선 데이터의 가용성을 보장하기위해 Replication Factor(복제 팩터)라는 개념을 활용합니다.

 

즉, 여러 개의 브로커가 존재할때, Leader-Follower 모델을 활용하여, 리더 브로커의 내용을 팔로워 브로커에게 복제하여

카프카를 안전히 사용할 수 있게 됩니다.

 

이때, 리더 브로커안에 있는 파티션은 Read-Write 둘다 가능하지만, 팔로워 브로커의 파티션은 Read만 할 수 있다 라는 특징이 있습니다.

 

이렇게 브로커가 3대일때, Replication Factor = 3 이라면, 브로커들은 각각 다른 데이터를 가지고 있는게 아니라, 동일한 데이터를 가지고 있습니다.

하지만 리더 브로커만 Write를 진행할 수 있고, 나머지 팔로워들은 Read만하여 읽기 작업때에만 병렬적으로 진행 할 수 있기 때문에, 처리 속도가 느려진다 라는 단점이 있습니다.

따라서, Replication Factor는 현재 카프카 내의 총 브로커 수와 현재 프로젝트의 요구사항에 맞춰 선택해야 합니다.

 

 

 

 

카프카의 동작 과정

 

지금까지 배운 카프카의 기본개념을 배웠습니다.
그럼 이제 간단히 카프카의 동작과정에 대해 순차적으로 살펴 보겠습니다.

 

 

1. 카프카 클러스터 실행
   - 주키퍼를 통해 카프카 클러스터를 실행 시킵니다.
   이때, 각 클러스터의 각 노드(서버)들은 브로커 역할을 합니다.
   
2. 토픽 생성
   - 프로듀셔와 컨슈머가서로 공유할 토픽을 생성합니다.
   이 토픽은 CLI를 사용해 생성할 수 있습니다.
   
3. Producer 데이터 Push
   - 프로듀서가 브로커에게 특정 토픽에 데이터를 Push 합니다.
   이때, 해당 토픽 안의 Partition 중 하나에 Push되며, 보통 라운드로빈 알고리즘으로 구현됩니다.
   
   
4. Consumer 데이터 Pop
   - 컨슈머가 특정 토픽에 데이터를 Pop 합니다.
   이때, 자신이 가져온 데이터의 OffSet을 기록하여 중복 소비를 방지합니다.
   또한, 데이터를 Pop한다고 Partition의 해당 데이터가 사라지는 것이 아니라, 그대로 남습니다.

 

 

토픽 이름 제약 조건

 

토픽은 개발자가 직접 생성하여 여러개의 토픽으로 관리를 할 수 있습니다.
토픽을 기준으로 실제 데이터가 구분되기 때문에 토픽의 이름을 잘 정하는것이 제일 중요합니다.
즉, 카프카에는 토픽 이름 제약 조건이 있는데, 다음과 같습니다.

 

• 아무것도 안들어간 토픽 이름은 지원하지 않음
• 마침표(.)와 언더바(_)가 동시에 들어가면 안됨.
• 토픽이름은 대소문자, 숫자, 마침표(.), 언더바(_), 하이픈(-)만 조합가능함.
• 실수를 줄이기 위해 케밥케이스(kebab-case)나 스네이크 케이스(snake_case)를 추천함.