spring

Spring Batch 성능 개선기 - N+1 문제 1. 서론 본 문서에서 다루는 배치 애플리케이션(추천 전처리 시스템)은 단순한 통계 집계가 아닌, 실제 서비스에서 사용자의 시청 이력에 기반한 개인화 푸시 알림을 빠르게 발송하기 위한 전처리 역할을 합니다. 서비스 입장에서는 수십만 명의 사용자에게 5분 이내로 추천 알림을 보내야 하고, 알림을 받은 사용자가 앱을 열었을 때 곧바로 추천 콘텐츠를 확인할 수 있어야 합니다. 하지만 알림 발송 시점마다 추천 로직을 실시간으로 실행한다면 문제가 생깁니다. 데이터베이스 I/O와 연산 비용으로 대규모 트래픽을 감당하기 어렵고, 지연도 불가피해집니다. 운영 환경에서는 마케터나 관리자들이 캠페인을 구성한 후, 특정 시간 예약 발송이나 즉시 발송을 유동적으로 선택합니다. 발송 요청 시점에야 "어느 사용자의 추천 데이터가 필요한지"가 드러나므로, 사전 계산 전략만으로는 부족합니다. 따라서 예약/즉시 여부와 무관하게 언제든 빠른 알림을 위해, 매일 자

🧪 Spring Batch JpaCursorItemReader에 대하여 Spring Batch에서 대량 데이터 처리를 다뤄본 개발자라면 한 번쯤 고민했을 것입니다. “JPA 기반으로 커서(Cursor)처럼 데이터를 읽을 수 있을까?” 오늘은 그 핵심 컴포넌트인 의 역사와, 왜 가 사라졌는지, 그리고 MySQL과 PostgreSQL의 커서 동작 차이까지 실제 실험 데이터와 함께 정리해보겠습니다. 1. JpaCursorItemReader의 역사 1.1 등장 배경 는 Spring Batch 4.3 (2020년경) 에 도입된 컴포넌트입니다. 그 이전까지는 JPA 환경에서 커서 기반 배치를 구현하려면 Hibernate의 를 직접 사용하거나, PagingItemReader를 우회적으로 이용해야 했습니다. 하지만 Paging 방식은 offset 기반 페이징 쿼리 특성상 큰 데이터셋에서는 성능이 급격히 저하되는 문제가 있었습니다. 그래서 Spring 팀은 “JPA 환경에서도 커서

Spring Batch에서 도중 종료시 BATCHJOBEXECUTION의 STATUS가 업데이트 되지 않는 문제 이 문서는 Spring Batch 애플리케이션에서 (안전한 종료)을 시도했음에도 불구하고, 테이블의 가 로 변경되지 않고 상태로 남아 재시작이 불가능한 문제에 대해 실제로 진행했던 트러블슈팅 과정을 중심으로 설명합니다. 1. 문제 상황 발생 배치 Job이 실행 중일 때 을 시도했습니다. 예상대로라면 테이블의 컬럼이 로 변경되어야 하지만, 실제로는 상태로 남아 있었습니다. - 예상 결과: = - 실제 결과: = 이 상태에서 동일한 파라미터로 Job을 재실행하면 Spring Batch는 해당 Job Instance가 이미 실행 중()이라고 판단하여 예외를 발생시키며 실패합니다. 2. 문제 상황 재현 = true로 하여, 애플리케이션이 실행될때 처리하도록 하려 했습니다. 이는 k8s에서 Job 파드로 처리하기 위함이었는데요, 문제는 요청 시점에 의 상태가

Spring Boot Auto Configuration 최근에 Spring 프레임워크에 대해 복기할 일이 생겼는데요, Spring Boot가 자동으로 해주던 Auto Configuration에 대한 내용이었습니다. 부끄럽게도 Component Scan에 관련해서 인식만 하고 있었지, 그 밑에 숨겨진 거대한 얼음덩어리에 대해 깊게 생각해보지 못한 것 같습니다. 그래서 본 포스팅에서는 Spring과 Spring Boot의 차이에 대해 전반적으로 정리하고, 그 중에서도 Auto Configuration이 어떻게 동작하고 어떻게 커스터마이징할 수 있는지에 대해 딥다이브 해보려 합니다. Auto Configuration이 왜 중요한 주제일까요? 💡개발자가 '설정'보다 '기능 구현'에 집중하게 해주는 핵심 장치이기 때문입니다. 물론 개발자가 기능에만 집중할 수 있도록 매번 귀찮은 설정에 대한 부분의 책임을 프레임워크가 맡아주는 것이 좋은 전략이긴 하나, 이것에 대해서 정확히 인지하고 있지

