묻고 답해요
160만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
미스터 KILL-9 Processor 단 질문이 있다
안녕하신가 미스터 KILL-9항상 빠르고 친절한 답변 고맙다 이번에 회사 로직 작성중에 조금 막막한 부분이 있어 질문 하러 왔다 reader 엑셀 파일 읽어오고processor 에서 해당 엑셀 데이터 값을 가지고 dao 호출해서 검증하고, 깍고(가공)마지막으로 쓰기 처형하는데 작업을 하는데문제는 가공 단계에서 dao 를 직접 호출하면ExecutorType 이 simple 로 호출되고 쓰기 단계에서 batch 로 ExecutorType 실행되어 에러가 발생한다Cannot change the ExecutorType… 이렇게 말이다..그래서 일단 아래 코드 처럼 해결은 했어 우선 기존 코드는 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> MyBatisBatchItemWriter -> 에러 Cannot change the ExecutorType… 해결한 코드 PoiItemReader -> ItemProcessor<> (여기서 mybatis dao 호출 해서 검증작업도 함) -> JdbcBatchItemWriter-> (해결)그런데 이렇게 작성해도 되려나 싶네.. 그리고 String 문으로 쿼리 짜는것도 맘에 안들고..ㅠㅠ
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
오타발견
- 명백한 한계점 (단점): - 네트워크 대역폭 소모: 실제 데이터를 전송하므로 네트워크 부하가 극심하다. 데이터 건수가 많거나 크기가 크면 통신 자체가 병목이 될 수 있다. ("핵탄두 데이터 전송에 따른 통신망 과부하 주의!") - Manager 읽기 병목: Manager 혼자 모든 데이터를 읽어야 하므로, 읽기 자체가 느리다면 원격 청킹은 효과가 없다. ("중앙 정찰 위성의 스캔 속도 한계!") - 복잡성(감시와 디버깅의 지옥문): 역시 미들웨어(Kafka 등)와 프링 인티그레이션 설정이 필수적이다.프링 인티그레이션 ->스프링 인티그레이션
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
예제 빠진부분?
KILL-9: "이 구성이 매우 중요하다. Job 설정을 보면, logFileManagerStep()이 먼저 실행되고, 그 다음에 mergeOutputFilesStep()이 실행되도록 .next() 메서드로 연결되어 있다.없어도 뻔해서 이해되긴하는데,위의 예제에서 Job빈이랑 LogFileManagerStep빈(이건 일부러?) 빼먹은듯?KILL-9: "이 구성이 매우 중요하다.로 검색하면될거야------그리고 그냥 궁금한건데,이번강의챕터가 컨셉자체는 맘에드는데(코드랑 내용이랑 같이 스토리넣어서 말하는거)인프런 강의 시스템상 너무 보기힘들지않아?부록 2: 전장 구축 - Redis to MongoDB 데이터 이관 작전 환경 설정같은거보면,나는 가로휠이 있어서 괜찮았는데 가로휠마우스가 없으면 마우스 드래그로 컨트롤하거나 키보드 화살표로 조금씩 밀어야하는데 이거 너무 보기 힘들거같아스크롤바도 내용화면이 한페이지를 넘어가면 안보이고 그래서다음거 스카이넷보고서인지 그런식으로 개행을 넣던가 하면될거같긴해킬구<스카이넷 ?다음거 원격 파티셔닝 강의 대부분 그냥 서두보고 다 스킵할거같은데,@ConditionalOnProperty로 조건부 빈생성 관리하는거 스킵되는거 아까운데 이거나 줏어가라고 마지막 부록에 넣어줄만하지않음?나도 그냥 내용 대충 훑어만봤는데 저거하나는 건진거같아서
-
미해결스프링 배치
스프링 배치 버전 질문
강의에서 사용되는 버전은 Spring Batch 2.5.1이고 최신 스프링 배치는 6 버전 대까지 나온걸로 알고있습니다.그리고, 얼핏 보니 deprecated된 클래스들이 꽤 있던것같은데 (예를들면 SimpleBatchConfiguration 제거, JobBuilderFactory 제거 등), 알아보니 이제 사용자가 더 사용하기 편해졌다(?) 정도인것같습니다. 그래서 질문은 지금 이전버전의 동작방식을 이해해도, 앞으로 나오는 버전들의 동작방식은 그대로인지 아니면 다시 새롭게 배워야할 부분이 많은 지 궁금합니다!
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
실무에서 배치 메타데이터 관리
$ kill-9.. 킬구형 추석 연휴는 잘 보냈는가.. 처음에 텍스트로만 구성된 강의인 걸 결제한 후 알게되어 당황했지만.. 걱정 마라.. 금방 킬며들었다.. 눈으로 읽고 생각하는 즐거움을 알게되었다.. 무엇보다 그동안 피로했을 내 귀를 지켜줘서 고맙다.. 아직 강의 초반이지만 궁금한 부분이 있어서 질문 올린다.. 대용량 트래픽을 다루는 회사에서는 배치 메타데이터의 양도 어마어마할 것 같은데 실무에서는 배치 메타데이터를 어떻게 관리하는 지가 궁금하다.. 혹시 배치 메타데이터를 활용할 일이 없을 것 같으면 안쌓는 것도 권장하는 방법인가..
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
FlatFileItemWriter의 FieldExtractor 커스텀 관련
킬구형 텍스트 강의임에도 몰입감 있는 구성에 연휴에 재밌게 공부하고 있어. 고마워FlatFileItemWriter에 대한 흐름을 정리하고 질문 해볼게1. sourceType() 메서드 내 객체 타입에 따라 FieldExtractor 구현체가 결정된다.2. (Bug가 fix되기 전까지) sourceType() 메서드 내 객체 타입이 Record일 경우 names() 메서드 호출은 무시되고, Record 타입의 모든 property가 쓰일 수밖에 없다.3. 그렇기에 Record 타입에서 필드 하나를 제외하고 파일을 쓰고싶다면, fieldExtractor()를 사용한 커스텀 구성을 통하여 필드 하나를 제외해야 한다.내가 강의를 보면서 정리한 흐름이고, 아래는 그 정리 중 나온 질문이야Q1. BeanWrapperFieldExtractor일 경우 필드 하나를 제외하고 싶다면, names()에서 해당 필드만 제외해도 되나? Q2. 만약 위와 같은 방법이 된다면, RecordFieldExtractor 관련 Bug가 fix 된 후에 FieldExtractor를 직접 커스텀하는 경우가 별로 없지 않을까 싶은데.. 혹시 내가 생각하지 못한 부분이 있을까?고마워 킬구형아
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
MessageConversionException 예외 타입
안녕 킬구형 형 때문에 이번 추석 연휴 재밌게 보내고 있어. 고마워 형. 강의를 보면서 예제 소스에 대한 궁금증이 생겨서 질문을 남겨. 6장. 작전4: 원격 청킹 (Remote Chunking) - 전방위적 타격이 시작되다. ☠ '데이터 변화 모듈(SerDes Classes)' 예제에서 예외 객체로 MessageConversionException을 사용하는데 클로드에서는 통상 Kafka를 사용할때는 org.apache.kafka.common.errors.SerializationException 을 사용해야 kafka와 호환이 된다고 하더라구. 이거에 대해 설명 부탁해도 될까?
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
실무 예시가 궁금합니다.
형 아직 잘 이해가 안되서 그러는데, Job 안에서 Chunk 방식 Step과 Tasklet 방식 Step을 혼합해서 사용하는 실무 예시를 알려줄수 있어?
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
Spring Data JPA 사용 시 자동 주입 관련 질문
킬구형 Spring Data JPA 사용하면 JpaRepository 인터페이스를 사용해서 PlatformTransactionManager, DataSource를 자동으로 주입받아 사용할 수 있는데, 강의에서는 스프링배치의 세밀한 조정을 위해 일부러 JpaRepository를 사용하지 않는 거야?아래 두 강의에 둘 다 데이터소스와 트랜잭션매니저를 직접 활용하고 있어서 궁금해서 물어봐3장. 작전1: 관계형 데이터베이스 읽고 쓰기 (테이블의 심장에 처형장을 세우다 ☠)OPERATION DOUBLE TAP - Spring Batch Test(추가) 생각해보니 예전에 아주 간단한 로직의 스프링배치 앱을 JpaRepository, JPQL을 이용해서 만들었던 만들었던 기억이 있는데,, 혹시 JpaRepository을 일부러 사용하지 않는 이유가 있는지 궁금해
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
예제 궁금증
실제로 실행을 못해보는환경이라서 질문하는건데,JobLauncher를 활용한 REST API 구현의 예제같은경우 컨트롤러 하나를 생략없이 다 표현한거같은데 jobRegistry 는 di받지않았는데 어떻게 실행하는거임?빼먹은건가? job = jobRegistry.getJob(jobName);
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
TransactionManager 분리
TransactionManager 분리에 대해서 이해가 잘 가지 않는게 있어. 실제 운영 환경에서는 배치와 비즈니스 데이터 DB를 분리하는게 필수라고 했잖아?근데 이 분리의 단위가 배치용 메타데이터 저장만 분리를 하는게 맞는거야? 현재 사이드 프로젝트에서 멀티모듈 구조에 (MSA는 아님) API 모듈과 배치 모듈을 따로 분리한 상태야.유저 데이터에서 생일을 뽑아서 내일 생일인 유저에게 FCM 을 발송하는 배치를 만드는데,이때 만들어준 예제처럼 @BatchDataSource와 비즈니스 로직용 @Primary DataSource를 분리하게 되면,API 모듈용 DB Connnection을 배치에서도 똑같이 갖다 쓰는거 아니야 ?? 즉, 배치에서 API 쪽 커넥션을 가져다 써서 배치가 돌 때 커넥션이 고갈날 수 있지 않을까? 라는 생각이 들었어지금 이해한 바로는 @BatchDataSource, @BatchTransactionManager를 분리하고 주입해줘도 Reader -> Processor -> Writer 에는 @Primary 걸 쓰는것 같은데 맞아 ?나는 DB 분리와 함께, 비즈니스 로직에 대한 커넥션, 트랜잭션도 배치용으로 분리하고 싶은데 이럴땐 어떻게 해야해?특히나 배치에서도 JpaTransactionManager를 쓰고 싶은 경우에는 어떻게 해야해 ?원하는 바는, API 처리용 DB 커넥션은 커넥션대로 있고, 배치 메타데이터용 커넥션 따로, 배치에서 라이브 DB에서 유저 데이터를 가져오는 커넥션 따로 구성하고 싶어 (배치가 API 모듈 에 영향을 주지 않았으면 해서,,,) 혹시 내가 강의를 제대로 이해를 못한거라면 알려줘
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
오타(?) 발견
킬구형 강의 자료 중간에 이상한 문구 발견해서 제보해강의 회차: 5장. 작전4: Flow - 배치의 흐름을 지배하라 (분기점에서 생사를 쥐락펴락하라 ☠🏴☠)이상한 문장: 즉, Spring Batch의 암시적 전환 규칙 대상에서 제외된다는 뜻이다.재시도Claude는 실수를 할 수 있습니다. 응답을 반드시 다시 확인해 주세요.강의 자료 중간에 LLM에서 가져온 내용을 잘못 편집한 것 같아.
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
오타 발견
가령 다음과 같이 getExecutionContextSerializer() 메서드를 오버라이드하면g에 볼드처리안됨--원시적 침투 예제의 BatchConfig에서 DefaultBatchConfiguration 상속을 제거하고@EnableBatchProcessing을 추가하자. 다음과 같이 말이다.예제밑의 예제가 그냥 기존 DefaultBatchConfiguration 방식만 나와있음아마 기존과 수정을 두개 다 표시하는식으로 하고싶었을거같음--JobContext/StepContext: Late-Binding의 최종 무기고키룩형 JobContext/StepContext가 존재하면 배치 스코프가 활성화된 상태라는 것은 알겠어. 근데 이 JobContext/StepSontext 대체 어디에 써먹는거지? 단순히 활성화를 의미하는게전부인가?키룩형 -> 갈매기가 되고싶은 내면의 소리일수있음괜찮음 주변에 돌멩이 지망생도 있고 독수리 지망생,딸기우유 지망생도 있어서 이해할수있음
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
멀티모듈에서 DB 커넥션 풀 분리
DataSource에 대한 질문 배치를 적용중인데, 멀티모듈에서 배치용 Application을 따로두고, 배치용 yaml에서 datasource를 두었고, api쪽도 yaml에서 datasource를 보고 있다.이때 , 아래와 같이 Config에서 Bean을 통해 Datasource을 생성, JobRepository에 전달해주지 "않아도" 커넥션이 분리가 되는가?API 쪽 디비와, 배치 디비의 커넥션풀을 따로 쓰고싶은데 아래와 같이 별도 세팅 없이 yaml만으로 분리는 안되는지 궁금하다...@Configuration class JpaConfig { @Bean @ConfigurationProperties("spring.datasource") fun batchDataSource(): DataSource { return HikariDataSource() } @Bean fun jobRepository( batchDataSource: DataSource, transactionManager: PlatformTransactionManager, ): JobRepository { return JobRepositoryFactoryBean().apply { setDataSource(batchDataSource) setDatabaseType(DatabaseType.POSTGRES.name) setTransactionManager(transactionManager) afterPropertiesSet() }object } }
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
오타 발견
SimpleStepHandler - Step 실행의 관리자Step의 실행은 StepHandler에 의해 의해 통제된다. Spring Batch는 기본 구현체로 SimpleStepHandler를 사용하는데, 이 컴포넌트가 Step 실행의 전체 라이프사이클을 관리한다.의해 의해 <-그리고 Step Squad 핵심 요약 있으니까 너무좋은데 Job Squad 에서도 핵심요약이 있었으면 더 좋았을거같음뭐 스탭이나 잡이나 내용이 거의 비슷비슷하긴한데(Execution 반드시 새거만들고,상태변경시 즉시 메타데이터저장소에 저장하고)그래도 실제 실행 따라가는 느낌이라 정리가 잘 안되는느낌이긴해서 마지막에 방점찍으면 보기 더 편할거같은느낌
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
writer retry 관련해서 궁금한 점이 있습니다.
반말은 조금 부끄러워서.. 존댓말로 질문드리겠습니다. ItemWriter에서 예외 발생 시 재시도 - 청크 단위로 재시도 관리 1. ItemWriter에서 예외 발생 시 ItemProcessor부터 처리가 재개된다.2. ItemProcessor에서와 달리, ItemWriter에서의 재시도 횟수는 청크 단위로 관리된다. 요 부분에서 실제로 배치를 돌려보니 writer부터 재시작하는 것을 확인 가능했습니다.. 관련해서 원인을 분석해보니, 아래 결론에 도달했는데 맞을까요? processorNonTransactional() 설정이 켜져있으면 Item 단위로 처리 결과를 캐시에 저장하기때문에 processor는 모두 완료 처리 -> writer부터 시작processorNonTransactional() 설정이 꺼져있으면 청크 단위로 완료 처리하기때문에 processor부터 다시 시작
-
해결됨죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
청크 지향 처리 시 벌크 read 방법?
킬구형, 청크 지향 처리 시 벌크 read를 할 수 있는 방법이 있어?ItemReader 사용 시 소스에서 1건 씩 데이터를 읽어온다면, 단건 SELECT문이 매번 날아가거나 아니면 JDBC의 ResultSet next()를 사용하는 것 같은데,, 전자면 DB 부하가 너무 심하고 후자여도 네트워크 IO가 꽤 발생할 것 같은데..지금 수백? 수천만? 건 정도의 데이터를 마이그레이션 해야하는 업무를 받았는데, 청크 생성 시 DB 부하나 네트워크 트래픽을 좀 줄이고 싶은데 다건 SELECT를 통해 처리하는 방법이 있을까?
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
redis 샘플 공격 데이터 2번 오류
오타 발견root@4ea86c29f1f7:/data# redis-cli set attack:2 "{\"id\":2,\"timestamp\":\"${TODAY}T09:28:47\",\"targetIp\":\"203.0.113.50\",\"attackType\":\"XSS\",\"payload\":\"<script>alert('HACKED!');</script>\"}" 위 명령어 실행 시, 아래와 같은 에러 메시지 발생!bash: !': event not found 에러 발생 원인bash: !': event not found 에러는 Bash의 히스토리 확장(history expansion) 때문에 납니다. ! 문자(예: HACKED!)가 들어가면 bash가 !로 시작하는 히스토리 토큰(예: !!, !$, !123)으로 해석하려 하고, 매칭되는 히스토리 항목이 없으면 event not found 오류가 납니다. set +H # 히스토리 확장 끄기 ... redis-cli set attack:2 "{\"id\":2,\"timestamp\":\"${TODAY}T09:28:47\",\"targetIp\":\"203.0.113.50\",\"attackType\":\"XSS\",\"payload\":\"<script>alert('HACKED!');</script>\"}" ... set -H # # 히스토리 확장 켜기OKredis key들을 set 하기 전에 히스토리 확장을 끄고 실행할 경우 정상 동작
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
MR.kill-9 첫번째 예제 코드 실습하면서 궁굼한점이 생겼다.
강의 예제를 따라가면서 SystemFailureJobConfig 배치를 실행했는데, 계속 FlatFileItemReader에서 JobParameter로 전달한 inputFile이 null로 들어오는 문제가 발생했다.정확하게는 Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.batch.item.file.FlatFileItemReader]: Factory method 'systemFailureItemReader' threw exception with message: Path must not be null이 오류 였으며, public FlatFileItemReader<SystemFailure> systemFailureItemReader( @Value("#{jobParameters['inputFile']}") String inputFile) { log.info("오잉 Reader inputFile: " + inputFile); // null return new FlatFileItemReaderBuilder<SystemFailure>() .name("systemFailureItemReader") //여기서 path not null 오류 발생 .resource(new FileSystemResource(inputFile)) .delimited() .delimiter(",") .names("errorId", "errorDateTime", "severity", "processId", "errorMessage") .targetType(SystemFailure.class) .linesToSkip(1) .build(); }.name("systemFailureItemReader") 이 위치에서 발생하고 있었다. 그리고 line numbers are likely diverged. try to find the current location inside 'SystemFailureJobConfig. systemFaliureItemReader()'이 메시지도 함께 보였다.GPT에 물어봐서 해결이 되긴 했는데, KillBatchSystemApplication에서 CommandLineRunner를 구현하고 직접 경로를 지정해주었다.@SpringBootApplication @AllArgsConstructor public class KillBatchSystemApplication implements CommandLineRunner { private final JobLauncher jobLauncher; private final Job systemFailureJob; public static void main(String[] args) { SpringApplication.run(KillBatchSystemApplication.class, args); } @Override public void run(String... args) throws Exception { JobParameters params = new JobParametersBuilder() .addString("inputFile", "/Users//Desktop/kill-batch-system2/system-failures.csv") .toJobParameters(); jobLauncher.run(systemFailureJob, params); } }실무에서는 CLI로 파라미터를 전달하는것이 핵심이라 했던걸로 기억한다.CLI로 전달한 JobParameter를 StepScope Bean에서 안전하게 받는 다른 방법은 없나?? 아 지금 작업도구는 MacOS M1, Spring Boot 3.4.7 이다. 연휴 잘 보내길 바란다.
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
청크 단위의 트랜잭션 롤백에 대한 질문
청크 단위로 트랜잭션된다는건 이해했다. 그에 관련해서 궁금증이 생겼는데,reader, processor에서 처리하다가 Exception이 나도 사실 DB엔 롤백할게 없으니 사실상 Writer 작업 중에만 단 한번 롤백이 수행될 것이라고 예상되는데 맞는가?read 시에, process 도중에도 롤백이 일어날 경우가 있는지 궁금하다. 추가로 과거 스프링 배치 공식 문서의 잘못된 다이어그램 이라던지null을 줘야 끝난다는 점과 97개 와 같이 자세한 예시를 들어준 점,read(), process()가 각각 10번씩 수행된다는 것과 같이사용자들이 많이 헷갈려 하는걸 명확하게 알려줘서 좋은 것 같다.