Special Coverage: Windows Server 2008

IIS 7.0 시작

Isaac Roybal

한 눈에 보기:

• IIS 7.0 아키텍처의 변화
• IIS 7.0 관리
• 이전 버전과의 호환성
• IIS 7.0 문제 해결

IT 조직은 저마다의 고유한 요구 사항과 목표에 따른 각기 다른 문제를 안고 있으며, 특히 웹 사이트나 서비스의 호스팅과 관련된 경우 더욱 그렇습니다. 조직의 요구 사항을 충족하려면 웹 서버에 여러 가지 기능을 추가하고 적절히 조합해야 합니다.

여기에는 이러한 기능의 조합을 여러 서버에 복제하는 동시에 모든 서버를 효율적으로 관리해야 하는 문제가 따릅니다. IIS 7.0의 가장 중요한 변경 중 일부는 IT 조직이 웹 서버나 웹 팜을 구축할 때 바로 이러한 작업을 수행할 수 있도록 지원하는 데 목적을 두고 있습니다.

IIS 7.0에서 제공하는 우수한 기능들을 살펴보면서 이들 기능의 세부적인 내용을 독자 여러분과 공유할 수 있게 된 점에 대해 매우 기쁘게 생각합니다. 이 한 편의 기사로는 모든 기능을 다룰 수 없으므로 여기서는 IIS 7.0의 가장 중요한 기능 및 가장 중요한 변경 내용 중 몇 가지에 대해서만 중점적으로 살펴보겠습니다. 보다 자세한 내용은 IIS.net의 IIS 커뮤니티 웹 사이트를 방문하십시오.

새로운 아키텍처

IIS 7.0의 중요한 변경은 아키텍처, 요청 처리, PHP 응용 프로그램 프레임워크 지원 및 구성 저장소와 관련됩니다. IIS 6.0에서는 기능을 전부 설치하거나 전부 설치하지 않는 방법밖에는 없었습니다. 기능을 설치하려면 모든 기능을 설치해야 했고 IIS의 사용자 지정은 ISAPI를 통해서만 가능했습니다.

IIS 7.0은 웹 관리자가 기본 기능 집합을 먼저 사용해 본 다음 나중에 환경에 필요한 추가 기능을 설치하기를 원한다는 가정하에 설계되었습니다. 관리자의 환경에 대해 가장 잘 알고 있는 사람은 바로 관리자 자신입니다. 따라서 IIS 7.0은 관리자가 고유의 사용자 지정 웹 서버를 만들 수 있도록 기본 구성 요소를 제공합니다. 이렇게 하면 서버의 공격 노출 영역이 줄어들고 사용되지 않는 구성 요소를 업데이트할 필요가 없으므로 관리 오버헤드가 감소됩니다. 이러한 접근 방법의 핵심은 바로 IIS 7.0의 모듈식 아키텍처입니다.

IIS 7.0에는 서버에 설치할 기능, 즉 모듈을 선택할 수 있는 새로운 설계가 도입되었습니다. 이러한 모듈은 통합 요청 파이프라인에 직접 연결됩니다. 새로운 모듈식 설계는 공격 노출 영역의 감소는 물론 웹 서버에 필요한 공간을 줄이는 것을 비롯하여 여러 가지 장점을 제공합니다.

IIS에는 현재 40개의 기본 모듈이 포함되어 있으며, 이제 기본, 익명 및 Windows® 인증 등의 모듈은 요청 파이프라인에 독립적으로 추가할 수 있는 개별 모듈로 제공됩니다. 이러한 모듈은 8개의 하위 범주로 그룹화되어 있습니다(그림 1 참조).

그림 1** 8개의 기능 영역으로 분류된 IIS 7.0 모듈 **(더 크게 보려면 이미지를 클릭하십시오.)

