최근 Spring Batch에 대한 사내 기술 지원 업무를 진행하면서 고민했던 것이 "Batch Job을 어떻게 배포할 것인가?"였다. Batch Job을 잘 개발하는 것도 중요하지만 어떻게 배포하느냐에 따라서도 운영 비용이 크게 차이가 날 수 있기 때문이다. Batch Job을 배포하면서 Batch 모니터링 툴도 어떻게 배포하는 것이 좋을지에 대한 고민도 같이 하게 되었다. 이 같은 고민을 하면서 배포 유형을 어떻게 가져갈 수 있을까에 대하여 정리해 봤다.

• Batch 관리툴이 있는 경우
  • Batch Job과 Batch 관리툴을 분리하여 운영한다.
  • Batch Job과 Batch 관리툴을 통합하여 운영한다.
• Scheduler 유형에 따른 경우
  • 시스템 Crontab 기능을 활용한다.
  • Quartz와 같은 Scheduler Framework를 활용한다.
• Batch Job의 분리 유무
  • 각각의 Batch Job을 분리하여 관리하는 경우
    • 단독 Application으로 만들어서 운영
    • 웹 컨테이너 또는 OSGi 컨테이너 기반으로 운영
  • 각각의 Batch Job을 통합하여 관리하는 경우
    • 단독 Application으로 만들어서 운영
    • 웹 컨테이너 또는 OSGi 컨테이너 기반으로 운영

생각할 수 있는 모든 방법을 고려하다보니 경우의 수가 무지 많다. 위 각각의 방법으로 Batch Job을 관리할 때의 장,단점을 살펴보면 다음과 같다.

Batch Job과 Batch 관리툴 분리 vs 통합

Batch 관리툴이 필요없다면 이에 대한 고려는 필요 없겠지만 Batch 관리툴이 필요한 경우에는 어떻게 운영하는 것이 좋을지에 대하여 고려해야 한다.

Batch Job과 Batch 관리툴 통합

Batch Job과 Batch 관리툴을 통합해서 관리해야 할 경우의 장점은 운영할 때 고려해야 하는 요소가 하나 줄어든다는 것이다. 이와 같이 통합해서 운영하는 경우는 각각의 Batch Job을 독립적으로 운영할 만큼의 대용량 Batch Job이 아니고, 운영을 쉽게 하는 것이 목적인 경우 유용한 접근 방법이다. 따라서 이와 같은 판단을 하는 경우 Batch 관리툴과 모든 Batch Job을 하나의 웹 컨테이너를 통하여 관리하는 경우가 일반적이다.
Batch Job과 Batch 관리툴을 통합해서 운영할 경우 Batch Job과 Batch 관리툴이 의존 관계가 있기 때문에 각각에서 문제가 발생할 경우 다른 영역에 영향을 미칠 수 있다. 또한 Batch Job과 Batch 관리툴에 변경이 발생했을 때 독립적으로 배포하기 힘들다.

각각의 Batch Job의 크기가 작고, 실행에 큰 부담이 없다면 운영의 편의성을 위해서 이 방법을 선택하는 것이 좋을 것으로 생각한다. 특히 Batch Job이 많지 않은 상황에서는 이 방법으로 운영하고 문제가 발생하는 경우 이후 분리하는 것도 좋은 전략이다.

Batch Job과 Batch 관리툴 분리

앞의 통합과는 반대로 독립적인 배포 및 운영이 가능하지만 관리해야할 부분이 늘어나기 때문에 운영 비용이 증가한다. 이 방법은 대량의 Batch 작업을 해야 하는 경우와 Batch Job과 Batch 관리툴의 의존 관계를 만들지 않고자 할 때 선택할 수 있는 좋은 전략이라고 생각한다.

각 Batch Job 분리 vs 통합

각각의 Batch Job을 분리해서 관리하느냐 통합해서 관리하느냐도 앞의 Batch 관리툴의 분리와 통합과 같은 전략으로 접근할 수 있다. 각 Batch Job의 독립성이 중요하고 실행 비용이 크다면 분리하는 것이 바람직한 선택이며, 그렇지 않은 경우에는 통합해서 관리하는 것이 운영 비용을 줄이기 위하여 좋은 선택이 될 수 있다.

Crontab과 Scheduler Framework(예. Quartz)

Batch Job을 실행하기 위하여 Scheduler 기능을 활용해야 하는데 일반적으로 Crontab과 Scheduler Framework를 이용하는 경우가 많다. 각각의 장,단점에 대하여 살펴보면 다음과 같다.

