Batch 작업시 선행 조건 고려할사항, 배치 전략, Job 실행 환경 with SpringBatch

Batch 작업은 서비스 플랫폼 관점에서 오류검출이나 예외 처리하기 상당히 불편한 기능중 하나입니다.

그래서 선행조건으로 스케쥴 작업을 왜 해야하는지 어떤검토가 필요한지 알아보도록 하겠습니다.

 

Batch 검토 시 고려 사항

비지니스 관점으로 볼때, 고가용성(대용량, 매우빠른배치전략) 이 필요한지 검토

데이터 안정성이 꼭필요한지 유실되도 문제 없는지에 대한 검토

연속으로 순서가 보장되어야 하는 비지니스를 가지는 배치가 있는지 검토

개발자가 배치를 개발할때 편하게 생성하고 관리나 모니터링 오류등을 확인할수 있는지 검토

관련 비지니스가 꼭 배치로 작업이 되어야 하는지 검토

장기적인 관점에서 개선이 가능한 배치방향인지 검토

 

Spring Batch

Spring Batch 는 읽기, 처리, 쓰기 단위를 명확히 구분 하는 구조를 가지고 있기 때문에

약간의 학습으로 빠르게 Batch Job 생성이 가능하지만 트랜잭션 구성은 좀더 러닝커브가 존재합니다.

 

Step은 Tasklet 으로 Reader & Processor & Write 3가지 기능을 가지고 있는 묶음으로도 구성으로 가능합니다.

 

Spring Batch Job Step 구조

 

Spring Batch는 프로젝트 생성 만으로 동작하는 구조가 아님

Spring Batch가 동작과 관련된 정보를 담고 있는 메타 테이블이 필요

메타 테이블에는 아래와 같은 정보들이 저장됨

• 이전에 실행된 Job 상태
• 최근 성공, 실패에 대한 Spring Batch Parameter 정보
• 실행된 Job에 어떤 Step들 성공, 실패 했는지 정보
• 다시 실행 할 경우, 어디서 부터 실행해야 될지 시작 지점 정보

참고 : metaDataSchema.html

Appendix B. Meta-Data Schema

 

Batch 실행

Spring Batch를 통해서 비즈니스 로직이 만들어 졌다면,

특정 상황에 맞게 배치가 실행될 수 있도록 실행 환경이 구성되어 있어야 합니다.

 

Batch Job 일 실행시키는 스케쥴 라이브러리에 대해서

가볍게 장단점을 정리해 보도록 하겠습니다.

Spring @Scheduled	Jenkins
장점 특정 인프라와 상관없이 실행 환경을 구성할 수 있음 Process가 아닌 Spring Thread Pool 환경에서 동작 빠르게 개발하기 용이함	장점 개발자에게 친숙한 관리 환경 다양한 Job 실행 환경 제공 수동으로 Job 재실행 A Job 성공하면 B Job 이어서 실행(Job Trigger) 다양한 플러그인 지원 풍부한 생태계(국내 노하우가 많음) 파이프라인을 통한 Job 배치 실행 순서 관리 Pipeline script를 통해 Loop 실행 가능
단점 단일 인스턴스에서 멀티 스레드 환경에서 동작하기 때문에 OOM(Out of Memery) 이슈 발생 위험 존재 멀티 인스턴스 생성을 통한 스케일 아웃 용이하지 않음(코드 수정을 통한 수동 처리 필요) 실패에 대한 처리 방안을 추가 고려 해야 함(Quiz, spring batch meta db ..etc)	단점 아주 작은 단위 배치에서는 적합하지 않음 관리 환경 UI 빈약함 Job 실행 이력에 대해서 단순히 log만 저장함(빈약한 실행 인력 관리) 다양한 플러그인이 존재하나 오픈소스인 것이 많아 검증되지 않음 파일 기반의 설정 정보 설정 정보 백업 및 이중화 작업이 어려움

TeamCity	Spring Cloud Data Flow(SCDF)
장점 JetBrains의 제품군으로 통합이 용이함 설정 정보를 DB로 관리하여 백업 및 이중화가 용이함	장점 Spring 제단에서 공식적으로 지원됨 Spring Batch, Data Stream 매니저 도구로 나온 제품으로 특화됨 오픈 소스로 외국 커뮤니티 많음 CloudFound, Kubernate 환경에 특화 되어 있어 대량의 작업이 용의함
단점 일정 규모 이상은 유료 버전으로 라이센스 구매 필요 CI/CD 도구이기 때문에 배치 스케쥴에 특화되어 있진 않음 플러그인 생태계가 Jenkins에 비해 약함	단점 국내에서는 도입된 사례가 적어서 운영 노하우 및 커뮤니티가 많지 않음 배치 목적보다는 클라우드 환경에 대해 런닝 커브가 존재하기 때문에 허들이 높음 다양한 SCDF 효과를 누리려면 배치 프로세스를 도커 이미지로 관리하기 때문에 추가적인 부수 작업이 존재함(기술적 운영적 런닝커브 존재) Stream등을 사용하려면 배치 환경 구성이 어려움

 

