지금 바로 떠나자 먹으러....

카프카를 아시나요? 카프카는 독일 문학에서 유명한 작가로 체코 프라하에서 집필활동을 하던 작가입니다. 하지만 지금 제가 설명드릴건 프란츠 카프가가 아닌 메세지 퍼블리싱을 위한 프로젝트인 카프카에 대해서 입니다. 처음에는 링크드인에서 로그 메시지등을 처리하기 위해서 개발되었다가 프로젝트 팀이 Confluent라는 회사로 독립을 했고 현재는 아파치 재단에 속해 있는 프로젝트 입니다. 프로젝트 명을 카프카로 한 것은 카프카를 좋아했었고 어감이 좋아서 이름을 그렇게 만들었다고 합니다. 큰 의미는 없습니다.

 

그럼 본격적으로 카프카란 무엇인지 살펴보도록 하겠습니다.

카프카는 Pub-Sub(Publish-Subscribe) 시스템이라고 불리기도 합니다. Producer에서 메세지를 Publish하고 Consumer에서 Subscribe하여 메세지를 가져오는 구조이기 때문입니다. 왜 이런 구조로 만들게 되었을까요? 간단한 로그를 가져오는 시스템 구조를 예를 들어 보겠습니다.

 

A라는 서버에서 발생한 메시지들을 가져와 메트릭 데이터를 만드는 시스템이 있다고 가정해보겠습니다. 그러면 첫 번째 그림처럼 간단하게 네트워크를 통해 메세지를 가져올 수 있습니다. 하지만 두번 째 그림처럼 B라는 서버가 추가되었고 동일한 메트릭을 만드는 시스템이라면 서버 B와의 연결을 새로 만들어야 합니다. 그런 다음 어떠한 사정에 의해서 새로 추가된 메트릭 정보가 필요해졌습니다. 그러면 메트릭 A는 A와 B로부터 데이터를 받고 메트릭 B 역시도 A와 B로부터 데이터를 받아야 합니다. 이러한 구조는 확장되면 확장될 수록 엄청나게 복잡해지겠지요? 이러한 복잡도를 해결하기 위해 Pub-Sub시스템을 이용해볼까요? 서버 A와 B는 중간에 메트릭 Publisher를 관리해 주는 시스템과 연결을 합니다. 그리고 메트릭 데이터를 처리하는 Metric A와 Metric B는 Subscribe을 중간 시스템에 등록하게 합니다. 이렇게 Publish-Subscribe 시스템을 만들면 다음 그림과 같이 훨씬 간단한 구조로 시스템을 구성할 수 있게 됩니다.

하지만 아직 문제점이 남아 있습니다. 메트릭 데이터의 처리가 아닌 단순히 로그 메세지를 저장하는 모듈을 추가할 때는 어떻게 해야할까요? 로그 메시지를 관리하는 Pub-Sub가 또 필요하게 됩니다. 이렇게 계속 또 확장을 하다보면 Pub-Sub 구조가 여러 개가 필요해져서 처음과 비슷한 복잡한 구조를 가지게 되어 버립니다. 모든 Pub-Sub를 한 번에 관리할 수 있는 방법은 없을까요? 그걸 관리해주는 것이 바로 Kafka입니다. 카프카의 Broker는 등록된 Topic들을 관리하고 Producer로부터 생성된 메시지들을 Consumer에게 전달하기 위한 여러가지 과정들을 관리하게 됩니다. 다음에 Producer들은 어떤 일을 하는지 또 Consumer는 어떤 일들을 하는지 자세히 알아보도록 하겠습니다.