현재는 Spring Batch Application 개발을 대부분 개발을 하고 있어, 해당 프레임워크로 개발을 진행하면서 내 나름대로의 고찰을 정리해볼까 한다. 2 ~ 10 개 정도의 배치 애플리케이션을 개발을 하고 크게 늘어날 가능성이 없다면 이 내용을 따르지 않는 것이 더 효율적이라고 생각한다. 본 포스팅은 배치 애플리케이션을 주로 개발하며 그 배치가 요구 사항에 따라 지속적으로 늘어나는 경우에 해당하는 경우이다.
Job 한 개당 한 개의 Batch Application
1 | . |
현재 속해 있는 팀에는 전체 배치 애플리케이션은 150 ~ 250개 정도 되는 거 같다. 한 배치 애플리케이션에 Job들이 40 ~ 60 정도 있게 된다. 나의 주관적인 생각이지만 Job 한 개당 한 개의 애플리케이션이 유지 보수하기 좋다고 생각한다.
조금 다른 이야기이긴 하지만, 그동안 유지 보수 좋으며 확장성에 열려있는 구조를 갖기 위해서 많은 노력 및 학습을 진행을 해봤고 관련 내용으로 포스팅도 했다. 이러한 원칙들도 중요했지만 최근에 들어서는 이런 것들 보다 더 중요한 것은 애플리케이션의 크기를 작게 유지하는 하는 것이라는 것을 느끼게 되었다. 결국 애플리케이션이 커지면 앞서 했던 노력들은 물거품이 되기 쉽다고 생각한다.
최근 Job 한 개당 한 개의 Batch Application 개발을 진행하고 있으며 장단점이 있지만 장점이 압도적으로 많다고 생각한다.
단점
Jar 파일
기존 방식은 결국 한 개의 프로젝트에 여러 Job이(Bean)이 있는 형태로 1개의 Jar 파일로 job name 기반으로 여러 잡들을 실행하게 된다. 그렇게 되면 1개의 Jar 파일만 있으면 실행이 가능한 구조이다.
그러나 Job 한 개당 한 개의 Batch Application을 하게 되면 Jar 파일이 Job 개수만큼 증가하게 되며 이것을 관리해야 하기 때문에 가장 큰 단점이라고 생각한다.
테스트 빌드의 속도
기존 방식을 사용해서 배치 애플리케이션 테스트 코드를 작성하면 스프링 빈 컨텍스트를 여러 Job들이 공유해서 사용할 수 있게 된다. 물론 @MockBean, @TestPropertySource 등 Environment가 변경되면 스프링 빈 컨텍스트를 다시 띄우기는 하지만 이것은 논외로 하겠다.
기존 방식은 공유해서 사용하기 때문에 압도적으로 빠르다. 하지만 배치 애플리케이션을 분리하면 스프링 빈 컨텍스트를 공유할 방법이 없다. 서로 다른 애플리케이션이기 때문에 공유 자체가 말이 안 된다. 그러기 때문에 배치 애플리케이션 개수만큼 스프링 빈 컨텍스트를 띄우고 죽는 시간이 추가되며 전체 테스트 시간이 많이 발생한다.
장점
단점이 있지만 결국 모든 단점을 상쇄 시킬 만큼의 충분한 장점이 있다고 생각한다. 위에서도 언급했듯이 애플리케이션의 크기가 작게 유지할 수 있는 게 가장 큰 장점이다.
하나의 배치 애플리케이션의 수십 개의 Job 중 Job name으로 실행시키는 것은 거대한 모노릭틱 서비스와 같다. 아니 배치의 경우는 더 안 좋은 영향을 미친다. 모노리틱 같은 경우는 어쨌든 해당 기능을 수행하기 위해서 수많은 디펜더 시가 필요하다. 하지만 배치의 경우에는 한 개의 Job만 실행시키기 때문에 해당 Job의 디펜던시 외에는 필요가 없다. 그렇기 때문에 배치의 경우가 훨씬 더 독립적인 애플리케이션을 유지하는 게 좋다고 생각한다.
결국 애플리케이션을 독립적(작은 크기로)으로 유지하면 유지 보수, 아키텍트 구조 개선, 테스트 코드 작성 등등 다양한 이점들이 있고 실제로 이런 형태로 개발을 하고 있다.
Spring Data Flow
만약 배치 애플리케이션을 주로 만들고 그 개수가 지속적으로 늘어날 예정이라면 Spring Data Flow를 강력하게 권장한다.
Spring Cloud Deployer를 쿠버네테스를 지원하기 때문에 배치 애플리케이션에 대해서 배치 오케스트레이션의 편의성을 높게 가진다. 기조 배치 애플리케이션은 젠킨스를 이용해서 사용하는데 이러한 모든 것을 스프링 데이터 플로우에서 지원해 주며 배치 테이블에 있는 메타 정보에 대한 결과 화면을 제공해 준다.
