지난 시간에 Spring Batch Architecture, Spring Batch Principles and Guidelines 그리고 Spring Processing Strategies 와 약간의 지식들에 대해 보았다.
너무 전략 부분이 쓸데없이 길었던것 같아서 중도에 읽다가 말았다.ㅠㅠ...
지극히 내 개인적인 생각으로는 아 이거 이렇게 해도 되나 싶을 때 다시 보면 될 것 같다.(너무 원론적이야!)
이번에는 배치의 도메인 언어 부분을 읽어볼 것이다.
그리고 읽는 와중에 이런 Job, JobLauncher같은 특별한 것들은 해석이 안된다. 그래서 되도록 본연의 개념을 더 알 수 있도록 영어로 그대로 적고자 한다. (영어 최고야 아잉!)
모든 경험있는 배치 설계자에게 스프링 배치에서 사용된느 배치 처리의 전반적인 개념이 익숙하고 편해야 한다.
Job과 Step으리고 ItemReader 와 ItemWriter로 불리는 개발자에게 제공되는 처리 유닛이 있다. 하지만 스프링 패턴, 작업, 템플릿, 콜백 그리고 이디엄(idioms) 때문에 다음과 같은 기회들이 있다.
- 관심사의 명확한 분리를 통한 중요한 개선
- 인터페이스로 제공된 명확하게 기술된 아키텍처 레이어와 서비스
- 간편하고 기본적인 구현으로 신속한 채택과 간편한 사용이 가능
- 상당히 향상된 확장성
다음 그림은 몇십 년 동안 사용되어온 배치 레퍼런스 아키첵처의 간단화된 버전이다.
배치 처리에서 도메인 언어를 구성하는 구성들의 개요를 제공한다.
이 아키텍처 프레임워크는 지난 몇 세대의 프랫폼들에서 수십년동안 구현되어오면서 검증되어온 청사진이다.
JCL 와 COBOL 개발자들은 C, C# 그리고 자바 개발자들처럼 개념에 쉽게 익숙해질 수 있다.
스프링배치는 레이어, 컴포넌트 그리고 기술적 서비스들의 물리적인 구현을 제공한다.
또한 복잡한 배치 어플리케이션을 간단한 생성을 처리하는데 사용되는 튼튼한 유지가능한 시스템으로 만들었고 매우 복잡한 처리 요구를 처리한다.(암튼 좋다는거!)
앞의 다이어그램은 스프링 배치의 도메인 언어를 구성하는 중요 컨셉들을 강조한다.
Job은 많은 스텝을 가졌고, 각각의 그 스텝들은 하나의 ItemReader, ItemProcessor 그리고 하나의 ItemWriter를 가지고 있다.(그림에 대해 설명중이다) Job은 JobLauncher에 실행되고 현재 실행중인 처리에 대한 메타데이터는 JobRepository에 저장되야 한다.
*메타 데이터?
메타데이터는 데이터에 대한 데이터입니다. 이는 파일, 이미지, 비디오, 웹 페이지 등의 콘텐츠에 대한 정보를 제공합니다. 예를 들어, 사진의 메타데이터는 촬영 날짜, 위치, 카메라 설정과 같은 세부 정보를 포함할 수 있습니다.
1. Job (잡)
이 섹션은 배치 잡의 개념과 연관된 정형화된 생각(stereotype)을 보여준다.
Job은 전반적인 배치 처리를 캡슐화한 엔티티이다. 다른 스프링 프로젝트처럼 흔하게, Job은 XML 설정(configuration) 파일 또는 자바 기반 설정과 둘 다 함께 연결되있다. 이 설정(configuration)은 아마 job configuration과 연관있을지도 모른다.
하지만, Jobdms 모든 계층의 유일한 상위다. 다음 그림에서 보듯이 말이다.
스프링 배치에서, Job은 간단하게 Step Instance의 컨테이너다. 논리적으로 한 흐름(flow) 에 함께 속한 다수의 step들을 결합하고 재시작성 같이 모든 스텝에게 속성 설정 기능을 제공한다.
잡 설정은 다음을 포함한다.
- Job 이름
- Step instance들의 순서와 정의
- Job의 재시작 할 수 있는지 없는지 여부
자바설정을 사용하는 사람들에게 스프링 배치는 Simple Job 클래스의 형식으로 Job 인터페이츠의 기본 구현체를 제공하는데 이것은 Job의 상위에 몇개의 표준 기능을 생성한다.
자바 기반 설정을 사용할 때 빌더의 모음(collection) 이 Job의 인스턴스화를 사용할 수 있도록 한다.
다음에서 보듯이 말이다.
@Bean
public Job footballJob(JobRepository jobRepository) {
return new JobBuilder("footballJob", jobRepository)
.start(playerLoad())
.next(gameLoad())
.next(playerSummarization())
.build();
}
위의 코드에서 잠시 설명을 더 하고 넘어가려고 한다.
우선 코드를 잘 살펴보자.
JobBuilder는 말 그래도 Job을 생성하는 Builder 로 현재 Job 생성을 Builder Pattern으로 하고 있다.
위의 설명에서 Job에서는 하나의 flow의 step들을 구성한다고 했다.
그럼 start(), next, next 하는 것이 순서대로step을 실행하는 것이다.
현재 세부적인 실행 순서나 step들의 구체적인 구현 정보는 없으나
위에서 설정한 잡 설정을 충족한다.
1. Job 이름, 2. Step instance들의 순서와 정의가 그에 해당한다.
(이름이 "footballJob", start에서부터 마지막 Step까지)
3.Job의 재시작 할 수 있는지 없는지 여부는 현재 없지만 추후에 보도록 하자.
2. JobInstance
JobInstance는 논리적인 잡 실행의 개념을 나타낸다.
배치 잡이 하루의 마지막에 한 번 실행되야 한다고 생각해보자. 앞의 다이어그램 처럼 EndOfDay Job 같이 말이다.
하나의 EndOfDay Job이 있지만 각각의 Job의 개인적인 실행은 부분적으로 추적되어야 한다.
이 Job의 경우에 매일 하나의 논리적인 JobInstance가 있다.
예를 들어, 1월 첫번째 작업, 1월 첫번째 작업 그리고 여러개가 있다. 만약 1월 첫번째 작업이 처음에 실패하고 다음날 다시 실행하면, 그건 여전히 1월 첫번째 작업이다. (일반적으로 이것은 1월 1일 실행이 1월 1일 데이터를 처리하는 것을 의미하며, 이것은 그것이 처리하고 있는 데이터와도 일치한다) 그러므로 각각의 JobInstance는 많은 실행을 가질 수 있다.
(JobExecution은 이 챕터의 나중에 더 논의된다.) 그리고 오직 하나의 JobInstance를 주어진 시간에 실행할 수 있다.
JobInstance의 정의는 절대적으로 적재된 데이터와 관계가 없다.
전반적으로 데이터가 어떻게 로드되는지 결정하는지는 ItemReader 구현체에 달려있다.
예를 들어,EndOfDay 시나리오에서 데이터가 속한 effective date 또는 schedule date를 나타내는 데이터의 컬럼이 있을 수 있다. 그래서, 1월 1일 실행이 첫째날로부터 데이터를 로드할 것이고 1월 2일 실행은 2일로 부터 데이터를 로드할 것이다.이 결정은 비즈니스 결정이 될 가능성이 있기 때문에 결정할 ItemReader에 달려 있다. 하지만 같은 JobInstance를 사용하는건 이전 실행의 상태가 사용됐는지 아닌지를 결정한다.
새로운 JobInstance를 사용하는 것은 처음부터 다시 시작하는 것을 의미하며 존재하는 instance를 사용하는건 그만둔 것을 시작한다 라는 것을 의미한다.
위를 간단하게 정리하자면...
JobInstance는 보통 한 번에 한 번 실행되며 job 실행시에 매번 새로운 JobInstance가 생성되서 실행된다.
간단히 정리하면 우리가 처리할 Job이 있고, 이것을 처리하기 위해 JobInstance가 생기는 것이다.
즉, 논리적인 Job 실행의 개념이라는 것이다.
Job을 새롭게 시작할 때 마다 JobInstance가 실행되고 데이터는 매번 실행마다 다른것이 다루어질 수 있다.
각 실행되는 JobInstance는 전에 실행되건, 혹은 나중에 생성되는 JobInstance들과는 별개라는 사실!
3. JobParameter
Job Instance와 Job과 어떻게 다른지에 대해 논의한 후, 자연스럽게 묻는 질문은 "한 Job Instance와 다른 Job Instance를 어떻게 구별할 수 있는가?"이다. 대답은 JobParamters다. JobParamters 객체는 배치 잡 시작에 사용되는 일련의 파라미터들을 가진다. 식별에 사용될 수 있거나 심지어 다음 그림처럼 실행 동안 레퍼런스 데이터로 사용될 수 있다.
앞의 예에서, 두 개의 인스턴스가 잇는데 1월 1일꺼 하나, 1월 2일꺼 하나인데 오직 하나의 Job이 있지만 두개의 파라미터객체를 가진다. 하나는 01-01-2017의 잡 파라미터를 가지고 실행된 것과 01-02-2017의 파라미터를 가지고 실행된 하나이다. 따라서 계약은 JobInstance = Job + Job Parameters 식별과 같이 정의할 수 있다.
이것은 개발자가 어떤 파라미터가 들어오는지 제어하기 때문에 어떻게 JobInstance가 정의되는지 효과적으로 제어하도록 한다.
* 주의!
모든 Job Parameter들이 JobInstance의 식별에 기여하는데 필요한 건 아니다. 기본적으로 그렇긴 하지만 프레임워크는 또한 JobInstance의 식별에 기여하지 않는 파라미터를 가지고 Job의 제출(submissison)을 허용한다.
(대게 Job Parameter가 있지만 없을수도 있다는 말이네!)
정리해보자면 JobParameter는 Batch Job 실행시 사용되는 파라미터로, JobInstance = Job + JobParameter 식별과 같이 정의된다고 한다. 여기서 JobParamter가 꼭 필요한건 아니라네!
다시 한번 정리하면... "Job Parameter는 배치 작업을 실행할 때 제공되는 외부 매개변수" 입니다!
4. JobExecution
JobExecution은 Job을 실행하는 한 시도의 기술적인 개념을 나타낸다.
실행(execution)은 성공하거나 실패할 건데 주어진 실행에 상응하는 JobInstance는 실행을 성공적으로 완료하지 않으면 완료라고 생각하지 않는다. 한 예로 이전에 묘사된 EndOfDay Job 을 사용하면, 실행때 처음 실패한 01-01-2017의 JobInstance를 생각해보자. 만약 처음 실행때 처럼 같은 job parametyer를 가지고 다시 실행하면, 새로운 Job Execution이 생성된다. 하지만, 여전히 하나의 JobInstance를 가진다.
Job은 job이 뭔지 정의하고 어떻게 실행될건지 정의하고 JobInstance는 순수하게 함께 실행할 것을 그룹핑한 조직적인 객체이며 주로 올바은 재시작 semantic이 가능하게 한다. 하지만 JobExecution은 실제로 실행동안 일어난 것에 대한 주요한 저장 메커니즘이고 제어되고 영속화 되어야 하는 더 많은 속성을 포함한다. 다음처럼 말이다.
| Property | Definition |
| Status | A BatchStatus object that indicates the status of the execution. While running, it is BatchStatus#STARTED. If it fails, it is BatchStatus#FAILED. If it finishes successfully, it is BatchStatus#COMPLETED |
| startTime | A java.time.LocalDateTime representing the current system time when the execution was started. This field is empty if the job has yet to start. |
| endTime | A java.time.LocalDateTime representing the current system time when the execution finished, regardless of whether or not it was successful. The field is empty if the job has yet to finish. |
| exitStatus | The ExitStatus, indicating the result of the run. It is most important, because it contains an exit code that is returned to the caller. See chapter 5 for more details. The field is empty if the job has yet to finish. |
| createTime | A java.time.LocalDateTime representing the current system time when the JobExecution was first persisted. The job may not have been started yet (and thus has no start time), but it always has a createTime, which is required by the framework for managing job-level ExecutionContexts. |
| lastUpdated | A java.time.LocalDateTime representing the last time a JobExecution was persisted. This field is empty if the job has yet to start. |
| executionContext | The “property bag” containing any user data that needs to be persisted between executions. |
| failureExceptions | The list of exceptions encountered during the execution of a Job. These can be useful if more than one exception is encountered during the failure of a Job. |
이 속성들은 중요한데 완벽하게 실행의 상태를 정의하는데 사용될 수 있고 영속화되기 떄문이다.
예를 들어, EndOfDay가 오후 9시에 01-01으로 실행 된고 오후 9시 30분에 실패한다면, 다음과 같은 entitiy가 배치 메타데이터 테이블에 만들어진다.
Table 2. BATCH_JOB_INSTANCE
| JOB_INST_ID | JOB_NAME |
| 1 | EndOfDayJob |
Table 3. BATCH_JOB_EXECUTION_PARAMS
| JOB_EXECUTION_ID | TYPE_CD | KEY_NAME | DATE_VAL | IDENTIFYING |
| 1 | DATE | schedule.Date | 2017-01-01 | TRUE |
Table 4. BATCH_JOB_EXECUTION
| JOB_EXEC_ID | JOB_INST_ID | START_TIME | END_TIME | STATUS |
| 1 | 1 | 2017-01-01 21:00 | 2017-01-01 21:30 | FAILED |
위에서 JobExecution은 Job을 실행하는 한 시도의 기술적인 개념을 나타낸다 고 했는데
이를 다시말하면 Job Execution은 배치 작업의 한 번의 실행을 나타낸다.
매번 실행할 때 마다 Job Execution 이 생성되는 것이다.
이번 시간에는 Job, JobInstance, JobExecution에 대해 알아보았다.
다시 정리를 하면 ..
Job은 전반적인 배치 처리를 캡슐화한 엔티티이고
JobInstance는 논리적인 잡 실행의 개념을 나타낸다.
또, Job Parameter는 배치 작업을 실행할 때 제공되는 외부 매개변수이고
Job Execution은 배치 작업의 한 번의 실행을 말한다.
용어에 주의하면서 학습을 하면 될 것이다.
출처:
https://docs.spring.io/spring-batch/docs/current/reference/html/domain.html#domainLanguageOfBatch