새로워진 IIS 7.0으로의 이전

IIS

새로워진 IIS 7.0으로의 이전

Fergus Strachan

한 눈에 보기:

• 웹 팜 환경에 IIS 7.0 배포
• 향상된 보안 및 성능
• IIS 6.0에서 IIS 7.0으로 ASP.NET 웹 응용 프로그램 마이그레이션
• IIS 7.0으로 PHP 웹 응용 프로그램 마이그레이션

목차

준비, 설치, 테스트
테스트 설정
IT 관리자를 위한 중요 향상
IIS 아키텍처
통합 모드와 클래식 모드
모듈 및 기능
웹 응용 프로그램 마이그레이션
맺음말

Microsoft의 IIS 팀에 따르면 IIS(인터넷 정보 서비스) 7.0은 IIS 역사상 가장 큰 릴리스입니다.이 버전은 새로운 표준을 설정하고 근본적으로 개선된 성능을 제공하며

웹 환경 통합을 위한 새로운 기능을 도입했습니다.Windows Server?? 2008 및 Windows Vista?? SP1에 포함된 IIS 7.0은 이미 Microsoft.com을 구동하고 있으며, 다수의 웹 호스팅 기업이 기존 웹 응용 프로그램을 새 웹 서버 플랫폼에 이식하려는 웹 디자이너 및 개발자에게 IIS 7.0 호스팅 서비스를 제공하기 시작했습니다.

이번 기사에서 필자는 IT 전문가에게 가장 중요한 IIS 7.0의 주요 향상된 기능에 대해 살펴본 후 ASP.NET 및 PHP 웹 응용 프로그램을 마이그레이션하는 방법에 대해 자세히 설명하려고 합니다.그러나 기본 프로덕션 환경과 비슷한 테스트 환경에 대해 먼저 간략히 짚고 넘어가겠습니다.

이는 중요한 단계입니다.시간이 걸리더라도 IIS 7.0을 프로덕션 서버에 배포하기 전에 웹 응용 프로그램이 새 웹 서버에서 순조롭게 실행될 수 있도록 테스트 환경에서 철저한 테스트를 수행할 필요가 있습니다.

준비, 설치, 테스트

필자의 테스트 환경에는 Windows Server 2003 및 IIS 6.0(ASP.NET 응용 프로그램 호스팅)을 실행 중인 시스템과 Ubuntu 7.10 Linux 배포 및 Apache HTTP Server 2.2(PHP 기반 웹 응용 프로그램 호스팅)를 실행 중인 서버가 있습니다.테스트의 궁극적인 목표는 스테이징 및 프로덕션 시스템에 Windows Server 2008을 배포한 다음 IIS 6.0 및 Apache 인스턴스를 IIS 7.0으로 교체하기 위해 복잡한 웹 응용 프로그램으로 전환하는 것입니다.

두 가지 주요 웹 응용 프로그램으로DotNetNuke 4.7 및 osCommerce 3.0a4가 있습니다.DotNetNuke는 ASP.NET 2.0과 Microsoft?? SQL Server??에 기반한 웹 응용 프로그램 프레임워크이고,osCommerce는 PHP와 MySQL을 기반으로 하며 모든 기능을 갖춘 전자 상거래 솔루션의 최신 알파 버전입니다.이제 이 고급 응용 프로그램들을 IIS 7.0으로 옮겨 보겠습니다.

여기서 소프트웨어 버전이나 제품 또는 플랫폼을 비교하려는 의도는 없음을 분명히 말씀드리고 싶습니다.하지만 Windows Server 2008 및 IIS 7.0 표준에 맞출 경우 많은 이점이 있다는 점을 강조하고 싶습니다.이를테면, 관리의 복잡성이 줄어들고 실행 중인 전체 웹 서버 수를 최소화할 수 있습니다.

그림 1은 이 글에 사용된 테스트 환경을 간략하게 보여 줍니다.자신의 테스트 환경에서 필자의 설명 내용을 따라 하려면 TechNet Magazine 웹 사이트(technetmagazine.com)의 코드 다운로드 섹션에서 구할 수 있는 첨부 자료에서 필수 소프트웨어 구성 요소에 대한 링크 및 자세한 단계별 설치 지침을 볼 수 있습니다.

