주) 이 글은 마소 편집부에 제가 발송한 원고를 약간 편집하여 올린 글입니다. 따라서 마소에 실린 글과는 약간의 차이가 있을 수 있습니다.

IIS 6.0

Subtitle : 웹 어플리케이션의 따스한 안식처 IIS 6.0

• Windows .NET Server
• IIS 6.0의 주요 기능들
     Core Architecture
     ProcessModel
        IIS 5.0 Isolation Mode
        Worker Process Isolation Mode
     Web Administration Service
• 안정성 (Reliability)
     Application Pool
     Recycling
     Health Monitoring
     Performance Management
• 보안 (Security)
• 메타베이스
• 그 밖의 것들
• 참고문헌

1월… 희망찬 기대로 닷넷 엔터프라이즈 아키텍처에 대한 내용을 칼럼으로 쓴지가 엊그제 같은데 벌써 한 해를 마무리해야 하는 12월이 다가왔다. 올해 3월에 출시된 Visual Studio .NET과 .NET Framework는 ‘정식’ 제품이라는 의미 외엔 큰 이슈가 아니였다. 이미 지난해부터 베타 버전을 통해 많은 프로그래머들에게 이미 접했기 때문이리라… 발표 이후에 나온 2번의 서비스 팩과 서비스 팩에서 수정되지 않은 몇몇 문제들은 필자를 괴롭히기도 했지만 안정화를 향해 한발씩 나아가는 것이라 생각하고 냉수를 벌컥였다. 필자가 2002년을 회고해 보면 닷넷의 정식 출시를 빼고는 닷넷과 관련된 큰 이슈는 없었다고 본다. 웹 서비스가 곧 시대의 대세일 것처럼 IT를 휩쓸었고 벤더와 언론은 웹 서비스라는 주제로 앨범 몇 장을 냈을 정도로 노래를 불렀지만 정작 웹 서비스라는 기술로서 우리 피부에 와 닿는 것은 없다는 것에 쓴 웃음을 짓게 한다. 그러나 앞으로는 더 구체적이고 실질적인 것들이 웹 서비스와 접목될 것이라는 것을 의심하지 않는다. 다만 너무 성급히 “앞으로는 이것이 대세이다” 라고 외쳐버리고 앞서 달려나가다 지쳐버리는 자세를 지양해야 하지 않을까 하는 바람이다.

12월에는 한 해를 마무리하고 정리를 해야 하겠지만… 이번 칼럼의 주제는 정리하고 관계가 먼 것이다. 이번 칼럼은 Windows .NET 서버에 새로이 포함된 IIS 6.0에 대한 내용을 다루어 보고자 한다. 특히, 웹 프로그래밍의 관점에서 바라본 IIS 6.0의 새로운 기능들과 이것이 어떻게 ASP 나 ASP .NET 웹 프로그래밍 모델에 영향을 미치는가 살펴볼 것이다. IIS 6.0은 웹 어플리케이션들을 위한 다양한 기능들이 제공된다. Windows .NET과 IIS 6.0은 운영체제에 포함된 닷넷 프레임워크, 보다 나은 수행환경, 편리한 관리환경, 높은 성능 등을 무기로 웹 어플리케이션들을 단꿀과 물엿, 조청과 엿기름, 버터와 쇼트닝유가 흐르는 안락한 웹 서버로 인도할 것이다.

여기서 소개하는 내용들이 IIS 6.0에서 변화되거나 추가된 사항들의 모두는 아님에 유의해야 할 것이다. Windows .NET 서버가 이전 Windows 2000 Server에 비해 바뀌거나 추가된 기능들을 살펴보려면 마이크로소프트의 공식 페이지를 확인하기 바란다. 이 칼럼은 Windows .NET Server에 대한 소개의 글이 아니다. 따라서 Windows .NET Server를 어떻게 설치하며 설치한 후에 바뀐 점, 소감 등등을 전혀 다루지 않을 것이다. 다만 독자들이 Windows .NET에서 ASP .NET을 수행할 수 있도록 하는 부분만을 간단히 다루게 될 것이다. 정식 버전이 아닌 제품의 기능을 소개할 때 빠짐없이 등장하는 말이지만 다시 한 번 해야 할 것 같다. 이번 칼럼에서 소개할 Windows .NET과 IIS 6.0의 기능은 RC(release candidate) 버전의 내용이므로 예고 없이 최종 버전에서 바뀔 수 있다는 점이다. Windows 2000의 In-Memory 데이터 베이스의 교훈을 잊지 말자(Windows 2000 베타에 포함되었던 In-Memory 데이터베이스 기능이 정식버전에서는 조용히 사라졌었다!).

Windows .NET Server

Windows .NET Server는 Windows 2000 Server의 차기 운영체제이다. 마이크로소프트의 이름 짓는 방식에 많은 사람들이 혼동을 겪고 있는데 소위 말하는 Windows 운영체제의 로드맵을 살펴보면 쉽게 이해할 수 있다. 표 1은 간략한 로드맵을 보여주고 있다. 2003년까지 마이크로소프트의 운영체제는 Windows XP Home edition으로 대표되는 가정용 운영체제와 기업용으로 Windows XP Professional, 그리고 이들 운영체제에 상응하는 서버 운영체제가 Windows .NET Server 제품군인 것이다. Windows .NET Server 제품군은 다시 Web Server edition, Standard edition, Enterprise edition, 그리고 Datacenter edition으로 나누어 진다. Windows .NET Server 제품군의 각 에디션에 대한 상세한 내용은 마이크로소프트 홈페이지를 참고하기 바란다.

표1. Windows 운영체제 로드맵

Windows .NET Sever가 이전 버전에 대한 특징으로는 다음과 같은 것을 들 수 있다.

• .NET Framework 통합
• 웹 서버 기능 강화 (IIS 6.0)
• Web Application Server로서의 기능 제공
• UDDI 서비스 제공
• 보안 강화
• XML Web Service로 최적화

요약해 보자면 Windows 2000에서부터 그래왔듯이 운영체제가 보다 많은 기능을 제공하겠다는 말과 일맥 상통한다. Windows .NET 이라는 이름에서 짐작할 수 있듯이 닷넷 프레임워크가 운영체제와 함께 자동으로 설치되며 IIS 6.0은 기본적으로 ASP .NET을 통해 웹 서비스를 제공할 수 있다. 또한 COM+와 IIS 6.0은 고가의 WAS(Web Application Server) 제품이 제공하는 기능들을 모두 제공한다. 보안에 관련된 사항을 간단히 언급하자면, Windows 2000에서는 기본적으로 설치되고 즉시 사용 가능한 상태로 제공되었던 것들이 이제는 사용자가 명시적으로 설치하거나 셋업 해주어야만 사용이 가능하도록 되어 있다. 예를 들어 Windows .NET 서버를 설치하면 IIS가 기본적으로 설치되지 않으며 서버 관리자(필자주: 지금은 사용자 서버 관리 란 이름으로 관리도구에 포함되어 있다) 쯤으로 불릴 “Manage Your Server” 를 통해 서버에 역할을 주면 그 역할에 맞는 소프트웨어들이 설치되곤 한다. 화면 1은 Web Application Server 역할(role)을 설정 받은 후에 나타나는 서버 관리자의 모습을 보여주고 있다. Web Application Server의 역할이 주어지면 Windows .NET 서버는 IIS를 설치하고 COM+ 관련 설정을 수행하며 필요에 따라 Front Page Extension 등을 설치하게 된다.

