강의

멘토링

커뮤니티

인프런 커뮤니티 질문&답변

퓨퓨님의 프로필 이미지
퓨퓨

작성한 질문수

죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.

1장. 작전1: 바이너리 초이스 - 스프링 배치의 두 가지 스텝 유형 (양자택일... 죽음의 선택이다 ☠️)

킬구형 혼자 삽질하면서 배치 운영하는데 궁금한 부분이 있어

작성

·

63

1

안녕 킬구형 나는 오랜만에 배치 복습하려고 형 강의 구매했어!

일단 그냥 책 보면서 실무에서 배치를 운영을 하려니깐 고민이 있어.

형 생각이 궁금해서 질문을 남겨

 

1. Jenkins , Spring Batch

형 일단 나는 Batch를 실무에서 Jenkins 스케줄러 + Batch 이렇게 사용하고 있어. 그런데 배치 인프라에 대해서 요즘 고민이 생기는 거 같아.

  • 나는 job enabled를 false로 설정하면서 운영하고 있는데 만약에 배치가 N개로 운영되고 있다고 가정하면 port 충돌에 대해서 고민이야 물론 parameter로 port를 넘겨줄 수 있어서 현재는 스크립트로 남는 포트를 parameter로 넘겨주면서 사용하고 있어. 간편성을 생각한다면

    그냥 enabled를 true로 하고 api 형식으로 그냥 호출만 해주면 이런 복잡한 과정 없이 사용할 수 있을 거 같은데 어떻게 생각해.

 

2. CI/CD

  • 하나의 jar에서 여러 개의 배치가 돌아가는데 이때 CI/CD 과정에서 문제가 생길 수 있을 거 같다. 현재는 ln 심볼릭 링크로 해결을 하고 있는데 이게 적절한 방식인지? 아니면 다른 방식이 있는지 궁금해

 

3. JobParametersIncrementer

  • 형 Spring Batch에서 JobParametersIncrementer(RunIdIncrementer 등) 관련해서 궁금한 점이 있어

    만약 업무적으로 특별한 파라미터(날짜, 키 등)가 없는 반복 배치라면
    이 때는 run.id와 같은 증분기 기반의 값으로 JobInstance의 고유성을 관리 하지만 업무적으로 중요한 파라미터(날짜, 키 값 등)가 있다면 이 경우에는 run.id 대신 해당 파라미터를 JobInstance의 기준으로 써야 멱등성 및 실패/재실행 제어가 더 적합하다고 생각해.

    실제로 파라미터가 없는 경우에는 run.id로 멱등성을 보장하고, 파라미터가 있는 경우에는 run.id 증분기를 쓰면 오히려 동일 파라미터로 재실행/복구 등 업무상 중요 컨트롤이 어렵지 않나요?

    이런 경우 run.id 증분기를 같이 쓰는 게 맞는지, 아니면 아예 쓰지 않는 게 맞는지 설계 원칙이 궁금해요.

https://github.com/spring-projects/spring-batch/issues/4910

https://github.com/spring-projects/spring-batch/wiki/Spring-Batch-6.0-Migration-Guide

답변 3

1

KILL-9님의 프로필 이미지
KILL-9
지식공유자

1) port 충돌에 대해 고민이란 것은 한 대의 서버에 여러 배치 인스턴스를 돌리려는시도로보이는군. 
그 인스턴스가 서버의 역할까지 하는것인가? 왜 포트를 고민하는 것인지 사용성을 좀 더 설명해주었으면 한다.

enabled를 true로 한다는 것은 JobLauncherApplicationRunner를 사용한다는 말이 된다. 앱이 기동하자마자 잡을 실행하게 되는 것이지 true와 false를 반대로 설명한 것으로보이는데 내가 이해한바가 맞는가??

배치 앱을 서버로 가동시켜뒀다가 api 호출을 받으면 잡을 실행시키는 유즈케이스를 말하는 것으로 보인다. 가령 매 분마다 돌아가는 배치가 있을 경우나 사용자 요청에 반응해 배치를 돌려야하는 경우에는 api 서버의 형태로 배치 앱을 구동하는 것도 좋다

2) 하나의 앱에서 여러개의 배치를 돌려야하는 유즈케이스를 설명해주었으면 한다. 앞서 말한 서버 포트때문인것인가? 배치 앱을 실행하고 그 다음 api 요청을 통해 배치를 실행시키는 것인가? 그렇다면 앱은 언제 종료되는 것인가??

3) 따끈따끈한 이슈로 질문을 줘서 아까부터 흥미로웠다(이해해주기 바란다 회사라 깊게 고민할 여유가없었다)

"이 때는 run.id와 같은 증분기 기반의 값으로 JobInstance의 고유성을 관리 하지만 업무적으로 중요한 파라미터(날짜, 키 값 등)가 있다면 이 경우에는 run.id 대신 해당 파라미터를 JobInstance의 기준으로 써야 멱등성 및 실패/재실행 제어가 더 적합하다고 생각해. " 너의 말이 맞다

"실제로 파라미터가 없는 경우에는 run.id로 멱등성을 보장하고," 
 
