[Linux] 프록시 서버의개념, NGINX 리버스 프록시와 캐싱

리버스 프록시란 무엇인가?

리버스 프록시는 웹 서버 앞에 위치하며 클라이언트(예: 웹 브라우저) 요청을 해당 웹 서버로 전달하는 서버이다다. 리버스 프록시는 일반적으로 보안 , 성능 및 안정성을 높이는 데 도움이 되도록 구현된다. 리버스 프록시의 작동 방식과 제공할 수 있는 이점을 더 잘 이해하기 위해 먼저 프록시 서버가 무엇인지 정의해 보겠다.

프록시 서버란 무엇인가?

프록시, 프록시 서버 또는 웹 프록시라고도 하는 정방향 프록시는 클라이언트 시스템 그룹 앞에 있는 서버이다. 이러한 컴퓨터가 인터넷의 사이트 및 서비스에 요청을 하면 프록시 서버는 해당 요청을 가로챈 다음 중개인처럼 해당 클라이언트를 대신하여 웹 서버와 통신한다.

예를 들어 일반적인 정방향 프록시 통신과 관련된 3대의 컴퓨터 이름을 지정해 보겠다.

• A: 이것은 사용자의 가정용 컴퓨터이다.
• B: 순방향 프록시 서버이다.
• C: 웹사이트의 원본 서버(웹사이트 데이터가 저장되는 곳)

표준 인터넷 통신에서 컴퓨터 A는 컴퓨터 C에 직접 연결되며 클라이언트는 원본 서버에 요청을 보내고 원본 서버 는 클라이언트에 응답한다. 순방향 프록시가 있으면 A는 대신 B로 요청을 보내고 B는 요청을 C로 전달한. 그런 다음 C는 B로 응답을 보내고 B는 응답을 다시 A로 전달한다.

왜 인터넷 활동에 이 중개서버를 추가하는 이유가 뭘까 순방향 프록시를 사용하려는 몇 가지 이유가 있다.

• 주 또는 기관의 브라우징 제한을 피하기 위해 - 일부 정부, 학교 및 기타 조직에서는 방화벽을 사용하여 사용자가 제한된 버전의 인터넷에 액세스할 수 있도록 한다. 정방향 프록시를 사용하면 사용자가 방문하는 사이트에 직접 연결하는 대신 프록시에 연결할 수 있으므로 이러한 제한을 피할 수 있다.
• 특정 콘텐츠에 대한 액세스를 차단하려면 - 반대로 사용자 그룹이 특정 사이트에 액세스하지 못하도록 프록시를 설정할 수도 있다. 예를 들어 학교 네트워크는 콘텐츠 필터링 규칙을 활성화하는 프록시를 통해 웹에 연결하도록 구성되어 Facebook 및 기타 소셜 미디어 사이트의 응답 전달을 거부할 수 있다.
• 온라인에서 자신의 신원을 보호하기 위해 - 경우에 따라 일반 인터넷 사용자는 단순히 온라인에서 익명성이 증가되기를 원하지만, 다른 경우에는 인터넷 사용자가 정부가 정치적 반체제 인사에게 심각한 결과를 부과할 수 있는 장소에 살고 있다. 웹 포럼이나 소셜 미디어에서 정부를 비판하는 것은 이러한 사용자에게 벌금이나 구금으로 이어질 수 있다. 이러한 반체제 인사 중 한 명이 순방향 프록시를 사용하여 정치적으로 민감한 댓글을 게시하는 웹사이트에 연결하면 댓글을 게시하는 데 사용된 IP 주소 로 반체제 인사를 역추적하기가 더 어려워진다. 프록시 서버의 IP 주소만 표시된다.

 

 

리버스 프록시는 어떻게 다른가?

리버스 프록시는 하나 이상의 웹 서버 앞에 위치하여 클라이언트의 요청을 가로채는 서버이다. 이것은 프록시가 클라이언트 앞에 있는 정방향 프록시와 다르다. 리버스 프록시를 사용하면 클라이언트가 웹사이트의 원본 서버에 요청을 보낼 때 리버스 프록시 서버가 네트워크 에지 에서 해당 요청을 가로챈다. 그런 다음 리버스 프록시 서버는 원본 서버에 요청을 보내고 응답을 받는다.

정방향 프록시와 역방향 프록시의 차이점은 미묘하지만 중요하다. 간단히 요약하면 정방향 프록시가 클라이언트 앞에 있으며 원본 서버가 특정 클라이언트와 직접 통신하지 않도록 한다. 반면에 리버스 프록시는 원본 서버 앞에 위치하며 어떤 클라이언트도 해당 원본 서버와 직접 통신하지 않도록 한다.

다시 한 번 관련 컴퓨터의 이름을 지정하여 설명하겠다.

• D: 임의 개수의 사용자 가정용 컴퓨터
• E: 리버스 프록시 서버이다.
• F: 하나 이상의 원본 서버

일반적으로 D의 모든 요청은 F로 직접 이동하고 F는 D로 직접 응답을 보낸다. 리버스 프록시를 사용하면 D의 모든 요청은 E로 직접 이동하고 E는 F로 요청을 보내고 응답을 받는다. E는 그런 다음 적절한 응답을 D에 전달한다.

