Spring Batch (10) @JobScope, @StepScope

🔗  Spring Batch @JobScope, @StepScope

지난 포스팅에서는 JobParametersValidator에 대해 살펴보았는데요 간략히 정리해보면 다음과 같습니다.

• Job 실행 시 필수적인 파라미터를 검증하는 역할입니다.
• 기본적으로 DefaultJobParametersValidator 구현체를 지원하며, JobParametersValidator 인터페이스를 직접 구현하여 파라미터를 검증할 수도 있습니다.

 

이번에 정리할 @JobScope, @StepScope는 지난 Spring Batch Job 포스팅에서 JobParameters를 받을 때 간략히 사용을 했었습니다.

• 코드로 생성 : JobParameterBuilder
• SPEL 사용 : @Value(“#{jobParameter[requestDate]}”) - @JobScope, @StepScope 선언이 필수
  
  • @JobScope, @StepScope는 Job, Step이 실행되는 시점에 Bean이 생성되도록 Bean의 생성시점을 지연시키는 역할을 합니다. @Value 어노테이션의 경우 애플리케이션이 실행될 때 바인딩을 하기 때문에 @JobScope, @Stepcope 어노테이션이 존재하지 않으면 NullPointerException 예외가 발생합니다.

이번 포스팅에서는 조금 더 자세히 살펴보겠습니다.

 

 

🔗  기본 개념 및 파라미터 설정

1. Scope

• Scope는 스프링 컨테이너에서 Bean이 관리되는 범위를 뜻합니다.
• 종류는 singleton(default), prototype, request, session, application이 존재합니다.
  • 각 종류는 Bean 정의에 대해 스프링 컨테이너 내에 단 하나만 존재하는지(singleton), 다수가 존재하는지(prototype), 라이프 사이클이 Http Request인지 등의 특징을 가지고 있습니다. 
  • 자세한 내용은 해당 포스팅을 참고해 주세요.

2. Spring Batch Scope (@JobScope, @StepScope)

• Spring Batch Scope는 Job, Step의 Bean 생성 및 실행에 관여하는 Scope입니다.
• 프록시 모드를 기본값으로 가지는 Scope 입니다.

• 해당 스코프가 선언되면 빈의 생성이 애플리케이션 구동 시점이 아닌 Bean의 실행 시점에 이루어집니다(Lazy Binding)
  
  • 즉 Job, Step이 실행되는 시점에 Bean이 생성되는데요, 이는 @Value 어노테이션의 경우 애플리케이션이 실행될 때 바인딩을 하기 때문에 Scope를 통해 생성시점을 지연시켜 바인딩이 이루어집니다.
  • 아래처럼 SpEL 표기법으로 선언해서 사용할 수 있습니다.

@Value("#{jobParameters[파라미터명]}") , @Value("#{jobExecutionContext[파라미터명]}")

 

• 프록시 모드로 Bean이 선언되기 때문에 애플리케이션 구동 시점에는 Bean의 프록시 객체가 생성되고, 메서드 실행 시점에서 실제 빈을 호출합니다. (AOP)
• 병렬처리 시 각 스레드마다 생성된 스코프 빈이 할당되기에 Thread-safe하게 실행이 가능합니다.

3. @JobScope

• Step 선언문에 정의합니다.
• @Value: jobParameter, jobExecutionContext만 사용이 가능합니다.

4. @StepScope

• Tasklet이나 ItemReader, ItemWriter, ItemProcessor 선언문에 정의합니다.
• @Value: jobParameter, stepExecutionContext 사용이 가능합니다.

 

 

🔗  예제코드

Step에는 @JobScope 선언과 @Value(jobParameters)를 선언하였고, Tasklet에는 @StepScope와 @Value(jobExecutionContext)를 선언해 주었습니다.

 

jobParameters는 실행할 때 인자로 값을 주입하여 받고, jobExecutionContext는 아래 사진처럼 커스텀 Listener 파일을 생성하여 값을 설정하겠습니다.

 

JobListener 클래스를 하나 생성하여 JobExecutionListener 클래스를 구현하고, 잡을 실행하기 전(beforeJob) jobExecutionContext에 "name" : "Lee" 의 값을 put 합니다.

 

프로그램 실행 인자(Program Arguments): --job.name=scopeJob message="JuHyuns"

 

결과를 확인해보면 기존에 설정한 값들이 정상적으로 출력되는 것을 확인할 수 있습니다.

 

만약 @JobScope를 주석 처리하고 실행해 보면 JobParameters가 생성되지 않기 때문에 오류가 발생합니다.

 

 

🔗  아키텍처

1. Proxy 객체 생성

• @JobScope, @StepScope 어노테이션이 선언되면 내부적으로 Bean의 Proxy 객체가 생성됩니다.
• 즉, Job 실행 시 Proxy 객체가 실제 빈을 호출해서 해당 메서드를 실행시키는 구조입니다.

2. JobScope, StepScope

• Proxy 객체의 실제 대상이 되는 빈을 등록하고 해제하는 역할을 합니다.
• 실제 빈을 저장하고 있는 JobContext, StepContext를 가지고 있습니다.

3. JobContext, StepContext

• 스프링 컨테이너에서 생성된 빈을 저장하는 컨텍스트 역할을 합니다.
• Job의 실행 시점에서 Proxy 객체가 실제 빈을 참조할 때 사용됩니다.

4. 스프링 애플리케이션 구동 ~ @Value 바인딩이 처리되기까지의 과정

@JobScope, @StepScope 아키텍처

1. 애플리케이션이 구동되면 스프링의 ApplicationContext가 Bean을 생성하고 관리하는 역할을 합니다.
2. @JobScope (혹은 @StepScope) 어노테이션이 존재하는지 확인합니다.
   • 존재하지 않는다면 기본적인 싱글톤 Bean을 생성하고, @Value 어노테이션 선언 시 오류가 발생합니다.
   • 존재한다면 해당 Bean의 Proxy 객체를 생성합니다.
   • @Scope(value = "job", proxyMode = ScopedProxyMode.TARGET_CLASS)
3. 설정이 끝나면 스프링 초기화가 완료되고 Job을 실행합니다. (JobLauncher)
4. Job은 Step의 실제 Bean이 아닌 Proxy 객체를 저장하고 있습니다.
5. 프록시 객체는 실제 Step 메서드(scopeStep1)를 호출할 때 실제 Bean 객체를 참조하고 이 시점에 Step Bean이 생성됩니다.
6. 5.에서 프록시 객체가 실제 메서드를 호출할 때 참조할 Bean을 JobScope에서 찾습니다. (JobScope는 JobContext를 통해 찾습니다.)
7. JobContext에서 실제 Bean이 존재하면 Bean을 꺼내 참조하여 실제 Step을 실행합니다.
8. JobContext에서 실제 Bean이 존재하지 않으면 스프링의 BeanFactory를 통해 실제 Step을 생성하고, 이 시점에서 실제 scopeStep1() 메서드를 호출해서 Bean을 생성합니다. 또한 @Value 바인딩 처리도 같이 진행이 됩니다.
9. 그 후 생성된 Step Bean을 JobContext에 저장하고, 이후에는 JobContext에서 Bean을 바로 꺼내어 사용할 수 있습니다.

5. 내부 코드

JobScope, StepScope 모두 내부 로직은 비슷하기에 JobScope의 코드만 살펴보겠습니다.

AbstractBatchConfiguration 추상 클래스 내부에 존재하는 ScopeConfiguration 클래스에서 StepScope, JobScope를 생성합니다.

 

위 코드에서 @Configuration(proxyBeanMethods = false)로 설정이 되어있는데요, 이는 프록시를 적용하지 않고 중복 코드에 의해 동일한 인스턴스가 생성되더라도 싱글톤으로 생성하지 않습니다. 

관련해서는 아래 링크들을 참고해 주세요.

• https://stackoverflow.com/questions/61266792/when-to-set-proxybeanmethods-to-false-in-springs-configuration
• https://sujl95.tistory.com/69
• https://mangkyu.tistory.com/234

 

JobScope

JobScope 클래스의 get() 메서드에서 JobContext를 통해 Bean이 존재하는지 확인합니다.

Bean이 존재하지 않을 경우 생성 & 저장을 하고, 존재할 경우 Bean을 가져와 바로 리턴합니다.

 

 

26라인에서 Job의 start() 메서드에서 Step 호출 시 실제 Step이 아닌 Proxy가 생성됩니다.

 

 

 

SimpleStepHandler

위 115라인의 step.getName() 메서드를 호출하는 순간 Proxy 객체가 참조할 실제 Bean을 생성합니다.

(위 step은 실제 메서드를 호출하기 전이므로 Proxy 객체입니다.)

 

(좌) JdkDynamicAopProxy.invoke / (우) AbstractStep.getName()

step.getName() 메서드를 호출해 보면 AbstractStep 추상 클래스의 getName() 메서드를 호출해야 하지만 Proxy 객체이므로 JdkDynamicAopProxy 클래스의 invoke() 메서드를 호출합니다. 

 

JdkDynamicAopProxy

Proxy의 targetSoucre가 실제 Bean인 scopeStep1을 확인할 수 있습니다.

 

 

JdkDynamicAopProxy.invoke()

JobScope

Proxy에서 실제 참조할 Bean을 구할 때(위 사진, 195라인) 필요한게 JobScope입니다.

 

 

JobScope

JobScope의 get() 메서드에서 최초 Job 호출 시 JobContext 내에 실제 Bean이 존재하지 않으므로 185~186 라인을 통해 Bean을 생성하고(185 라인), JobContext에 실제 Bean을 저장(186 라인)합니다. 

또한 이때 실제 Step인 scopeStep1() 메서드를 호출합니다.

 

 

하지만 현재 저의 상황은 Job을 처음 실행한 게 아닌 두 번째 실행한 상황이므로 인자인 name에 해당하는 실제 Bean을 JobContext에서 바로 가져온 후 리턴하고, 이후 AbstractStep 추상 클래스의 getName() 메서드를 호출하고 값을 얻습니다.

 

 

이상으로 @JobScope, @StepScope에 대해 살펴보았습니다.

정리하면서도 어려운 내용도 많았고, 잘못 작성한 내용이 있을수도 있습니다...😂

 

다음부턴 Spring Batch에서 청크 프로세스 방식에 대해 정리해보겠습니다.

 

 

참고 문서

• https://docs.spring.io/spring-batch/docs/current/reference/html/index-single.html#late-binding
• https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B0%B0%EC%B9%98/dashboard