응용 프로그램 요청 라우팅을 이용한 HTTP 로드 밸런싱

등록일시: 2011-05-23 13:33, 수정일시: 2013-11-26 11:02

이 문서는 IIS 기술을 널리 알리고자 하는 개인적인 취지로 제공되는 번역문서입니다. 이 문서에 대한 모든 저작권은 마이크로소프트에 있으며 요청이 있을 경우 언제라도 게시가 중단될 수 있습니다. 번역 내용에 오역이 존재할 수 있고 주석은 번역자 개인의 의견일 뿐이며 마이크로소프트는 이에 관한 어떠한 보장도 하지 않습니다. 번역이 완료된 이후에도 대상 제품 및 기술이 개선되거나 변경됨에 따라 원문의 내용도 변경되거나 보완되었을 수 있으므로 주의하시기 바랍니다.

본 번역문서의 원문은 HTTP Load Balancing using Application Request Routing _www.iis.net 입니다.

개요

본문에서는 응용 프로그램 요청 라우팅을 구성해서 높은 가용성과 확장성을 얻을 수 있도록 HTTP 요청을 로드 밸런스하는 과정을 살펴봅니다. 또한, 응용 프로그램 요청 라우팅이 콘텐츠 서버의 상태를 모니터하는 방법과 특정 클라이언트의 요청을 특정 콘텐츠 서버에 밀접하게 연결하는 방법 같은 몇 가지 핵심적인 기능들을 중점적으로 살펴볼 것입니다.

목표

응용 프로그램 요청 라우팅을 이용해서 HTTP 요청을 다음과 같은 몇 대의 콘텐츠 서버에 로드 밸런스하는 것이 본문의 목표입니다:

전제조건

본문의 과정을 정상적으로 따라해보기 위해서는 먼저 다음과 같은 조건들을 만족해야 합니다:

IIS 7.0이 설치되어 있는 윈도우 2008(모든 SKU 가능) 이상의 시스템
마이크로소프트 응용 프로그램 요청 라우팅 버전 1 및 관련 모듈들
사이트 및 응용 프로그램이 실행되고 있는 최소한 두 개 이상의 응용 프로그램 서버

만약, 아직 응용 프로그램 요청 라우팅을 설치하지 않았다면, 다음 링크에서 다운로드가 가능합니다: *

응용 프로그램 요청 라우팅을 설치하는 보다 자세한 방법은 응용 프로그램 요청 라우팅 설치하기를 참고하시기 바랍니다.

그리고, 마지막으로 응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 문서에서 설명하는 과정에 따라 정의 및 구성된 서버 팜이 준비되어 있어야만 합니다.

* 이전 문서에서 설명했던 것처럼 현재 ARR의 최신 버전은 2.5로(2011년 5월 23일 현재), 두 링크 중 어떤 것을 선택하더라도 그 결과는 같습니다. 결론적으로 웹 플랫폼 설치 관리자에 의해서 모든 설치 과정이 이뤄지도록 변경되었습니다.

단계 1 - URL 재작성 규칙 확인

응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 문서에서 설명한 과정에 따라 서버 팜을 생성했다면, 간단한 로드 밸런스 시나리오를 위한 URL 재작성 규칙도 이미 생성되어 있을 것입니다.

UI를 이용해서 URL 재작성 규칙을 확인하려면:

IIS 관리자를 실행합니다.
응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 문서에서 설명하는 과정에 따라 생성한 "myServerFarm" 서버 팜을 선택합니다.
그러면, 다음과 같은 아이콘들이 나타납니다.
"Routing Rules" 아이콘을 마우스로 더블 클릭합니다.
"Use URL Rewrite to inspect incoming requests" 체크박스가 체크되어 있는지 확인합니다.
SSL offloading 옵션은 기본으로 활성화되어 있는데, 이 기능이 활성화되어 있으면 클라이언트에서 ARR 서버로 HTTPS 요청이 전달된 경우에도 ARR 서버와 응용 프로그램 서버간의 모든 통신은 평문으로 이뤄집니다. ARR 서버와 응용 프로그램 서버들이 상호신뢰할 수 있는 네크워크상에 존재한다면, 가령 같은 데이터센터에 존재하는 경우에는 SSL offloading 옵션을 활성화시켜도 보안 문제가 발생할 우려가 적습니다. 또한, 이 기능을 활성화하면 요청과 응답을 암호화하고 복호화하기 위해서 사이클을 소모할 필요가 없기 때문에 응용 프로그램 서버들의 리소스를 더욱 극대화 시킬 수 있습니다.

