[Nginx] Nginx와 프록시

2021. 10. 29. 09:46개발공부/DevOps

Nginx와 프록시

클라이언트 레이어(vue, javascript, react...등)서비스를 빌드 하는데엔 여러 방법이 있습니다. 회사 서비스를 테스트 서버에 빌드 후 실행하는 작업을 앞두고 있어서 관련 medium 아티클을 참고해보려 합니다.

Vue와 Java(Spring boot)서버를 빌드/실행하는 방법 중 Vue static content를 NGINX 웹 서버를 이용해 빌드하는 방법을 택했습니다. NGINX는 웹 서버를 실행시키고, 프록싱, 캐싱, 로드 밸런싱, 미디어 스트리밍등을 위한 오픈 소스 소프트웨어 입니다. 웹 서버의 성능 최적화를 위해 디자인 되었습니다. 또한 HTTP 서버 가용성은 email(IMAP, POP3, SMTP)를 위한 기능으로 사용할 수 있으며 HTTP, TCP, UDP 서버들의 리버스 프록시, 로드 밸런서가 되어 줄 수 있습니다.

reverse proxy란 클라이언트가 웹 서버에 접근하기 전 위치하여 요청들을 웹 서버로 포워딩 해주는 서버 입니다. 주로 보안, 성능, 안정성을 위해 사용됩니다. 이해를 위해선 프록시 서버를 알아야 합니다.

프록시 서버는 보통 프록시, 프록시 서버, 웹 프록시라고 불리는데 클라이언트 그룹 앞에 위치합니다.(리버스 프록시는 웹 서버 앞에 위치, 사진 참고)이 서버에 도달하기 전 경로에 위치하는 서버입니다. 클라이언트에서 사이트나 서비스에 요청을 보내면 프록시 서버가 요청들을 인터셉트 해 웹 서버와 통신합니다. 즉, 클라이언트들의 요청을 대신해주는 중개자 미들맨 역할로 볼 수 있습니다. 그럼 프록시가 왜 필요할까요?

프록시를 사용하는 이유는 크게 3가지 입니다. 첫째, 정부나 공공기관의 방화벽을 회피하기 위해서 씁니다. 기관들은 방화벽을 이용하기 때문에 인터넷 버전에 제한이 있기도 합니다. 하지만 프록시를 사용하면 이런 제한들을 우회해 클라이언트가 접근할 수 있도록 도와줍니다.

둘째, 앞의 이유와는 반대로 특정 클라이언트의 접근을 막기 위해서도 사용합니다. 예를 들어 학교에서 사용하는 교내 네트워크는 컨텐츠 필터링 기능 적용해 페이스북이나 SNS 사이트 접근을 막을수도 있습니다.

마지막으로 IP를 추적한 개인정보 유출을 방지할 수 있습니다.

프록시 서버

image

[출처: https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/]

리버스 프록시 서버

image

[출처: https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/]

리버스 프록시는 일반 프록시와 어떤점이 다를까요?

첫번째로 클라이언트의 요청을 인터셉트 하는 위치가 다릅니다. 프록시는 클라이언트 앞에 위치하지만 리버스 프록시는 하나 또는 다수의 웹 서버 앞에 위치합니다. 따라서 클라이언트가 origin server에 요청을 보내면 network edge에서 리버스 프록시 서버가 인터셉트 해줍니다. 리버스 프록시가 인터셉트 한 요청은 origin server로 보낸 다음 리턴된 응답을 다시 클라이언트로 보내줍니다.

프록시와 리버스 프록시의 차이점은 복잡하지만 중요합니다. 간단히 말하면 프록시는 클라이언트 앞에 위치해 origin server가 클라이언트와 직접 통신하지 않도록 하는 역할을 합니다. 반면 리버스 프록시는 origin server 앞에 위치해 클라이언트가 origin server와 직접 통신하지 않도록 합니다. 말장난인 것 같지만, 위에서 말한 프록시 서버 예시(접근 우회, 접근 보안 등)를 읽어보시면 이해가 되실 겁니다.

Reverse Proxy Flow에서 볼 수 있듯이 프록시를 사용하지 않으면 D에서 F로 직접 요청, 응답이 일어납니다. 하지만 리버스 프록시를 사용하면 D가 E로 직접 요청을 보내고 E(리버스 프록시)가 F에 직접 요청을 보낸다음 응답을 받아 다시 D로 공유하는 방식으로 변경됩니다.

이렇게 하는 이유는 무엇일까요? 클라이언트 애플리케이션에서 nginx를 사용하지 않고, 직접 서버 호스트 IP에 요청하고 응답을 받으면 안되는 걸까요? 아래는 리버스 프록시를 사용했을 때의 이점입니다.

Load balancing(로드 밸런싱)

하루에 수백만 유저들이 접속하는 웹사이트는 single origin server로 감당하지 못합니다. 여러 서버를 두고 되는데 하나의 사이트로부터 요청이 오면 여러 서버에 나눠서 응답을 할당하고 다시 응답을 클라이언트에 줘야합니다. 리버스 프록시는 로드 밸런싱 기능을 제공해 유입되는 트래픽을 균등하게 서버들에 할당해줄 수 있습니다.

해킹공격 보호

리버스 프록시가 있으면 웹사이트나 서비스는 실제 서버의 IP 주소를 외부에 공개하지 않아도 됩니다. 보안이 강화된 웹은 DDoS 공격이나 해커로부터 완벽하진 않지만 훨씬 안전해집니다.

Global Server Load Balancing(GSLB)

글로벌 서버 로드 밸런싱은 웹사이트 서버가 세계 각지에 있을 경우 리버스 프록시가 요청을 분석해 가까운 서버로 전송할 수 있게 됩니다. 이는 클라이언트의 요청대기 시간을 단축시킵니다.

Caching(캐싱)

리버스 프록시는 캐싱 기능도 제공합니다. 예를 들어 프랑스 파리에 있는 사용자가 미국 LA 웹 서버(origin server)를 통해 요청을 보냈을 경우, 클라이언트의 실제론 파리의 로컬 리버스 서버에 연결되었을 수 있습니다. 프록시 서버는 응답 데이터를 캐싱해놓을 수 있습니다. 파리에 있는 클라이언트들은 앞으로 파리에 있는 캐싱된 버전의 리버스 프록시 서버를 통해 통신할 수 있어 성능 개선 효과를 볼 수 있습니다.

SSL encryption\

SSL(혹은 TLS)를 암복호화 하는 과정은 시스템적으로 origin server에 부담을 줄 수 있습니다. 리버스 프록시는 유입되는 요청을 복호화 하도록 설정할 수 있으며 응답할 때 암호화하는 기능을 제공합니다. 이로써 origin server는 리소스를 줄이고 필요한 데에 사용할 수 있습니다.

프록시와 관련된 대부분의 내용은 cloudflare 문서에 있습니다.


참고자료