메시지 큐와 카프카 간단하게 알아보자

우리 서버 구조에서는 카프카가 쓰이는 것을 알고는 있었는데 카프카가 정확히 어떤 역할을 하는지에 대한 지식이 미비한 듯하여 오늘은 카프카에 대해서 알아본 걸 간단하게 적도록 하겠다.


메시지 큐란?
카프카가 무엇인지 알아보기 위해서는 먼저 메시지 큐라는 개념을 먼저 알아야한다.

초창기의 구조는 A가 B에게 데이터를 직접 요청하여 받듯이 데이터를 직접 주고받는 구조는 방식이었다.

이 방식은 A와 B가 높은 결합도를 가지게되는데 예를 들어 A와 B는 반드시 서로의 존재를 알아야하며, B가 문제가 생길 시 A에도 영향이 생길 뿐더러 A외에도 추가적으로 B의 데이터가 필요한 C가 생긴다면 이를 또 새롭게 대응해줘야하는 여러 문제들이 있다. 결합도도 높고 확장도 불리하며 데이트 흐름도 단방향이라 추적까지 힘든 것이었다.

이러한 상황을 해결하기 위해 메시지 큐라는 아키텍처가 등장하게되었다.

 

메시지 큐는 시스템 혹은 애플리케이션 간의 결합도를 크게 낮춰 데이터를 안전하고 효율적으로 전송할 수 있는 아키텍처 혹은 인프라로, B가 완성된 데이터를 큐에 넣어놓으면 A는 이 큐에서부터 데이터를 꺼내 처리하면 되는 것이다. 즉 직접적으로 서로 연결하는 것이 아닌 하나의 우체통을 만들어 그 곳에서 서로 연락을 하는 것이다.
이렇게 하면 B가 느리거나 죽거나 해도 A의 시스템에는 전혀 영향이 없으며 혹시라도 큐에 넣어둔 처리해야할 데이터가 많아지면 언제든지 새로운 시스템을 붙여서 처리량을 높일 수도 있는 것이다.

그러나 이러한 메시지 큐는 데이터를 한 번 소비하면 삭제되기 때문에 여러 소비자가 동시에 같은 메시지를 보는 데는 어려움이 있다. 따라서 메시지큐는 단순히 데이터들을 전달하는데 좀 더 초점이 맞춰져있다고 할 수 있다.

 

 

이벤트 스트리밍 기반의 메시지 큐
과거 인터넷 서비스들은 이 정도로 충분했지만 최근에는 좀 더 데이터를 실시간으로 수집하고 분석해야하는 필요한 상황이 많아졌다. 이에 따라 카프카같은 이벤트 스트리밍을 기반으로 하여 메시지 큐 방식으로 처리한 시스템들이 나오기 시작했다. 

기존 메시지 큐와 다른 점으로는 먼저 메시지를 바로바로 지우지 않고 저장하여 1:1이 아닌 1:n으로써 데이터를 확산 가능하다. 소비자가 데이터를 가져가면 바로 지워버려 다른 시스템에서는 이를 확인하기 어려웠지만 해당 방식에서는 바로 지우는 것이 아니기에 다른 시스템에서도 가져갈 수 있고 또 소비자가 직접 어디까지 가져간 것을 추적하고 재처리도 가능해진 것이다.

 

 

	메시지 큐	이벤트 스트리밍 기반 메시지 큐
소비 방식	1회 소비 후 삭제	여러 소비자가 각자 읽음
저장 방식	짧게 보관	디스크 기반 장기 저장 가능
주 사용 목적	비동기 요청 처리	실시간 로그 수집/분석
확장성	제한적	파티션 기반 수평 확장