메시징 시스템 Kafka

메시징 시스템의 이해

  • MSA에서 데이터 송수신 방법으로 메시징 시스템을 사용
  • MSA에서는 시스템 간의 호출이 많기 때문에 서비스간 결합도를 낮추기 위해 비동기요청, 성능, 안정성 등 여러 이점이 있음

MOM(Message Oriented Middleware, 메시지 지향 미들웨어)

  • 독립된 애플리케이션 간에 데이터를 주고받을 수 있도록 하는 시스템 디자인
    • 함수호출, 공유메모리 등의 방식이 아닌, 메시지 교환을 이용하는 중간 계층에 대한 인프라 아키텍쳐 개념
    • 분산 컴퓨팅이 가능해지며, 서비스간의 결합성이 낮아짐
  • 비동기로 메시지를 전달하는 것이 특징
  • Queue, Broadcast, Multicast 등의 방식으로 메시지 전달
  • Pub/Sub 구조
    • 메시지를 발행하는 Publisher(Producer), 메시지를 소비하는 Subscribe(Consumer)로 구성

Message Broker

  • 메시지 처리 또는 메시지 수신자에게 메시지를 전달하는 시스템, 일반적으로 MOM을 기반으로 구축됨

MQ(Message Queue, 메시지 큐)

  • Message Broker와 MOM을 구현한 소프트웨어(RabbitMQ, ActiveMQ, Kafka 등)
  • MOM은 메시지 전송 보장을 해야하므로 AMQP를 구현함

AMQP(Advanced Message Queueing Protocol)

  • 메시지를 안정적으로 주고받기 위한 인터넷 프로토콜

RabbitMQ, Kafka 등은 AMQP를 구현한 MOM 시스템

메시징 시스템이란

  • 로그데이터, 이벤트 메시지 등 API로 호출할 때 보내는 데이터들을 처리하는 시스템

  • 회원가입을 했을 때, 이메일 발송하는 MemberService
  • 주문완료 되었을 때, 이메일 발송하는 OrderService
  • 메일을 실제 발송하는 MailService
  1. MemberService에서 회원가입, OrderService에서 주문완료 이벤트 발생
  2. Messagin Client로 메일 전송에 필요한 데이터(수신/송신 메일주소, 제목, 내용 등)를 API호출
  3. Messaging Client에서 MOM을 구현한 소프트웨어(Kafka)로 메시지 생산
  4. MailService에서 메시지가 존재하는지 구독하고 있다가 메시지가 존재하면 메시지 소비
  5. MailService에서 API정보들을 통해 User에게 메일 발송

메시징 시스템 장점

  • 서비스간의 결합성이 낮아지므로 각자의 비즈니스 로직에만 집중
  • 메시지 처리 방식은 Message Broker에 위임(각 서비스는 Client를 통해 메시지를 보내고 받기만 하면 됨)
  • 각 서비스는 비동기 방식으로 메시지를 보내기만 하면, Message Broker에서 순서보장, 메시지 전송 보장등을 처리
  • 메시징 시스템이 잠깐 다운되어도 각 서비스에는 직접적인 영향을 미치지 않음

메시징 시스템 단점

  • Message Broker 구축(Kafka 클러스터 구축에 필요한 금전, 인적 자원의 비용)
  • 함수호출, 공유메모리 사용방식보다 메시징 시스템을 사용했을 때 호출구간이 늘어나므로 네트워크 비용 발생

Kafka 아키텍쳐

Zookeeper(Apache Zookeeper)

  • 본래 Zookeeper의 용도는 클러스터 최신 설정정보 관리, 동기화, 리더 채택 등 클러스터의 서버들이 공유하는 데이터를 관리하기 위해 사용됨(Broker에 분산 처리된 큐의 정보들을 관리)
  • 클리스터를 관리하는 Zookeeper 없이는 Kafka 구동 불가능

Broker

  • Kafka Server를 의미
  • 한 클러스터 내에서 Kafka Server를 여러 대 띄울 수 있음

TOPIC

  • Kafka에서 데이터에 대한 논리적인 이름
  • 메시지가 생산되고 소비되는 주제 ex)email topic, sms topic …
  • Kafka를 통해 유통되는 모든 데이터는 Topic이라는 데이터 유형으로 만들어지며 Producer/Consumer들은 자신이 생성 혹은 소비할 Topic의 이름을 알고 있어야함

Partition

  • Topic을 물리적으로 몇개의 분할된 Queue 형태로 나눠 관리할지를 지정
  • 특정 Topic이 1개의 Partition으로 되어 있다는 것은 데이터 처리를 위한 Queue가 한개 존재한다는 것, 3개의 Partition으로 구성되어 있다면 3개의 Queue가 존재, 각각의 Queue에는 독립적으로 데이터가 들어갈 수 있음
  • 이론적으로 Partition의 개수가 많을수록 동시에 클러스터에 데이터를 더 빠르게 받아들일 수 있음을 의미함
  • 클러스터를 구성하는 서버, CPU, Memory 등 자원의 제약을 고려해 최적의 Partition 정책을 세우는게 필요함

Log

  • Partition의 한 칸
  • key, value, timestamp로 구성

Offset

  • Partition의 각 메시지를 식별할 수 있는 유니크 값
  • 메시지를 소비하는 Consumer가 읽을 차례를 의미하므로 Partition마다 별도로 관리
  • 0부터 시작하여 1씩 증가

Categories:

Updated:

Comments