사용자 삽입 이미지사용자 삽입 이미지

그동안 별 신경 안쓰고 넘겼던 부분인데, 오늘 알아보니 두 기술이 많이 다르더군요. (request 건당 fork를 하게 되어있는 CGI 스펙의 단점을 보완하기 위해 태어났다는 공통점은 있습니다만)

FastCGI
  • 웹서버와 별도의 process로 동작. 단, 이 별도의 process를 웹서버가 뜰때 같이 띄우고 죽을때 같이 죽는 등의 컨트롤은 옵셔널하게 가능함.
  • 웹서버와 이 컨테이너는 소켓을 통해 통신
  • 컨테이너 프로세스는 언어에 독립적 (perl, php, ruby, python, 심지어 java도 가능)
mod_* (mod_perl, mod_php, mod_python...)
  • 언어엔진을 웹서버(apache)의 내부에 embed시킴.
  • 따라서 웹서버 프로세스의 크기가 증가함. (그래도 실제로는 공유되는 비율 높음)
결국, 서블릿 컨테이너 모델이 FastCGI와 같은 거였군요. 이런 모델 하에서는 이렇게되면 정적 컨텐츠를 처리하는 웹서버와 동적 컨텐츠를 처리하는 웹서버가 굳이 같은 기계 안에 있을 필요가 없으니 아키텍처상의 이점도 얻을 수 있겠네요. (물론, 컨테이너의 안정성이 확보되어야죠!!)

뱀발)

위 내용을 찾아보다가, 그동안 몰랐던 새로운 사실을 알게 됐습니다.

최근 몇년간 PHP 기반의 애플리케이션들을 작성해오면서(apache2 + mod_prefork + mod_php 썼습니다), 24시간 365일을 돌려도 웹서버를 내렸다 올려줘야 하는 일이 별로 없다는 안정성에 매우 감탄하고 있었습니다만 - 아니 이놈의 애플리케이션은 memory leak도 없나? 슬슬 죽을 때가 됐는데 뭘 이렇게 오래살지?! - 그럼 그렇지, 아파치가 관리해주는 거였군요.

http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxrequestsperchild

아파치 설정항목 가운데 MaxRequestsPerChild에 그 비밀이 있습니다. 이 항목을 100으로 설정해두면, 100개의 request를 처리한 프로세스는 무조건 죽여버리고 새 프로세스를 띄워서 우발적 memory leak을 방지하게 돼있더라는..