그림 1 IIS 7.0 신규 도입을 위한 테스트 환경(크게 보려면 이미지 클릭)

본 기사를 마무리할 무렵 Microsoft에서 IIS 6.0 및 7.0으로의 웹 응용 프로그램 배포, 동기화 및 마이그레이션을 지원하기 위한 명령줄 도구(MSDeploy.exe)를 출시했으며,필자는 이 도구를 권하는 바입니다.Microsoft 웹 배포 팀 블로그(go.microsoft.com/fwlink/?LinkId=118272)에서 자세한 내용을 볼 수 있습니다.

테스트 설정

본 기사를 집필하는 동안 Windows Server 2008이 시험판이어서 도메인 컨트롤러나 데이터베이스 서버에서 Windows Server 2003을 교체하지 못했습니다.공식 Windows Server 2008 버전이 출시되면서 Active Directory?? 인프라의 마이그레이션도 고려하고 계실 수 있겠지만,SQL Server?? 2005 및 MySQL 데이터베이스를 SQL Server 2008로 마이그레이션하는 방법은 이 글에서 논외로 합니다.

필자는 SQL Server 2005(서비스 팩 2 포함)보다 더 설치하기 쉽다는 이유에서 SQL Server 2008을 스테이징 서버에 배포했습니다.DotNetNuke는 SQL Server 2008 데이터베이스와 함께 실행하는 데 문제가 없었고Windows Server 2008에 MySQL 5.0을 설치하는 데에도 별다른 어려움이 없었습니다.

IIS 7.0은 Server Core에서 사용 가능하지만, 필자는 테스트의 특정 요구 사항 때문에 Server Core 설치를 사용하지 않았습니다.필자의 스테이징 서버에는 주 테스트 시스템으로서 전체 설치가 필요하기 때문입니다.게다가, Server Core에서는 Microsoft .NET Framework를 사용할 수 없습니다.

PHP는 Server Core에서 잘 실행되지만 ASP.NET 및 PHP 응용 프로그램의 통합이라는 이 테스트의 목적상 Server Core는 선택 범위에서 제외하기로 했습니다..NET Framework가 Server Core에서 지원되기 전까지는 ASP.NET 응용 프로그램을 지원하기 위해 전체 설치를 수행해야 합니다.테스트 환경 설치에 대한 자세한 단계별 지침은 첨부 자료의 01_install_testlab.htm 파일을 참조하십시오.

필자는 기존 서버에서 업그레이드하지 않고 Windows Server 2008을 완전히 새로 설치하기로 했습니다.무엇보다도, 새로 설치할 경우 그림 2의 시나리오와 같은 단계적 마이그레이션 시나리오를 구현하기가 더 쉽습니다.모든 관련 웹 응용 프로그램 구성 요소를 스테이징 서버에서 성공적으로 테스트한 후 새 IIS 7.0 웹 팜으로 이동할 때까지 기존 웹 팜 실행을 유지한다는 전략입니다.

그림 2 IIS 7.0으로의 단계적 전환(크게 보려면 이미지 클릭)

환경의 복잡도에 따라 기존 웹 응용 프로그램을 모두 한 번에 옮기거나 단계적으로 이동할 수 있습니다.각 웹 응용 프로그램 또는 사이트별로 새 웹 팜에 대한 최종 수용 테스트를 수행한 후에 브라우저를 새 IIS 7.0 웹 팜으로 지정하도록 해당 DNS 레코드를 변경함으로써 전환할 수 있습니다.이렇게 하면 가동 중지 시간 및 중단을 최소화할 수 있습니다.

IT 관리자를 위한 중요 향상

MSDN?? Magazine에서 Mike Volodarsky의 "Windows Vista 및 그 이상의 웹 서버를 위한 탐색(msdn2.microsoft.com/magazine/cc163453.aspx)"이라는 기사를 참조하면 IIS 7.0의 향상된 기능에 대해 빠르게 살펴볼 수 있습니다.

