Inside Microsoft.comASP.NET의 관리 및 위임
Jeff Toews
microsoft.com 웹 인프라는 거의 대부분 .NET Framework 2.0에서 실행됩니다. microsoft.com 운영 팀의 주요 웹 관리 과제 중 하나는 ASP.NET을 올바르게 구성하는 것인데, 운영 팀은 완벽한 설정을 만들기 위해 노력하면서 많은 것을 배우고 있습니다.
구성을 올바르게 설정하려면 web.config 및 machine.config 파일의 다양한 구성 섹션을 잘 다룰 수 있어야 하며 설정의 의미를 알아야 합니다. 설정을 다루는 방법과 그 의미를 잘 이해하려면 예제를 살펴보는 것이 좋습니다. 본 칼럼에서는 microsoft.com을 실행하는 서버를 실제로 구성했던 경험을 통해 얻은 몇 가지 유용한 정보를 소개하고자 합니다.
1. 올바른 컴파일 스위치 설정
ASP.NET 기반 응용 프로그램을 프로덕션 환경에 배포할 경우 실수이든 의도적이든 응용 프로그램의 web.config 파일에서 compilation debug 특성이 다음과 같이 true로 설정되어 있어서는 안 됩니다.
<compilation debug="true" />
관리해야 할 웹 응용 프로그램이 많은, 아주 복잡한 환경에서는 ASP.NET 구성 제어 메커니즘을 사용하여 이런 일이 생기지 않도록 방지할 수 있습니다. 이 주제에 대해서는 잠시 후에 자세히 다루겠습니다.
개별 .aspx 파일에 있는 페이지별 디버깅 특성도 다음과 같이 true로 설정되어 있어서는 안 됩니다.
<%@ Page debug="true" %>
게시 내용이 많은 복잡한 환경에서는 페이지를 게시하기 전에 이 설정을 모든 .aspx 페이지에서 제거하기가 쉽지 않습니다. 따라서 전체 환경에서 이런 상황이 발생하는 것을 방지할 수 있는 방법이 필요합니다.
이 설정으로 웹 응용 프로그램을 컴파일하면 정식 바이너리 대신 디버그 바이너리가 생성됩니다. 또한 코드가 최적화되지 않아서 성능이 떨어집니다. 게다가 디버그 설정에서는 시간 제한이 없으므로 ASP.NET 요청이 시간 초과되지 않습니다. 프로덕션 환경에서 디버그 버전을 사용하는 것은 문을 열어 해커를 초대하는 것과 같습니다.
다행히 Microsoft® .NET Framework 2.0에서는 machine.config에 대한 새로운 배포 설정을 사용하여 ASP.NET에게 web.config 파일이나 특정 페이지 특성의 지침에 상관없이 디버그 기능, 추적 출력 및 ASP.NET 오류 메시지 표시(로컬 호스트나 원격으로)를 비활성화하도록 지시할 수 있습니다. 예를 들면 다음과 같습니다.
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
추적 출력을 비활성화하고 자세한 ASP.NET 오류 메시지를 원격에서 비활성화할 수 있다는 마지막 두 개의 장점은 반드시 채택해야 하는 최선의 보안 방법입니다. 이 방법을 채택하지 않는다면, 자신의 응용 프로그램의 내부를 마음껏 이용하라고 전세계에 드러내는 것이나 마찬가지입니다.
이 주제와 관련하여 중요한 사실이 하나 더 있습니다. 루트 web.config 파일의 <location allowOverride="false"> 내에서 <system.web><compilation> debug 특성을 잠그거나 lockItems 특성을 사용하면 응용 프로그램 구성 계층 하위에 있는 web.config 파일에서 디버그 설정을 활성화할 수 없게 됩니다. 그렇지만 개별 .aspx 페이지에서 페이지 특성의 디버그 모드는 활성화할 수 있습니다. 모든 수준에서 ASP.NET 디버그 기능을 완전히 비활성화할 수 있는 유일한 방법은 deployment retail 스위치뿐입니다.
deployment retail 스위치를 true로 설정하는 것은 공식 프로덕션 서버를 사용하는 회사에서 응용 프로그램을 보안 정보 누출 없이 언제나 최상의 성능으로 실행하기 위해 지켜야 할 최선의 방법입니다. 앞에서 설명했듯이 이 스위치는 ASP.NET 팀에 전달된 피드백을 직접적으로 반영하여 ASP.NET 2.0에서 새로 개발된 것입니다.
이와는 반대로 개발자가 웹 응용 프로그램을 디버그해야 하는 내부 프리프로덕션 환경에서는 deployment retail 설정을 사용해서는 안 됩니다. 단지, 프리프로덕션 루트 web.config 파일에서 <compilation debug="false">를 설정한 다음 개별 응용 프로그램의 web.config 파일이나 .aspx 페이지 특성에서 이 값을 다시 정의할 수 있도록 허용하기만 하십시오.
2. ASP.NET 2.0에서 보통 신뢰 사용
사이트나 응용 프로그램을 ASP.NET 2.0으로 마이그레이션한 이후에도 microsoft.com의 다른 많은 사이트와 마찬가지로 여전히 완전 또는 높은 신뢰 수준을 사용하고 있었다면 보통 신뢰 수준에서 현재 어떤 작업을 수행할 수 있는지 다시 한번 살펴보십시오. 예를 들어 제한된 WebPermission을 사용하면 응용 프로그램은 <trust> 요소에 정의된 단 하나의 주소나 주소 범위와만 통신할 수 있습니다. 따라서 이를 통해, 원격에서 호출할 수 있는 승인된 외부 사이트 및 주소 범위 목록을 제어하고 관리할 수 있습니다. 이는 보안을 위해 아주 유용합니다.
FileIOPermission도 역시 제한됩니다. 즉, 응용 프로그램의 코드에서는 가상 디렉터리 계층 구조에 있는 파일에만 액세스할 수 있습니다. 보통 신뢰 수준에서는 기본적으로 가상 디렉터리 계층 구조에 대해서만 읽기, 쓰기, 추가 및 PathDiscovery 권한이 각 응용 프로그램에 부여됩니다. 따라서 많은 응용 프로그램이 호스트되는 공유 웹 환경에서 매우 중요한 문제인 임의 파일 I/O 액세스를 막을 수 있습니다.
또 하나의 이점은 비관리 코드 사용 권한이 제거된다는 것입니다. 이는 레거시 구성 요소의 사용을 막을 수 있다는 것을 뜻하는데, 이 방법은 Aspcompat 페이지 특성을 사용하지 못하게 하는 가장 쉬운 방법입니다. Aspcompat를 true로 설정하면 페이지의 성능이 저하될 수 있습니다.
ASP.NET 2.0에서 보통 신뢰를 사용하면 관리자가 이전의 기본 제한 각각에 대해 사용자 지정 예외를 만들 수 있기 때문에 융통성 면에서 상당히 바람직합니다. ASP.NET 1.1에는 이러한 융통성이 없었습니다. ASP.NET 2.0에서 보통 신뢰를 사용하는 것이 ASP.NET 1.1보다 쉬운 또 다른 이유는 Microsoft SQL Server™ 데이터베이스에 액세스할 수 있기 때문입니다.
따라서 동일한 서버에서 여러 응용 프로그램을 호스트하는 경우 코드 액세스 보안과 보통 신뢰 수준을 사용하여 응용 프로그램을 격리시킬 수 있습니다. 루트 web.config 파일에서 <location allowOverride="false"> 태그를 사용하여 신뢰 수준을 설정한 뒤 잠그는 방법을 통해 서버의 모든 웹 응용 프로그램에 대한 보안 정책을 설정할 수 있습니다. 그림 1과 같이 allowOverride="false"를 설정하면 개별 개발자가 응용 프로그램의 web.config 파일에서 보통 신뢰 정책 설정을 다시 정의할 수 없습니다.
Figure 1 신뢰 설정
<configuration>
<location allowOverride="false">
<system.web>
<securityPolicy>
<trustLevel name="Full" policyFile="internal" />
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
<trustLevel name="Low" policyFile="web_lowtrust.config" />
<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
</securityPolicy>
<trust level="Medium" originUrl="" />
</system.web>
</location>
</configuration>
ASP.NET 2.0에서 보통 신뢰를 사용하는 방법에 대한 자세한 내용은 "How To: Use Medium Trust in ASP.NET 2.0"(영문)을 참조하십시오.
3. 지정된 파일 형식의 다운로드 제한
서버에는 원치 않는 사람 손에 들어가면 절대 안 되는 형식의 파일이 있습니다. 다행히 ASP.NET은 기본적으로 ASP.NET 응용 프로그램에서 사용하는 여러 가지 다양한 형식의 파일에 대한 요청을 가로채서 중지하도록 구성되어 있습니다. 이러한 파일 형식으로는 응용 프로그램의 소스 코드가 저장된 .config 파일과 .cs 파일이 있습니다. ASP.NET에서는 이 두 가지 형식의 파일을 System.Web.HttpForbiddenHandler에 연결하여 파일 보안을 유지합니다. 이 핸들러는 호출될 경우 파일을 요청한 사용자에게 오류를 반환합니다. 실제로 이 메서드를 사용하여 파일 형식을 제한할 수 있습니다.
예를 들어 microsoft.com 사이트에서 루트 web.config 파일의 <system.web><httpHandlers> 섹션에 다음 항목을 추가하여 .asmx 형식의 파일을 사용하지 못하게 할 수 있습니다.
<add path="*.asmx" verb="*" type=
"System.Web.HttpForbiddenHandler" />
위의 예에 나타난 것처럼 <httpHandlers> 요소에서 <add> 하위 태그를 사용하여 차단하려는 파일 형식을 추가로 지정할 수 있습니다. verb 특성을 "*"로 설정하면 해당 파일 형식에 대한 모든 형식의 HTTP 요청이 차단됩니다. 차단하려는 파일 형식에 맞게 와일드카드 문자를 사용하여 path 특성을 정의합니다. 예를 들어 "*.mdb"를 지정할 수 있습니다. 마지막으로 type 특성을 "System.Web.HttpForbiddenHandler"로 설정합니다.
4. 신중하게 어셈블리 참조 추가
.NET Framework를 실행하는 각 웹 서버에는 GAC(전역 어셈블리 캐시)라는 시스템 전체에 걸친 코드 캐시가 있습니다. GAC에는 컴퓨터의 여러 응용 프로그램에서 공유하도록 특별히 지정된 어셈블리가 저장됩니다. 웹 서버에 있는 대부분의 사이트에서 액세스하지 않더라도 여러 다양한 응용 프로그램에서 참조할 필요가 있는 어셈블리의 경우 GAC에 추가하는 것이 좋습니다. 이 경우 성능/리소스 면에서 그다지 큰 부담을 주지 않으면서도, 서버에 있는 개별 응용 프로그램의 /bin 폴더에 흩어져 있는 어셈블리를 공유하지 않고 중앙 집중적으로 버전 제어를 관리할 수 있다는 이점이 있습니다.
그러나 어셈블리 참조를 루트 web.config에 추가해야 하는 시기에 대한 기준은 어셈블리를 GAC에 저장할 시기를 결정하는 기준보다 훨씬 엄격해야 합니다. 개별 응용 프로그램에서 실제로는 글로벌하지 않은 구성 요소에 대한 어셈블리 참조를 응용 프로그램의 web.config 파일에 추가하는 것이 이러한 어셈블리 참조를 루트 web.config 파일에 선언하는 것보다 성능 면에서 훨씬 바람직합니다. 이 경우 컴파일러에서 필요 없는 어셈블리를 로드하기 위해 시간을 낭비할 필요가 없기 때문에 웹 서버에 있는 모든 응용 프로그램의 페이지 로드 시간이 상당히 줄어듭니다. ASP.NET 컴파일러는 어셈블리가 GAC에 있기만 하면 응용 프로그램에 대한 어셈블리를 로드하지 않으며 어셈블리 참조가 appdomain이나 상위 응용 프로그램 범위에 있는 경우에만 어셈블리를 로드합니다. 결과적으로 microsoft.com에서 응용 프로그램 개발자는 응용 프로그램의 web.config 파일에 있는 <configuration><system.web><compilation><assemblies> 요소를 모든 Microsoft.com 환경에 대해 다시 정의할 수 있습니다.
보다 구체적으로 설명하자면, microsoft.com 프로덕션 및 스테이징 환경의 루트 web.config 파일에서는 <system.web><compilation> 노드의 모든 특성(debug, explicit, defaultLanguage 포함)이 잠겨 있으며 <assemblies> 요소를 제외한 모든 요소(buildProviders, expressionBuilders 등)가 잠겨 있습니다.
<compilation debug="false"
explicit="true" defaultLanguage="vb"
numRecompilesBeforeAppRestart="500"
lockAttributes="*" lockAllElementsExcept=
"assemblies" >
내부 프리프로덕션 환경의 경우 루트 web.config 파일에서 <system.web><compilation> 섹션이 잠겨 있지만 응용 프로그램 게시자는 특별히 <assemblies> 요소를 다시 정의할 수 있으며 문제 해결 및 디버깅을 위해 debug="false"도 다시 정의할 수 있습니다.
<compilation debug="false" explicit="true"
defaultLanguage="vb"
numRecompilesBeforeAppRestart="500"
lockAllAttributesExcept="debug"
lockAllElementsExcept="assemblies" >
여기에서 사용한 lock 특성은 ASP.NET 2.0의 새로운 기능입니다. 이러한 특성에 대한 자세한 내용과 사용 예는 "section 요소에서 상속된 일반 특성"을 참조하십시오.
5. 수동으로 설정한 MaxConnection 값 제거
거의 모든 microsoft.com 웹 사이트에는 원격 웹 서비스 클러스터를 호출하는 ASP.NET 응용 프로그램이 있습니다. 단일 웹 서버에서 동시에 호출할 수 있는 원격 웹 서비스의 최대 수는 machine.config 파일에 있는 <connectionManagement> 요소의 maxConnection 특성에 따라 결정됩니다. ASP.NET 1.1의 경우 maxConnection 값은 기본적으로 2로 설정됩니다. 수백 개의 응용 프로그램이 원격 서비스를 호출하는 microsoft.com과 같은 사이트의 경우 기존의 이 maxConnection 기본값은 너무 작습니다. 이 값으로 인해 ASP.NET 요청은 원격 웹 서비스 호출이 완료될 때까지 기다려야 했습니다. 대기 중인 ASP.NET 요청의 수는 perfmon 카운터 ASP.NET\Requests Queued를 통해 볼 수 있습니다. 원격 웹 서비스에 대한 동시 호출 수를 늘려서 사이트의 응용 프로그램 성능을 높이기 위해 쿼드 프로세서 웹 서버의 maxConnection 값을 40으로 늘렸습니다. 일반적으로 권장되는 maxConnection의 값은 CPU 수의 12배지만 상황에 맞게 이 값을 조정하십시오.
이제 ASP.NET 2.0에서는 maxConnection이 자동으로 확장 및 설정되므로 더 이상 수동으로 구성하지 않아도 됩니다. 이는 machine.config에 processModel 태그에 대한 새로운 구성 섹션이 추가되었기 때문입니다. processModel 요소에 대한 자세한 내용은 "processModel 요소(ASP.NET 설정 스키마))"를 참조하십시오.
<system.web>
<processModel autoConfig="true" />
</system.web>
machine.config에서 autoConfig가 활성화된 경우(기본 설정임) ASP.NET은 maxConnection 매개 변수의 값을 12n(여기서 n은 CPU의 수)으로 설정합니다. autoConfig를 활성화하면 maxWorkerThreads 매개 변수와 maxIoThreads 매개 변수가 100으로 설정되고 minFreeThreads 매개 변수가 88n으로 설정되며, minLocalRequestFreeThreads 매개 변수가 76n으로 설정되고 minWorkerThreads가 50으로 설정됩니다.
ASP.NET 2.0에서 autoConfig를 사용하여 maxConnection 및 목록의 다른 특성 값을 자동으로 확장 및 설정하기 전에 이러한 매개 변수에 대해 수동으로 설정된 값을 제거해야 합니다. 그렇지 않으면 수동으로 설정된 값이 autoConfig 값 대신 사용됩니다. maxConnection을 명시적으로 설정해야 하는 ASP.NET 1.1에서 기본값을 사용하는 ASP.NET 2.0으로 마이그레이션할 경우에는 이 점을 명심해야 합니다.
앞에서 나열한 maxConnection 및 다른 특성에 대한 autoConfig 값은 다소 임의적이기 때문에 모든 경우에 다 맞는다고 할 수는 없지만, 제가 확인한 바로는 거의 모든 microsoft.com 응용 프로그램에서 제대로 작동됩니다.
maxConnection 값을 수동으로 조정해야 하는 경우 이 값을 늘리면 CPU 사용률이 증가할 수 있으므로 주의해야 합니다. 이는 들어오는 요청이 순서를 기다리지 않고 바로 웹 서비스를 호출할 수 있기 때문에 ASP.NET에서 처리해야 하는 요청의 수가 많아질 수 있기 때문입니다. 물론 maxConnection 특성은 로컬 웹 서비스 호출에 영향을 주지 않고 원격 호출에만 영향을 준다는 점을 기억해야 합니다.
6. 처리되지 않은 예외 경계
ASP.NET 1.1 웹 사이트 또는 응용 프로그램을 ASP.NET 2.0으로 이전할 경우 처리되지 않은 예외에 대한 기본 정책의 주요 변경 사항을 알고 있으면 아주 유용합니다. .NET Framework 1.1 및 1.0의 경우 관리되는 스레드의 처리되지 않은 예외는 무시되었으며, 응용 프로그램이 계속 실행되었기 때문에 이러한 예외는 종종 숨겨진 채로 남아 있었습니다. 디버거를 사용하여 예외를 catch하지 않는 한, 문제를 인식할 수 없었습니다. 그러나 ASP.NET 2.0에서는 처리되지 않은 예외가 throw되면 ASP.NET 기반 응용 프로그램이 예기치 않게 종료됩니다. 기존의 기본 예외 처리 정책에서 무시되었던 처리되지 예외가 많은 경우에는 이 문제가 사이트나 응용 프로그램의 가용성에 심각한 영향을 줄 수 있습니다.
이 문제를 해결하는 가장 좋은 방법은 테스트를 통해 응용 프로그램에 있어서는 안 되는 처리되지 않은 예외를 제거하는 것입니다. 그러나 예외 발생 위치를 찾아내기 어려운 대규모 응용 프로그램을 마이그레이션하거나 철저한 개별 테스트가 불가능한 수많은 레거시 응용 프로그램을 마이그레이션해야 하는 경우 선택할 수 있는 몇 가지 방법이 있습니다. microsoft.com 웹 사이트를 ASP.NET 2.0으로 마이그레이션할 때, 처리되지 않은 예외 정책을 ASP.NET 1.1 및 ASP.NET 1.0에서 발생하는 기본 동작으로 다시 돌려 놓았습니다.
이 레거시 기본 예외 처리 동작을 활성화하려면 다음 코드를 aspnet.config 파일에 추가하십시오.
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy
enabled="true" />
</runtime>
</configuration>
이 코드는 다음 두 폴더에 있습니다.
%WINDIR%\Microsoft.NET\Framework\v2.0.50727(x86 또는 SYSWOW64 시스템) 및 %WINDIR%\Microsoft.NET\Framework64\v2.0.50727(x64 시스템)
위와 같이 코드를 변경하면 .NET Framework가 기존 1.1 및 1.0처럼 동작합니다. 하지만 이러한 변경으로 인해 응용 프로그램의 실제 버그가 감춰질 수 있으므로 이 방법은 임시방편으로만 사용해야 합니다. 그럼에도 불구하고 이 방법은 예기치 않은 작업자 프로세스 종료로 인해 발생하는 가용성 문제를 방지할 수 있는 간편한 방법입니다. 이 동작 변경에 대한 자세한 내용은 ".NET Framework 2.0에서 처리되지 않은 예외로 인해 ASP.NET 기반 응용 프로그램이 예기치 않게 종료된다"를 참조하십시오.
7. 올바른 프록시 서버 구성
웹 서버 관리자는 machine.config 파일의 <configuration><system.net><defaultProxy> 요소를 구성하여 인터넷에 대한 HTTP 요청을 사용하도록 프록시 서버를 지정할 수 있습니다.
microsoft.com 프로덕션 환경에서는 방화벽 클라이언트가 설치되지 않았으므로 시스템 기본 프록시를 사용하도록 <defaultProxy> 값을 구성하고, 실수로 내부 프록시 서버와 함께 web.config 파일을 게시할 가능성이 있는 응용 프로그램 개발자가 <defaultProxy> 요소를 다시 정의하지 못하도록 <location allowOverride="false"> 태그를 사용합니다. 이에 대한 코드 예는 다음과 같습니다.
<configuration>
<location allowOverride="false">
<system.net>
<defaultProxy>
<proxy usesystemdefault="true" />
</defaultProxy>
</system.net>
</location>
</configuration>
microsoft.com 내부 프리프로덕션 및 스테이징 환경에서는 usesystemdefault 특성을 false로 설정하고, bypassonlocal을 true로 설정하고, 프록시 bypasslist(그림 2 참조)를 추가했습니다. bypasslist는 지정된 프록시를 사용하지 않는 주소를 설명하는 정규식을 나열합니다. 그리고 개발자가 자신의 web.config 파일에서 자체 프록시 서버를 지정하지 못하도록 이 섹션은 <location allowOverride="false"> 태그 내에 포함됩니다. 이러한 프록시 서버는 주로 내부용이며 이들에 대한 호출은 페이지가 프로덕션에 게시될 때 중단됩니다. 프리프로덕션 또는 스테이징 환경에서 프록시 서버를 지정하려고 하면 런타임에 ASP.NET 오류가 발생하기 때문에 개발자는 이 구성을 프로덕션에 게시하기 전에 제거해야 합니다.
Figure 2 Bypasslist 설정
<configuration>
<location allowOverride="false">
<system.net>
<defaultProxy>
<proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />
<bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
</bypasslist>
</defaultProxy>
</system.net>
</location>
</configuration>
8. 사용자 지정 오류 노출 방지
앞에서 이미 언급했지만 프로덕션 환경에서는 웹 서버가 원격으로 자세한 ASP.NET 오류 메시지를 반환하지 않도록 해야 합니다.
microsoft.com 프로덕션 및 스테이징 환경의 루트 web.config 파일에는 <configuration><system.web><customErrors> mode 특성이 RemoteOnly로 설정되어 있기 때문에 사용자 지정 오류가 원격 클라이언트에 표시되고 ASP.NET 오류가 로컬 호스트에 표시됩니다(웹 서버 관리자가 문제를 해결할 수 있도록). 그림 3에 나타난 것처럼 <customErrors> 요소는 allowOverride="false"인 <location> 태그 내에 포함되어 있습니다. 이는 개별 응용 프로그램 소유자가 실수나 고의로 mode="Off"로 설정하고 자세한 ASP.NET 오류 메시지를 인터넷에 출력하지 못하도록 하기 위해서입니다.
Figure 3 오류 메시지 표시 방지
<configuration>
<location allowOverride='false'>
<system.web>
<customErrors mode='RemoteOnly' defaultRedirect=
'/errorpages/generic_customerror.aspx'>
<error statusCode='404' redirect='/errorpages/filenotfound_customerror.aspx' />
</customErrors>
</system.web>
</location>
<configuration>
또한 앞에서 말한 것처럼 machine.config 파일에서 <deployment retail="true"/> 스위치를 사용하면 자세한 ASP.NET 오류 메시지를 원격 클라이언트뿐만 아니라 로컬에도 표시할 수 없게 됩니다. ASP.NET 2.0을 실행하는 경우에는 주로 이 deployment retail 스위치를 사용하여 이러한 오류 메시지의 표시 기능을 해제해야 합니다. ASP.NET 예외에 대한 자세한 정보를 얻으려면 응용 프로그램 이벤트 로그를 사용합니다.
microsoft.com 내부 프리프로덕션 환경 루트 web.config 파일에서는 <customErrors> mode 특성이 off로 설정되므로 ASP.NET 오류가 항상 로컬 호스트와 원격 클라이언트 양쪽 모두에 표시됩니다. 이렇게 하면 디버깅 및 문제 해결이 가능합니다. 또한 사용자 지정 오류 페이지가 하나도 구성되지 않습니다.
<configuration>
<location allowOverride="false">
<system.web>
<customErrors mode="Off" />
</system.web>
</location>
<configuration>
9. 추적 기능 사용 시기
ASP.NET 추적은 ASP.NET 페이지를 실행하는 동안 생성되는데, 웹 요청, 페이지 제어 트리, 페이지 컨트롤 및 수명 주기의 다양한 단계 실행과 관련된 흥미로운 세부 정보를 캡처합니다. 또한 추적에 기록하도록 페이지 개발자가 지정한 메시지도 표시될 수 있습니다. 추적은 추적 또는 조사되는 페이지의 응답 출력에 추가될 수 있는데, 이때 추적되는 요청 목록의 일부로 응용 프로그램 추적 뷰어에 추가됩니다. 이 기능은 주로 내부 프리프로덕션 환경에서 개발 시 디버깅 시나리오에서 사용하기 위한 것이므로 프로덕션 배포에서는 사용해선 안 됩니다.
microsoft.com 프로덕션 및 스테이징 환경의 루트 web.config 파일에서 <configuration><system.web><trace> enabled 특성은 "false"로 설정되므로 웹 페이지에 추적 정보를 출력하는 기능은 비활성화됩니다. <trace> 요소는 allowOverride="false"인 <location> 태그 내에 포함되어 있습니다. 이는 개별 응용 프로그램 소유자가 실수나 고의로 enabled="true"로 설정하고 자세한 ASP.NET 추적 정보를 인터넷에 출력하지 못하도록 하기 위해서입니다.
<configuration>
<location allowOverride="false">
<system.web>
<trace enabled="false" localOnly="true"
pageOutput="false" requestLimit="10" traceMode="SortByTime" />
</system.web>
</location>
<configuration>
<system.web><trace>
앞에서 이미 설명했지만 machine.config 파일에서 <deployment retail="true"/> 스위치를 사용하면 ASP.NET 추적 출력을 웹 페이지에 출력하는 기능이 해제됩니다. .NET Framework 2.0을 실행하는 경우에는 주로 이 스위치를 사용하여 추적 출력 기능을 해제해야 합니다.
추적 기능이 외부 프로덕션 환경에서 실수로 활성화되는 경우가 절대 발생하지 않도록 microsoft.com에서는 실제 trace.axd 핸들러를 루트 web.config 파일에서 제거하거나 다음과 같이 주석으로 처리했습니다.
<!--
<add path="trace.axd" verb="*" type=
"System.Web.Handlers.TraceHandler"
validate="True" />
-->
10. 세션 상태 웹 팜 비활성화
microsoft.com의 모든 웹 사이트는 선호도가 지정되지 않은(클러스터의 모든 서버에 요청이 균등하게 분산되도록) NLB(네트워크 부하 분산)를 사용하여 현재 클러스터되어 있기 때문에, 지정된 응용 프로그램에 대한 모든 요청이 동일한 서버에서 처리되지 않을 수도 있습니다. 따라서 응용 프로그램 개발자가 Session 속성을 사용하지 못하도록 ASP.NET 세션 상태 모듈이 비활성화됩니다. 상태를 유지해야 하는 응용 프로그램 개발자라면 뷰 상태를 사용하는 것이 좋습니다. 뷰 상태는 페이지 코드 내의 구조체로 상태를 유지하기 때문에 서버 리소스를 사용하지 않습니다.
웹 서버에서 세션 상태를 비활성화하려면 <httpModules> 노드에서 다음과 같은 자식 노드를 제거하기만 하면 됩니다.
<add name="Session" type=
"System.Web.SessionState.
SessionStateModule"/>
본 칼럼은 독자가 ASP.NET 구성 파일(machine.config, 루트 web.config 및 개별 응용 프로그램 web.config 파일)을 사용해 본 경험이 있는 것으로 가정하고 작성된 것이므로, 이러한 경험이 없는 독자는 ASP.NET Quickstart Tutorial(asp.net/QuickStart/aspnet/doc/management/fileformat.aspx)(영문)을 참조하십시오.
본 문서에서는 관리자가 lockItems 및 lockCollections 특성을 사용하여 구성의 개별 요소 및 특성을 잠그는 데 사용할 수 있는 아주 유용한 여러 가지 기능이 ASP.NET 2.0 구성 시스템에 포함되어 있다는 점을 언급하였습니다. 이러한 특성 및 사용 방법에 대한 자세한 내용은 "section 요소에서 상속된 일반 특성"을 참조하십시오.
Jeff Toews는 워싱턴주 레드몬드에 있는 Microsoft.com 운영 팀의 팀원으로 6년간 근무한 시스템 엔지니어링 관리자입니다. 기술적인 질문이나 의견이 있으면 mscomblg@microsoft.com으로 연락하십시오.
© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..