한빛출판네트워크

by 라이언 블룸(Ryan Bloom), 역 한빛 리포터 1기 이호재 지난번 기사에서 아파치 2.0을 설정하고 설치하는 방법에 대해서 알아 보았다. 훌륭한 입문서이긴 했지만, 현재 아파치 서버를 운영하고 있는 사람에게는 그 내용이 부족할 수 밖에 없다. 사용자는 아파치 2.0을 설치하는 것뿐만 아니라 업그레이드시 서비스 다운 시간이 적었으면 하고 생각할 것이다. 이번 기사에서 다룰 내용은 apache.org 서버를 아파치 2.0으로 포팅하면서 알게 된 것이다. 첫째 베타버전이 발표되기 전인 지난 12월에 업그레이드를 했기 때문에 기존과 약간 달라진 기능이 있을 수 있지만, 이 기사의 내용은 모두 적용 가능하다. 공로는 그렉 에임즈(Greg Ames)에게 돌려야 한다. 필자는 아파치 2.0이 작동하고 있는 apache.org를 결코 보지 못했다. 포팅을 시작하긴 했지만 개인적 이유로 끝마치지 못했고, 그렉 에임즈가 뒤를 이어 끝내야 했다. 필자는 그가 작업하는 것을 지켜 보았고, 직면한 문제 중 일부를 도와주기도 했지만, apache.org를 2.0서버로 업그레이드하는 데 성공한 사람은 필자가 아니라, 그렉이다. 업그레이드 계획을 세우면서 가장 중요시했던 것은 apache.org에서 제공하는 서비스를 그대로 지원하는 것이었다. apache.org는 방문자수가 가장 많은 사이트는 아니지만, 하루에 절반은 많은 사용자로 붐빈다. 그래서 사이트가 다운된다면 사람들이 알아차릴 것이었다. 이런 생각으로 아파치 2.0을 8091 포트에 설치했고, 잘 작동되는지 살펴보기 위해 사람들에게 알렸다. 사람들이 그 서버를 일주일동안 테스트했고, 그 후 기본 웹 서비스인 80번 포트로 옮겼다. 멀티프로세싱 결정 서버를 설치하기 전에 몇 가지 결정을 해야 했다. 아파치 2.0의 설정은 아파치 1.3에 비해 훨씬 유연하기 때문이다. 첫째 결정 사항은 어떤 멀티프로세싱 모듈(MPM)을 사용할 것인가였다(MPM를 자세히 알고 싶으면, 필자의 첫째 기사를 참조하자). 필자는 prefork MPM으로 설정할 것을 제안한다. 아파치 2.0에서 많은 것이 변화되었기 때문에 잘 작동하는 기존의 모델(우리가 잘 알고 있는)을 사용해서 시작하는 것이 좋다. 물론 일단 새로운 아파치 2.0이 작동해서 웹 페이지를 서비스하면, 어떤 MPM이 사용자의 서비스에 가장 적합한지 새로운 MPM을 실험해 보고 결정하면 된다. MPM은 프로세스와 스레드가 생성되는 방식을 넘어서 사용자의 서버에 영향을 미칠 수 있다. 가장 적합한 예가 mod_cgid이다. 대부분의 유닉스에서는 스레드 프로세스를 잘 생성하지 못한다. 새로운 싱글 스레드 프로세스를 생성하는 대신, 모든 스레드를 포함한 전체 프로세스를 복사한 다음 하나의 스레드만 남기고 없애는 경우가 많다. 그래서 이는 프로세스를 생성하는 가장 효율적인 방법이 결코 아니다. 아파치 개발자는 아파치가 새로운 CGI 프로세스를 생성하기 위해 사용하는 CGI 데몬을 해결책으로 내놓았다. 이 데몬 프로세스는 다른 프로세스가 생성되기 전에 만들어지는 싱글 스레드 프로세스이다. CGI 요청을 CGI 데몬으로 보내면, 데몬 프로세스는 새로운 CGI 프로세스를 생성한다. CGI 프로세스는 클라이언트에게 보내는 결과 데이터를 자식 프로세스에 보낸다. 이 모듈은 표준 모듈인 mod_cgid처럼 진일보한 모듈이 아니므로, 서버를 threaded MPM으로 시작한다면, CGI 요청이 문제를 일으키기 때문에 mod_cgid로 다운그레이드해서 문제가 계속되는지 살펴봐야 한다. mod_cgid는 threaded MPM과 작동은 잘하지만 성능은 최적화되지 않는다. 필터 설정 아파치 1.3과 아파치 2.0의 주요한 차이점은 필터를 추가했다는 것이다. 프로그래머에게 필터는 다른 모듈이 생성한 데이터를 수정하는 강력한 수단이 되고, 관리자에게는 완전히 새로운 생각을 갖게 한다. 필터를 구현한 표준 모듈은 mod_include뿐이기 때문에 이 모듈에 초점을 맞춰 설명할 것이다. 아파치 1.3에서.shtml 파일을 SSI로 파싱하려면, 다음과 같은 설정을 사용한다.

