애플리케이션 요청 라우팅을 사용하여 HTTP 부하 분산

아티클
04/12/2024

작성자: IIS 팀

개요

이 항목에서는 고가용성 및 확장성을 달성하기 위해 HTTP 요청 부하를 분산하도록 애플리케이션 요청 라우팅을 구성하는 단계를 안내합니다. 또한 이 연습에서는 애플리케이션 요청 라우팅이 콘텐츠 서버의 상태를 모니터링하고 클라이언트에서 콘텐츠 서버로 요청을 선호하게 하는 방법에 대한 몇 가지 핵심 기능을 강조 표시합니다.

목표

아래와 같이 애플리케이션 요청 라우팅을 사용하여 여러 콘텐츠 서버에서 HTTP 요청 부하를 분산하려면 다음을 수행합니다.

필수 조건

이 연습을 수행하려면 다음 필수 구성 요소가 필요합니다.

Windows 2008(모든 SKU) 이상에서 IIS 7.0 이상.
Microsoft 애플리케이션 요청 라우팅 버전 1 및 종속 모듈.
작업 사이트 및 애플리케이션이 있는 최소 두 개의 콘텐츠 서버.

이 문서에 설명된 단계에 따라 애플리케이션 요청 라우팅을 설치합니다.

또 다른 필수 조건은 판독기가 ARR(애플리케이션 요청 라우팅) 서버 그룹 정의 및 구성에 설명된 단계를 사용하여 서버 팜을 정의하고 구성했다는 것입니다.

1단계 - URL 다시 쓰기 규칙 확인

ARR(애플리케이션 요청 라우팅) 서버 그룹 정의 및 구성에 설명된 단계를 사용하여 서버 팜을 만든 경우 간단한 부하 분산 시나리오에 대한 URL 다시 쓰기 규칙이 이미 생성되었습니다.

UI를 사용하여 URL 다시 쓰기 규칙을 확인하려면 다음을 수행합니다.

IIS 관리자를 시작합니다.
ARR(애플리케이션 요청 라우팅) 서버 그룹 정의 및 구성에서 만든 서버 팜 myServerFarm을 선택합니다.
다음 아이콘이 표시됩니다.
라우팅 규칙을 두 번 클릭합니다.
URL 다시 쓰기를 사용하여 들어오는 요청 검사box가 검사 검사하는지 확인합니다.
SSL 오프로드는 기본적으로 사용하도록 설정됩니다. 이 기능을 사용하도록 설정하면 클라이언트에서 ARR 서버로의 HTTPS 요청에 대해서도 ARR 서버와 애플리케이션 서버 간의 모든 통신이 명확한 텍스트로 수행됩니다. ARR 서버와 애플리케이션 서버가 모두 동일한 데이터 센터 내와 같은 신뢰할 수 있는 네트워크 내에 배포되는 경우 SSL 오프로드를 사용하도록 설정해도 보안이 희생되지 않습니다. 또한 이 기능을 사용하도록 설정하면 요청 및 응답을 암호화 및 암호 해독하는 데 주기를 소비할 필요가 없으므로 애플리케이션 서버에서 서버 리소스를 최대화하는 데 도움이 될 수 있습니다.
SSL 오프로드를 사용하지 않도록 설정하려면 SSL 사용 오프로드 검사 상자를 검사 해제한 다음 적용을 클릭합니다.
브라우저를 열고 ARR 서버에 여러 요청을 보냅니다.
요청이 애플리케이션 서버 간에 동일하게 부하 분산되는지 확인하려면 myServerFarm을 선택합니다. 모니터링 및 관리를 두 번 클릭합니다.
대시보드 보기에서 요청이 균등하게 분산되고 있는지 확인합니다.

명령줄을 사용하여 URL 다시 쓰기 규칙을 확인하려면 다음을 수행합니다.

관리자 권한으로 명령 프롬프트를 엽니다.
%windir%\system32\inetsrv으로 이동합니다.

