NGINX 캐시 삭제 시 오류 로그에 중요한 연결 해제 오류가 기록됨
게시됨: 2025년 2월 15일 오전 11시 24분 15초 UTC
이 문서에서는 오류 메시지로 로그 파일이 어지럽지 않게 NGINX 캐시에서 항목을 삭제하는 방법을 설명합니다. 일반적으로 권장되는 방법은 아니지만 일부 예외적인 경우에는 유용할 수 있습니다.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
이 게시물의 정보는 Ubuntu Server 14.04 x64에서 실행되는 NGINX 1.4.6의 FastCGI 캐싱을 기반으로 합니다. 다른 버전에서는 유효할 수도 있고 그렇지 않을 수도 있습니다.
(2025년 업데이트: 원래 글을 쓴 이후 지금까지 많은 것이 바뀌었습니다. 서버는 더 빠르고 저렴해졌기 때문에 이 글에서 설명한 접근 방식, 즉 동적 콘텐츠의 몇 세대를 더 절약하기 위해 캐시 만료를 세부적으로 관리하는 방식은 권장하지 않습니다. 나중에 참고할 수 있도록, 그리고 어떤 이유로든 실제로 필요한 사람이 있을 경우를 대비해 내용을 여기에 남겨두겠습니다. 이것이 현재 버전의 NGINX에서도 여전히 작동하는지 확인하지는 못했지만, 작동할 것이라고 생각합니다.)
여러 사이트를 Apache에서 NGINX로 마이그레이션한 후로 저는 내장된 캐싱 기능을 매우 좋아하게 되었는데, 제가 별도로 간섭하지 않아도 대부분의 상황에서 매우 잘 작동했습니다.
하지만 사이트 중 하나에서는 캐시를 완전히 지우거나 개별 항목을 제거하는 기능이 정말 필요했습니다. NGINX의 무료 커뮤니티 에디션은 시간 기반 캐시 만료만 지원합니다(즉, 1시간, 1일 등 후에 무언가가 변경되었는지 확인하도록 설정할 수 있습니다). 하지만 특정 리소스가 언제 변경될지 미리 확인할 수 있는 신뢰할 수 있는 방법이 없다면 어떨까요? 예를 들어, 이 게시물에서 무언가를 다시 편집하기까지 1시간, 1일 또는 1년이 걸릴지 전혀 알 수 없습니다. 그리고 1일 동안 캐싱하는 것이 괜찮았을 텐데 왜 1시간 동안만 캐싱해야 할까요?
여기서 캐시를 수동으로 지울 수 있는 기능(또는 웹 애플리케이션에서 NGINX에 무언가를 제거해야 한다고 알리는 기능)이 필요합니다. NGINX를 만든 사람들은 이 기능이 유료 버전의 제품에서 지원되기 때문에 이 기능의 필요성을 분명히 알고 있습니다. 하지만 그들이 원하는 대로 라이선스를 설정할 수 있는 권한이 확실히 있지만, 이 기능이 제가 정말 필요로 하는 유일한 유료 기능인 경우 가격이 약간 비쌉니다.
다행히도 캐시 디렉토리에서 파일을 직접 삭제하면 NGINX가 이를 알아채서 아무런 문제 없이 백엔드에서 새 사본을 가져옵니다. 하지만 구성을 조정하지 않고 이 작업을 수행하면 잠시 후 오류 로그에 이와 비슷한 메시지가 많이 표시될 가능성이 높습니다.
이러한 오류는 NGINX 자체가 fastcgi_cache_path 지시문의 inactive 매개변수에서 지정한 시간 이후에 캐시 항목을 삭제하려고 할 때 발생하는 것으로 보입니다. 기본값은 10분에 불과하지만 원하는 값으로 설정할 수 있습니다. 예를 들어 10년으로 설정하면 그동안 서버를 다시 시작하지 않았을 가능성이 높으므로 메모리의 키 인덱스가 그동안 지워졌을 것입니다. 이렇게 하면 캐시를 직접 지워야 합니까 ? NGINX가 더 이상 대신 지워주지 않습니다.
캐시 항목이 존재하지 않기 때문에 삭제할 수 없다는 것이 심각한 오류로 간주된다는 것이 정말 이상합니다. 심각도 분류가 너무 높다는 사실은 특정 임계값 아래의 로그 항목을 무시하는 것만으로는 제거할 수 없다는 것을 의미합니다. 백엔드에서 새 사본을 가져오는 즉시 항목이 다시 존재하므로 제 생각에는 기껏해야 경고일 것입니다.
이제, 권한 문제나 다른 이유로 캐시 항목을 삭제할 수 없다면, 그것은 심각한 오류일 것입니다. 왜냐하면 NGINX가 만료 시간이 지난 후에도 캐시된 콘텐츠를 계속 제공할 수 있기 때문입니다. 하지만 정리 프로세스에서는 이러한 구별이 이루어지지 않는 듯합니다.