Spring Batch 다양한 트리거방식

아래 항목들은 서로 짬뽕이 될 수 있다.

트리거 방식

• linux crontab : crontab -e
  • 토이 프로젝트에서나 써라
  • 어디서 돌리는지 제3자가 보면 절대 못 찾음, 로그도 보기 어려움
• spring @Scheduled 이용
  • 단일 인스턴스, 서버 한대로 돌릴때만 써먹을 수 있음. 2대면 같은 스케쥴에 2대씩 돌테니깐
  • 장점
    • 코드상에 박혀서 버전관리됨
  • 단점
    • 스케쥴 수정하려면 배포해야함 -> 여기서부터 별로임
    • 서버 한대로만해야하니깐 이중화 불가능함
• 직접 batch 돌리도록 구현
  • 스케쥴 db 에 넣어놓고 트리거링하는애를 구현한다.
  • 장점
    • 내가 모든걸 컨트롤한다.
  • 단점
    • 귀찮음
• jenkins
  • 장점
    • 위에 단점들을 다 완벽하게 커버 가능함.
  • 단점
    • 깔아야함. jenkins 띄우는데만 보통 메모리 2G~4G 씀. jenkins 까는 script 는 보통 관리 잘안하니까 이전설치하거나할떄 너무 빡침. job 셋팅 export 같은것도 지원은 하는데 잘 안됨.
    • 설정 변경 히스토리가 의외로 안 남아서 오류나면 범인찾기 생각보다 어려움.
    • 설정 변경 히스토리 남기려면 좀 귀찮음
      • 버전 제한도 있는 듯함. https://blog.leocat.kr/notes/2020/10/15/jenkins-save-config-histories

실행 방식

• mvc 로 띄워놓고 API 호출
  • 이중화 가능. 일반 어플리케이션 처럼 그냥 빌드 배포 하는 느낌. jobExecutor bean 이용해서 실행시킨다
  • 장점
    • spring 구동자체 하지도 않기 때문에(미리 해서 떠있으니깐) 실행속도도 제일 빠름
  • 단점
    • 배포할때 서버 내리고 띄우고 짓거리 해야하기 때문에 초기 셋팅 좀 불편해
    • 어떤이유에서건 서버가 뜨질않으면 돌릴수가 없다. 서버를 튼튼하게 유지해야함. 이중화 필수
• jar 빌드해서 갖다놓고 jar 실행
  • 장점
    • job 마다 jvm 설정 다르게 줄수도 있음
    • 빌드 결과물만 원하는곳에 갖다놓으면 되니깐 devops 셋팅 과정이 복잡하지않음
    • 망했을때 서버들어가서 수동 jar 실행 계속하면, 장애 극복 가능.
  • 단점
    • spring 띄워야해서 bean 이 많아지면 많아질수록 구동속도 느려짐
• repo 체크아웃 받아서 gradle 빌드 실행
  • 장점
    • 커밋이 곧 서버 반영. reset 이 곧 롤백. 전환은 빠르다
  • 단점
    • 커밋이 곧 서버 반영이기 떄문에 인간 실수로 인한 사고날 수 있다.(가령 bean 설정 오류내서 spring 구동 안되면 모두 장애)
    • 체크아웃 못 받으면 모든 배치 전면 장애

그냥

• 항상 배치 꺠지는걸 확인해서 의도적으로 알람 수신이 되는지 확인하라 : 테스트 코드처럼
  • 떄떄로 java -jar 실패했는데, jenkins 상에는 SUCCESS 로 뜨고 그럴수 있음. 모두 인지 불가
• 까먹고 안적은게 있을수도 있다. to be continue