SpringBoot

개요 스프링부트로 개발을 시작하면서 자주 보이는 어노테이션들이 있다. 그것은 바로 @NoArgsConstructor, @Builder, @AllArgsConstructor 이 3 가지이다. 김영한 강사님의 강의를 들으면서 @Builder에 대해서는 아직 학습하지 못

현재 User의 Rank와 방 목록을 조회하는 API에서 findAll 로직을 구현하고 있다.User Rank로 예시를 들어보려고 한다.현재 이 코드는 JPQL을 사용하여 User의 Score를 기준으로 내림차순으로 List를 뽑았고 이 User 객체를 UserRank

처음에는 당연히 오류코드를 파악하고 해당 log를 찾아보았다.그때 필터에서 오류가 나는 것을 확인하였고 그때는 이해를 하지 못했다.하지만 코드를 계속 찬찬히 보고있는데 왜 anonymous가 NumberException이 나는지를 도무지 이해를 못했다.일일히 sout을

Servlet에 대한 학습내용을 기록합니다.자바 서블릿(Java Servlet)은 자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 말하며, 흔히 "서블릿"이라 불린다. 자바 서블릿은 웹 서버의 성능을 향상하기 위해 사용되는 자바 클래스 이다

Apache Tomcat은 Apache Software Foundation에서 개발한 Java 기반의 서블릿 컨테이너이다.JSP, Spring으로 개발을 한다면 톰캣이 내장되어있기 때문에 사용하고 있을 것이다.WS(Web Server)는 웹 서버를 의미하며, 가장 쉽게

SpringBoot 3.x.x로 오면서 2.6.x보다 세팅이 간단해졌다고한다.3.x 버전부터 QueryDSL 플러그인을 추가하지 않아도 된다.build.gradle아래 Gradle에서 clean → buildsrc/main/generated에 Q클래스 생성QHello가

현재 100명의 TestUser를 생성한 이후 하나의 Todo에 좋아요를 누르려고 한다.이에 executorService 를 사용하여 테스트를 진행하려고 했지만 수없이 많은 오류를 겪게 되어 기록한다.기존에 하듯이 다음과 같이 테스트를 시작하기전 테스트 유저 100명을

💡 드디어 동시성 문제를 해결했다. 예상치도 못하게 해결이 되어서 당황스러웠다. 진행 과정 분산락을 걸었는데도 불구하고 동시성 제어가 되지 않았다. 기존의 경우 likes가 41개정도였는데 해당 코드를 작성하고 나서 90개가 넘도록 데이터 정합성은 올랐다. 하지

E2EE를 구현하기에 앞서 학습한 내용을 기반으로 서버와 클라이언트에서의 시나리오를 정리한다.필자는 Public Key 저장소를 MongoDB로 사용한다.Comment 작성 및 암호화: 사용자가 댓글을 작성하면, 해당 댓글은 사용자 장치에서 수신자의 공개 키를 사용하여

현재 개발하고 있는 프로젝트에서 인증을 메일로 처리하는 부분이 있어 JavaMailSender가 아닌 AWS의 SES를 적용해본 일지를 기록한다.Amazon Simple Email Service의 줄임말이다.말 그대로 간단하게 이메일을 전송할 수 있는 서비스이다.처음

코드를 작성하면서 @Transactional, @Transactional(read=only)를 붙이는 이유에 대해서 학습해보고자 하여 정리한다.데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 또는 한꺼번에 모두 수행되어야 할 일련의 연산

Spring Batch를 적용해보았다. 적용 과정을 기록한다.이 글에서 나는 이론적인 부분보다 간략하게 코드에 대한 정리를 남길 것이다.build.gradle에 다음과 같이 spring batch 의존성을 부여한다.이렇게 하면 가장 최신 버전이 설치되게 된다.Versi

Sprinb Batch를 말로만 들어보다가 사용하게 되며 사용 이유에 대해 정리한다.Spring Batch 자체에 대한 내용은 공식 문서를 읽거나 이미 수많은 정리가 되어있기에 그 글들을 읽으면 될 것 같다.현재 나의 신분은 대학교 3학년 2학기 재학생이다.회사에 다니

AWS SES에서 메일 전송 속도를 비동기로 최적화했다. 93%정도의 시간을 줄일 수 있었다. 이에 대해 가볍게 정리해본다.AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)는 공통 관심사(부가 기능)를 비즈니스 로직에서 분리하여 모듈화하

Kotlin을 사용하여 SpringBoot를 연습합니다.멀티 모듈 환경을 구축하면서 학습한 내용을 정리합니다.루트의 gradle.properties 파일에서 공통 변수를 관리한다.applicationVersion, projectGroup은 root 경로의 build.g

