Kafka - 메시징 시스템

Kafka

 카프카는 메시지라고 불리는 단위를 다룹니다. 보내는 측(프로듀서)에서는 토픽이라는 메시지 저장소에 메시지를 저장하고, 메시지를 가져가는 측(컨슈머)은 원하는 토픽에서 메시지를 가져가기만 하면 됩니다. 중앙에 메시징 시스템 서버를 두고 메시지를 보내고(publish) 받는(subscribe) 형태의 통신을 펍/섭 모델이라고 하고 카프카는 펍/섭 모델을 기반으로 만들어진 메세징 시스템 입니다. 그래서 카프카에 대해 알기 위해선 펍/섭 모델, 메시징 시스템에 대해 알아야 한다고 생각합니다.

 

 그래서 이번 글에서는 카프카에 대한 설명 위주가 아닌 메시징 시스템을 도입하면 좋은점에 대해 설명하고 다른 메시징 시스템에 비해 카프카를 왜 사용해야 하는지에 대해서 간단하게 설명하겠습니다.

 

메시지 발행/구독 시스템의 장점

 

대부분의 발행/구독 시스템은 메시지 큐나 프로세스 간 통신 채널을 갖는 형태로 만들어집니다. 프론트엔드와 백엔드 서버로부터 메트릭 정보를 받아 화면에 정보를 보여주는 애플리케이션을 예로 들어보겠습니다.

 

카프카 핵심 가이즈 chapter1

 

초기에는 서버 구성이 위와 같이 간단 할 것입니다. 발행자(프론트엔드, 백엔드)와 구독자(메트릭 UI)가 직접 연결된 구조로 되어 있습니다. 현재는 알아보기도 쉽고 구현하기도 쉽게 되어 있습니다. 하지만 메트릭을 분석하는 서버가 필요할 수도 있고 서버의 상태를 모니터링 하는 서버가 필요하게 될 수도 있습니다. 서버의 숫자가 증가하면 어떻게 될까요?

 

 

 

 발행자와 구독자가 늘어남에 따라 선은 점점 많아지게 되고 위와 같이 그림으로 시스템 구조를 표현해도 알아보기 힘들게 될 것 입니다. 위 그림에서 추가적으로 데이터베이스 서버가 하나 더 생기고 데이터베이스 모니터링 서버가 추가 된다고 상상해보겠습니다. 선은 점점 더 많아지고 복잡도는 증가하게 될 것입니다.

 

 복잡도가 왜 증가하게 되는 것일까요? 이는 발행자와 구독자가 직접 연결되어 있기 때문입니다. 직접 연결 되어 있기 때문에 발행자,구독자의 서버가 추가되거나 변경이 발생할 때 영향을 끼치게 됩니다. 한 곳에 대한 변경이 다른 곳에 영향을 줄 수 있다는 의미가 됩니다.

 

 예를 들어, 메트릭 서버가 새로운 애플리케이션(채팅서버)으로 부터 메트릭을 수집하려고 한다면, 메트릭 서버는 채팅서버로부터 메트릭 데이터를 받을 수 있는 방법(HOW)에 대해 직접적으로 알고 있어야만 합니다. 메트릭 서버가 채팅서버에 대한 정보를 반드시 알고 있어야만 한다는 것입니다. 만약 채팅서버의 변경 또는 새로운 서버가 추가된다면 그때마다 메트릭 서버의 정보도 함께 변경을 해줘야 합니다.

 

 

요약하자면

 

• 직접 연결이 되면 한쪽의 변경이 다른 쪽에 영향을 끼치게 된다.
• 그 영향은 눈에 잘 보이는 영향일 수도 있고, 잘 보이지 않는  영향일 수도 있다.
• 이는 변화가 생길때마다 어떤 영향이 생길지 예측이 불가능하고 대응하기 어려울 수도 있다는 것을 의미한다. (대응을 하지 못해 장애를 유발할 수도 있다)
• 이러한 의존성은 줄여주는게 좋다.

해결방법은 결합도를 줄이는 느슨한 구조로 변경하는 것 입니다. 아래와 같은 구조로 변경을 한다면?

 

 

메트릭 발행/구독 서버를 추가하게 되면 데이터(메시지)를 발행자(전송자)가 직접 구독자(수신자)에게 보내지 않습니다. 이러한 구조로 변경을 하게 되면 아래와 같은 장점이 생깁니다.

 

