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

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