IIS 8.0 응용 프로그램 초기화 (Application Initialization)
- 본 번역문서의 원문은 IIS 8.0 Application Initialization www.iis.net 입니다.
- 본 번역문서는 IIS 8.0 미리보기 - IIS 8.0 응용 프로그램 초기화 www.taeyo.net 에서도 함께 제공됩니다.
호환성
버전 | 비고 |
---|---|
IIS 8.0 | 응용 프로그램 초기화는 IIS 8.0에서 도입되었습니다. |
IIS 7.5 | 응용 프로그램 초기화(RC)는 IIS 7.5에서 별도 모듈로 도입되었습니다. |
IIS 7.0 | IIS 7.0에서는 응용 프로그램 초기화가 지원되지 않습니다. |
내용
문제점
일반적으로 웹사이트 관리자들이 당면하게 되는 보편적인 문제점들 중 하나는 웹 응용 프로그램에 대한 초기화 작업 및 준비(Warm Up) 작업을 수행해야 하는 경우가 있다는 점입니다. 대부분 크고 복잡한 웹 응용 프로그램일수록 첫 번째 HTTP 요청을 처리하기까지 긴 시동 과정과 인-메모리 캐시 준비, 내용 생성 등의 작업들을 필요로 합니다.
해결방법
IIS 8.0의 응용 프로그램 초기화(Application Initialization) 기능을 이용하면, 웹사이트 관리자가 하나 이상의 웹 응용 프로그램들에 대한 초기화 작업을 미리 수행하도록 IIS 8.0을 구성할 수 있습니다. 그리고, 응용 프로그램 초기화 작업이 완료되기 전까지 대체 페이지나 시작 페이지(Splash Page) 역할을 하는 특정 정적 컨텐트를 반환하도록 IIS 8.0을 구성할 수도 있습니다.
전역 규칙과 응용 프로그램별 규칙을 조합하여 IIS 8.0이 웹 응용 프로그램을 언제, 어떻게 초기화할지 구성할 수도 있습니다. 또한, 응용 프로그램 초기화 기능과 IIS Url 재작성 모듈을 통합할 수 있기 때문에, 응용 프로그램 초기화가 진행 중일때 보다 복잡한 대체 페이지 콘텐트의 처리도 지원할 수 있습니다.
단계별 지침
전제조건:
응용 프로그램 초기화 기능을 사용하려면 IIS 8.0이 설치되어 있어야하고, IIS의 응용 프로그램 개발 기능(Application Development) 하위의 응용 프로그램 초기화 기능(Application Initialization)이 설치되어 있어야만 합니다.
다음 스크린샷은 응용 프로그램 초기화 기능이 나타나 있는 윈도우 8의 서버 관리자 UI 화면입니다.
노트: 본문에서는 응용 프로그램 초기화 기능을 살펴보기 위해서 ASP.NET 4.5 응용 프로그램을 이용합니다. 본문 마지막 부분의 부록에서 예제 응용 프로그램 자체와 해당 응용 프로그램의 설치 방법이 제공됩니다.
알려진 버그에 대한 해결방법:
- 현재 이 기능에 대한 알려진 버그는 존재하지 않습니다.
전역 응용 프로그램 초기화
응용 프로그램 초기화 기능은 머신 수준의 applicationHost.config 파일과 응용 프로그램 수준의 web.config 파일, 이렇게 두 곳에서 구성할 수 있습니다. 이 중, applicationHost.config 파일에는 "전역" 응용 프로그램 초기화 설정이 저장되고, 응용 프로그램 수준의 web.config 파일에는 "지역" 응용 프로그램 초기화 설정이 저장됩니다.
이번 미리보기에서는 응용 프로그램과 연결된 응용 프로그램 풀이 시작될 때마다 항상 초기화가 수행되도록 예제 응용 프로그램을 구성해보겠습니다. 응용 프로그램 풀과 관련된 동작은 applicationHost.config에서만 구성할 수 있기 때문에, 응용 프로그램 풀이 시작될 때마다 응용 프로그램 초기화를 수행하려면 "전역" 응용 프로그램 초기화 설정의 일부로 구성되야 합니다.
applicationHost.config 수정하기
메모장으로 %WINDIR%\system32\inetsrv\config에 위치한 applicationHost.config 파일을 엽니다. (메모장을 실행할 때 "관리자 권한으로 실행" 옵션을 지정해야 합니다.) 그리고, <applicationPools> 구성 섹션으로 이동한 다음 ".NET v4.5"라는 이름의 응용 프로그램 풀 항목을 찾습니다.
이 응용 프로그램 풀이 항상 실행되도록 응용 프로그램 풀 항목을 수정해보겠습니다. 보통 전역 응용 프로그램 초기화가 수행될 응용 프로그램의 응용 프로그램 풀은 자동으로 시작되고 실행되는 것이 일반적입니다. 다음 구성 조각에서 굵게 표시된 부분이 구성 항목에 추가되야 할 부분입니다.
<add name=".NET v4.5" startMode="AlwaysRunning" managedRuntimeVersion="v4.0" />
조금 더 아래 부분으로 스크롤해서 applicationHost.config의 <sites> 구성 요소로 이동합니다. 해당 섹션을 살펴보면 예제 응용 프로그램에 대한 <application> 항목이 존재하는 것을 확인할 수 있습니다. (예제 응용 프로그램의 설치 방법은 부록을 참고하시기 바랍니다.) 이 응용 프로그램의 이름은 "appinit"이고 path 어트리뷰트의 값이 "/appinit" 입니다. 다음과 같이 <application> 항목에 preloadEnabled 어트리뷰트를 추가한 다음 변경 사항을 저장합니다.
<application path="/appinit" preloadEnabled="true" applicationPool=".NET v4.5">
이와 같이 preloadEnabled 어트리뷰트를 "true"로 설정하면 응용 프로그램과 연결된 응용 프로그램 풀이 시작될 때 IIS 8.0이 "가상"의 요청을 이 응용 프로그램으로 전송합니다. 바로 이를 위해서 조금 전에 응용 프로그램 풀의 startMode 어트리뷰트를 "AlwaysRunning"으로 설정한 것입니다.
지금 살펴본 것처럼, 응용 프로그램 풀이 항상 실행되도록 설정하고 응용 프로그램 자체에 대한 가상 요청 수신을 허용하면, 머신이 재시작되거나 WWW 서비스가 재생될 때마다 IIS 8.0이 해당 응용 프로그램의 구동이 시작될 수 있도록 응용 프로그램 풀의 인스턴스를 실행하고 "/appinit" 응용 프로그램에게 매번 가상 요청을 전송합니다.
응용 프로그램의 web.config 수정하기
두 번째 메모장으로 다음 경로에 위치한 응용 프로그램 수준의 web.config 파일을 엽니다. (메모장을 실행할 때 "관리자 권한으로 실행" 옵션을 지정해야 합니다.)
C:\inetpub\wwwroot\appinit
노트: 만약, Default Web Site를 다른 물리적 드라이드에 설치했다면 위 경로에서 드라이브명을 바꿔줘야 합니다.
이 web.config 파일을 살펴보면 미리 구성되어 있지만 주석 처리가 되어 있는 몇 가지 구성 섹션들이 존재합니다. 그 중에서 <system.webServer> 구성 섹션 내부에 위치한 다음과 같은 구성 조각의 주석 처리를 제거합니다. 이 조각은 web.config 파일의 "Exercise 1 - Step 1" 주석의 바로 아래 부분에 위치해 있습니다. 그리고, 변경 사항을 저장합니다.
<applicationInitialization remapManagedRequestsTo="Startup.htm" skipManagedModules="true"> <add initializationPage="/default.aspx" /> </applicationInitialization>
여기에서 applicationInitialization 요소는 응용 프로그램을 초기화하려면 응용 프로그램의 루트 Url로 (이 예제의 경우 "/") 요청을 전송해야 한다는 것을 IIS에게 알려줍니다. 그리고, IIS는 "/"에 대한 요청을 대기하는 동안 모든 활성 브라우저 클라이언트에게 "Startup.htm"를 반환해줍니다. 이 "Startup.htm"은 해당 응용 프로그램에 대한 시작 페이지입니다. *
* 본문에서는 "/"와 "/default.aspx"를 동일한 경로로 간주하고 설명하고 있습니다. 물론, 그 이유는 굳이 설명드리지 않아도 되겠죠? :-)
응용 프로그램 실행하기
먼저, 권한이 상승된 명령줄 창에서 다음과 같은 명령을 입력하여 월드 와이드 웹 서비스를 재생합니다:
net stop w3svc & net start w3svc
명령 프롬프트 창을 실행할 때 "관리자 권한으로 실행" 옵션을 지정해야 한다는 점을 기억하시기 바랍니다. 그리고, 인터넷 익스플로러를 이용해서 다음의 Url로 이동합니다:
http://localhost/appinit/default.aspx
그러면, 처음 몇 초간은 브라우저에 회색 바탕의 정적 "Startup.htm" 페이지가 나타나는데, 바로 이 페이지가 web.config에 구성된 시작 페이지이기 때문입니다. 약 8초 가량이 지난 뒤에 웹 브라우저에서 페이지를 새로 고침해보면 흰색 바탕의 "실제" default.aspx 콘텐트를 수신하는 것을 확인할 수 있습니다. (본문의 예제 응용 프로그램에서는 global.asax에서 스레드를 잠시 중단하는 것으로 가상의 초기화 작업을 가정하고 있습니다.) 즉, 응용 프로그램 초기화가 완료된 것입니다.
프로세스 중첩 재생 구성하기 *
IIS 8.0은 중첩 프로세스에서 응용 프로그램 초기화를 수행할 수 있도록 전역 응용 프로그램 초기화와 프로세스 중첩 재생 기능이 내부적으로 통합되어 있습니다. IIS는 현재 작업자 프로세스가 재생 중인 것을 감지한 경우, 새로운 작업자 프로세스 내에서 모든 응용 프로그램 초기화 Url 실행이 완료될 때까지, 활성 트래픽을 재생된 새로운 작업자 프로세스로 전달하지 않습니다. 따라서, 웹사이트에 접근하는 고객들은 가장 최초에 응용 프로그램이 활성화되어 실행된 이후부터는 응용 프로그램 초기화 페이지를 보지 못합니다.
다시, applicationHost.config 파일을 열어 놓았던 메모장으로 돌아갑니다. 그리고, ".NET v4.5" 응용 프로그램 풀 항목을 다음 구성 조각과 같이 수정합니다:
<add name=".NET v4.5" startMode="AlwaysRunning" managedRuntimeVersion="v4.0"> <recycling logEventOnRecycle="Schedule"> <periodicRestart requests="30" /> </recycling> </add>
변경 사항을 저장하는 것을 잊지마시기 바랍니다. 이 <recycling> 요소는 IIS에게 매번 30번의 HTTP 요청마다 작업자 프로세스를 재생하도록 지시합니다.
* IIS의 프로세스 재생에 관해서는 본문을 읽고 계신 여러분들도 대부분 잘 알고 계실 것입니다. 이는 IIS 6.0부터 제공된 새로운 응용 프로그램 격리 방식의 일부로, 간단히 말해서 응용 프로그램 풀이 지정한 조건에 도달하거나 응답을 하지 않으면 새로운 응용 프로그램 풀을 시작해서 기존 응용 프로그램 풀을 대체하는 기능이죠. 간단하게 이렇게만 알고 있어도 IIS를 사용하시는 데에는 큰 무리가 없습니다.
그러나, 본문을 보다 깊이 이해하려면 프로세스 중첩 재생(Overlapped Process Recycling)이라는 개념을 이해하셔야만 합니다. (참고로 '프로세스 중첩 재생'이라는 한글 용어는 설명의 편의를 위해서 제가 만들어낸 번역 용어입니다. 마이크로소프트의 공식 용어는 아닙니다.) 특정 응용 프로그램이 실행되는 프로세스가 재생될 때, 즉 응용 프로그램이 재생될 때, 그냥 프로세스가 하나 덜컥 생기고 바로 기존 프로세스를 대체하는 것이 아니거든요. :-)
먼저, 새로운 프로세스가 하나 만들어지게 되는데 그렇다고 해서 바로 기존 프로세스가 종료되거나 사용자들의 요청이 새 프로세스로 전달되지는 않습니다. 당연히 기존 프로세스에서 실행 중이던 모든 작업들이 먼저 완료되어야만 하겠죠. 그리고, 새로운 프로세스의 초기화 작업도 완료되어야 합니다. 이렇게 모든 준비가 마무리된 뒤에야 비로소 기존 프로세스가 종료되고 사용자들의 요청이 새로운 프로세스로 전달되는 것입니다. 따라서, 자연스럽게 프로세스 두 개가 동시에 존재하는, 즉 중첩되는 순간이 존재하게 되는데, 이런 방식의 재생을 프로세스 중첩 재생이라고 얘기합니다. 이쯤되면 눈치 빠르신 분들은 왜 본문에서 갑자기 프로세스 중첩 재생에 대한 얘기를 꺼내는지 아셨을 겁니다.
프로세스 중첩 재생에 대한 보다 자세한 설명은 IIS Process Recycling 문서를 참고하시기 바랍니다.
다시 응용 프로그램 실행하기
다시 권한이 상승된 명령줄 창에서 다음과 같은 명령을 입력하여 월드 와이드 웹 서비스를 재생합니다:
net stop w3svc & net start w3svc
그리고, 인터넷 익스플로러의 새로운 인스턴스를 시작한 다음, 다시 한 번 다음의 Url로 이동합니다:
http://localhost/appinit/default.aspx
그러면, 회색 바탕의 "Startup.htm" 시작 페이지가 나타나는 것을 확인할 수 있습니다.
이번에는, 작업 관리자를 시작한 다음 프로세스 탭으로 이동합니다. 프로세스 목록을 이름으로 정렬한 다음, 실행 중인 w3wp.exe의 인스턴스를 찾습니다. 바로 이 인스턴스가 현재 "appinit" ASP.NET 응용 프로그램이 실행 중인 작업자 프로세스입니다.
실제 default.aspx 페이지의 콘텐트가 반환될 때까지 브라우저를 몇 번 새로 고침합니다. 이미 알고 있는 것처럼 바탕색이 흰색으로 바뀌면 응용 프로그램이 "실제" default.aspx 페이지를 반환한 것입니다. 그러면, 작업 관리자와 브라우저를 동시에 볼 수 있도록 윈도우의 화면을 조정합니다.
다시 브라우저로 돌아가서 페이지를 30번 이상 새로 고침하면 IIS가 응용 프로그램 풀을 재생시킵니다. 그리고, 다음과 같이 작업 관리자의 프로세스 목록에 두 번째 w3wp.exe 인스턴스가 나타나면 페이지의 새로 고침을 중지합니다:
이 스크린샷에 나타난 w3wp.exe의 두 번째 인스턴스는 앞에서 설정한 프로세스 재생 조건에 도달했기 때문에 시작된 것입니다.
이 상태에 도달한 뒤로도 10초 정도간 브라우저 창을 주기적으로 새로 고침해 봅니다. 이때 실제 default.aspx가 계속 실행된다는 점에 주목하시기 바랍니다. 잠시 후 중복 재생이 완료되면 하나의 w3wp.exe 인스턴스가 작업 관리자 프로세스 창에서 사라지게 됩니다.
이처럼, 비록 응용 프로그램에 대한 응용 프로그램 초기화가 구성되어 있고 새로운 w3wp.exe의 인스턴스 내부에서 초기화 Url이 실행되고 있더라도, 중첩 재생이 진행되는 동안에는 "실제" default.aspx가 제공해주는 콘텐트가 반환됩니다.
URL 재작성과 응용 프로그램 초기화
기본적으로는 응용 프로그램이 초기화되는 동안 보여줄 응용 프로그램 초기화 기능의 "시작 페이지" Url은 단 하나만 지정할 수 있습니다. 그러나, 응용 프로그램 초기화 기능에서 몇 가지 서버 변수가 지원되기 때문에 초기화가 수행되는 동안 해당 서버 변수들을 요청 처리 제어에 활용할 수 있습니다. 이런 특성을 활용하면 미리 생성해 놓은 정적 콘텐트에 보다 다양하게 맵핑할 수 있는 선언적 URL 재작성 모듈 규칙을 생성할 수 있습니다.
이번 미리보기에서는 remapManagedRequestsTo 어트리뷰트 대신 URL 재작성 규칙을 사용하여 동일한 결과를 얻어보도록 하겠습니다.
노트: URL 재작성 모듈의 설치 방법에 대해서는 부록을 참고하시기 바랍니다.
applicationHost.config 수정하기
다시 메모장으로 applicationHost.config 파일을 열고 응용 프로그램 풀 요소와 응용 프로그램 요소를 원래대로 변경하여 전역 응용 프로그램 초기화 처리를 비활성화시킵니다. 지금부터는 응용 프로그램 초기화 동작 구성을 집중적으로 살펴보려고 하므로 이번 단계에서는 먼저 전역 구성을 제거해야 합니다.
따라서, 응용 프로그램 풀과 응용 프로그램에 관한 applicationHost.config 항목들은 다음과 같이 변경되어야 합니다.
응용 프로그램 풀 구성 항목:
<add name=".NET v4.5" managedRuntimeVersion="v4.0" />
응용 프로그램 구성 항목:
<application path="/appinit" applicationPool=".NET v4.5">
작업을 마쳤으면 변경 사항들을 저장합니다. 그리고, 변경된 내용을 IIS에 반영해야 하므로 권한이 상승된 명령줄 창에서 다음과 같은 명령을 입력하여 월드 와이드 웹 서비스를 재생합니다:
net stop w3svc & net start w3svc
응용 프로그램 수준 web.config 수정하기
먼저, 응용 프로그램 수준의 web.config 파일을 열었던 메모장에서 <applicationInitialization> 요소를 찾아서 emapManagedRequestsTo 어트리뷰트를 제거합니다. 이 작업을 마치고 나면 <applicationInitialization> 구성 섹션은 다음 구성 조각과 같은 모습이어야 합니다.
<applicationInitialization skipManagedModules="true"> <add initializationPage="/default.aspx" /> </applicationInitialization>
이제, 더 이상 <applicationInitialization> 요소에 요청을 재맵핑할 Url이 존재하지 않기 때문에 이를 대신할 URL 재작성 규칙을 추가해야 합니다. 따라서, 명시적으로 "default.aspx"과 "/"에 대한 요청을 "Startup.htm"로 전달하는 재작성 규칙을 추가합니다. URL 재작성 모듈은 기본 문서가 동작하는 방식을 "알지 못하므로" 이처럼 두 개의 재작성 규칙이 필요합니다. ASP.NET 응용 프로그램에서 "/"와 "default.aspx"는 같은 의미를 갖고 있으므로 URL마다 각각 하나 씩, 두 개의 URL 재작성 규칙이 필요합니다.
작성된 새로운 규칙들은 다음과 같습니다. 또는, web.config 파일에서 "Exercise 2 - Step 2 Mapping Requests to the Home Page" 주석의 바로 다음 부분의 주석을 제거해서 미리 구성해놓은 URL 재작성 규칙을 활성화시켜도 됩니다.
<rewrite> <rules> <rule name="Home Page-Expanded" stopProcessing="true"> <match url="default.aspx" /> <conditions> <add input="{APP_WARMING_UP}" pattern="1" /> </conditions> <action type="Rewrite" url="Startup.htm" /> </rule> <rule name="Home Page-Short" stopProcessing="true"> <match url="^$" /> <conditions> <add input="{APP_WARMING_UP}" pattern="1" /> </conditions> <action type="Rewrite" url="Startup.htm" /> </rule> </rules>
</rewrite>
이 두 가지 규칙에는 몇 가지 주의 깊게 살펴볼 부분들이 있습니다. 첫 번째는 <rule /> 요소의 stopProcessing 어트리뷰트가 "true"로 설정되어 있다는 점입니다. 이 어트리뷰트는 뒤에 포괄적 URL 재작성 규칙을 추가할 때 default.aspx나 "/"에 대한 요청에 대해 포괄적 URL 재작성 규칙이 실행되는 것을 원하지 않기 때문에 필요한 설정입니다.
두 번째로 <conditions /> 요소에 작성한 URL 재작성 조건에 주목하시기 바랍니다. 이 조건은 사실상 "응용 프로그램이 초기화 상태에 있을 때만 규칙을 적용하라"는 의미를 갖고 있습니다. 즉, APP_WARMING_UP 서버 변수는 응용 프로그램 초기화가 활성화되어 있고 IIS가 모든 초기화 Url들을 처리하는 상태일 때만 IIS에 의해서 "1"로 설정되기 때문입니다.
마지막으로 실제 요청을 재작성해서 대신 "Startup.htm"을 실행하도록 동작이 정의되어 있습니다. 이는 IIS로 하여금 정적 Startup.htm 페이지를 렌더하도록 요청을 정적 파일 처리기로 전달하는 효과가 있습니다.
이제 포괄적 재작성 규칙을 추가해야합니다. URL 재작성 모듈과 응용 프로그램 초기화를 함께 사용하는 경우, 선행 규칙들이 하나도 적용되지 않았을 때 실행될 포괄적 규칙들이 필요합니다. 다음에서 굵게 표시된 규칙들을 rewrite 섹션에 포괄적 규칙으로 추가합니다. 또는, web.config 파일에서 "Exercise 2 - Step 2 Setting Up a Catch-All Rule" 주석의 바로 다음 부분의 주석을 제거해서 미리 구성해놓은 규칙을 활성화시켜도 됩니다.
<rewrite> <rules> <rule name="Home Page-Expanded" stopProcessing="true"> <match url="default.aspx" /> <conditions> <add input="{APP_WARMING_UP}" pattern="1" /> </conditions> <action type="Rewrite" url="Startup.htm" /> </rule> <rule name="Home Page-Short" stopProcessing="true"> <match url="^$" /> <conditions> <add input="{APP_WARMING_UP}" pattern="1" /> </conditions> <action type="Rewrite" url="Startup.htm" /> </rule> <rule name="All Other Requests"> <match url=".*" /> <conditions> <add input="{APP_WARMING_UP}" pattern="1" /> </conditions> <serverVariables> <set name="SKIP_MANAGED_MODULES" value="0" /> </serverVariables> <action type="Rewrite" url="{URL}" /> </rule> </rules> </rewrite>
작업을 마쳤으면 변경 사항들을 저장합니다.
이 새로운 규칙은 해당 규칙에 전달된 모든 Url에 적용되며 IIS로 하여금 전달된 Url에 대한 요청을 계속 처리하도록 지시합니다. 또한, 이 규칙은 "SKIP_MANAGED_MODULES"라는 이름의 서버 변수 값을 "0"으로 설정하는데 이는 곧 "false"로 설정한 것과 동일합니다. 이 설정은 IIS로 하여금 정상적인 방식으로 요청이 전달되는 경우와 같은 방식으로 URL 재작성 모듈이 해당 요청을 재작성하도록 지시합니다.
응용 프로그램 실행하기
다시 권한이 상승된 명령줄 창에서 다음과 같은 명령을 입력하여 월드 와이드 웹 서비스를 재생합니다:
net stop w3svc & net start w3svc
그리고, 인터넷 익스플로러의 새로운 인스턴스를 시작한 다음, 다시 한 번 다음의 Url로 이동합니다:
http://localhost/appinit/default.aspx
그러면, URL 재작성 규칙을 이용해서 시작 페이지 로직을 다시 정의했음에도 첫 번째 미리보기에서와 동일하게 동작하는 것을 확인할 수 있을 것입니다. 다시 말해서, 초기에는 회색 배경의 Startup.htm 페이지가 나타나고 그 이후 브라우저를 주기적으로 새로 고침해보면, 약 8초 가량 뒤에 배경색이 흰색으로 바뀌게 되는데, 이는 응용 프로그램 초기화가 완료되어 "실제" default.aspx 페이지가 반환되었다는 것을 뜻합니다.
복잡한 시작 페이지 규칙
방금 전의 미리보기에서는 특정 Url "X"를 특정 Url "Y"로 직접 맵핑하는 응용 프로그램 초기화를 구성했었습니다. 이번에는 보다 복잡한 응용 프로그램 초기화 시나리오를 구현해보도록 하겠습니다.
브라우저를 이용해서 다음의 두 Url들로 이동해봅니다:
- http://localhost/appinit/ImageHandler.ashx?image=Lighthouse
- http://localhost/appinit/ImageHandler.ashx?image=Tulips
이 Url들은 동적으로 정적 콘텐트를 생성하는 예제입니다. 이 예제 응용 프로그램의 ImageHandler.ashx 내부 코드에서는 쿼리스트링에서 "image"라는 키를 찾습니다. 그리고, 만약 그 키의 값이 "Lighthouse"나 "Tulips"이라면 ASP.NET 처리기가 App_Data 폴더에 위치해있는 해당 JPG 화면을 전송합니다.
이 처리기는 단순히 이미지를 반환할 뿐이므로 응용 프로그램 초기화가 진행 중인 상황에서도 적절한 이미지를 반환할 수 있습니다. 비록 이미지 반환 메커니즘에서 관리되는 코드가 사용되지만 기반 ASP.NET 응용 프로그램을 시작하고 초기화하기 위해서 장시간이 걸릴 때에도 사용자들에게 미리 생성한 이미지들을 신속하게 제공할 수 있습니다.
응용 프로그램 수준 web.config 수정하기
응용 프로그램 수준의 web.config 파일이 열려있는 메모장에서 또 다른 URL 재작성 규칙을 마지막 포괄적 규칙 직전에 추가합니다. 지금 추가해야 할 새로운 규칙은 다음과 같습니다. 또는, web.config 파일에서 "Exercise 3 - Step 1 Complex Splash Page Rules" 주석의 바로 다음 부분의 주석을 제거해서 미리 구성해놓은 규칙을 활성화시킬 수도 있습니다.
<rule name="Image Handler Remapping" stopProcessing="true"> <match url="ImageHandler.ashx" /> <conditions> <add input="{APP_WARMING_UP}" pattern="1" /> <add input="{QUERY_STRING}" pattern="image=([A-Za-z]+)&?" /> </conditions> <action type="Rewrite" url="Images/{C:1}_static.jpg" appendQueryString="false" /> </rule>
작업을 마쳤으면 변경 사항들을 저장합니다.
이 규칙에서도 default.aspx나 "/"에 대한 재작성 규칙의 경우와 동일하게 stopProcessing 어트리뷰트를 "true"로 설정해서 ImageHandler.ashx에 대한 요청이 뜻하지 않게 실패한 경우, 응용 프로그램이 초기화되는 동안 맨 끝의 포괄적 재작성 규칙으로 요청이 전달되는 것을 방지합니다.
그리고, 이 규칙은 "ImageHandler.ashx"에 대한 요청의 퀴리스트링에서 필요한 이미지를 추출해내기 위해서 정규표현식 캡쳐 그룹을 사용합니다. 사용된 매치 패턴 정의는 pattern="image=([A-Za-z]+)&?"로, IIS에게 "image"라는 이름의 쿼리스트링 값을 추출하도록 지시합니다. 그리고, 이 추출된 값은 action 요소의 url 어트리뷰트에 url="Images/{C:1}_static.jpg"와 같이 재사용됩니다.
이 action 요소의 url 어트리뷰트는 URL 재작성 모듈에게 ImageHandler.ashx에 대한 요청을 응용 프로그램의 하위 디렉터리인 Images 디렉터리의 파일 중 하나로 재작성하도록 지시합니다. 그리고, 정규표현식으로 캡쳐한 쿼리스트링 값을 이용해서 Images 하위 디렉터리에서 최종적으로 서비스 될 이미지의 파일명을 구성합니다. 즉, ImageHandler.ashx?image=Tulips와 같은 요청은 Images/Tulips_static.jpg로 재전송됩니다.
윈도우 탐색기로 inetpub\wwwroot\appinit 디렉터리를 살펴보면 Images 하위 디렉터리에서 Tulips.jpg의 "정적" 버전과 Lighthouse.jpg의 "정적" 버전의 두 파일을 확인하실 수 있습니다. 이 정적 이미지들은 응용 프로그램이 초기화되는 도중에 제공될 미리 준비된 콘텐트로 사용됩니다.
응용 프로그램 실행하기
다시 권한이 상승된 명령줄 창에서 다음과 같은 명령을 입력하여 월드 와이드 웹 서비스를 재생합니다:
net stop w3svc & net start w3svc
그리고, 인터넷 익스플로러를 이용해서 다음의 두 Url들로 이동해봅니다:
http://localhost/appinit/ImageHandler.ashx?image=Lighthouse
또는
http://localhost/appinit/ImageHandler.ashx?image=Tulips
이 때, 이미지가 반환되는 방식을 주의해서 살펴보시기 바랍니다. 두 Url 모두 이미지에 "정적"으로 미리 만들어진 버전의 이미지임을 나타내주는 워터마크가 찍혀있습니다. 워터마크는 이미지의 상단 부분에 "This image is the static version of...."라는 텍스트로 나타닙니다.
그러나, 약 10초 정도 뒤에 브라우저를 새로 고침해보면, 반환되는 이미지 콘텐트가 ImageHandler.ashx 처리기를 통해서 제공되는 "실제" 콘텐트로 변경되는 것을 확인할 수 있습니다. 응용 프로그램의 초기화가 완료되었기 때문에 ASP.NET 처리기에 의해 동적으로 생성된 콘텐트가 제공되어 워터마크가 사라지게 됩니다.
노트: 만약 인터넷 익스플로러가 새로 고쳐지지 않는다면 주소 창의 "호환성 보기" 아이콘을 클릭하거나 새로 고침 아이콘을 클릭해서 강제로 인터넷 익스플로러가 페이지를 새로 고치도록 만듭니다.
요약
IIS 8.0의 응용 프로그램 초기화 기능을 이용하면 IIS가 중지된 응용 프로그램을 초기화하는 동안 브라우저로 정적 콘텐트를 반환하도록 개발자나 관리자가 IIS를 구성할 수 있습니다. 이와 같이 정적 콘텐트를 브라우저로 즉시 반환하면 사용자들은 무작정 응답을 기다리는 대신 보다 훌륭한 사용자 경험을 얻을 수 있습니다. 응용 프로그램 초기화 기능을 이용하면 중지됐던 응용 프로그램을 시작하는 동안, 빈 브라우저 페이지나 빙글빙글 돌아가는 단순한 대기 아이콘만 보여주는 것이 아니라, 기반 응용 프로그램이 고비용의 초기화 작업을 처리를 완료하는 동안 적절한 정적 컨텐트를 제공할 수 있습니다.
또한, 웹 서버가 시작되거나 재생될 때마다 초기화 작업을 자동적으로 시작할 수도 있습니다. 서버 관리자가 응용 프로그램이 자동적으로 초기화되는 것을 원하지 않는다면 중지된 응용 프로그램에 대한 첫 번째 요청이 전달되었을 때, 요청에 따라 초기화 작업이 시작되도록 구성할 수도 있습니다.
전역 및 지역 응용 프로그램 초기화 기능은, 두 가지 모두 보다 풍부하고 복잡한 초기화 규칙을 제공할 수 있도록 URL 재작성 모듈과 통합되어 있습니다. 응용 프로그램 초기화 기능과 통합된 URL 재작성 규칙을 이용하면, IIS가 내부적으로 응용 프로그램을 시작하는 동안 각각의 Url들 및 가상 경로에 대해 미리 만들어진 개별적인 형식의 정적 콘텐트를 제공해줄 수 있습니다.
부록 - 예제 ASP.NET 응용 프로그램 설정하기
노트: 다음 내용들은 서버에 이미 IIS 8.0이 설치되어 있고 IIS 8.0에서 ASP.NET 4.5가 활성화되어 있다고 가정하고 있습니다.
예제 응용 프로그램 풀기
다음 .zip 파일에 본문에서 사용하는 예제 ASP.NET 응용 프로그램이 들어 있습니다:
이 파일을 다운로드 받은 다음, 웹 서버의 wwwroot 폴더에 압축을 풉니다. 가령, 웹 서버의 "Default Web Site"가 C:\ 드라이브에 설치되어 있다면 이 파일의 콘텐츠들을 "c:\inetpub\wwwroot\appinit"에 풀면 됩니다.
IIS 8.0에 응용 프로그램 생성하기
파일 시스템에 "appinit" 예제의 압축을 풀었으면 이 폴더를 IIS 8.0에서 ASP.NET 응용 프로그램으로 구성해야 합니다. 다음 스크린샷은 IIS 8.0에 응용 프로그램으로 구성된 appinit 예제 응용 프로그램을 보여줍니다. 더불어, 이 응용 프로그램이 ".NET v4.5" 응용 프로그램 풀에 할당된 것에 주의하시기 바랍니다.
URL 재작성 모듈 설치하기
이이 예제 응용 프로그램은 응용 프로그램 초기화 기능과의 향상된 통합을 위해 URL 재작성 모듈을 사용합니다. 따라서, 서버에 URL 재작성 모듈을 설치해야만 합니다. URL 재작성 모듈은 http://www.iis.net/download/URLRewrite에서 다운로드 받을 수 있습니다.
URL 재작성 모듈 구성하기
웹 서버에 URL 재작성 모듈을 설치한 다음에는, 응용 프로그램 초기화 기능에서 SKIP_MANAGED_MODULES 서버 변수를 사용할 수 있도록 IIS의 applicationHost.config 파일을 수정해야 합니다.
메모장 등의 텍스트 편집기를 사용해서 머신 수준 applicationHost.config 파일을 엽니다. 가령, 운영체제가 C:\ 드라이브에 설치되어 있다면 applicationHost.config 파일은 C:\Windows\System32\inetsrv\config에 위치해 있을 것입니다.
파일을 스크롤해서 보안 섹션을 찾아 이동합니다. 이 섹션은 <security> XML 요소로 시작됩니다. 그리고, <security> 요소 직전에 다음과 같은 XML 요소를 추가합니다:
<rewrite> <allowedServerVariables> <add name="SKIP_MANAGED_MODULES" /> </allowedServerVariables> </rewrite>
마지막으로 applicationHost.config 파일의 변경 사항을 저장합니다.
- 윈도우 서버 8에 IIS 8 설치하기 2012-04-11 08:46
- ASP.NET 3.5와 ASP.NET 4.5를 지원하는 IIS 8 2012-04-21 22:20
- IIS 8.0 ASP.NET 구성 관리 2012-04-29 10:40
- IIS 8.0 응용 프로그램 초기화 (Application Initialization) 2012-05-15 13:36
- IIS 8.0 동적 IP 주소 제한 2012-05-29 17:17
- IIS 8.0 FTP 로그온 시도 제한 2012-06-04 14:48
- IIS 8.0 CPU 쓰로틀링: 사이트 및 응용 프로그램 샌드박싱 2012-06-15 22:45
- IIS 8.0 중앙집중식 SSL 인증서 지원: SSL 확장성 및 관리용이성 2012-06-22 08:36
- IIS 8.0 서버 이름 표시(SNI, Server Name Indication): SSL 확장성 2012-06-29 14:20
- NUMA 하드웨어 상에서의 IIS 8.0 멀티코어 스케일링 2012-07-06 15:27
- IIS 8.0 익스프레스 개요 2012-07-13 09:14