0. 배경프로젝트 진행 중, 프론트엔드 개발자분이 로그인 API가 Swagger 문서에 없다는 말씀을 하셨고, 확인해보니 Swagger 문서에 API가 존재하지 않았습니다.이번 프로젝트에서는 Security를 활용하여 인증/인가를 구현하였고, Springdoc은 Spring Security 필터를 자동으로 등록해주지 않습니다./login 엔드포인트를 문서에서 확인하기 위해서는 추가 설정이 필요합니다. Swagger를 보다 효율적으로 활용하기 위한 과정입니다. 1. 문제점이 존재하는 방법 - yml 설정 파일로 end-point 추가https://springdoc.org/#how-can-i-make-spring-security-login-endpoint-visible OpenAPI 3 Library for..
0. 배경https://byungil.tistory.com/331게시글 불러오는 쿼리와 마찬가지로, 게시글을 좋아요가 높은 순으로 정렬하여 불러올 때 속도가 매우 느렸고, OutOfMemory 장애가 발생하였습니다. 위 게시글과 마찬가지로 현재 어떠한 상황인지, 어떻게 해결하였는지 정리하였습니다. 1. 좋아요 순으로 정렬하여 No-Offset 방식을 적용한 쿼리처음 좋아요 순으로 정렬하여 No-Offset 방식을 활용하여 쿼리를 짰습니다.이 쿼리부터 문제가 있었고 하나하나 문제점을 찾고 해결하겠습니다.1.1 쿼리1.2 문제점 (1) - 여러명이 동시에 요청을 하면, OOM (OutOfMemory) 발생으로 서버가 종료됩니다.한 명이 요청하였을 때 문제가 발생하지 않았지만, 5명이 동시에 요청한다고 가정하..
0. 배경게시글 불러오는 쿼리를 개선하기 위해 좋아요 데이터를 많이 넣어보다가 좋아요 데이터가 많아지면 조회 속도가 매우 느려지는 것을 확인했고, 더 많은 데이터를 넣었을 때 Java heap space 에러가 발생하여 해결 방법을 정리하였습니다. 1. 현재 상황1.1 Post Entity, PostLike Entity1.2 PostService - getPost()1.3 PostResponse.of()1.4 게시글에 좋아요가 478,416개 있는 상황에서 단건 조회 응답 시간 - 9s1.5 발생하는 쿼리PostLike를 전체 조회하는 것을 확인할 수 있습니다.2. 발생 원인2.1 PostResponse 코드 문제발생원인은 PostResponse에서 찾을 수 있습니다.post.getPostLikes()...
0. 배경웹소켓을 이용하여 실시간 매칭 시스템을 구현하고 동시에 여러 사용자가 접근하는 테스트를 하는 여러 에러를 겪었고, 서비스에 큰 문제가 생길 수 있기 때문에 해결하는 과정을 정리하였습니다.1. 동시성 문제가 어떻게 발생할까동시성 문제가 발생하는 상황을 시뮬레이션 해보겠습니다. 이 상황에서 여자 1명이 대기 중이고, 남자 2명이 동시에 웹소켓 매칭 시스템에 접속하면 어떤 문제가 발생할 수 있는지 설명하겠습니다.1.1 상황 설정1. 여자 사용자 A가 매칭 대기 중2. 남자 사용자 B, C가 동시에 웹소켓 매칭 시스템에 접속3. 시스템은 1:1 매칭을 해야 한다.1.2 동시성 문제 시나리오대기 상태 [A]이며 B, C가 동시에 매칭 요청을 보냅니다. 사용자 B의 매칭 요청 처리 -> A를 선택하여 B와..
0. 배경Spring에 내장된 Simple Message Broker는 서버 내부 메모리에서 동작합니다.메세지 발행 시 서버가 다운 되어 메세지 전송을 실패하게 된다면, 인메모리 기반으로 동작하는 메세지 큐로 인해 메세지를 유실할 가능성이 높고, scale-out 상황에서 메세지를 못 받는 경우가 발생하였습니다. 메세지를 받지 못하는 상황을 개선하기 위한 과정입니다. 1. 서버가 다른 경우 메세지 수신이 안 되는 상황2개의 서버가 존재하고 각각 다른 서버에서 구독을 하고 있다는 상황을 가정하였습니다.내장된 SimpleMessageBroker를 사용하면 스프링 부트 서버의 내부 메모리에서 동작하게 됩니다. 서버간 채팅을 공유할 수 없는 상태입니다.서버가 다른 경우 메세지를 수신할 수 없습니다. 채팅 전용 ..
0. 배경작성된 게시글에 댓글을 작성하는 기능을 추가하였고, 알람 기능이 존재하지 않아 실시간으로 확인이 불가능하여 불편함을 겪는 사용자가 존재한다고 생각했습니다. 요구사항에 따라 알람 기능을 추가하면서 문제가 발생했습니다. 현재 제가 짠 로직은 댓글 작성 로직과 알람 발송 로직이 하나의 트랜잭션 안에서 처리되었습니다.외부 API - FCM과, Alarm Entity저장 그리고 댓글 작성을 하나로 처리하였을 때 발생할 수 있는 문제는 FCM과 알람 저장 기능에 문제가 생겼을 때 댓글 저장도 롤백되어버리는 문제입니다. 비즈니스 중요도를 고려하면 사용자 편의를 위한 부가적인 알림 기능(서비스 로직)이 댓글 작성(도메인 로직)이라는 메인 기능에 영향을 미치는 것이 부자연스럽다고 판단해 트랜잭션 분리를 고려하게..
