조회 성능 개선 지표우선 네트워크 속도 차이 및 제 개인 맥북으로 테스트를 하는 것이기 때문에 성능개선에 대해서 차이가 존재함을 말씀드립니다.🚀 성능 개선 상황데이터가 쌓여 수천, 수만건이 되는 경우 특정 필터들을 걸어 데이터를 조회하는 것은 굉장히 비효율적입니다. 결국은 Full-scan 을 통해서 데이터 목록을 조회하기 때문입니다.이는 실제 사용자 경험(UX)에 직접적인 영향을 끼치는 부분입니다. 따라서 이를 개선하며 테스트하고 최종적으로는 어떤 방식을 사용했는지 작성해보겠습니다.✅ 인덱스모임 목록을 조회할 때는 몇가지 필터를 적용할 수 있습니다. 사용하는 필터는 category_id, is_deleted, status, meetingDate, title등을 필터로 걸 수 있습니다. 위 작성한 상황..

문제 상황저는 현재 소모임과 비슷한 백엔드 서비스를 팀프로젝트로 진행중입니다. 그 과정에서 모임 삭제 로직 내부에서 발견한 오류입니다.문제 상황은 다음과 같습니다. 1. 모임 삭제 시 참가자 컬럼 또한 삭제가 필요2. 애그리거트 루트가 Meeting 이기 때문에 엔티티 클래스에 메서드를 생성해 삭제하는 로직 작성3. column 'meeting_id' cannot be null 에러 발생 문제 원인1 : N 단방향 관계에서 쉽게 일어날 수 있는 문제이며, 직접적으로 1:N 단방향을 설정하며 개발을 많이 안해왔기 때문에 파악하지 못했던 문제입니다.Jpa에서 위와 같이 JoinColumn을 통해서 연관관계를 1:N 을 정했을 때, Jpa는 관계를 우선적으로 정리하기 위해서UPDATE meeting_parti..

상황결제로직, 외부서버(Elasticsearch)와 데이터 전송을 할 때 만약 데이터 정합성이 크게 문제가 되는 부분은 어떻게 처리를 해야할까요? 만약 로직 과정에서 데이터가 유실되고 이벤트가 유실된다면 환불, 결제 로직은 누락되어 돈문제가 발생할 것이며, Es는 트랜잭션이 따로 존재하지 않기 때문에 데이터 변경 정보가 누락된다면 데이터 정합성이 깨지는 문제가 발생할 것입니다.이러한 문제를 해결하기 위해서 도입한 패턴이 아웃박스 패턴입니다. 아웃박스 패턴 아웃박스 패턴이란 이벤트를 발행할 때 데이터베이스에 저장하는 것과 이벤트 발행이 둘다 확실하게 성공하게 하는 패턴입니다. 시나리오를 통해 생각해보겠습니다. 모임 삭제를 호스트가 실행했다면 곧바로 모임 삭제를 하고 끝나는 것이 아닌, 내부 참가자에게 환불..

MQ를 학습하게 된 배경기존 팀프로젝트는 DDD 설계를 이용하여 타 컨텍스트로의 요청을 할 때 webClient 혹은 SpringEvent를 발행하는 방식으로 처리를 하고 있습니다. 그러나 저희 프로젝트가 DDD로 완전히 분리하게 되며 추후 MSA를 하게 된다면 MQ 사용은 필수적인 부분이 될 것이기에 사용해보며, 또한 결제 로직과 같은 보상로직 혹은 실패시 처리가 중요한 로직 같은 경우 이벤트 손실 시 처리할 수 있는 방법이 없습니다.따라서 재시도를 구현하거나 이벤트를 손실하는 것에 대응할 수 있는 방안을 찾자에서 시작되었습니다. 그래서 MQ란 무엇인가?MQ의 사전적의미는 Message Queue입니다. Producer가 메세지를 Publish하고 Consumer가 이를 처리할 수 있습니다. MQ를 왜..