이제 관리자 환경에 꼭 맞는 사용자 지정 웹 서버를 만들 수 있게 되었습니다. 그러나 사용자 지정 인증이나 콘텐츠 수정자 같이 40개의 기본 모듈에서 제공하지 않는 기능이 필요한 경우에는 어떻게 해야 할까요? 간단합니다. 이 경우 네이티브 코드나 관리 코드로 필요에 맞는 모듈을 작성한 다음 파이프라인에 곧바로 연결할 수 있습니다. 또한 Microsoft가 새로운 모듈을 별도로 개발하여 제공할 수 있게 되어 사용자가 다음 서비스 팩이나 주요 제품 릴리스가 나올 때까지 기다릴 필요가 없습니다. IIS 7.0에서는 40개의 기본 모듈을 고유의 사용자 지정 모듈로 덮어쓸 수 있는 기능도 제공합니다. 고유의 모듈을 만드는 방법에 대한 자세한 내용은 IIS.net을 참조하십시오.

통합 요청 파이프라인

통합 요청 파이프라인은 페이지가 제공될 때마다 순서대로 수행되어야 하는 일련의 기본 단계라고 볼 수 있습니다(그림 2 참조). 일반적으로 어떤 형태로든 인증이 수행된 후에는 콘텐츠 검색을 위한 권한 부여, 해당 콘텐츠에 필요한 처리기 결정과 실행, 필요한 로깅의 수행 등이 이루어져야 하며 마지막으로 응답을 보내야 합니다. 통합 요청 파이프라인은 IIS 7.0에 서로 다른 응용 프로그램 프레임워크를 동시에 실행할 수 있는 유연성을 제공합니다. 예를 들어 사용자 지정 로깅 모듈을 사용하여 주요 PHP 콘텐츠에 대해 폼 인증을 실행할 수 있으며, 이 모두를 하나의 파이프라인에서 실행할 수 있습니다.

그림 2** IIS 7.0 통합 파이프라인 및 모듈 **(더 크게 보려면 이미지를 클릭하십시오.)

통합 요청 파이프라인은 서버의 각 웹 사이트에 있으며 통합 모드와 클래식 모드의 두 가지 모드 중 하나로 실행할 수 있습니다. 기본 모드인 통합 모드에서는 특정한 기능을 파이프라인에 통합할 수 있으므로 요청 프로세스를 보다 세밀하게 제어할 수 있습니다. 호환성을 위해 클래식 모드에서는 IIS 6.0/ISAPI 기능을 ISAPI 모듈을 통해 파이프라인에 재현합니다. 이는 응용 프로그램을 IIS 7.0으로 마이그레이션하는 경우에 매우 유용합니다.

기본 설치

이제 새로운 모듈식 웹 서버를 설치하는 방법에 대해 설명하겠습니다. 기본 설치로 제공된 IIS 7.0을 보면 10개의 모듈만 포함된 것을 알 수 있습니다(Windows Process Activation Service를 포함한 경우). IIS 7.0 설치 프로그램은 웹 서버 역할을 설치하는 경우 IIS의 기본 기능, 즉 일반 HTML이나 기존 ASP 같은 정적 콘텐츠를 제공하는 데 필요한 모듈만 제공합니다. 이후에 서버에 어떤 기능을 설치할 것인가에 대한 판단은 전적으로 관리자의 몫입니다. 다음은 기본 설치에 포함되는 기능입니다.

• 정적 콘텐츠, 기본 문서, 디렉터리 검색 및 HTTP 오류를 비롯한 일반 HTTP 기능
• HTTP 로깅 및 요청 모니터 등의 상태 및 진단 기능
• 요청 필터링 등의 보안 기능
• 정적 콘텐츠 압축 등의 성능 기능
• IIS 관리 콘솔을 비롯한 관리 도구
• Windows Process Activation Service

보시다시피 기본 설치로 제공된 서버는 ASP.NET이나 진단 및 문제 해결 기능 같은 IIS 7.0의 새로운 기능이 포함되지 않은 최소한의 서버입니다. 서버에서 ASP.NET 및 FastCGI(PHP) 같은 동적 콘텐츠를 제공하는 추가 기능을 사용하도록 설정하는 작업은 간단합니다. Windows Server® 2008 서버 관리자 내에 있는 웹 서버 역할의 "역할 서비스 추가"에서 설치할 모듈 집합을 선택하기만 하면 됩니다.

새로운 구성 저장소

