# MQ
메시지 큐(Message Queue, MQ)
메시지 큐(Message Queue, MQ)란? 프로그램(프로세스) 간의 데이터를 교환할 때 사용하는 기술이다. 메시지 큐는 메시지 지향 미들웨어(Message Oriented Middleware, MOM)를 구현한 시스템이다. 1만 개의 요청이 발생했을 때 모든 요청을 서버로 보내는 것이 아니라 메시지 큐에 보낸다. 서버 측에서는 처리하는데 이상 없을 정도의 요청들만 메시지 큐에서 가져와서 처리한다면 서버의 부담을 줄일 수 있다. > 👀메시지 지향 미들웨어(Message Oriented Middleware, MOM) 메시지 지향 미들웨어는 응용 소프트웨어 간의 데이터 통신을 위한 소프트웨어이다. 일반적
Message Queue (MQ)
Message Queue Message Queue는 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중 하나로, 메시지 지향 미들웨어 (Message Oriented Middleware: MOM) 를 구현한 시스템을 의미한다. > 메시지 지향 미들웨어란? 비동기 메시지를 사용하는 응용 프로그램들 사이에서 데이터를 송수신하는 것을 의미한다. 여기서 메시지는 요청, 응답, 오류 메시지나 단순한 정보 등의 작은 데이터가 될 수 있다. 메시지 큐는 메시지를 임시로 저장하는 간단한 버퍼라고 생각하면 되고, 메시지를 전송 및 수신하기 위해 중간에 메시지 큐를 둔다. 메시지 전송 시 생산자(Producer) 로 취급되는 컴포넌트가 메시지를 메시지 큐에 추가한다. 해당 메시지는 소비자(Consumer) 로 취급되는 또 다른 컴포넌트가 메시지를 검색하고 이를 사용
엉금엉금 Kafka 도입기
서론 Kafka가 필요한 이유 MSA(MicroService Architecture)는 도메인 서비스간 분리가 되어 있어서 각 서비스간에 통신이 불가능하다. 하지만, 각 도메인 서비스를 나눴다고 해도 서비스간에 통신이 필요할수도 있다. ex) 주문 서비스에서 주문을 처리 했을 경우 재고 서비스에서 해당 재고를 차감시켜야하는 경우가 있다. → 사실 이 경우엔 도메인을 어떻게 나누냐의 차이이다. 위와같은 경우에서 주문 서비스만으로 다 처리가 불가능 하므로 서비스간 통신을 위한 무언가가 필요하다. MSA에서 서비스간 통신을 위해 지원하는 몇가지 방법이 있습니다. RESTful API (FeignClient) Message queue MSA 통신을 위한 큰틀 고르기 RESTful API (FeignClient) 동기 처리 방식으로 HTTP Endpoint에 대한 Interface를 생성하고 @
Kafka Consumer 간단 정리
토픽 파티션은 그룹 단위로 할당 컨슈머 그룹 단위로 파티션을 할당한다. 파티션 그룹보다 컨슈머 그룹이 많아지면 유휴상태의 컨슈머가 많아지게 된다. 컨슈머 그룹이 파티션 그룹보다 많아지면 안된다. 만약 처리량이 떨어져 파티션을 늘려야 한다면 컨슈머 또한 늘려야 한다. 커밋과 오프셋 컨슈머는 커밋 과정을 반복한다. 카프카 브로커로부터 데이터를 어디까지 가져갔는지 커밋을 통해 기록하는 것이다. 비명시적 오프셋 커밋 오프셋 커밋은 컨슈머 애플리케이션에서 명시적, 비명시적으로 수행할 수 있다.
Kafka Producer 간단 정리
프로듀서의 기본 흐름과 Sender의 기본 동작 처리량 관련 속성 batch.size: 배치 크기. 배치가 다 차면 바로 전송 linger.ms: 전송 대기 시간. (기본값 0) 대기 시간이 없으면 배치가 덜 차도 브로커로 바로 전송 대기 시간을 주면 그 시간 만큼 배치에 메시지 추가가 가능해서 한 번의 전송 요청에 더 많은 데이터 처리 가능 전송 결과 확인 안함 producer.send(new ProducerRecode("simple", "value")); 전송 실패를 알 수 없음 실패에 대한 별도 처리가 필요없는 메시지 전송에 사용 전송 결과 확인 함: Future 배치 효과 떨어짐 → 처리량 저하 건 별로 확실하게 전
Kafka 기본 구조와 용어 정리
기본 구조 카프카 브로커 카프카 브로커는 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자, 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션이다. 데이터를 안전하게 보관하고 처리하기 위해 3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영한다. 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게 분산 저장하고 복제하는 역할을 수행한다. 프로듀서 카프카에서 데이터의 시작점은 프로듀서이다. 카프카에 필요한 데이터를 선언하고 브로커의 특정 토픽의 파티션에 전송한다. 프로듀서는 데이터를 전송할 때 리더 파티션을 가지고 있는 카프카 브로커와 직접 통신한다. 데이터를 직렬화하여 카프카 브로커로 보내기 때문에 J
[Kubernetes] Rabbitmq Cluster 구축 (삽질기)
Kubernetes와 RabbitMQ Operator 활용하여 RabbiMQ 클러스터링 구축 RabbitMQ 클러스터를 구축하기 위해 Kubernetes와 RabbitMQ Operator를 활용하여 RabbitMQ 클러스터를 구축을 시도해보자 RabbitMQ는 대규모 메시지 처리에 적합한 오픈 소스 메시지 브로커이며 RabbitMQ Operator는 Kubernetes 상에서 RabbitMQ 클러스터를 관리하기 위한 컨트롤러로, 효율적인 클러스터 구성과 관리를 지원해준다. 처음엔 Helm을 통해 시도했으나, Connection refused 에러가 발생하여 pod 실행되지않았다. 그래서 오퍼레이터를 사용했고, 이 글도 오퍼레이터를 이용한 구축기록이다. 나중에 찾아보니 bind_ip가 로컬호스트로만 설정되어 발생한 것인데 이를 발견하기까지 오래걸렸다. 서론은 길다 일단 들어가보자, [RabbitMQ official Docs](
메세지 큐(Message Queue)
메세지 큐(Message Queue)란? 프로세스(프로그램) 간에 데이터를 교환할 때 사용하는 통신 방법 중에 하나로 더 큰 개념으로는 MOM(Message Oriented Middleware : 메시지 지향 미들웨어 이하 MOM)을 의미 MOM이란 비동기 메시지를 사용하는 프로그램 간의 데이터 송수신을 의미하는데 MOM을 구현한 시스템을 MQ라고 한다. MQ는 작업을 늦출 수 있는 유연성을 제공한다. 메시지를 교환할 때 AMQP(Advanced Message Queuing Protocol 이하 AMQP)를 이용한다. AMQP는 ISO응용 계층의 MOM 표준으로 JMS(Java Message Service)와 비교되는데 JMS는 MOM을 자바에서 지원하는 표준 API다. JMS는 다른 Java Application 간에 통신은 가능하지만 다른 MOM(AMQP, SMTP 등)끼리는 통신할 수 없다. 그에 반해 AM
카프카(kafka)란? (기본구조, 토픽, 파티션)
카프카(kafka)는 메세지큐의 대표적인 솔루션 중 하나이다. 링크드인에서 개발했으며 현재는 오픈소스로 공개되어있어 데이터 파이프라인 구축을 위해 많은 사람들이 사용하고 있다. 카프카 기본 구조 카프카는 크게 브로커, 컨슈머, 프로듀서 세가지 컴포넌트로 구성된다. 프로듀서: 카프카 브로커에 데이터(메세지)를 전송하는 어플리케이션 브로커: 브로커는 카프카가 설치되어 있는 서버이며 프로듀서로부터 받은 데이터를 관리한다. 보통 고가용성을 위해 클러스터로 구성된다. 컨슈머: 브로커에 저장된 메세지를 읽어와 사용하는 어플리케이션 카프카 토픽 & 파티션 토픽은 카프카 클러스터에 데이터를 저장할 떄 데이터를 구분하기 위한 기준이다. 프로듀서가 특정 토픽을 지정
MQ(Message Queue) 를 사용하는 이유
MQ는 어떤 장점이 있고 왜 사용하는 것일까? Case 1. 한가지 시나리오를 생각해보자. 시스템 A 는 시스템 B,C,D 에게 동일한 데이터를 전송중이다. 만약 시스템 E도 이 데이터를 원한다면 어떻게 될까? 만약 시스템 C가 이 데이터를 더이상 원하지 않는다면 어떻게 될까? A는 B,C,D 와 강하게 커플링되어 있다. 만약 데이터 전송이 실패한다면? 재전송을 해야한다면? 시스템 A 는 B,C,D 를 모두 고려해야한다. 여기에 MQ를 사용해보자 A는 MQ 에 데이터를 전송한다. 이 데이터를 필요로한는 시스템은 MQ 에서 데이터를 컨슘한다. 새로운 시스템이 이 데이터가 필요하다면 MQ 에서 컨슘할 수 있고 더 이상 데이터가 필요없는 시스템은 컨슘을 중단하면 된다. 
Message Queue
📌개념 대용량의 데이터를 처리하기 위해 분산 처리할때 쓰는 것 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중에 하나 메시지를 전송 및 수신하기 위해 중간에 메시지 큐을 두는 버퍼 느낌 수신 서비스가 사용 중이거나 연결이 끊어졌을 때 임시 메시지 저장소를 제공 시스템이 처리할 일을 차례대로 넣어놓고 시스템이 하나씩 작업을 가져가 처리하도 다음 작업을 또 가져올 수 있는 Store-and-Forward 방식의 시스템 messageQue 그림 출처) [https://www.cloudamqp.com/blog/what-is-message-queuing.html](https://www.cloudamqp.com/blog/w
Spring boot - RebbitMq 적용기
관리자 채팅 페이지 제작을 위해 채팅서버를 알아보다.. 20년도에 적용하려다 실패한 rebbitMq를 해보려고 한다. 그때는 WebFlux로 하려고 했지만 지금은 javaSpring이니... 자료도 많고 하기도 쉬어보인당. 도커가 정상적으로 실행되면 localhost:8080으로 접속시 아래와 같은 화면을 볼 수 있다. 여기에 해당코드를 복붙해서 실행했다면 Username:test Password:test 로 입력시 로그인이 가능하다. 상단부분에서 Exchanges 를 클릭해준뒤 
메세지 지향 미들웨어(MOM)
메세지 지향 미들웨어(Message Oriented Middleware > MOM) 미들웨어란 애플리케이션들을 연결해 이들이 서로 데이터를 교환할 수 있게 해주는 소프트웨어 메세지 지향 시스템이란 메세지 API를 통해 각 분산되어있는 애플리케이션간의 다리역할을 함으로써 데이터를 교환할 수 있도록 하는 시스템 메세지를 통해 여러 분산되어 있는 시스템간의 Connector 역할로 결합성을 낮추고, 이들이 서로 실시간 비동기식 데이터를 교환할 수 있도록 하는 소프트웨어 즉, 분산 시스템 간 메시지를 주고 받는 기능을 지원하는 소프트웨어나 하드웨어 인프라 MOM 특징 비동기 방식으로 메세지를 전달한다. Queue, Broadcast, Multicast 등의 방식으로 메세지를 전달
MQ 비교 (Kafka, RabbitMQ, Redis)
RabbitMQ 개념 AMQP를 따르는 오픈소스 메세지 > 💡 AMQP(Advanced Message Queuing Protocol): 메세지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜 구성 요소 producer: 메세지를 보냄 exchange: 메세지를 목적지(큐)에 맞게 전달 queue: 메세지를 쌓아둠 consumer: 메세지를 받음 rabbitMQ 메세지 처리 과정 Producer가 메세지를 보내면 exchange에서 해당하는 키에 맞게 큐에 분배(바인딩 or 라우팅) topic 모드: Routing Key가 정확히 일치하는 Queue에 메세지 전
22.6.13 Message Queue
🤔 메시지? 인풋을 통해 들어오는 프로세스에 대한 다양한 요청, 이벤트 등을 메시지라고 한다. 메시지 큐 메시지 큐(Message Queue)는 프로세스 또는 프로그램 인스턴스가 데이터를 서로 교환할 때 사용하는 통신 방법이다. 브로커라고 불리기도 한다. 모니터링, 로그, 이벤트 메시지 등 아주 거대한 양의 데이터를 다룰 일이 생김에 따라 활용한다. Queue는 여러 컴포넌트들이 데이터를 생성, 저장, 사용하는 과정에서 일종의 버퍼 역할을 한다. 이로 인해 프로듀서와 컨슈머 간의 속도가 다를 때, 둘 중 어느 한 컴포넌트에 장애가 발생했을 때 대응이 가능해 장애의 전파를 막을 수 있다. 장점 비동기(Asynchronous): 큐에 넣어두기 때문에 문제가 생겨도 나중에 처리할 수 있다. 분리 또는 비동조(Decoupling): 애플리케이션과 분리할 수 있다. 탄력성(Resilience): 일부가 실패 시 전체에 영향을 받지 않는다.
RabbitMQ Quickstart
2020년에 작성한 노트를 옮긴 것입니다. 로컬 설치 Web Managemetn Plugin 설정 개념 Virtual host Apache의 Virtual host와 같다. 하나의 서버가 여러개의 도메인을 가지고 있고, 각 도메인마다 다른 서비스를 하고 싶을 때 서버 IP가 123.123.123.123일때, a.com으로 접속하면 A 서비스로, b.com으로 접속하면 B 서비스로 접속됨. 포트기반으로도 가능 (마치 포트포워딩처럼) 하나의 RabbitMQ안에서 사용중인 application 분리 User마다 다른 환경을 사용하도록 설정할 수 있다 (one user to many vhosts) 유저 생성 후, virtual host 만들고, 클릭하여 접근 가능한 유저를 추가한다. 
Message Queue 개념 정리
2020에 작성한 노트를 옮겨 적은 것입니다. Protocols AMQP - Advanced Message Queuing Protocol Reliability and interoperability 굉장히 feature-rich하다 reliable queuing, topic-based pub/sub messaging, flexible routing, security queue에 대한 access control이나 depth 설정 가능 MQTT - Message Queue Telemetry Transport Pub/sub without queue 굉장히 가볍다. 단순함이 장점. Resource-constrained devices나 bandwidth 낮은 경우 사용 -> IoT 다음 messaging만 보장 fire-and-forget at least once exactly once STOMP
메시지 큐와 프로토콜
💡 메시지 큐(MQ)에 대해 학습하고 정리한 글입니다. Queue는 이전부터 익히 들었던 데이터 구조입니다. 큐는 2개의 끝을 가지고 있으며 각각은 머리와 꼬리의 역할을 합니다. 새로운 아이템은 꼬리로 입력되며 제거할 아이템은 머리에서 저게됩니다. 이런 구조를 FIFO(First In First Out)라고 모두 알고 계실 것입니다. 메시지 큐도 마찬가지로 Queue입니다. 큐가 메시지들로 채워져있으며 큐의 기본적인 원리를 그대로 따릅니다. 대신 머리와 꼬리와 연결된 Producer와 Consumer가 등장합니다. Proucer는 메시지 큐에 새로운 메시지를 추가하고 Consumer는 메시지 큐에서 메시지를 제거함으로 두 종단간에 데이터를 교환합니다. 비즈니스 적인 관점에서 보면 이 데이터 교환은 커머스에서 주문 유저의 회원가입 사용자의 서비스 요청이 될 수 있습니다. Producer는 Consumer에게