대규모 데이터를 배치로 처리할 때에 알아두면 좋은 내용

배치가 뭐고 왜 쓰는거지?

간단하게 말하자면 데이터나 작업 등을 자동으로 처리하는 방법이다.

사용 용도는 다음과 같다.

즉, 얘는 개발자가 직접 처리하지 않고 뭉탱이로 처리할 수 있는 용도이고 장점은

등이 있을 것이다.

배치를 사용하면 대용량 데이터를 처리할 수 있다.
그런데... 만약 그 대상이 되는 데이터가 진짜 짱많은면 어떨까?
생각을 해보면

결국은 간단하게(말로는) 해결할 수 있어 보인다.
한번에 다 해서 문제라면 그냥 따로 나눠서 하면 되기 때문.

한번에 가져오는게 문제라면?
-> 여러번에 걸쳐 들고오면 된다.

그냥 간단히 말하면 게시글 볼 때 페이지 나누는 거라고 생각하면 된다.
당연하겠지만 offset limit 은 좋지 않고, Cursor 방식을 활용하면 좋다.
마지막으로 처리한 데이터 이후로부터 들고오는 방식이라고 생각하면 되는데, 이 글을 참고해 봐도 좋을듯.

방식을 설명해 보자면, 한 10000개 정도의 데이터를 가져오려 할 때

이러면 된다.
중간에 실패한다면 그 부분만 다시 시도하면 될 것이다.

한번에 가져오는게 문제라면?
-> 여러명이 들고오면 된다.

이거는 이제 여러 배치 서버가 같이 일한다고 생각하면 된다.
나누는 것 자체는 위랑 같지만, 혼자서 여러번 하는것과 한꺼번에 나눠서 하는것의 차이다.

근데 그게 방법이 여러개가 있는데

일단은 셋의 차이는 이렇다.
정말 데이터가 많다면 사실상 분산처리가 강제되기 때문에 이 내용에서는 이거를 생각하면 될듯.

그러면 이게 어떻게 할까? 똑같이 10000개의 데이터를 처리한다고 하면
10개의 서버가 있다고 가정한다.

이러면 간단히 처리된다.
여기서 저거 어떤 값을 처리할지를 어떻게 아냐? 하면

하는 방식이 있다.
DB 부하를 줄이는 것이 좋고 데이터 분포가 균일하다면 Range를, 아니면 Modulo 를 선택하면 될 것이다.

사실 분산 처리의 경우는 합쳐서 처리하는 경우가 많다.
서버를 여러 대 운용하면서 각 서버가 잘 나눠서 처리하는 것이다.

예를 들어 10개의 서버에서 100000개 데이터를 처리해야 한다면

요런 식으로 가면 된다.
모듈로를 사용한다면

이런 식으로 가면 될 것이다.
어떤 것이 성능이 좋을지를 잘 고민하고 쓰면 좋을 것 같다.

그러면 저런 작업 중에 일부분이 실패하면 어떻게 할까?
보통은 배치에서는 작업 단위로 Transaction 을 건다.
그렇기 때문에 어떤 작업이 실패하면 그 부분에 해당하는 것들만 롤백될 것이다.

이 경우 재시도를 하면 되는데, 여기서도 좀 애매한게 있다.

재시도 횟수 고려
- 당연하지만 실패했으니 재시도를 통해 처리해야 하는데, 그게 계속 실패하면 뭔가 일시적인게 아니라 계속되는 실패일 수도 있다.
- 그러면 이거를 계속 돌리는 것 자체가 리소스의 낭비일 것이다.
- Threshold 등을 걸어, 재시도 횟수를 제한하는 것도 괜찮을 것이다.
멱등성을 보장해야 한다.
- 매우 중요한 내용인데, 배치에서 실패했을 떄 재시도를 하는 경우 원했던 결과의 멱등성을 보장해야 한다.