IIS 7.0의 또 다른 중요한 변경은 새로운 구성 저장소입니다. 이제 XML 구성 시스템으로 대체된 메타베이스는 이전 버전과의 호환성을 위해서만 선택적으로 설치하는 구성 요소가 되었습니다. "메타베이스도 XML이었다"라는 생각이 드실 것입니다. 물론 그렇습니다. 그러나 이전의 메타베이스는 사람이 판독하기가 어렵고 번거로웠습니다. 이제 이 메타베이스가 보다 유연성 있는 XML 시스템으로 대체되었습니다. ASP.NET과 마찬가지로 IIS 7.0에서도 간단 명료하고, 이식 가능하며, 읽기 쉬운 .config 파일을 사용합니다.

이러한 형식으로의 전환은 이제 개별 시스템에 맞게 조정되었던 메타베이스와는 달리 구성 시스템이 시스템과 독립적으로 존재한다는 것을 의미합니다. 그 결과 끌어서 놓기나 xcopy를 사용하여 구성 시스템을 다른 서버에 간편하게 이식할 수 있게 되었습니다.

이 새로운 구성 시스템은 IIS 7.0의 공유 구성이라는 새로운 기능을 활용함으로써 웹 팜에 대해 중요한 역할을 합니다. 새 구성 시스템은 이식이 가능하므로 웹 팜의 모든 노드에서 하나의 마스터 .config 파일을 공유할 수 있습니다. 공유 구성을 사용하면 알려진 적절한 테스트 환경 서버의 구성을 내보낸 다음 프로덕션 환경이나 "라이브" 환경에서 공유할 수 있습니다.

.config 파일을 내보낼 때 암호화 키 암호를 제공해야 합니다. 암호를 제공하면 권한 없이 서버의 .config 파일을 모방하려는 악성 웹 서버로부터 파일을 보호할 수 있습니다.

공유 구성을 사용하도록 설정하는 방법은 간단합니다. IIS 관리자의 서버 노드에서 작업창의 관리 섹션에 있는 공유 구성을 선택합니다. "공유 구성 사용"을 선택하고 공유하려는 구성의 실제 경로(일반적으로 UNC 공유)를 지정하며 실제 경로에 액세스하는 데 필요한 자격 증명을 입력한 다음 '적용'을 클릭하기만 하면 됩니다. .config가 있으면 파일의 암호화 암호를 확인하는 메시지가 표시됩니다. 이 프로세스가 완료되면 새 .config를 사용하도록 IIS 관리자를 다시 시작합니다.

이 새 구성 시스템은 이전의 구성 시스템과는 구조가 다릅니다. 이제 새 구성 시스템의 구조에 대해 간략히 살펴보겠습니다. 그림 3에서 볼 수 있듯이 IIS 7.0의 구성은 서버 전체 설정과 사이트별 설정이라는 두 가지 범주로 나뉩니다. 서버 전체 설정은 모두 %systemroot%\windows\system32\inetsrv\config에 있는 applicationhost.config 내에 저장됩니다. 여기에는 설치된 모든 모듈, 서버의 사이트 등이 포함됩니다. 사이트별 설정은 개별 web.config 파일에 저장됩니다.

그림 3** 서버 전체 설정에는 하나의 .config 파일이 사용되고 해당 서버의 각 웹 사이트에는 개별 .config 파일이 사용됩니다. **(더 크게 보려면 이미지를 클릭하십시오.)

ASP.NET을 사용해 본 적이 있다면 web.config 파일에 대해 잘 알고 있을 것입니다. IIS 7.0에서는 web.config 파일을 사용하여 ASP.NET 설정은 물론 사이트의 기본 문서 및 응용 프로그램 설정 등의 개별 웹 사이트에 고유한 설정을 저장합니다. 즉, 서버의 각 사이트마다 하나의 web.config 파일이 있습니다.

사이트의 web.config 파일은 %systemroot%\inetpub\wwwroot 같은 사이트의 실제 경로에 있습니다. 이러한 설계를 통해 앞에서 언급한 이식성이라는 장점을 사이트 수준에서 얻을 수 있습니다. 예를 들어 테스트 서버에서 사이트를 손쉽게 개발한 다음 끌어서 놓기나 xcopy를 사용하여 사이트의 web.config와 응용 프로그램 파일을 프로덕션 서버로 복사할 수 있습니다.