다시 본론으로 돌아와 Windows .NET 서버는 Windows 2000 때부터 시도했던 운영체제가 WAS를 대신한다는 목표를 점차로 완성해가는 듯 싶다. 실제 Windows 2000 역시 WAS의 핵심 요소인 웹 서버와 미들웨어로서 IIS 5.0/COM+ 1.0을 지원했지만 그 기능이 상용 WAS 만큼이나 풍부하지는 않았던 것이 사실이다. 하지만 IIS 6.0, COM+ 1.5로 무장된 Windows .NET 서버는 이제 WAS 제품들과 비교되어도 크게 손색이 없을 만큼이나 탄탄한 어플리케이션 기반 구조를 갖게 되었다. 물론 운영체제가 WAS 기능까지 해야 하는가에 대한 논란은 여전히 남아 있지만 말이다.

화면 1. 사용자 서버 관리 화면(영문판)

IIS 6.0의 주요 기능들

이제부터 IIS 6.0의 주요 기능들을 살펴보도록 하자. IIS의 버전 별 변화 사항은 표 2에 나타낸 바와 같다. IIS가 주목 받기 시작한 것은 Windows NT 4.0의 옵션팩(Option Pack)으로 제공된 IIS 4.0부터 라고 할 수 있다. 그리고 Windows 2000에서는 기존 버전에 비해 탁월하게 향상된 성능과 Windows 2000에 포함된 로드밸런싱 및 클러스터링 기능 그리고 닷컴 회사의 붐을 타고 IIS는 가장 많은 웹 사이트를 호스팅하는 웹 서버로서 자리매김하고 있다. 그리고 Windows .NET 서버와 함께 다양한 기능들로 새롭게 무장하고 새로이 6.0이 등장한 것이다.

표2. IIS 버전별 차이점 및 변화 사항들 발췌

Core Architecture

IIS 6.0이 이전 버전에 비해 가장 두드러지게 달라진 부분을 꼽으라면 바로 IIS가 기본적으로 작동하는 방식이 달라졌다는 것일 것이다. 거두절미하고 말하자면 웹 서비스(WWW 서비스)를 위해 80 포트를 리스닝(listening)하는 주체가 inetinfo.exe가 아닌 Windows .NET 커널 드라이버(HTTP.SYS)로 바뀌었다. 즉, 80 포트는 커널 모드에서 작동하는 HTTP.SYS 디바이스 드라이버가 리스닝하며 이 드라이버가 80 포트로부터 수신되는 HTTP Request를 읽어 적절한 웹 어플리케이션들에게 이들을 분배해 주게 된다. 구체적으로 어떻게 이들 request가 분배되는가는 조금 후에 살펴보도록 하고, HTTP.SYS 드라이버가 80 포트를 리스닝 함으로서 달라지는 사항에 대해 살펴보자.

그림 1. IIS 5.0과 IIS 6.0의 기본 아키텍처

IIS 5.0은 다른 WINSOCK 어플리케이션과 크게 다를 바 없이 80 포트를 리스닝 했었다. 80 포트의 리스닝 주체는 inetinfo.exe 프로세스였으며 다소 최적화는 되어 있더라도 기본적으로는 WINSOCK을 통해 80 포트를 리스닝 했었다. 이는 TCPIP를 관장하는 TCPIP.SYS를 통해 HTTP 서비스 요청을 처리했음을 의미한다. Inetinfo.exe에 의해 수신된 HTTP Request들은 웹 어플리케이션 설정에 따라 적절한 웹 어플리케이션들에게 배포되었고 웹 어플리케이션은 이를 처리하고 다시 inetinfo.exe를 통해 클라이언트(웹 브라우저)에게 결과를 전송했었다.

Windows .NET에서는 80 포트를 리스닝 하는 주체는 더 이상 inetinfo.exe가 아니다. 80 포트는 커널 모드 드라이버인 HTTP.SYS가 수행하며 이 드라이버가 HTTP 요청을 받아 적절한 웹 어플리케이션들에게로 넘겨주게 된다. 결과를 클라이언트에게 넘겨줄 때 역시 HTTP.SYS가 역할을 담당하게 될 것이다. 이것이 의미하는 바는 첫째로 성능 향상을 들 수 있겠다. 그림 1에서도 볼 수 있듯이 inetinfo.exe 프로세스를 사용하지 않기 때문에 병목현상을 줄일 수 있고 WINSOCK 계층 역시 거치지 않으므로 오버헤드를 줄일 수 있다. 운영체제를 제공하는 마이크로소프트 만이 할 수 있는 꽁수라고 말하지 않을 수 없다. 마이크로소프트에 의하면 커널 모드 포트 리스닝으로 20~30%의 성능향상을 가져올 수 있다고 한다. 하지만 IIS 6.0이 정말로 이 정도의 성능향상을 가져오는 지는 필자도 아직 테스트 해 보지 못했으며 의문사항일 뿐이다.

두번째 의미는 안정성 향상이다. Windows 2000에서는 inetinfo.exe가 중단되면 전체 웹 서비스 자체가 중단 되었었다. 80 포트를 리스닝 하는 프로세스가 중단되었으니 웹 서비스가 중단됨은 당연한 일일 것이다. 하지만 Windows .NET 에서는 80 포트를 리스닝 하는 주체가 프로세스가 아닌 커널이므로 특정 프로세스의 중단으로 인한 웹 서비스의 중단은 발생하지 않는다. 다만 커널이 다운되면 웹 서비스 역시 중단될 것이다. Windows .NET 서버가 어느 정도 안정적이라고 가정한다면 웹 서비스의 안정성은 올라간다고 말할 수 있다. 하지만 Windows .NET 서버가 안정적이지 않다면?

Inetinfo.exe와 관련하여 언급할 사항은, 이 프로세스가 여전히 사용되며 예전만큼은 아니더라도 여전히 중요하다는 점이다. Inetinfo.exe 프로세스는 여전히 FTP, NNTP, SMTP 서비스를 제공하며 In-memory 메타베이스를 보유하고 있다. 따라서 이 프로세스가 정지된다면 FTP/NNTP/SMTP 서비스와 더불어 메타베이스 서비스 역시 제대로 제공되지 않을 것이다.

Process Model