Microsoft.com 팀의 블로그 게시물인 "최상의 기능 소개(go.microsoft.com/fwlink/?LinkId=117436)"도 유익한 참고 자료가 될 수 있습니다.이 게시물은 팀 구성원들의 초기 IIS 7.0 환경에 대해 간략히 설명하고 있습니다.가장 주목할 만한 향상된 기능을 요약하여 다음 순위에 따라 나열하고 있습니다.

1. 간편한 설치
2. 뛰어난 호환성
3. 메타베이스가 필요 없음
4. UNC 공유에 있는 applicationHost.config 파일을 통한 중앙 집중식 구성
5. 응용 프로그램 디렉터리의 web.config 파일을 통해 위임된 구성
6. 향상된 관리 도구
7. 실패한 요청 추적
8. URLScan이 필요 없는 요청 필터링
9. UNC 공유를 통해 간소화된 콘텐츠 동기화 사용
10. 동적 콘텐츠의 출력 캐싱

간소화된 설치는 필자가 꼽는 목록에도 포함됩니다.Microsoft.com 팀은 블로그 게시물에서 단일 명령줄을 사용하여 IIS 7.0의 모든 기능(또는 원하는 기능만)을 배포하는 방법을 보여 주고 있습니다.그림 3에 표시된 명령줄을 사용하는 이러한 접근법을 필자의 테스트 환경 설치 지침에도 포함하였습니다.

이 명령은 다소 긴 편입니다.이 명령을 복사하려면 손으로 다시 입력하지 말고 TechNet Magazine 웹 사이트에서 복사하여 붙여넣는 것이 좋습니다.이 명령은 사용 가능한 모든 모듈을 IIS 7.0 컴퓨터에 설치하지만 PHP가 빠져 있습니다.IIS 7.0에는 PHP가 포함되어 있지 않으며, 인터넷을 통해 Debian 패키지를 다운로드하여 설치한다는 것은 Windows?? 패키지 관리자(pkgmgr.exe)에는 낯선 개념입니다.이제 Windows AIK(자동 설치 키트)가 등장합니다.

그림 3 단일 명령줄을 사용한 IIS 7.0 기능 배포

코드 복사

<PRE class=libCScode id=ctl00_ContentPlaceHolder1_ctl08 space="preserve">start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-­WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI# Command provided by the Microsoft.com team (blogs.technet.com/mscom).</PRE>

AIK를 사용하면 IIS 7.0과 PHP 5가 포함된 Windows Server 2008용 사용자 지정 설치 DVD를 만들 수 있습니다.배포에 필요한 MySQL, 웹 응용 프로그램 파일 및 기타 구성 요소들도 여기에 포함할 수 있습니다.모든 구성 요소를 Windows Server 2008 설치의 일부로 포함하는 방법을 통해 사용자 지정 내용을 모든 웹 서버에 일관되게 적용할 수 있습니다.명령줄이나 구성 파일을 편집할 필요가 없습니다.

심지어 완전 무인 설치가 가능한 사용자 지정 DVD를 만들 수도 있습니다.AIK에는 AutoUnattend.xml 파일을 만들어 DVD의 루트 폴더에 저장할 수 있는 설명서와 도구가 포함되어 있습니다.첨부 자료의 Custom Image Deployment.htm 파일에서 단계별 지침을 제공합니다.

호환성도 많은 관리자들이 핵심 개선 사항으로 손꼽았습니다.테스트로 돌아가서, 필자는 DotNetNuke와 osCommerce에서 몇 가지 호환성 문제가 발생할 것으로 예상했지만 이 두 가지 웹 응용 프로그램 모두 폼 인증 및 검색 엔진에 친화적인 URL 등과 같은 고급 기능을 포함하고 있음에도 불구하고 IIS 7.0으로의 전환은 생각보다 순조로웠습니다.

DotNetNuke의 경우 64비트 플랫폼의 UNC 콘텐츠 공유를 사용하는 복잡한 웹 팜 시나리오로 이전하기 전까지 전혀 문제가 없었습니다.발생한 문제도 아주 미미한 수준이었습니다.이러한 호환성 개선은 결국 IIS 7.0에서 웹 응용 프로그램을 실행하기까지 시간이 더 적게 소요됨을 의미합니다.

