Skip To Content

역방향 프록시 또는 로드 밸런서를 통한 포털 통합

역방향 프록시 서버 또는 로드 밸런서는 일반적으로 경계 네트워크(비무장지대[DMZ] 또는 스크린된 서브넷이라고도 함) 내에서 배포되는 어플라이언스로, 인터넷에서 요청을 처리하고 이를 내부 네트워크에 있는 머신으로 전달합니다. 역방향 프록시 서버를 대신하여 요청을 전달하면 조직의 방화벽 뒤에 있는 머신의 ID를 마스크하므로 내부 사용자의 직접 공격으로부터 내부 머신을 보호합니다. 추가 보안 기능이 역방향 프록시 서버에서 구현되어 외부 사용자로부터 내부 네트워크를 추가로 보호할 수 있습니다.

역방향 프록시 서버 또는 로드 밸런서가 상태 확인 기능을 지원하는 경우 Portal for ArcGIS 상태 확인 엔드포인트를 통해 요청을 수신하는 데 포털을 사용할 수 있는지 확인할 수 있습니다. 사이트에서 소프트웨어 또는 하드웨어 오류가 발생했는지를 빠르게 확인하려는 경우 이 기능이 유용합니다. 자세한 내용은 상태 확인을 참고하세요.

주의:

이 항목에 설명된 구성은 ArcGIS Server 사이트를 포털과 페더레이션하기 전에 수행해야 합니다. ArcGIS Server 사이트가 포털과 페더레이션된 후 DNS 별칭 또는 역방향 프록시를 추가하는 것은 지원되지 않습니다. 기관 URL에서 호스트 이름을 변경해야 하는 경우 Esri 컨설팅 서비스 또는 다른 신뢰할 수 있는 컨설팅 파트너에게 문의하세요.

ArcGIS Server 사이트의 페더레이션 해제는 몇 가지 중대한 결과를 초래하며 쉽게 실행 취소되지 않습니다. 자세한 내용은 페더레이션된 서버 관리를 참고하세요.

로드 밸런서 유형

역방향 프록시는 가끔 로드 밸런서라고도 하지만 일반적으로 백엔드 대상 간에 수신되는 메시지를 배포하는 것 외에 더 많은 기능을 제공합니다. 많은 역방향 프록시 서버 구현은 구성에 따라 아래에 설명된 유형 중 하나로 작동할 수 있습니다.

로드 밸런싱 작업은 작동되는 개방형 시스템 간 상호 연결(OSI) 모델의 레이어에 따라 구분되는 경우가 많습니다. 기존 로드 밸런서 기술을 통합할 때는 배포의 전체 아키텍처에 영향을 미치므로 구현 중인 유형을 파악하는 것이 중요합니다.

레이어 3/4 로드 밸런서는 네트워크 또는 패킷별 로드 밸런서라고도 합니다. 이러한 로드 밸런서는 일반적으로 수신되는 트래픽을 검사하지 않고 수신되는 TCP/UDP 패킷을 백엔드 대상으로 라우팅합니다. 최신 구현에서는 로드 밸런서에서 SSL을 종료할 수 있지만 클라이언트 SSL 세션은 일반적으로 백엔드 대상 서버와 함께 설정됩니다.

레이어 7 로드 밸런서는 응용프로그램 또는 응용프로그램 인지 로드 밸런서라고도 합니다. 이러한 로드 밸런서는 수신되는 메시지를 검사하고 여러 요소를 기반으로 라우팅 의사결정을 내릴 수 있으며, 메시지를 백엔드 대상에 프록시하기 전에 해당 메시지의 내용을 수정할 수 있습니다. HTTPS를 사용하는 레이어 7 로드 밸런서는 클라이언트와의 SSL 커뮤니케이션을 종료하고 백엔드 HTTPS 대상에 대한 요청을 프록시하기 전에 해당 트래픽을 다시 암호화합니다.

역방향 프록시 서버 또는 로드 밸런서 준비

기관의 역방향 프록시 서버에 Portal for ArcGIS를 추가하기 전에 다음 사항을 완료해야 합니다.

  • 역방향 프록시 서버에서 HTTPS(HTTP, HTTPS나 HTTPS 전용)를 구성합니다. Portal for ArcGIS에서는 통신에 HTTPS가 기본 설정으로 사용됩니다. HTTPS를 설정하는 방법은 프록시 서버의 제품 설명서를 참고하세요.
비고:

Portal for ArcGIS에서는 역방향 프록시 서버/로드 밸런서를 통한 SSL 오프로드를 지원하지 않습니다. 따라서 역방향 프록시 서버를 사용하여 구성하는 경우 트래픽을 ArcGIS Web Adaptor로 전달하거나 HTTPS를 통해 Portal for ArcGIS로 직접 전달해야 합니다.