IIS의 핵심 아키텍처가 변화함에 따라서 웹 어플리케이션이 수행되는 프로세싱 모델 역시 변화되는 것은 당연하다. Windows 2000에서는 HTTP 서비스 요청은 inetinfo.exe 가 수신하고 요청된 URL과 메타베이스 설정, 즉 어떤 URL이 어떤 웹 어플리케이션과 매핑 되며 이 웹 어플리케이션의 응용 프로그램 보호(application isolation)가 어떻게 되는가에 따라서 HTTP 요청은 적절히 분산되었다. 예를 들어 사용자가 http://svr/app1/test.asp를 요청했다고 가정해 보자. Inetinfo.exe는 /app1 디렉터리의 응용프로그램 보호 수준을 살펴볼 것이며 이것이 ‘높음’ 혹은 ‘중간’ 이라면 별도의 dllhost.exe 프로세스로 클라이언트 요청을 넘겨주며, 보호 수준이 ‘낮음’ 이라면 inetinfo.exe 내의 어플리케이션에게 클라이언트 요청을 넘겨 주었을 것이다.

IIS 6.0에서는 HTTP 서비스 요청은 HTTP.SYS 드라이버가 수신한다. 그리고 이전에 inetinfo.exe가 수행하던 모든 작업을 HTTP.SYS 가 수행하게 된다. 즉, 메타 베이스의 정보에 근거하여 어떤 웹 어플리케이션 프로세스에게 수신된 HTTP 요청을 넘겨줄 것인가를 HTTP.SYS가 결정하며 웹 어플리케이션의 수행 결과 역시 HTTP.SYS가 클라이언트에게 다시 넘겨주게 된다. IIS 6.0 은 이러한 웹 서비스(여기서 웹 서비스라 함은 SOAP 기반의 협의의 웹 서비스를 지칭하는 것이 아니라 HTTP 프로토콜을 사용하는 광의의 서비스를 지칭한다) 프로세싱과 관련하여 크게 두 가지 모드를 가지고 있다. 첫 번째 모드는 IIS 5.0 Isolation Mode로 불리는 IIS 5.0과 유사한 프로세싱 모드이다. 두 번째 모드는 IIS 6.0의 디폴트인 작업 프로세스(worker process) 모드이다. 이제 이들에 대해 살펴보도록 하자.

IIS 5.0 Isolation Mode

IIS 5.0 Isolation Mode는 IIS 5.x와 호환성을 위해 제공되는 모드이다. 이 모드는 디폴트로 사용되지 않으며 이 모드로 전환하기 위해서는 인터넷 서비스 관리자에서 Web Sites를 선택하고 등록정보를 클릭하면 나타나는 ‘웹 사이트 등록 정보(Web Sites Properties)’ 대화 상자를 이용해야 한다(화면 2). 이 대화 상자의 서비스(service) 탭을 클릭하면 Isolation mode를 바꿀 수 있으며 IIS 5.0 Isolation mode를 사용하면 웹 서비스는 다시 시작되어야 한다. 후에 설명할 작업 프로세스 모드와 IIS 5.0 모드는 공존할 수 없으며 두 모드 중 하나만이 사용될 수 있음에 유의해야 할 것이다.

화면 2. IIS 5.0 Isolation Mode 전환을 위한 대화상자

그림 2는 IIS 5.0 모드의 처리 상황을 보여주는 그림이다. 앞서 설명한 대로 HTTP request는 HTTP.SYS에 의해 수신되며 이 request는 곧바로 inetinfo.exe로 넘겨진다. Inetinfo.exe는 메타 정보에 근거하여 응용프로그램 보호 수준이 ‘낮음’ 인 어플리케이션은 inetinfo.exe 프로세스 내에서 처리하고, 보호 수준이 ‘보통’ 혹은 ‘높음’ 인 어플리케이션은 별도의 dllhost.exe 프로세스에서 처리하게 될 것이다. 한가지 주의해서 보아야 할 사항은 dllhost.exe 프로세스로 request를 넘겨주는 주체는 HTTP.SYS가 아닌 inetinfo.exe라는 점이다.

그림 2. IIS 5.0 Isolation Mode

ASP(Active Server Page)라면 그림 2로 충분한 설명이 될 것이다. 하지만 ASP .NET 이라면 어떻게 될까? ASP .NET 웹 어플리케이션은 inetinfo.exe나 dllhost.exe에 의해 호스팅 되지 않는다는 것을 독자들은 알고 있을 것이다. IIS 5.0 격리 모드에서 ASP .NET 웹 어플리케이션은 Windows 2000과 동일하게 aspnet_wp.exe 라는 ASP .NET 작업 프로세스에 의해 호스팅 되며 모든 ASP .NET 웹 어플리케이션은 이 작업 프로세스에 의해 처리된다. 지난 10월호의 닷넷 칼럼에서 언급했듯이 이 작업 프로세스가 종료되면 모든 ASP .NET 웹 어플리케이션은 중단될 것임은 이전과 완전히 동일하다. Aspnet_wp.exe 프로세스는 기본적으로 명시적으로 inetinfo.exe가 종료되거나 aspnet_wp.exe를 강제로 종료시킬 때 까지 종료되지 않는다. 이 설정은 machine.config 파일을 수정함으로써 주기적으로 재활용(recycling)되거나 특정 조건이 되면 재시작 되도록 설정될 수 있다. 상세한 내용은 MSDN을 참고하기 바란다.

그림 2에서 한가지 이상한 것은 WAS 라는 것이다. 절대로 혼동하지 말아야 할 것은 WAS가 Web Application Server가 아니라, Web Administration Service 라는 점이다. 앞으로 필자가 특별한 언급 없이 WAS라고 하면 이것은 Web Administration Service를 지칭하는 것이므로 혼동하지 않기를 바란다. 어찌 되었건 WAS라는 것은 IIS 6.0에 처음으로 등장한 구성요소이다. WAS는 IIS 6.0에서 새로이 소개된 메타 베이스 관리를 위한 프로세스이다. Inetinfo.exe는 더 이상 메타베이스를 관리하지 않는다(필자주: 현재 메타베이스의 관리는 Inetinfo.exe가 수행하고 있다. WAS가 Inetinfo.exe 내부로 포함된 것이다). 대신 WAS가 메타 베이스를 관리하게 되는데, 왜 WAS가 필요하게 되는가는 차츰 설명하도록 하겠다.

Worker Process Isolation Mode

IIS 6.0의 기본 프로세싱 모델은 작업 프로세스 모드이다. 작업 프로세스 모드는 inetinfo.exe를 거치지 않고 HTTP.SYS에서 곧바로 응용 프로그램까지 클라이언트의 요청이 전달되는 모드를 말한다. 그림 3은 작업 프로세스 모드를 잘 보여주고 있다. HTTP.SYS에서 곧바로 클라이언트 요청이 작업 프로세스로 전달되므로 각 작업 프로세스는 각각 ISAPI 필터를 로드 하게 되며 작업 프로세스가 호스팅 하는 웹 어플리케이션에 따라 개별 프로세스 공간에 ISAPI 익스텐션을 로드 하게 된다. 작업 프로세스는 w3wp.exe 라는 이름으로 수행되며 메타 베이스의 설정에 의해 다수의 w3wp.exe 프로세스가 수행될 수 있다.