웹 응용 프로그램에서 호환성 문제가 발생할 경우 기본 제공되는 진단 및 추적 지원 기능을 사용하면 큰 도움이 됩니다.의미있는 상세한 진단 정보가 제공되며, 제안된 솔루션 경로는 실제로 효과가 있으며 유용합니다.

그림 4는 IIS 7.0의 통합 모드에서 DotNetNuke 4.7을 실행하여 얻은 진단 정보입니다.이 예에서는 세 가지 선택 사항이 있습니다("가능한 해결 방법" 섹션에 표시됨).응용 프로그램에서 통합 모드를 지원하도록 변경하는 것이 DotNetNuke 개발자에게 최선의 선택이 될 것입니다.오류를 무시하는 것은 좋은 방법이 아닙니다.필자의 경우 IIS 7.0에서 수정하지 않은 DotNetNuke 4.7을 실행할 생각이므로 웹 응용 프로그램을 클래식 .NET AppPool로 전환하여 클래식 모드를 활성화하는 세 번째 방법을 선택했습니다.

그림 4 통합 모드에서 실행 중인 DotNetNuke 의 진단 정보(크게 보려면 이미지 클릭)

IIS 아키텍처

이쯤에서 이러한 통합 모드와 클래식 모드에 각각 어떤 기능이 있으며 PHP 응용 프로그램(osCommerce)에는 영향을 주지 않고 ASP.NET 응용 프로그램(DotNetNuke)에만 영향을 주는 이유가 궁금해질 것입니다.이해를 돕기 위해 먼저 IIS 7.0의 아키텍처를 살펴보겠습니다.이전 버전에서는 ASP.NET 런타임을 주로 ISAPI 확장(aspnet_isapi.dll)을 통해 핵심 웹 서버로 통합합니다.반면 IIS 7.0에서는 ASP.NET 지원 DLL(webengine.dll)을 IIS 7.0 요청 처리 파이프라인에 로드하는 ManagedEngine이라는 전역 수준 HTTP 모듈을 통해 ASP.NET 모듈이 핵심 웹 서버에 직접 연결됩니다.

네이티브 모듈은 IIS 웹 서버 핵심 API를 사용하여 BeginRequest, AuthenticateRequest, AuthorizeRequest 및 ExecuteRequestHandler와 같은 특정 이벤트를 파이프라인에 등록합니다.ManagedEngine도 ASP.NET 모듈을 요청 파이프라인으로 통합하기 위해 필요한 지원을 제공합니다.IIS 7.0은 이런 새 아키텍처를 기반으로, 요청된 콘텐츠 형식에 관계없이 요청 처리 과정의 임의의 단계에서 네이티브 및 ASP.NET 모듈을 호출할 수 있습니다.

예를 들어 ASP.NET 사용자 인증을 생각해 보겠습니다.IIS 6.0에서는 ASP.NET 기반 HTTP 모듈을 FormsAuthentication.OnAuthenticate, WindowsAuthentication.OnAuthenticate 등과 같은 OnAuthenticate 이벤트에 등록하여 현재 HttpContext에서 사용자의 ID를 설정하는 것이 가능합니다.이것은 ASP.NET 런타임 내부에서는 훌륭하게 작동하지만 이 ASP.NET 코드로는 PHP 기반 웹 응용 프로그램을 통해 노출된 리소스를 보호할 수 없습니다.

IIS 6.0은 그 스크립트맵 구성에 따라 ASP.NET 콘텐츠 형식에 대한 요청을 aspnet_isapi.dll로 전달하지만 PHP 콘텐츠 형식에 대한 요청은 ASP.NET을 위한 ISAPI 확장으로 전달하지 않습니다.결국, ASP.NET이 PHP 코드를 처리하지 않으며, 이것은 PHP 페이지가 요청될 경우 ASP.NET 인증 코드가 실행되지 않음을 의미합니다.따라서 IIS 6.0에서는 PHP 응용 프로그램을 위한 고유한 인증 메커니즘을 구현해야 하므로 인증 로직을 복제해야 합니다.

