올해 3월에 출시된 비주얼 스튜디오 닷넷과 닷넷 프레임워크는 ‘정식’ 제품이라는 의미 외엔 큰 이슈가 아니었다. 이미 지난해부터 베타 버전을 통해 많은 프로그래머들에게 알려졌기 때문일 것이다. 발표 이후에 나온 두 번의 서비스 팩과 서비스 팩에서 수정되지 않은 몇몇 문제들은 필자를 괴롭히기도 했지만 안정화를 향해 한발씩 나아가는 것이라 생각하고 냉수를 들이키곤 했다.
필자가 2002년을 회고해 보면 닷넷의 정식 출시를 빼고는 닷넷과 관련된 큰 이슈는 없었다고 본다. 웹 서비스가 곧 시대의 대세일 것처럼 IT를 휩쓸었고 벤더와 언론은 웹 서비스라는 주제로 앨범 몇 장을 냈을 정도로 노래를 불렀지만 정작 웹 서비스라는 기술로서 우리 피부에 와 닿는 것은 없다는 것에 쓴 웃음을 짓게 한다.
그러나 앞으로는 더 구체적이고 실질적인 것들이 웹 서비스와 접목될 것이라는 것을 의심하지 않는다. 다만 너무 성급히 ‘앞으로는 이것이 대세이다’라고 외쳐버리고 앞서 달려나가다 지쳐버리는 자세는 지양해야 할 것이다.
12월에는 한 해를 마무리하고 정리하는 것이 마땅하지만 이번 컬럼의 주제는 정리와 관계가 먼 것이다. 이번 컬럼은 윈도우 닷넷 서버에 새로이 포함된 IIS 6.0에 대한 내용을 다뤄보고자 한다. 특히, 웹 프로그래밍의 관점에서 바라본 IIS 6.0의 새로운 기능들과 이것이 어떻게 ASP나 ASP.NET 웹 프로그래밍 모델에 영향을 미치는지 살펴볼 것이다.
IIS 6.0은 웹 애플리케이션을 위한 다양한 기능들을 제공한다.
윈도우 닷넷과 IIS 6.0은 운영체제에 포함된 닷넷 프레임워크, 보다 나은 수행 환경, 편리한 관리 환경, 높은 성능 등을 무기로 웹 애플리케이션들을 단꿀과 물엿, 조청과 엿기름, 버터와 쇼트닝유가 흐르는 안락한 웹 서버로 인도할 것이다.
여기서 소개하는 내용들이 IIS 6.0에서 변화되거나 추가된 사항들의 모두는 아님에 유의해야 한다. 윈도우 닷넷 서버가 이전 윈도우 2000 서버에 비해 바뀌거나 추가된 기능들을 살펴보려면 마이크로소프트(이하 MS)의 공식 페이지를 확인하기 바란다.
이제 독자들이 윈도우 닷넷에서 ASP.NET을 수행할 수 있도록 하는 부분만을 간단히 다루도록 하겠다. 정식 버전이 아닌 제품의 기능을 소개할 때 빠짐없이 등장하는 말이지만 다시 한 번 해야 할 것 같다. 여기서 설명할 내용은 윈도우 닷넷과 IIS 6.0의 기능은 RC(Release Candidate) 버전의 내용이므로 예고 없이 최종 버전에서 바뀔 수 있다는 점이다. 윈도우 2000의 인 메모리(In-Memory) 데이터베이스의 교훈을 잊지 말자(윈도우 2000 베타에 포함되었던 인 메모리 데이터베이스 기능이 정식 버전에서는 조용히 사라진 적이 있다).
윈도우 닷넷 서버
윈도우 닷넷 서버는 윈도우 2000 서버의 차기 운영체제이다. MS의 이름 짓는 방식에 많은 사람들이 혼동을 겪고 있는데 소위 말하는 윈도우 운영체제에 관해 다음과 같은 로드맵을 살펴보면 쉽게 이해할 수 있다.
2003년까지 MS의 운영체제는 윈도우 XP 홈 에디션으로 대표되는 가정용 운영체제와 기업용으로 윈도우 XP 프로페셔널, 그리고 이들 운영체제에 상응하는 서버 운영체제가 윈도우 닷넷 서버 제품군인 것이다.
윈도우 닷넷 서버 제품군은 다시 웹 서버 에디션, 스탠다드 에디션, 엔터프라이즈 에디션, 그리고 데이터센터 에디션으로 나눠진다. 윈도우 닷넷 서버 제품군의 각 에디션에 대한 상세한 내용은 MS 홈페이지를 참고하기 바란다.
윈도우 닷넷 서버가 이전 버전에 비해 지닌 특징으로는 다음과 같은 것을 들 수 있다.
◆ 닷넷 프레임워크 통합
◆ 웹 서버 기능 강화(IIS 6.0)
◆ 웹 애플리케이션 서버로서의 기능 제공
◆ UDDI 서비스 제공
◆ 보안 강화
◆ XML 웹 서비스로 최적화
요약하자면 윈도우 2000에서부터 그래왔듯 운영체제가 보다 많은 기능을 제공하겠다는 말과 일맥 상통한다. 윈도우 닷넷이라는 이름에서 짐작할 수 있듯 닷넷 프레임워크가 운영체제와 함께 자동으로 설치되며 IIS 6.0은 기본적으로 ASP.NET을 통해 웹 서비스를 제공할 수 있다. 또한 COM+와 IIS 6.0은 고가의 WAS(Web Application Server) 제품이 제공하는 기능을 모두 제공한다.
보안에 관련된 사항을 간단히 언급하면, 윈도우 2000에서는 기본적으로 설치되고 즉시 사용 가능한 상태로 제공되었던 것들이 이제는 사용자가 명시적으로 설치하거나 셋업해야만 사용 가능하도록 되어 있다.
예를 들어 윈도우 닷넷 서버를 설치하면 IIS가 기본적으로 설치되지 않으며 서버 관리자 쯤으로 불릴 ‘Manage Your Server’를 통해 서버에 역할을 주면 그 역할에 맞는 소프트웨어들이 설치된다. <화면 1>은 웹 애플리케이션 서버 역할(role)을 설정받은 후에 나타나는 서버 관리자의 모습을 보여주고 있다. 웹 애플리케이션 서버의 역할이 주어지면 윈도우 닷넷 서버는 IIS를 설치하고 COM+ 관련 설정을 수행하며 필요에 따라 프론트 페이지 익스텐션 등을 설치하게 된다.
<화면1> Manage Your Server
다시 본론으로 돌아와 윈도우 닷넷 서버는 윈도우 2000부터 시도했던 운영체제가 WAS를 대신한다는 목표를 점차로 완성해가는 듯 싶다. 실제 윈도우 2000 역시 WAS의 핵심 요소인 웹 서버와 미들웨어로서 IIS 5.0/COM+ 1.0을 지원했지만 그 기능이 상용 WAS만큼이나 풍부하지는 않았던 것이 사실이다. 하지만 IIS 6.0, COM+ 1.5로 무장된 윈도우 닷넷 서버는 이제 WAS 제품들과 비교해도 크게 손색이 없을 만큼이나 탄탄한 애플리케이션 기반 구조를 갖게 되었다. 물론 운영체제가 WAS 기능까지 해야 하는가에 대한 논란은 여전히 남아 있지만 말이다.
IIS 6.0의 주요 기능들
이제부터 IIS 6.0의 주요 기능들을 살펴보자. IIS의 버전별 변화 사항은 다음과 같다.
IIS가 주목받기 시작한 것은 윈도우 NT 4.0의 옵션팩으로 제공된 IIS 4.0부터라고 할 수 있다. 그리고 윈도우 2000에서는 기존 버전에 비해 탁월하게 향상된 성능과 윈도우 2000에 포함된 로드밸런싱 및 클러스터링 기능 그리고 닷컴 회사의 붐을 타고 IIS는 가장 많은 웹 사이트를 호스팅하는 웹 서버로서 자리매김하고 있다. 또한 윈도우 닷넷 서버와 함께 다양한 기능들로 새롭게 무장한 6.0이 등장한 것이다.
코어 아키텍처
IIS 6.0이 이전 버전에 비해 가장 두드러지게 달라진 부분을 꼽으라면 바로 IIS가 기본적으로 작동하는 방식이 달라졌다는 점이다. 거두절미하고 말하자면 웹 서비스(WWW 서비스)를 위해 80포트를 리스닝(listening)하는 주체가 inetinfo.exe가 아닌 윈도우 닷넷 커널로 바뀌었다.
즉, 80포트는 커널 모드에서 작동하는 HTTP.SYS 디바이스 드라이버가 리스닝하며 이 드라이버가 80포트로부터 수신되는 HTTP 요청(request)을 읽어 적절한 웹 애플리케이션들에게 이들을 분배한다. 구체적으로 어떻게 이들 요청이 분배되는가는 조금 후에 살펴보도록 하고, HTTP.SYS 드라이버가 80포트를 리스닝함으로써 달라지는 사항에 대해 살펴보자.
IIS 5.0은 다른 WINSOCK 애플리케이션과 크게 다를 바 없이 80포트를 리스닝했었다. 80포트의 리스닝 주체는 inetinfo.exe 프로세스였으며 다소 최적화는 되어 있더라도 기본적으로는 WINSOCK을 통해 80포트를 리스닝했다. 이는 TCPIP를 관장하는 TCPIP.SYS를 통해 HTTP 서비스 요청을 처리했음을 의미한다. Ineti nfo.exe에 의해 수신된 HTTP 요청은 웹 애플리케이션 설정에 따라 적절한 웹 애플리케이션들에게 배포되었고 웹 애플리케이션은 이를 처리하고 다시 inetinfo.exe를 통해 클라이언트(웹 브라우저)에게 결과를 전송했다.
윈도우 닷넷에서는 80포트를 리스닝하는 주체는 더 이상 inetinfo.exe가 아니다. 80포트는 커널 모드 드라이버인 HTTP.SYS가 수행하며 이 드라이버가 HTTP 요청을 받아 적절한 웹 애플리케이션들에게로 넘겨주게 된다. 결과를 클라이언트에 넘겨줄 때 역시 HTTP.SYS가 역할을 담당하게 될 것이다. 이것이 의미하는 바는 첫째로 성능 향상을 들 수 있겠다. <그림 1>에서도 볼 수 있듯 inetinfo.exe 프로세스를 사용하지 않기 때문에 병목 현상을 줄일 수 있고 WINSOCK 계층 역시 거치지 않으므로 오버헤드를 줄일 수 있다.
운영체제를 제공하는 MS만이 할 수 있는 꽁수(?)라고 말하지 않을 수 없다. MS에 의하면 커널 모드 포트 리스닝으로 20~30%의 성능 향상을 가져올 수 있다고 한다. 하지만 IIS 6.0이 정말로 이 정도의 성능 향상을 가져오는 지는 필자도 아직 테스트해 보지 못했으며 의문사항일 뿐이다.
<그림1> IIS 5.0과 IIS 6.0의 기본 아키텍처
두 번째 의미는 안정성 향상이다. 윈도우 2000에서는 inetinfo.exe가 중단되면 전체 웹 서비스 자체가 중단되었다. 80포트를 리스닝하는 프로세스가 중단되었으니 웹 서비스가 중단됨은 당연한 일일 것이다. 하지만 윈도우 닷넷에서는 80포트를 리스닝하는 주체가 프로세스가 아닌 커널이므로 특정 프로세스의 중단으로 인한 웹 서비스의 중단은 발생하지 않는다. 다만 커널이 다운되면 웹 서비스 역시 중단될 것이다.
윈도우 닷넷 서버가 어느 정도 안정적이라고 가정한다면 웹 서비스의 안정성은 올라간다고 말할 수 있다.
하지만 윈도우 닷넷 서버가 안정적이지 않다면? Inetinfo.exe와 관련해 언급할 사항은 이 프로세스가 계속 사용되며 예전만큼은 아니더라도 여전히 중요하다는 점이다. Inetinfo.exe 프로세스는 여전히 FTP, NNTP, SMTP 서비스를 제공하며 인 메모리 메타베이스를 보유하고 있다. 따라서 이 프로세스가 정지된다면 FTP/NNTP/SMTP 서비스와 더불어 메타베이스 서비스 역시 제대로 제공되지 않을 것이다.
프로세스 모델
IIS의 핵심 아키텍처가 변화함에 따라 웹 애플리케이션이 수행되는 프로세싱 모델 역시 변화되는 것은 당연하다. 윈도우 2000에서는 HTTP 서비스 요청은 inetinfo.exe가 수신하고 요청된 URL과 메타베이스 설정, 즉 어떤 URL이 어떤 웹 애플리케이션과 맵핑되며 웹 애플리케이션의 응용 프로그램 보호(application isolation)가 어떻게 되는가에 따라 HTTP 요청은 적절히 분산되었다.
예를 들어 사용자가 http://svr/app1/test.asp를 요청했다고 가정해 보자. Inetinfo.exe는 /app1 디렉토리의 응용 프로그램 보호 수준을 살펴볼 것이며 이것이 ‘높음’ 혹은 ‘중간’ 이라면 별도의 dllhost.exe 프로세스로 클라이언트 요청을 넘겨주며, 보호 수준이 ‘낮음’ 이라면 inetinfo.exe 내의 애플리케이션에 클라이언트 요청을 넘겨주었을 것이다.
<화면2>IIS 5.0 보호 모드 전환을 위한 대화상자
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 보호 모드
IIS 5.0 보호 모드는 IIS 5.x와 호환성을 위해 제공되는 모드이다. 이 모드는 디폴트로 사용되지 않으며 이것으로 전환하기 위해서는 인터넷 서비스 관리자에서 ‘Web Sites’를 선택하고 등록정보를 클릭하면 나타나는 ‘웹 사이트 등록 정보(Web Sites Properties)’ 대화상자를 이용해야 한다.
이 대화상자의 서비스(service) 탭을 클릭하면 보호 모드를 바꿀 수 있으며 IIS 5.0 보호 모드를 사용하면 웹 서비스는 다시 시작돼야 한다. 후에 설명할 작업 프로세스 모드와 IIS 5.0 모드는 공존할 수 없으며 두 모드 중 하나만이 사용될 수 있음에 유의해야 할 것이다.
<그림2>IIS 5.0 보호 모드
<그림 2>는 IIS 5.0 모드의 처리 상황을 보여주는 그림이다. 앞서 설명한 대로 HTTP 요청은 HTTP.SYS에 의해 수신되며 이 요청은 곧바로 inetinfo.exe로 넘겨진다. Inetinfo.exe는 메타 정보에 근거하여 응용 프로그램 보호 수준이 ‘낮음’ 인 애플리케이션은 inetinfo.exe 프로세스 내에서 처리하고, 보호 수준이 ‘보통’ 혹은 ‘높음’인 애플리케이션은 별도의 dllhost.exe 프로세스에서 처리하게 될 것이다. 한 가지 주의해야 할 사항은 dllhost.exe 프로세스로 요청을 넘겨주는 주체는 HTTP.SYS가 아닌 inetinfo.exe라는 점이다.
ASP(Active Server Page)라면 <그림 2>로 충분한 설명이 될 것이다. 하지만 ASP.NET이라면 어떻게 될까? ASP.NET 웹 애플리케이션은 inetinfo.exe나 dllhost.exe에 의해 호스팅되지 않는다는 것을 독자들은 알고 있을 것이다. ASP.NET 웹 애플리케이션은 윈도우 2000과 동일하게 aspnet_wp.exe라는 ASP.NET 작업 프로세스에 의해 호스팅되며 모든 ASP.NET 웹 애플리케이션은 이 작업 프로세스에 의해 처리된다.
이 작업 프로세스가 종료되면 모든 ASP.NET 웹 애플리케이션이 중단될 것임은 이전과 완전히 동일하다. Aspnet_wp.exe 프로세스는 명시적으로 inetinfo.exe가 종료되거나 asp net_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는 더 이상 메타베이스를 관리하지 않는다. 대신 WAS가 메타베이스를 관리하게 되는데, 왜 WAS가 필요하게 되는가는 차츰 설명하도록 하겠다.
작업 프로세스 보호 모드
IIS 6.0의 기본 프로세싱 모델은 작업 프로세스 모드이다. 작업 프로세스 모드는 inetinfo.exe를 거치지 않고 HTTP.SYS에서 곧바로 응용 프로그램까지 클라이언트의 요청이 전달되는 모드를 말한다.
<그림 3>은 작업 프로세스 모드를 잘 보여주고 있다. HTTP.SYS에서 곧바로 클라이언트 요청이 작업 프로세스로 전달되므로 각 작업 프로세스는 각각 ISAPI 필터를 로드하며 작업 프로세스가 호스팅하는 웹 애플리케이션에 따라 개별 프로세스 공간에 ISAPI 익스텐션을 로드하게 된다. 작업 프로세스는 w3wp.exe라는 이름으로 수행되며 메타베이스의 설정에 의해 다수의 w3wp.exe 프로세스가 수행될 수 있다.
<그림3>IIS 6.0 작업 프로세스 보호 모드
작업 프로세스는 하나 이상의 웹 애플리케이션을 호스팅하거나 하나의 웹 애플리케이션이 다수의 작업 프로세스로 분산되어 처리될 수 있다. 각각의 경우에 대해 살펴보자. 먼저 하나의 작업 프로세스가 하나의 웹 애플리케이션을 담당하는 경우는 하나의 w3wp.exe가 하나의 웹 애플리케이션을 전담하여 수행하는 경우이다.
이 경우는 IIS 5.0의 응용 프로그램 보호 수준의 ‘높음’과 유사하다. 다른 점은 inetinfo.exe가 웹 브라우저의 요청을 먼저 수신하고 이 요청을 명명된 파이프(named pipe)를 통해 dllhost.exe로 전달되었지만 이제는 inetinfo.exe가 80포트를 리스닝하지 않기 때문에 HTT P.SYS로부터 곧바로 w3wp.exe로 HTTP 메시지가 전달된다는 점이다. 이 웹 애플리케이션을 종료하기 위해서는 인터넷 서비스 관리자에서 해당 작업 프로세스를 선택하고 종료 버튼을 누르면 된다. 구체적인 방법에 대해서는 후에 다시 설명하도록 하겠다.
두 번째는 하나의 작업 프로세스(w3wp.exe)가 두 개 이상의 웹 애플리케이션을 호스팅하는 경우이다. 이 경우는 IIS 5.0 모델의 ‘보통’ 보호 수준과 유사하다. 다른 점은 inetinfo.exe가 관여하지 않고 HTTP.SYS 드라이버로부터 웹 브라우저의 요청이 작업 프로세스로 직접 전달된다는 점이다. 물론 작업 프로세스가 종료되면 이 프로세스가 호스팅 중이던 모든 웹 애플리케이션 역시 종료된다.
마지막으로 살펴볼 경우는 하나의 웹 애플리케이션이 여러 작업 프로세스에 의해 처리되는 경우이다. 이 경우는 특별히 웹 정원(web garden)이라 부른다. 웹 농장(web farm)은 여러 대의 웹 서버가 한 웹 사이트를 서비스하는 경우를 말하며 웹 정원은 하나의 웹 서버 기계 내에서 한 웹 애플리케이션을 여러 프로세스가 나누어 처리하는 경우를 말한다.
각각의 작업 프로세스는 웹 브라우저의 요청을 나누어 처리하게 되므로 여러 개의 CPU를 가진 서버의 처리 능력을 향상시켜줄 뿐만 아니라 작업 프로세스들이 두 개 이상이 되므로 어느 프로세스가 예기치 않게 종료되더라도 서비스는 계속 유지될 수 있다.
웹 정원으로 설정된 웹 애플리케이션이 시작되면 IIS는 메타베이스에 설정된 작업 프로세스의 개수만큼을 생성할 것이며 어느 작업 프로세스가 종료하거나 작업 중이지 않다고 판단되면 이 작업 프로세스를 재활용할 것이다.
IIS 6.0의 작업 프로세스 보호 모드의 전반적인 장점은 기존 모델에 비해 빠른 성능을 낼 수 있으며 관리의 편의성을 증대시켰다는 점이다. Inetinfo.exe가 아닌 HTTP.SYS가 커널 모드에서 작업하며 커널 모드에서 직접 HTTP 메시지를 작업 프로세스에 전달해 주므로 성능이 향상될 수 있으며 여러 작업 프로세스를 통해 전체 웹 사이트가 중단되는 경우를 현저히 줄여줄 수 있다. MS에 의하면 4 CPU에서는 15%, 8 CPU에서는 25% 정도의 ASP.NET 애플리케이션의 성능 향상을 가져올 수 있다고 한다.
지금까지는 일반적인 IIS 6.0의 새로운 프로세싱 모델을 살펴봤다. 이제 ASP.NET의 관점에서 이 모델을 살펴보도록 하자. 윈도우 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에서는 업데이트 대상 혹은 다운으로 간주되는 웹 애플리케이션만을 선택하여 종료시키거나 재시작시킬 수 있다. 하나의 작업 프로세스에 몇 개의 웹 애플리케이션을 호스팅할 것인가 혹은 웹 애플리케이션을 몇 개의 작업 프로세스를 할당(웹 정원)할 것인가의 선택은 순전히 웹 서버의 목적, 사이트의 용도, 사용자 수 등을 고려하여 결정할 일이다. 웹 마스터는 이제 다양한 선택의 폭을 갖추게 된 것이다.
윈도우 2000에서는 ASP.NET 애플리케이션은 asp net_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의 세션 객체나 애플리케이션 객체는 정보를 메모리에 기록하므로 사용해서는 안 되는 대표적인 것이다. 어떤 작업 프로세스에서 세션 객체에 어떤 값을 기록했다 하더라도 다른 작업 프로세스에서는 이 세션 객체의 값을 볼 방법은 없다.
이런 세션 문제는 전통적으로 ASP의 문제점이었고 웹 농장 구축에서도 항상 문제였으며 웹 정원에서도 문제는 여전하다. 따라서 웹 정원에서는 세션보다는 쿠키나 데이터베이스에 상태를 저장하는 것이 좋다.
ASP.NET의 경우라면 이야기가 달라진다. ASP.NET은 세션 상태를 저장하기 위해 세 가지 옵션을 제공한다. 디폴트인 in-proc 세션은 문제를 일으키지만 Out-of-proc 세션은 별도의 프로세스에서 세션 정보를 유지할 수 있고 이 프로세스는 별도의 서버에 둘 수 있기 때문이다. 더욱 안전한 세 번째 방법은 SQL 서버에 세션을 기록하는 방법으로 트랜잭션까지 보장하지만 성능이 좋지 못하다.
Web Administration Service
IIS 6.0의 작업 프로세스 보호 모드의 등장으로 인해 새로운 WAS가 필요하게 되었다. WAS는 메타베이스 관리를 위한 윈도우 서비스로서 메타베이스를 관리하고 작업 프로세스를 관리하는 중추적인 역할을 담당한다. 이전에는 HTTP 80포트를 inetinfo.exe가 리스닝하기 때문에 모든 HTTP 메시지를 inetinfo.exe가 수신하고, 이들을 필요에 따라 dllhost.exe에 분배해주었기 때문에 메타베이스는 Inetinfo.exe에 의해 관리되면 되었다.
하지만 작업 프로세스 보호 모드는 HTTP.SYS 커널 드라이버가 HTTP 80포트를 리스닝하므로 수신된 HTTP 메시지를 어떤 작업 프로세스에 넘겨야 하는 가를 HTTP.SYS 드라이버가 알아야 할 필요가 생긴 것이다.
게다가 나중에 설명할 XML 기반의 메타베이스 채용으로 인해 XML 파일에 기록된 메타베이스를 메모리로 로드하고 메모리에 가해진 메타베이스 변화사항을 주기적으로 디스크에 기록할 필요도 생겨났다. 때문에 WAS라는 새로운 서비스가 등장한 것이며 이 서비스는 메타베이스와 작업 프로세스(정확하게 말하면 애플리케이션 풀이며 애플리케이션 풀에 대해서는 조금 후에 설명할 것이다)를 관리하는 주체가 된 것이다. WAS에 대해서는 메타베이스에 대한 내용을 다루면서 좀더 이야기하기로 하자.
안정성
IIS 6.0은 웹 애플리케이션 서버의 역할로서 충분한 안정성을 보장하도록 재구성되었다. 필자는 IIS 6.0의 새로운 기능 중 안정성(reliability) 향상에 많은 점수를 주고 싶다. IIS 6.0은 작업 프로세스가 어떤 임계치를 넘은 메모리 사용이나 CPU 점유를 수행하면 작업 프로세스를 종료하거나 재시작하도록 설정하거나 작업 프로세스가 재시작되도록 할 수 있다. 또한 주기적으로 작업 프로세스의 활동 상황을 감시하고 반응하지 않는 작업 프로세스를 종료시킬 수도 있다.
이런 기능들은 웹 사이트가 안정적으로 24시간 작동할 수 있도록 해주며 웹 애플리케이션의 충돌에 대해 유연한 대응책을 제공한다.
애플리케이션 풀
IIS의 안정성에 관련된 사항을 알기 위해서는 IIS 6.0의 애플리케이션 풀(application pool)에 대한 개념을 이해해야 한다. 애플리케이션 풀에 대해 필자는 이미 설명을 했다. 다만 애플리케이션 풀이라는 용어를 사용하지 않았을 뿐이다. 앞서 보호 모드를 설명할 때 작업 프로세스는 하나 이상의 웹 애플리케이션을 호스팅할 수 있다고 설명한 바 있다.
좀더 정확하게 다시 표현해 보면 이렇다. “웹 애플리케이션은 하나의 애플리케이션 풀에 속하며 애플리케이션 풀은 한 개 이상의 작업 프로세스로 구성된다.” 하나의 웹 애플리케이션이 하나의 작업 프로세스와 대응되는 경우를 생각해 보면, 하나의 애플리케이션 풀이 하나의 웹 애플리케이션을 호스팅하는 것이며 하나의 작업 프로세스로 구성되어 있음을 말하는 것이다.
비슷하게 생각해 보면, 하나의 작업 프로세스가 여러 웹 애플리케이션을 호스팅하는 경우도 하나의 작업 프로세스로 구성된 애플리케이션 풀이 여러 웹 애플리케이션을 호스팅하는 것이다. 웹 정원의 경우, 애플리케이션 풀은 두 개 이상의 작업 프로세스로 구성되어 있으며 한 개 이상의 웹 애플리케이션을 호스팅하는 것을 말한다. 애플리케이션 풀은 IIS 6.0에서 중요한 요소인데, 그 이유는 프로세스 재활용, 헬스 확인, 성능 지수 설정, 보안 설정(뒤에서 모두 설명할 것이다)이 작업 프로세스 단위가 아닌 애플리케이션 풀 단위로 설정되기 때문이다.
<화면3>어플리케이션 풀 설정
<화면 3>은 인터넷 서비스 관리자의 애플리케이션 풀 설정을 보여준다. IIS 5.0과 다르게 컴퓨터 밑에 애플리케이션 풀 폴더가 보이고 생성된 애플리케이션 풀의 목록이 나타난다. 그리고 애플리케이션 풀에 할당된 웹 애플리케이션이 그 밑에 나타나고 있다.
<화면 3>에서 DefaultAppPool 애플리케이션 풀은 ROOT, TestWebApplication, App1 웹 애플리케이션을 호스팅하고 있다. 웹 애플리케이션이 어떤 애플리케이션 풀을 사용할 것인가의 설정은 웹 애플리케이션의 등록정보 대화상자에서 Home Directory(혹은 Virtual Directory) 탭에서 설정이 가능하다. IIS 5.0에서는 ‘애플리케이션 풀’ 설정 대신 ‘응용 프로그램 보호 수준’을 선택하도록 되어 있었다.
애플리케이션 풀에 웹 애플리케이션을 할당하기 위해서는 먼저 애플리케이션 풀을 생성하고 필요한 설정(잠시 후에 다루게 될 것이다)을 수행한 후에 웹 애플리케이션 설정에서 새로이 생성한 혹은 이전에 존재하는 애플리케이션 풀을 <화면 3>과 같이 선택할 수 있다.
재활용
IIS 6.0의 작업 프로세스들은 재활용될 수 있다. 재활용의 의미는 작업 프로세스인 w3wp.exe를 재시작한다는 의미이다. 재활용은 웹 애플리케이션의 운영에 큰 의미를 지닌다. 웹 사이트를 운영하다 보면 서버를 일주일, 한 달 길게는 몇 달 동안 계속 수행시킬 때가 많다. 이 때 시간이 흐르면 흐를수록 응답 시간이 길어지거나 전체적인 웹 서버의 효율이 떨어지는 것을 경험할 때가 많다.
이런 현상의 주요 이유 중 하나는 IIS/COM+의 버그 혹은 애플리케이션의 버그로 인해 메모리 누수(memory-leak)가 발생하는 경우이다. Inetinfo.exe 혹은 dllhost.exe가 점유하는 메모리가 시간이 지날수록 커지며 전체적으로 웹 서버의 메모리 사용량이 증가하기 때문에 성능이 점차로 낮아지는 것이다.
<화면4>재활용 설정
또 한 가지 이유로는 IIS의 작업 쓰레드가 어떠한 이유로 데드락(deadlock)이 걸려 더 이상 작동하지 않는 경우이다. 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>와 같은 대화상자를 통해 조정이 가능하다.
작업 프로세스 재활용과 관련되어 프로그래밍 상의 주의점은 애플리케이션이 작동하던 작업 프로세스가 바뀌기 때문에 메모리에 저장해둔 사항들이 소실된다는 점이다. 앞서 웹 정원에서 언급했던 사항들이 재활용에 관해서도 여전히 적용된다. 따라서 프로세스 재활용을 사용하고자 한다면 세션의 상태 유지에 상당한 주의를 기울여야 한다. 세상엔 공짜란 없다.
헬스 감시
IIS 6.0이 웹 서버의 안정성에 많은 관심을 갖고 있다는 증거는 IIS의 헬스 감시(health monitoring)에서 찾을 수 있다. IIS 6.0의 WAS는 주기적으로 작업 프로세스의 작업 상황을 모니터링할 수 있다. 이런 모니터링 과정은 작업 프로세스 핑(ping)이라 불리며, 핑에 응답하지 않거나 핑에서 자신의 건강도가 낮다고 보고한 작업 프로세스는 재활용 대상이 된다. 또한 어떤 애플리케이션 풀이 주어진 시간 동안 일정 회수의 오류를 발생하면 해당 애플리케이션 풀은 비활성화된다.
이렇게 비활성화된 웹 애플리케이션에 대한 사용자 접근은 ‘서비스 거부’ 오류(HTTP 503)를 경험하게 될 것이다. 이런 IIS 기능은 rapid-fail protection이라 불리는데, 어떤 문제로 인해 작업 프로세스가 계속해서 충돌하는 상황이 오랫동안 반복적으로 일어나지 않도록 하기 위함이다.
필자도 이런 상황을 겪어 보았는데, 실수로 웹 애플리케이션이 사용하는 DLL이 PATH에 포함되어 있지 않아서 30분 동안 웹 애플리케이션은 백 여 번의 재시작을 수행했다! 필자의 경험에서 왜 이름이 rapid-fail protection인가를 이해할 수 있을 것이다.
<화면5>헬스 감시 옵션
헬스 감시의 마지막 설정은 작업 프로세스에 주어진 시작 기간과 셧다운(shutdown) 기간이다. 작업 프로세스는 주어진 시간 안에 시작 완료해야 하며 주어진 시간 내에 셧다운돼야 한다. IIS가 작업 프로세스를 종료해야 할 경우, 작업 프로세스에게 셧다운할 것을 지시한다(임의로 그냥 종료시키지 않는다). 그리고 주어진 셧다운 타임아웃 내에 작업 프로세스가 종료하지 않은 경우에는 프로세스를 강제 종료(termina te)시켜 버린다. 지금까지 설명한 헬스 감시의 기능들은 <화면 5>를 통해 설정이 가능하다.
성능 관리
IIS 6.0에서는 성능 관리(performance management)가 가능하다. 여기서 말하는 성능 관리는 애플리케이션 성능을 올려주도록 관리해준다는 의미가 아니다. 웹 서버의 전체적 성능이 떨어지지 않도록 프로세스를 관리하거나 주의를 주겠다는 의미이다.
첫 번째 기능은 애플리케이션 풀에 특정 시간 이상 HTTP 요청이 들어오지 않으면 작업 프로세스(들)를 종료시켜 준다. 이는 불필요한 프로세스를 종료시킴으로써 시스템의 전체적인 자원 효율을 높이겠다는 의미이다. 두 번째는 단시간에 몰리는 HTTP 요청을 줄여주는 기능으로서 각 작업 프로세스마다 가지고 있는 HTTP 요청 큐(queue)에 기록되는 요청 개수에 제한을 두는 것이다. 이는 폭주하는 사용자 요청을 조정함으로써 웹 애플리케이션의 응답 속도를 떨어뜨리지 않을 수 있다. 이 제한 사항을 넘는 사용자 요청은 Server-Busy 결과를 받게 된다. 세 번째 기능은 소위 CPU 쓰로틀링(throttling)이라 불리는 기능으로 일정 기간 동안 작업 프로세스가 어떤 한계를 넘는 CPU 점유를 수행하면 이벤트 로그를 남기고 필요에 따라 작업 프로세스를 재활용하도록 할 수 있다.
<화면6>성능 관리 옵션
앞서 언급한 웹 정원의 작업 프로세스 개수 설정 역시 성능 관리 카테고리에 포함된다. <화면 6>의 대화상자를 이용하여 웹 정원에 포함될 작업 프로세스의 개수를 설정할 수 있다. 작업 프로세스의 개수를 설정할 때는 CPU의 개수, 메모리 양, 애플리케이션의 상태 저장 방법 등의 다양한 사항에 대해 검토를 충분히 한 후에 작업 프로세스 개수를 설정해야 할 것이다. 작업 프로세스의 개수를 무턱대고 높게 잡는다고 해서 성능이 올라가지 않음을 유의해야 할 것이다.
보안
IIS 6.0은 이전 버전들이 바이러스 공격이나 기타 사항들에 상대적으로 취약하다는 악명을 떨치고자 노력한 흔적이 보인다. MS의 이런 노력이 얼마나 효과가 있을지는 두고 볼 일이지만 세심한 곳까지 신경을 쓴 것 같다.
필자는 윈도우 닷넷을 설치한 후 IIS 도움말을 보기 위해 웹 브라우저를 띄우고 http://localhost/를 입력했다. 하지만 전혀 엉뚱하게도 WWW 서비스가 존재하지 않는다는 내용의 오류를 만났다. 서두에서도 언급했듯 윈도우 닷넷은 IIS를 디폴트로 설치하지 않는다. 윈도우 2000의 행동과는 정반대의 행동을 하고 있는 것이다. 왜 IIS를 기본으로 설치하지 않을까?
모든 윈도우 기반의 서버들이 웹 서비스를 제공하지는 않는다(다시 말하지만 여기서의 웹 서비스는 HTTP 기반의 광의의 웹 서비스를 말한다. SOAP을 사용하는 특정 웹 서비스를 말하지 않음을 주의하자). 그럼에도 불구하고 윈도우 2000 서버 제품군은 IIS를 기본으로 설치한다. 웹 개발자들에게는 이것이 좋을지 몰라도 단순한 데이터베이스 서버나 파일 서버에 IIS 설치는 이점보다 단점을 가져올 수 있다. 특히 바이러스에게는 이렇게 무심코 설치된 IIS는 단꿀과 물엿이 흐르는 좋은 숙주가 된다.
예를 들어 파일 서버 목적으로 설치된 윈도우 2000이 있다고 가정해 보자. 파일 서버가 주요 용도이므로 이 서버에 IIS가 설치된 것을 관리자는 크게 고려하지 않을 것이다. IIS에 관련된 보안 패치나 기타 IIS와 관련된 관리를 수행하지 않을 것임은 자명하다. 이런 윈도우 2000 서버들이 인터넷에는 부지기수로 널려 있다. 이런 서버들은 IIS를 목표로 하는 단 한번의 바이러스 공격으로 와해되고 바이러스를 퍼뜨리는 좋은 위치로 활용될 것이다. 윈도우 닷넷은 명시적으로 시도하지 않는 한 IIS를 설치하지 않는다.
이제 IIS를 설치했다고 가정해 보자. 그리고 간단한 ASP 파일을 만들어 IIS를 테스트해 보고자 한다. 몇 줄짜리 ASP는 순식간에 만들 수 있고 테스트를 했다. 하지만 브라우저에 나타난 결과는 역시 오류 메시지뿐이다. IIS 6.0은 최초 설치 후에는 오직 정적 컨텐츠(.htm, .gif 등)만을 서비스한다. ASP, ASP.NET, ISAPI 익스텐션을 비롯한 CGI, SSI(Server-Side Include) 등의 모든 동적 컨텐츠는 명시적으로 활성화돼야만 서비스가 가능해진다. 이런 상태를 락(Lock) 모드라 불리며 IIS 5.x를 위한 락 매니저도 제공되고 있다. 이렇게 IIS가 락 모드 상태에서 설치되는 이유는 앞서 설명한 내용과 같다.
단순히 설치되었다는 것으로만 바이러스나 악의적 해커의 공격에 무방비로 노출되는 것을 막고자 함이다. 윈도우 닷넷 베타 버전에서는 설치 후에 필요한 기능을 Enable해야 했지만 윈도우 닷넷 RC 버전에서는 친절하게도 <화면 1>과 같은 설정에서 ‘프론트 페이지 익스텐션’과 ASP.NET을 기본적으로 Enable할 것인가를 묻는다. 또한 그 외의 모든 ISAPI 익스텐션(ASP도 ASP.NET도 근본적으로는 ISAPI 익스텐션 일종이다)은 사용이 허가되지 않는다. 물론 <화면 7>과 같은 설정을 통해 필요한 ISAPI 익스텐션을 사용하도록 할 수도 있다.
<화면7>ISAPI 익스텐션의 제어
IIS 6.0의 보안상 나아진 점 중 또 한 가지는 각 작업 프로세스마다 프로세스 계정을 할당할 수 있다는 점이다. IIS 5.0에서도 불가능한 것은 아니었지만 웹 애플리케이션의 보호 수준을 ‘보통’ 혹은 ‘높음’으로 설정해야만 가능했고 프로세스 계정을 바꾸기 위해서는 인터넷 서비스 관리자가 아닌 구성요소 관리자를 통해 설정했다.
가장 안 좋았던 것은 ASP.NET은 오직 aspnet_wp.exe 프로세스에 의해서만 호스팅되므로 모든 ASP.NET 웹 애플리케이션들이 하나의 프로세스 계정을 공유했다는 점이다.
IIS 6.0은 이제 프로세스 풀에 사용할 프로세스 계정을 설정할 수 있다(<화면 8>). 그리고 ASP.NET 웹 애플리케이션들은 다양한 작업 프로세스에 의해 호스팅되므로 보다 안전하게 웹 애플리케이션 보안 설정을 수행할 수 있다. 또한 윈도우 닷넷은 작업 프로세스들이 사용하는 계정들을 IIS_WPG 그룹에 포함시키고 있으므로 특정 디렉토리를 작업 프로세스들이 액세스하도록 허용하기 위해서는 IIS_WPG 그룹에 대한 권한을 주면 된다. 이전에는 IUSR_XXX, IWAM_XXX, ASP NET 계정 등에 권한을 따로따로 설정해야 했다.
<화면8>작업 프로세스의 계정 설정
마지막으로 IIS 6.0의 보안 관련 사항은 향상된 SSL 관련 기능이다. SSL 관련 설정을 위한 마법사가 향상되었고 SSL 암호화를 위한 윈도우 Crypto 프로바이더를 선택할 수 있게 되었다. 이는 다양한 암호화 패키지를 사용할 수 있음을 의미하고 하드웨어를 통해 암호화를 수행하는 암호화 패키지를 통해 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가 시작되면 메모리로 읽혀진다. 메모리로 읽혀진 메타베이스는 인 메모리 메타베이스라 불리며 이제부터 인터넷 서비스 관리자를 통하거나 프로그래밍적인 방법으로 메타베이스가 변경되면 인 메모리 메타베이스가 변경된다. 그리고 IIS의 WAS는 틈 만 나면 인 메모리 메타베이스의 변경 사항을 디스크에 기록한다.
물론 이런 과정은 트랜잭셔널(transactional)하게 작동하며 변경 사항은 히스토리로서 하드 디스크에 남게 된다. 또한 XML 메타베이스(평범한 텍스트 파일이다)가 변경되면 변경 사항을 읽어들여 인 메모리 메타베이스가 갱신되도록 유지할 수도 있다. 이제 여러 대의 웹 서버를 동일한 환경으로 맞추기 위해서는 Metabase.xml 파일을 복사하기만 해도 된다.
한 가지 더 메타베이스와 관련된 희소식은 백업/리스토어(backup/restore) 기능이 크게 강화되었다는 점이다. 윈도우 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 애플리케이션을 운영하는 데 최적의 환경이 될 것이라는 점이다. @
