수만 건을 한꺼번에 바꾸지 않고 나눠서 하는 법

수만 건을 외부 시스템에 다시 보내야 했는데 한 번에 돌리면 중간에 실패했을 때 어디까지 됐는지 알 수 없었다. 나눠서 하기로 했지만 나누는 것만으로는 부족했다.

Open Table of contents

대상을 고정하는 문제

제일 먼저 부딪힌 것이 대상을 어떻게 잡느냐였다. 처음에는 아직 처리 안 된 것이라는 조건으로 잡았는데 처리하면 그 조건에서 빠진다는 문제가 있었다.

진행률을 재려고 다시 세면 숫자가 줄고 성공할수록 대상이 사라지니 아무것도 안 된 것처럼 보인다. 그래서 시작할 때 대상 식별자에 웨이브 번호를 붙여 고정하고 그다음부터는 그 번호로 대상을 지정했다. 조건이 바뀌어도 대상이 안 바뀌는 것이 이 방식의 핵심이다.

여기서도 실수를 했는데 조건에 다른 경로로 이미 완료된 것이 빠져 있어서 그것들이 계속 후보로 뽑혔다. 상태 컬럼만 보고 결과 컬럼은 안 봤기 때문이었고 조건에 결과 컬럼을 추가하고 나서야 정리됐다.

50건씩과 100건씩을 각각 돌려 보니 실패율이 달랐다. 50건일 때 8퍼센트였고 100건일 때 16퍼센트였다.

크게 잡을수록 처리 시간이 길어지면서 시간 초과에 걸리거나 잠금 경합이 나기 때문이었다. 고정값을 정하지 않고 실패율을 보면서 조절하기로 했고 실패가 늘면 크기를 줄인다.

여기가 가장 중요했다. 호출이 성공 응답을 돌려주고 실패 목록이 비어 있어도 실제로는 안 된 것이 있었는데 내부 검증에서 걸리면 아무것도 반환하지 않고 조용히 건너뛰는 경로가 있었다.

그래서 성공 판정을 데이터로 한다. 웨이브별 전체 건수와 성공 상태 건수와 외부 식별자가 비어 있는 건수를 함께 세면 응답이 무엇이라고 하든 실제 상태가 나온다. 응답은 요청이 접수됐다는 것이지 처리됐다는 증거가 아니다.

한 번은 앞단이 끊겨서 응답을 아예 못 받았는데 이때는 재시도하면 안 된다. 응답을 못 받은 것과 처리가 안 된 것은 다르고 뒤에서는 이미 접수했을 수 있어서 그대로 다시 보내면 중복이 생긴다.

그래서 그 웨이브의 실제 처리량을 세고 안 된 것만 골라 그것만 다시 보낸다. 한 번은 100건 중 8건만 실제 미처리였고 전량 재전송했으면 92건이 중복됐을 것이다.

실패한 것을 그냥 다시 보내면 대개 또 실패해서 사유별로 갈랐다. 시간 초과나 잠금 경합 같은 일시적 문제는 다시 하면 되고 필수값 누락이나 형식 불일치 같은 데이터 문제는 데이터를 고쳐야 한다.

상대가 거부하는 외부 문제는 우리가 못 고치고 애초에 보내면 안 되는 대상 아님이 나오면 대상 선정으로 돌아가야 한다. 실제로 한 번은 한 번도 등록된 적 없는 것이 대상에 섞여 있었다.

웨이브마다 건수와 성공과 실패와 사유별 내역을 기록으로 남겼다. 다음 웨이브 크기를 정하는 근거가 되고 나중에 개별 건의 경위를 추적할 수 있다. 기록을 안 남기고 진행했다가 며칠 뒤에 처음부터 다시 조사한 적이 있다.