이 기능을 비활성화하려면 "Enable SSL offloading" 체크박스의 체크를 해제하고 "Apply" 버튼을 클릭합니다.
이제, 브라우저를 열고 ARR 서버로 요청을 몇 번 전송해봅니다.
전송한 요청들이 응용 프로그램 서버들로 균일하게 로드 밸런스되는 것을 확인해보려면, "myServerFarm" 노드를 선택하고 "Monitoring and Management" 아이콘을 마우스로 더블 클릭합니다.
대시보드 뷰에서 요청들이 균등하게 분배되고 있는지 확인해봅니다.

명령 프롬프트를 이용해서 URL 재작성 규칙을 확인하려면:

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

URL 재작성 규칙이 정상적으로 생성되었는지 확인해보려면 다음과 같이 명령어를 입력합니다:

appcmd.exe list config -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 offloading 기능을 비활성화하기 위해서, 먼저 이 URL 재작성 규칙을 모두 제거합니다:

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

그리고, HTTPS 트래픽을 전달하기 위한 URL 재작성 규칙들을 생성합니다. 이 규칙들은 ARR로 전달된 요청이 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

마지막으로, HTTP 트래픽을 응용 프로그램 서버에 평문으로 전달하기 위한 URL 재작성 규칙들을 생성합니다:

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

URL 재작성 규칙이 SSL offloading 기능이 비활성화 된 상태로 정상적으로 생성되었는지 확인해보려면 다음과 같이 명령어를 입력합니다:

appcmd.exe list config -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" 서버 팜을 선택합니다. 그러면, 다음과 같은 아이콘들이 나타납니다.
"Health Test" 아이콘을 마우스로 더블 클릭합니다.
"URL" 텍스트 박스에 "http://(ARR 서버의 서버명이나 FQDN)/healthCheck.txt"를 입력합니다.
"Response match" 텍스트 박스에 "healthy"라는 단어를 입력합니다. 필요한 경우, 이 Response match 기능을 이용하면 응답의 본문에 기대하는 문장이 포함되어 있는지 선택적으로 확인할 수 있습니다. 가령, healthCheck.txt 파일에는 "I am healthy."라는 문장이 담겨 있으므로 Response match 기능이 "healthy"라는 단어를 확인할 수 있습니다.
"Apply" 버튼을 클릭해서 변경된 내용들을 저장합니다.
상태 점검 모니터링 기능이 정상적으로 동작하는지 확인해보려면 응용 프로그램 서버들 중 한 서버의 모니터링 대상 사이트를 중지합니다. "Interval (seconds)" 항목의 값이 30초로 설정되어 있으므로 다음 상태 점검까지 30초를 기다려야 합니다.
30초가 지났으면 ARR 서버로 요청을 몇 번 정도 보내봅니다.
모든 요청들이 정상적인 상태의 서버(들)로 전달되는지 확인해 보려면 "Monitoring and Management" 아이콘을 더블 클릭한 다음, F5키를 눌러서 대시보드의 내용들을 새로 고칩니다. 런타임 통계 정보가 초기화되는 것에 주의하시기 바랍니다. 이는 의도된 동작입니다. 원하는 만큼 추가적인 요청을 전송하고 대시보드를 새로 고쳐서 정보를 확인해 볼 수 있습니다.
상태 모니터링은 비정상적인 서버가 정상적으로 회복되는 것을 감지하는 데도 이용됩니다. 이를 확인해 보려면 9.번 단계에서 중지시켰던 사이트를 다시 시작시킵니다. "Interval (seconds)" 항목의 값이 30초로 설정되어 있으므로 이번에도 다음 상태 점검까지 30초를 기다려야 합니다.
30초가 지났으면 ARR 서버로 요청을 몇 번 정도 보내봅니다.
요청들이 서버들간에 균등하게 전달되는지 확인해보려면 IIS 관리자에서 대시보드의 정보를 새로 고쳐봅니다. 런타임 통계 정보가 초기화되는 것에 주의하시기 바랍니다. 이는 의도된 동작입니다. 원하는 만큼 추가적인 요청을 전송하고 대시보드를 새로 고쳐서 정보를 확인해 볼 수 있습니다.

