해당 프로젝트에서 채팅 구현을 맡고 있었다. 이전까지는 단지 STOMP프로토콜을 사용해 직접 client에게 메세지르 바로 보내는 것을 구현하였다. 하지만 해당 과정은 synchronize하기 때문에 다량의 트래픽이 몰린다면 문제가 발생될 수 있었다. 이것을 해결하기 위해서 pub/sub 구조인 Message queue를 도입하고자한다. Message queue의 후보지는 2가지가 있다. 1. Kafka 2. Redis 이 두개의 차이점을 비교하고 현재 나의 프로젝트에 맞는 Message Queue를 선택하고자 한다. 또한 DB도 문제이다. 현재는 MYSQL에다 채팅 데이터를 저장하고 있다. 항상 고민됐던게 MYSQL에 트랜잭션도 자주 발생하고 성능도 고려가 된다... 만약 채팅을 위한 DB를 구성하고 ..

SpringBoot에서 Kafka - Producer https://devbksheen.tistory.com/entry/Kafka-Spring-Boot%EC%97%90-Kafka%EB%A5%BC-%EC%97%B0%EB%8F%99?category=1024738 Spring Boot에 Kafka 연동 [Kafka] Local에서 Kafka 명령어 날리기 [Kafka] EC2 생성 후 접속, Kafka 설치 및 설정 AWS EC2 생성 후 Inbound rule 추가 1. AWS Console 로그인 후 EC2에 접속 2. EC2 인스턴스 생성 3. 키 페어 생성 4. Inbou.. devbksheen.tistory.com springboot와 kafka 연동은 다음을 참고하였음 public static St..

브로커? 클러스터? 주키퍼? 브로커 브로커는카프카 클라이언트와 데이터를 주고 받기 위해 사용하는 주체입니다. 1대의 서버에는 하나의 브로커가 올라옵니다. 클러스터 클러스터는 다음사진과 같이 broker의 집합이라고 할 수 있습니다. 즉 cluster는 kafka의 broker를 관리하는 역할을 합니다.그러면 클러스터에는 여러개의 브로커가 존재하는데, 이렇게 많은 브로커를 운영하는 이유는 무엇일까요?바로 데이터를 안전하게 보관하기 위해서입니다. 예를들어 사진과 같이 Broker1, Broker2, Broker3은 같은 데이터를 가집니다. 즉 하나가 리더가 되어 나머지 Broker들을 복제합니다.해당 설명은 Kafka의 전체적인 구조를 설명하고 복제에 대해 자세하게 설명하겠습니다. 주키퍼 주키퍼는 Kafka..

KafKa가 생겨난 이유 초기 어플리케이션은 간단한 구조로 이루어져있었습니다. 하지만 급속도로 발전을 하면서 요즘 많이 들리는 MSA 아키텍쳐라고 한번쯤 들어보셨을 겁니다. 여러개의 어플리케이션이 서로 상호작용을 하며 구조가 점점 복잡해졌습니다. 다음 사진과 같이 말이죠. 이후 링크드인에서 카프카라는것을 만들어냅니다. 즉 데이터 흐름(flow)를 한곳에 모아 중앙관리 형태의 구조를 만들어냈습니다. 사진만 봐도 dataflow관점에서 확연한 차이가 나는것을 확인할 수 있습니다. MQ-메세지 큐 MQ는 들어본사람도 있고 들어보지 못한 사람도 있을겁니다. Message-Queue라고 하는데, 자료구조에서 Queue형태는 다들 아실거라고 생각합니다. FIFO(First-In-First-Out)이죠 kafka도 ..