그림 3. IIS 6.0 Worker Process Isolation Mode

작업 프로세스는 하나 이상의 웹 어플리케이션을 호스팅 하거나 하나의 웹 어플리케이션이 다수의 작업 프로세스로 분산되어 처리될 수 있다. 각각의 경우에 대해 살펴보자. 먼저 하나의 작업 프로세스가 하나의 웹 어플리케이션을 담당하는 경우는 하나의 w3wp.exe가 하나의 웹 어플리케이션을 전담하여 수행하는 경우이다. 이 경우는 IIS 5.0의 응용프로그램 보호 수준의 ‘높음’과 유사하다. 다른 점은 inetinfo.exe가 웹 브라우저의 요청을 먼저 수신하고 이 요청을 명명된 파이프(named pipe)를 통해 dllhost.exe로 전달되었지만 이제는 inetinfo.exe가 80 포트를 리스닝 하지 않기 때문에 HTTP.SYS로부터 곧바로 w3wp.exe로 HTTP 메시지가 전달된다는 점이 다르다. 이 웹 어플리케이션을 종료하기 위해서는 인터넷 서비스 관리자에서 해당 작업 프로세스를 선택하고 종료 버튼을 누르면 된다. 구체적인 방법에 대해서는 후에 다시 설명하도록 하겠다. 두 번째는 하나의 작업 프로세스(w3wp.exe)가 2개 이상의 웹 어플리케이션을 호스팅 하는 경우이다. 이 경우는 IIS 5.0 모델의 ‘보통’ 보호수준과 유사하다. 다른 점은 inetinfo.exe가 관여하지 않고 HTTP.SYS 드라이버로부터 웹 브라우저의 요청이 직접 작업 프로세스로 전달된다는 점이 다르다. 물론 이 작업 프로세스가 종료되면 이 프로세스가 호스팅 중이던 모든 웹 어플리케이션 역시 종료된다. 마지막으로 살펴볼 경우는 하나의 웹 어플리케이션이 여러 작업 프로세스에 의해 처리되는 경우이다. 이 경우는 특별히 웹 가든(web garden)이라 부른다. 웹 농장(web farm)은 여러 대의 웹 서버가 한 웹 사이트를 서비스하는 경우를 말하며 웹 가든은 하나의 웹 서버 기계 내에서 한 웹 어플리케이션을 여러 프로세스가 나누어 처리하는 경우를 말한다. 각각의 작업 프로세스는 웹 브라우저의 요청을 나누어 처리하게 되므로 여러 개의 CPU를 가진 서버의 처리 능력을 향상 시켜줄 뿐만 아니라 작업 프로세스들이 2개 이상이 되므로 어느 프로세스가 예기치 않게 종료되더라도 서비스는 계속 유지될 수 있다. 웹 가든으로 설정된 웹 어플리케이션이 시작되면 IIS는 메타 베이스에 설정된 작업 프로세스의 개수만큼을 생성할 것이며 어느 작업 프로세스가 종료하거나 작업 중이지 않다고 판단되면 이 작업 프로세스를 재활용(recycling)할 것이다.

IIS 6.0의 Worker Process Isolation Mode의 전반적인 장점은 기존 모델에 비해 빠른 성능을 낼 수 있으며 관리의 편의성을 증대 시켰다는 점이다. Inetinfo.exe가 아닌 HTTP.SYS가 커널모드에서 작업하며 커널모드에서 직접 HTTP 메시지들을 작업 프로세스들에게 전달해 주므로 성능이 향상될 수 있으며 여러 작업 프로세스를 통해 전체 웹 사이트가 중단되는 경우를 현저히 줄여 줄 수 있다. 마이크로소프트에 의하면 4 CPU에서는 15%, 8 CPU에서는 25% 정도의 ASP .NET 어플리케이션의 성능향상을 가져올 수 있다고 한다.

지금까지는 일반적인 IIS 6.0의 새로운 프로세싱 모델을 살펴보았다. 이제 ASP .NET의 관점에서 이 모델을 살펴보도록 하자. Windows 2000에서 ASP .NET이 ASP에 비해 불편한 점 중 하나는 웹 어플리케이션 단위의 관리가 어려웠다는 점이다. 이유는 모든 ASP .NET 웹 어플리케이션이 aspnet_wp.exe라는 작업 프로세스에 의해 호스팅 되었기 때문이다. 따라서 이 프로세스가 종료되면 모든 ASP .NET 웹 어플리케이션이 종료되었었다. 또한 aspnet_wp.exe를 종료시키는 적당한 방법 또한 없어서 IIS 자체를 중단시키거나 다소 불안한 방법으로 aspnet_wp.exe를 작업 관리자(task manager)에서 강제로 종료시키는 방법을 사용했었다. 개발 용 서버인 경우 IIS 종료가 큰 문제가 아니겠지만 실제 웹 사이트를 운영 중인 서버라면 IIS 종료는 문제가 될 수도 있다. 특히 웹 호스팅을 제공하는 서버의 경우 IIS를 중단하는 것은 치명적이다. 이 때 웹 어플리케이션마다 하나의 작업 프로세스를 할당한다면 문제는 쉽게 해결될 수 있다. IIS 6.0에서는 업데이트 대상 혹은 다운으로 간주되는 웹 어플리케이션만을 선택하여 종료시키거나 재시작 시킬 수 있게 되었다. 하나의 작업 프로세스에 몇 개의 웹 어플리케이션을 호스팅 할 것인가 혹은 웹 어플리케이션을 몇 개의 작업 프로세스를 할당(웹 가든)할 것인가의 선택은 순전히 웹 서버의 목적, 사이트의 용도, 사용자 수 등을 고려하여 결정할 일이다. 시스템 관리자는 이제 다양한 선택의 폭을 갖추게 된 것이다.

Windows 2000에서는 ASP .NET 어플리케이션들은 aspnet_wp.exe 프로세스에 의해서 호스팅 되었었다. 비록 응용프로그램 보호 수준이 ‘보통’ 이거나 ‘높음’ 이더라도 ASP .NET 어플리케이션들은 dllhost.exe가 아닌 aspnet_wp.exe에 의해 호스팅 되었다. 하지만 이제는 작업 프로세스인 w3wp.exe 프로세스는 ASP .NET 어플리케이션도 호스팅 할 수 있다. 따라서 몇 개의 ASP .NET 웹 어플리케이션들이 복수개의 w3wp.exe에 의해 호스팅 되며 단일 w3wp.exe 내에서 ASP .NET 어플리케이션의 보호는 닷넷의 어플리케이션 도메인(application domain)에 의해서 수행되게 될 것이다.

