보호되어 있는 글입니다.

지난 번에 log4j2 Rolling Policy Property를 추가하는 PR을 올리면서 Spring Boot 코드 읽는게 재밌었고 자신이 어느정도 생겨서 심심할 때 Spring Boot 레포를 확인해보다가 흥미로운 이슈를 발견해서 PR을 올려보았다. issue 46674, 46665에 문제가 상세하게 작성되어있다.https://github.com/spring-projects/spring-boot/issues/46674https://github.com/spring-projects/spring-boot/issues/4666546674 issue를 확인하고 작업을 시작했다. 해당 issue에 background로 46665 이슈가 있길래 확인해 보았는데, 비슷한 내용을 서술하는 것 같지만 다루는 이슈가 ..

이제 마지막으로 새로 추가한 Rolling Policy를 Spring Boot의 기본 xml 파일에서 어떻게 읽는지 확인해보도록 하자. 대부분 비슷한 내용이지만 블럭에 새로운 Rolling Policy를 적용한 것을 확인할 수 있다. 다시 흐름을 설명해보자면 파일 로깅이 활성화된 경우(LogFile 존재) 이 Log4j2 구성이 사용되며 Boot가 시스템 프로퍼티를 먼저 채우고, XML은 ${sys:...} 치환으로 이를 소비해 최종 구성을 완성하는 흐름이다. xml 대부분의 동작 요소는 log4j2의 플러그인 시스템을 통해 이름/카테고리 매칭으로 읽어 인스턴스화한다. Spring Boot에서는 StructuredLogLayout이라는 커스텀 플러그인을 추가로 작성하여 사용하고 있다.기본 플러그인 -..

지난 번엔 기존 Spring Boot의 Logging 관련 설정들이 어떻게 적용되는지 알아보았다. 이제 그 흐름 사이에 추가하려고 하는 Log4J2의 Rolling Policy 속성들을 읽을 수 있도록 끼워넣으면 된다! 직접 구현한 내용에 대해 회고 및 자가 피드백할 겸 남겨두려고 한다. 흐름을 다시 살펴보면1. properties, yml에 정의한 속성을 시스템 프로퍼티로 읽게 하기2. 시스템 프로퍼티에 작성된 로깅 관련 값들을 log4j2-file.xml 파일에서 소비하는 단계로 이루어져있다. 이제 해야할 일은 다음과 같다.1. properties, yml에 Rolling Policy 관련 설정을 추가하면 시스템 프로퍼티로 작성할 수 있게 하기2. 새로운 프로퍼티를 xml 파일이 읽을 수 있도록 하기..

개발 배경Spring Boot는 Slf4J의 기본 구현체로 Logback을 지원한다. 하지만 대부분은 성능, 편의상 이유로 기본 의존성 Logback을 제거하고 Log4J2를 사용할 것이다. 로깅에는 Rolling Policy라는 것이 존재한다. 간단히 말하자면 하나의 로그 파일이 너무 커지는 것을 방지하기 위해 시간, 크기, cron 등의 기준으로 log파일을 끊어서 새로 작성하는 것이다.Logback은 이러한 Rolling Policy를 지정하는 것을 단순히 Spring Boot의 properties(yml) 파일의 속성으로 지정할 수 있다. 하지만 Log4J2에는 Rolling Policy를 지정할 수 없어 이러한 문제를 해결하고자 PR를 작성하게 되었다. 기본적인 것들은 지원해주는데 Rolling..

인증/인가와 Spring Security의 SecurityFilterChain과 대해 알아봅니다.GOAL인증, 인가에 대해 명확하게 이해한다.Spring Security의 FilterChain의 작동 방식에 대해 이해한다.Bearer와 Basic 인증의 차이를 이해한다.인증 / 인가먼저 간단하게 인증과 인가에 대해서 정리해보자. 인증(AuthN)사용자의 정체를 묻는 것으로 리소스에 접근하려는 사용자가 정말 그 사람인지를 물어보는 것이다. 사용되는 방식으로는 아이디/비밀번호, OTP, 인증서, 소셜 로그인 토큰 등이 있다. 보통 인증 요청이 실패한다면 401 Unauthorized 예외로 처리하게 된다. (재인증 필요) 인가(AuthZ)사용자의 권한을 검증하는 것으로 인증을 마친 사용자가 정말 이 행동을 ..

지난 번엔 모든 멤버들이 가입된 동아리를 가져오는 과정에서 생긴 N+1 문제를 해결하여 성능을 향상시켰다. 이번엔 재고가 1개 남은 물품을 동시에 예약하는 경우를 가정하고 해당 상황에서 생기는 문제를 해결해보았다. 동일한 물품에 대한 동시 대여서비스를 운영하면서 재고가 1개 남은 물품에 있어서 여러 명이 동시에 예약을 진행한다면 어떻게 될까? 라는 생각이 들어 직접 테스트를 해보았다. 현재 사용자가 물품을 예약하는 흐름은 다음과 같다.@Transactionalpublic BookDTO bookItem(String studentId, long itemId, int count){ if (count 3) { throw new LimitRentException("물품은 세 종류까지만 대여가 가..

교내 물품 대여 서비스를 운영하면서 생겼던 N+1 문제를 해결하기 위해 고민했던 시간을 회고하려 글을 작성한다. 처음 시작했던 프로젝트라 정말 N+1이 뭔지도 모르고 막 코드를 작성하고 재밌어했었는데.. 하지만 문제가 생기고 해결해 나가는 과정이 진짜 유의미한 시간이라고 생각한다. 문제 상황첫 번째로 확인한 N+1이 발생한 상황은 모든 동아리원 정보를 확인하는 관리자 페이지에서 간헐적으로 응답이 느려지는 현상이다. 관리자 페이지이고 전체 이용자 수가 500명 정도인 소규모 프로젝트여서 크게 체감되는 부분은 아니었지만 어떤 부분에서 오류가 발생하는지 확인하고 해결해보고자 한다.// 모든 학생의 가입된 동아리 정보public List findJoinedClubsForAllMember(){ List me..