자바의 레퍼런스 타입은 런타임에 지워짐 예상결과 실제결과 왜 다 지워져버리는걸까? 이는 T의 타입 정보가 런타임까지 전달되지 않고, 컴파일 시점에 Object로 타입 소거되었기 때문이다. Sup이나 Sup 모두 동일한 바이트코드를 가지며, 리플렉션을 통해 타입 정보를 확인하려 해도 Object로 나오는 것이 정상이다. 여기에는 역사적인 이유가 있는데, 자바 1.4 이전 버전과의 호환성을 맞추기 위해 컴파일 타임에 타입을 소거시키는 것이다. 그래서 확장성있으면서도 안전한 형 보존을 위해서는 추가적인 작업이 필요하다. 예시: ObjectMapper 유틸리티 기존 프로젝트에서 ObjectMapper를 사용해서 json을 파싱할때면, 항상 와 같은식으로, ObjectMapper 빈은 스프링이 자동으로 빈 컨텍스트에 넣어주는데도 불구하고, 새로운 ObjectMapper를 만들어서 사용했고, 코드의 재사용성이 현저히 떨어졌다. 이를 개선하기 위해 JsonUtil 클래스를 만들었다. level

컴파일러, JIT, AOT, Graal, 그리고 Spring Native 이해하기 💡 이 포스트에서는 컴파일러, Just-In-Time(JIT), Ahead-Of-Time(AOT) 컴파일, GraalVM, 그리고 이들이 Spring Native와 어떻게 연관되는지에 대해 살펴본다. 이러한 개념들은 자바 및 다른 언어들이 다양한 런타임 환경에서 어떻게 작동하는지 이해하는 데 중요한 역할을 하며, Spring 애플리케이션이 이 기술들을 통해 성능을 최적화할 수 있는 방법을 제공한다. 1. 컴파일러란 무엇인가? 컴파일러는 프로그래밍 언어로 작성된 소스 코드를 기계어로 변환하는 도구이다. 두 가지 주요 컴파일 방식이 있다: - 정적 컴파일 (예: javac): 프로그램이 실행되기 전에 소스 코드를 기계어 또는 중간 형태로 변환한다. 자바에서는 파일을 파일(바이트코드)로 변환하는 과정이다. - 동적 컴파일 (예: JIT): 프로그램이 실행되는 동안 코드의 일부를 기계어로 변환한다. 2.

AuthenticationProvider and Housekeeping AuthenticationProvider 고객의 요구사항은 다양할 수 있다. 예를 들어, 어떤 고객은 애플리케이션에서 인증을 수행하는데 유저이름과 비밀번호를 사용하고 싶을 수 있고, 어떤 고객은 OAuth2를 사용하고 싶을 수도 있다. 또 어떤 고객은 몇몇 서비스에 OTP를 적용하는 것을 고려할지도 모른다. 이렇게 수 많은 경우의 요구사항을 프레임워크에서 모두 준비해 줄 수 없기 때문에, 우리는 우리만의 를 커스텀하여 사용해야 한다. AuthenticationProvider 내에는 두 가지 추상 메서드가 있다. 첫 번째는 메서드이다. 반환하는 객체는 인증이 성공적이었는지에 대한 정보를 가지고 있어야 가 다른 를 시도해 볼 수 있다. 두 번째는 메서드이다. 해당 메서드는 우리가 커스텀하는 가 어떤 종류의 인증을 지원하고 싶은지를 서술한다. 어떤 종류의 인증에 관해 이 가 부름을 받아야 하는지 프레임워크에