.config 파일을 이식하거나 공유할 때는 IP 주소와 드라이브 문자 같은 시스템별 정보에 유의해야 합니다. IIS 7.0에서는 %systemroot% 같은 OS 환경 변수를 지원함으로써 이를 간과하지 않도록 합니다. 또한 테스트 서버와 프로덕션 서버에 동일한 모듈 집합을 설치해야 합니다. 이렇게 하면 예기치 않은 응용 프로그램 오류를 방지하는 데 도움이 됩니다. 설치되지 않은 모듈을 web.config가 참조하거나 기본 모듈이 사용자 지정 모듈과 충돌하는 경우에도 오류가 발생할 수 있습니다.

웹 서버 관리

이제 사용자 지정 및 이식이 가능한 유연성 있는 새로운 웹 서버가 만들어졌습니다. 이제 웹 서버를 어떤 방식으로 관리해야 할까요? 관리는 IIS 7.0 계획 및 구축의 매우 중요한 부분이며 관리 작업을 처리하는 방법은 여러 가지입니다.

일반적으로 관리 작업은 UI 내에서의 가리키고 클릭하기 관리, 명령줄을 통한 명령 입력, 스크립트 작성을 통한 자동화의 세 가지 범주 중 하나에 해당합니다. 먼저 UI를 사용한 관리부터 살펴보겠습니다.

IIS 6.0에서는 Microsoft® Management Console(MMC) 스냅인 UI에 트리 보기와 탭 보기의 두 가지 친숙한 기본 보기가 포함되어 있었습니다. 자세한 설정을 알아보기 위해 마우스 오른쪽 단추로 클릭하고 속성을 선택하면 엄청나게 많은 옵션이 포함된 다양한 탭이 표시되었습니다.

IIS 7.0에서는 UI가 완전히 새롭게 수정되었습니다. IIS 관리자라는 이 UI는 그림 4에서 볼 수 있듯이 작업 기반 방식을 사용하도록 설계되었습니다. Windows XP 및 Windows Server 2003과 같은 하위 수준 클라이언트를 위한 원격 관리자도 제공되며, 이는 IIS.net/downloads에서 다운로드할 수 있습니다.

그림 4** IIS 7.0의 새로운 UI **(더 크게 보려면 이미지를 클릭하십시오.)

새로운 사용자 인터페이스는 왼쪽의 연결 창, 오른쪽의 작업 창 및 중앙의 작업창이나 작업 영역으로 구성됩니다. 왼쪽의 연결 관리자 트리는 부모 및 자식 노드가 포함된 IIS 6.0 트리 보기와 비슷합니다. 트리 보기에는 새 연결을 만들고, 현재 연결을 저장하고, 기존 연결을 삭제할 수 있는 기능이 새로 추가되었습니다. 작업창은 이 UI에서 가장 크게 개선된 부분으로, 작업을 수행하는 데 사용하는 두 개의 보기가 포함되어 있습니다. 기능 보기는 이전의 "탭" 보기에서 제공하던 IIS의 모든 구성 가능한 속성을 가져와서 IIS, 관리 및 보안 같은 관리 영역별로 그룹화합니다.

ASP.NET 속성도 IIS 관리자에 통합되므로 추가 MMC 스냅인을 사용할 필요가 없습니다. 구성 가능한 각 속성은 고유의 아이콘으로 표시되므로 찾기가 쉽습니다. 또한 IIS 관리자는 Windows Forms 응용 프로그램으로 만들어졌으므로 직접 작성한 사용자 지정 모듈이나 기능에 대한 플러그 인 아이콘을 손쉽게 추가할 수 있습니다.

작업창의 또 다른 보기인 콘텐츠 보기에서는 IIS 6.0에서와 비슷하게 사이트의 콘텐츠 디렉터리에 있는 내용을 보고 해당 콘텐츠에 대해 작업을 수행할 수 있습니다. 콘텐츠 보기에는 특정 콘텐츠 부분, 즉 특정 웹 페이지를 선택한 다음 기능 보기로 전환하여 선택한 콘텐츠에 대해 특정 설정을 실행할 수 있는 기능이 추가되었으며 이를 통해 페이지 수준까지 콘텐츠를 보다 세밀하게 제어할 수 있습니다.

