리포트 서빙을 정리하려고 엔드포인트를 전수로 훑다가 두 개가 410을 돌려주고 있는 것을 발견했다. 처음에는 미구현이거나 실수로 막아 놓은 것으로 보고 되살리면 되겠다고 생각했다.
Table of contents
Open Table of contents
커밋이 말한 의도
되살리기 전에 언제 이렇게 됐는지를 이력에서 찾았다. 그 상태 코드를 넣은 커밋 하나가 나왔고 메시지가 리포트 서빙 경량화였다.
의도적으로 폐기한 것이었다. 그 커밋의 설명과 관련 기록을 보니 두 엔드포인트의 실측 최대 메모리가 각각 3기가바이트를 넘었고 운영 태스크에 할당된 메모리는 1기가바이트였다.
되살렸을 때의 결과
동시 요청이 아니라 단독 호출 하나만으로도 메모리가 초과되는 상태였다. 깨진 엔드포인트로 보고 되살렸으면 배포 후 누가 한 번 부르는 순간 서빙이 죽는다.
그것도 그 엔드포인트만이 아니라 같은 프로세스의 모든 요청이 죽는데 메모리 초과는 프로세스 단위이기 때문이다. 안 되는 것을 고쳤다는 행위가 그대로 장애가 되는 구조였다.
유입을 막는 역할
그 응답이 다른 일도 하고 있었다. 캐시된 옛 페이지와 북마크와 감시 스크립트가 여전히 그 주소를 부르는데 그것을 싸게 막아 주고 있었다.
정상 응답으로 되돌리면 그 계산이 다시 돌고 라우트를 아예 없애면 유입이 다른 데로 흘러 로그를 더럽히거나 프록시 설정에 따라 다른 핸들러로 갈 수 있다. 명시적으로 그 코드를 두는 것 자체가 설계였고 지금 없다는 뜻의 코드와 있었는데 없앴다는 뜻의 코드는 다르므로 폐기에는 뒤쪽이 맞다.
폐기가 아니라 이전
그러면 그 기능은 어떻게 되는지도 확인했다. 전체 월을 일괄로 반환하던 것은 프런트가 단건 조회와 인덱스만 쓰므로 필요가 없었다.
당월 재집계는 일배치가 미리 만들어 저장소에 올리고 있어서 요청 시점에 계산할 이유가 없었다. 기능 손실이 없었고 폐기가 아니라 이전이었다. 살아 있는 경로를 전부 열거하니 여섯 개였고 폐기된 것을 빼고 나서야 이 서비스가 얼마나 단순한지가 보였다.
죽은 코드의 선별
폐기의 잔해도 확인했다. 폐기된 엔드포인트가 쓰던 캐시 변수와 잠금과 저장 함수가 선언만 남아 있었고 검색해도 선언 줄만 나왔다.
반면 리포트 키 상수는 네 곳에서 쓰이고 있어서 못 지운다. 폐기했으니 관련된 것도 다 죽었겠거니 하고 뭉뚱그려 지우면 안 되고 하나씩 사용처를 확인해야 한다.
정리
- 폐기 응답이 깨진 것이 아니라 의도적 폐기일 수 있다
- 되살리기 전에 그렇게 만든 커밋을 찾는다
- 폐기 이유가 실측 메모리면 되살리는 순간 프로세스 전체가 죽는다
- 폐기 응답은 캐시와 북마크와 감시가 보내는 유입도 함께 막는다
- 없다와 없앴다는 다른 뜻이고 폐기에는 뒤쪽이 맞다
- 폐기가 기능 손실이 아니라 이전인지 확인한다
- 살아 있는 경로를 전부 열거하면 서비스의 실제 크기가 보인다
- 죽은 코드는 하나씩 사용처를 확인하고 지운다