Kotling SpringBoot로 개발을 진행하던 중 Validation이 동작하지 않아 학습 내용을 정리한다.프로젝트에서 DTO 유효성 검증을 위해 @NotBlank, @NotNull, @Future 등의 애노테이션을 사용했다.이렇게 작성하면 Kotlin은 기본적으

Todo를 지정한 시간에 알림을 보내주는 기능을 구현하려고 한다.이전에 먼저 DB에 등록한 Todo를 서버단에서 Todo 예정 등록 시간에 맞춰 잘 추출해내는 지를 확인한다.이렇게 가볍게 구현할 수 있다.1분마다 스케줄러를 돌리면서 DB에 기록되어있는 Todo 중 완료

개발을 진행하며 DB Table 구조를 설계할 때 깊은 고민을 하지 않고 양방향과 연관성이 보이면 무조건 외래키를 걸어서 구현한 결과, 규모가 커질수록 미친듯한 불편함과 문제점이 발생해서 연관관계 매핑에 대한 학습을 진행하고 정리한다.OneToMany와 OneToOne

대부분의 개발자들은 insert, update, delete 쿼리가 발생하는 메서드에 습관적으로 @Transactional을 적용한다.이런 단순한 경우에는 문제가 없다. 하지만 외부 서비스 호출이 포함된 경우에는 상황이 달라진다.이 코드의 문제점:SMS 발송과 Slac

멀티 모듈을 직접 구현해보고 개발을 하면서 구현하기 시작한 그 즉시부터 지금까지 생겼던 의문을 해결하고 글로 정리한다.Core-API, Core-Domain으로 모듈이 분리되어있다고 가정하자.Core-API에서는 Presentation Layer를 Core-Domain

Sent 프로젝트를 개발하면서 클라이언트가 직접 API 명세서를 확인할 수 있도록 문서 제공 환경을 구축할 필요가 생겼다. 초기에는 기존 개발 서버에 명세서를 함께 제공하려 했지만, 최종적으로는 GitHub Pages를 활용한 별도 배포 방식으로 결정하게 되었다.이 글

멀티모듈(Spring) 환경에서 순환 의존성 없이, 시스템 예외 발생 시 Discord 웹훅으로 실시간 알림을 전송할 수 있도록 설계한다.common 모듈: 예외 핸들러, DTO, 상수 등 순수 공통 코드 담당support 모듈: Discord 알림 등 부가 기능 담당

Sent 프로젝트를 진행하면서 Todo 기능을 구현할 때 월별로 Todo 조회 시 어떤 카테고리에 속해있는 지도 추출해서 보내주어야했다. 이를 코드로 작성하면 Category 조회 코드도 필요하고 Todo를 일괄적으로 조회하면서 내부적으로 Category 조회 코드도

나인멘스모리스라는 1:1 실시간 턴제 게임을 웹으로 구현하기 위해서 예전에 STOMP를 사용해서 서버를 구현한 적이 있었다.STOMP를 사용한 이유는 순수 WebSocket으로만 구현하려면 이것저것 복잡한 세팅들을 전부 구현해주어야했으나 STOMP 자체에서 제공하는 많

채팅 메세지를 보내면 RabbitMQ로 메세지 전송 후 MongoDB에 해당 메세지 백업 후 MySQL에 마지막으로 보낸 메세지와 날짜를 업데이트 한다.이 3가지의 과정이 동기적으로 일어나므로, 이 또한 부하를 줄 수 있을 것으로 판단되어 비동기처리를 적용한다.현재 R

개요 > 채팅방에 접속했을 때 채팅 이력을 조회한다. 이때 데이터가 쌓이면 쌓일수록 DB 부하가 일어날 것이라고 판단했다. 10만개의 채팅 이력이 쌓였다면 FULL SCAN으로 DB에서 데이터를 모두 조회해서 반환하는 것은 상당한 부하가 갈 것이다. 그렇기에 우선적으로

예전 작업하다가 임시 중단했던 Sent Project를 보수하기로 했다.채팅에 대해서 K6를 사용해서 부하테스트를 했었는데, 페이지네이션 + 인덱스 적용에 이어 Redis 캐싱을 적용해보자.메시지 저장 과정에서 MongoDB + Redis ZSET에 동시에 쓰는 방식(

채팅 시스템의 SQL 튜닝을 진행하던 중, 로그인 후 채팅방 목록을 조회하는 단순한 과정에서 User 테이블을 중복 조회하는 쿼리가 다수 발생함을 확인했다. 이는 트래픽이 증가할 경우 DB 부하를 가중시키는 주원인이 될 수 있으므로, 인증 로직을 전면적으로 리팩토링하여