Welcome! Everything is fine.

🧐 Spring Batch란? 배치(Batch) 처리란 대량의 데이터를 정해진 시점에 자동으로 일괄 처리하는 방식이다.예시 매일 자정 주문 데이터 통계 저장 매주 고객 대상 이메일 발송DB 마이그레이션, 정산 처리 등특징사람이 직접 요청하지 않아도 자동으로 주기적 실행실시간성보다 정확성과 안정성이 중요실패 시 재처리, 로그 추적이 중요Spring Batch는 대용량 배치 작업을 쉽고 안전하게 처리할 수 있도록 도와주는 Spring 기반 프레임워크다.Job/Step 기반 구성 제공예외, 로그. 재시작, 로깅 등의 기능 제공청크 기반 처리, 병렬 처리 등 내장💡 Spring Batch의 구조Job과 Step아래 그림은 Spring Batch의 전반적인 실행 흐름을 나타낸다.JobLauncher : 배치..

🧠 동기 · 비동기와 블로킹 · 논블로킹동기 vs 비동기동기(Synchronous) : 호출자와 요청자의 결과 확인이 동시에 일어남비동기(Asynchronous) : 호출자와 요청자의 결과 확인이 동시에 일어나지 않아도 됨블로킹 vs 논블로킹블로킹(Blocking) : 호출자가 요청에 대한 결과가 나올 때까지 요청자에게 제어권을 돌려주지 않는 것논블로킹(Non-Blocking) : 호출자가 요청에 대한 결과가 나오지 않더라도 요청자에게 제어권을 돌려줌동시성 vs 병렬성동시성(Concurrency) : 싱글 코어에서 여러 작업을 번갈아 가며 처리하는 방식병렬성(Parallelism) : 멀티 코어가 각 작업을 물리적으로 동시에 처리하는 방식 예를 들어, 아래 코드는 메시지를 수신할 때 동시에 최대 3개의..

이번 주 스터디 주제는 인증/인가다!최종 프로젝트에서 다른 팀원이 구현한 코드를 분석해보며 인증/인가에 대한 공부도 함께 진행해보려한다.Spring Security + JWT를 사용하는 방식은 이전에 강의를 듣고 포스팅 한 적이 있지만,프로젝트를 진행하면서 인증/인가 부분은 맡은 적이 없어서 기본에 충실한 내용들로 구성해 정리해보려 한다. 👤인증/인가가 필요했던 이유우선 인증(Authentication)과 인가(Authorization)에 대해 짚고 가자.인증(Authentication) : 사용자가 서비스에 가입되어 있는지 확인하는 과정(= 로그인)인가(Authorization) : 인증된 사용자에 대해 권한을 확인하는 과정인증/인가가 없다면 식당 예약, 이벤트 참여, 결제와 같은 주요 기능에 누..

최종 프로젝트가 끝난지 벌써 2주가 됐다...!최종 프로젝트에서 나는 예약 및 이벤트 동시성 제어를 구현했지만 아쉬운 점이 많았다. 좀 더 다양한 동시성 제어 방법에 대해 공부하지 않은 점DB 락 구현이 잘못된 점내가 구현한 부분은 말로 설명하는 연습이 부족한 점따라서 팀원들과 매주 모여 자신이 공부한 내용을 발표하고 의견을 나눠보기로 했다.주제는 최종 프로젝트의 핵심적인 내용 위주로 진행될 예정이다.첫 번째 주제는 "동시성 제어"이다.내가 맡은 부분이긴하지만 어렵고 헷갈리는 부분이 많아 쉽지 않은 주제인 것 같다.🧐동시성(Cocurrency) 제어란? 둘 이상의 실행 흐름(스레드 또는 트랜잭션)이 동시에 동일한 자원에 접근할 때 발생할 수 있는 데이터 충돌이나 정합성 오류를 방지하기 위한 제어 기법...

기존 코드의 문제점기존 이벤트 API는 오픈 알림이 구현되지 않았고,단순 DB 기반 스케줄러로 1분마다 오픈 시간을 체크해 상태를 변경하는 구조였다. 하지만 지금과 같은 구조는 다음과 같은 단점이 있다.데이터베이스 부하 증가스케줄러는 매 분마다 WHERE open_at 모든 이벤트를 조회해야 한다. 기존 코드는 매 분마다 위와 같은 조건으로 풀스캔하고 있다. 인덱스를 적용하더라도 유저 수와 이벤트 수가 많아질수록 쿼리 부하가 커지고, 인덱싱만으로는 처리 한계가 생긴다. 이벤트 오픈 비동기 전파 필요성만약 알림 도메인과 직접적인 연결을 한다면?두 서비스가 서로의 생명주기와 내부 구조에 영향을 받을 수 있다.직접적인 연결은 유지보수를 어렵게 하고, 장애 전파 가능성을 높인다.MQ를 사용하면 이벤트 서비스는..

문제점이벤트 정원이 10명인데도 200명 신청 시 9명까지만 들어가는 문제가 발생했다.또한 로그에서 “이벤트 정원이 초과되었습니다.”라는 메세지가 떴다.Redis에는 이미 200명이 저장된 상태DB는 한 명이 누락된 상태DB에 존재하지 않는 ID로 다시 신청 → EVENT_ALREADY_JOINED 예외 발생원인Redis와 DB의 정합성이 깨졌는데, 검증 기준은 Redis에만 의존하고 있기 때문이다. Redis는 ID를 이미 참여한 유저로 보고 있지만, 실제 DB에는 들어가지 않았다.하지만 ZSet에 있는 것만 보고 판단하여 중복 신청으로 막아버린 것이다.Zset에는 실패한 유저도 들어있기 때문에 100% 신뢰할 수 없다.왜 지금까지 이런 문제가 한 번도 없었는지는 잘 모르겠다..😓해결 방법valida..

캐싱(caching)이란?Redis에 대해 알아보기 전, 먼저 캐시 & 캐싱이 무엇인지 알아보자! 파레토의 법칙에 따라 자주 사용되는 20%의 데이터를 미리 캐싱해둔다면 효과적인 성능 향상을 기대할 수 있다.캐시(Cache) : 원본 저장소보다 데이터를 더 빠르고 효율적으로 가져올 수 있는 임시 데이터 저장소.캐싱(Caching) : 캐시에 접근해 데이터를 빠르게 가져오는 방식.캐시 사용 시 주의사항자주 사용되면서 변경이 적은 데이터에 적합하다.유실되어도 크게 문제가 없는 데이터에 적합하다.DB와 함께 사용 시 데이터 정합성 문제를 고려해야한다.데이터 캐싱 전략단순히 "캐싱"만 한다고 성능이 무조건 보장되는 것은 아니다. 어떻게 캐싱하느냐가 중요하다.대표적인 데이터 캐싱 전략을 알아보자.Cache Asi..

문제점애플리케이션을 실행하자, 다음과 같은 에러가 발생했다.원인Bean 초기화 시에 순환 참조가 생기면서 앱이 실행되지 않았다.EventService → EventJoinService를 @RequiredArgsConstructor로 주입EventJoinService → EventService를 또 @RequiredArgsConstructor로 주입서로 의존성을 주입하고 있어서 다음과 같은 순환 의존 구조가 된 것이다.EventController → EventService → EventJoinService → EventService (다시 참조)해결 과정기존에 EventJoinService에서 사용하고 있던 EventService를 EventRepository로 바꿨다.EventServic..