github stackoverflow twitter linkedin email rss
프로젝트 출시 10일 후 새벽 4시에 발생한 장애의 원인

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

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

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

  • 센트OS 서버 운영체제
  • 엔진엑스 웹서버
  • 스프링부트+제티 스탠드얼론 웹애플리케이션 서버 (이하 WAS)

당시까지만 해도 스프링부트(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