• 발행자는 구독자의 정보를 알 필요가 없다 (직접연결,의존성을 없앤다). 서로의 변경에 영향을 받지 않게 된다.
• 발행자는 단순하게 발행/구독 시스템에 전송하면 구독자는 원하는 메시지를 읽어가기만 하면 된다.
• 이렇게 하면 새로운 발행자를 추가할 때, 발행자는 메트릭 발행/구독 서버만 알면 되고 그외의 정보는 필요하지 않게 된다. 발행자가 추가됐을 때, 구독자에 아무런 영향을 끼치지 않는다.
• 구독자가 추가되어도 발행자에는 아무런 영향도가 없다.
• 서버가 추가되어도 서로에게 영향을 끼치지 않으니 새로운 서버를 추가하거나 기존 서버를 변경하는데 수월해지고, 이는 수평적인 확장을 가능하게 해준다.

 

 메시징 시스템을 도입하면 점점 복잡해지는 아키텍처를 단순화 시킬 수 있습니다. 그럼 메시징 시스템 중에서 왜 카프카를 사용해야 하는지 알아보겠습니다.

Why Kafka?

 

메시징 시스템 중에서 왜 카프카를 사용해야 할까요? 우선 간단하게 카프카 용어에 대해 설명하고 카프카의 장점을 알아보겠습니다.

 

• 브로커 : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드
• 토픽 : 프로듀서가 생산한 메시지를 저장하는 저장소
• 프로듀서 : 메시지를 생산하는 서버 또는 애플리케이션
• 컨슈머 : 메시지를 소비하는 서버 또는 애플리케이션

 

다중 프로듀서, 다중 컨슈머

 메시징 시스템의 발행자의 역할을 하는 것이 카프카의 프로듀서 입니다. 여러 클라이언트가 많은 토픽(메시지 저장소)을 사용하거나 같은 토픽을 사용해도 카프카는 무리없이 처리할 수 있습니다. 여러 프로듀서로부터 데이터를 수집하고 일관성을 유지하는데 이상적인 구조를 가지고 있습니다.

 

 메시징 시스템의 구독자 역할을 하는 것이 카프카의 컨슈머 입니다. 카프카는 많은 컨슈머가 상호 간섭 없이 어떤 메시지도 읽을 수 있게 지원합니다. 다른 메시징 시스템의 경우엔 한 구독자 클라이언트가 특정 메시지를 소비하면 다른 구독자 클라이언트에서는 그 메시지를 사용할 수 없습니다. 하지만 카프카 컨슈머는 컨슈머 그룹이란 개념을 이용하여 각각의 컨슈머가 메시지를 관리할 수 있습니다. 이에 대해서는 후에 파티션 및 오프셋이란 용어와 함께 설명 하겠습니다.

 

디스크 기반의 보존

카프카 프로듀서에 의해 저장된 메시지는 디스크에 보존할 수 있습니다. 컨슈머의 메시지 처리가 느리거나, 접속 폭주로 인해 컨슈머가 메시지를 읽는 데 실패하더라도 디스크에 저장되었기 때문에 유실될 위험이 없습니다. 또한 컨슈머가 동작하지 않더라도 메시지는 카프카에 보존되므로 메시지의 백업이 필요없습니다. 또한 중단되었던 컨슈머가 다시 실행되면 중단 되었던 시점부터 메시지를 처리할 수 있기 때문에 시스템 중단으로 인해 메시지를 유실할 위험이 적습니다.

 

확장성

카프카는 확장이 매우 용이하도록 설게 되어 있습니다. 확장 작업은 카프카 서비스 중단 없이 온라인 상태에서 작업이 가능하므로 부담없이 진행할 수 있습니다.

 

고성능

카프카는 내부적으로 분산 처리, 배치 처리 등의 기법을 사용해 고성능을 유지하게 만들어져 있습니다.

 

 

 

추가로 카프카가 왜 빠른지 설명해주는 글을 공유하겠습니다.

https://medium.com/swlh/why-kafka-is-so-fast-bde0d987cd03

 

카프카의 근간이 되는 메시징 시스템 및 카프카를 왜 사용하는가에 대한 간단한 설명을 마치겠습니다. 다음 글부터 본격적으로 카프카 용어 및 구조에 대해 알아보겠습니다.

 

 

<참고>

카프카 핵심 가이드 , 제이펍

카프카, 데이터 플랫폼의 최강자 , 책만