명령 프롬프트를 이용해서 상태 모니터링을 구성하려면:

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

URL을 "http://(ARR 서버의 서버명이나 FQDN)/healthCheck.txt"로, 일치 문자열을 "I am healthy."로 설정하려 다음과 같이 명령어를 입력합니다:

appcmd.exe set config -section:webFarms 
    /[name='myServerFarm1'].applicationRequestRouting.healthCheck.url:"http://(ARR 서버의 서버명이나 FQDN)/healthCheck.txt " 
    /[name='myServerFarm1'].applicationRequestRouting.healthCheck.responseMatch:"I am healthy." 
    /commit:apphost

단계 3 - 클라이언트 친화성 구성

응용 프로그램 요청 라우팅은 클라이언트의 세션 기간 동안, 해당 클라이언트를 응용 프로그램 요청 라우팅 뒷편의 특정 콘텐츠 서버에 맵핑시켜주는 클라이언트 친화성 기능을 제공해줍니다. 이 기능이 활성화되면, 로드 밸런싱 알고리즘은 각각의 클라이언트로부터 전달된 가장 첫 번째 요청에 대해서만 적용됩니다. 이 시점부터 동일한 클라이언트로부터 전달되는 모든 요청들은 해당 클라이언트의 세션 기간 동안 항상 같은 콘텐츠 서버로 전달됩니다. 이 기능은 콘텐츠 서버에서 서비스되는 응용 프로그램이 상태를 갖고 있는 반면, 세션은 중앙에서 집중 관리되고 있지 않아서 클라이언트의 요청들이 동일한 서버로 전달되어야 하는 경우에 유용합니다.

명령 프롬프트를 이용해서 상태 모니터링을 구성하려면:

IIS 관리자를 실행합니다.
응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 문서에서 설명하는 과정에 따라 생성한 "myServerFarm" 서버 팜을 선택합니다.
그러면, 다음과 같은 아이콘들이 나타납니다.
"Server Affinity" 아이콘을 마우스로 더블 클릭합니다.
클라이언트 친화성을 활성화하려시키려면 "Client affinity" 체크박스를 체크한 다음, "Apply" 버튼을 클릭합니다.

응용 프로그램 요청 라우팅은 클라이언트 친화성을 활성화시키기 위해서 쿠키를 사용합니다. "Cookie name" 텍스트 박스에 지정된 값이 바로 클라이언트에 설정될 쿠키의 이름입니다. 따라서, 클라이언트 친화성 기능이 정상적으로 동작하기 위해서는 클라이언트가 반드시 쿠키를 허용해야 합니다.
클라이언트 친화성 기능이 정상적으로 동작하는지를 확인해보려면 먼저 ARR 서버로 요청을 몇 차례 전송합니다. 그 뒤에 IIS 관리자에서 "Monitoring and Management" 대시보드를 새로 고침합니다. 그러면, 런타임 통계 정보에서 클라이언트의 모든 요청이 클라이언트 친화성이 설정된 특정 응용 프로그램 서버로 전달되는 것을 확인할 수 있습니다. 원하는 만큼 추가적인 요청을 전송하고 대시보드를 새로 고쳐서 정보를 확인해 볼 수 있습니다.

명령 프롬프트를 이용해서 클라이언트 친화성을 구성하려면:

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

클라이언트 친화성 기능을 활성화 시키려면 다음의 명령어를 입력합니다:

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