URL 다시 쓰기 규칙이 올바르게 만들어졌는지 확인하려면 appcmd.exe 목록 구성 -section:system.webServer/rewrite/globalRules를 입력합니다. 다음과 같은 globalRules를 반환합니다.

<system.webServer>
    <rewrite>
        <globalRules>
            <rule name="ARR_myServerFarm_loadbalance" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                </conditions>
                <action type="Rewrite" url="http://myServerFarm/{R:0}" />
            </rule>
        </globalRules>
    </rewrite>
</system.webServer>

SSL 오프로드를 사용하지 않도록 설정하려면 먼저 모든 URL 다시 쓰기 규칙을 제거합니다.

appcmd.exe clear config -section:system.webServer/rewrite/globalRules

그런 다음 URL 다시 쓰기 규칙을 만들어 HTTPS 트래픽을 전달합니다. 더 구체적으로, 이 규칙을 사용하면 들어오는 요청이 HTTPS인 경우 ARR은 SSL을 사용하여 요청을 전달합니다.

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTPS}',pattern='On']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite"
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.url:"https://myServerFarm/{R:0}"
/commit:apphost

마지막으로, URL 다시 쓰기 규칙을 만들어 명확한 텍스트의 HTTP 트래픽을 애플리케이션 서버로 전달합니다.

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'].action.type:"Rewrite"
/[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].action.url:"http://myServerFarm/{R:0}"
/commit:apphost

SSL 오프로드를 사용하지 않도록 설정하여 URL 다시 쓰기 규칙이 올바르게 만들어졌는지 확인하려면 appcmd.exe 목록 구성 -section:system.webServer/rewrite/globalRules를 입력합니다. 다음과 같은 globalRules를 반환합니다.

<system.webServer>
    <rewrite>
        <globalRules>
            <rule name="ARR_myServerFarm_loadbalance_SSL" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                <add input="{HTTPS}" pattern="On" />
                </conditions>
                <action type="Rewrite" url="https://myServerFarm/{R:0}" />
            </rule>
            <rule name="ARR_myServerFarm_loadbalance" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                </conditions>
                <action type="Rewrite" url="http://myServerFarm/{R:0}" />
            </rule>
        </globalRules>
    </rewrite>
</system.webServer>

2단계 - 상태 검사 모니터링 구성

애플리케이션 요청 라우팅은 다음 두 가지 방법으로 콘텐츠 서버의 상태를 모니터링합니다.

라이브 트래픽을 통해
명시적 URL 테스트를 통해

라이브 트래픽 테스트는 애플리케이션 요청 라우팅에 대한 요청이 수행될 때 기본적으로 자동으로 수행됩니다. 명시적 URL 테스트는 라이브 트래픽 테스트와 함께 사용할 수 있는 추가 테스트입니다. 이 섹션에서는 명시적 URL 테스트를 구성하는 방법을 안내합니다.

UI를 사용하여 상태 검사 모니터링을 구성하려면 다음을 수행합니다.