Spring Security PasswordEncoder Encoding, Encryption and Hashing 고객의 데이터를 저장할 때, 비밀번호와 같은 민감한 값은 Plaintext 형태로 직접 저장해서는 안된다. 데이터 보안의 핵심은 이러한 민감한 정보를 안전하게 보호하는 것이다. 이를 위해 흔히 사용하는 세 가지 방법은 Encoding, Encryption, 그리고 Hashing이다. 각 방법의 특징과 차이점을 이해하는 것은 매우 중요하다. Encoding - 목적: 데이터를 다른 형식으로 변환하여 전송하거나 저장하는 과정. - 특징: 데이터의 변환은 가독성을 높이기 위한 것이며, 정보 자체의 보안을 고려하지 않는다. - 가역성: 가역적이다. 즉, 원래 데이터로 복원할 수 있다. - 예: Base64, URL Encoding 등. Encryption - 목적: 데이터를 암호화하여 권한이 없는 사람이 읽을 수 없도록 보호. - 특징: 암호화 키를 사용하여 데이터를 변

Spring Security 유저 관리 인터페이스 기본 설정에서의 스프링 시큐리티 시퀀스 기본 설정에서 의 구현체인 를 사용하고, 의 구현체인 를 사용했다. 는 의 확장인 의 구현체인 를 사용했다. 위 내용은 아주 중요하니 숙지하고 들어가야 한다. UserDetails 이전 섹션에서 설명한 /는 유저 정보를 표현하기 위해 인터페이스를 사용한다. 한 번 인터페이스를 살펴보자 - : 이 메서드는 엔드 유저의 권한 또는 역할 목록을 보유하고 있고 그래서 이를 이용하여 인가 또는 역할 기반 엑세스 메커니즘을 구현할 수 있다. - : 엔드 유저의 비밀번호를 반환한다. - : 엔드 유저의 유저 이름을 반환한다. - 기본 세부 정보 이후에 유저 계정이 만료되었는지, 잠겨 있는지, 자격 증명이 만료되었는지 등을 확인하는데 도움이 되는 몇가지 다른 메서드들도 제공한다. User 스프링 시큐리티 팀은 를 구현한 를 샘플로 제공한다. 우리는 이 구현체가 마음에 들지 않으면 커스텀한 새로

Spring Security 기본 설정, 커스텀 기본 필터체인 을 확인하면 다음과 같이 기본 필터체인이 등록되었음을 확인할 수 있다. - : 이 구문은 해당 필터체인의 인가 규칙을 정의한다. - : 모든 요청에 대해 인증이 필요하다고 설정한다. - ⚠️ 최신 스프링 시큐리티에서는 TypeCasting 없이 사용할 수 있도록 개선됐다. - - : 폼 기반 로그인을 설정한다. 프론트엔드와 백엔드가 나뉘어 http로 유저네임과 비밀번호를 전송하는 경우에는 사용하지 않는다. - : http 기본 인증을 설정한다. 이 설정은 http 헤더를 통해 인증을 수행할 수 있도록 한다. -이는 JWT의 그것과 다르다. 자세한 내용은 아래 참조. HTTP Basic? HTTP Basic 인증 과정 1. 클라이언트 요청: - 클라이언트는 보호된 리소스에 접근하기 위해 서버에 HTTP 요청을 보냅니다. 이때 클라이언트는 아직 인증되지 않은 상태입니다

Spring Security 디버깅 Spring Security Filters 스프링 프레임워크는 Tomcat 서블릿 컨테이너 위에서 돌아가므로 Tomcat의 서블릿 필터 기능에 의존한다. 스프링 시큐리티를 사용하게 되면 이 Tomcat의 FilterChain에 스프링 시큐리티 전용 필터를 하나 끼워넣어 모든 요청을 가로채는데, 이것이 바로 이다. 는 기타 로직이 하나도 없이 단지 스프링 프레임워크 내부의 빈으로 요청을 넘겨주는 프록시 역할만을 할 뿐이다. 는 엔드 유저의 요청에 따라 스프링 시큐리티가 관리하는 을 호출하여 요청을 거기로 프록시한다. 는 인증 및 인가와 관련된 여러 사항을 검증하고 적절한 응답을 반환하는 것을 목표로 한다. 는 위 그림과 같이 여러개로 구성될 수 있으며, 엔드 유저의 요청 URL에 따라 가 적절한 에게 프록시 해준다. Default Spring Security Filter Chain 를 열어보면 다음과 같은 메서드를 확인할 수 있다. 이 메서드는 가