리버스 프록시의 장점

• 로드 밸런싱 - 매일 수백만 명의 사용자를 확보하는 인기 있는 웹사이트는 단일 원본 서버로 들어오는 모든 사이트 트래픽을 처리하지 못할 수 있다. 대신, 사이트는 동일한 사이트에 대한 요청을 모두 처리하는 서로 다른 서버 풀에 분산될 수 있다. 이 경우 리버스 프록시는 단일 서버가 과부하되는 것을 방지하기 위해 서로 다른 서버 간에 들어오는 트래픽을 균등하게 분배하는 로드 밸런싱 솔루션을 제공할 수 있다. 서버가 완전히 실패하는 경우 다른 서버가 트래픽을 처리하기 위해 나설 수 있다.
• 공격으로부터 보호 - 역방향 프록시를 사용하면 웹 사이트나 서비스에서 원본 서버의 IP 주소를 공개할 필요가 없다. 이로 인해 공격자가 DDoS 공격 과 같은 표적 공격을 활용하기가 훨씬 더 어려워진다. 대신 공격자는 Cloudflare의 CDN 과 같은 리버스 프록시만 대상으로 삼을 수 있다. 이 프록시 는 사이버 공격을 방어할 수 있는 더 강력한 보안과 더 많은 리소스를 갖추고 있다.
• GSLB( Global Server Load Balancing ) - 이 형태의 로드 밸런싱에서는 웹 사이트를 전 세계 여러 서버에 배포할 수 있으며 역방향 프록시는 클라이언트를 지리적으로 가장 가까운 서버로 보낸다. 이렇게 하면 요청 및 응답이 이동하는 데 필요한 거리가 줄어들어 로드 시간이 최소화된다.
• 캐싱 - 리버스 프록시는 콘텐츠를 캐싱할 수 있으므로 성능 이 더 빨라진다. 예를 들어, 파리에 있는 사용자가 로스앤젤레스에 있는 웹 서버가 있는 리버스 프록시 웹 사이트를 방문하는 경우 사용자는 실제로 파리에 있는 로컬 리버스 프록시 서버에 연결한 다음 LA에 있는 원본 서버와 통신해야 한다. 프록시 서버 그러면 응답 데이터를 캐시(또는 임시 저장)할 수 있다. 이후 사이트를 탐색하는 파리 사용자는 파리에있는 리버스 프록시 서버에서 로컬로 캐시된 버전을 가져오므로 성능이 훨씬 빨라진다.
• SSL 암호화 - 각 클라이언트에 대한 SSL (또는 TLS ) 통신을 암호화 하고 해독 하는 것은 원본 서버에 계산 비용이 많이 들 수 있다. 들어오는 모든 요청을 해독하고 모든 나가는 응답을 암호화하도록 역방향 프록시를 구성하여 원본 서버의 귀중한 리소스를 확보할 수 있다.

 

프록시 서버에대해 알았으니 NGINX를 이용해서 리버스 프록시 서버를 구축해보겠다

 

 

프록시 서버로의 요구 전달

NGINX는 요청을 프록시할 때 지정된 프록시 서버로 요청을 전송하고 응답을 가져와 클라이언트에 반환한다.지정된 프로토콜을 사용하여 HTTP 서버(다른 NGINX 서버 또는 다른 서버) 또는 비 HTTP 서버(PHP 또는 Python과 같은 특정 프레임워크로 개발된 애플리케이션을 실행할 수 있음)에 요청을 프록시할 수 있다.지원되는 프로토콜에는 FastCGI, uwsgi, SCGI 및 memcached가 포함된다.

HTTP 프록시 서버에 요청을 전달하려면 위치 location에서 proxy_pass 디렉티브를 지정한다.예를 들어 다음과 같다.

location / {
		proxy_pass <대리할 서버>;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
}

proxy_set_header Host $host는 클라이언트 요청 헤더에 아무것도 전달되지 않을때 $host 변수를 사용해서 이 값은 "Host" 요청 헤더 필드의 서버 이름과 같거나 이 필드가 없으면 기본 서버 이름과 같으며 헤더에 전달 할 수있다.

proxy_set_header X-Real-IP $remote_addr; 실제 접속자의 IP를 X-Real-IP 헤더에 입혀서 전송한다

위의 location처럼 했다면 대리할 서버가 프록시되어 curl localhost:<listen port>를 하게되면 대리한 서버가 요청된걸 확인 할 수있다.

 

NGINX 콘텐츠캐싱

프록시된 웹 및 응용 프로그램 서버에서 정적 및 동적 컨텐츠를 모두 캐시하여 클라이언트에 신속하게 전달하고 서버의 부하를 줄인다.

캐시가 활성화되면 NGINX Plus는 응답을 디스크 캐시에 저장하고 매번 동일한 콘텐츠에 대한 요청을 프록시하지 않고도 클라이언트에 응답하는 데 사용한다.

