응용 프로그램 요청 라우팅을 이용한 3-티어 배포 아키텍처 구성하기
개요
본문에서는 응용 프로그램 요청 라우팅을 이용한 3-티어 배포 아키텍처의 구성 과정을 살펴봅니다. 일반적으로 3-티어 배포 아키텍처는 다음과 같이 웹 티어, 응용 프로그램 서버 티어, 그리고 데이터 티어로 구성됩니다:
대부분 이 배포 시나리오에서 정적 콘텐츠는 티어 1의 서버에 의해서 서비스되고, 동적 콘텐츠는 티어 2 서버의 업무 로직에 의해서 서비스됩니다.
목표
본문의 목표는 응용 프로그램 요청 라우팅을 이용해서 3-티어 배포 아키텍처를 구성하는 것입니다. 그리고, 그 중에서도 정적 콘텐츠는 ARR 서버가 직접 서비스하는 반면, 동적 콘텐츠에 대한 요청은 응용 프로그램 서버로 전달되도록 구성하는 방법을 중점적으로 살펴볼 것입니다.
전제조건
본문의 과정을 정상적으로 따라해보기 위해서는 먼저 다음과 같은 조건들을 만족해야 합니다:
- IIS 7.0이 설치되어 있는 윈도우 2008(모든 SKU 가능) 이상의 시스템
- 마이크로소프트 응용 프로그램 요청 라우팅 버전 1 및 관련 모듈들
- 사이트 및 응용 프로그램이 실행되고 있는 최소한 두 개 이상의 응용 프로그램 서버
- 응용 프로그램 요청 라우팅 서버에서 서비스 할 정적 콘텐츠
만약, 아직 응용 프로그램 요청 라우팅을 설치하지 않았다면, 다음 링크에서 다운로드가 가능합니다: *
- Download Microsoft Application Request Routing Version 1 for IIS 7 (x86)
- Download Microsoft Application Request Routing Version 1 for IIS 7 (x64)
응용 프로그램 요청 라우팅을 설치하는 보다 자세한 방법은 응용 프로그램 요청 라우팅 설치하기를 참고하시기 바랍니다.
그리고, 마지막으로 응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 문서에서 설명하는 과정에 따라 정의 및 구성된 서버 팜이 준비되어 있어야만 합니다.
* 이전 문서에서 설명했던 것처럼 현재 ARR의 최신 버전은 2.5로(2011년 5월 30일 현재), 두 링크 중 어떤 것을 선택하더라도 그 결과는 같습니다. 결론적으로 웹 플랫폼 설치 관리자에 의해서 모든 설치 과정이 이뤄지도록 변경되었습니다.
단계 1 - 정적 요청을 필터링하도록 URL 재작성 규칙 수정하기
이번 단계에서는 특정 확장자나 경로에 대한 요청을 응용 프로그램 요청 라우팅 서버에서 직접 서비스하도록 URL 재작성 규칙을 수정해볼 것입니다. 정적 요청은 .jpg나 .gif 등의 파일 확장자를 확인함으로써 구분이 가능합니다. 만약, 정적 리소드들이 /images/ 같은 특정 폴더 하위에 존재한다면 URL 재작성 규칙을 이용해서 URL에서 해당 경로를 찾아낼 수도 있습니다.
본문에서는 확장자 .jpg와 .css, 그리고 /images/ 폴더를 찾도록 URL 재작성 규칙을 수정합니다. 그러면, 요청된 리소스가 .jpg나 .css를 확장자로 갖고 있는 경우, 해당 리소스는 ARR 서버에서 직접 서비스됩니다. 마찬가지로, 요청된 URL이 /images/를 포함하고 있다면 이 요청은 ARR 서버에서 직접 서비스됩니다. 그리고, 그 밖의 다른 요청들은 ARR 서버 뒤편에 감춰진 응용 프로그램 서버로 전달될 것입니다.
다음 과정을 진행하기 전에 먼저 서비스 될 정적 콘텐츠들이 ARR 서버에 정상적으로 존재하는지 확인하시기 바랍니다. ARR 서버 자체에 위치한 로컬 콘텐츠나 공유 콘텐츠 모두 정적 콘텐츠로 사용할 수 있습니다.
UI를 이용해서 URL 재작성 규칙을 수정하려면:
- IIS 관리자를 실행합니다.
- 응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 문서에서 설명한 과정에 따라 생성한 "myServerFarm" 서버 팜을 선택합니다.
- 그러면, 다음과 같은 아이콘들이 나타납니다.
- "Routing Rules" 아이콘을 마우스로 더블 클릭합니다.
- 그리고, "Requests with the following extensions are not forwarded" 텍스트 박스에 "*.jpg"와 "*.css"를 입력합니다.
이처럼 여러 개의 확장자를 입력하는 경우에는 콤마(,)로 연결해줍니다.
URL에서 일치하는 경로를 찾기 위해서 "Requests with the following patterns are not forwarded" 텍스트 박스에 "*/images/*"를 입력합니다.
여기에서 와일드 카드(*)는 모든 문자와 일치한다는 의미로 /images/ 경로의 앞과 뒤에 사용되었습니다.
- 정적 이미지들이 ARR 서버에서 서비스되는 것을 확인해보려면 로그를 분석해보면 됩니다. 기본적으로 로그는 "c:\inetpub\logs\LogFiles\"에 생성됩니다. 물론, ARR 서버 뒤편에 감춰져 있는 응용 프로그램 서버의 로그에는 *.jpg, *.css 또는 */images/*를 참조하는 어떠한 요청도 기록되어 있지 않을 것입니다.
명령 프롬프트를 이용해서 URL 재작성 규칙을 수정하려면:
- 관리자 권한으로 명령 프롬프트를 엽니다.
- %windir%\system32\inetsrv로 이동합니다.
- 다음의 명령어를 입력해서 모든 URL 재작성 규칙들을 제거합니다:
appcmd.exe clear config -section:system.webServer/rewrite/globalRules
- 확장자가 *.jpg나 *.css거나 경로에 */images/*가 포함된 리소스들이 응용 프로그램 서버로 전달되지 않도록 라우팅 규칙들을 수정하기 위해서 다음과 같은 명령어들을 입력합니다:
appcmd.exe set config -section:system.webServer/rewrite/globalRules /+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True']" /commit:apphost appcmd.exe set config -section:system.webServer/rewrite/globalRules /[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*" /commit:apphost appcmd.exe set config -section:system.webServer/rewrite/globalRules /+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='EXT_{URL}',negate='True',pattern='*.jpg']" /commit:apphost appcmd.exe set config -section:system.webServer/rewrite/globalRules /+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='EXT_{URL}',negate='True',pattern='*.css']" /commit:apphost appcmd.exe set config -section:system.webServer/rewrite/globalRules /+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{URL}',negate='True',pattern='*/images/*']" /commit:apphost appcmd.exe set config -section:system.webServer/rewrite/globalRules /[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite" /[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].action.url:"http://myServerFarm1/{R:0}" /commit:apphost
요약
본문에서는 응용 프로그램 요청 라우팅을 이용해서 3-티어 배포 아키텍처 시나리오를 위한 URL 재작성 규칙들을 수정해보았습니다. 응용 프로그램 요청 라우팅의 보다 많은 속성 및 기능들을 살펴보려면 응용 프로그램 요청 라우팅을 이용한 HTTP 로드 밸런싱 문서를 참고하시기 바랍니다.
그리고, 이 시나리오에서 응용 프로그램 요청 라우팅이 리버스 프록시(Reverse Proxy)로 사용되는 경우, 응답 헤더와 엔티티 바디를 재작성할 수 있는 기능을 갖고 있는 URL 재작성 버전 2를 함께 사용하면 더 강력한 기능을 제공할 수 있습니다.
관련 자료
- 문서
- 응용 프로그램 요청 라우팅 설치하기 2011-05-13 18:43
- 응용 프로그램 요청 라우팅 모듈 사용하기 2011-05-17 15:27
- 응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 2011-05-19 18:56
- 응용 프로그램 요청 라우팅을 이용한 HTTP 로드 밸런싱 2011-05-23 13:33
- 응용 프로그램 요청 라우팅을 이용한 3-티어 배포 아키텍처 구성하기 2011-05-30 14:34
- 응용 프로그램 요청 라우팅을 이용한 파일럿 프로그램 관리 2011-06-08 16:27
- 응용 프로그램 요청 라우팅 2.0을 이용한 공유 호스팅의 배포 개요 2011-07-03 15:12
- 응용 프로그램 요청 라우팅을 이용한 공유 호스팅 2011-07-10 13:34
- 응용 프로그램 요청 라우팅 서버들의 다중 인스턴스 이용하기 2011-07-14 14:18