IIS 7.0은 요청 파이프라인의 개별 모듈에 대한 혼합 및 일치를 지원하는 이벤트 중심의 처리 모델을 사용합니다.다른 구성 요소 중에서 IIS 7.0은 요청 파이프라인에서 AuthenticateRequest 이벤트가 발생했을 때 OnAuthenticate 이벤트를 트리거하는 관리 WindowsAuthentication 및 FormsAuthentication 모듈을 함께 제공합니다.이제 RequestFilteringModule이나 IpRestrictionModule과 같은 네이티브 모듈이 제공되고, 조기에 중요한 요청을 거부하도록 BeginRequest 이벤트를 처리할 수 있으며, AuthenticateRequest 이벤트에서 사용자 지정 ASP.NET 인증 코드를 실행할 수 있고, ExecuteRequestHandler 이벤트에서 FastCgiModule이 PHP 스크립팅 엔진(php-cgi.exe)을 실행하여 PHP 페이지를 처리하도록 할 수 있습니다.

이러한 통합 아키텍처로 인해 웹 개발자가 공통 비즈니스 논리를 구현하기 위해 코드를 복제할 필요가 없게 되었습니다.사용자 지정 ASP.NET 인증 코드를 사용하면 PHP 응용 프로그램을 비롯한 모든 IIS 리소스를 보호할 수 있습니다.ASP.NET 모듈을 통해 URL 다시 쓰기, 사용자 지정 추적, 오류 로깅 등의 기타 전처리 및 후처리 작업을 수행할 수 있습니다.

통합 모드와 클래식 모드

새로 도입한 이 아키텍처의 부작용은 기존 ASP.NET 응용 프로그램이 요청 파이프라인에서 변경 내용으로 인한 모듈 충돌을 방지하기 위해 응용 프로그램 개발자에게 코드 및 구성 변경을 요구할 수 있다는 것입니다.이렇게 기존 웹 응용 프로그램을 즉시 이식할 수 없는 경우 작업자 프로세스에서 웹 응용 프로그램을 실행할 때 사용되는 응용 프로그램 풀에서 클래식 모드를 활성화할 수 있습니다.IIS 7.0은 ManagedEngine을 클래식 모드의 작업자 프로세스로 로드하지 않으며, 이 경우 요청 파이프라인에서 ASP.NET 모듈을 확인하거나 호출할 수 없음을 의미합니다.그 대신 IIS 7.0은 IsapiModule(aspnet_isapi.dll)에 기반한 다양한 ISAPI 처리기를 활성화하여 IIS 6.0과 유사한 ASP.NET 콘텐츠 형식을 처리합니다.applicationHost.config 파일(기본적으로 %WinDir%\System32\InetSrv\Config 폴더에서 찾을 수 있음)의 system.webServer 아래에 있는 처리기 섹션을 분석해 보면 이를 알 수 있습니다.

예를 들어 문자열 aspx를 검색하면 PageHandlerFactory-Integrated(preCondition="integratedMode" 설정에 의해 통합 모드 응용 프로그램 풀 작업자 프로세스에 로드됨)를 나타내는 한 가지 항목과 PageHandlerFactory-ISAPI-2.0 및 PageHandlerFactory-ISAPI-2.0-64(preCondition="classicMode" 설정에 의해 클래식 모드 응용 프로그램 풀 작업자 프로세스에 로드됨)를 나타내는 다른 항목들을 볼 수 있습니다.

파이프라인 모드가 응용 프로그램 풀 수준에서 설정되기 때문에 IIS 7.0은 웹 응용 프로그램을 통합 모드와 클래식 모드에서 동시에 실행할 수 있습니다.그리고 작업자 프로세스는 서로 다른 응용 프로그램 풀에서 실행하기만 하면 되고 동일한 서버에서 호스팅할 수 있습니다.

하지만 통합 모드와 클래식 모드는 IIS 7.0이 ASP.NET을 요청 파이프라인에 통합하는 방법에만 영향을 준다는 점에 유의해야 합니다.이러한 파이프라인 모드는 PHP 응용 프로그램에 직접 영향을 주지는 않습니다.FastCgiModule 및 기타 모든 네이티브 모듈은 통합 모드와 클래식 모드 모두에서 파이프라인 모드에 대한 전제 조건 없이 로드합니다.FastCGI는 IIS 7.0에서 PHP 스크립팅 엔진을 실행하는 기본 인터페이스이며,FastCGI 대신 CGI를 통해 PHP 스크립팅 엔진의 처리기 매핑을 만들거나 IsapiModule을 PHP-ISAPI(php4isapi.dll)와 함께 사용할 수 있습니다.