Spring Security 내부 흐름 플로우 다이어그램 1. 사용자가 웹 어플리케이션에 자격증명 정보를 입력한다. 이 정보는 으로 넘겨진다. 는 사용자가 입력한 자격증명을 가로채고, 접근 권한이 있는지 확인한다. Spring Security Filter Chain? FIlter Chain에는 : 사용자 이름과 비밀번호를 통한 인증을 처리 : HTTP Basic 인증을 처리 : CSRF 공격을 방지 : 로그아웃 요청을 처리 와 같은 필터들이 있을 수 있다. 2. 는 엔드유저가 보낸 자격증명 정보에서 유저네임과 비밀번호를 추출하여 객체로 변환한다. 에 이미 정보가 존재하는 경우는 이후 해당 객체를 사용하고, 과정을 스킵한다. Authentication? 객체는 스프링 시큐리티 프레임워크 안에서 엔드유저의 정보를 저

SecurityBuilder와 SecurityConfigurer 본 포스팅 시리즈에서 Spring Security는 Spring Boot 2.7.x 버전을 기준으로한 강의를 최신 스프링 공식 문서를 참고하여 수정하였습니다. Deprecated된 여러 메서드들을 최대한 최신에 맞게 바꾸었지만 완벽하지 않을 수 있습니다. Spring Security OAuth 시리즈 1. 포인터를 잘 알아야 하는 이유 개념 및 구조 이해 - 는 빌더 클래스로서 웹 보안을 구성하는 빈 객체와 설정 클래스들을 생성하는 역할을 하며 , 가 있다. - 는 Http요청과 관련된 보안처리를 담당하는 필터들을 생성하고 여러 초기화 설정에 관여한다. - 는 를 포함하고 있으며 인증 및 인가 초기화 작업은 에 의해 진행된다. 시퀀스 다이어그램 에서 를 호출하면, 의 과 가 호출되어 초기화 작업이 진행된다. - 의 가 반환하는 최종 클래스는 내부의 가 반환한 이다. - 의 가 반환하는 최종 클래스는 내부의 가 반환한

Spring Security 6.2.1 JWT 설정하기 Security Config 클래스 기본 요소 작성 - 스프링 시큐리티의 인가 및 설정을 담당하는 클래스이다. - Security Config 구현은 스프링 시큐리티의 세부 버전별로 많이 상이하다 (이번 시리즈는 스프링 시큐리티 6.2.1 버전) BCryptPasswordEncoder 등록 커스텀 로직 구현 Form 로그인 방식에서는 클라이언트단이 username과 password를 전송한 뒤 Security 필터를 통과하는데 필터에서 회원 검증을 진행을 시작한다. (회원 검증의 경우 가 호출한 를 통해 진행하며 DB에서 조회한 데이터를 를 통해 받음) 우리의 JWT 프로젝트는 에서 formLogin 방식을 disable 했기 때문에 기본적으로 활성화 되어 있는 해당 필터는 동작하지 않는다. 따라서 로그인을 진행하기 위해서 필터를 커스텀하여 등록해야 한다. 🚀 구현 목표 - 아이디, 비밀번호 검증을 위한 커스텀 필터() 작성

Servlet Filter 와 Spring Interceptor 웹과 관련된 공통 관심사는 AOP를 사용할 수도 있지만 서블릿 필터 또는 스프링 인터셉터를 사용하는 것이 좋다. 웹도 관련된 공통 관심사를 처리할 땐, HTTP의 헤더나 URL의 정보들이 필요한데, 서블릿 필터나 스프링 인터셉터는 를 제공한다. 서블릿 필터 서블릿 필터 흐름 - 여기서 말하는 서블릿은 스프링 디스패처 서블릿이다. 필터 제한 필터 체인 - 필터는 순서를 지정하여 자유롭게 구성할 수 있다. 사용예시 LogFilter WebConfig 스프링 인터셉터 스프링 인터셉터 흐름 - 여기서 말하는 서블릿은 스프링 디스패처 서블릿이다. 스프링 인터셉터 제한 스프링 인터셉터 체인 - 스프링 인터셉터도 체이닝 기능을 사용할 수 있다. 스프링 인터셉터 인터페이스 - 서블릿 필터의 경우 단순하게 하나만 제공되나, 인터셉터는 컨트롤러 호출 전(), 호출 후(), 요청 완료 이후()와 같이 단계적으로 잘 세분화 되어 있다. -