메시지 브로커 중에 Kafka를 도입한 이유

메시지 브로커란?메시지 브로커는 애플리케이션 간 서로 통신할 때 정보를 주고받을 수 있도록 도와주는 소프트웨어이다.우체국처럼 메시지를 보내는 쪽인 **생산자(Producer)**와 메시지를 받는 쪽인 소비자(Comsumer) 사이에서 메시지를 전달하는 역할을 수행한다.그렇기 때문에 MSA(Micro Service Architecture) 또는 분산 시스템에서 서비스 간 통신에 주로 사용되는 경우가 많고, 시스템 로그 처리, 비동기 메시지 큐 등 다양한 곳에서 활용된다.왜 메시지 브로커가 필요한가?메시지 브로커가 필요한 이유는 다음과 같다.편지를 받는 사람(Consumer)는 편지를 쓰는 사람(Producer)이 편지를 다 쓸때까지(=메시지를 생산할때까지), 멍 때리며 가만히 있지 않는다. 무언가 일을 하..

Cursor기반 페이지네이션으로 성능 개선하기

현재 [강아지 모아보기]페이지에서 5가지 속성(브리더의 인증여부, 견종, 분양가능상태, 성별, 크기)을 기반으로 다중검색이 가능한 상황이다.기존 코드는 아래와 같다.@Transactional(readOnly = true)public ResponseEntity getDogs(Pageable pageable, Long dogTypeId, String verification, Boolean isAvailable, Gender gender, Size size) { Specification spec = Specification .where(DogSpecification.isVerified(verification)) ..

SNS프로젝트를 하다가, 특정 인기 게시물에 대한 좋아요 개수가 multi-thread환경에서 올바르게 증가되지 않는 현상을 발견하였다.인기 게시물의 경우, 수십명이 좋아요를 누르게 될 것이다. 여러 Thread가 좋아요 컬럼에 update를 하다가 여러 경합이 발생했을 것이라고 판단하였다.이 문제를 해결하고자 비관적락을 도입하여 좋아요 개수가 올바르게 증가하도록 하였다.이번 글에서는 비관적 락과 낙관적 락의 차이에 대해 설명하고, 왜 비관적 락을 도입했는지 설명하고자 한다.DB 충돌 상황을 개선할 수 있는 방법DB에 접근해서 데이터를 수정할 때, 위 SNS프로젝트처럼, 동시에 수정이 일어나 충돌이 일어날 수 있다.이를 해결할 수 있는 방법으로 크게 2가지를 제시한다.첫번째, 테이블의 Row에 접근시, ..

Cache 캐시는 나중에 요청할 결과를 미리 저장해 둔 후 빠르게 서비스해주는 것을 의미한다. 즉, 결과를 미리 저장하고 나중에 요청이 오면, 이 요청에 대해서 DB를 참조하지 않고 캐시에 접근하여 요청을 처리하는 기법이다. 그렇다면 어떤 데이터를 캐싱해야할까? 자주 조회되면서 쓰기가 거의 일어나지 않는 데이터에 대해서 캐싱해야한다. 캐싱을 할때 로컬캐싱 vs 글로벌 캐싱 캐싱할 데이터를 선정했다면, 이 데이터를 "어디"에 저장할지 고민해야한다. 일반적으로 로컬메모리에 저장하거나, Redis와 같은 별도 서버에 저장할 수 있다. 로컬캐싱 애플리케이션 서버의 메모리에 캐싱할 데이터를 저장하는 방법이며 일반적으로 Guava cache나 Caffeine cache를 많이 사용한다. 장점 애플리케이션 로직을 수..

Offset pagination SELECT * FROM items WHERE 조건문 ORDER BY id DESC OFFSET 페이지번호 LIMIT 페이지사이즈 offset(몇번째부터 가져올 것인가?)과 limit(몇개를 가져올 것인가?)예약어를 통하여 select전체 결과 중 일부만 가져오는 방법이다. 단점 페이지 요청 시, 데이터 변화가 있는 경우 중복 데이터 발생 예를 들어, 1페이지에서 20개의 row를 불러와서 유저에게 1페이지를 띄워주었다. 고객이 1페이지의 상품을 보고 있는 사이, 상품 운영팀에서 5개의 상품을 새로 올렸다면? 유저가 1페이지 상품을 다 둘러보고 2페이지를 눌렀을 때, 1페이지에서 보았던 상품 20개중 마지막 5개를 다시 2페이지에서 보게 된다. 대부분이 RDBMS에서 OF..

pull mode, push model 타임라인을 구현하는 방법에는 총2가지가 있다. 이때, 타임라인은, 인스타그램, 페이스북, 트위터와 같은 sns의 메인 피드를 의미한다. fanout : 사용자가 게시물을 작성하였을 때, 이 글을 봐야하는 모든 사람들(인스타그램의 팔로워, 페이스북 친구 등)에게 전달하는 과정 push model(fanout-on-write) : 쓰기 시점에 fanout하는 것을 의미한다. 즉, 사용자 1명이 게시글을 적을 때마다, 자신의 팔로워 모두에게 해당 글을 전파한다. pull model(fanout-on-read) : 읽기 시점에 fanout하는 것을 의미한다. 게시글을 적을 때는 별 동작이 없다가, 팔로워 1명이 새로고침하는 시점에 그 사람의 피드만 갱신한다. 따라서 on-..