Batch- Reader

저번 글에서는 스프링 배치를 왜 사용하는지에 대해 살펴보았다. 일괄 작업이 필요한 경우, 배치는 효과적인 선택지가 될 수 있다.
배치의 기본 흐름은 단순하다. 데이터를 읽고, 가공한 뒤, 저장하는 것이다. 데이터의 출처가 어디든 상관없이, 해당 위치에서 데이터를 읽어오고, 배치 애플리케이션 내부에서 가공한 뒤, 최종 결과를 저장한다. 여기서 중요한 특징 중 하나는 배치가 주로 스케줄링 기반으로 실행된다는 점이다. 즉, 정해진 시간에 자동으로 실행되며, 사용자 요청과는 분리되어 동작한다.

이 말은 곧, 배치가 처리하는 작업은 실시간으로 즉시 반영될 필요가 없으며, 대량의 데이터를 나누어 처리하더라도 서비스에 직접적인 영향을 주지 않는다는 의미다. 따라서 배치는 뒤에서 안정적으로 대량 데이터를 처리하는 데 적합한 방식이라고 볼 수 있다.

이제부터는 스프링 배치에 대해 본격적으로 학습해보려고 한다. 첫 번째로 살펴볼 것은 Reader이다.

Reader의 역할은 무엇일까?

Reader의 역할은 단순하다. 데이터를 가져오는 것이다.
좀 더 정확하게 말하면, 어딘가에 쌓여 있는 데이터를 하나씩 꺼내오는 것을 의미한다.

그렇다면 왜 데이터를 하나씩 처리할까? 배치는 대량의 데이터를 처리하는 방식이라고 배워왔다.

여기서 중요한 점은, 수천 건, 수만 건의 데이터를 한 번에 모두 가져오게 되면
메모리 부담이 커지고, 처리 흐름을 관리하기도 어려워진다는 것이다.

그래서 Reader는 데이터를 한 건씩, 혹은 스트림처럼 순차적으로 읽어온다.
이 방식은 메모리 사용을 줄이고, 대량 데이터를 안정적으로 처리할 수 있게 해준다.

또한 배치는 실시간 처리가 목적이 아니기 때문에,
즉시 결과를 확인하기보다는 전체 데이터를 끝까지 안정적으로 처리하는 것이 더 중요하다.
정리하면, Reader의 역할은 다음과 같다. 어딘가에 저장된 대량의 데이터를, 순차적으로 하나씩 읽어와 다음 단계로 전달하는 것이다.

한번 실제로 사용해보자.

현재 외부 api를 통해 데이터를 가져오고 있다. 여기서 의문이 드는 사실이 있다.
데이터를 그냥 가져와서 저장하면 되는것이 아닌가 라는 생각이 들 수 있다.

이유는 다음과 같다. 
데이터는 항상 그대로 쓸 수 없다. 외부 API에서 가져온 데이터는 우리 서비스의 데이터 구조와 다를 수 있고, 불필요한 값이 포함되어 있을 수 있으며, 추가적인 계산이나 변환이 필요할 수 도 있다.

막상 이 데이터를 쓰기에는 뭔가 애매하다는 생각이 들 수 있다. 즉, 단순 저장이 아니라 가공 과정이 반드시 필요하다.
또, 가져온 데이터를 바로 변환하면 되지 않나 생각할 수 있다. 하지만, 대량 처리 시 안정성이 중요하다.
데이터가 많아질수록 중간에 실패할 수 있고 일부만 저장될 수 있으며 재처리가 필요할 수 있다.
이때 단순 저장 구조로는 대응이 어렵다. 다른 이유도 있겠지만 지금 파트는 Reader이기 때문에 이쯤하고 넘어가겠다.

그렇다면 어떻게, 데이터를 가져올까?