URL 테스트에는 테스트할 특정 URL이 필요합니다. 이 요구 사항을 충족하려면 메모장 사용하여 "I am healthy"라는 문장이 포함된 healthCheck.txt 텍스트 파일을 만듭니다.
애플리케이션 서버에 healthCheck.txt 파일을 배치합니다.
브라우저에서 페이지를 열어 healthCheck.txt 제대로 렌더링되는지 확인합니다.
IIS 관리자에서 서버 팜 myServerFarm을 선택합니다. 다음 아이콘이 표시됩니다.
상태 테스트를 두 번 클릭합니다.
URL 값으로 입력 http://(server name or FQDN of ARR server)/healthCheck.txt 합니다.
응답 일치 값으로 정상으로 입력합니다. 응답 일치는 응답 본문에 예상 문자열이 포함되어 있는지 확인하는 선택적 테스트입니다. 이 경우 healthCheck.txt "I am healthy"라는 문장을 포함하므로 응답 일치는 "정상"이라는 단어를 찾습니다.
적용을 클릭하여 변경 내용을 저장합니다.
상태 검사 모니터링의 기능을 확인하려면 애플리케이션 서버 중 하나에서 모니터링되는 사이트를 중지합니다. Interval(초) 값이 30초로 설정되어 있으므로 다음 상태 검사 30초 동안 기다립니다.
30초 동안 기다린 후 ARR 서버에 여러 요청을 보냅니다.
모든 요청이 정상 서버로 이동 중인지 확인하려면 모니터링 및 관리를 두 번 클릭한 다음 F5 키를 사용하여 대시보드를 새로 고칩니다. 런타임 통계가 다시 설정되었습니다. 이것은 의도적인 것입니다. 필요에 따라 추가 요청을 보내고 대시보드를 새로 고칠 수 있습니다.
상태 모니터링은 비정상 서버가 정상 상태가 되는 시기를 감지하는 데도 사용됩니다. 이 기능을 확인하려면 9단계에서 중지된 사이트를 시작합니다. 다시 한 번 Interval(초) 값이 30초로 설정되었으므로 다음 상태 검사 30초 동안 기다립니다.
30초 동안 기다린 후 ARR 서버에 여러 요청을 보냅니다.
요청이 서버 간에 균등하게 분산되는지 확인하려면 IIS 관리자에서 대시보드를 새로 고칩니다. 런타임 통계가 다시 설정되었습니다. 이것은 의도적인 것입니다. 필요에 따라 추가 요청을 보내고 대시보드를 새로 고칠 수 있습니다.

명령줄을 사용하여 상태 검사 모니터링을 구성하려면 다음을 수행합니다.

관리자 권한으로 명령 프롬프트를 엽니다.
%windir%\system32\inetsrv으로 이동합니다.

URL http://(server name or FQDN of ARR server)/healthCheck.txt 을 정상 상태로 설정하려면 다음을 입력합니다. 일치시킬 문자열로 다음을 입력합니다.

appcmd.exe set config -section:webFarms
/[name='myServerFarm1'].applicationRequestRouting.healthCheck.url:"http://(server
name or FQDN of ARR server)/healthCheck.txt "
/[name='myServerFarm1'].applicationRequestRouting.healthCheck.responseMatch:"I am
healthy." /commit:apphost

3단계 - 클라이언트 선호도 구성

애플리케이션 요청 라우팅은 클라이언트 세션 기간 동안 애플리케이션 요청 라우팅 뒤에 있는 콘텐츠 서버에 클라이언트를 매핑하는 클라이언트 선호도 기능을 제공합니다. 이 기능을 사용하도록 설정하면 부하 분산 알고리즘은 클라이언트의 첫 번째 요청에만 적용됩니다. 이 시점부터 동일한 클라이언트의 모든 후속 요청은 클라이언트 세션 기간 동안 동일한 콘텐츠 서버로 라우팅됩니다. 이 기능은 세션 관리가 중앙 집중화되지 않으므로 콘텐츠 서버의 애플리케이션이 상태 저장 상태이고 클라이언트의 요청을 동일한 콘텐츠 서버로 라우팅해야 하는 경우에 유용합니다.

UI를 사용하여 클라이언트 선호도를 구성하려면 다음을 수행합니다.

IIS 관리자를 시작합니다.
ARR(애플리케이션 요청 라우팅) 서버 그룹 정의 및 구성에서 만든 서버 팜 myServerFarm을 선택합니다.
다음 아이콘이 표시됩니다.
서버 선호도를 두 번 클릭합니다.
클라이언트 선호도를 사용하도록 설정하려면 클라이언트 선호도 검사 상자를 검사 다음 적용을 클릭합니다.

