Page history of 서버 프로세스를 관리하는 올바른 방법

웹사이트 개발을 완료하고 서비스할 프로덕션(production) 서버에 배치(deploy)할 때 고민하게 되는 문제 중 하나가 서버에서 띄워야 하는 여러 가지 프로세스들을 어떻게 띄울 것인가 하는 문제다. 프로세스가 죽으면 다시 띄우는 것도 물론 필요하다. monit이나 supervisord, god 등은 이런 목적으로 나온 것이다(몇 가지 부가적인 목적이 더 있긴 하다). 하지만 이건 OS에 대한 이해 부족에서 나온 것이다. 프로세스 관리는 OS의 핵심적인 기반이 되는 기능이다. 본 연구에서는 왜 monit 등이 잘못된 선택인지, 올바른 방법은 무엇인지에 대해 다룰 것이다.

monit에서 시작된 흑역사

수년 전, Ruby on Rails 개발자들 사이에서 monit이 유행을 타기 시작했다. Rails가 뜨기 전까지 웹 개발의 주류는 PHP와 자바였는데, PHP는 아파치에 모듈로 붙으니 따로 프로세스 관리를 할 필요가 없고, 자바 WAS들은 자체적인 프로세스 관리를 탑재했다. 그래서 아마도 웹 개발자가 서버의 프로세스를 어떻게 띄우고 내리고 리스타트시키는지에 대해 고민할 기회가 별로 없었을 것이다. 이런 상황에서 Rails가 탄생했는데 Rails를 돌릴 마땅한 애플리케이션 서버가 없어서 mongrel 같은 서버를 루비 개발자들이 직접 만들어서 썼다. 오픈소스다보니 자바 WAS들처럼 프로세스 관리 기능을 통째로 개발해서 탑재할 수는 없었는데 아직 Rails가 충분히 안정화되지 않은 시기다보니 mongrel 프로세스가 죽는 일이 잦았다. 프로세스가 죽는지 모니터링하다가 죽으면 살려주자는 발상을 하게 되었고, 그 결과가 monit이다. monit이 Rails + mongrel 조합의 불안정성을 개선해주면서 인기를 끌게 된 것이다.

문제는 이 목적으로 monit을 만들 필요가 없었다는 것이다. 서버를 설치하면서 띄우게 되는 여러 가지 프로세스들, 이를테면 httpd나 mysqld, crond 등을 monit이나 supervisord로 띄우는 것을 본 적이 있는가? 왜 이런 프로세스들은 monit 같은 걸 사용하지 않을까? 이런 건 프로세스가 죽었는지 모니터링할 필요도 없고 다시 살릴 필요도 없을까? 

물론 OS에서 돌아가는 모든 서비스는 쉽게 start, stop 시킬 수 있어야 하고, 죽으면 다시 살려주어야 한다. 그리고, 그 일을 해온 것이 바로 init 시스템이다. 

monit을 위한 변명

ReinventTheWheel이 늘 나쁜 것은 아니다. 더 나은 바퀴를 만들어내기도 하니까. 주로 System V에 기반하고 있던 당시의 init 시스템은 낡고 느렸다. 그리고 프로세스가 죽으면 메일을 보내준다든지 하는 모니터링 기능도 monit의 주요 기능 중 하나였는데, 이것은 init에 없는 기능이다.

running-processes

그런데도 monit 류를 쓰지 않는 것은 더 나은 시스템, 유닉스 계열에서는 이라는 시스템이 있기 때문이다. 물론 init은 오래되었고 여러 가지 부족함이 있지만 이미 현대적인 리눅스는 init의 대안으로 upstart나 systemd를 사용하고 있으므로, 이 둘 중에 하나를 쓰면 된다.