다 좋은 것처럼 보이지만 이 세상에 공짜는 없는 법이다. 웹 가든을 사용하는 경우, 다수의 CPU를 갖는 서버는 보다 향상된 성능의 웹 서비스를 제공하게 될 것이지만 웹 프로그래밍은 제약사항들을 갖게 된다. 대표적인 것이 웹 어플리케이션이 여러 프로세스에 의해 호스팅 되므로 웹 페이지들은 메모리 상에 어떤 상태 혹은 정보를 저장해서는 안 된다. 특히 ASP의 세션 객체나 Application 객체는 정보를 메모리에 기록하므로 사용해서는 안 되는 대표적인 것이다(ASP.NET도 마찬가지 이다). 어떤 작업 프로세스에서 세션 객체에 어떤 값을 기록했다 하더라도 다른 작업 프로세스에서는 이 세션 객체의 값을 볼 방법은 없다. 이러한 세션 문제는 전통적으로 ASP의 문제점 이였고 웹 농장 구축에서도 항상 문제였으며 웹 가든에서도 문제는 여전하다. 따라서 웹 가든에서는 세션보다는 쿠키나 데이터베이스에 상태를 저장하는 것이 좋다. ASP .NET의 경우라면 이야기가 달라진다. ASP .NET은 세션 상태를 저장하기 위해서 3가지 옵션을 제공하기 때문이다. 디폴트인 in-proc 세션은 문제를 일으키지만 Out-of-proc 세션은 별도의 프로세스에서 세션 정보를 유지할 수 있고 이 프로세스는 별도의 서버 상에 둘 수 있기 때문이다. 더욱 안전한 세 째 방법은 SQL Server에 세션을 기록해 두는 방법으로 트랜잭션까지 보장하지만 성능이 좋지 못하다.

Web Administration Service

IIS 6.0의 작업 프로세스 보호 모드의 등장으로 인해 새로운 WAS가 필요하게 되었다. WAS는 메타베이스 관리를 위한 Windows 서비스로서 메타베이스를 관리하고 작업 프로세스들을 관리하는 중추적인 역할을 담당한다(필자주: 현재의 Windows 2003 서버에서 WAS는 Inetinfo.exe 내로 포함되었고 별도의 서비스로 제공되지 않는다). 이전에는 HTTP 80 포트를 Inetinfo.exe가 리스닝 하기 때문에 모든 HTTP 메시지를 inetinfo.exe가 수신하고 이들을 필요에 따라서 dllhost.exe에 분배해주었기 때문에 메타베이스는 Inetinfo.exe에 의해 관리되면 되었었다. 하지만 작업 프로세스 보호 모드는 HTTP.SYS 커널 드라이버가 HTTP 80 포트를 리스닝 하므로 수신된 HTTP 메시지를 어떤 작업 프로세스에 넘겨 주어야 하는 가를 HTTP.SYS 드라이버가 알아야 할 필요가 생긴 것이다. 게다가 나중에 설명할 XML 기반의 메타베이스 채용으로 인해 XML 파일에 기록된 메타베이스를 메모리로 로드하고 메모리에 가해진 메타베이스 변화사항을 주기적으로 디스크에 기록할 필요도 생겨났다. 이 때문에 WAS라는 새로운 서비스가 등장한 것이며 이 서비스는 메타베이스와 작업 프로세스(정확하게 말하면 어플리케이션 풀이며 어플리케이션 풀에 대해서는 조금 후에 설명할 것이다)를 관리하는 주체가 된 것이다. WAS에 대해서는 메타베이스에 대한 내용을 다루면서 좀 더 이야기 하기로 하자.

안정성 (Reliability)

IIS 6.0은 Web Application Server의 역할로서 충분한 안정성을 보장하도록 재 구성되었다. 필자는 IIS 6.0의 새로운 기능 중 안정성 향상에 많은 점수를 주고 싶다. IIS 6.0은 작업 프로세스가 어떤 임계치를 넘은 메모리 사용이나 CPU 점유를 수행하면 작업 프로세스를 종료시키거나 재시작 하도록 설정하거나 주기적으로 작업 프로세스가 재시작 되도록 할 수 있다. 또한 주기적으로 작업 프로세스의 활동 상황을 감시하고 반응하지 않는 작업 프로세스를 종료시킬 수도 있다. 이러한 기능들은 웹 사이트가 안정적으로 24시간 작동할 수 있도록 해주며 웹 어플리케이션의 크래쉬에 대해 유연한 대응책을 마련해 주도록 해준다.

Application Pool

IIS의 안정성에 관련된 사항을 알기 위해서는 IIS 6.0의 어플리케이션 풀에 대한 개념을 이해해야 한다. 어플리케이션 풀에 대해서 필자는 이미 설명을 하였다. 다만 어플리케이션 풀이라는 용어를 사용하지 않았을 뿐이다. 앞서 Isolation Mode를 설명할 때 작업 프로세스는 하나 이상의 웹 어플리케이션을 호스팅 할 수 있다고 설명한 바 있다. 좀 더 정확하게 다시 표현해 보면 이렇다. “웹 어플리케이션은 하나의 어플리케이션 풀에 속하며 어플리케이션 풀은 1개 이상의 작업 프로세스로 구성된다.” 하나의 웹 어플리케이션이 하나의 작업 프로세스와 대응되는 경우를 생각해 보면, 하나의 어플리케이션 풀이 하나의 웹 어플리케이션을 호스팅 하는 것이며 하나의 작업 프로세스로 구성되어 있음을 말하는 것이다. 비슷하게 생각해 보면, 하나의 작업 프로세스가 여러 웹 어플리케이션을 호스팅 하는 경우도 하나의 작업 프로세스로 구성된 어플리케이션 풀이 여러 웹 어플리케이션을 호스팅 하는 것이다. 웹 가든의 경우, 어플리케이션 풀은 2개 이상의 작업 프로세스로 구성되어 있으며 1개 이상의 웹 어플리케이션을 호스팅 하는 것을 말한다. 어플리케이션 풀은 IIS 6.0에서 중요한 요소인데, 그 이유는 프로세스 재활용, health 확인, 성능 지수 설정, 보안 설정(조금 후에 모두 설명할 것이다)이 작업 프로세스 단위가 아닌 어플리케이션 풀 단위로 설정되기 때문이다.

화면 3은 인터넷 서비스 관리자의 어플리케이션 풀 설정을 보여준다. IIS 5.0과 다르게 컴퓨터 밑에 어플리케이션 풀 폴더가 보이고 생성된 어플리케이션 풀의 목록이 나타난다. 그리고 어플리케이션 풀에 할당된 웹 어플리케이션이 그 밑에 나타나고 있다. 화면 3에서 DefaultAppPool 어플리케이션 풀은 ROOT, TestWebApplication, App1 웹 어플리케이션을 호스팅하고 있다. 웹 어플리케이션이 어떤 어플리케이션 풀을 사용할 것인가의 설정은 웹 어플리케이션의 등록정보 대화상자에서 Home Directory(혹은 Virtual Directory) 탭에서 설정이 가능하다. IIS 5.0에서는 Application Pool 설정 대신 ‘응용프로그램 보호 수준’을 선택하도록 되어 있었다.

