역방향 프록시란 무엇이며 어떻게 작동합니까?

역방향 프록시는 모든 시스템 관리자의 도구 상자에 있는 유용한 도구입니다. 로드 밸런싱, DDOS 보호를 포함하여 많은 용도가 있습니다.

역방향 프록시란 무엇입니까?

정방향 프록시라고 하는 일반 프록시 서버는 사용자의 연결이 라우팅되는 서버입니다. 여러 면에서 인터넷 연결 앞에 있는 간단한 VPN과 같습니다. VPN이 이에 대한 일반적인 예이지만 여기에는 특정 콘텐츠에 대한 액세스를 차단할 수 있는 학교 방화벽과 같은 것도 포함됩니다.

역방향 프록시는 약간 다르게 작동합니다. 시스템 관리자가 사용하는 내부 도구입니다. 콘텐츠를 제공하는 웹사이트에 직접 연결하는 대신 NGINX와 같은 역방향 프록시가 중간에 위치할 수 있습니다. 사용자로부터 요청을 받으면 해당 요청을 최종 서버로 전달하거나 “프록시”합니다. 이 서버는 요청에 응답할 서버이기 때문에 “원본 서버”라고 합니다.

사용자는 VPN이나 ​​방화벽과 같은 순방향 프록시를 통해 라우팅되는지 알 수 있지만 역방향 프록시는 내부 도구입니다. 사용자가 아는 한, 그들은 단순히 웹사이트에 연결합니다. 역방향 프록시 뒤에 있는 모든 것이 숨겨져 있으며 이 또한 많은 이점이 있습니다.

그러나 이 효과는 반대로도 발생합니다. 원본 서버는 사용자와 직접 연결되어 있지 않으며 역방향 프록시의 IP 주소에서 오는 많은 요청만 볼 수 있습니다. 이것은 문제가 될 수 있지만 NGINX와 같은 대부분의 프록시 서비스  X-Forwarded-For 는 요청에 유형 헤더를 추가합니다. 이 헤더는 클라이언트의 실제 IP 주소를 원본 서버에 알립니다.

역방향 프록시는 무엇에 사용됩니까?

역방향 프록시는 개념상 매우 단순하지만 예상치 못한 많은 사용 사례에서 놀라울 정도로 유용한 도구임이 입증되었습니다.

부하 분산

리버스 프록시의 주요 장점 중 하나는 가벼움입니다. 요청을 전달하기만 하기 때문에 특히 데이터베이스 쿼리를 실행해야 하는 상황에서 많은 처리를 수행할 필요가 없습니다.

즉, 병목 현상이 종종 원본 서버이지만 그 앞에 역방향 프록시가 있으면 쉽게 여러 원본 서버를 가질 수 있습니다. 예를 들어 프록시는 요청의 50%를 한 서버로 보내고 50%를 다른 서버로 보내 웹사이트 대역폭을 두 배로 늘릴 수 있습니다. HAProxy와 같은 서비스가 이에 적합합니다.

이것은 매우 일반적인 사용 사례이며 Amazon Web Services(AWS)와 같은 대부분의 클라우드 제공업체는 로드 밸런싱을 서비스로 제공하므로 직접 설정해야 하는 수고를 덜어줍니다. 클라우드 자동화를 사용하면 “자동 크기 조정”이라는 기능인 트래픽을 기반으로 소스 서버 수를 자동으로 조정할 수도 있습니다.

AWS의 Elastic Load Balancer와 같은 로드 밸런서는 소스 서버가 다운될 때 자동으로 재구성되도록 구성할 수 있으며, 이 모두는 내부의 역방향 프록시를 통해 가능합니다.

캐싱

리버스 프록시는 종종 원본 서버보다 훨씬 빠르게 응답하기 때문에 캐싱이라는 기술은 일반적으로 공유 경로에 대한 요청 속도를 높이는 데 사용됩니다. 캐싱은 페이지 데이터가 역방향 프록시 서버에 저장되고 몇 초/분에 한 번만 원본 서버에서 요청되는 경우입니다. 이렇게 하면 원본 서버의 부하가 크게 줄어듭니다.