비고:

역방향 프록시 서버의 컨텍스트 이름은 하나의 URL 수준까지만 설정해야 합니다. 예를 들어 https://proxy.domain.com/enterprise와 같은 역방향 프록시 URL은 사용할 수 있지만 https://proxy.domain.com/myorg/enterprise는 역방향 프록시 URL로 사용할 수 없습니다.

프록시 서버가 gzip 인코딩을 지원하며 Accept-Encoding 헤더를 허용하도록 구성되었는지 확인합니다. 이 헤더를 통해 gzip 인코딩을 사용하여 HTTP 1.1 응답을 압축할 수 있습니다. 예를 들어 헤더가 허용되는 경우 Map Viewer Classic를 불러오는 요청은 약 1.4MB로 압축된 응답을 브라우저에 반환합니다. 헤더가 허용되지 않거나 무시되는 경우 요청은 약 6.8MB의 압축되지 않은 응답을 브라우저에 반환합니다. 네트워크 속도가 느린 상태에서 응답이 압축되지 않았다면 Map Viewer Classic를 불러오는 데 시간이 오래 걸릴 수 있습니다. 따라서 Esri는 이 헤더를 역방향 프록시 서버 구성의 일부로 허용하는 것을 권장합니다.

레이어 3/4 로드 밸런서

로드 밸런서는 기본 HTTPS 포트에서 수신하고 트래픽을 ArcGIS Web Adaptor에 전달하거나 7443 포트의 Portal for ArcGIS 머신에 직접 전달해야 합니다. Portal for ArcGIS 내부 웹 서버에서 클라이언트 SSL 세션을 종료할 때 해당 웹서버에서 제공하는 SSL 인증서가 DNS 별칭 및 사이트에 있는 머신의 FQDN 모두에 유효한지 확인하여 인증서 신뢰 문제를 방지합니다. 이는 일반적으로 SSL 인증서에 대한 주체 대체 이름을 사용하여 수행할 수 있습니다.

비고:

ArcGIS Web Adaptor를 사용하지 않는 경우 사이트에 기본 컨텍스트(/arcgis)를 사용해야 합니다. 동일한 레이어 3/4 로드 밸런서에서 다중 Portal for ArcGISArcGIS Server 사이트를 통합할 때 각 사이트에 고유한 DNS 레코드를 사용해야 하며 적절한 백엔드 대상으로 트래픽을 라우팅하는 데 사용되는 SNI(Server Name Identification)를 사용해야 합니다.

레이어 7 로드 밸런서

로드 밸런서 구성에서 X-Forwarded-Host 헤더를 사이트의 DNS 별칭에 대한 호스트 이름으로 설정해야 합니다. Portal for ArcGIS는 역방향 프록시에서 전송한 헤더에 이 등록정보가 설정되어 있다고 간주하여 역방향 프록시 서버의 URL과 일치하는 요청을 반환합니다. 포털에서 ArcGIS Web Adaptor를 사용하지 않는 경우 Portal for ArcGIS가 설치된 머신의 호스트 이름과 로드 밸런서에 의해 설정된 Host 헤더가 일치하는지 확인합니다.

팁:

포털 관리자 디렉터리의 머신 엔드포인트를 사용하여 Portal for ArcGIS를 실행 중인 머신의 호스트 이름을 볼 수 있습니다.

