계획을 깬 정상 메서드

대량 데이터를 새 값으로 일괄 매핑해야 했고 건수가 십만을 넘었다. 한꺼번에 전송하면 외부에 부하가 크므로 데이터를 먼저 바꾸고 전송은 나중에 나눠서 할 계획이었다.

Open Table of contents

계획과 정상 메서드

원칙대로 서비스 계층의 갱신 메서드를 쓰려 했다. 직접 질의보다 안전하다는 것이 그 원칙의 근거다.

그런데 이 계획에서는 그 선택이 계획 자체를 깼다. 무엇이 안전한가는 무엇을 하려는가에 따라 달라진다.

그 메서드를 따라가니 값을 바꾸면서 수정 이력을 하나 만들고 있었다. 별도 스케줄러가 그 이력을 읽어 전송을 만든다.

즉 이력을 만드는 순간 전송이 예약된다. 데이터만 바꾸고 전송은 나중에라는 계획이 성립하지 않고 십만 건의 전송이 한꺼번에 걸리게 된다.

요구사항에 변경 이력을 남기라는 항목이 있었다. 정상 메서드가 이력을 남기기는 하는데 일반 이력 테이블이 아니라 다른 테이블에 남겼다.

그러면 요구된 이력은 안 남고 남는 것은 스케줄러용 이력이다. 이력을 남긴다는 말이 어느 테이블을 뜻하는지까지 맞춰 봐야 했다.

더 보니 이 값이 두 테이블에 걸쳐 있었다. 내부 채널은 단일 현재값을 보고 외부 채널은 채널별 정본을 본다.

하나만 바꾸면 절반만 반영되는데 정상 메서드는 한쪽만 손댄다. 결국 직접 질의로 두 테이블을 함께 갱신하고 이력은 요구된 테이블에 따로 넣었다.

여기에 하나가 더 있었는데 상위 항목의 채널별 행도 함께 바꿔야 했다. 안 바꾸면 이후 하위를 재생성할 때 옛 값을 그대로 물려받는다.

당장은 안 보이고 나중에 드러나는 종류라 재생성 경로가 무엇을 참조하는지 확인이 필요했다. 검증에 실행보다 오랜 시간이 들었지만 그것을 안 봤으면 되돌리기 어려운 전송이 한꺼번에 나갔을 것이다.