1. 개념

1.1 Spring Batch 란?

• 대용량 데이터나 반복적인 업무를 효율적으로 처리하기 위한 스프링 기반 배치 프레임워크

1.2 언제 사용하는가?

1.2.1 주기적으로 실행되는 작업이 있는 경우

• ex) 정산

1.2.2 대용량 데이터를 처리해야 하는 경우

• ex) 로그 분석

1.2.3 멀티 스레드, 분산 처리, 병렬 처리가 필요한 경우

• ex) 매출 데이터 분석

1.2.4 재시도 혹은 재실행이 필요한 경우

• ex) 외부 API에서 데이터를 가져와서 처리하는 경우

1.2.5 트랜잭션 관리가 필요한 경우

• ex) 포인트 적립

1.3 왜 사용하는가?

1.3.1 일관된 아키텍처

• 배치 작업에 필요한 공통 패턴과 템플릿을 미리 제공해 중복 코드 최소화

1.3.2 안정성 & 트랜잭션 관리

• 실패 시 재시도, 재실행을 지원하며 트랜잭션 경계를 쉽게 설정 가능

1.3.3 손쉬운 모니터링 & 로깅

• Job, Step 단위로 상태를 관리하여 문제 원인 파악이 쉬움

1.4 특징

1.4.1 잡(Job)과 스텝(Step)을 통한 구조적 설계

• 작업 단계를 명확히 구분해 유지보수가 쉽고, 실패/재실행 시에도 어디서 문제가 발생했는지 확인이 용이

1.4.2 Chunk(청크) 지향 처리

• 대량 데이터를 일정 덩어리(Chunk)로 나눠 읽고, 가공 후 한 번에 쓰는 방식

1.4.3 다양한 인터페이스 및 구현체 지원

• ItemReader, ItemProcessor, ItemWriter 등 표준화된 인터페이스 제공
  • CSV, JDBC 등… 제공

1.4.4 에러 처리 및 재시도(Retry) 정책

• 작업 도중 오류가 발생해도 재시도 횟수, 건너뛰기(Skip) 등을 설정 가능

2. 아키텍처

2.1 JobLauncher

• 외부 (스케줄러 등)로 부터 배치를 실행 하라는 요청을 받아 시작
• ❗햇갈리면 안되는 내용
  • Spring Batch VS Scheduler(or Quartz) 어떤걸 사용하는게 좋을까요??
    • 서로 다른 개념이니 비교하면 안된다!
    • Spring Batch는 대용량 처리!
    • Spring Scheduler는 특정한 시간에 등록된 작업을 자동으로 실행시키는 것!
• Job과 파라미터 정보를 받아 Job을 실행하고, 그 결과를 반환

2.2 JobRepository

• 배치 작업의 메타 데이터를 저장/관리하는 장소
• 각 Job과 Step의 실행 결과를 DB에 기록하여 재실행, 모니터링, 통계 분석 등 활용할 수 있도록 함

2.3 Job

• 하나의 배치 프로세스 전체를 나타내는 상위 개념
• 내부에 여러 Step을 가지고 있으며 각 Step을 순서대로 실행

2.4 Step

• 배치 처리를 위한 실질적인 실행 단위

2.4.1 ItemReader

• DB, 파일, 메시지 큐 등에서 데이터를 한 건씩(또는 여러 건 단위) 읽어 옴

2.4.2 ItemProcessor

• 읽어온 데이터를 가공, 변환, 검증, 필터링 등 비즈니스 로직 수행

2.4.3 ItemWriter

• 가공된 데이터를 최종적으로 저장(파일, DB 등)

2.5 ExecutionContext & JobExecution

• ExecutionContext
  • 각 Step에서의 중간 상태나 필요한 데이터를 임시로 저장하는 컨텍스트
• JobExecution / StepExecution
  • 실행 시간, 처리 건수, 오류 발생 시점 등 세부 정보를 기록해 JobRepository에 보관
  • 재 시작 시 참조되어 어디까지 진행되었는지 확인 가능

1. Spring Security

1.1 Spring Security 란?

• 보안을 손쉽게 적용하기 위한 Spring Framework의 하위 프로젝트
• 인증(Authentication)과 인가(Authorization)에 대한 다양한 기능을 제공
• Filter 기반의 아키텍처로 구성되어 있어, 다양한 커스터마이징이 가능

1.2 Spring Security 인증 및 인가 흐름

2. OAuth 2.0

2.1 OAuth2.0 이란?

• Open + Authorization (개방형 인가)
• 웹 및 애플리케이션 인증 및 권한 부여를 위한 개방형 표준 프로토콜
• 외부 Resoure에 접근하기 위해 사용

2.2 기본 용어

2.2.1 서버 및 클라이언트