애플리케이션 요청 라우팅은 쿠키를 사용하여 클라이언트 선호도를 사용하도록 설정합니다. 쿠키 이름은 클라이언트에서 쿠키를 설정하는 데 사용됩니다. 즉, 클라이언트 선호도가 제대로 작동하려면 클라이언트가 쿠키를 수락해야 합니다.
클라이언트 선호도의 기능을 확인하려면 ARR 서버에 여러 요청을 보냅니다. IIS 관리자(모니터링 및 관리)에서 대시보드를 새로 고칩니다. 클라이언트가 선호도가 설정된 애플리케이션 서버 중 하나에 대해서만 런타임 통계가 변경되고 있는지 확인합니다. 필요에 따라 추가 요청을 보내고 대시보드를 새로 고칠 수 있습니다.

명령줄을 사용하여 클라이언트 선호도를 구성하려면 다음을 수행합니다.

관리자 권한으로 명령 프롬프트를 엽니다.
%windir%\system32\inetsrv으로 이동합니다.

클라이언트 선호도를 사용하도록 설정하려면 다음을 입력합니다.

appcmd.exe set config -section:webFarms
/[name='myServerFarm1'].applicationRequestRouting.affinity.useCookie:"True"
/commit:apphost

4단계 - 새 연결 허용 불가

서버에서 새 연결을 허용하지 않는 것은 서버를 서버 팜 환경에서 벗어나는 정상적인 방법입니다. 애플리케이션 요청 라우팅은 새 연결을 허용하지 않을 때 기존 세션을 적용하기 때문에 클라이언트 선호도 기능을 사용할 때 더 의미가 있습니다. 즉, 클라이언트가 새 연결을 허용하지 않는 서버로 선호되는 경우 클라이언트는 계속해서 동일한 서버로 라우팅되므로 클라이언트에 영향을 주지 않습니다. 그러나 새 클라이언트는 새 연결을 허용하지 않는 서버로 라우팅되지 않습니다.

UI를 사용하여 새 연결을 허용하지 않도록 하려면 다음을 수행합니다.

위의 3단계에서 설정을 사용하여 클라이언트가 선호도가 높은 서버를 식별합니다.
ARR(애플리케이션 요청 라우팅) 서버 그룹 정의 및 구성에서 만든 서버 팜 myServerFarm을 선택합니다.
다음 아이콘이 표시됩니다.
모니터링 및 관리를 두 번 클릭합니다.
클라이언트가 선호도가 설정된 서버를 선택합니다. 작업 창에서 새 커넥트 허용을 클릭합니다.
확인 대화 상자에서 예를 클릭합니다.
클라이언트의 요청이 새 연결을 허용하지 않는 선호도 서버로 계속 라우팅되는지 확인하려면 ARR 서버에 여러 요청을 보냅니다. IIS 관리자에서 대시보드를 새로 고칩니다. 서버의 런타임 통계가 클라이언트가 선호도인 위치로만 변경되고 있는지 확인합니다. 필요에 따라 추가 요청을 보내고 대시보드를 새로 고칠 수 있습니다.
새 클라이언트가 새 연결을 허용하지 않는 서버로 라우팅되지 않는지 확인하려면 브라우저를 닫고 다시 시작하여 애플리케이션 요청 라우팅에 의해 설정된 쿠키를 제거합니다.
ARR 서버에 여러 요청을 보냅니다. IIS 관리자에서 대시보드를 새로 고칩니다. 사용 가능한 서버에 대해서만 런타임 통계가 변경되고 있는지 확인합니다. 더 구체적으로는 서버의 런타임 통계가 새 연결을 허용하지 않는지 확인합니다. 필요에 따라 추가 요청을 보내고 대시보드를 새로 고칠 수 있습니다.

요약

이제 부하를 스케일 아웃하고 균등하게 분산하도록 애플리케이션 요청 라우팅에 대한 여러 설정을 성공적으로 구성했습니다. 애플리케이션 요청 라우팅을 사용하는 고급 라우팅 기능은 애플리케이션 요청 라우팅 사용을 참조 하세요.

다음을 통해 공유