캐시를 활성화하려면 최상위 수준에 지시문을 포함해야한다. http {}맥락.필수 첫 번째 파라미터는 캐시된 콘텐츠의 로컬파일 시스템 경로이며 필수 파라미터는keys_zone파라미터는 캐시된 항목에 대한 메타데이터를 저장하기 위해 사용되는 공유 메모리존의 이름과 크기를 정의한다.

http {
	proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=10g inactive=5s use_temp_path=off;	
    server {
        location / {
                proxy_cache mycache;
                proxy_pass <대리할 서버>
                proxy_cache_valid  200 5s;
	        add_header X-Cache-Status $upstream_cache_status;
                add_header Cache-Control "public";
        }   	    
    }   
}

• 캐시의 로컬 디스크 디렉토리를 /var/cache/nginx/라고 한다.
• levels는 /var/cache/nginx/아래에 2레벨의 디렉토리 계층을 설정합니다.단일 디렉터리에 많은 파일이 있으면 파일 액세스 속도가 느려질 수 있으므로 대부분의 배포에서 2단계 디렉터리 계층을 사용하는 것이 좋다.이 경우,levels파라미터는 포함되지 않는다.NGINX는 모든 파일을 같은 디렉토리에 저장한다.
• keys_zone는 캐시 키 및 사용 타이머 등의 메타데이터를 저장하기 위한 공유 메모리존을 설정한다.메모리에 키의 복사가 있는 것으로써, NGINX는, 요구가 confirst-module/module/module/module/module/module/mHIT또는MISS디스크로 이동할 필요 없이 검사 속도를 크게 높일 수 있다.1MB 영역에는 약 8,000개의 키에 대한 데이터를 저장할 수 있으므로 예제에서 구성한 10MB 영역에는 약 80,000개의 키에 대한 데이터를 저장할 수 있다.
• max_size는 캐시 크기의 상한(이 예에서는 10기가바이트)을 설정한다. 값을 지정하지 않으면 사용 가능한 모든 디스크 공간을 사용하도록 캐시를 확장할 수 있다.캐시 크기가 제한에 도달하면 캐시 관리자라고 하는 프로세스가 캐시 크기를 제한 아래로 되돌리기 위해 가장 최근에 사용된 파일을 제거한다.
• inactive항목을 액세스하지 않고 캐시 내에 유지할 수 있는 기간을 지정한다.이 예에서는 60분 동안 요청되지 않은 파일은 만료 여부에 관계없이 캐시 관리자 프로세스에 의해 캐시에서 자동으로 삭제된다. 기본값은 10분이다(10m비활성 콘텐츠는 유효기간이 지난 콘텐츠와 다르다. NGINX는 캐시 제어 Cache-Control:max-age=120헤더에 의해 정의된 대로 만료된 콘텐츠를 자동으로 삭제하지 않는다.
• NGINX는 먼저 캐시를 수신처로 하는 파일을 임시 스토리지 영역에 쓰고,use_temp_path=off디렉티브는 NGINX가 캐시되는 디렉토리와 동일한 디렉토리에 쓰도록 지시한다 .이 파라미터는 다음과 같이 설정하는 것이 좋다. off파일 시스템 간에 불필요한 데이터 복사를 방지한다.
• proxy_cache_valid 기본적으로 캐싱할 response code 와 시간을 정의한다. 여기서는 200응답 상태를 5초캐싱한다

add_header X-Cache-Status $upstream_cache_status;
# NGINX 캐시를 측정 하기위해 클라이언트에 대한 응답에 HTTP 헤더를 추가한다

• MISS– 캐시에서 응답을 찾을 수 없으므로 오리진 서버에서 가져왔다.
• BYPASS– 요구와 일치하기 때문에 캐시에서 처리되지 않고 원래 서버에서 응답을 가져왔다.
• EXPIRED– 캐시의 엔트리가 만료되었다.응답에 오리진 서버의 새로운 콘텐츠가 포함되어 있다.
• STALE– 원본 서버가 올바르게 응답하지 않아 컨텐츠가 오래되었다.proxy_cache_use_stale가 설정되었다.
• UPDATING– 이전 요청에 따라 현재 엔트리가 업데이트되고 있기 때문에 콘텐츠가 오래되었다.proxy_cache_use_stale updating가 설정되어 있다.
• REVALIDATED– 그proxy_cache_revalidate디렉티브가 네이블로 되어 있어 NGINX가 현재 캐시된 콘텐츠가 아직 If-Modified-Since유효한 것을 확인했다.
• HIT– 응답에는 캐시에서 직접 유효한 새로운 콘텐츠가 포함된다.

위에 나와있는 것처럼 캐싱을 세팅했다면 

curl 명령어로 확인해본다면 이 명령어를 최초 입력, 2번째 입력, 그로부터 5초후 입력 → 3번에 걸쳐 입력한 후 확인하면 X-cache-status 값이 3번 다 다르게 나온 것을 확인할 수 있다.

 

 

 

 

https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

NGINX Reverse Proxy | NGINX Plus

https://www.nginx.com/blog/nginx-caching-guide/

A Guide to Caching with NGINX and NGINX Plus - NGINX

 

http://nginx.org/en/docs/dirindex.html

Alphabetical index of directives

https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/