다른 관리 방법

명령줄을 선호하는 사용자를 위해 APPCMD.exe라는 강력한 새로운 도구가 제공됩니다. 이 명령줄 도구를 사용하면 사이트 중지나 현재 .config 파일 백업 등의 간단한 작업은 물론 구성 스키마 검색 같은 복잡한 작업을 수행할 수 있습니다. 구문은 다음과 같이 매우 간단합니다.

APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>. 

APPCMD에 사용할 수 있는 모든 개체를 표시하려면 다음과 같이 입력하십시오.

APPCMD /? 

또는 특정 개체 유형에 사용할 수 있는 명령을 보려면 다음과 같이 입력하십시오.

APPCMD (object-type) /?

모든 코드 작성자를 위해 IIS 7.0에는 Microsoft.Web.Administration이라는 관리 코드 API와 새로운 WMI(Windows Management Instrumentation) 공급자가 추가되었습니다. 이제 이 두 옵션을 통해 IIS 7.0 관리용 도구를 스크립팅하고 자동화하고 작성하는 다양한 방법을 활용할 수 있게 되었습니다. 두 옵션 모두 Windows PowerShell®과 함께 사용할 수 있으며 WMI 공급자의 경우 VBScript 및 JScript®와 함께 사용할 수도 있습니다. 자세한 내용은 blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx를 참조하십시오.

원격 관리 및 위임된 관리

IIS 7.0에서는 서버, 사이트 및 웹 응용 프로그램을 원격으로 관리하고 관리자가 아닌 사용자에게 관리 권한을 안전하게 위임하는 새로운 방법을 제공합니다. 먼저 새로운 원격 관리 기능과 이러한 기능을 편리하게 활용하는 방법을 살펴보겠습니다.

과거에는 두 가지 방법으로 IIS 서버를 원격으로 관리할 수 있었습니다. 하나는 원격 관리 웹 사이트를 사용하는 방법이고 다른 하나는 원격 데스크톱/터미널 서비스를 통해 UI에 액세스하는 방법이었습니다. 그러나 사용자가 방화벽 외부에 있거나 사이트에 없는 경우에는 이러한 옵션이 그다지 유용하지 않았습니다. IIS 7.0에서는 방화벽 환경에서 편리하게 사용할 수 있는 HTTPS를 통해 작동하는 원격 관리 기능을 UI에 직접 구축함으로써 이러한 단점을 보완합니다.

IIS 7.0의 원격 관리는 여러 가지 측면에서 유용합니다. 무엇보다도 로컬에서 로그온한 것과 동일한 UI 환경을 이용할 수 있습니다. 또한 HTTPS를 통해 통신이 이루어지므로 방화벽에서 포트를 열 필요가 없습니다. 마지막으로, 단일 UI에서 여러 서버를 관리할 수 있으므로 한 번에 여러 개의 원격 데스크톱 창이나 원격 웹 사이트 창을 열어 둘 필요가 없습니다.

IIS 7.0 내의 원격 관리 서비스는 실제로는 NT Service\WMSVC라는 Windows NT® 로컬 서비스 계정에서 별도의 서비스로 실행되는 소규모 웹 응용 프로그램입니다. 따라서 IIS 서버 자체가 응답하지 않는 경우에도 원격 관리 기능은 그대로 사용할 수 있습니다.

IIS 7.0에 포함된 대부분의 기능과 마찬가지로 원격 관리도 보안을 위해 기본적으로 설치되지 않습니다. 원격 관리 기능을 설치하려면 관리 도구에 있는 Windows Server 2008 서버 관리자에서 웹 서버 역할에 대한 역할 서비스를 추가해야 합니다. 원격 관리 기능을 설치하고 나면 원격 연결을 활성화하고 WMSVC 서비스를 시작해야 합니다. WMSVC 서비스는 기본적으로 중지되어 있습니다.

