프로젝트 출시 10일 후 새벽 4시에 발생한 장애의 원인

약 3년 반 전 2013년 겨울, 맡고 있던 모바일웹 프로젝트 출시 후 문제없이 돌아가던 서버에서 10일이 지난 새벽 4시 2분에 장애가 발생했다. 출근했을 때에는 이미 시스템엔지니어링팀에서 서버를 재시작하여 문제는 복구된 상태였다. 별다른 로그는 없었고 단서는 문제가 발생했을 때 스크린캡처한 404 페이지 화면 밖에 없었다.

정확한 원인이 무엇인지 찾아내지 않으면 언제 다시 문제가 발생할지 모르는 상황.

서버 구성은 다음과 같았다.

당시까지만 해도 스프링부트(Spring Boot)가 베타 버전이었기 때문에 프로덕션에서는 활발히 사용되고 있지 않았고 스탠드얼론(Standalone) WAS 서버도 흔치 않았다. 나에게는 톰캣이 익숙했지만, 당시 그래들(Gradle)에는 스탠드얼론 서버를 운용할 수 있는 임베디드 톰캣 플러그인이 없었기 때문에 제티를 선택했다.

사내에서는 처음 시도된 방식이었고 서버구조나 운용방법도 새로웠다. 설정파일 관리, 배포방식, 스태이징(Staging) 서버 관리 등 기존 구조가 가지고 있던 많은 불편한 부분들을 해소할 수 있도록 설계하였기 때문에 위험할 수 있는 새로운 시도임에도 시스템엔지니어링팀에서도 지지해 주었다.

유일한 단서인 404 페이지를 유심히 보았다. 레이아웃이 깨어져 있었다. CSS와 이미지 파일 로딩이 안 된 것이다. 404 페이지의 HTML은 엔진엑스에서 제공되고 있었고 CSS와 이미지 파일은 WAS와 함께 있었다. 서버에 단순히 에러가 생긴 것이 아니고 파일들이 사라진 것이다.

파일들이 갑자기 왜 사라졌을까. 지금 WAS 관련 파일들이 어디에 저장되고 있지? 약간의 조사 후 명시적으로 WAR(Web application ARchive) 파일 압축을 풀 디렉터리를 설정하지 않으면 /tmp/jetty 디렉토리에 압축이 풀린다는 사실을 알게되었다.

그럼 센트OS에서 /tmp 디렉토리는 어떻게 관리되지?

센트OS 6에서 /tmp 디렉토리의 10일 이상 된 파일들은 tmpwatch 명령어에 의해 삭제된다. tmpwatchcron.daily의 일부로 들어가 있고, /etc/crontab 파일을 살펴보면 다음과 같다.

01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
github stackoverflow twitter linkedin email rss