• Resource Owner(사용자)
• Client(애플리케이션)
• Authorization Server(인증 서버, 토큰 발급)
• Resource Server(API 서버, 자원을 실제로 소유)

2.2.2 기타

• Authorization Code (인증 코드)
• Scope (범위)

2.3 인증 방식

2.3.1 Authrozation Code Grant

• 서버 기반 애플리케이션(Server-side Application)에서 가장 많이 사용되는 인증 방식
• 사용자에게서 직접 자격 증명 정보를 받지 않고, “인가 코드(Authorization Code)”를 발급받아 이를 이용해 액세스 토큰(Access Token)을 얻는 구조

2.3.2 Implicit Grant

• 브라우저에서 동작하는 자바스크립트 기반 애플리케이션과 같이 클라이언트 비밀(Client Secret)을 안전하게 보관하기 어려운 환경에서 사용하던 방식

2.3.3 Password Credentials Grant

• 사용자가 클라이언트에 직접 아이디/비밀번호 등의 자격 증명을 입력하고, 클라이언트가 이를 권한 서버에 전달하여 인증 및 액세스 토큰을 발급받는 방식

2.3.4 Client Credentials Grant

• 서버 대 서버 혹은 백엔드 서비스 간 통신과 같이, 사용자 대신 애플리케이션 자체가 리소스에 접근해야 할 때 사용하는 방식

2.4 통합 흐름

1. 개념

1.1 DB Lock 이란?

• DB Lock은 여러 트랜잭션이 동시에 같은 자원에 접근할 때 데이터 무결성(정합성)을 보장하기 위해 사용되는 메커니즘
• 쉽게 말해, 어떤 사용자가 데이터를 사용하고 있는 동안에는 다른 사용자가 그 데이터를 동시에 수정하면 안 되기 때문에, ‘잠금’을 걸어서 충돌(Conflict)을 방지

1.2 왜 Lock이 필요한가?

• 여러 사용자가 동시에 DB를 사용하는 경우 같은 데이터를 동시에 수정하려고 시도하는 경우 충돌 제어 및 데이터의 일관성을 보장하기 위해

1.3 언제 Lock을 사용하는가?

• 사용해야 하는 경우!
  • 동시에 읽기/쓰기가 빈번하게 일어나는 중요한 테이블에 대해, 데이터 무결성을 엄격히 보장해야 할 때.
  • 은행 이체, 재고 관리, 주문 처리와 같이 동시에 발생하면 안 되는 시나리오를 제어할 때.
    

    

• 주의해야할 점!
  • 불필요한 락은 성능 저하를 유발할 수 있으므로, 적절한 수준에서 사용하는 것이 중요
  • DeadLock!!
    • DeadLock발생 여부를 꼭 확인해야함!

1.4 Lock의 생명주기

1.4.1 트랜잭션 시작!

• DB와의 트랜잭션을 시작
• 아직 특정 자원에 대한 락이 획득된 상태는 🙅

1.4.2 Lock 획득

1. 쿼리 요청
2. Lock 체크
3. 대기 혹은 Lock 획득

1.4.3 트랜잭션 종료

1. 트랜잭션 커밋 혹은 롤백
2. 락 해제

2. Lock 종류

2.1 낙관적 락 (충돌이 발생하지 않을 것이라고 가정)

• 데이터베이스의 락을 사용하는 것이 아닌 application 레벨에서 버전 관리
• 특정 작업을 수행하기 전에 별도의 락(lock)을 걸지 않고, 작업 완료 시점에서 데이터의 변경 여부를 확인하여 충돌 여부를 판단 (@Version 활용)
• 데이터 충돌이 거의 없을것이라고 가정한 경우 사용
  • LockModeType.OPTIMISTIC로 적용
• 충돌 시 ObjectOptimisticLockingFailureException 발생

2.2 비관적 락 (충돌이 자주 발생할 것이라고 가정)

2.2.1 공유락(Shared Lock, S Lock)

• 여러 트랜잭션이 동시에 데이터를 읽기할 수 있지만, 쓰기 하려면 공유락을 해제하고 배타락으로 변경
• 다른 트랜잭션이 쓰기하려 하면 대기 상태
  • LockModeType.PESSIMISTIC_READ로 적용

2.2.2 배타락(Exclusive Lock, X Lock)

• 오직 한 트랜잭션만 해당 데이터를 읽거나 쓸 수 있음
• 다른 트랜잭션이 접근하려 하면 대기 상태
  • LockModeType.PESSIMISTIC_WRITE로 적용

2.3 분산 락

• 여러 인스턴스나 분산 환경에서 락을 설정
• 데이터베이스에 직접 Lock을 걸지 않고, 외부에서 권한을 받아 처리
• Redis, **Zookeeper 등... 을 활용하여 적용**