backend

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

JPA saveAll이 느린 이유와 개선 방향 💡 “JPA를 포함한 ORM은 은총알이 될 수 없습니다.” 우리는 종종 ORM을 사용하면 SQL과 트랜잭션의 복잡함에서 해방될 거라 믿습니다. ORM은 데이터를 객체로 다루는 자유를 주지만, 동시에 성능과 제어의 일부를 포기하는 대가를 요구합니다. Hibernate의 은 한 줄의 코드로 모든 걸 해결할 수 있을 것처럼 보입니다. 그러나 그 한 줄 뒤에서 ORM은 수십, 수백 개의 INSERT를 순차적으로 실행하며 JDBC의 배치 성능을 스스로 봉인하고 있습니다. 기존 은 엔티티 단위로 INSERT가 반복되어 네트워크 라운드트립과 엔티티 라이프사이클 오버헤드가 컸습니다. 로 전환하고 드라이버 배치 리라이트를 켜서 한 번의 배치로 밀어 넣으니 60초 → 7.3초로 단축됐습니다. 다대다 테이블을 매핑하는 가상의 TableMapper 엔티티의 예시를 통해 아래에 원인, 설정, 로그 차이, 주의사항을 정리하겠습니다. 배경: 기존 코드 vs 개선

🧪 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에서 LocalStack + Testcontainers로 AWS 통합 테스트 구축하기 현대의 많은 애플리케이션 컴포넌트가 클라우드로 이전하면서, 테스트 과정에서 테스트만을 위한 별도의 클라우드 인프라를 구성하는 것은 큰 부담으로 다가올 수 있습니다. LocalStack은 이러한 문제를 해결하기 위해 등장했습니다. 이번 포스트에서는 LocalStack을 활용하여 클라우드 인프라 의존적인 테스트 코드를 걷어내고 Testcontainers와 통합하여 어떻게 안전하고 신뢰성 있는 테스트를 할 수 있는지 정리하겠습니다. 💡 다음 선행 지식이 필요하다: - JUnit 5 - Testcontainers ⚠️ 사전 준비: Docker가 설치/실행되어 있어야 한다. (Testcontainers와 LocalStack은 Docker 컨테이너를 사용한다) LocalStack이란 무엇인가요? LocalStack은 로컬 환경에서 AWS 클라우드 서비스를 시뮬레이션 할 수

Flyway로 Testcontainer에서 기본데이터 구축하기 테스트를 진행할때 Mock데이터나 fixture를 준비하는 과정은 다소 번거롭습니다. Testcontainer를 사용하여 테스트 환경의 DB를 격리할 수 있으나, API 레이어를 경유하는 E2E 통합 테스트(예: @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOMPORT)와 TestRestTemplate이나 WebClient를 활용한 실제 HTTP 요청 시나리오)에서는 트랜잭션 경계가 모호해져 @Transactional 롤백 처리가 불완전하거나 예상치 못한 동작을 보일 수 있기 때문에 또 다른 고려 사항이 필요합니다. 이는 MockMvc처럼 서버를 모킹하는 통합 테스트에서는 @Transactional로 충분히 효과적인 롤백을 지원하지만, E2E에서는 실제 네트워크 레이어(포트 바인딩, HTTP 헤더 처리, 보안 필터 등)를 포함해 전체 스택을 검증해

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

DDD 애그리거트에서의 fetch join 처음 나는 도메인 주도 설계(DDD)의 원칙에 따라 와 을 하나의 애그리거트로 묶었다. 그리고 자연스럽게 모든 의 변경은 루트를 통해서만 일어나도록 설계했다. 이 구조 자체는 문제가 없었다. 문제는 그 이후, 성능 최적화에 대한 오해에서 비롯되었다. 💡 애그리거트 패턴이란? 애그리거트(Aggregate) 패턴은 도메인 모델에서 관련된 객체들을 하나의 일관된 단위로 묶어 관리하는 개념이다. 이 묶음의 중심에는 루트 엔티티(Aggregate Root)가 있으며, 외부에서는 반드시 루트를 통해서만 내부 구성 요소에 접근하거나 변경할 수 있다. 이렇게 함으로써 도메인의 불변 조건이나 비즈니스 규칙을 루트가 통제할 수 있게 된다. 구성 객체들은 루트 없이는 독립적으로 저장되거나 로딩될 수 없다. 애그리거트는 하나의 트랜잭션 단위를 구성하며, 변경은 항상 이 경계 내에서 일어난다. 여러 애그리거트가 서로 참조할 경우에는 실제 객체

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

서드파티 결제서비스 연동가이드(구글 플레이스토어) 구글에서 엔드포인트 유저의 재화결제에 대한 데이터를 식별하고 핸들링하기 위해서는 구글에서 제공하는 결제관련 API와 RTDN 웹훅을 사용해야합니다. 구글에서는 크게 단발성 결제와 구독형 결제의 두 가지 결제타입을 지원하고 있으며, 아래는 각각의 결제 타입에 따른 프론트엔드와 백엔드의 역할 시퀀스 다이어그램입니다. - 프론트엔드 = 클라이언트 = 앱 - 백엔드 = 서버 단발성 결제 시퀀스 다이어그램 구독형 결제 시퀀스 다이어그램 결제정보 핸들링 위 시퀀스 다이어그램을 살펴보면, 단발성 결제와 구독형 결제 모두 과 유저를 매핑하는 부분은 동일함을 알 수 있습니다. 은 해당 결제에 대한 unique id로, 같은 이 영구히 유지되기 때문에, 추후 환불에 대한 요청에서도 같은 으로 어떤 상품인지를 식별해야 합니다. 각 4번 단계( 유효성 검증)요청을 받는 응답(5번) 예시는 다음과 같습니다. 이라는 Unique id가 있는데, 왜 라는 값이

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

CreatedDate, CreatedBy 어노테이션 JPA에는 엔티티의 생성 정보를 자동으로 기록해주는 와 와 같은 어노테이션이 있다. 어노테이션은 엔티티가 생성된 날짜와 시간을 자동으로 저장하는 데 사용되며, 어노테이션은 엔티티를 생성한 사용자의 정보를 기록하는 데 사용된다. 이 두 어노테이션의 사용 방법과 그 역할에 대해 알아보자. 예시 코드 위 코드는 JPA에서 자식 클래스들에 모두 적용할 컬럼을 지정하는 슈퍼 클래스의 예시이다. 모든 자식 클래스들에 생성일, 생성자, 최종수정일, 최종수정자를 컬럼으로 갖게 하여 DB와 매핑시킬 의도를 가지고 있다. 사전작업 1. AuditorAware 구현체 정의 를 구현한 클래스인 을 작성한다. 에는 로써 이름을 붙여두고(추후 메인 클래스에서 지정하기 위함), 메서드에서는 감사자(auditor)로 들어갈 값을 지정해주면 된다. 예시 코드의 경우, 가 지정된 컬럼에는 "AUDITOR"가 들어갈 것이다. 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 스프링 시큐리티 팀은 를 구현한 를 샘플로 제공한다. 우리는 이 구현체가 마음에 들지 않으면 커스텀한 새로