하지만 FastCGI가 상당히 향상된 성능 및 안정성을 제공하므로 이러한 IIS 6.0식 구성 옵션은 이제 오래된 방식에 속합니다.FastCGI가 여러 요청에 대한 CGI 프로세스를 다시 사용하는 반면 CGI는 IIS에서 HTTP 요청마다 새 CGI를 초기화해야 하므로 속도가 더 느립니다.ISAPI에는 스레드로부터 안전한 PHP 구축이 필요하며, 이 경우에는 스레드로부터 안전하지 않은 PHP를 실행하는 경우보다 오버헤드가 큽니다.

더욱 중요한 점은 일부 PHP 확장을 스레드로부터 안전한 버전으로 사용할 수 없다는 것입니다. ISAPI와 함께 스레드로부터 안전하지 않은 확장을 실행하는 것은 서버의 안정성 문제를 유발할 수 있으므로 좋지 않습니다.반면 FastCGI는 CGI와 같은 단일 동시성 환경입니다.스레드로부터 안전하지 않은 PHP를 실행하는 데 사용되는 FastCGI는 안정적이면서 빠른 특성을 가지며 IIS 7.0에서 PHP 5를 함께 사용하는 확실한 방법이라고 할 수 있습니다.IIS 7.0으로 전환할 준비가 되지 않은 경우에는 IIS 6.0에서도 FastCGI를 사용할 수 있습니다.

모듈 및 기능

IIS 7.0은 섬세하게 모듈화된 아키텍처가 특징입니다. IIS 개발자의 표현에 따르면 구성 요소별로 구분된 기능 집합이라고도 할 수 있습니다.IIS 7.0의 메모리 공간을 최대로 유지하면서 공격 대상 영역을 최소화하려는 웹 관리자들에게는 반가운 소식일 것입니다.여러 모듈을 활성화하거나 표준 모듈을 사용자 지정 모듈로 교체하는 등, 사용 중인 웹 서버에서 IIS 7.0 기능을 완전하게 제어할 수 있습니다.

동일한 서버에서 통합 모드 또는 클래식 모드로 PHP 응용 프로그램뿐만 아니라 ASP.NET도 실행하려면 요청 처리, 서버 구성, ASP.NET, ISAPI 및 CGI(FastCGI 모듈 포함)를 지원하기 위해 웹 서버 역할 및 핵심 모듈을 최소 수준으로 설치해야 합니다.다음 명령줄을 통해 이를 실행할 수 있습니다.

코드 복사

<PRE class=libCScode id=ctl00_ContentPlaceHolder1_ctl10 space="preserve">start /w pkgmgr /iu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-ProcessModel;WAS-ConfigurationAPI;IIS-ASPNET;IIS-NetFxExtensibility;WAS-NetFxEnvironment;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI</PRE>

필자는 일반적으로 스테이징 서버에 IIS 7.0을 설치할 때 웹 응용 프로그램을 신속하게 실행하는 데 모든 구성 요소와 관리 도구를 사용할 수 있도록 가능한 모든 옵션을 사용합니다.필자의 전략은 작동하게 만드는 것이므로, 역할 서비스를 제거하고 모듈을 비활성화하여 구성 범위를 좁히고웹 응용 프로그램이 활성화되면 제거했던 역할 서비스 또는 모듈을 다시 추가했습니다.

패키지 관리자(pkgmgr.exe) 또는 IIS 7.0 명령줄 도구(appcmd.exe)를 사용하거나 applicationHost.config 파일에서 직접 globalModules 섹션을 편집하는 방법 중 선택할 수 있지만, 필자의 경험으로는 그래픽 도구가 매우 편리합니다.RequestFilteringModule 및 StaticCompressionModule과 같은 일부 모듈은 엄격히 말해서 응용 프로그램을 실행하는 데 반드시 필요한 모듈은 아니지만 매우 유용합니다.응용 프로그램 풀에 필요한 모듈을 제거하면 웹 응용 프로그램에 액세스할 때 그림 5와 같은 HTTP 오류를 수신하게 됩니다.