어플리케이션 풀에 웹 어플리케이션을 할당하기 위해서는 먼저 어플리케이션 풀을 생성하고 필요한 설정(잠시 후에 다루게 될 것이다)을 수행해야 한다. 그 후 웹 어플리케이션 설정에서 새로이 생성한 혹은 이전에 존재하는 어플리케이션 풀을 화면 3과 같이 선택할 수 있다.

화면 3. Application Pool 설정

Recycling

IIS 6.0의 작업 프로세스들은 재활용(recycling) 될 수 있다. 재활용의 의미는 작업 프로세스인 w3wp.exe를 재시작 한다는 의미이다. 재활용은 웹 어플리케이션의 운영에 큰 의미를 지닌다. 웹 사이트를 운영하다 보면 서버를 일주일, 한달 길게는 몇 달 동안 계속 수행시킬 때가 많다. 이 때 시간이 흐르면 흐를 수록 응답 시간이 길어지거나 전체적인 웹 서버의 효율이 떨어지는 것을 경험할 때가 많다. 이러한 현상의 주요 이유 중 하나는 IIS/COM+의 버그 혹은 어플리케이션의 버그로 인해 메모리 누수(memory-leak)가 발생하는 경우이다. Inetinfo.exe 혹은 dllhost.exe가 점유하는 메모리가 시간이 지날수록 커지며 전체적으로 웹 서버의 메모리 사용량이 증가하기 때문에 성능이 점차로 낮아 지는 것이다. 또 한가지 이유로는 IIS의 작업 스레드가 어떠한 이유로 데드락(dead-lock)이 걸려 더 이상 작동하지 않는 경우이다. IIS이 작업 스레드는 특정 개수 이상 증가하지 않으므로 데드락이 걸려 죽어버린(hang) 스레드는 웹 어플리케이션의 성능을 감소시키게 된다. 이러한 오류들은 발견이 매우 어렵다. 메모리 누수는 감지하기 어려울 뿐더러 감지 했다 하더라도 이것이 응용 프로그램의 문제인지 아니면 IIS/COM+의 문제인지 결정하기 더욱 어렵다. 이러한 문제를 해결하는 가장 간단한 방법은 inetinfo.exe 혹은 dllhost.exe를 재시작 하는 것이다(-_-;;). IIS 6.0 이전에는 inetinfo.exe를 재시작 하는 것은 전체 웹 서비스가 잠시 중단된다는 것을 의미했으며 dllhost.exe를 재시작 하기 위해서는 관리자가 직접 해당 프로세스를 종료했어야 했다. 이렇게 inetinfo.exe나 dllhost.exe를 종료하면 사용자는 아무런 경고도 없이 사이트에서 튕겨 나가는 현상을 겪었어야 했으며 더욱 좋지 못한 점은 인터넷 뱅킹과 같은 사이트는 임의로 서비스를 중단하기 조차 어렵다. 대개 관리자들은 메모리를 증설하여 문제를 해결(아니 우리는 이런 상황을 땜빵이라고 한다)하곤 했다.

IIS 6.0은 이렇게 작업 프로세스를 재시작 해야 하는 경우를 대비하고 있다. 이것이 재활용인 것이다. IIS 6.0에서는 어플리케이션 풀에 다양한 조건을 주고 이 조건을 만족하면 어플리케이션 풀 내의 작업 프로세스들을 재활용 시킬 수 있다. 재시작과 재활용은 다른 의미를 갖는다는 점에 유의하자. IIS는 단순히 재활용 대상인 작업 프로세스를 종료시키고 새 작업 프로세스를 시작시키지 않는다. 만약 단순하게 작업 프로세스를 종료 시켜 버린다면, 작업 프로세스에서 처리 중이던 모든 작업이 중단되어 버리므로 어플리케이션 무결성을 저해 할 수도 있다. IIS 6.0은 재활용 대상인 작업 프로세스는 현재 처리 중인 HTTP 요청들을 계속 처리한다. 그러나 새로이 들어오는 HTTP 요청들은 새로이 생성된 작업 프로세스에서 처리가 된다. 재활용 대상인 작업 프로세스가 더 이상 처리할 요청이 없을 때 작업 프로세스는 자연스럽게 종료가 될 것이다.

재활용 조건은 다양하게 설정될 수 있다. 특정 시간이 지나면 작업 프로세스(들)을 재활용하거나, 특정 회수 이상의 HTTP 요청을 처리했다면 작업 프로세스(들)를 재활용 한다. 혹은 계획된 스케줄에 의해 재활용을 수행할 수도 있다. 마지막으로 작업 프로세스가 특정 한계 이상의 메모리를 사용하면 재활용 되도록 설정할 수도 있다. 이와 같은 설정은 어플리케이션 풀 단위로 설정할 수 있으며 화면 4와 같은 대화 상자를 통해 조정이 가능하다.

화면 4. Recycling 설정

작업 프로세스 재활용과 관련되어 프로그래밍 상의 주의점은 어플리케이션이 작동하던 작업 프로세스가 바뀌기 때문에 메모리상에 저장해둔 사항들이 소실된다는 점이다. 앞서 웹 가든에서 언급했던 사항들이 재활용에 관해서도 여전히 적용된다. 따라서 프로세스 재활용을 사용하고자 한다면 세션의 상태 유지에 상당한 주의를 기울여야 한다. 세상엔 공짜란 없다…

Health Monitoring

IIS 6.0이 웹 서버의 안정성에 많은 관심을 갖고 있다는 증거는 IIS의 헬스 감시(Health Monitoring)에서 찾을 수 있다. IIS 6.0의 WAS는 주기적으로 작업 프로세스의 작업 상황을 모니터링 할 수 있다. 이러한 모니터링 과정은 작업 프로세스 핑(ping)이라 불리며 이 핑에 응답하지 않거나 핑에서 자신의 건강도가 낮다고 보고한 작업 프로세스는 재활용 대상이 된다. 또한 어떤 어플리케이션 풀이 주어진 시간 동안 일정 회수의 오류를 발생하면 해당 어플리케이션 풀은 비활성화 된다. 이렇게 비 활성화된 웹 어플리케이션에 대한 사용자 접근은 “서비스 거부” 오류(HTTP 503)를 경험하게 될 것이다. 이러한 IIS 기능은 rapid-fail protection 이라 불리는데, 어떤 문제로 인해 작업 프로세스가 계속적으로 크래쉬 되는 상황이 오랫동안 반복적으로 일어나지 않도록 하기 위함이다. 필자도 이러한 상황을 겪어 보았는데, 실수로 웹 어플리케이션이 사용하는 DLL이 PATH에 포함되어 있지 않아서 30분 동안 웹 어플리케이션은 백 여 번의 재시작을 수행했었다! 필자의 경험에서 왜 이름이 rapid-fail protection 인가를 이해할 수 있을 것이다. 헬스 감시의 마지막 설정은 작업 프로세스에게 주어진 시작 기간과 셧다운(shutdown) 기간이다. 작업 프로세스는 주어진 시간 안에 시작완료 해야 하며 주어진 시간 내에 셧다운 되어야 한다. IIS가 작업 프로세스를 종료해야 할 경우, 작업 프로세스에게 셧다운 할 것을 지시한다(임의고 그냥 종료시키지 않는다). 그리고 주어진 셧다운 타임아웃 내에 작업 프로세스가 종료하지 않은 경우에는 프로세스를 강제 종료(terminate)시켜 버린다. 지금까지 설명한 헬스 감사의 기능들은 화면 5를 통해 설정이 가능하다.