WMSVC 서비스의 기본 시작 설정은 '수동'입니다. 시스템을 다시 부팅한 후 서비스가 자동으로 시작되도록 하려면 설정을 '자동'으로 변경해야 합니다. 명령줄에서 다음과 같이 입력합니다.

sc config WMSVC start=auto

관리 서비스를 통해 원격 연결을 활성화할 때 ID 자격 증명, 연결 및 IPV4 주소 제한 등의 설정 목록이 표시됩니다. 이때 'Windows 자격 증명만'이나 'Windows 및 IIS 관리자 자격 증명' 중 IIS 7.0에 대한 연결 권한을 부여할 ID 자격 증명 집합을 결정해야 합니다.

첫 번째 옵션은 로컬 계정이든 도메인 계정이든 Windows 사용자 계정만 허용한다는 것을 나타냅니다. 두 번째 옵션은 Windows 사용자 계정과 IIS 7.0에 새로 도입되었으며 Windows 사용자 계정과 연결되지 않은 IIS 관리자 사용자라는 새로운 유형의 계정을 모두 포함합니다. IIS 관리자 사용자 계정을 사용하는 경우 관리자는 IIS 7.0의 컨텍스트에서만 인식되고 OS에 대한 액세스 권한이 없는 사용자 계정을 만들 수 있습니다. 마지막으로, IIS에서는 기본적으로 자체 서명된 인증서를 제공하지만, 별도로 유효한 서명된 SSL 인증서를 추가하는 것이 좋습니다. 이제 설정을 적용하고 서비스를 시작합니다.

추가적인 제어와 보안을 위해 IT 관리자는 개별 사이트나 웹 응용 프로그램의 관리 작업을 관리자가 아닌 사용자에게 안전하게 위임할 수 있습니다.

위임된 관리는 기본적으로 원격 관리이지만 액세스 범위가 개별 사이트나 웹 응용 프로그램으로 제한됩니다. 특히 여기서는 IIS 관리자 사용자 기능이 유용합니다. 사이트 외부의 소유자 같은 사용자를 위해 IIS 사용자를 만든 다음 해당 사이트나 응용 프로그램에 대한 관리 권한을 위임할 수 있습니다. 권한을 위임받은 사용자는 서버 전체 설정에는 액세스할 수 없으며 특정 사이트나 웹 응용 프로그램의 설정에만 액세스할 수 있습니다.

또한 관리자는 사용자가 변경하거나 UI에 표시할 수 있는 기능과 설정을 지정할 수도 있습니다. 예를 들어 임의의 사용자가 사이트에 사용되는 인증 유형을 변경하지 못하도록 하려면 이 기능을 '읽기 전용'이나 '상속 안 됨'으로 설정할 수 있습니다. '읽기 전용'으로 설정된 기능의 경우 사용자가 기능에 액세스하고 설정을 확인할 수는 있지만 설정을 변경할 수는 없으며 '상속 안 됨'으로 설정된 기능의 경우 위임된 사용자의 IIS 관리자 보기에 기능 아이콘이 나타나지 않습니다. 이 같은 기능 위임을 통해 웹 서버에 대한 관리 권한을 제공하지 않고도 엄격하게 제어되는 액세스 권한을 다른 사용자에게 제공할 수 있습니다.

IIS 7.0으로 전환

IIS 7.0을 설계할 때 IIS 팀은 기존의 IIS 6.0용 관리 도구 및 스크립트 중 일부를 사용할 수 있도록 지원함으로써 IIS 7.0으로의 전환이 가능하면 원활하게 이루어지기를 희망했습니다. 이전 버전과의 호환성을 중요하게 고려한 결과 IIS 7.0에서 IIS 6.0 스크립트를 사용할 수 있게 되었습니다. 이제 설치 중 IIS 6.0 메타베이스 호환성에서 실제 IIS 6.0 관리 콘솔에 이르는 모든 도구 집합을 IIS 6.0 관리 호환성 노드에 설치할 수 있습니다.