예를 들어 현재 읽고 있는 이 기사는 기사의 내용과 메타데이터를 가져오기 위해 SQL 데이터베이스에 액세스해야 하는 WordPress에서 제공한 것입니다. 페이지가 실제로 변경되지 않는다는 점을 감안할 때 모든 페이지 새로 고침에 대해 이 작업을 수행하는 것은 낭비입니다. 이렇게 하면 이 경로를 캐시할 수 있고 역방향 프록시는 WordPress를 다시 귀찮게 하는 대신 다음 사용자에게 마지막 응답을 보냅니다.

콘텐츠를 캐시하는 역방향 프록시 서버의 전용 네트워크를 콘텐츠 전송 네트워크 또는 CDN이라고 합니다. CloudFlare 또는 Fastly 와 같은 CDN은 글로벌 전송 속도를 높이기 위해 대규모 웹사이트에서 매우 일반적으로 사용됩니다. 콘텐츠를 캐시하는 전 세계 서버를 “에지 노드”라고 하며 많은 서버가 사이트를 매우 빠르게 만들 수 있습니다.

네트워크 보안 및 개인 정보 보호

사용자는 역방향 프록시 뒤에 무엇이 있는지 모르기 때문에 쉽게 원본 서버를 직접 공격할 수 없습니다. 실제로 역방향 프록시는 일반적으로 사설 서브넷의 원본 서버와 함께 사용됩니다. 즉, 외부 인터넷으로 들어오는 연결이 전혀 없습니다.

이렇게 하면 네트워크 구성이 비공개로 유지되고 은폐를 통한 보안은 결코 신뢰할 수 없지만 공격에 노출된 상태로 두는 것보다 낫습니다.

이러한 고유한 신뢰는 네트워크를 계획할 때도 도움이 될 수 있습니다. 예를 들어 데이터베이스와 상호 작용하는 API 서버는 역방향 프록시와 같습니다. 데이터베이스는 프라이빗 서브넷의 API 서버를 신뢰할 수 있고 API 서버는 데이터베이스에 대한 방화벽 역할을 하여 유효한 연결만 허용한다는 것을 알고 있습니다.

사용자 정의 가능한 인터페이스

NGINX와 같은 역방향 프록시의 장점 중 하나는 설정이 쉽다는 것입니다. 이러한 서비스에 대한 사용자 액세스를 구성하기 위해 다른 서비스 앞에 두는 것이 종종 유용합니다.

예를 들어 NGINX는 특정 경로에 대한 요청을 제한할 수 있어 공격자가 단일 IP 주소에서 원본 서버에 수천 건의 요청을 하는 것을 방지할 수 있습니다. DDOS 공격을 막지는 않지만 좋은 일입니다.

NGINX는 사용자 정의 “서버” 블록을 사용하여 여러 도메인 이름의 트래픽을 리디렉션할 수도 있습니다. 예를 들어, example.com 원본 서버에 요청을 보낼 api.example.com 수 있지만 사용자 지정 API 서버 또는 files.example.com 파일 저장소 등으로 보낼 수 있습니다. 각 서버에는 고유한 구성 및 규칙이 있을 수 있습니다.

NGINX는 중앙 집중식 HTTPS 인증서 및 헤더 구성과 같은 기존 원본 서버에 추가 기능을 추가할 수도 있습니다.

때로는 NGINX를 다른 로컬 서비스와 동일한 시스템에 두어 해당 서비스의 콘텐츠를 제공하는 것이 유용합니다. 예를 들어 ASP.NET Web API는 응답성이 좋은 Kestrel이라는 내부 웹 서버를 사용하지만 그 이상은 아닙니다. 개인 포트에서 Kestrel을 실행하고 NGINX를 사용자 지정 역방향 프록시로 사용하는 것은 매우 일반적입니다.

중앙 집중식 로깅

매우 간단하지만 대부분의 트래픽이 단일 서비스를 거치므로 로그를 쉽게 확인할 수 있습니다. NGINX 액세스 로그에는 트래픽에 대한 유용한 정보가 많이 포함되어 있으며 Google Analytics와 같은 서비스보다 성능이 좋지는 않지만 유용한 정보입니다.