MOM(Message Oriented Middleware) : 메시지 지향 미들웨어1.1 다른 미들웨어 종류: RPC 방식, ORB 방식1.2 미들웨어: 어플리케이션들을 연결시켜, 서로 데이터를 교환할 수 있게 해주는 소프트웨어1.3 메시지 지향: 메시지 전달을 통해 데이터를 교환할 수 있게 만들어주는 시스템.
Message Broker2.1 MOM 기반으로 메시지 전송을 담당하는 시스템.2.2 Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할 → 응용 소프트웨어 간에 메시지 교환 담당2.3 이때, 메시지가 적재되는 공간: Message Queue.2.4 오픈소스 종류 : RabbitMQ,Apache Kafka, ActiveMQ, ... 2.5 장점비동기(Asynchronous) : Queue에 넣기 때문에 후처리 가능비동조(Decoupling) : 애플리케이션과 분리 가능탄력성(Resilience) : 일부가 실패해도, 전체에 영향 미비과잉(Redundancy) : 실패 할 경우 재실행 가능보증(Guarantees) : 작업완료 확인 가능확장성(Scalable) : 다수의 프로세스들이 큐에 메시지를 보낼 수 있음
탄생 배경 이해
카프카란?!
메시징 시스템
대용량, 대규모 메시지 데이터를 빠르게 처리할 수 있는 메시징 시스템링크드인에서 시작했으나 → 현재는 아파치 공식 오픈소스
링크드인은 왜 카프카를 만들었을까?
기존 ene-to-end 연결 방식 아키텍처의 많은 문제점 해결을 위해서
통합/ 중앙화된 전송 영역이 없음 → end-to-end 연결이 갈수록 복잡해짐
문제 발생 시 관련 여러 시스템을 확인해야 함 → 문제 해결이 어려워짐하드웨어 증설 같은 작업이 어려움
데이터 파이프라인 관리의 어려움
연결된 시스템 마다 제각기 다른 방식으로 구현될 수 있음 → 파이프라인 통합(확장)이 어려움
이런 문제를 해결하기 위해
모든 시스템으로 데이터를 전송할 수 있고
실시간 처리 가능하고
급속도로 성장하는 서비스를 위해 확장이 용이한
시스템(카프카)을 만들자
카프카 개발팀의 목표
카프카의 동작 방식과 원리
카프카는 pub/sub 모델을 기반으로 만들어진 메세징 시스템
메시징 시스템이란?!"로그 데이터, 이벤트 메시지 등 API 로 호출할 때 보내는 데이터들을 처리하는 시스템"
pub/sub 모델이란?중앙에 메시징 시스템 서버를 두고, 메시지를 보내고(publish), 받는(subscribe) 형태의 통신구독을 신청한 수신자만 메세지를 전달받을 수 있음장점(기존 네트워크 통신 방식의 단점 극복)개체가 빠지거나 수신 불능이 되도, 메시징 시스템만 살아있으면 전달한 메시지가 유실 xN:M으로 연결되는 것이 아니기 때문에 확장성이 용이
데이터 단위: 메시지(로그 데이터, 이벤트 메시지 등등)
데이터 보내는 측 : Publisher, Producer
데이터 가져가는 측: Subscriber, Consumer
주제별 데이터 저장소: 토픽
전체 돌아가는 방식을 간단히 정리하면
포르듀서가 새로운 메시지를 카프카로 보냄
프로듀서가 보낸 메시지는 카프카에 컨슈머 큐(카프카 기준 토픽-식별자-)에 도착해 저장됨
컨슈머는 카프카 서버에 접속해 새로운 메시지 가져감
추가 용어 정리
카프카 : 아파치 프로젝트 애플리케이션 이름. 클러스터 구성이 가능하며 카프카 클러스터라고 부름
브로커 : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드
토픽 : 메시지 그룹. 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 이름으로 사용함. 많은 수의 프로듀서, 컨슈머들이 동일한 카프카를 이용하게 된다면 메시지들이 서로 뒤섞여 각자 원하는 메시지를 얻기가 어려워짐. 그래서 토픽이라는 이름으로 구분해서 사용
파티션 : 병렬처리가 가능하도록 토픽을 나눌수 있고 많은 양의 메시지를 처리하기 위해 파티션의 수를 늘릴수 있다.
프로듀서 : 메시지를 생산하여 브로커의 토픽 이름으로 보내는 서버 또는 애플리케이션을 말함
컨슈머 : 브로커의 토픽 이름으로 저장된 메시지를 가져가는 서버 또는 애플리케이션을 말함
pub/sub 모델의 장/단점
장점
기존 네트워크 통신 방식의 단점 극복
개체가 빠지거나 수신 불능이 되도, 메시징 시스템만 살아있으면 전달한 메시지가 유실 x
N:M으로 연결되는 것이 아니기 때문에 확장성이 용이
단점
직접 통신하는 것이 아니기 때문에 메시지가 정확하게 전달되었는지 확인하려면 코드가 복잡해짐
메시징 시스템이 있기 때문에 메시지 전달속도가 느림
만약, 메시징 시스템 서버 없이(pub/sub 모델 없이) 직접 연결해서 통신하면?
장점: 속도 빠름
단점: 송,수신자 상태에 따라 장애 처리를 해줘야 함참여하는 개체가 많아질수록 각 개체를 연결해줘야 함 → 확장성 불리
카프카는 기존 메시징 시스템의 한계를 어떻게 극복했을까?
기존 메시징 시스템
목적: 간단한 이벤트(n KB 정도의 크기) 전송
특징
메시지 보관, 전달 과정에서 속도, 용량보다 신뢰성 보장을 중요하게 여김
많은 양의 데이터 관리 못함(이유: 메시징 시스템 내부의 교환기의 부하, 컨슈머 큐 관리를 직접함, 메시지의 정합성, 전달결과 관리등을 위하여 프로세스가 복잡하고 다양했기 때문에)=> 데이터를 모으고, 전달함에 있어서 성능 이슈 발생
극복 방법
메시지 교환 전달의 신뢰성 관리를 프로듀서, 컨슈머 쪽으로 넘김
부하가 많이 걸리는 교환기 기능을 컨슈머가 만들 수 있게 함> 메시징 시스템 내의 작업량 줄어듦> 절약한 작업량을 메시징 전달 성능에 집중시킴=> 고성능 메시징 시스템 만듦
카프카의 특징
프로듀서와 컨슈머의 분리
pub / sub 방식을 통해 메시지를 보내는 역할과 받는 역할이 완벽하게 분리됨=> 다른 시스템, 서비스 서버의 상태와 상관없이 그저 메시지 시스템과 메시지 기반 송/수신 하면 됨.
멀티 프로듀서, 멀티 컨슈머
하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능한 구조 => 이를 통해 카프카는 중앙 집중형 구조로 구성할 수 있음
프로듀서는 1개 이상의 토픽으로 메시지 전송 가능
컨슈머는 1개 이상의 토픽에서 메시지 가져올 수 있음
멀티 기능이 필요한 이유: 데이터 분석 및 처리 프로세스에서 하나의 데이터를 다양한 용도로 사용하는 요구가 많아졌기 때문
디스크에 메시지 저장
(기존 메시징 시스템 - RabbitMQ, ActiveMQ): 컨슈머가 메시지 읽어가면 큐에서 바로 삭제
(카프카): 보관 주기 동안 디스크에 메시지 저장 -> 트래픽이 폭주해 컨슈머의 처리가 늦어져도 카프카 디스크에 안전하게 보관 됨 -> 메시지 손실x페이지 캐시?!OS에서 사용하는 페이지 캐시와 동일함→ 한 번 읽은 파일의 내용을 페이지 캐시라는 영역에 저장시킴. 파일의 논리적인 내용을 페이지 단위로 캐시하기 위해 사용되며, 파일과 파일 내의 오프셋을 통해 접근. 디스크에서 메모리로 페이지들을 읽어 들이면, 페이지들은 페이지 캐시에 캐싱메모리(RAM) 영역에 어플리케이션이 사용하는 부분을 할당하고 남은 잔여 메모리를 캐시로 전환 → 디스크 접근을 최소화시켜 I/O 성능을 향상시키는 메모리 영역카프카는 페이지 캐시를 적극적으로 사용함 → 페이지 캐시를 사용하기 위해서 잔여 메모리를 쓰기 때문에, 카프카 서버에 다른 어플리케이션을 함께 실행하는 것을 권장하지 않음.
디스크 I/O 는 느리지 않을까?답: 아니다! 카프카는 페이지 캐시를 이용해서 디스크 접근을 최소화 시켜, 처리 속도가 빠름
확장성: 시스템 확장이 용이하다
분산 시스템을 기반으로 설계 → 분산 시스템 구성 및 복제에 대한 설정을 쉽게 할 수 있음
수십 대의 브로커로 간단하게 확장 가능(1개의 카프카 클러스터는 초기 3대로 시작함)
확장 시 서비스의 중단 없이 온라인 상태에서 작업 가능
높은 성능
분산 처리 가능 -> 하나의 서버/노드에서 장애 발생하면 다른 서버/노드가 대신 처리 가능
배치 처리 가능
예상 문제 상황: 서버와 클라이언트간에 데이터를 주고 받는 경우라면 I/O가 발생 → 네트워크 I/O, 디스크 I/O가 자주 일어나 서버의 속도를 저하
해결 방법 : 크기가 작은 I/O를 그룹핑해서 처리할 수 있도록 배치작업을 통한 처리
TCP 기반의 프로토콜을 사용해 오버헤드 감소
AMQP 프로토콜을 사용하지 않음=> 기존의 메시징 시스템과 달리 프로토콜로 인한 오버헤드는 없도록 설계
