캐시를 지우고 재시작하는 것이 답일 때

배포했는데도 옛 코드가 도는 일이 있었고 캐시를 지우고 재시작하니 해결됐다. 왜 그랬는지는 모른 채로 넘어갔는데 다음 배포에서 같은 일이 그대로 다시 났다.

Open Table of contents

지우니 되는데 원인은 모르는 상태

지우고 재시작해서 증상이 풀리면 그 자리에서는 일이 끝난 것으로 보인다. 다만 왜 옛것이 남아 있었는지를 안 보면 다음 배포에서 같은 상태가 다시 만들어진다.

같은 일을 두 번 겪고 나서야 캐시 파일이 언제 만들어지는지를 들여다봤다. 같은 증상이 반복된다는 것 자체가 원인을 안 봤다는 신호였다.

설정을 한 파일로 미리 만들어 두는 단계가 배포 스크립트 안에 들어 있었다. 그런데 그 단계가 새 코드를 받아 오는 단계보다 앞에 놓여 있었다.

받기 전에 만들면 옛 설정으로 만든 파일이 새 코드와 함께 남으므로 배포가 끝나도 옛 설정이 이긴다. 순서를 바꿔서 받은 뒤에 만들게 하고 순서가 중요하다는 것을 주석으로 남겼다.

그래서 만들기 전에 지우는 단계를 넣어서 옛 파일이 남을 자리를 없앴다. 다만 조회 결과를 담아 둔 데이터 캐시까지 함께 지우지는 않았다.

그것까지 지우면 배포 직후에 모든 조회가 다시 채워지느라 응답이 느려진다. 지울 것과 안 지울 것을 가르는 것이 이 단계의 판단이었다.

컨테이너 안을 보니 이미지에 캐시 파일이 이미 들어 있었고 빌드 단계에서 만들어진 것이었다. 빌드 시점의 설정으로 만들어졌으므로 실행할 때 환경 변수를 줘도 그 파일이 이긴다.

그래서 빌드에서 그 단계를 빼고 컨테이너가 시작하는 시점으로 옮겼다. 설정이 실행 환경에서 정해지는 값이면 캐시도 실행 시점에 만들어져야 했다.

설정 캐시는 파일이라 지우면 다음 요청부터 반영되지만 코드 캐시는 프로세스 메모리에 있어서 재시작이 필요했다. 소스 파일이 바뀌어도 다시 읽지 않는 설정이 켜져 있었기 때문이다.

배포 스크립트 끝에 상태 확인 경로를 불러 배포 표시가 기대값과 같은지 보게 하고 다르면 실패로 끝나게 했다. 그리고 지우고 재시작한 사건은 원인과 함께 기록하게 했는데 기록하지 않으면 같은 것을 반복하기 때문이다.