Kubernetes 환경에서 J-Jobs를 활용하는 4가지 업무 패턴

목차

1. 들어가며
2. 왜 Container 환경에서도 J-Jobs가 필요한가
3. 패턴 1. 시간 기반 반복 k8s Job 템플릿 실행
4. 패턴 2. REST API 호출 기반 업무 실행
5. 패턴 3. S3 파일 수신 시 후행 Job 실행
6. 패턴 4. 대량 데이터를 분할해 다수 Pod로 병렬 처리
7. 패턴 비교
8. 마무리

들어가며

Container/Kubernetes 환경으로 업무 실행 기반이 이동하면, 기존의 배치나 연계 업무도 자연스럽게 Pod 단위로 재구성하게 됩니다. 다만 Pod를 잘 띄운다고 해서 스케줄링, 선후행 제어, 운영 이력 관리, 승인, 알림 같은 운영 요구까지 함께 해결되는 것은 아닙니다.

LG CNS가 개발한 Workload Automation 제품인 J-Jobs는 이런 지점에서 여전히 유효합니다. Kubernetes가 실행 환경을 담당한다면, J-Jobs는 업무 실행 제어와 운영 관점의 상위 오케스트레이션 계층으로 역할을 맡을 수 있습니다.

이 글에서는 Container 환경에서 J-Jobs를 활용할 때 실무에서 자주 검토하게 되는 4가지 구성 패턴을 정리합니다. 예시는 AWS와 Kubernetes를 기준으로 설명하지만, 핵심 아이디어는 다른 Container 환경에도 동일하게 적용할 수 있습니다.

왜 Container 환경에서도 J-Jobs가 필요한가

Kubernetes는 실행 환경을 제공하지만 업무 운영 체계까지 완결해 주지는 않으며, J-Jobs는 그 간극(스케줄링·선후행 제어·이력 관리·승인·알림)을 메우는 상위 오케스트레이션 계층 역할을 합니다. 두 계층의 강점과 빈 곳을 나눠 보면 다음과 같습니다.

Kubernetes는 다음 영역에서 강점이 있습니다.

• 애플리케이션 배포와 교체
• Pod 수평 확장과 자원 격리
• 장애 복구와 선언적 운영

반면, 기업 업무 운영에서는 여전히 다음 요구가 별도로 존재합니다.

• 정해진 시각 또는 조건에 따라 업무를 실행해야 합니다.
• 업무 간 선후행과 실패 처리 규칙이 필요합니다.
• 운영자가 실행 이력과 로그를 한 화면에서 확인해야 합니다.
• 재실행, 승인, 알림 같은 운영 절차가 필요합니다.

즉 Kubernetes만으로는 실행 환경은 마련되지만, 업무 운영 체계까지 완결되지는 않습니다. J-Jobs는 이 간극을 메우는 역할로 배치하는 것이 현실적입니다.

패턴 1. 시간 기반 반복 k8s Job 템플릿 실행

기존 레거시 환경에서 로컬 서버의 Shell Script를 정해진 시각마다 수행하던 방식을, 별도 Job Pod를 호출하는 구조로 전환하는 패턴입니다. J-Jobs가 스케줄을 관리하고, 실제 업무는 Docker image로 패키징된 k8s Job이 수행합니다.

위 그림은 J-Jobs가 정해진 스케줄에 따라 k8s Job 템플릿을 실행하고, Kubernetes가 일회성 Job Pod를 생성해 업무를 수행한 뒤 로그와 상태를 다시 J-Jobs 운영 화면으로 연결하는 구조를 표현합니다.

J-Jobs에는 kubectl 기반으로 k8s Job 을 제어하는 템플릿이 제공되며, Job 생성, 모니터링, 중지, 로그 추적까지 수행할 수 있습니다. 즉 기존 서버 로컬 환경에 스크립트와 실행 환경을 미리 올려두는 대신, 업무 코드와 실행 환경을 함께 담은 Docker image를 기준으로 작업 단위를 분리할 수 있습니다.

구성 개요

• J-Jobs가 정해진 시각이나 반복 일정에 따라 k8s Job 템플릿을 실행합니다.
• 생성된 k8s Job은 업무 수행용 Job Pod를 생성하고, 작업 완료 후 종료합니다. Job Pod는 Docker Image로 생성되며 업무 수행에 필요한 Shell Script, 바이너리, 라이브러리를 포함하고 있습니다.
• J-Jobs는 Job 상태를 추적하고 표준출력 로그를 수집해 운영자가 Manager 화면에서 확인할 수 있게 합니다.

추천 적용 대상