그림 5 IsapiModule이 없어서 ASP.NET 응용 프로그램이 클래식 모드로 실행되지 않음(크게 보려면 이미지 클릭)

참고:가장 좋은 방법은 모든 IIS 7.0 서버에 동일한 모듈 집합을 설치하여 활성화하는 것입니다.설치된 구성 요소를 확인하려면 HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\로 이동하여 레지스트리 키를 확인합니다.NetFxEnvironment나 CGI 같은 레지스트리 값에서 REG_DWORD 값이 0000 0001이면 해당 구성 요소가 설치되어 있음을 나타냅니다.

웹 응용 프로그램 마이그레이션

이론은 이것으로 마치고, 이제 실제로 웹 응용 프로그램을 IIS 7.0으로 이동해 보겠습니다.앞서 언급했듯이 필자의 스테이징 서버에는 사용 가능한 모든 구성 요소가 포함된 IIS 7.0과 스레드로부터 안전하지 않은 PHP 5(FastCGI로 등록됨)가 실행 중입니다.시작하기 전에 몇 가지 기본적인 질문을 던져 보겠습니다.

• 웹 응용 프로그램에 SQL Server나 MySQL과 같은 데이터베이스 관리 시스템이 필요합니까?
• ODBC 연결, COM 개체, SSL 인증서와 같은 추가 구성 요소를 설치하거나 구성해야 합니까?
• 웹 응용 프로그램에 특수 서비스 계정과 파일 공유 및 기타 리소스에 대한 관리자 권한의 로컬 또는 원격 액세스 권한이 필요합니까?
• Apache 모듈의 URL 다시 쓰기(mod_rewrite)에 대한 종속성과 같이 IIS 7.0에서 사용할 없는 플랫폼 특정 기능에 대한 종속성이 있습니까?

이와 같은 질문들은 IIS 7.0에서 웹 응용 프로그램을 더 빨리 가동하는 데 도움이 될 것입니다.예를 들어 Apache 2.2에서 mod_rewrite를 사용하는 PHP 응용 프로그램을 마이그레이션하려는 경우(예: 검색 엔진 친화성을 위해 또는 인라인 연결 이미지를 통한 대역폭 가로채기를 방지하기 위해), IIS 7.0에서 호환되는 사용자 지정 URL 다시 쓰기 솔루션을 구현하기 전에는 문제가 발생하게 됩니다.다행히 osCommerce의 경우 IIS 7.0에서 mod_rewrite 기능이 요구되지 않지만, 일부 검색 엔진 최적화 패키지에서는 필요할 수 있습니다.

스테이징 서버에 필요한 추가 구성 요소를 결정하여 설치했으므로 이제 웹 응용 프로그램을 실행할 준비가 되었습니다.여기서 또 다시 다음과 같이 자문해 보겠습니다.

• 웹 응용 프로그램을 지원하기 위해 사용할 수 있는 가장 단순한 구성은 무엇입니까?
• 프로덕션 환경에서는 현재 어떤 구성을 사용 중입니까?
• 새 플랫폼에서 웹 응용 프로그램 구성을 최적화할 수 있습니까?
• 웹 응용 프로그램이 원하는 구성으로 작동하기 위해 필요한 최소한의 역할 서비스와 모듈은 무엇입니까?

가장 단순한 구성으로 웹 응용 프로그램을 실행하는 것이 가장 빠르게 가동하는 방법입니다.다른 문제가 없어 보이면 이제 기존 프로덕션 환경과 유사한 구성을 적용하고 프로덕션 데이터를 테스트 테이터베이스로 가져옵니다.물론, 일부 문제가 발생할 수 있지만 고급 구성에서만 해당합니다.

테스트 환경의 프로덕션 구성을 미러링할 때 이미 느끼셨는지 모르겠지만applicationHost.config 파일을 UNC 공유에 배치하면 여러 웹 서버의 구성을 한 곳으로 집중시킬 수 있는 훌륭한 방법이 될 수 있습니다.중복과 콘텐츠 동기화를 통해 내결함성을 향상시키려면 Windows Server 2003 R2 및 Windows Server 2008에서 사용할 수 있는 상태 기반 다중 마스터 복제 엔진인 DFS(분산 파일 시스템) 복제를 구현하십시오.또한, UNC 공유에 웹 응용 프로그램 콘텐츠 파일을 배치하여 웹 프런트 엔드의 저장소 요구 사항을 최소화할 수도 있습니다.

