[Kafka] 카프카 시작하기 1

현재 작성 중인 KAFKA 시리즈는 [카프카 핵심 가이드] 책을 보고 정리한 글임을 밝힙니다.

 

CHAPTER 1

과학자들이 서로 동의하지 않는 상황이 벌어진다면, 그것은 데이터가 불충분하기 때문이다. 그리고 어떤한 데이터를 얻을 것인지를 합의하고 데이터를 얻을 수 있다면 문제는 해결된다. 내가 옳든 상대방이 옳든, 아니면 둘 다 틀리든 말이다. 그제서야 우리는 그 다음으로 진행해 갈 수 있다

- 닐 디그래스 타이슨

 

데이터가 중심이 되는 기업에서 파이프라인은 핵심적인 요소임

데이터를 어떻게 이동시키느냐의 문제는 데이터 그 자체만큼이나 중요함

 

1.1. pub/sub 메시지 전달

아파치 카프카의 특징에 대해 이해하기 전, pub/sub 메시지 전달의 개념과 데이터 주도 애플리케이션에서의 중요성을 이해할 필요가 있음

 

pub/sub 메시지 전달 패턴의 특징

• 전송자가 데이터를 보낼 때 직접 수신자로 보내지 않는다는 것
• 대신, 전송자는 어떤 형태로든 메시지를 분류해서 보내고, 수신자는 이렇게 분류된 메시지를 구독함
• pub/sub 시스템에는 대개 발행된 메시지를 전달받고 중계해주는 중간 지점 역할을 하는 브로커가 있음

 

1.1.1 초기의 pub/sub 시스템

사례

• 가운데 간단한 메시지 큐나 프로세스 간 통신 채널을 놓은 것
• 예를 들어 어딘가로 모니터링 지표를 보내야 하는 애플리케이션을 개발했다고 치면, 애플리케이션에서 지표를 대시보드 형태로 보여주는 앱으로 연결을 생성하고 그 연결을 통해 지표를 전송함

발행자와 구독자가 직접 연결된 단일 지표 발행자

 

문제점

• 장기간에 걸처 지푯값을 분석하고자 한다면 이 대시보드가 잘 작동하지 않음
• 지표를 받아서 저장하고, 분석하는 서비스를 새로 하나 만듦
• 이 서비스가 작동하도록 하기 위해서는 애플리케이션을 고쳐서 두 시스템에 지푯값을 쓰게 만듦
• 지표를 생성하는 애플리케이션이 세 개가 되면, 두 서비스에 똑같은 연결을 또 만듦

발행자와 구독자가 직접 연결된 여러 지표 발행자

이러한 방식에서 발생하는 기술 부채는 명백하기 때문에 개선의 필요가 있음

 

모든 애플리케이션으로부터 지표를 받는 하나의 애플리케이션을 만들고, 이 지푯값들을 필요로 하는 어느 시스템이든 지표를 질의할 수 있도록 해주는 서버를 제공하면 됨

이것이 바로 pub/sub 시스템의 개념임

지표 발행 및 구독 시스템

 

1.1.2 개별 메시지 큐 시스템

지표를 다루는 것과 동시에 로그 메시지에 대해서도 비슷한 작업을 해줘야 할 수 있음

프론트엔드 웹사이트에서의 사용자 활동을 추적해서 이 정보를 기계 학습 개발자에게 제공하거나 관리자용 보고서를 생성하는 데 사용해야 할 수도 있음

이러한 경우에도 비슷한 시스템을 구성함으로써 정보의 publisher와 subscriber를 분리할 수 있음

 

아래는 세 개의 pub/sub 시스템으로 이루어진 인프라스트럭처임

다수의 pub/sub 시스템

 

하지만 아직 문제점이 존재함

 

문제점

• 중복이 많음
• 버그도 한계도 제각각인 다수의 데이터 큐 시스템을 유지/관리해야 함
• 비즈니스가 확장됨에 따라 함께 확장되는 시스템이 필요함
  • 예) 메시지 교환을 필요로 하는 사례가 추가로 생길 수도 있음

 

일반화된 유형의 데이터를 발행하고 구독할 수 있는 중앙 집중화된 시스템이 필요함