• 기존 서버 로컬에 있던 Shell Script 기반 배치 업무를 Container 방식으로 전환하려는 경우
• 업무 수행 자원을 상시 확보하지 않고, 실행 시점에만 Job Pod를 생성하고 싶은 경우
• 호출 빈도가 아주 높고 수행 시간이 짧은 업무보다는, 실행 단위 격리와 환경 독립성이 더 중요한 업무
• 스크립트와 실행 환경 의존성이 강해 image 단위로 배포하는 편이 더 관리하기 쉬운 경우

장점

• 배치 업무를 수행할 자원을 미리 확보하고 있을 필요가 없습니다.
• 클라우드 과금 환경이라면 실행한 만큼만 비용이 발생하는 구조로 설계할 수 있습니다.
• 실행마다 독립된 Job Pod를 사용하므로, 업무 간 환경 충돌을 줄이고 재현 가능한 실행 단위를 만들기 쉽습니다.
• 업무 코드와 실행 환경을 image로 함께 관리할 수 있어 서버 간 환경 차이를 줄일 수 있습니다.
• J-Jobs가 스케줄, 실행 이력, 선후행 제어를 담당하고 Kubernetes는 실제 실행 자원을 담당하므로 역할 분리가 명확합니다.

패턴 적용 시 체크 포인트

• namespace는 J-Jobs 사용자 그룹 설정과 연결되어 동작하므로, 업무별 namespace 운영 기준을 먼저 정해야 합니다.
• Job명 충돌을 피하기 위한 네이밍 규칙이 필요합니다. 실행 ID를 붙이는 난수화 옵션을 사용할 경우 이름 길이 제약도 함께 고려해야 합니다.
• 리소스 제한, PVC, Service Account, imagePullSecrets, restartPolicy, backoffLimit 같은 Job 옵션을 운영 기준에 맞게 표준화하는 편이 좋습니다.
• J-Jobs는 kubectl 명령어 기반으로 로그를 추적하므로, 표준출력 로그 기준으로 운영 로그를 남기도록 설계하는 편이 유리합니다.
• 이전 실행 Job 정리 여부, 재시작 정책, 실패 시 재처리 기준을 업무 특성에 맞게 정해야 합니다.

패턴 2. REST API 호출 기반 업무 실행

가장 단순하면서 적용 범위가 넓은 방식입니다. Spring Boot 기반 업무 애플리케이션을 Kubernetes Deployment로 배포하고, J-Jobs가 해당 서비스를 REST API로 호출해 업무를 실행합니다.

위 그림은 J-Jobs가 실행 제어를 담당하고, Kubernetes Deployment가 실제 처리량과 확장성을 담당하는 기본 구조를 표현합니다.

J-Jobs에는 Rest API 템플릿이 제공되며, REST API 전송을 위한 다양한 설정을 지원합니다. 타임아웃 시간 지정, 응답값 비교, 응답값 추출 기능 등도 제공됩니다.

구성 개요

• 업무 애플리케이션은 Kubernetes Deployment로 배포합니다.
• 부하에 따라 HPA 또는 운영 정책으로 Pod 수를 조절합니다.
• J-Jobs는 업무 시작용 API 엔드포인트를 호출합니다.
• 업무 애플리케이션은 요청 파라미터를 받아 실제 비즈니스 처리를 수행합니다.
• 운영자는 J-Jobs Manager에서 실행 이력과 결과를 확인합니다.

추천 적용 대상

• 이미 HTTP 기반으로 실행 가능한 업무가 존재하는 경우
• 상시 기동형 서비스에 배치성 호출을 얹고 싶은 경우
• 호출 빈도가 높고 수행 시간이 짧아, 매번 Job Pod를 생성하고 정리하는 비용이 부담되는 업무
• 스케줄은 J-Jobs가 관리하고, 실제 처리량은 Kubernetes가 흡수하게 하고 싶은 경우

장점

• 기존 업무를 비교적 작은 변경으로 Container 환경에 올릴 수 있습니다.
• 실행 제어와 스케일링을 분리할 수 있습니다.
• 상시 기동형 Pod를 재사용하므로, 짧고 자주 수행되는 업무에서 Job Pod 생성과 종료 오버헤드를 줄일 수 있습니다.
• 트래픽이나 처리량 증가에 따라 Pod 수를 유연하게 조절할 수 있습니다.
• J-Jobs는 스케줄링, 선후행, 이력 관리에 집중할 수 있습니다.
• J-Jobs의 Rest API 템플릿을 활용하면 응답값을 전체 또는 일부 추출하여 후행 Step에 전달할 수도 있습니다.

패턴 적용 시 체크 포인트

