CDN에서 애플리케이션 요청 라우팅 배포
작성자: 원유
문서의 이 섹션은 IIS 7 이상용 Microsoft 애플리케이션 요청 라우팅 버전 2에 적용됩니다.
Goal
CDN/ECN(콘텐츠 배달 네트워크/에지 캐싱 네트워크) 환경에서 2계층 캐시 계층 구조 배포에서 자식/에지 캐시 노드 및 부모 캐시 노드를 성공적으로 구성합니다. 이 연습의 초점은 자식/에지 캐시 노드 및 부모 캐시 노드의 URL 다시 쓰기 규칙을 이해하는 것입니다. 궁극적으로 이 연습에서는 단계별 지침을 통해 다음 구성을 설정합니다.
이 구성의 주요 내용은 다음과 같습니다.
원본 조회는 자식/에지 캐시 노드에서 수행됩니다.
- 고객 목록(즉, 허용 가능한 원본 서버 목록)은 URL 다시 쓰기에서 다시 쓰기 맵을 사용하여 명시적으로 관리됩니다.
- 다시 쓰기 맵에서 찾을 수 없는 호스트 이름이 차단됩니다.
부모 캐시 노드는 대부분 전달 프록시로 구성됩니다.
SAN은 자식/에지 캐시 노드에서 공유되도록 구성됩니다.
실제로 캐시 계층은 3개입니다.
- 자식/에지 캐시 노드.
- 산.
- 부모 캐시 노드.
사전 요구 사항
이 연습에서는 ARR 버전 2의 디스크 캐시 및 캐시 계층 관리 구성에 익숙하다고 가정합니다. 아직 수행하지 않은 경우 계속하기 전에 다음 연습을 검토하는 것이 좋습니다.
애플리케이션 요청 라우팅 버전 2가 설치되지 않은 경우 다음에서 다운로드할 수 있습니다.
- IIS 7(x86)용 Microsoft 애플리케이션 요청 라우팅 버전 2(
https://download.microsoft.com/download/4/D/F/4DFDA851-515F-474E-BA7A-5802B3C95101/ARRv2_setup_x86.EXE
). - IIS 7용 Microsoft 애플리케이션 요청 라우팅 버전 2(x64)는 여기(
https://download.microsoft.com/download/3/4/1/3415F3F9-5698-44FE-A072-D4AF09728390/ARRv2_setup_x64.EXE
)입니다.
애플리케이션 요청 라우팅 버전 2 설치 문서에 설명된 단계에 따라 ARR 버전 2를 설치합니다.
자식/에지 캐시 노드 구성
1단계 - 디스크 캐시 구성
애플리케이션 요청 라우팅 버전 2 설치 문서에 따라 디스크 캐시를 구성하고 사용하도록 설정합니다. 이 문서에서는 보조 캐시 드라이브 위치로 사용하도록 SAN을 구성하는 방법에 대해서도 설명합니다.
2단계 - 부모 캐시 노드에 대한 서버 팜 정의
애플리케이션 요청 라우팅을 사용하여 캐시 계층 관리 문서에 따라 서버 팜을 정의하고 부모 캐시 노드를 추가합니다.
3단계 - 자식/에지 캐시 노드에 대한 추가 URL 다시 쓰기 규칙 만들기
이 시점에서 myParentCacheNodes를 서버 팜의 이름으로 사용하여 다음 URL 다시 쓰기 규칙이 에 있는 %windir%\system32\inetsrv\config\
applicationHost.config 파일에 작성되었습니다.
<rewrite>
<globalRules>
<rule name="ARR_myParentCacheNodes_loadbalance" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<action type="Rewrite" url="http://myParentCacheNodes/{R:0}" />
</rule>
</globalRules>
</rewrite>
위의 규칙은 캐시 노드가 계층화되어 있기 때문에 CDN/ECN 배포에 충분하지 않으며, 캐시 노드의 다음 계층(즉, 부모 캐시 노드)은 부모 캐시 계층에 캐시 누락이 있을 때 원본 서버를 찾는 방법을 알지 못합니다.
이 연습에서는 요청이 부모 캐시 노드로 라우팅되기 전에 자식 캐시 노드가 원본 서버를 매핑하도록 하여 문제를 해결합니다. 원본 서버는 자식 캐시 노드가 받는 URL에 따라 매핑되는 가장 일반적인 두 가지 방법이 있습니다.
- CDN/ECN의 고객은 하위 도메인으로 지정됩니다. 이 경우 자식 캐시 노드의 동일한 IP 주소에 많은 호스트 이름 바인딩이 있을 수 있습니다.
예:http://customer1.mycnd.net/
,http://customer2.mycdn.net/
, 등 - CDN/ECN의 고객은 URL의 첫 번째 경로로 지정됩니다.
예:http://static.mycdn.net/customer1/
,http://static.mycdn.net/customer2/
, 등
이 연습에서는 첫 번째 예제가 데모에 사용됩니다. 두 번째 시나리오도 사용하도록 유사한 규칙을 작성할 수 있습니다.
원본 서버의 호스트 이름을 조회하는 데 사용할 수 있는 URL 다시 쓰기 맵을 정의합니다. IIS 관리자를 시작합니다.
서버의 루트를 선택하고 확장합니다. 자식(에지) 캐시 노드입니다.
URL 다시 쓰기를 두 번 클릭합니다.
작업 창에서 다시 쓰기 맵 보기를 클릭합니다.
작업 창에서 다시 쓰기 맵 추가를 클릭합니다.
다시 쓰기 맵 추가 대화 상자에서 다시 쓰기 맵의 이름을 OriginServers로 지정합니다.
다시 쓰기 맵에서 자식 캐시 노드가 받는 호스트 이름과 해당 원본 호스트 이름 간의 매핑을 명시적으로 식별합니다. 작업 창에서 매핑 항목 추가...를 클릭합니다.
매핑 항목 추가 대화 상자에서 자식 캐시 노드가 받는 호스트 이름과 원본 호스트 이름을 추가합니다. 아래 예제에서 ARR 자식 캐시 노드는 호스트 이름 헤더로 customer1.mycdn.net 받습니다. 해당 원본 서버가 images.customer1.com.
CDN/ECN에서 서비스를 제공하는 모든 고객을 포함하도록 8단계를 필요에 따라 여러 번 반복합니다. 이렇게 하면 고객의 명시적 목록을 관리하여 서비스가 고객에게만 제공되도록 할 수 있습니다.
다시 쓰기 맵 목록에 없는 고객을 차단하려면 이 다시 쓰기 맵의 기본값을 #RFC당 호스트 이름 헤더의 일부로 사용할 수 없는 잘못된 문자인 로 설정합니다. 작업 창에서 지도 설정 편집...을 클릭합니다.
맵 다시 쓰기 편집 대화 상자에서 이 다시 쓰기 맵의 기본값으로 를 입력 # 합니다.
OriginServers 다시 쓰기 맵에 구성된 규칙으로 호스트 이름 헤더를 다시 작성합니다. 캐시 누락이 있고 요청이 부모 캐시 노드로 라우팅되는 경우 요청은 원본 서버와 일치하는 호스트 이름을 갖습니다. 따라서 대부분의 경우 부모 캐시 노드가 전달 프록시로 구성됩니다. 부모 캐시 노드에 캐시 누락이 있는 경우 요청은 부모 캐시 노드가 수신하는 호스트 이름 헤더를 기반으로 원본 서버로 라우팅됩니다.
URL 다시 쓰기 UI에서 규칙을 찾습니다. 이 연습에서는 규칙 이름을 ARR_myParentCacheNodes_loadbalance 합니다.
규칙을 선택하고 작업 창에서 편집을 클릭합니다.
조건 추가를 클릭하여 두 개의 규칙을 추가합니다.
첫 번째 규칙은 6단계에서 만든 OriginServers 다시 쓰기 맵을 사용합니다. 다음 규칙은 호스트 헤더를 OriginServers의 항목과 일치하는 키로 일치합니다.
두 번째 규칙은 호스트 헤더가 OriginServers의 항목과 일치하지 않을 때 기본값을 로 # 설정합니다. 위에서 # 설명한 것처럼 은 유효한 문자가 아니며 호스트 이름으로 사용할 수 없습니다. 다음 규칙은 나중에 OriginServers 의 고객(호스트 이름으로 표시됨)만 ARR에서 서비스되도록 하는 데 사용됩니다.
여러 조건에서 캡처 그룹 추적을 선택합니다.
위의 조건과 일치하도록 HTTP_HOST 값을 설정하려면 서버 변수를 클릭합니다.
HTTP_HOST 다시 설정하려면 다음 값을 입력합니다.
확인을 클릭하여 변경 내용을 저장합니다.
작업 창에서 적용을 클릭하여 변경 내용을 저장합니다.
올바른 규칙이 작성되었는지 확인하려면 메모장을 사용하여 applicationHost.config 파일을 엽니다. 구성 파일은 에 있습니다
%windir%\system32\inetsrv\config\
.서버 팜 myParentCacheNodes에 대한 URL 다시 쓰기 규칙을 찾습니다. 다음과 같이 표시됩니다.
<rewrite> <globalRules> <rule name="ARR_myParentCacheNodes_loadbalance" patternSyntax="Wildcard" stopProcessing="true"> <match url="*" /> <conditions trackAllCaptures="true"> <add input="{OrigServers:{HTTP_HOST}}" pattern="*" /> <add input="{C:1}" negate="true" pattern="#" /> </conditions> <serverVariables> <set name="HTTP_HOST" value="{C:1}" replace="true" /> </serverVariables> <action type="Rewrite" url="http://myParentCacheNodes/{R:0}" /> </rule> </globalRules> </rewrite>
강력히 권장합니다. 위의 다시 쓰기 맵에 정의된 호스트 이름과 일치하지 않는 요청을 차단하려면 이러한 요청에 400 응답을 보내는 기본 URL 다시 쓰기 규칙을 만듭니다.
IIS 관리자를 시작합니다.
서버의 루트를 선택하고 확장합니다. 자식(에지) 캐시 노드입니다.
URL 다시 쓰기를 두 번 클릭합니다.
작업 창에서 규칙 추가를 클릭합니다.
규칙 추가 대화 상자에서 빈 규칙을 선택합니다.
다음 값을 입력한 다음, 규칙을 저장합니다.
이름: 내 고객이 아님
사용: 와일드 카드
패턴: *
작업 유형: 사용자 지정 응답
상태 코드: 400
하위 상태 코드: 0규칙의 순서가 중요합니다. URL 다시 쓰기 규칙은 위에서 아래로 처리됩니다. 이 예제에서 들어오는 호스트 이름이 위의 다시 쓰기 맵에 지정된 호스트 이름 중 하나와 일치하는 경우 첫 번째 규칙 인 ARR_myParentCacheNodes_Loadbalance 실행됩니다. 들어오는 호스트 이름이 위의 다시 쓰기 맵에 정의된 호스트 이름과 일치하지 않으면 두 번째 규칙인 내 고객이 아님이 실행됩니다.
자식/에지 캐시 노드 구성이 완료되었습니다.
추가 자식 캐시 노드의 구성을 간소화하기 위해 자식 캐시 노드의 구성을 관리할 위치가 하나만 있도록 공유 구성을 사용할 수 있습니다. 그렇지 않으면 CDN/ECN 환경의 모든 자식 캐시 노드에서 위의 구성을 개별적으로 변경해야 합니다. 공유 구성에 대한 자세한 내용은 공유 구성 문서를 참조하세요.
부모 캐시 노드 구성
ARR을 부모 캐시 노드로 구성하는 방법에는 두 가지가 있습니다.
- ARR을 정방향 프록시로 설정합니다.
- 다시 쓰기 맵을 사용하여 ARR을 "역방향" 프록시로 설정합니다.
위의 두 번째 옵션을 사용하더라도 다시 쓰기 맵은 들어오는 호스트 이름을 동일한 값으로 다시 작성하여 효과적으로 전달 프록시로 만듭니다. 다시 쓰기 맵은 위에서 자식 캐시 노드가 구성된 방식과 유사하게 부모 캐시에서 허용할 호스트 이름 목록을 명시적으로 구성하는 데 사용됩니다. 연습의 두 번째 부분에서 부모 캐시 노드는 첫 번째 옵션을 간단한 전달 프록시로 사용하여 구성됩니다.
1단계 - 디스크 캐시 구성
애플리케이션 요청 라우팅에서 디스크 캐시 구성 및 사용 문서에 따라 디스크 캐시를 구성하고 사용하도록 설정합니다.
2단계 - ARR을 전달 프록시로 구성
ARR을 프록시로 사용하도록 설정합니다. IIS 관리자를 시작합니다.
이 구성에는 서버 팜이 포함되지 않습니다. 모든 설정은 서버 수준에서 수행됩니다.
애플리케이션 요청 라우팅 캐시를 두 번 클릭합니다.
작업 창에서 서버 프록시 설정을 클릭합니다.
프록시 사용 확인란을 선택한 다음 적용을 클릭합니다. 서버 수준에서 프록시로 ARR을 사용하도록 설정했습니다.
ARR을 앞으로 프록시로 전환하려면 탐색 창에서 서버 노드를 클릭합니다.
URL 다시 쓰기를 두 번 클릭합니다.
작업 창에서 규칙 추가...를 클릭합니다.
규칙 추가 대화 상자에서 빈 규칙을 선택합니다.
다음 값을 입력한 다음, 규칙을 저장합니다.
이름: 프록시 전달
사용: 와일드 카드
패턴: *
조건:
입력: {HTTP_HOST}
형식: 패턴과 일치
패턴: *
작업 유형: 재작성
URL 다시 쓰기: http://{C:1}/{R:0}부모 캐시 노드 구성이 완료되었습니다.
추가 부모 캐시 노드의 구성을 간소화하기 위해 부모 캐시 노드의 구성을 관리할 위치가 하나만 있도록 공유 구성을 사용할 수 있습니다. 그렇지 않으면 CDN/ECN 환경의 모든 부모 캐시 노드에서 위의 구성을 개별적으로 변경해야 합니다. 공유 구성에 대한 자세한 내용은 다음 문서를 참조하세요 .
요약
이제 고급 URL 다시 쓰기 규칙을 사용하여 2계층 캐시 계층 구조 CDN/ECN 환경에서 자식 캐시 노드 및 부모 캐시 노드를 성공적으로 구성했습니다. 기능을 확인하려면 애플리케이션 요청 라우팅에서 디스크 캐시 구성 및 사용 문서의 4단계 및 5단계를 수행할 수 있습니다. 오류가 있는 경우 실패한 요청 추적 규칙을 사용하여 애플리케이션 요청 라우팅 문제 해결 문서의 단계에 따라 실패한 요청 추적 규칙을 사용하도록 설정합니다.
다른 ARR 버전 2 연습은 애플리케이션 요청 라우팅 버전 2 개요 문서의 문서를 참조하세요.