예를 들어 ArcGIS 포털 디렉터리에 대한 요청(https://dnsalias.domain.com/arcgis/sharing/rest)은 동일한 URL로 클라이언트에 반환됩니다. 등록정보가 설정되지 않은 경우 Portal for ArcGIS는 요청이 전달되는 내부 머신의 URL을 반환할 수도 있습니다(예시: https://dnsalias.domain.com/arcgis/sharing/rest 대신 https://portal.domain.com/arcgis/sharing/rest). 클라이언트가 이 URL에 접근할 수 없을 때는 문제가 발생합니다(일반적으로 브라우저 404 오류라고 함). 또한 클라이언트가 내부 머신의 일부 정보에 대한 접근 권한을 부여받게 됩니다.

X-Forwarded-Host 헤더와 함께 로드 밸런서는 재전송(HTTP 응답 코드 301 또는 302)할 수 있어야 합니다. 모든 Location 헤더는 응답의 정규화된 도메인 이름(FQDN)과 컨텍스트가 포털의 WebContextURL 값과 일치하도록 로드 밸런서에 다시 작성해야 합니다.

포털 추가

다음 섹션에서는 기관의 역방향 프록시 서버에 Portal for ArcGIS를 추가하는 방법에 대해 설명합니다.

레이어 3/4 로드 밸런서: 로드 밸런서 구성에 ArcGIS Web Adaptor 또는 Portal for ArcGIS 머신 추가

백엔드 대상에 대한 트래픽 프록시는 TCP를 통해 발생하기 때문에 각 사이트의 머신을 로드 밸런서 구성에 추가해야 합니다. ArcGIS Web Adaptor를 사용하는 경우 백엔드 대상은 Web Adaptor를 호스팅하는 웹서버(일반적으로 443 또는 8443)의 포트를 가리켜야 합니다. 트래픽을 Portal for ArcGIS에 직접 프록시할 때 백엔드 대상은 사이트의 각 머신에서 7443 포트를 가리켜야 합니다.

레이어 7 로드 밸런서: 프록시 서버 지시문에 ArcGIS Web Adaptor 또는 Portal for ArcGIS 머신 추가

Portal for ArcGIS에서 ArcGIS Web Adaptor를 구성한 후, 컴포넌트를 직접 프록시 서버 지시문에 추가하여 ArcGIS Web Adaptor를 내 기관의 역방향 프록시 서버로 사용할 수 있습니다. 예를 들어 Apache를 역방향 프록시로 사용하는 경우 Apache 웹서버 구성 파일 httpd.conf에서 ProxyPass 지시문에 ArcGIS Web Adaptor를 추가해야 합니다.

ProxyPass /webadaptorname https://webadaptorhost.domain.com/webadaptorname
ProxyPassReverse /webadaptorname https://webadaptorhost.domain.com/webadaptorname

ProxyPass 지시문은 ArcGIS Web Adaptor에 지정된 이름과 일치해야 합니다(위의 샘플에서는 /webadaptorname). Portal for ArcGIS 앞에 ArcGIS Web Adaptor를 사용하지 않는 경우 /context가 선택한 URL 최상위 경로인 다음 지시문을 추가합니다.

ProxyPass /context https://portal.domain.com:7443/arcgis
ProxyPassReverse /context https://portal.domain.com:7443/arcgis

역방향 프록시 또는 로드 밸런서를 사용하도록 포털 구성

다음 섹션에서는 역방향 프록시 서버 URL을 사용하도록 포털을 구성하는 방법과 URL 구성 후 다시 수행해야 하는 관리 작업에 대해 설명합니다.

WebContextURL 속성 설정

포털의 WebContextURL 속성을 설정하면 최종 사용자에게 보내는 모든 리소스에서 올바른 URL을 구성할 수 있습니다. WebContextURL을 변경하려면 다음과 같이 하세요.

  1. 웹 브라우저를 열고 포털 관리자 디렉터리에 기관의 기본 관리자 역할 구성원으로 로그인합니다. URL의 형식은 https://portal.domain.com:7443/arcgis/portaladmin입니다.
  2. 시스템 > 등록정보 > 등록정보 업데이트를 클릭합니다.
  3. 시스템 등록정보 업데이트 대화 상자에서, 역방향 프록시 서버 또는 내 기관 방화벽의 외부 사용자에게 보이는 DNS 별칭 URL을 대체하면서 다음 JSON을 삽입합니다.
    {
       "WebContextURL": "https://dnsalias.domain.com/portal"
    }
    비고:

    Portal for ArcGIS단일 기관 URL만 지원합니다.

    비고:

    WebContextURL 등록정보를 설정할 때 비표준 포트(즉, 443 이외의 포트)를 사용할 수 없습니다.

  4. 등록정보 업데이트를 클릭합니다.

관리 작업 다시 실행

포털에서 역방향 프록시 서버를 구성하고 나면 이제 ArcGIS Web Adaptor URL 대신 역방향 프록시 서버 URL을 통해 포털에 접근합니다. 포털 또는 포털 관리자 디렉터리에서 접근하는 모든 항목이 역방향 프록시 서버 URL을 반환합니다.

다음 관리 작업은 역방향 프록시 서버 URL을 사용하여 다시 완료해야 합니다.

이전에 보안 서비스를 포털에서 항목으로 추가한 경우 기존 항목을 삭제하고 다시 추가해야 합니다. 이는 기존 항목이 역방향 프록시 서버 URL 대신 ArcGIS Web Adaptor URL을 사용하기 때문입니다. 자세한 내용은 보안 서비스 연결을 참고하세요.

포털에 역방향 프록시 서버를 구성한 후에는 서버의 설정을 조정해야 할 수 있습니다. 예를 들어 배포 내의 작업이나 요청이 연결 시간 초과 오류로 실패할 경우 역방향 프록시 서버의 시간 초과 값이 너무 짧은 것이 문제일 수 있습니다. 이 오류를 수정하려면 서버 페더레이션 등의 장기 실행 요청이 완료될 수 있도록 시간 초과 값을 늘려보세요.