• 업무 WAS에서 배치가 수행되므로 J-Jobs Manager를 통해서 로그를 조회할 수 없습니다. 만약 미리 지정된 J-Jobs 로그경로에 업무용 로그를 적재한다면 J-Jobs Manager를 통해서 업무 로그를 확인할 수도 있습니다.
• 업무 WAS 내부에서 여러 배치가 동시에 수행되는 구조라면, Pod 메모리와 JVM 힙 크기를 충분히 확보하고 최대 동시 실행 수를 제한해야 합니다. 이 경우 메모리는 기본 WAS 사용량 + 배치 1건당 최대 메모리 x 동시 실행 수 + 여유분 기준으로 산정하는 편이 안전합니다.
• 장시간 수행 API라면 중지 시 호출할 별도 종료 API도 함께 설계하는 편이 좋습니다. J-Jobs Rest API 템플릿은 stop 시 별도 kill 요청을 보내는 구조도 지원합니다.
• 응답 지연이나 일시 오류에 대비해 호출 타임아웃과 재시도 기준을 명확히 정해야 하며, 재호출 시 동일 업무가 중복 실행되지 않도록 설계해야 합니다.

패턴 3. S3 파일 수신 시 후행 Job 실행

파일 기반 레거시 연계 업무를 Container 환경으로 옮길 때 유용한 방식입니다. 핵심은 S3 객체 수신을 감지한 뒤, 그 결과를 후행 Job으로 전달해 다양한 템플릿과 연결할 수 있다는 점입니다.

위 그림은 선행 S3 Watcher가 객체 키를 감지하고, J-Jobs가 그 결과를 후행 Job으로 전달해 다양한 템플릿과 연결하는 흐름을 한 장으로 정리한 것입니다.

J-Jobs에서 제공하는 S3 Watcher 템플릿은 bucket + prefix + 정규식 패턴을 기준으로 객체 목록을 주기적으로 폴링합니다. 감지된 객체 키는 outparam으로 후행 Job에 전달할 수 있으며, 후행 Job은 반드시 k8s Job일 필요가 없습니다. Rest API, Command, Java, Shell, k8s Job 등 J-Jobs가 제공하는 다양한 템플릿으로 연결할 수 있습니다.

구성 개요

• 선행 Job은 S3 Watcher 역할을 수행합니다.
• 지정한 Bucket/Prefix에 대상 파일이 1개 이상 수신되면 매칭된 객체 키를 후행에 전달할 수 있습니다.
• 후행 Job은 전달받은 객체 키를 파라미터로 사용해 업무를 수행합니다.
• J-Jobs는 선후행 제어, 실패 처리, 이력 관리를 담당합니다.

추천 적용 대상

• 기존 파일 수신 기반 연계를 S3 중심 구조로 전환하는 경우
• S3 객체 도착을 기준으로 다양한 후행 업무를 유연하게 연결하고 싶은 경우
• 객체 키나 파일명 같은 선행 결과를 후행 Step 파라미터로 직접 전달하고 싶은 경우

장점

• 공유 파일시스템 감시 기반 연계를 객체 스토리지 감지 기반으로 전환할 수 있습니다.
• 후행 Job을 하나의 템플릿으로 고정하지 않고, 업무 특성에 따라 다양하게 선택할 수 있습니다.
• 선행 Job의 결과를 후행 Job에 명확하게 전달할 수 있어 파라미터 연결이 단순합니다.
• J-Jobs의 선후행 제어, 운영 이력, 실패 대응 체계를 유지할 수 있습니다.

패턴 적용 시 체크 포인트

• S3 Event Notification을 Amazon SQS로 연결하는 환경이라면 폴링 방식인 S3 Watcher 대신 이벤트 연계형인 SQS Watcher를 사용할 수 있습니다.
• S3 재전송이나 중복 이벤트를 고려해 bucket + key + versionId 또는 별도 업무 키 기준의 중복 실행 방지 기준이 필요합니다.
• S3 Watcher는 File Watcher처럼 완료 판정을 제공하지 않으니 업무단에서 판단해야 합니다.
• 후행 Job이 어떤 템플릿인지에 따라 파라미터 형식과 오류 처리 방식이 달라지므로, 객체 키 전달 규칙을 미리 정해야 합니다.
• 여러 객체 키를 한 번에 받을 수 있는 경우, 후행 Job이 단건 처리형인지 다건 처리형인지 구분해서 설계해야 합니다.

패턴 4. 대량 데이터를 분할해 다수 Pod로 병렬 처리

처리 건수가 많아 순차 처리로는 시간이 과도하게 소요될 때 적합한 방식입니다. J-Jobs가 상위 오케스트레이터가 되고, 실제 데이터 처리는 여러 Pod가 분할 수행합니다.