전달해준 이슈(스프링 배치6에 반영될 내용이지)에서 말하는 run.id의 근본 목적을 잘 이해하고 있군. 

그러나 현재 우리강의에서 다루고있는 스프링 배치5에 한해 말하자면

챕터5 작전1에서 설명했듯 파라미터가 없는 경우에는 재시작 검사가 진행되지않는다 따라가 run.id가 불필요하다(너가 전달한 이슈에서 run.id의 근본 목적에 맞게 코드가 수정된 이유가 바로 지금 말하는 재시작 검사 회피 이슈가 해결되었기에 가능해진것이지) 

파라미터가 있는 경우에 run.id 증분기를 사용하면 

"파라미터가 있는 경우에는 run.id 증분기를 쓰면 오히려 동일 파라미터로 재실행/복구 등 업무상 중요 컨트롤이 어렵지 않나요?" 너의 말이 맞다 재시작을 사용하고자한다면 증분기는 피해야한다. 배치5까지 나를 포함한 대부분의 사용자들이 파라미터 증분기를 다소 의도치 않은 방향으로 사용해왔다. 재시작은 포기하고 동일 파라미터로 여러번 잡을 실행하기 위해서였지 (그렇다 트릭이였다)

그러나 이 방식이 이점이 전혀없다고 할수는없다. 급하게 동일 잡을 다시돌려야한다고하자 매번 임시 파라미터를 다른 값으로 지정해서 잡을 실행시키지 않고도 간편하게 잡을 다시 돌릴 수 있지. 

재시작을 통해 실패지점부터 다시 돌려야하는 배치잡이있는 반면 멱등성이 보장된다면 깔끔하게 실패한 잡을 처음부터 다시 돌리는것도 방법이될 수 있다.

아무튼 #4910 으로 인해 앞으로는 증분기를 다른 파라미터와 사용하게 될 일은 사라졌다. 증분기를 사용하면 다른 파라미터들이 다 무시되도록 변경되었기 때문이지

깊은 이해에따른 질문 고맙다.

질문 1) 2)는 좀 더 디테일한 사용성을 말해줘야 더 이야기를 나눌수있을 것 같다

일이 너무 밀려 급한맘에 정돈되지못한 상태로 대답한 것 양해바란다 💀💀💀💀


 

 



3



1

KILL-9님의 프로필 이미지
KILL-9
지식공유자

흥미로운 질문 고맙다형

밤10시에서 11시 사이 자세히 살펴보고 답변달아보겠다 💀💀

0

안녕하세요, 인프런 AI 인턴입니다.

퓨퓨님, 배치 관련 질문을 주셨군요. 하나씩 답변 드리겠습니다.

1. Jenkins와 Spring Batch

Jenkins를 스케줄러와 함께 사용해서 Spring Batch를 운영 중인 상황이시군요. 포트 충돌에 대한 고민은 충분히 이해됩니다. Spring Batch를 API 형태로 호출하여 배치를 실행하는 방식은 간편함과 유연성을 제공합니다. 그러나 이는 배포 환경에 따라 검토가 필요합니다.

  • API 호출로 배치 운영: API 형태로 배치를 호출하면 Jenkins에서 배치 서버에 대한 접근 권한과 네트워크 설정이 필요합니다. 간편성을 확보할 수 있으나, 적절한 권한 관리와 네트워크 보안 설정이 필수입니다.

2. CI/CD

하나의 JAR에서 여러 개의 배치가 돌아간다면, CI/CD에서 각 배치에 대해 신중히 계획해야 할 부분들이 있습니다. 현재 ln 심볼릭 링크로 해결하고 계시다면 이는 효율적인 방법입니다.

  • 심볼릭 링크 활용: 이 방법은 같은 버전의 배치에 대해 유연하게 배포하고 테스트 환경에서 효율적인 자원 관리를 도와줍니다. 단, 심볼릭 링크를 사용할 경우 상위 경로에 대한 권한 관리와 유지 보수가 중요합니다.

3. JobParametersIncrementer

Spring Batch에서 JobParametersIncrementer는 각 JobInstance를 고유하게 식별하기 위해 사용됩니다. 업무적으로 중요한 파라미터가 포함된 배치라면 이 파라미터들로 식별하는 것이 더 적합합니다.

  • 중요 파라미터 활용: 주기적인 JobInstance 고유식별에 run.id와 같은 증분기를 보통 사용하지만, 업무적으로 중요한 파라미터로 식별하는 것이 실패 시 재실행 및 데이터 복구 면에서 더 적합할 수 있습니다.

  • 증분기 사용의 필요성: run.id 증분기를 배치 식별 목적으로 사용하는 것은 파라미터가 없을 때 유용하며, 파라미터가 있는 경우에는 별도의 증분기가 아닌 해당 파라미터를 중심으로 고유성과 멱등성을 유지해야 합니다.

관련된 추가적인 정보는 아래 링크를 통해 확인하실 수 있습니다:

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

퓨퓨님의 프로필 이미지
퓨퓨

작성한 질문수

질문하기