(연관된 글이 1개 있습니다.)
정말이지, Microsoft가 IIS 6.0을 설계한 방식에 대해서는 감탄을 자아내게 합니다.
Kernel 단계로 내린 http.sys는 다른 어떤 웹 서버도 따라올 수 없는 경지이죠. 운영체제를 만든 업체로서 시도해 볼 수 있는 커널 드라이버로의 이전은 대단한 성능 개선으로 이뤄집니다.
(32bit 윈도우즈 기준으로 설명하면)
Kernel 드라이버는 그 특성상 2GB ~ 4GB 가상 메모리에 존재하게 됩니다. 그러면서, 프로세스 전역적으로 매핑이 되어지게 되죠. IIS 5.0/5.1 같은 경우에는 inetinfo.exe가 받아들인 요청을, 그것을 처리해야 하는 worker process로 전달하기 위해서 Named Pipe 또는 TCP/IP를 별도로 사용해야 했습니다. 즉, 부하가 심한 프로세스 간 통신(Inter-process Communication)을 사용해야 했지요.
반면에, IIS 6.0에서는 전역적으로 가상 메모리에 매핑되는 커널 단에 존재하기 때문에 결국 받아들인 요청은 w3wp.exe 프로세스 메모리에 매핑되어 있는 효과와 같게 됩니다. 프로세스 간 통신 부하 자체가 없어진 것이죠. 이를 도식화해서 표현한 그림을 아래에 보여주고 있습니다. (2가지 그림 모두 MSDN 사이트에서 가져온 것입니다.)
[그림 1: IIS 5.0 구조]
[그림 2: IIS 6.0 구조]
이렇게 IIS 6.0에 대해서는 여러 가지 칭찬해 줄 만한 것들이 있긴 하지만, 개인적으로 "최고"로 꼽는 기능이 바로 AppPool을 이용한 실제 서비스의 디버깅 환경 구성입니다.
아시는 것처럼, 디버깅 프로세스를 attach 시킨 후 예외 상황이 발생하면 프로세스 스케쥴링은 완전히 중지하게 됩니다. 현재 서비스 중인 웹 애플리케이션을 디버깅할 수 없는 원인이 바로 여기에 있죠. 해당 예외가 발생한 스레드 뿐만 아니라, 프로세스에 존재하는 모든 스레드가 중지되기 때문에 사용자들이 전혀 사용할 수 없는 상황이 되어버립니다.
VS.NET에 원격 디버깅 기능이 있다고 해도 실제로 많은 효용성이 없는 이유가 바로 여기에 있습니다. 서비스 오픈 하기 전의 운영 장비에서 발생하는 특별한 버그를 잡을 때 정도만이 사용될 수 있을 뿐, 일단 서비스가 시작되면 원격 디버깅은 무용지물이 됩니다. 물론, 사용자들이 접속하지 않는 시간대를 선택하면 가능하겠지요. ^^ 그래도, 그런 상황의 개발자는 안스러울 따름입니다.
그동안 IIS 5.0/5.1에서는 불가능했지만, IIS 6.0의 AppPool을 이용하게 되면 서비스 중인 웹 응용 프로그램에 지장을 주지 않고도 그와 동등한 환경에서 디버깅을 할 수 있습니다. 벌써, 이 말만 듣고도 감을 잡으셨을 분이 계시겠지만, 간단하게 과정을 설명드리겠습니다.
1. 임시로 사용될 "웹 사이트"를 만듭니다. 아래와 같이, IP 및 포트는 동일하게 유지면서, 호스트 헤더값만 달리 합니다.
2. 만들어진 웹 사이트는 다음과 같습니다. 보시는 것처럼 이름은 "디버그 웹 사이트"로 되어 있으며, 루트 디렉터리 또한 "기본 웹 사이트"와 동일한 곳으로 설정을 했습니다.
3. 이제 w3wp.exe 프로세스를 달리 설정할 수 있도록 별도의 AppPool을 만들어야 합니다. 최대한 실제 서비스 환경과 동일하게 하기 위해 AppPool 역시 다음 그림과 같이 "기존 응용 프로그램 풀을 템플릿으로 사용"을 선택해서 만듭니다.
4. 자, 이제 적절한 URL(예제의 경우 http://debug.sysnet.pe.kr)로 네비게이션을 하면, 새로운 w3wp.exe가 서버에서 구동되게 됩니다. 원래의 서비스는 또 다른 w3wp.exe에서 변함없이 동작하고 있으므로, VS.NET 원격 디버깅으로 새롭게 생긴 w3wp.exe 프로세스에 대해 디버깅을 시작할 수 있습니다.
별거 아닌 것처럼 보일 수도 있지만, 실제 운영 서버에서만 발생하는 오류들을 디버깅할 수 있다는 것은 다른 여타의 웹 서버와는 비교할 수 없는 장점을 제공해 줍니다.
[연관 글]