위 그림은 분할 기준 생성부터 병렬 Pod 실행, 결과 집계, 전체 완료 판정까지의 책임 분리를 보여줍니다.

k8s Job 템플릿 자체에서 partition 사용 여부, mapper command, mapper arguments, mapper result keyword, thread count를 설정할 수 있습니다.

구성 개요

• 선행 단계에서 전체 처리 대상을 조회합니다.
• 분할 로직 또는 Mapper가 데이터를 여러 실행 단위로 나눕니다.
• 각 분할 단위별로 Plan 또는 실행 파라미터를 생성합니다.
• J-Jobs가 여러 Pod를 병렬로 호출합니다.
• 모든 하위 실행이 종료될 때까지 집계한 뒤 전체 성공 또는 실패를 판단합니다.

추천 적용 대상

• 대량 정산, 집계, 변환, 정리 작업처럼 처리 시간이 긴 업무
• 처리 단위를 명확히 분리할 수 있는 업무
• 일부 구간 실패 시 실패 구간만 재실행하고 싶은 업무

장점

• 단일 배치 인스턴스 기준의 전체 처리 시간을 줄일 수 있습니다.
• 데이터 양에 따라 병렬도와 분할 크기를 유연하게 조절할 수 있습니다.
• 각 실행 단위를 별도 Pod로 격리할 수 있어 자원 충돌을 줄이기 쉽습니다.
• J-Jobs 기준으로 전체 병렬 실행의 이력과 결과를 통합 관리할 수 있습니다.

Spring Batch의 Partition과 목적은 유사하지만 접근 방식은 다릅니다. Spring Batch가 애플리케이션 내부 배치 프레임워크 중심의 분할 처리라면, 이 패턴은 J-Jobs가 외부에서 실행 단위를 제어하는 오케스트레이션 중심 모델에 가깝습니다.

패턴 적용 시 체크 포인트

• Mapper도 구현 대상입니다. Shell Script 형태로 작성하고 그 경로를 설정해야 합니다.
• Mapper는 같은 데이터를 여러 Pod가 중복 처리하지 않도록 범위 정의가 명확해야 합니다.
• 병렬로 처리 가능한 업무인지 먼저 확인해야 합니다.
• 결과 집계 단계에서 순서 보장 또는 중복 제거가 필요한지 확인해야 합니다.
• 여러 Pod가 동시에 기동할 수 있도록 줘충분한 Node 자원이 확보되어야 합니다.

패턴 비교

구분	패턴 1. 시간 기반 반복 k8s Job	패턴 2. REST API 호출	패턴 3. S3 파일 수신 시 후행 Job 실행	패턴 4. 분할 병렬 처리
실행 대상	일회성 Job Pod	상시 기동형 서비스	선행 감지 Job + 후행 Job	다수의 병렬 Pod
시작 조건	스케줄 또는 반복 일정	스케줄 또는 수동 실행	S3 객체 수신	대량 데이터 조회 후 분할
적합한 업무	스크립트형 배치, 환경 의존형 작업	HTTP 호출형 업무	파일 기반 연계/변환	대량 데이터 처리
확장 방식	Job Pod 단위 실행	Deployment 스케일링	후행 템플릿 조합	분할 수와 병렬도 조절
운영 핵심	이미지 관리, Job 옵션 표준화	API 중복 실행 방지, 호출 제어	감지 방식 선택, 후행 Job 연결	Mapper 관리, 분할 기준

마무리

Container 환경으로 전환되었다고 해서 스케줄링과 운영 통제가 사라지는 것은 아닙니다. 오히려 실행 주체가 분산될수록, 상위 제어 계층으로서 J-Jobs의 역할은 더 분명해집니다.

시간 기반 반복 k8s Job 템플릿 실행 패턴은 기존 로컬 Shell Script 배치를 Container 방식으로 전환할 때 유용하고, REST API 호출 패턴은 상시 기동형 서비스를 배치 실행 흐름에 연결할 때 적합합니다. S3 파일 수신 시 후행 Job 실행 패턴은 객체 수신 결과를 다양한 템플릿으로 연결하는 데 강점이 있으며, 대량 데이터를 병렬 분할해 처리하는 패턴은 처리 시간 단축이 중요한 업무에서 효과가 큽니다.

중요한 것은 Kubernetes 자체를 업무 스케줄러로 과신하지 않는 것입니다. Kubernetes는 실행 환경이고, J-Jobs는 업무 운영 체계입니다. 두 역할을 분리해서 설계해야 운영이 단순해집니다.