0. 배경Swagger를 사용하여 Api 명세로 의사소통 없이 API에 대한 요청과 응답을 확실하게 하고 싶었습니다. @ApiResponses를 이용하여 응답값에 대한 모든 예외를 처리하였는데, 문제점이 많아 어떻게 하면 편리하게 사용하고 보여줄 수 있는지 고민하였고 해결 과정입니다. 1. 기존 방식의 문제점1.1 정확한 값이 나오지 않는다.Swagger에서는 @RestControllerAdvice와 같은 어노테이션을 이용한 전역 예외 처리를 식별하여 문서화하는 기능이 포함되어있습니다.이렇게 되었을 때, 400에 대한 무슨 에러인지 어떤 메세지가 발생하는지에 대한 예외를 알 수 없습니다.1.2 responseCode, description을 직접 작성해야 한다.같은 에러코드를 묶고, 정확한 설명을 위해서..
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를 사용하면 스프링 부트 서버의 내부 메모리에서 동작하게 됩니다. 서버간 채팅을 공유할 수 없는 상태입니다.서버가 다른 경우 메세지를 수신할 수 없습니다. 채팅 전용 ..