Batch 실행 전략

스스로 실행되는 배치

• URL 요청 등에 빠르게 대응하기 위해서 미리 캐시에 넣어 놓고 실행되는 형태
  • 특정 시간에 스스로 활성화 되어 캐시를 만들어 줌
  • 스스로 동작하는 형태 이므로 외부에서 요청되는 형태가 아님
  • 미리 실행에 필요한 데이터가 준비된 형태로, 배치 실행 중에 준비된 데이터는 거이 변경되지 않음
  • 준비된 데이터를 기준으로 배치 실행시 매번 새로운 데이터가 생성 혹은 수정되는 형태
• 배치 실행 시간이 비교적 짧음
• 중복된 실행에도 크게 리스크가 없음
  
  

외부 요청에 따라 실행되는 배치

• 외부 요청에 의해서 데이터가 취합되고, 취합된 데이터를 기준으로 실행되는 형태
  • 취합된 데이터 자체가 실행된 배치에 의해서 변경될 수 있으며, 배치 실행이 길어 질 수 있음
• 매번 실행될 때 결과가 다를 수 있음
• 실패시 재 요청에 대한 전략이 필요함

특정 조건이 만족되어서 선행 배치 실행 후에 다음으로 실행되는 배치

• 특정 조건 예를 들어 서버에 가용자원에 80% 이상일경우 사용되지 않은 파일 자동백업 폴더 이동 및 파일 삭제

 

Batch 작업시 
진짜 중복 코드(True Duplicate) VS 현재 상황에서 어쩔수 없이 발생되는 중복(Accident Duplicate)

 

 

	True Duplicate	Accident Duplicate
이론	개발을 진행하다 발생하는 중복 코드를 의미 하며, 시간이 지나 비즈니스가 발전하게 되면, 지속적인 문제를 만들기 때문에 중복을 제거하는 것을 목적으로 리팩토링을 진행해야 하는 현상을 의미함	예기치 않게 성격이 다른 여러 프로젝트에서 중복되는 코드로 이 중복되는 코드를 제거 하려면 오히려 많은 노력이 들게 되며, 중복된 코드로 시작했지만 시간이 지나면서 많은 유지 보수나 비즈니스 복잡도가 올라가게 되면 점차 중복되던 코드가 희미하게 다른 코드를 가지게 되는 현상을 의미함
상황	보통 레거시 코드에서 많이 발생하며, 현재 코드가 어느 부분까지 영향을 미치는지 알지 못하여, 같은 코드를 복사해서 만들면서 발생함	여러 프로젝트에 걸쳐서 데이터를 가볍게 다루는 value 성격의 코드는 중복 제거하는 것은 쉬울 수 있으나 비즈니스 코드가 있는 경우, 같은 중복 코드이나 성격이 다른 프로젝트에서 전혀 다른 목적을 가지고 쓰일 수 있기 때문에, 중복을 제거하는 것이 매우 힘들어 오히려 중복되는 것이 효율적일 수 있음

웹 어플리케이션과 배치

중복된 코드를 바라보는 관점에서 배치의 코드와 웹 어플리케이션 코드가 중복될 수 있으나,

이는 Accident Duplicate일 가능성이 상당이 큼,

또한 같은 프로젝트 상에서 위와 같은 코드만 관리 되는 것이 아니라

환경 설정 정보( 멀티 DB리소스 설정, API 연동 등) 등에서

매우 다르게 적용될 가능 성 있으므로 하나 프로젝트에서 멀티 모듈로 관리하게 되면

다양한 관리 이슈가 발생할 수 있을 것으로 생각됨

 

	멀티 모듈에 포함된 배치	단독으로 구성한 배치
장점	같은 프로젝트 상에서 모듈로 분리 되어 있기 때문에 언제든 배치 작업 코드 생성이 쉬움 한 프로젝트 상에서 모든 배치들을 관리하기 때문에 같은 Context 상에 있는 배치들은 설정이 용이 할 수 있음	독립된 환경으로 구성된 배치를 사용하므로 배포가 자유로움 일반적으로 단일 행동을 하는 배치가 많기 때문에 필요에 맞게 단독으로 프로젝트를 생성하기 용이함
단점	독립적으로 분리 되지 않았기 때문에 시간이 지나면서 설정 정보와 코드가 믹싱될 가능성이 높음 특히 Service 영역에서 믹싱 발생율이 높음 극단적으로 관리되지 않으면 프로젝트가 혼돈스러워 질수 있음 단일 행동을 하는 배치가 여러개 생성이 필요한 경우, 배치 모듈이 여러개 이거나, 여러개의 패키지로 구성해서 관리해야 하기 때문에 유지보수에 어려움이 생길수 있음 독립된 환경으로 구성된 배치를 사용하므로 배포가 자유로움 일반적으로 단일 행동을 하는 배치가 많기 때문에 필요에 맞게 단독으로 프로젝트를 생성하기 용이함	중복된 코드 발생 가능 성 있음(Accident Duplicate) 설정 중복을 피하기 위해서는 독립적인 환경(spring-config 등) 고려 필요