단계 4 - 신규 연결 제한

서버 팜 환경에서 서버를 깔끔하게 분리하려면 해당 서버에 대한 신규 연결을 제한하면 됩니다. 이는 클라이언트 친화성 기능이 사용 중인 경우에 보다 의미가 있는데, 신규 연결이 제한된 상황에서도 응용 프로그램 요청 라우팅이 기존 세션은 계속 유지하기 때문입니다. 이 경우, 신규 연결이 제한된 서버와 친화성이 맺어져 있는 클라이언트의 요청은 여전히 해당 서버로 라우트되고, 결과적으로 클라이언트에게는 어떠한 영향도 미치지 않습니다. 반면, 신규 연결이 제한된 서버로 새로운 클라이언트가 라우트되지는 않습니다.

UI를 이용해서 신규 연결을 제한하려면:

단계 3에서 설명한 과정을 이용해서 클라이언트와 친화성이 맺어진 서버를 확인합니다.
응용 프로그램 요청 라우팅 모듈 서버 팜 정의 및 구성하기 문서에서 설명하는 과정에 따라 생성한 "myServerFarm" 서버 팜을 선택합니다.
그러면, 다음과 같은 아이콘들이 나타납니다.
"Monitoring and Management" 아이콘을 마우스로 더블 클릭합니다.
클라이언트와 친화성이 맺어진 서버를 선택합니다. 그리고, "Actions" 패인에서 "Disallow New Connections" 링크 버튼을 클릭합니다.
확인 대화 상자가 나타나면 "Yes" 버튼을 클릭합니다.
클라이언트의 요청이 현재 신규 연결이 제한된, 친화성이 맺어져 있는 서버로 여전히 전달되는 것을 확인해보려면 ARR 서버로 요청을 몇 번 전송해봅니다. 그리고, IIS 관리자에서 대시보드를 새로 고칩니다. 클라이언트와 친화성이 맺어진 서버의 런타임 상태 정보만 변경되는 것을 확인할 수 있습니다. 원하는 만큼 추가적인 요청을 전송하고 대시보드를 새로 고쳐서 정보를 확인해 볼 수 있습니다.
신규 연결이 제한된 서버로 새로운 클라이언트가 연결되지 않는 것을 확인해보려면 브라우저를 닫고 다시 시작해서 응용 프로그램 요청 라루팅에 의해 설정된 쿠키를 제거합니다.
ARR 서버로 요청을 몇 번 전송해봅니다. 그리고, IIS 관리자에서 대시보드를 새로 고칩니다. "Available" 상태인 서버의 런타임 상태 정보만 변경되는 것을 확인할 수 있습니다. 다시 말해서, 신규 연결이 제한된 서버의 런타임 통계 정보는 변경되지 않는 것입니다. 원하는 만큼 추가적인 요청을 전송하고 대시보드를 새로 고쳐서 정보를 확인해 볼 수 있습니다.

요약

본문에서는 스케일 아웃과 균등한 부하 배분을 위한 응용 프로그램 요청 라우팅의 몇 가지 설정을 구성해 봤습니다. 보다 많은 고급 라우팅 기능들에 대해서는 응용 프로그램 요청 라우팅 모듈 사용하기 문서를 참고하시기 바랍니다.

응용 프로그램 요청 라우팅을 이용한 HTTP 로드 밸런싱

개요

목표

전제조건

단계 1 - URL 재작성 규칙 확인

UI를 이용해서 URL 재작성 규칙을 확인하려면:

명령 프롬프트를 이용해서 URL 재작성 규칙을 확인하려면:

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

UI를 이용해서 상태 모니터링을 구성하려면:

명령 프롬프트를 이용해서 상태 모니터링을 구성하려면:

단계 3 - 클라이언트 친화성 구성

명령 프롬프트를 이용해서 상태 모니터링을 구성하려면:

명령 프롬프트를 이용해서 클라이언트 친화성을 구성하려면:

단계 4 - 신규 연결 제한

UI를 이용해서 신규 연결을 제한하려면:

요약

관련 자료