스케줄이 없다고 기능이 없는 것은 아니다

쓰지 않는 기능을 정리하는 작업을 하고 있었는데, 후보를 뽑는 기준 중 하나가 「cron에 없으면 죽은 것」이었다.

Open Table of contents

상황 — 정리 후보로 올렸다

정산 보정 배치가 crontab에 없었고, 코드는 남아 있는데 그것을 부르는 자리가 보이지 않았다.

정리 목록에 올리고 지울 준비를 했다. 그런데 지우기 전에 로그를 한 번 더 봤다.

CloudWatch 로그에 최근 실행 기록이 있었는데, 이틀 전에 돌았고 처리 건수까지 남아 있었다.

cron이 아니라 다른 곳에서 부르고 있었고, 실행 경로를 추적하니 셋이나 나왔다.

하나는 EventBridge 규칙이 Lambda를 거쳐 부르는 것, 하나는 다른 배치가 끝나며 이어서 부르는 것, 나머지는 관리자 화면의 수동 실행 버튼이었다.

「cron에 없으면 죽은 것」이라는 기준이 실행 경로를 하나로 가정하고 있었는데 실제로는 넷이었다.

AWS로 옮기면서 스케줄이 EventBridge로 간 것이 많았고, crontab은 옮기다 만 흔적으로 남아 있었다.

판정 기준을 고치는 방법이 둘이었다. 실행 경로를 전부 열거해 확인하거나, 로그의 마지막 실행 시각만 보는 것이다.

경로를 열거하는 쪽은 정확한 대신, 새 경로가 생기면 목록을 갱신해야 하고 그것을 잊으면 같은 실수가 반복된다.

로그를 보는 쪽은 경로와 무관한 대신, 로그를 안 남기는 기능은 판정이 안 되고 보관 기간보다 주기가 긴 것은 죽은 것으로 보인다.

로그의 마지막 실행 시각을 1차 기준으로 골랐다. 경로가 늘어도 판정이 흔들리지 않는 쪽이 유지 비용이 낮았다.

로그가 없는 기능은 판정 불가로 따로 빼서, 죽은 것으로 넘기지 않고 사람이 확인하도록 했다.

보관 기간을 늘리는 것은 하지 않았다. 분기 배치를 잡으려면 90일 보관이 필요한데 그 비용이 이 판정 하나를 위해 쓸 값보다 컸다. 대신 주기가 긴 것은 목록으로 관리하기로 했다.

판정 불가로 빠지는 비율이 20%를 넘으면 기준을 다시 보기로 했다. 그 수를 넘으면 사람이 확인할 양이 자동화의 값을 넘어선 것이다.