본문 바로가기

STUDY/실전 카프카 개발부터 운영까지

1장 - 카프카 개요

MSA의 등장

 

과거에는 하나의 어플리케이션에 모든 기능이 들어가있는 모놀릭 아키텍처가 대부분이었다. 따라서 모든 데이터의 흐름은 어플리케이션 안에서 이루어지고, 다른 어플리케이션과의 데이터 공유는 제한적이었다. 하지만 시대가 변하고, 최근에는 대부분의 어플리케이션이 마이크로서비스 아키텍처를 채택하고 있다. 마이크로서비스 아키텍처는 하나의 어플리케이션을 각각의 기능을 가지는 여러 서비스로 나누고, 이들을 결합하여 운영하는 구조이다. 따라서 서비스간의 활발한 데이터 공유가 이전보다 더욱 많아지고 중요해졌다.

 

 

 


문제발생

 

서비스간 데이터 공유를 한다는 것은 공통에 저장소에서 데이터를 사용하는 것(Reddis나 Oracle Database 같은 경우)일 수도 있다. 아니면 한 서비스에서 다른 서비스로 데이터를 전송하는 것 일수도 있다. 여기서는 데이터를 전송하는 경우를 얘기해보겠다. 한 어플리케이션을 개발했고, 그 어플리케이션 안에는 회원 정보를 관리하는 CustomerService, 메일발송을 관리하는 MailService가 있다. 신규 회원 가입이 완료되면, 환영 메일 발송을 위해 해당 내용을 CustomerService에서 MailService로 데이터를 보내야 한다.

 

위와 같이 CustomerService가 MailService로 직접 데이터를 보내도록 하면, 처음 개발할 때는 간단하지만 여러 문제가 발생한다.

  • 메일 서비스가 다운된다면, 회원 서비스에 문제가 없을 때에도 회원가입기능을 정상적으로 수행할 수 없다.
  • 회원 서비스의 기능 처리 성능이 충분히 빠르더라도, 메일 서비스의 기능 처리 속도에 맞춰야 한다.
  • 한 서비스에 보내거나 받는 데이터 모양이 바뀌어야 하면, 반대쪽 서비스도 같이 수정되어야 한다.
  • 한마디로 각 서비스간에 느슨한 결합이 이루어지지 못한다.

 


메세지 브로커

 

메세지 브로커란 송신자/수신자 사이에서 데이터 통신을 도와주는 미들웨어이다. 메세지 브로커는 송신자에게 데이터를 수신하고 이를 정해진 목적지로 라우팅 해주고, 수신자에 맞게 데이터를 변형해주며, 장애 및 오류에 대응하는 역할을 수행한다. 이에 따라 송신자와 수신자는 서로를 신경쓰지 않고 메시지 브로커를 통해 데이터를 주고 받을 수 있으며, 느슨한 결합을 달성 할 수 있다.

 

 


카프카(Kafka) 

 

카프카는 링크드인이 내부에서 발생하는 문제점들은 해결하기 위해 만든 메세지 브로커이다. 데이터 파이프라인 확장의 어려움, 이기종 간의 호환성, 고성능의 데이터 처리 등의 이슈를 가지고 있었고 카프카를 개발하여 이를 해결하였다. 이후 뛰어난 메세지 브로커로 인정을 받으며 다양한 기업들에서 사용하고 있다.

 

카프카는 Pub/Sub 구조를 채택하고 있다. Producer는 Consumer가 누군지 모른상태로 Topic에 메시지를 발행하고, Consumer 역시 Producer가 누군지 모른 상태로 필요한 Topic에서 메시지를 구독한다. 여기서 메세지는 단순한 큐 처럼, Consumer가 데이터를 받아간다고 사라지지 않는다. 이 때문에 Kafka는 메세지 큐가 아니라 메세지 스트리밍 플랫폼이라고 불린다. 그리고 이 덕분에 Consumer와의 결합도가 높지 않아 확장이 용이하다.

 

 


vs RabbitMQ

 

 

RabbitMQ는 카프카와 마찬가지로 데이터 송수신을 중계하는 메시지 브로커이다. 하지만 카프카의 Pub/Sub 구조와는 다르게, 메세지 큐 방식을 사용한다. Producer가 보낸 데이터는 정해진대로 각 Consumer를 위한 메시지 큐에 들어간다. 그리고 Consumer들은 자신의 메세지 큐에서 데이터를 가져온다. 그리고 큐의 특징대로 Consumer가 가져간 데이터는 큐에서 사라진다. 그래서 RabbitMQ는 Consumer와 결합도가 비교적 높고, 확장성이 좋지 않다는 말을 듣는다.

 

하지만 RabbitMQ는 유연한 라우팅을 지원하고, 메시지 우선순위를 지정할 수 있다는 장정을 가지고 있습니다. 그리고 카프카에 비해 프로그램이 가볍기도 해서, 어플리케이션의 Consumer가 고정되어 있고 대용량의 메세지 처리가 목적이 아니라면 RabbitMQ를 사용하는 것이 좋을 수 있습니다.

 

 


참고 - https://www.cloudamqp.com/blog/when-to-use-rabbitmq-or-apache-kafka.html

728x90