상황현재 개발중인 팀프로젝트가 마무리되어가는 과정에서 로직을 다듬으며 작성했던 코드가 생각처럼 작동하지 않아서 찾느라 애먹은 부분을 작성해볼까 합니다.흐름은 다음과 같습니다1. 모임 삭제2. 결제로직은 유실시 문제상황이 크리티컬 할 수 있기 때문에 아웃박스 패턴적용.3. 모임 삭제 시 after commit으로 SpringEvent 발행 ( 모임 삭제 시 모임의 참가 인원에게 환불 로직을 타게 하기 위함 )4. RabbitMQ로 타 도메인으로 발행 ( 기존 MSA까지 구현하기 위해서 분리해놓은 상태 )5. 발행 이후 SpringEvent Listener 내부에서 아웃박스 패턴을 이용하여 성공적으로 발행됨을 저장.6. 결제 도메인에서 처리 . 제가 맡은 부분은 모임관련 로직이기 때문에 흐름은 위와 같습니다..

저번에 작성했던 글에서 Elasticsearch에 대해서 학습하였으며 이번엔 현재 진행중인 팀프로젝트에 적용하여 어떠한 방식으로 사용했고 실제 성능개선은 어떤 식으로 되었는지 작성을 해보려 합니다. 도입하게 된 배경- INDEX만을 사용해 데이터 조회 성능 개선을 할 수 없는 부분에 대한 개선 (Like 문법을 포함한 조회)- 유사 실서비스의 기능을 생각했을 때, 가장 많이 이루어지는 기능은 조회이며, 그에 따른 처리속도 개선을 Elasticsearch 사용을 통해 더욱 개선할 수 있습니다.우선 사용방법에 대해서 작성하기 전, 그래서 실제로 성능이 좋아졌는지에 대해서 먼저 말씀드리려 합니다. 우선 네트워크 속도 및 제 개인 맥북으로 테스트를 하는 것이기 때문에 성능개선에 대해서 오차는 좀 있으며 데이터 ..

Elasticsearch 도입의 배경진행하고 있는 팀프로젝트에서 모임 도메인을 맡아 기능을 구현하고 있던 도중, 이전 글에서 작성한 적이 있는데 Index를 통해서 조회 성능을 개선한 경험이 있습니다. 복합 인덱스로 is_deleted, category_id, status, meeting_date 를 걸어서 조회 성능을 개선했었는데 ( 초당 1000번의 요청 30초간 테스트 ), 실제 조회로직을 생각해보면 검색어 또한 중요한 필터가 될 것입니다. 하지만 이런 경우는 인덱스만을 통해서 성능 개선을 할 수 없습니다. 그 이유는 RDB 사용시 Title 조회 같은 경우 Like 문법을 사용하여 데이터를 조회해야하는데, Like사용시 인덱스를 무시하기 때문입니다. 또한 데이터가 많아지는 경우를 생각해보면 Ela..

테스트를 한 배경저는 모임을 가입할 수 있는 팀프로젝트를 만들고 있으며 그 중 모임을 구현하고 있습니다.소모임 같은 어플을 생각해봤을 때 가장 많이 사용되는 기능은 모임을 조회하는 로직이겠죠.저 또한 그 어플을 예전에 몇번 사용해보며 농구 모임을 찾았던 기억이 있습니다. 그렇다면 그 부분에 대해서 어떤 식으로 조회를 구현했는지와 성능테스트 결과를 비교해보며 왜 그런 선택을 했는지 알아보도록 하겠습니다. 우선 기존 조회로직입니다. 모임 조회를 한다고 할 때 간단히만 생각해봐도 조건들이 좀 있을 겁니다. 모임의 제목 조회, 상태, 카테고리 등등 이 존재할 겁니다. 그렇기 때문에 컴파일러에서 에러를 잡을 수 있고 가독성을 잡기 위해서 queryDsl을 사용했습니다. @Override public Page f..