Crontab은 crontab 명령을 이용하여 쉽게 Scheduler를 등록하는 것이 가능하다. 또한 Scheduler와 Batch Job이 분리되어 있기 때문에 Scheduler에 변경이 발생하는 경우 Batch Job과 독립적으로 시간을 변경할 수 있다. 하지만 Batch Job과 같이 관리되지 않기 때문에 서버를 이전하는 경우나 운영 담당자가 바뀌는 경우 누락하는 경우가 많다. Batch 관리툴까지 없는 상태라면 Batch Job이 실행되지 않아서 버그나 장애가 발생하는 경우를 종종 경험한다.

Quartz와 같은 Scheduler Framework는 Batch Job과 같이 소스 코드를 관리하고 배포 단위를 같이 가져갈 수 있기 때문에 Batch Job을 운영하기 위해서는 좋은 선택이지만, 시간이 변경되는 경우 설정을 변경하고 소스를 재배포해야 하는 불편함이 있으며, 개발자가 새로운 API를 익혀야하는 부담이 있다.

하지만 Batch Job을 운영해 본 경험으로 봤을 때 새로운 API에 대한 학습 비용과 소스 코드 재배포에 대한 비용보다는 장애가 발생하지 않도록 운영하는 것이 운영자의 입장에서는 더 중요하기 때문에 가능하면 Crontab 보다는 Scheduler Framework를 활용하는 것이 더 좋은 선택이지 않을까 생각한다.

위와 같이 각각에 따른 장,단점이 있기 때문에 Batch Job과 Batch 관리툴에 대한 배포 전략은 다음과 같이 가져가는 것이 좋지 않을까?

• 대용량의 Batch Job이 없고, 운영 비용을 줄이는 것이 목적이라면 Batch 관리툴, 모든 Batch Job을 하나의 웹 컨테이너에 배포하여 관리한다. 만약 대용량 Batch Job이 발생한다면 해당 Batch Job에 대해서만 독립적으로 관리한다.
  • Batch Job과 Batch 관리툴을 개발해 보면 각각의 개발 환경이 다른 경우가 많다. 따라서 개발은 모듈로 분리하여 개발하고 배포만 같이하는 전략도 좋은 선택이 될 수 있다.
• 각 Batch Job 간의 독립적인 배포 및 운영이 중요하다면 각 Batch Job과 Batch 관리툴을 분리하여 배포한다.
• Batch Job에 대한 Scheduler는 가능한 Quartz와 같은 Scheduler Framework를 활용하고, 각 Batch Job 기준으로 관리하여 분리할 필요가 있을 때 분리하기 용이하도록 한다.

위와 같이 Batch Job과 Batch 관리툴에 대한 배포 전략을 수립하고 나서 좀 더 좋은 방법이 없을까 고민하다가 OSGi 컨테이너인 Spring DM Server에 눈길을 돌리게 되었다. Spring DM Server라면 각 Batch Job별로 Stop, Start, 재배포가 가능하지 않을까 생각하면서 접근하기 시작했다. 이렇게 해서 Spring DM Server에 배포할 Batch Job Bundle을 만들고 삽질을 한 결과 내가 원하는 형태로 배포하는 것이 가능하다는 결론을 얻었다. Spring DM Server에 Batch Job을 배포할 경우 얻게 되는 장,단점은 다음과 같다.

장점

• 서버 운영 중에도 각 Batch Job 별로 소스를 배포하는 것이 가능하다.
• 서버 운영 중에 각 Batch Job 별로 Batch의 Stop, Start가 가능하다.
• Batch Job이 실행 중에 Stop을 실행할 경우 Batch Job이 완료되는 것을 보장해 준다.

단점

• Batch Job을 OSGi Bundle로 만들어야 하기 때문에 학습 비용이 발생한다.
• Spring DM Server에 대한 운영 노하우가 없어 이 또한 학습 비용과 경험이 필요하다.
• 단순한 Batch Job을 개발하는 경우 복잡도가 너무 높을 수 있다.

Spring DM Server를 활용할 경우 좋은 점도 많지만 아직 경험이 많지 않다는 것과 작은 Batch Job까지 OSGi Bundle로 만들 필요가 있을까라는 생각이 든다. 아직 경험이 없는 상태라 그럴 수 있지만 기술적인 욕심 때문에 쉽게 풀 수 있는 문제를 너무 어렵게 접근하는 것은 아닌가라는 의구심을 가지게 되었다.

아직 Spring DM Server에 대한 운영 노하우가 없어 실무에 바로 적용하기는 힘들겠지만 경험이 쌓이고, 운영 노하우가 생긴다면 가져갈만한 전략이라고 생각한다. 현재로서는 Spring Dynamic Module로 개발하는 것이 익숙하지 않기 때문에 많은 삽질을 해야겠지만 경험이 축적되고 모듈 기반으로 개발해 재사용성을 높이는 노하우를 쌓는다면 장기적인 관점에서는 좋은 선택이 되리라 생각한다.