역방향 프록시란 무엇이며 어떻게 작동합니까?
게시 됨: 2022-08-09
역방향 프록시는 모든 시스템 관리자의 툴킷에서 유용한 도구입니다. 로드 밸런싱, DDOS 공격으로부터의 보호를 포함하여 많은 용도가 있습니다.
역방향 프록시란 무엇입니까?
정방향 프록시라고 하는 일반 프록시는 사용자의 연결이 라우팅되는 서버입니다. 여러 면에서 인터넷 연결 앞에 있는 간단한 VPN과 같습니다. VPN은 이들의 일반적인 예이지만 특정 콘텐츠에 대한 액세스를 차단할 수 있는 학교 방화벽과 같은 것도 포함합니다.
역방향 프록시는 약간 다르게 작동합니다. 시스템 관리자가 사용하는 백엔드 도구입니다. 콘텐츠를 제공하는 웹사이트에 직접 연결하는 대신 NGINX와 같은 역방향 프록시가 중간에 위치할 수 있습니다. 사용자로부터 요청을 받으면 해당 요청을 최종 서버로 전달 또는 "프록시"합니다. 이 서버는 실제로 요청에 응답하기 때문에 "원본 서버"라고 합니다.
사용자는 VPN이나 방화벽과 같은 순방향 프록시를 통해 라우팅되는지 알 수 있지만 역방향 프록시는 백엔드 도구입니다. 사용자가 아는 한, 그들은 단지 웹사이트에 연결하고 있을 뿐입니다. 역방향 프록시 뒤에 있는 모든 것이 숨겨져 있으며 이는 많은 이점도 있습니다.
이 효과는 반대로도 발생합니다. 원본 서버는 사용자와 직접 연결되어 있지 않으며 역방향 프록시의 IP에서 오는 많은 요청만 볼 수 있습니다. 이것은 문제가 될 수 있지만 NGINX와 같은 대부분의 프록시 서비스는 요청에 X-Forwarded-For 와 같은 헤더를 추가합니다. 이 헤더는 클라이언트의 실제 IP 주소를 원본 서버에 알립니다.
역방향 프록시는 무엇에 사용됩니까?
역방향 프록시는 개념상 매우 간단하지만 예기치 않은 사용 사례가 많이 있는 놀라울 정도로 유용한 도구임이 입증되었습니다.
로드 밸런싱
역방향 프록시의 주요 이점 중 하나는 매우 가볍다는 것입니다. 요청을 전달하기만 하기 때문에 특히 데이터베이스를 쿼리해야 하는 상황에서 많은 처리를 수행할 필요가 없습니다.
이것은 병목 현상이 종종 원본 서버임을 의미하지만 그 앞에 역방향 프록시가 있으면 쉽게 여러 원본 서버를 가질 수 있습니다. 예를 들어 프록시는 요청의 50%를 한 서버로 보내고 50%를 다른 서버로 보내 웹사이트 용량을 두 배로 늘릴 수 있습니다. HAProxy와 같은 서비스는 이를 잘 처리하도록 설계되었습니다.
이것은 매우 일반적인 사용 사례이며 Amazon Web Services(AWS)와 같은 대부분의 클라우드 제공업체는 로드 밸런싱을 서비스로 제공하여 직접 설정하는 수고를 덜어줍니다. 클라우드 자동화를 사용하면 "자동 확장"이라고 하는 기능인 트래픽에 응답하여 원본 서버의 수를 자동으로 확장할 수도 있습니다.
AWS의 Elastic Load Balancer와 같은 로드 밸런서는 오리진 서버가 가동 및 중단될 때 자동으로 재구성되도록 설정할 수 있으며, 이 모두는 내부의 역방향 프록시를 통해 가능합니다.
관련: 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 웹 API는 Kestrel이라는 내부 웹 서버를 사용합니다. Kestrel은 요청에 응답하는 데는 뛰어나지만 그 외에는 그다지 많지 않습니다. 개인 포트에서 Kestrel을 실행하고 NGINX를 구성 가능한 역방향 프록시로 사용하는 것은 매우 일반적입니다.
중앙 집중식 로깅
이것은 매우 간단하지만 대부분의 트래픽이 하나의 서비스를 거치면 로그를 쉽게 확인할 수 있습니다. NGINX의 액세스 로그에는 트래픽에 대한 유용한 정보가 많이 포함되어 있으며 Google Analytics와 같은 서비스의 기능을 능가하지는 않지만 있으면 좋은 정보입니다.
관련: 비즈니스를 위한 Elasticsearch 분석 및 모니터링 패널을 설정하는 방법