다른 잠재적 최적화에 보안 또는 동적 캐싱이 수반될 수 있습니다.필자는 이 테스트 환경에서 보안 및 성능 최적화에 대한 내용은 논외로 하고 설명하지 않았으며서버 추가 설치를 피하기 위해 DFS를 구성하지도 않았습니다.첨부 자료의 단계별 지침에서는 applicationHost.config 파일과 웹 콘텐츠를 UNC 공유에서 호스팅하는 방법을 예를 들어 보여 줍니다.또한 그림 6은 DFS를 사용하여 UNC 기반 웹 팜을 구현하는 방법을 보여 줍니다.

그림 6 applicationHost.config 파일 및 웹 콘텐츠가 UNC 공유에 배치된 상태에서 웹 팜 배포(크게 보려면 이미지 클릭)

맺음말

IIS 7.0은 놀라운 웹 서버 플랫폼입니다.새롭게 설계된 핵심 아키텍처를 갖추면서 동시에 이전 버전인 IIS 6.0과 거의 완벽에 가까운 호환성을 유지하는 것이 그 특징입니다.대부분의 기존 ASP.NET 웹 응용 프로그램을 따로 수정하지 않고 실행할 수 있지만아키텍처 변경 정도에 따라 호환성 문제가 발생할 수도 있습니다.

IIS 7.0으로 마이그레이션할 대상이 ASP.NET 웹 응용 프로그램이든 아니면 PHP 웹 응용 프로그램이든 어느 경우에도 적절한 계획과 준비, 테스트, 코드 및 구성 변경 문서화 등에 초점을 두어 단계적으로 접근하는 것이 가장 좋습니다.

IIS 7.0은 이러한 노력을 들일 만한 가치를 제공합니다.보안, 성능, 구성 용이성, 유연성 면에서 다수의 향상된 기능을 볼 수 있습니다.이러한 기능에 대해 모두 논하려면 족히 책 한 권은 될 것입니다.UNC 공유에 기반한 중앙 집중식 구성 및 콘텐츠 공유, 응용 프로그램 디렉터리의 web.config 파일을 통한 구성 위임, 향상된 관리 도구, 상세한 진단 정보 및 실패한 요청 추적, 동적 출력 캐싱 등이 웹 관리자가 반길 만한 기능입니다.

요청 처리 파이프라인에서 네이티브 모듈과 관리되는 모듈을 혼합할 수 있는 기능은 ASP.NET 개발자에게 유용하며,IIS 7.0의 FastCGI와 함께 제공되는 성능 및 안정성 향상은 PHP 응용 프로그램 개발자에게 희소식이 될 것입니다.

IT 전문가가 IIS 7.0을 성공적으로 사용하는 데 도움이 되는 중요한 부분이 한 가지 더 있습니다.바로 Microsoft IIS 커뮤니티 포털(www.iis.net)입니다.아키텍처에 대한 상세한 설명이 수록된 기사들과 C++용 소스 코드 및 IIS 7.0 모듈을 만드는 방법에 대한 ASP.NET 개발자의 설명 그리고 PHP 응용 프로그램을 실행하기 위한 단계별 지침 등 모든 필요한 정보를 여기서 찾아볼 수 있습니다.이 사이트가 필요한 상황이 있을 것입니다.이 사이트는 IIS 관련 질문에 대한 해답을 찾기 위해 맨 먼저 활용할 수 있는 훌륭한 자료입니다.

Fergus Strachan은 전문 IT 인프라 설계 및 프로젝트 관리 지원 컨설팅 전문 기업으로서 영국의 국제적인 은행 및 교육 기관에 서비스를 제공하고 있는 Maestra Ltd London의 설립자 겸 이사입니다.Fergus는 Microsoft의 서버 기술에 대한 기사를 연재하고 있으며 Integrating ISA Server 2006 with Microsoft Exchange 2007의 저자이자Microsoft Exchange Server 2003 Resource Kit의 공동 저자이기도 합니다.