AddHandler server-parsed .shtml

아파치 2.0에서는 핸들러가 없기 때문에 위 설정은 동작하지 않는다. 대신 다음과 같은 INCLUDES 필터를 추가해야 한다.

SetOutputFilter INCLUDES

이 지시자는 클라이언트로 가는 모든 데이터를 SSI로 파싱하게 하는데, 파일, 디렉토리, 혹은 위치(Location containers)에 쓰인다. 이는 사용자의 설정 파일이 더 커지고 해석하기 어려워 지며, 아파치에서 mime 타입이나 Handler가 더 이상 중요한 의미를 가지고 있지 않다는 뜻이다. 데이터를 생성하는 대부분의 모듈은 디스크에서 파일을 읽기 위해 기본 핸들러를 사용할 것이고, 그 데이터를 수정하기 위해 필터를 사용할 것이기 때문이다. IPv6와의 문제 우리의 서버를 셋팅하는 것이 원래 생각했던 것보다 훨씬 어렵게 되었다. 첫째 문제는 가상 호스팅(virtual hosts)에 관한 것이다. 한 컴퓨터가 apache.org 사이트의 모든 주소를 호스팅하는데, 이는 명백히 아파치 서버의 장점이라 생각해 왔다. 문제는 apache.org가 IPv4와 IPv6를 모두 인지할 수 있는 시스템에서 돌아갔다는 것이다. 아파치 2.0은 IPv6를 자동으로 지원하는데, IPv6를 지원하는 플랫폼에서 너무 잘 동작했던 것이다. 즉, 플랫폼이 IPv6를 지원한다면 Apache 2.0이 IPv4를 사용하기 매우 어렵다는 게 문제였다. 아파치 개발자들은 어떤 종류의 주소가 쓰일지 결정하기 위해 설정 플래그를 사용하자고 했지만 이 지시자는 아직 구현되지 않았다. 지금 서버에 접속하는 데 문제가 있다면, 그 문제는 아마도 IPv6 지원일 것이다. 이 문제를 해결하기 위해서는 모든 설정 파일에서 IP 주소를 지정하기 위해 * 지정자를 사용해야 한다. 그러면 서버가 모든 주소에 대해 같은 포트로 바인딩한다. 일단 서버가 8091 포트로 동작하게 하면, 일주일 정도 돌려 보고 실제 서비스를 하도록 해야 한다. 실제로 우리가 해 보았을 때, 서버가 실제 서비스를 할 만큼 안정적이지 않았고 서버는 몇 시간 동안 작동하다 멈춰버렸다. 왜 이런 일이 일어났을까? 서버를 테스트했다고 해서, 실제 서버처럼 잘 동작해야 하는 것은 아니다. 찾기 힘든 조그마한 버그를 일으킬 수 있는 브라우저간의 미묘한 차이가 많이 있기 때문이다. 결론 위의 기사는 apache.org를 1.3에서 2.0으로 업그레이드하면서 겪은 문제를 다루었다. 이 기사가 여러분이 아파치 2.0으로 업그레이드 하면서 겪게 될 모든 문제를 다루지는 않았지만, 일반적인 문제에 대한 답변과 업그레이드를 위한 초석을 제공했으면 한다. 필자는 아파치가 사용자들의 피드백이 있을 때 더욱 좋아진다고 말한 적이 있다. 여러분이 해결할 수 없는 문제가 발생하면, http://bugs.apache.org에 있는 버그 데이터베이스에 버그포스팅을 하자. 그리고 이 사이트에 언급되어 있는 뉴스그룹을 이용하면 더 많은 정보를 얻을 수 있다. 아파치 개발자들은 뉴스그룹에서 많은 시간을 보내고, 어떻게든 도움을 줄 수 있을 때 행복함을 느낀다. 다음 기사에서는 필터를 작성하는 법과 한 모듈이 다른 모듈을 수정하는 새로운 방법에 대해 다룬다.

---

라이언 블룸(Ryan Bloom)은 Apache Software Foundation의 멤버이며, Apache Portable Run-time 프로젝트의 부사장이다. 이호재님은 한빛 리포터 1기로 활동 중입니다. 카드코리아 개발 실장으로 근무한 경험이 있으며, 지금은 서울대 지구환경시스템공학부(컴퓨터 공학)에 다니고 있습니다. 컴퓨터에 관련된 모든 분야에 두루 관심이 많으며, 요즈음엔 파이썬, MPI, PHP 등에 관심이 많다고 합니다.