화면 5. Health Monitoring 옵션

Performance Management

IIS 6.0에서는 성능 관리(Performance Management)가 가능하다. 여기서 말하는 성능 관리는 어플리케이션 성능을 올려주도록 관리해준다는 의미가 아니다. 웹 서버의 전체적 성능이 떨어지지 않도록 프로세스를 관리하거나 주의를 주겠다는 의미이다. 첫 번째 기능은 어플리케이션 풀에 특정 시간 이상 HTTP 요청이 들어오지 않으면 작업 프로세스(들)를 종료시켜 준다. 이는 불필요한 프로세스를 종료시킴으로써 시스템의 전체적인 자원 효율을 높이겠다는 의미이다. 두 번째는 단시간에 몰리는 HTTP 요청을 줄여주는 기능으로서 각 작업 프로세스마다 가지고 있는 HTTP 요청 큐(queue)에 기록되는 요청 개수에 제한을 두는 것이다. 폭주하는 사용자 요청을 조정함으로써 웹 어플리케이션의 응답 속도를 떨어뜨리지 않을 수 있다. 이 제한 사항을 넘는 사용자 요청은 Server-Busy 결과를 받게 된다. 세 번째 기능은 소위 CPU throttling 이라 불리는 기능으로 일정 기간 동안 작업 프로세스가 어떤 한계를 넘는 CPU 점유를 수행하면 이벤트 로그를 남기고 필요에 따라 작업 프로세스를 재활용 하도록 할 수 있다.

앞서 언급한 웹 가든의 작업 프로세스 개수 설정 역시 성능 관리 카테고리에 포함된다. 화면 6의 대화 상자를 이용하여 웹 정원에 포함될 작업 프로세스의 개수를 설정할 수 있다. 작업 프로세스의 개수를 설정할 때는 CPU의 개수, 메모리 양, 어플리케이션의 상태 저장 방법 등의 다양한 사항에 대해 검토를 충분히 한 후에 작업 프로세스 개수를 설정해야 할 것이다. 작업 프로세스의 개수를 무턱대고 높게 잡는다고 해서 성능이 올라가지 않음을 유의해야 할 것이다.

화면 6. Performance Management 옵션

보안 (Security)

IIS 6.0은 이전 버전들이 바이러스 공격이나 기타 사항들에 상대적으로 취약하다는 악명을 떨치고자 노력한 흔적이 보인다. 마이크로소프트의 이러한 노력이 얼마나 효과가 있을지는 두고 볼 일이지만 세심한 곳까지 신경을 쓴 것 같다.

필자는 Windows .NET 을 설치한 후 IIS 도움말을 보기 위해 웹 브라우저를 띄우고 http://localhost/ 를 입력했다. 하지만 결과는 전혀 엉뚱하게도 WWW 서비스가 존재하지 않는다는 내용의 오류를 만났다. 그렇다 서두에서도 언급했듯이 Windows .NET 은 IIS를 디폴트로 설치하지 않는다. Windows 2000의 행동과는 정반대의 행동을 하고 있는 것이다. 왜 IIS를 기본으로 설치하지 않을까? 모든 Windows 기반의 서버들이 웹 서비스를 제공하지는 않는다(다시 말하지만 여기서의 웹 서비스는 HTTP 기반의 광의의 웹 서비스를 말한다. SOAP을 사용하는 특정 웹 서비스를 말하지 않음을 주의하자). 그럼에도 불구하고 Windows 2000 서버 제품군은 IIS를 기본적으로 설치 한다. 웹 개발자들에게는 이것이 좋을지 몰라도 단순한 데이터베이스 서버나 파일 서버에게 IIS 설치는 이점 보다 단점을 가져올 수 있다. 특히 바이러스에게는 이렇게 무심코 설치된 IIS는 단꿀과 물엿이 흐르는 좋은 숙주가 된다. 예를 들어 파일 서버 목적으로 설치된 Windows 2000 이 있다고 가정해 보자. 파일 서버가 주요 용도이므로 이 서버에 IIS 가 설치된 것을 관리자는 크게 고려하지 않을 것이다. IIS에 관련된 보안 패치나 기타 IIS와 관련된 관리를 수행하지 않을 것임은 자명하다. 이런 Windows 2000 서버들이 인터넷에는 부지기 수로 널려 있다. 이런 서버들은 IIS를 목표로 하는 단 한번의 바이러스 공격으로 와해되고 바이러스를 퍼트리는 좋은 위치로 활용될 것이다. Windows .NET Server는 명시적으로 시도하지 않는 한 IIS를 설치하지 않는다.

이제 IIS를 설치했다고 가정해 보자. 그리고 간단한 ASP 파일을 만들어 IIS를 테스트 해보고자 한다. 몇 줄짜리 ASP야 순식간에 만들 수 있고 테스트를 했다. 하지만 브라우저에 나타난 결과는 역시 오류 메시지 뿐 이다. IIS 6.0는 최초 설치 후에는 오직 정적 컨텐츠(.htm, .gif 등)만을 서비스 한다. ASP, ASP .NET, ISAPI Extension을 비롯한 CGI, SSI(Server-Side Include) 등의 모든 동적 컨텐츠는 명시적으로 활성화 되어야만 서비스가 가능해 진다. 이러한 상태를 Lock 모드라 불리며 IIS 5.x 를 위한 Lock 메니저도 제공되고 있다. 이렇게 IIS가 Lock 모드 상태에서 설치되는 이유는 앞서 설명한 내용과 같다. 단순히 설치되었다는 것으로만 바이러스나 악의적 해커의 공격에 무방비로 노출되는 것을 막고자 함이다. Windows .NET 베타 버전에서는 설치 후에 필요한 기능을 Enable 해야 했지만 Windows .NET RC 버전에서는 친절하게도 화면 1과 같은 설정에서 Front Page Extension과 ASP .NET을 기본적으로 Enable 할 것인가를 묻는다. 그 외의 모든 ISAPI Extension (ASP도 ASP .NET도 근본 적으로는 ISAPI Extension의 일종이다.)은 사용이 허가되지 않는다. 물론 화면 7과 같은 설정을 통해 필요한 ISAPI Extension을 사용하도록 할 수도 있다.

화면 7. ISAPI Extension의 제어