IIS 6.0 메타베이스 호환성 인프라는 ADOMapper라는 구성 요소를 사용합니다. 메타베이스 호환성 인프라는 새로운 구성 시스템에 대해 IIS 6.0 ABO(Admin Base Object) 및 ADSI(Active Directory 서비스 인터페이스) 메타베이스 스크립트를 실행하여 IIS 6.0에서 수행할 수 있는 작업으로만 구성 시스템을 제한할 수 있도록 합니다. 따라서 구성 시스템에서 새로운 IIS 7.0 속성을 읽고 쓰거나, 새 런타임 데이터에 액세스하거나, ASP.NET 속성이나 web.config 파일을 읽거나 쓸 수 없습니다.

문제 해결 및 진단

문제 해결 및 진단은 대개 시간이 많이 걸리는 번거로운 작업입니다. 대규모 웹 팜이나 심지어는 단일 서버에서조차 로그를 분석하고 문제를 재현하는 작업은 어렵고 번거로울 수 있습니다. IIS 7.0에는 이러한 번거로움과 시간 낭비를 줄이는 실패한 요청 추적이라는 도구가 도입되었습니다. 이 도구는 요청이 중단되거나 오류가 발생하거나 인증 및 권한 부여 문제를 조사하려는 경우와 같은 다양한 상황에서 유용하게 사용할 수 있습니다.

실패한 요청 추적에서는 추적 규칙을 조건으로 사용하여 오류를 검색합니다. 추적할 콘텐츠의 형식(예: 서버의 모든 콘텐츠, ASP.NET 콘텐츠만, PHP 같은 사용자 지정 콘텐츠) 및 추적이 시작되는 조건(예: 특정 상태 코드 반환, 페이지 제공에 소요된 시간, 이벤트 심각도 또는 이들의 조합)을 지정하여 추적 규칙을 작성함으로써 여러 가지 유형의 동작이나 오류를 검색할 수 있습니다.

예를 들어 사용자가 사이트를 로드하는 데 시간이 너무 오래 걸린다고 가정해 보겠습니다. 이러한 시나리오는 어떤 상황에서든 재현하기가 어렵습니다. 특히 시간당 방문 횟수가 수천 건에 이르는 경우에는 더욱 그렇습니다. 실패한 요청 추적을 사용하면 페이지를 로드하는 데 적정 시간(여기서는 2초) 이상이 걸리는 경우 이를 기록하는 추적 규칙을 추가하고 서버에서 자체적으로 문제를 재현할 때까지 기다리면 됩니다(그림 5 참조).

그림 5** 문제 해결을 위해 실패한 요청 추적 사용 **(더 크게 보려면 이미지를 클릭하십시오.)

실패한 요청 추적은 특정 실패한 요청 조건이 감지된 경우에만 이를 기록한다는 점에서 기존의 로깅과는 다릅니다. 로그 파일 자체는 맨 위에 XML 스타일시트가 있는 XML로, 명확하고 읽기가 쉽습니다. 대부분의 다른 IIS 7.0 기능과 마찬가지로 실패한 요청 추적 기능은 기본적으로 설치되지 않습니다. 이 기능은 설치 프로그램의 상태 및 진단 섹션에 있으며 기능을 설치한 후에는 IIS 관리자 내에서 기능을 사용하도록 설정해야 합니다.

IIS 7.0은 모든 관리자에게 있어 눈부신 도약입니다. IIS 7.0의 새로운 아키텍처와 기능은 끊임없이 변화하는 환경에 유연하고 융통성 있게 적응할 수 있도록 지원합니다. 관리 기능, 이전 버전과의 호환성 도구, 문제 해결 기능이 모두 포함된 IIS 7.0을 지금 바로 배포하여 기존의 환경과 함께 원활하게 운영할 수 있습니다.

Isaac Roybal은 Microsoft Windows Server 팀의 제품 관리자로, Windows Server의 모든 웹 관련 작업을 담당하고 있습니다. Windows NT 3.51 및 IIS 4.0부터 Windows Server 작업에 참여했고 이전에는 Office Internet Platform and Operations 그룹의 운영 프로그램 관리자였으며 Windows NT 4.0, Windows 2000 및 Windows Server 2003 관련 MCSE 자격증을 소지하고 있습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..