요청 생성 이후의 남은 일

출금 요청이 접수됐다는 화면이 뜨는데 며칠 뒤에도 처리가 안 되어 있었다. 만드는 코드는 요청 행을 저장하고 바로 반환하고 있었다.

Open Table of contents

만들고 끝낸 요청

화면에는 접수되었다는 문구가 나오지만 실제로 일어난 것은 행이 하나 생긴 것뿐이었다. 그 뒤에 무엇이 그것을 처리하는지 아무도 보고 있지 않았다.

만드는 쪽 코드에는 아무 문제가 없었다. 만드는 쪽만 보면 정상이라는 결론이 나오는 구조였다.

처리 워커가 안 돌고 있었고 언제부터인지도 알 수 없었다. 대기 상태로 남은 건을 세니 며칠치가 쌓여 있었다.

요청을 남겼다는 것과 처리됐다는 것은 다른 사실인데 화면 문구가 그 둘을 하나로 보이게 만들고 있었다. 그래서 오래 대기한 건을 세어 임계를 넘으면 알리게 했다.

대기 중인 것을 상태별로 묶고 가장 오래된 것의 시각을 함께 봤다. 보내는 중 상태에 하루 넘게 머문 건이 하나 있었는데 전송 도중에 죽은 것이었다.

단계마다 정상적으로 머무는 시간이 다르므로 임계도 다르게 뒀다. 외부 응답을 기다리는 단계는 길게 잡고 내부 처리 단계는 짧게 잡았다.

워커가 주기적으로 살아 있다는 표시를 남기고 일정 시간 없으면 죽은 것으로 보게 했다. 대기 건수로 아는 것보다 빨랐다.

대기 건수는 요청이 없으면 안 늘어나므로 새벽에 워커가 죽으면 아침까지 모른다. 쌓이는 것을 보는 것과 워커가 사는지 보는 것은 다른 신호라 둘 다 필요했다.

워커가 다시 뜨면 쌓인 것을 한꺼번에 처리해 외부로 몰려 나간다. 그래서 한 번에 처리할 건수와 간격을 두고 밀린 것을 나눠 보내게 했다.

같은 구조가 다른 곳에도 있는지 찾아보니 정산 요청과 알림 예약이 같은 모양이었다. 같은 방식으로 대기와 생존을 세니 알림 예약 쪽에서 예약만 되고 안 나가는 건이 나왔다.