정말 좋은 실버라이트 3 세미나가 있어서 소개 합니다.
실버라이트 코리아 커뮤니티에서 운영진이 집필한 실버라이트 3 서적 출간 기념 세미나 입니다.
실버라이트 3 세미나도 듣고, 실버라이트 3 서적도 30%나 싸게 구입할 수 있는 좋은 기회 입니다.
먼저 출간 된 RIA in 실버라이트 3 책과 더불어 참고할 만한 좋은 실버라이트 3 서적이네요. :)
안녕하세요. IISKOREA 팀블로그의 김대우 입니다. 이번에 같이 고민해 보고 싶은 내용은 지난번의 포스팅에 이어서 두번째, 바로 “웹서버 관리 작업 자동화”에 대한 내용으로 포스팅을 풀어 보려고 합니다.
지난 포스트를 통해 IIS7의 다양한 설치/구성/관리/배포 기능 및 도구 소개 - 관리 및 배포 툴에 대해서 이야기를 드렸는데요. 이번에는 관리 자동화 툴에 대해 초점을 맞춰 단상을 정리해 보려고 합니다.
IIS는 이러한 관리작업 자동화를 위해 여러가지 도구들을 제공하는데요. – 당연히 IIS 관리자는 GUI툴이니 자동화 도구라고 할 수 없겠죠?(설마, 현업에서 말하는 인간 자동화???) ^_^;;;
이렇게 IIS의 구성 정보를 담고있는 XML 파일을 수정하는 방법이지요. 특히, 자동화를 위해서는 파워쉘과 명령 프롬프트의 AppCmd를 이용하는 것이 하나의 방법이 되실 겁니다.
IIS의 자동화를 위해서는 크게 세가지를 보시면 될 것 같습니다.
(1) 파워쉘(Power Shell)
(2) AppCmd 명령 프롬프트 처리
(3) WMI(Windows Management Instrumentation)와 MWA(Microsoft.Web.Administration) API
GUI 관리 툴일 경우 여러 단계를 거쳐야 하는 작업들을 이 자동화 툴들을 이용하면 스크립트화 시켜주기 때문에 유용한데요. 조금만 더 알아 보도록 하면
(1) 파워쉘 – IIS 7용 파워쉘 스냅인을 이용 가능합니다.
- 강력하고 심플함 : 매우 복잡한 관리 작업들을 키워드 기반 프로그래밍 명령어들로 자동화 시킬 수 있음
- 오브젝트 기반 : 여러 오브젝트들을 호출해 스크립트에서 작업 가능
- 심플하고 강력한 명령줄 기반 인터페이스 : 복잡한 스크립트를 명령줄 기반으로 제작해 안전하게 테스트도 가능
- 시스템 통합 : .NET Framework나 WMI 확장기능, 레지스트리 등에 대한 호출 및 처리가 가능
- 안전 최우선 작업 가능 : 인승서 기반의 사인된(Signed) 스크립트를 지원해 안전하게 여러 작업을 제한 가능함
참고자료 :
Managing IIS with the IIS 7.0 PowerShell Snap-in
Windows PowerShell Snap-In
(2) AppCmd 명령 프롬프트
이 AppCmd가 생소한 분들도 계실 것 같은데요. 이런 형태의 명령 프롬프트에서 수행하는 작업으로 웹사이트 제작, 응용프로그램 풀 바인딩 등의 작업을 손쉽게 처리 가능합니다. 이녀석은 어떤 장점이 있을까요?
- 웹사이트, 웹 어플리케이션, 응용프로그램 풀, 가상 디렉토리를 생성하고 구성할 수 있음
- 웹사이트 시작, 중지 명령을 수행 가능하며, 응용프로그램풀을 리사이클링 시킬 수 있음
- 수행중인 작업자 프로세스에 대한 리스트와 현재 실행중인 요청에 대해서 조회 가능
- IIS와 ASP.NET 구성 정보에 대해서 조회, 출력, 내보내기(Export), 가져오기(Import)를 수행 가능
참고자료 :
AppCmd.exe 소개
ABC's of Appcmd (command line administration in IIS7)
AppCmd도 이렇게 여러가지 명령줄 기반 자동화 작업을 수행이 가능합니다. 그렇다면 갑자기 드는 생각인데요. 파워쉘과 AppCmd의 차이는 어떻게 설명이 가능할까요?
- 파워쉘은 오브젝트 기반으로 더욱 유연하고 복잡한 관리 작업들을 수행 가능합니다. 또한 파워쉘은 .NET Framework나 WMI 확장 API를 접근 가능하고 높은 보안성을 요구하는 복잡한 스크립트 작업을 실행 가능합니다.
- AppCmd는 파워쉘에 비하면 심플하고, IIS 관리를 위한 기능들에 초점을 맞춰 실행이 가능합니다. 바꿔말하면, 파워쉘과 같은 강력하고 복잡합 스크립트 기능은 이용이 불가능합니다.
이렇게 두가지, 관리자 분들이 선호하시는 자동화 관리 툴에 대해서 알아 보았습니다. 개인적인 소견으로 파워쉘이나 AppCmd는 개별 서버 기반에서 작업하거나, 관리하는 서버의 수가 5~10대 미만이라면 이용 가능하겠으나, 수십 수백대의 서버를 유지 관리해야 하는 호스팅회사와 같은 경우에는 관리 작업이 쉽지 않을 겁니다. 이럴때 이용하는것이 바로 MWA와 WMI를 이용해 직업 각 회사에 맞는 작업을 처리 가능한 관리 프로그램을 제작하는 것이지요. 왜 MWA와 WMI가 필요한지는 감 잡으셨는지요? 그렇다면, MWA와 WMI와 같은 관리 프로그램 제작을 위한 API들에 대해서 알아 보도록 할까요?
(3) WMI(Windows Management Instrumentation)와 MWA(Microsoft.Web.Administration) API
먼저 WMI를 소개해 드리고 이어서 MWA를 이야기 드리려고 합니다.
WMI로 수행할 수 있는 작업
- 웹사이트 생성
- 전체 웹사이트 조회
- 웹사이트 중지, 시작
- 웹사이트 삭제
- 웹사이트 인스턴스 및 어플리케이션 인스턴스 관리
- 어플리케이션 도메인 관리 및 작업자 프로세스 관리
즉, IIS와 관련된 다양한 작업들을 이 WMI를 이용해 모두 프로그래밍적으로 자동화 처리가 가능합니다.
참고자료 : Managing Applications and Application Pools on IIS 7.0 with WMI
그렇다면 MWA는 어떨까요?
MWA를 보시기 전에 - IIS는 XML 구성 파일(applicationHost.config 파일과 web.config 파일)에 대해서 개발사가 자신의 커스텀 구성 섹션을 이용 가능하도록 허용하고 있습니다. 개발사는 이 영역에 기술된 구성 정보를 프로그래밍적으로 가져와 처리할 필요가 있을 수 있는데요, 이때 사용 가능한것이 바로 MWA API입니다.
참고자료 : Overview of MWA and MWM for IIS 7.0
참고로, 파워쉘을 이용해 WMI나 MWA 오브젝트를 호출해 속성 등을 불러와 파워쉘 스크립트로 처리하는 작업도 가능합니다.
이렇게 간단히, 웹서버 관리 자동화에 대한 내용을 정리해 보았습니다. 개인적으로는 좀더 욕심이 있어서, 호스팅회사가 처리해야할 자동화 작업 목록이나 기술 명세가 있다면 한번 마음 맞는 분들끼리 관리 툴을 오픈소스로 만들어 보는 것도 하나의 좋은 시도가 아닐까 생각됩니다. ^_^
감사합니다.
참고자료 : Provisioning Options in IIS 7.0
안녕하세요. IISKOREA 팀블로그의 김대우 입니다. 이번에 소개해 드릴 내용은 어플리케이션 개발자 / 관리자 분들이라면 모두가 고민하는 웹 어플리케이션의 구성/관리/배포에 대한 내용입니다.
단순히, 웹사이트 설치나 웹사이트 이전, 백업 하는 정도라고 생각하기 쉽습니다만, 웹사이트 및 응용프로그램들이 가지는 다양한 종속성(Dependency)등에 대한 고려와 시스템 / 웹사이트에 대한 설정까지 다양한 환경이 정확히 생성/관리/배포 되어야 하기 때문에 관리 작업에서 가장 어렵고 시간이 많이 소요되는 힘든 과정이 바로 이 구성/관리/배포가 아닐까 생각합니다.
또한, 한 두대의 웹서버를 관리하시는 분들부터, 5~10대의 서버를 관리해야 하는 경우, 또는 수백대의 웹서버를 자동화 기능들을 통해 관리해야 하는 호스팅사까지 다양한 환경에 맞는 스크립트나 배포 도구, 또는 필요할 경우 배포나 유지관리를 위한 툴을 직접 제작해야 하는 경우까지, 다양한 환경에 맞는 기능을 선택하는 것도 필요하실 겁니다. 이런 비지니스 구조, 환경에 맞는 툴들이나 방법은 어떻게 선택해야 할까요?
예를 들어, 한 서버에서 대략 300개 정도의 운영 중인 웹사이트에 하드웨어 적인 장애가 발생해 다른 시스템으로 이전해야 하는 상황이 발생하는 (웹호스팅) Shared Hosting 환경이라면 어떨까요? 더더욱 자동화된 배포나 이전, 백업 등에 대해서 고민하시게 될겁니다.
이 복잡한 작업들을 어떻게 쉽고 빠르게 해결 가능할까요?
IIS7은 여려 배포를 위한 훌륭한 기능들을 제공하고 있는데요. 그 배포 기능들을 차례대로 소개해 드리려고 합니다. ^_^
IIS의 다양한 배포 도구
(1) 웹 플랫폼 설치 관리자 – WPI
웹플랫폼 설치 관리자는 설치 과정을 GUI로 쉽게 구성 가능하도록 돕는 도구 입니다. 특히, Dependency가 있는 웹 어플리케이션을 자동으로 설치하거나, 관리툴, 개발도구, 다양한 확장기능들을 설명과 함께 선택이 가능하기 때문에 유용한 도구 입니다.
- 가장 손쉽고 자동화된 설치 환경 제공
- 국내&전세계의 다양한 웹 어플리케이션 기본 탑재
- 웹서버/데이터베이스서버/프레임워크/도구들을 설치 가능
- 웹 어플리케이션 설치시 종속적인 웹서버 기능이나 데이터베이스 기능들을 자동 설치
WPI 기술소개 링크 : http://www.iis.net/webpi
WPI 다운로드 : http://www.microsoft.com/web/downloads/default.aspx
웹플랫폼 설치 관리자는 단순한 배포 도구를 넘어선, 훨씬 중요한 역할을 Microsoft 웹 플랫폼 아키텍쳐와 관련해 수행하게 되는데요. 관련해서는 따로 상세하게 소개해 드릴 예정이니 도움 되시길 바랍니다.
(2) 웹 배포 도구 – Web Deployment Tool
웹 배포 도구는 웹사이트나 웹서버에 대해서 배포를 가능하게 돕는 IIS7의 확장기능(Extension)입니다. 특히, IIS6에서 IIS7으로의 마이그레이션이나 구성파일 패키징 기능을 지원하기 때문에 다양한 웹사이트 구성을 쉽게 이전이 가능한 특징이 있습니다. 여러대의 서버를 관리하는 경우라면 이 웹 배포 도구가 많은 도움이 되실 겁니다.
링크 : http://www.iis.net/extensions/WebDeploymentTool
- 패키징 기능으로 전체 웹사이트 파일, 포함된 데이터베이스, 권한 및 레지스트리정보 등을 패키지 가능
- IIS6를 IIS7으로 손쉽게 마이그레이션 가능
- 서버간 동기화(Synchronization) 가능
- IIS Manager와 연계해 이용 가능
웹 배포 도구 관련된 내용 역시 곧 포스트를 통해 상세히 전달해 드릴 예정입니다.
(3) IIS7의 파워쉘(Power Shell) 부가기능
파워쉘은 윈도우서버에 대해서 관심있는 분들은 잘 알고계시는 기능일텐데요. 윈도우 서버의 다양한 작업들을 파워쉘을 이용하면 모두 스크립트로 자동화가 가능한 것처럼, IIS7도 파워쉘을 이용해 모든 기능들을 스크립트화 시킨 후 웹사이트 생성부터 유지관리까지의 작업을 스크립트로 자동화시켜 실행 가능합니다. 다수의 웹서버를 관리하실 경우에 유용하며, 호스팅 환경 등에서도 활용 가능합니다.
- IIS7의 구성 정보들을 파워쉘 스크립트로 관리
- 웹사이트, 응용프로그램 풀, 웹응용프로그램, 가상디렉토리, 작업자 프로세스 등을 관리 가능
- 파워쉘의 다양한 스크립팅 기능으로 대규모의 복잡한 IIS 관리 기능을 처리 가능
- 파워쉘 2.0의 원격 기능을 이용해, 원격 서버를 파워쉘로 제어 가능
마찬가지로, IISKOREA 팀블로그에서 이 파워쉘을 이용한 유지 관리도 준비하고 있으니 기대해 주세요.
(4) 프로그래밍 API를 이용한 사용자 정의(Custom) 배포/관리툴 제작을 위한 기능
API를 이용한 방법은 자신이 소속된 회사에 적합한 패턴의 웹서버 생성, 관리 및 배포를 위한 프로그램을 직접 제공되는 기능을 이용해 제작 가능하게 합니다. 즉, 수백대가 넘는 호스팅사와 같은 IIS 웹서버 관리에 필요한 기능들을 이 제공되는 프로그래밍을 위한 API로 제작해 회사에 맞는 관리/배포를 위한 프로그램 직접 생성 가능하게 합니다. – 이미 나와있는 관리 솔루션들도 있지요.
WMI(Windows Management Instrument)
http://learn.iis.net/page.aspx/163/managing-applications-and-application-pools-on-iis-7-with-wmi/
Microsoft.Web.Administration
http://learn.iis.net/page.aspx/165/how-to-use-microsoftwebadministration/
자~ 이렇게 IIS는 비지니스 방식과 운용 규모 등에 맞는 다양한 관리/배포 도구를 제공하고 있습니다. 각각의 기능들에 대해서는 차후에 IISKOREA의 팀블로그를 통해 계속 소개해 드리도록 하겠습니다.
감사합니다.
안녕하세요, IISKOREA 팀블로그의 김대우 입니다. 이번에 소개해 드릴 내용은 살짝 도발적이기도 할 것 같은데요. 당연히 IIS와 관련된 내용이기도 합니다. 혹시, SQL서버의 쿼리 툴을-정확히는 GUI기반 툴을- 사용해본 경험이 있으신지요?
SQL2008의 GUI 관리 툴인 SQL Server Management Studio
SQL2000 시절에는 GUI 툴의 쌍두마차인, 엔터프라이즈 관리지와 쿼리 분석기가 있었지요. GUI로 편리하게 쿼리를 작성 가능하고, 데이터 조회, 프로시져 생성 등의 개발과정에 필수적인 쿼리 작성에 꼭 필요한 여러 기능들을 모두 담고 있는 유용한 녀석입니다. 특히, 조회한 결과를 그리드(표형식)로 볼 수 있고 쿼리 제작과 수정도 용이하기 때문에(vi 쓰시는 분들 말고 ^^;;) 개발 시간을 엄청나게 단축해 주는 녀석이기도 하지요. 하지만, 웹서버에 이 툴들을 설치하기도 애매한 노릇이고, DB서버마다 원격 접속하기도 쉽지 않지요. 특히, 여러 DB를 다루면서 개발과 관리를 동시에 해야 하는 PHP 개발자 분들은 시간이 많이 소요되는 작업이실 겁니다. - DB도 MySQL만 하는게 아니라 MSSQL도 같이 관리 하신다면? 가히 서버 관리 때문에 머리가 터져버릴지도…
IIS7는 PHP를 위한 최고의 개발 / 서비스 환경입니다.
IIS7은 윈도우 기반으로 Vista 및 Win7, Windows Server 2008에서도 이용 가능합니다. 즉, 주로 개발을 진행하시는 윈도우 환경에서 쉽게 구축이 가능하며, FastCGI를 통해 PHP를 아주 깔끔하게~ 지원합니다. 이런 개발용 PC에서 원격지의 SQL서버나 MySQL DB 처리, 또는 개발을 쉽게 할 수는 없을까요?
특히, PHP 개발 과정에서 주로 사용하는 + MySQL 또는 MSSQL은 DB에 접속해 개발하시기 어떤가요? – 쓸만한 GUI 쿼리 툴?
MySQL GUI 툴들 세트가 있긴 하지만 2%가 아닌 20% 넘게 부족한 느낌입니다. 또한, 한 PHP 하시는 분들께 비교적 잘 알려진 SQLyog라는 녀석이 있긴 합니다만, 유료라는게 좀~ 부담스럽습니다. 무료에 깔끔한, PHP 개발에 이용 가능한 그런 녀석은 없을까요? 있습니다. 바로, IIS 데이터베이스 관리자(Database Manager) 입니다.
IIS 데이터베이스 관리자로 MySQL과 MSSQL 웹 개발을 더욱 더 편리하게~
IIS의 기능 설치 관리를 위한 핵심 툴인 웹 플랫폼 설치 관리자를 실행 하시고, 웹플랫폼 – 웹서버 – 관리 항목에서 “데이터베이스 관리자”를 선택 가능합니다. 이어서 설치를 진행하시면 몇몇 종속성 기능들과 함께 설치가 완료됩니다.
참고 정보 : IIS Database Manager
Database Manager가 제공하는 기능
- 로컬 또는 원격지의 MSSQL, MySQL 데이터베이스를 관리 가능합니다.
- 테이블 추가, 수정, 삭제, 이름바꾸기 가능
- View 및 테이블 개체(PK, FK, 색인) 등을 관리 가능
- 테이블의 데이터를 GUI로 손쉽게 수정 가능
- 쿼리 제작 및 실행 가능
- 저장 프로시져 및 View 생성,수정,삭제 가능
- MSSQL 서버에 대해 백업과 복구 가능
- MSSQL과 MySQL을 제외한 다른 DBMS에 대해 관리 기능 확장을 위한 API 제겅(즉, 타 DB도 개발해 IIS 모듈로 추가 가능)
이렇게 흥미로운 기능들을 Database Manage가 제공합니다. 그럼, 실행하고 직접 DB에 붙어 볼까요.
Database Manager 실행
설치가 완료되면 IIS7의 관리 툴에서 Database Manager를 실행합니다.
이어서 MSSQL이나 MySQL 연결을 추가합니다.
Add connection을 클릭히고
Connection을 추가합니다. 물론, MySQL을 선택 하고 연결 정보를 입력하시면 물론 MySQL에 연결 가능합니다.
데이터를 그리드에서 조회가능하며, 다양한 작업을 수행 가능합니다.
테이블 스키마 정보도 확인 가능하며
PHP 개발 과정에서 꼭~ 필요한 쿼리 제작 및 수행도 손쉽게 처리 가능합니다.이렇게 데이터베이스를 쉽게 IIS에서 조회 가능하고, 쿼리 수행도 가능하며 원격 서버 관리 기능도 포함되기 때문에 개발하실때 유용할 것 같네요. 개인적인 생각에 MSSQL과 거의 동일한 인터페이스이기 때문에 MSSQL에 약간이라도 경험이 있다면 도움말이나 설명 없이도 슥슥~ 사용 가능하실 것 같습니다.
이렇게 간단히 IIS7의 Database Manager에 대해서 알아 보았습니다. IIS7은 PHP 개발과 배포에도 좋은 환경입니다. – 특히 관리 및 보안에 장점이…. 이런 여러 좋은 장점들에 대해서도 차근차근 풀어 보도록 하겠습니다. 감사합니다.
더 많은 IIS관련 정보는 IISKOREA 팀블로그를 참고하세요.
IISKOREA 팀블로그 : http://www.iiskorea.net
참고자료
IIS Database Manager
Using the IIS Database Manager
Basics of the IIS Database Manager
윈도우7 출시 쯤에 맞이하여 드디어 Visual Studio 2010 베타2가 공개 되었습니다. 10월 21일부터 MSDN에 영문버전이 공개 될 예정인데, 이번 Visual Studio 2010 베타2는 .NET Framework 4의 베타2 버전이 포함되어 있습니다.
이미 지난 베타1 버전을 테스트 해 보았던 분이라면, 이번 베타2에서는 더 안정적이고 빠른 속도를 만 깃 할 수 있을 겁니다. Visual Studio 개발 팀에서 베타1 보다 23배 더 빠르게 향상시키는 데 중점을 두었다고 하네요. 한편, 지난 베타1에서 일주일 동안 약 500명의 개발자들이 베타 테스트(DogFood)에 참여 했으며, 내부적으로 TFS 서버를 .NET 4 으로 적용되었으며 Visual Studio 팀의 87% 정도의 2,500명이 이를 이용하여 현재 쓰고 있다고 합니다.
또 한 가지 흥미로운 점은 이와 더불어, Visual Studio 브랜드 로고가 코발트 빛으로 좀더 모던한 느낌으로 바뀌었습니다. 이미 알고 계셨나요?
그렇다면, 이번 Visual Studio 2010이 무엇이 바뀌었나 살펴보자면 뭐니 뭐니 해도 세 가지 형태의 라인업을 가지고 가는 것에 대해 변경되었습니다. 다음의 도표를 상세한 내용은 다음 도표를 봐 주세요!
| VS 2010 새로운 라인업 | 기존 제품과의 연간 관계 | 제품 설명 |
| Visual Studio 2010 Ultimate | Visual Studio Team System Team Suite | Visual Studio 2010 Ultimate는 솔루션 개발을 간소화하고 위험을 낮추며 수익을 높여 줍니다. 설계 및 개발에서 테스트 및 배포에 이르기까지 Application Life Cycle Management 의 모든 단계를 위한 도구를 제공하여 개발자 여러분들과 개발 팀이 자유롭게 상상력을 발휘하고 유용한 솔루션을 개발할 수 있도록 지원합니다. 기존 Visual Studio Team System Team Suite 급의 제품입니다. |
| Visual Studio 2010 Premium | Visual Studio Team System Role Edition Development Edition / Database Edition / Architect Edition / Test Edition | Visual Studio 2010 Premium은 응용 프로그램 개발 작업을 간소화하는 완벽한 개발 도구 집합입니다. 개발자 여러분들과 개발팀은 보다 강력해진 코딩, 디버깅, 데이터베이스 및 테스트 도구를 사용하여 확장 가능한 고품질 솔루션을 개발할 수 있습니다. 기존 Visual Studio Team System Role Edition 급의 제품으로 주로 Development Edition 과 Database Edition 의 기능들이 포함되어 있는 제품입니다. |
| Visual Studio 2010 Professional | Visual Studio 2010 Professional | Visual Studio 2010 Professional은 기본적인 응용 프로그램 작성, 디버깅 및 배포 작업을 간소화하는 통합 환경입니다. 개발자 여러분들은 Visual Studio 2010 Professional을 통해 자유롭게 상상력을 발휘하고 아이디어를 손쉽게 구현할 수 있습니다. 기존 Visual Studio Professional Edition 급의 제품입니다. |
Visual Studio 2010 정식 버전은 3월 24일에 미국부터 시작하여 발표될 예정이며, 한국어 버전은 4월 초순쯤이면 여러분들과 만날 것으로 예상됩니다.
한편, Visual Studio 2010 베타2에 맞추어서 Silverlight 으로 이쁘게 꾸며진 웹 사이트를 개봉하였네요! 국내에서 어떤 기업이 Visual Studio 와 .NET 프레임워크를 도입했는지 한 번 살펴보시는 것도 재미있을 것이며, 국내 주요 .NET 컨설팅 파트너들도 있으니 필요하신 프로젝트가 있다면 요청 주시기 바랍니다. 또한 이와 맞물려, 새롭게 한글 MSDN 사이트도 이쁘게 바뀌었답니다. 개인적으로 저는 파란색을 좋아하는 지라 왠지 더 깔끔하게 느껴집니다.
아래의 사진을 클릭하시면 각각 해당 사이트로 방문합니다!
끝으로, 채널9에서 Visual Studio 2010에 대한 에피소드가 시리즈로 33번째 올라오고 있습니다. 이번 연재는 Visual Studo 2010 베타2를 어떻게 다운로드 받고 설정하는 지에 대한 소개가 올라와져 있습니다!
- Download instructions for all files in this video
- Compatibility hotfix for Team Explorer 2008 connecting to Team Foundation Server 2010
- More information about the Windows Server 2008 VHD
- Beta 2 home on MSDN
- Information on "Go Live" license
- MSDN Forums
- Visual Studio Connect site (버그 리포트 및 제안)
- Team Foundation Server 2010 Deployment Guidance
- Visual Studio 2010 and .NET Framework 4 Training Kit
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)
안녕하세요. IISKOREA의 김대우 입니다. 이번에 소개해 드릴 내용은 Rewrite Map에 대한 내용인데요.
간단히 말씀 드리자면, 모든 URL 변환 처리를 패턴을 이용해 프로그래밍적으로 처리 가능하다면 행복할 겁니다. 하지만, 모든 URL 처리가 이렇게 패턴에 매핑 가능한 것은 아닐겁니다. 바로 이럴 경우, URL 처리를 위한 패턴매칭 규칙(Rule)을 적용하기 어려운 여러 URL들에 대해 새로운 URL로 정의하려 할 경우에 Rewrite Map을 이용해 1:1로 매핑하는 처리를 이용하면 유용합니다. 즉, 단순 URL Rewrite Rule이 생성되는 것은 줄이면서 효율적으로 Rewrite 처리가 가능해지는 장점이 있는 것이지요. 물론 Rule의 수가 줄어들게 되니 정규표현식 처리가 줄게되고 이어서 시스템리스소도 적게 사용할 수 있을 겁니다.
Rewrite Map 제작
마찬가지로, 테스트를 위해 예전 포스트에서 작성한 심플한 article.aspx 파일을 이용해 볼께요.
<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>URL Rewrite Module Test</title>
</head>
<body>
<h1>URL Rewrite Module Test Page</h1>
<table>
<tr>
<th>Server Variable</th>
<th>Value</th>
</tr>
<tr>
<td>Original URL: </td>
<td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td>
</tr>
<tr>
<td>Final URL: </td>
<td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>
</tr>
</table>
</body>
</html>
테스트를 위해 http://localhost/article.aspx 링크를 접속해 보면 아래와 같은 결과를 보실 수 있을 겁니다.
(만약 안 나오신다면 ASP.NET 서비스를 설치해 주세요.)
Rewrite Map 생성
그렇다면, 본격적으로 Rewrite Map을 생성해 보겠습니다.
URL Rewrite를 선택해 주세요.
Manage rewrite map을 선택해 Rewrite Map을 생성합니다.
이렇게 이름을 “StaticRewrite”로 설정하고 “Add Mapping Entry”를 선택해 다음 Entry들을 넣습니다.
각각 값을 “/article1” 그리고 New Value를 “/article.aspx?id=1&title=some-title” 으로 지정합니다. 즉, /article1 요청이 들어오면 뒤에 나오는 URL로 rewrite 하라는 의미이지요.
| Original URL |
New URL |
| /some-title |
/article.aspx?id=1&title=some-title |
| /post/some-title.html |
/article.aspx?id=1&title=some-title |
이런 형태로 값을 넣어 줍니다. 이어서 확인할 내용! 과연 이 매핑 정보는 어디에 저장될까요? 넵! 바로 web.config에 저장되게 됩니다. 어떻게? XML 형태로요.
1: <rewrite>
2: <rewriteMaps>
3: <rewriteMap name="StaticRewrites" defaultValue="">
4: <add key="/article1" value="/article.aspx?id=1&title=some-title" />
5: <add key="/some-title" value="/article.aspx?id=1&title=some-title" />
6: <add key="/post/some-title.html" value="/article.aspx?id=1&title=some-title" />
7: </rewriteMap>
8: </rewriteMaps>
9: </rewrite>
이렇게 보시는 것처럼 web.config에 차곡차곡 저장되게 됩니다. 주의해서 보실 것은 Rewrite Rule이 아니라 rewriteMap 하위에 저장된다는 것이지요.
그렇다면, 이 Rewrite Map을 어떻게 Rewrite Rule에 매핑 시킬까요? 바로 새로운 Rule을 만들고, 그 Rule에 이 Map을 걸어 주는 형태로 완성됩니다.
”Add Rule”을 실행하고, Rule with rewrite map을 선택합니다.
이어서 Rule Action은 “Rewrite”, rewrite map은 당연히 조금 전에 위에서 생성한 “StaticRewrite”를 선택 가능합니다.
그렇다면 확인을 위해 web.config를 열어 볼까요?
1: <rewrite>
2: <rewriteMaps>
3: <rewriteMap name="StaticRewrite">
4: <add key="/article1" value="/article.aspx?id=1&title=some-title" />
5: <add key="/some-title" value="/article.aspx?id=1&title=some-title" />
6: <add key="/post/some-title.html" value="/article.aspx?id=1&title=some-title" />
7: </rewriteMap>
8: </rewriteMaps>
9: <rules>
10: <rule name="Rewrite rule1 for StaticRewrite">
11: <match url=".*" />
12: <conditions>
13: <add input="{StaticRewrite:{REQUEST_URI}}" pattern="(.+)" />
14: </conditions>
15: <action type="Rewrite" url="{C:1}" appendQueryString="false" />
16: </rule>
17: </rules>
18: </rewrite>
10번 라인부터 16번 라인까지 보시면 Rewrite Map을 처리하는 Rule을 확인 가능하지요.
11번 라인의 “<match url=".*" />”은 모든 인입되는 URL에 대해서 동작한다는 의미 입니다.
13번 라인의 내용은 StaticRewrite Map에서 리턴되는 값이 빈 문자열이 아니라는 조건 처리 입니다.
15번 라인의 Action은 이 Rewrite Map에서 나온 결과값으로 URL을 Rewrite하는 동작을 수행하라는 의미 입니다.
그렇다면, 우리가 만든 Rewrite Map이 잘 동작하는지 확인을 위해 테스트를 해 볼까요.
http://localhost/article1
http://localhost/some-title
http://localhost/post/some-title.html
위의 테스트 작업을 수행하면 아래처럼 결과가 잘 나오는 것을 확인 가능할 것입니다.
그렇다면, “Redirect”는 어떻게 처리 가능할까요? Rewrite와 같습니다.
Rewrite Map을 Rule에 매핑하던 화면 기억 나시는지요? 여기에서 Rewrite 대신 Redirect를 선택하시면 됩니다.
마침 - Rewrite Map을 왜 사용하는가?
모든 URL 처리가 패턴 규칙으로 매핑 가능하지는 않습니다. 이렇게, URL 처리를 위한 패턴매칭 규칙(Rule)을 적용하기 어려운 여러 URL들에 대해 새로운 URL로 여럿 정의하려 할 경우에 Rewrite Map을 이용해 1:1로 매핑하는 처리를 이용하면 유용합니다. 단순 URL Rewrite Rule이 생성되는 것은 줄이면서 효율적으로 Rewrite 처리가 가능해지는 장점이 있는 것이지요. 물론 단순 Rule들을 나열하는 것보다 부하를 줄일 수도 있다고 합니다.
이렇게 해서 전반적인 URL Rewrite 기능에 대해 알아 보았습니다. URL Rewrite만 해도 유용한 Fancy URL 제작 기능부터 보안 기능 등 다양한 내용이 포함되어 있는 것 같습니다. 이 외에도 IIS에 대한 수많은 유용한 기능들이 있는데요, IISKOREA 팀분들과 차근차근 좋은 내용으로 풀어 나가 보도록 하겠습니다. 감사합니다.
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)
참고자료
서버주무르기 - IIS 7, URL Rewrite Module (URL 재작성 모듈)
Using Rewrite Maps in URL Rewrite Module
Using URL Rewrite Module
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 ASP.NET 라우팅(Routing)과 URL Rewrite에 대한 내용입니다.
ASP.NET 라우팅이란 무엇인가?
URL Rewrite와 마찬가지로, ASP.NET에서 사용자 & 검색엔진 친화적인 URL을 이용 가능하도록 돕는 ASP.NET의 기능입니다. 대략 느낌이 오는 것처럼 .NET Managed Code와 Native Code의 차이점이 주가 될 것 같은 느낌이 들지요?
URL Rewrite는 왼쪽에서 보는 것처럼, HTTP 처리 파이프라인 중 “Begin Request” 영역에서 주로 처리되는 Native 처리기능을 수행합니다. 바꿔말하자면, HTTP 요청을 처리하는 절차들 중에서 비교적 앞쪽에서 일종의 Filter 형태로 동작하게 됩니다. ASP.NET 라우팅은 Managed Code로 작성되며 Resove Cache 처리와 Map Handler 처리에서 이루어지고 Execute Handler에서 역시 처리되게 됩니다. ASP.NET 라우팅 관련 내용은 아래 내용을 참고해 보세요.
링크 : ASP.NET 라우팅에 대한 상세한 정보
그렇다면, ASP.NET 라우팅과 URL Rewrite의 차이점은 무엇일까? 언제 URL Rewrite를 이용해아 하는지?
- URL Rewrite는 ASP, ASP.NET, PHP나 정적 HTML 파일(Static HTML file)과 같은 웹서버에서 처리되는 파일들에 대해서 동작 가능하다. 그러나, ASP.NET 라우팅은 오직 ASP.NET 웹 어플리케이션으로만 동작 가능하다.
- URL Rewrite는 도메인명, HTTP 헤더, 서버변수(Server variables)에 대해서 처리 가능하나, ASP.NET 라우팅은 URL Path와 HTTP Method 헤더에 대해서만 처리 가능하다.
- URL rewrite는 HTTP 리다이렉트(Redirect), 커스텀 상태코드(Custome status code), 요청 중단(Abort Request)가 가능하나, ASP.NET 라우팅은 이러한 처리를 하지 못한다.
- URL Rewrite는 제공되는 정해진 Rule 엔진(정규표현식 등)만을 이용해 처리 가능해 Rule에 대한 확장이 어려우나 ASP.NET 라우팅은 개발자가 얼마든지 기능을 확장하거나 커스터마이징이 가능하다.
이렇게 ASP.NET의 라우팅과 URL Rewrite의 차이점에 대해서 알아 보았습니다. 비슷한 역할을 하는 두 서비스는 각각 사용처가 어쩌면 명확해 보이네요. 감사합니다.
참조 : IIS URL Rewriting and ASP.NET routing
지난 포스트 링크 URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치 URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성 URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 IIS7의 URL Rewrite 기능 세번째 시간으로, 요청필터링(Request Filtering) 기능과 URL Rewrite 기능에 대한 비교 내용입니다.
요청 필터링(Request Filtering)이 뭔가요?
요청 필터링은 IIS7에서 기본적으로 제공하는 보안 기능입니다. 혹시 아실지 모르겠습니다만, 이전에는 URLScan 이라는 녀석의 기능과 비슷하기도 합니다. 간단히 이녀석이 수행하는 기능은 IIS의 내장된 보안 기능으로 특정 URL이 들어올 경우 필터링, 특정 파일 확장자(Extension)을 요청할 경우 필터링, ASP.NET의 App_code와 같은 폴더에 대한 접근 필터링, HTTP 헤더의 길이 제한, HTTP의 특정한 verb에 대한 필터링 등이 가능합니다.
아울러, 요청 필터링은 이러한 보안 필터링 기능을 웹사이트단위 또는 웹서버 전체에 대해서 적용 가능합니다. 기존 URLScan3.0 버젼까지와는 약간 틀린 부분이지요.
참고로, 기존의 URLScan 3.0 버젼까지는 이러한 보안 기능들이 전체 웹서버에 대해서 적용되었습니다.
하지만, URLScan3.1부터는 보안기능들을 웹사이트 단위로도 구성이 가능하다고 하니 도움 되시길 바랍니다.
URLScan3.1 정보
요청 필터링에 대한 내용은 아래를 참고 하세요.
How to Use Request Filtering
Request Filtering <requestFiltering>
또 참고로, 요청 필터링을 IIS관리자에서 실행해 보고 싶으시다면?
먼저, IIS Administration Pack을 설치합니다.
다운로드 링크에 가시면 웹 플랫폼 설치 관리자가 실행되고 여기에서 “관리 팩 1.0”을 설치하세요.
그러면 IIS 관리자에서 Request Filtering을 수행 가능합니다.
자~ 그렇다면 다시 오늘의 주제인 요청 필터링과 URL Rewrite의 기능 비교에 대해서 알아 보도록 하지요.
요청 필터링과 URL Rewrite의 비슷한점은 무엇인가요?
두가지 기능 모두 URL이나 HTTP Request에 대한 보안 기능을 적용 가능하다는 점에서는 유사합니다. 하지만 아래와 같은 차이점이 있지요.
요청필터링은 순수한 보안 목적으로 제작되었습니다. URL Rewrite는 범용적인 URL 처리를 위한 목적으로 제작되었으며, URL Rewrite가 제공하는 보안 기능은 여러가지 기능들 중의 일부입니다.
간략히 표현된 요청 필터링과 URL Rewrite의 비교표 입니다. – 각각의 보안 기능들에 대해서 차이점이 존재 합니다.
그렇다면, 성능적인 측면에서는 어떨까요?
성능 측면에서는 두가지 기술 모두 영향을 줄 정도로 부하가 높지는 않습니다. 하지만, URL Rewrite의 경우 정규표현식을 이용하기 때문에 요청 필터링 보다는 약간 더 높은 시스템 리소스를 이용하게 됩니다. 요청 핕터링은 문자열에 대한 추출 작업만을 진행해 비교하기 때문에 시스템 리소스를 상대적으로 덜 사용하게 됩니다.
URL Rewrite와 요청 핕터링은 각각의 목적에 맞는 보안 기능들이 있으며 필요할 경우 두 기능을 조합해서 이용도 가능합니다. 많은 도움 되시길 바랍니다.
지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
지난 포스트 링크
http://www.iiskorea.net/entry/URL-Rewrite-11-URL-재작성-1-소개-및-설치
지난 시간에 간략히 URL Rewrite의 역할과 기능을 소개해 드렸습니다. 이번 시간에는 URL Rewrtie를 실제로 사용해 보고 어떻게 이용하는지 간략히 설명 드리려고 합니다.
먼저, URL Rewrite를 왜 써야 합니까?
그렇다면 왜 URL Rewrite를 알아야 하는가? 간단하다, 다양한 웹 어플리케이션인 블로그나 CMS, 쇼핑몰 등도 Fancy URL과 Permanent Link가 제공하는 장점들을 기본적으로 제공하고 있다.
- XpressEngine
- Textyle
- Textcube
국내에서 가장 많이 사용되는 오픈소스 웹 어플리케이션들이며 모두 Rewrite 동작에 기반한 Fancy URL을 제공하고 있다. IIS7에서 역시 이러한 어플리케이션들을 구동시킬 수 있으며, 당연히 Rewrite 동작들을 어플리케이션들에 맞게 제공 가능하다. - Rewrite는 먼나라 이야기가 아니라, IIS를 운영하기 위한 필수적인 확장 기능이며, 당연히 IIS의 URL Rewrite는 국내 오픈소스 어플리케이션에서 제공하는 Rewrite Rule을 그대로 이용 가능하다.
Rewrite Rule 따라해보기
간단히 아래와 같은 역할을 수행한다고 가정해 보자.
Fancy URL http://localhost/article/342/some-article-title 을
http://localhost/article.aspx?id=342&title=some-article-title 으로 변환 하는 것이 목표다. – 그냥 보기에도 어려워 보인다. 흠…
Fancy URL인 위의 구조는 사람이나 검색엔진에는 친화적인 URL이지만, 개발자가 어플리케이션에 의해 처리되는 Request들을 받아 처리하기에는 적절하지 못하다.
당연히 Rewrite를 통해 Fancy URL을 재작성(Rewrite)하는 과정이 필요하다. 어떻게 진행 할 수 있을까?
1: <%@ Page Language="C#" %>
2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3: <html xmlns="http://www.w3.org/1999/xhtml">
4: <head>
5: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
6: <title>URL Rewrite Module Test</title>
7: </head>
8: <body>
9: <h1>URL Rewrite Module Test Page</h1>
10: <table>
11: <tr>
12: <th>Server Variable</th>
13: <th>Value</th>
14: </tr>
15: <tr>
16: <td>Original URL: </td>
17: <td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td>
18: </tr>
19: <tr>
20: <td>Final URL: </td>
21: <td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>
22: </tr>
23: </table>
24: </body>
25: </html>
테스트를 위해 위와 같은 텍스트 파일을 생성하고, 파일 이름을 article.aspx 파일로 저장한다. 이후, IIS의 웹사이트 루트에 저장하도록 한다. 본인의 경우는 http://localhost/article.aspx 형태가 되도록 구성했다. 이어서 Rule을 작성해 보도록 하자.
그렇다면 Rule(규칙), Pattern(패턴), Action(동작)이란 무엇인가?
알아야할 세가지 키워드가 존재한다. Pattern은 URL의 패턴을 의미한다. 즉, URL이 abc.com/article/123/abcd 형태라고 한다면 서버의 DNS 주소 뒤에 article이 오고 숫자가 오고 문자가 오는 형태의 패턴이라고 말할 수 있다. 즉, 이런 패턴을 치환하는 동작이 바로 Action이라고 보면 된다. 이렇게 패턴에 따라 정의한 동작이 있는 것이 하나의 Rule이라고 보면 되며 이런 Rule들이 여러개 조건에 따라 존재할 수 있다. 이 Rule들을 관리하게 쉽게 돕는것이 바로 URL Rewrite라고 보면 된다.
URL Rewrite를 실행
웹사이트를 선택하고, 이렇게 URL Rewrite를 실행한다.
우측 상단의 Add Rule을 실행한다.
Blank Rule을 선택합니다. – 물론 필요할 경우 Template 등을 선택할 수도 있습니다.
이어서, 위와 같이 Rule을 구성합니다.
Pattern 부분을 주의해서 보시면
^article/([0-9]+)/([_0-9a-z-]+)
이런 내용이 보이는데요. 의미하는 바는
- 시작 문자열이 article로 시작되고
- 하나 이상의 숫자가 처음 “/” 부터 존재하고
- 하나 이상의 “_” 또는 “-” 또는 알파벳 문자열이 두번째 “/” 이후에 존재하는
패턴을 의미 합니다. 즉, 이런 패턴일 경우에만 이 Rule이 동작 하겠지요.
이어서 Action 부분을 주의해서 봐 보시면
article.aspx?id={R:1}&title={R:2}
이런 내용이 보이는데요. {R:1}은 Rewrite된 패턴의 첫번째 리턴값, {R:2}는 두번째 리턴값이 들어간다고 보시면 됩니다.
URL Rewrite의 Rule은 어디에 저장 되는가?
IIS는 똑똑하게도 이러한 Rule을 기본적으로 웹사이트 루트디렉토리에 포함된 web.config에 저장하게 된다. 만약, 시스템 전체에 적용되는 Rewrite Rule을 이용하고 싶을 경우에는 당연히 시스템에서 구성하면 되며, 시스템에 구성한 Rule은 applicationhost.config에 저장되며 모든 웹사이트가 상속받아 실행하게 된다. 그렇다면, web.config에 저장된 rewrite rule은 어떤 모습일까?
1: <rewrite>
2: <rules>
3: <rule name="Rewrite to article.aspx">
4: <match url="^article/([0-9]+)/([_0-9a-z-]+)" />
5: <action type="Rewrite" url="article.aspx?id={R:1}&title={R:2}" />
6: </rule>
7: </rules>
8: </rewrite>
이런 형태로 web.config에 저장된다. 즉, URL Rewrite 툴은 이런 Rule을 쉽게 제작하도록 도와주는 툴인 것이고, 실제 동작은 IIS의 Filter로 동작하게 되는 것이다. 그렇다면, URL Rewrite를 실행해 보면?
테스트 URL : http://localhost/article/234/some-title
이렇게 Rewrite가 처리되는 것을 볼 수 있다. Fancy URL에 대한 처리가 이렇게 가능해 진다. URL Rewrite는 이렇게 URL을 재작성해 어플리케이션에서 이용 가능하도록 URL을 재작성한다. URL “Redirect”는 어떨까? Redirect는 URL을 아예 옮겨버리는 작업을 진행하는 차이점이 있다.
URL Redirect를 테스트 해 보도록 하자.
이런 URL을 http://localhost/blog/some-other-title/543
http://localhost/article/543/some-other-title 이런 URL로 Redirect 시키려 할 경우를 진행해 보면
Pattern :
^blog/([_0-9a-z-]+)/([0-9]+)
Action 을 “Redirect”로 설정하고 Redirect URL을 아래처럼 구성한다.
테스트를 하기 위해 아래 링크를 수행한다.
http://localhost/blog/some-other-title/323
브라우져의 결과가 Redirect되어 http://localhost/article/323/some-other-title 로 이동된 것을 확인 가능하다.
Access Block Rule을 이용할 수도 있다.
이 경우는 해킹 시도와 같이 호스트명으로 처리되는 요청이 아닌 IP로 요청되는 시도를 blocking 할 수 있는 Rule이다. 즉, http://123.123.123.123 과 같은 형태의 요청을 기본적으로 block하고 http://abc.com 형태로 요청될 경우에만 통과 시키는 규칙으로 구성가능하다.(당연하겠지만, 이런 형태의 방어 처리는 IIS의 바인딩 설정이나 URL Scan 등에서도 처리 가능하다)
1: <rule name="Fail bad requests">
2: <match url=".*"/>
3: <conditions>
4: <add input="{HTTP_HOST}" pattern="localhost" negate="true" />
5: </conditions>
6: <action type="AbortRequest" />
7: </rule>
- 2번 라인은 Rule이 모든 URL 스트링에 대해서 동작하라는 의미이다.
- 4번 라인은 HTTP_HOST 값이 “localhost”이 아닐 경우에 대한 조건 처리이다.
- 6번 라인은 조건일 경우 요청을 취소 시키는 처리이다.
테스트를 위해서 http://127.0.0.1/article/234/some-title 과 같은 IP로 요청을 수행할 경우 Request가 중단되는 것을 확인 가능하다.
이렇게 URL Rewrite의 핵심적인 3개 기능을 알아 보았습니다.
1. Rewrite 기능을 이용한 URL 처리
2. Redirect 동작
3. Access Block 처리
다음 내용에서는
- 요청필터링과 URL Rewrite 비교
- ASP.NET 라우팅과 URL Rewrite 비교
- Apache의 mod_rewrite Rule을 Import해서 처리 가능한 URL Rewrite의 import 기능
- Rewrite Map 이용
내용에 대해서 알아 보도록 하겠습니다. 감사합니다.
[지난포스트 링크]
http://www.iiskorea.net/entry/URL-Rewrite-11-URL-재작성-1-소개-및-설치
마이크로소프트와 Red Hat이 가상화 관련 협업을 하겠다고 2009년 2월 선언한 후 8개월 만에 결과물이 나왔습니다. 마이크로소프트의 Windows Server 2008과 Red Hat Enterprise Linux 5.4가 함께 구동되는 가상화 환경에 대해 테스트와 검증이 완료되었습니다.
마이크로소프트와 Red Hat의 첫번째 대규모 협업이라는 점에서 큰 의미가 있습니다. 데이터센터, 엔터프라이즈 환경에서 단 하나의 운영체제로 구동되는 경우는 거의 없고, 이 기종 운영체제가 혼재되어 있는 상황을 감안할 때 기념비적인 사건이라고 말할 수 있을 것 같습니다. 이에 앞서 Novell의 SUSE Linux와는 이미 테스트 및 검증이 완료되어 있기 때문에 리눅스와 상호운용성이 완성 단계에 이르렀습니다. 이외에도 7월에 리눅스 커널을 위한 가상화 디바이스 드라이버 개발을 지원하기 위해 마이크로소프트가 코드를 무상으로 제공한 바 있습니다.
이번에 인증된 부분은 다음과 같습니다.
1. Kernel Virtual Machine(KVM) Hypervisor를 사용하는 Red Hat Enterprise Linux 5.4와 Windows Server 2003, 2008, Windows Server 2008 R2 게스트
2. Windows Server 2008 Hyper-V, Microsoft Hyper-V Server 2008, Windows Server 2008 R2 Hyper0V와 Red Hat Enterprise Linux 5.2, 5.3, 5.4
위 인증된 가상화 소프트웨어 상에서 구동되는 선별된 애플리케이션들에 대해 기술지원을 제공합니다. 마이크로소프트 애플리케이션 중 BizTalk 서버, Exchange 서버, Sharepoint 서버가 포함되며 이후에 추가될 예정입니다. Hyper-V 위에서 구동되는 Red Hat의 JBoss Enterprise Middleware의 경우도 기술지원을 받을 수 있습니다.
Red Hat 엔터프라이즈 리눅스 구독을 하고 있는 고객, Windows Server 2008 기술지원 계약을 맺고 있는 고객은 모두 기술지원을 받을 수 있고, 계약이 없는 고객은 지원이 필요할 때 마다 Incident를 별도로 구매할 수 있습니다.
닷넷과 자바. 이 두 플랫폼은 당분간 우리 개발자 곁을 떠나기 쉽지 않을 것 같다. 고인 물인 금방 썩듯이 주변에서 끊임없이 자극을 주는 경쟁자가 있을 때 상호간 건전한 발전을 기대할 수 있다. 개발 플랫폼도 마찬가지다. 닷넷과 자바는 늘 서로의 장점을 수용하여 (즉, 끊임없이 베꼐가며) 개발자의 요구사항, 시장의 기대에 부응하는 방향으로 발전해 가고 있다. 하여 많은 영역에서 닷넷과 자바는 경쟁의 대상으로, 비교의 대상으로 여겨지며, 이것이 고객의 입장에서도 자신이 선정한 플랫폼이 다른 경쟁 상대에 비해 가지는 상대적인 우수함에 만족하며 때로는 안도해하는 것이다.
이번 글에서는 지난 3월 마이크로소프트 MSDN 싸이트에 공개된 “Bendhmarking IBM WebSphere 7 on IBM Power 6 and AIX vs. Microsoft .NET on Hewlett Packard BladeSystem and Wndows Server 2008”이라는 벤치마크 리포트를 소개하고자 한다.
닷넷과 자바에 대한 다양한 각도의 비교는 예전부터 있어 왔다. EJB가 처음 세상에 나왔을때 가장 먼저 한 것중의 하나가 바로 Microsoft MTS와의 비교를 통해 EJB가 지원하는 각종 declarative한 시스템 서비스들이 어떻게 MTS와 유사한지, 트랜잭션의 옵션이나 Isolation level이 MTS와 같은 것은 무엇이고 다른 것이 무엇인지를 통해 시장에 접근하기도 했었다. 또한 현재에도 왕성하게 활동하고 있는 Middleware company (http://theserverside.com / http://theserverside.net)는 웹 서비스 관련하여 자바가 웹 서비스를 지원하기 시작한 초기에 시차를 두고 두번에 걸쳐 자바와 닷넷의 표준 웹 서비스 성능 및 확장성에 대해 벤치마크를 진행하여 자바 개발자들의 마음을 아프게 하기도 했다. (그 당시 아마 현재에도 middleware company는 자바 친화적인 기업이다. 벤치마크 결과는 그 당시 가장 빠른 WAS에서의 성능도 닷넷에 비해 최고 열배, 두 번째에는 두 세배 느린 성능을 보여줬었다.) 본 리포트는 IBM이 만든 Trader라는 샘플 애플리케이션의 닷넷 버전을 만들어 IBM WebSphere 기반의 Java EE 5와 Microsoft .NET 3.5에서 세가지 측면에서 성능을 비교하였다. 즉, 일반 웹 애플리케이션 구현시 성능 비교 (논란의 여지를 없애기 위해 EJB를 사용치 않고, JSP/Servlet/JDBC direct call 이용), 미들티어 웹 서비스 성능 비교, 그리고 마지막은 썬마이크로시스템이 고안한 웹 서비스 스택(엔진자체)의 성능(우수성) 검증 툴인 WSTest를 통해 닷넷과 자바(WebSphere7) 웹 서비스 엔진의 성능 비교를 진행했다.
결론적으로 웹 애플리케이션 구축할 경우 윈도우 기반의 닷넷 시스템이 IBM Power 570 / AIX 5.3 / WebSphere7 기반의 자바 시스템에 비해 가격은 1/5 수준으로 성능은 57% 더 나은 결과를 보여주었고, WebSphere의 경우에도 AIX 에서보다 윈도우 서버에서 가격은 1/3 수준으로 성능은 37% 더 나은 시스템을 제공할 수 있음을 보여준다.
웹 서비스를 구축할 경우에도, Windows Server 2008 기반의 닷넷 시스템이 IBM Power 570 기반의 WebSphere 7 기반 Java EE 시스템에 비해서 가격은 1/5 수준으로 성능은 111% 더 나은 웹 서비스를 구축할 수 있음을 알 수 있다. 같은 WebSphere 7 기반의 자바 웹 서비스 시스템 구축의 경우에도 Windows Server 2008 / HP BladeSystem C7000 위에서 구동하는 것이 IBM AIX 5.3 / IBM Power 570 위에서 구동하는 것에 비해가격은 1/3 수준으로 성능은 37% 더 나은 결과를 제공할 수 있음을 알 수 있다.
벤치마크 자체에 대한 좀 더 상세한 조건 및 벤치마크 방법, 분석 결과 등은 MSDN 싸이트에서 결과 리포트에서 직접 확인하는 것이 좋을 듯 하다. 여기에는 이전 비교시 작성한 각종 기술문서들이 있어 단지 이 벤치마크 만이 아닌 일반적인 사항에서 사용할수 있는 기법들도 찾을 수 있다. 또한 다른 개발자들이 이 리포트에 대해 어떻게 생각하고 있는지 포럼에서 돌러볼 수도 있다.
원문보다 느낌은 덜하지만 한글화되고 요약된 것을 원한다면 이 블로그 포스트를 참고하시길..
URL Rewrite의 기본 역할? 어디에 쓰는 건가요?
URL Rewrite는 사용자가 기억하기 더 쉽고, 검색 엔진에 의해 검색될 수 있도록 하는 URL을 만들어 주는 IIS의 확장기능(Extension) 입니다. Rewrite 본연의 기능을 보시려면, 아래의 화면을 통해 말씀 드리겠습니다.
이렇게 복잡한 URL 링크는 사용자나 검색엔진에게 친화적이지 않습니다. 보통 이런 URL을 Dirty Link 라고도 표현하는데요, 이를 보완하기 위해 아래에 보시는 깔끔한 링크처럼 사용자 편의적이고 검색엔진에 친화적인 URL로 만들어주는(Fancy URL) 기능이 바로 URL Rewrite가 지원하는 대표 기능입니다.(느끼시는 것처럼 그 외에도 다양하고 많은 기능들을 제공합니다.)
Rewrite에서 말하는 Rule 이란 무엇입니까?
이렇게, IIS Rewrite에서 특정 조건의 URL을 Fancy URL로 바꿔주는 하나하나의 규칙을 “Rule” 이라고 표현합니다.
Rule template이나 rewrite map 등을 쉽게 구축 가능하도록 돕는 이 기능은 HTTP 헤더의 URL과 서버변수(Server variable) 등에 대해서 처리가 가능하며 재정의된 응답을 사용자에게 내려 보내거나 HTTP 요청을 중지하는 다양한 규칙을 만들 수도 있으며, 보안 기능 등에도 활용 가능합니다. ? 차근차근 보여 드리겠습니다.
URL Rewrite의 주요한 특징 및 기능
- Rule을 기반으로 동작해 다양한 로직이나 표현식, 개발 루틴 등을 이용 가능해 강력한 rewrite 처리가 가능합니다.
- 정규 표현식을 이용 가능합니다. ECMA-262 호환 정규 표현식 구문을 사용 가능합니다.
- 와일드카드(wild card) 패턴 매칭을 이용 가능합니다.
- Rewrite는 HTTP 헤더에 기반한 URL과 서버변수(Server variable)에 대해서 처리합니다.
- 다양한 rule 동작을 제공해, 단순한 rewriting 뿐만 아니라, HTTP 리다이렉트, HTTP 요청 중지, 커스텀 상태 코드를 클라이언트에 전달하는 처리 역시 가능합니다.
- IIS 커널 모드와 User 모드 출력 캐시를 지원해 빠른 성능을 제공합니다.
- 문자열 처리 함수를 제공합니다. 기본 포함된 문자열 처리 함수들과 다양한 변환 함수 등의 Action 처리가 가능합니다.
- Rewrite map을 지원합니다. 이는 다수의 매핑 rule에 대한 정의가 편리합니다. GUI로도 생성 가능합니다.
- Rule 템플릿을 지원
- IIS의 관리툴과 완벽하게 상호 작용해 관리의 편의성이 높고 GUI 기반의 rule 생성, 체크 테스트,디버깅 등을 도와 줍니다.
- mod_rewrite의 rule도 손쉽게 GUI를 통해 import를 할 수 있습니다.
- 국내에서 가장 많이 사용되는 오픈소스 웹 어플리케이션의 rewrite rule도 완벽하게 지원합니다. 요것도 차근차근 보여 드리겠습니다.
URL Rewrite 다운로드
개인적으로는 웹 플랫폼 인스톨러(Web Platform Installer)-WPI 2.0을 이용해 다운로드 하실 것을 추천해 드립니다.
웹 플랫폼 인스톨러 http://www.microsoft.com/web/downloads/platform.aspx
웹 플랫폼 인스톨러는 윈도우 서버에서 사용되는 모든 웹 플랫폼 프레임워크, 웹 어플리케이션, IIS 확장 기능 및 SQL서버와 같은 제품 등에 대한 설치와 구성을 돕는 최고의 툴입니다. ? IIS로 웹 어플리케이션을 구동하기 위한 최적의 툴이지요.
웹플랫폼 / 웹서버의 사용자 지정 / 일반 HTTP 기능에서 설치 가능합니다.
또는 http://www.iis.net/extensions/URLRewrite 링크에서 다운로드 가능합니다. X86용과 X64용이 모두 제공되는 적절한 파일을 받으시면 됩니다.
더 많은 다양한 IIS 관련 강좌는 IISKOREA 커뮤니티 http://www.iiskorea.net 에서 확인 하실 수 있습니다.
웹을 위한 모든 것이라는 주제로 REMIX09가 2009년 9월 24일 코엑스 인터컨티넨탈 호텔에서 오후 1시부터 시작 됩니다. 2007년과 2008년에 REMIX에 참석하셨던 분들께서는 아시겠지만, REMIX는 기존의 일반적인 컨퍼런스와는 차별화된 신선하고 의미 있는 내용들을 다루어 왔습니다. 올해도 예외가 아니며, 키 노트에서부터 각각 트랙에 이르기까지 웹 업계에 계신 분들이라면 놓치지 말아야 할 내용들을 가득 준비 했습니다.
참석하셔서, 플랫폼에서 개발, 디자인까지 웹을 위한 마이크로소프트의 제안을 만나보시길 바랍니다. 참가 등록 및 세부 내용은 아래 이미지 클릭 후 나오는 REMIX09 사이트를 참고하세요.
(아래 내용은 Smooth Streaming의 이해를 위해서 Silverlight 사이트에 있는 영문을 한글로 번역한 내용 입니다.)
Smooth Streaming(스무드 스트리밍)을 사용하면 더 오랜 시간 영상을 시청할 수 있습니다. 이유는 사용자의 변화하는 네트워크 및 CPU 상황에 맞게 화질을 조정할 수 있어서 끊김 없이 영상을 제공할 수 있기 때문입니다. HTTP 기반의 adaptive(상황에 맞게 변화하는) 스트리밍을 통해서 최소한의 버퍼 링과 빠른 속도의 재생 시작을 경험 할 수 있습니다.
Smooth Streaming은 HTTP프로토콜을 통해서 Silverlight Client 로 Adaptive 스트리밍 미디어를 전송하는 IIS 7.0 미디어 서비스의 새로운 extension입니다.
Smooth Streaming은 동적으로 현재의 상태를 진단하고, 끊임없이 변화 합니다. 이는 실시간으로 CPU 와 로컬 네트웍 상태에 기반해서 최적 화질의 미디어를 실버라이트 플레이어가 받을 수 있도록 하는 것을 뜻합니다. 높은 네트워크 대역폭 가진 사용자들은 HD 급의 스트리밍을 경험할 수 있으며, 낮은 네트워크 대역폭을 가진 사용자들은 현 상황에서 최적화된 스트리밍을 이용할 수 있습니다. 이것을 통해 사용자들이 끊김 없이 미디어를 즐길 수 있고, 더 오랜 시간 미디어를 이용하게 됩니다.
미디어 업체들은 사용자들이 HD(720p+) 급의 비디오를 쉽고 끊김 없이 볼 수 있게 됨으로써 시청 시간을 늘어나고 이를 이용해서 광고 및 구독으로 얻는 수익을 증대 시킬 수 있습니다. 또한, Smooth Streaming을 이용하면 현재 구축된 방대한 규모의 HTTP 방식을 활용할 수 있습니다. 큰 규모의 스트리밍 네트워크 들은 HTTP 방식 외에는 작은 규모로만 가지고 있으며, 이는 HTTP 방식 이외에는 네트워크 트래픽이 가득 차게 되면 인기 있는 컨텐츠의 접속이 제한 될 수도 있기 때문입니다.
실제 Smooth Streaming 되는 것 체험해 볼 수 있는 사이트
라이브 Smooth Streaming은 실시간 스트리밍을 비디오를 감상 하듯이 앞 뒤로 이동하면서 이용하실 수 있습니다. 실시간 라이브 방송이 진행 되는 사이에 접속해서도 시작 부분의 영상이나 주요 부분 들의 영상을 쉽게 찾아 보실 수 있습니다.
Smooth Streaming 의 기능과 IIS Media Services 를 더 자세하게 알아보기
Smooth Streaming 에 관련한 모든 기술 내용이 담긴 백서보기
