[Kafka] 탄생 배경 (1)

전통적인 Database 시스템 구조는 애플리케이션과 DB가 연결된 end-to-end 형태를 띄고 있다. 하지만 간단한 구조에 반해 각각 분리된 Data 파이프 라인이 필요하고 요구사항이 증가함에 따라 더욱 복잡해지는 문제가 생긴다.

시스템 복잡도가 증가하면 아래와 같은 문제가 발생한다.

1. 중앙화된 데이터 전송 영역의 부재
2. 데이터 흐름을 파악하기 어려움
3. 복잡한 시스템 관리
4. 일부 문제 발생 시 연결된 모든 애플리케이션을 확인

end-to-end 형태 시스템은 시스템을 복잡하게 만드는 것에서 나아가 여러 문제를 일으킨다.

• 데이터 일관성을 유지하기가 어려워진다
• 실시간 데이터 처리가 어렵다
• 확장성에 제한이 생긴다.

이런 이유들로 인해 링크드인은 DB와 어플리케이션 사이를 중개하는 메시지 브로커, Kafka 를 만들게 된 것이다.

카프카를 개발하던 개발자들은 아래와 같은 목표를 세우고 카프카를 구상하기 시작했다.

• 프로듀서와 컨슈머의 분리
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
• 높은 처리량을 위한 메시지 최적화
• 데이터가 증가함에 따라 스케일아웃이 가능한 시스템

카프카를 개발하면서 데이터 스토어 백엔드 관리와 백엔드 포맷, 별도의 앱 개발 과정을 생략할 수 있게 된다. 카프카에만 데이터를 전달하면 해당 데이터를 필요로 하는 서비스들이 각자 가져가면서 본연의 업무에 집중할 수 있는 것이다.

카프카는 메시지 전달을 위한 중앙 플랫폼으로, 다른 갖가지 서비스와 연결된 파이프라인을 만들 수 있도록 설계된다.

메시지 전달을 위한 중앙 플랫폼이라 표현하고 간단하게 메시지 큐의 일종이라 할 수 있다.

메시지큐

응용 소프트웨어 간 비동기적 데이터 통신을 위한 소프트웨어를 메시지 지향 미들웨어(MOM) 이라고 하는데, 메시지 큐는 메시지 지향 미들웨어(MOM) 을 구현한 시스템이다.

Producer 라는 메시지 발행부와 Consumer 라 하는 메시지 소비 부분으로 구성된다. 메시지 큐는 그 사이에서 메시지를 전달하는 매개체 역할을 한다.

 

일반적으로 Producer에서 메세지를 생성, 전송하고 큐를 사용하여 producer, consumer간 결합성을 약하게 해주면서 우선순위나, 라우팅, failover등 여러 기능을 제공해주고 consumer에서 메세지를 사용하는 구조이다.

이를 기반으로 구성된 Kafka 는 분산 메시징 시스템이다. 분산 환경에 특화되었으며 rabbitmq와 비슷한 역할을 하지만 클러스터링 구성이나 fail-over를 쉽게 할 수 있도록 설계되어있다. broker의 역할을 하지만 중앙집중화되어있고 소비자 중심의 rabbitmq와 다르게 생산자 중심으로 설계됐다. 구독 방식의 비동기식으로 구성되어있다(pub-sub모델)