IIS 6.0의 보안상 나아진 점 중 또 한가지는 각 작업 프로세스마다 프로세스 계정을 할당할 수 있다는 점이다. IIS 5.0에서도 불가능한 것은 아니였지만 웹 어플리케이션의 보호 수준이 ‘보통’ 혹은 ‘높음’으로 설정해야만 가능했고 프로세스 계정을 바꾸기 위해서는 인터넷 서비스 관리자가 아닌 구성요소 관리자를 통해서 설정했어야 했다. 가장 안 좋았던 것은 ASP .NET은 오직 aspnet_wp.exe 프로세스에 의해서만 호스팅되므로 모든 ASP .NET 웹 어플리케이션들이 하나의 프로세스 계정을 공유했어야 했다는 점이다(상세한 내용은 2002년 10월호 닷넷 칼럼을 참고하기 바란다). IIS 6.0은 이제 프로세스 풀에 사용할 프로세스 계정을 설정할 수 있다(화면 8). 그리고 ASP .NET 웹 어플리케이션들은 다양한 작업 프로세스에 의해 호스팅 되므로 보다 안전하게 웹 어플리케이션 보안 설정을 수행할 수 있다. 또한 Windows .NET은 작업 프로세스들이 사용하는 계정들을 IIS_WPG 라는 그룹에 포함시키고 있으므로 특정 디렉터리를 작업 프로세스들이 액세스하도록 허용하기 위해서는 IIS_WPG 그룹에 대한 권한을 주면 된다. 이전에는 IUSR_XXX, IWAM_XXX, ASPNET 계정 등등에 권한을 따로따로 설정해 주었어야 했다.

화면 8. 작업 프로세스의 프로세스 계정 설정

마지막으로 IIS 6.0의 보안 관련 사항은 향상된 SSL 관련 기능이다. SSL 관련 설정을 위한 마법사가 향상 되었고 SSL 암호화를 위한 Windows Crypto Provider를 선택할 수 있게 되었다. 이는 다양한 암호화 패키지를 사용할 수 있음을 의미하여 하드웨어를 통해 암호화를 수행하는 암호화 패키지를 통해 SSL의 성능을 향상 시킬 수 있음을 의미하기도 한다. SSL 관련 기능은 필자가 직접 테스트할 환경을 구축하지 못해 구체적인 스크린샷이나 예를 보여주지 못한 점 독자들에게 사과하는 바이다.

메타베이스

IIS는 웹 서버의 다양한 설정들, 가상 디렉터리 설정, 보안 설정 등의 웹 어플리케이션에 대한 전반적인 설정을 기록해 두는 장소를 두고 있다. 이것을 메타베이스라 하며 IIS 5.x 까지 하드 디스크 내의 이진 파일에 이러한 정보들을 기록해 두고 있었다. 문제는 이 이진 파일로 기록되는 메타베이스가 관리에 어려움을 준다는 것이다. 대개의 경우 인터넷 서비스 관리자를 통해 메타베이스에 접근하거나 기타 프로그래밍 적인 방법(ADSI, WMI 등)을 통해 메타베이스를 액세스 할 수 있었다. 하지만 일부 프로퍼티 값들은 인터넷 서비스 관리자에서 인터페이스를 제공하지 않았으므로 수정을 위해 WSH(Windows Scripting Host)를 사용하거나 VB, C# 등의 개발 도구로 개발했어야 했다. 또 한 가지 문제가 되었던 것은 어느 웹 어플리케이션에 관련된 IIS 설정을 다른 컴퓨터로 옮기고자 할 때 편리한 방법이 없었다는 점이다. 예를 들어, 한 웹 서버가 하드웨어 문제를 일으켜서 이 서버가 서비스하던 웹 사이트를 다른 서버로 옮기고자 한다. 컨텐츠를 옮기는 것은 그다지 어렵지 않다. 하지만 웹 어플리케이션에 관련된 다양한 설정 사항들은 어떻게 해야 하는가? 이전에 변경했던 사항들을 모두 기억하고 있다면 별 문제가 되지 않겠지만(기억하고 있는 사람이 있을까?) 그렇지 않다면 골치 아픈 문제가 발생한다. IIS 설정을 복사해주는 유틸리티들이 있기는 하지만 이러한 메타베이스 관리는 IIS의 문제점으로 지적되었었다.

IIS 6.0은 메타베이스가 XML 파일로 저장된다. XML 파일은 Metabase.xml 이라는 파일로서 IIS가 시작되면 메모리로 읽혀 진다. 메모리로 읽혀진 메타 베이스는 인 메모리(In-memory) 메타베이스라 불리며 이제부터 인터넷 서비스 관리자를 통하거나 프로그래밍적인 방법으로 메타베이스가 변경되면 인 메모리 메타베이스가 변경된다. 그리고 IIS의 WAS는 틈 만나면 인 메모리 메타베이스의 변경 사항을 디스크에 기록한다. 물론 이러한 과정은 트랜잭셔널(transactional)하게 작동하며 변경사항은 히스토리로서 하드디스크에 남게 된다. 또한 XML 메타베이스(평범한 텍스트 파일이다)가 변경되면 변경 사항을 읽어 들여 인 메모리 메타베이스가 갱신되도록 유지할 수도 있다. 이제 여러 대의 웹서버를 동일한 환경으로 맞추기 위해서는 Metabase.xml 파일을 복사하기만 해도 된다.

한 가지 더 메타베이스와 관련된 희소식은 백업/리스토어(backup/restore) 기능이 크게 강화되었다는 점이다. Windows XP에 포함된 IIS 5.1의 백업/리스토어는 전체 IIS 메타베이스를 백업하는 것이였지만, IIS 6.0은 XML 기반의 메타베이스이므로 특정 부분만을 복사하여 다른 Metabase.xml에 붙여넣기(paste) 할 수도 있다. 이제 웹 어플리케이션을 백업하기 위해서 컨텐츠와 Metabase.xml을 복사해 두면 된다. 이외에도 IIS 6.0의 메타베이스에 관련된 사항들이 여러 가지 바뀌었다. 상세한 내용을 모두 다룰 수 없으므로 참고 문헌의 자료들을 살펴보기 바란다.

그 밖의 것들

IIS 6.0은 지금까지 언급한 사항들 외에 다양한 내용들이 변화되었다. 지면 관계상 많은 것을 다루지 못 한 점이 아쉬울 뿐이다. 분명한 것은 지금까지 필자가 다룬 내용들이 버그 없이 작동하기만 한다면 IIS 6.0은 ASP .NET 어플리케이션을 운영하는데 최적의 환경이 될 것이라는 점이다.

참고문헌

• Windows .NET Online help
  Internet Information Service online document
• Windows .NET Server home page
  http://www.microsoft.com/windows.netserver/default.mspx (필자주: 부정확한 링크임)
• IIS 6.0 : New Features Improve Your Web Server's Performance, Reliability, and Scalability
  George Shepherd, MSDN Magazine March 2002
• Security in IIS 6.0 : Innovations in Internet Information Services Let You Tightly Guard Secure Data and Server Processes
  Wayne Berry, MSDN Magazine September 2002
• MSDN ISV Summit 세미나 자료
  Microsoft