앞서 살펴본 예시는 외부 API를 통해 데이터를 가져오는 방식이었다. 하지만 지금부터 살펴볼 내용은, 외부 API의 결과를 단순히 사용하는 것이 아니라, 스프링 배치에서 데이터를 읽어오는 방식에 대해 이야기해보려고 한다.

즉, 데이터의 출처가 어디인지보다 중요한 것은 배치 내부에서 이 데이터를 어떤 방식으로 읽어오고 처리하느냐이다.
이러한 관점에서, 스프링 배치는 데이터를 읽기 위해 ItemReader라는 개념을 제공한다.
이제 이 ItemReader를 통해 데이터를 어떻게 읽어오는지 살펴보자.

 ItemReader은 무엇인가?

ItemReader는 스프링 배치에서 데이터를 읽기 위한 인터페이스이다.
배치 처리의 첫 단계에서 동작하며, 어딘가에 저장되어 있는 데이터를 하나씩 가져오는 역할을 한다.

여기서 중요한 점은, ItemReader는 데이터를 가공하거나 저장하지 않는다는 것이다. 오직 데이터를 읽어오는 것에만 집중한다.
또한 ItemReader는 데이터를 한 번에 모두 가져오는 것이 아니라, read() 메서드를 통해 한 건씩 순차적으로 반환하는 방식으로 동작한다.
이러한 구조 덕분에, 대량의 데이터를 처리하더라도 메모리 사용을 최소화하면서 안정적으로 작업을 수행할 수 있다.
정리하면, ItemReader는 배치에서 데이터를 읽어오는 시작점이자, 데이터를 하나씩 다음 단계로 전달하는 역할을 한다.

배치는 대량의 데이터를 처리하는 방식이다.
수천 건, 수만 건의 데이터를 한 번에 모두 메모리에 올려 처리하게 되면, 메모리 부담이 커지고 처리 흐름을 제어하기도 어려워진다.
이러한 이유로 Reader는 데이터를 한 번에 모두 가져오는 것이 아니라, 필요한 시점에 하나씩 꺼내어 다음 단계로 전달하는 방식으로 동작한다. 즉, Reader는 단순히 데이터를 조회하는 것이 아니라, 처리 흐름에 맞게 데이터를 공급하는 역할을 수행한다고 볼 수 있다.

이제 이 Reader를 실제로 어떻게 사용할 수 있는지 살펴보자.

ItemReader를 통해 데이터를 하나씩 읽는 방식과, 외부 API를 통해 데이터를 가져오는 방식은 이미 살펴보았다.
하지만 아직 이 두 가지가 어떻게 연결되는지는 살펴보지 않았다. 현재 코드에서는 이 연결 지점에서 ListItemReader 를 사용하고 있다.
즉, 외부 API를 통해 조회한 데이터를 리스트로 만든 뒤, ListItemReader가 이를 하나씩 꺼내어 ItemReader처럼 동작하도록 구성하고 있는 것이다.

그렇다면, 이렇게 데이터를 가져오는 방법은 ListItemReader만 존재할까?

물론 그렇지 않다.
스프링 배치는 다양한 데이터 소스에 맞게 여러 종류의 ItemReader를 제공하고 있다.
ListItemReader는 그 중 하나일 뿐이며, 상황에 따라 더 적합한 Reader를 선택할 수 있다.

예를 들어, 데이터베이스에서 직접 조회하는 경우에는 JdbcCursorItemReader나 JdbcPagingItemReader를 사용할 수 있고,
파일을 읽는 경우에는 FlatFileItemReader를 사용할 수 있다. 즉, ListItemReader는 외부에서 이미 수집된 데이터를 처리할 때 유용한 방식이며, 데이터의 출처와 특성에 따라 다양한 Reader를 선택할 수 있다.

이에 대해서는 나중에 다시 정리해보자.

결론

배치의 첫 단계인 Reader에 대해 살펴보았다. 데이터가 어디에서 들어오고, 어떤 방식으로 읽히는지에 대해 학습해보았다.
다음 시간에는 Processor에 대해 알아보자.