들어가기

프로젝트에 Nginx를 사용하면서 기능은 사용하지만 원리는 잘 알지못하고 사용하고
로드밸런싱, 로드밸런서는 면접 질문이기도 해서 한번 다뤄보고 싶은 내용이였습니다.

Proxy Server, Forward Proxy , Reverse Proxy, Load Balancer 에 대해 학습합니다. 또한 프록시 서버를 얘기 할 때 캐시를 빼고 얘기 할수 없는데 간단하게 정리해보고 나아가 Ngnix가 이 용어와 역할과 관련지어 정리했습니다.

Proxy Server

먼저 Proxy란?

디자인 패턴에도 나오고 JPA에서도 나오고 참 많이 나오는 용어같습니다. Proxy Server에서도 똑같습니다. 기본적으로 많이쓰이는 대리 개념으로 이해하면 되겠습니다.

Proxy Server란?

프록시 서버는 사용자를 인터넷에서 분리하는 중간 서버 역할을 합니다. 중간자 역할을해 클라이언트와 서버가 직접 소통 하는 것이 아닌 프록시 서버를 거치게됩니다.
프록시 서버는 캐시/보안/트래픽 분산등의 역할을 수행가능합니다.

프록시 서버는 정보를 찾는 사용자와 서버 사이에서 게이트키퍼 역할을 하는 컴퓨터 응용 프로그램입니다. 사용자의 모든 요청을 체계적인 방식으로 수집하고 전달하는 동시에 DDoS 공격 등에 대한 보안 및 보호를 제공합니다.

프록시 서버는 사실 다양하지만 일반적으로 크게 2가지로 나뉩니다.
포워드 프록시(forward proxy) , 리버스 프록시(reverse proxy)를 중점으로 살펴보겠습니다.

Forward Proxy

일반적으로 말하는 Proxy 서버가 Forward Proxy 서버입니다. 주로 캐싱, 보안 향상, 속도 향상, Privacy등 역할을 합니다.

작동

위에서 말한바와 같이 프록시 서버(Forward Proxy를 이단락에서 프록시 서버라 칭하겠습니다.)는 중간 역할을 하게됩니다. 프록시 서버가 없다면 트래픽이 장치에서 웹사이트로 직접 흐르게 되고 프록시 서버가 있을 경우 트래픽이 웹 서버로 이동 전 트래픽이 프록시 서버로 이동하게 됩니다.

1. 사용자가 웹브라우저에 웹 사이트 주소를 입력
2. 프록시 서버가 중간에 사용자 요청을 수신한다.
3. 프록시 서버가 엑세스하려는 웹 서버로 요청을 전달한다.
4. 웹 서버는 응답값을 프록시 서버로 보낸다.
5. 프록시가 사용자에게 응답 데이터를 전달한다.

역할,특징

• Privacy 프록시 서버는 요청자의 위치를 숨기고 익명 브라우징을 보장합니다.
  사용자가 서버에 요청시 중간에 프록시 서버를 거치기 때문에 서버는 프록시 서버가 요청을 보낸 것으로 인식합니다.

• Security 프록시 서버는 첫 번째 방어선 역할을 하고 사용자와 서버 사이에 서서 모든 파일을 저장하는 기업의 핵심 서버 인프라를 보호할 수 있습니다.

• Caching 위 그림처럼 프록시 캐시 서버를 중간에둬 성능을 향상 시킬수 있습니다.
  프록시 캐시 서버처럼 공용으로 사용하는 곳은 public 캐시, 로컬에서 사용하는 웹 브라우저 캐시는 private 캐시라고 합니다.

어떻게 작동합니까?

Reverse Proxy

어떠한 요청에 대한 응답을 보내줄 때 캐싱과 보안 취약점 제거를 위해 리버스 프록시를 사용합니다. 클라이언트 입장에서는 서버 측의 실제 IP가 아닌, 리버스 프록시의 IP만 알 수 있기 때문에 보안상 취약점을 커버할 수 있게 됩니다. Load Balancing 역할 또한 해줍니다.

사용자/클라이언트는 Forward Proxy를 사용하고 서버는 Reverse Proxy를 사용합니다.

특히 보안상 강점이 있는데 리버스 프록시 서버를 WEB/WAS로 구성된 서버 앞에 두게됩니다. 이 때 클라이언트는 프록시 서버를 거쳐 WEB/WAS로 구성된 서버를 거치기 때문에 내부 서버를 직접 접근하는 것이 아니게됩니다.

즉 클라이언트는 내부 서버에 대한 정보를 알 필요 없이 리버스 프록시에만 요청하면 됩니다.

리버스 프록시 서버를 DMZ(내부네트워크/외부네트워크에 둘다 접근할 수 있는 공간)에 두고 실제 서비스 서버는 내부망에 위치 시킵니다. WAS는 DB에 직접 접근하기 때문에 외부 네트워크에 노출시키지 않습니다.

예를들어 Web Server에 Ngnix를 두고 Was에 Tomcat을 두는 방식으로 이때 Nginx 리버스 프록시 역할을 한다고 보면됩니다.

역할

• Load Balancing
  실제 서버(오리진 서버)는 수백만 명의 트래픽을 감당 할수 업습니다. 이런한 경우 트래픽을 분산시켜 웹사이트를 안정화 시킵니다. 대부분의 인기 있는 리버스 프록시는 주로 로드 밸런싱에 사용됩니다.

  Load Balancer 와 Reverse Proxy

  단 짚고 넘어가야 할것이 있습니다. Reverse Proxy가 Load Balancing을 한다고 하였습니다. 그렇다면 Revers Proxy가 Load Balancer냐 라고하면 이것은 엄밀히 말하면 또 다른 개념이지만 모든 리버스 프록시가 모두 로드벨런서는 아니지만 대다수의 리버스 프록시 서버가 로드벨런서 역할을 하기 때문에 너무 세밀한 비교는 혼란을 가중 시킵니다. 적절히 혼용해서 사용합니다. 밑은 둘에 대한 설명인데 설명과 같이 둘은 비교하기 참 어렵습니다.

1. Load Balancer란 들어오는 클라이언트 요청을 서버 그룹 간에 분산하며 각 경우에 선택한 서버에서 적절한 클라이언트로 응답을 반환합니다.

2. Reverse Proxy 는 클라이언트의 요청을 수락하고 이를 이행할 수 있는 서버로 전달한 다음 서버의 응답을 클라이언트에 반환합니다.

로드 밸런싱(Load Balancing)은 트래픽을 여러 대의 서버로 분산시켜서 성능을 향상시키는 개념을 의미합니다. 로드 밸런서(Load Balancer)는 로드 밸런싱을 구현하는 기술이나 장치를 말합니다.

정리하자면 리버스 프록시와 로드 밸런서는 서로 다른 개념이지만, 일부 경우에는 리버스 프록시가 로드 밸런서의 역할을 수행할 수 있습니다.

로드밸런싱도 중요한 내용이니 밑에서 더 설명하겠습니다.

• Enhanced Security(향상된 보안)
  1.원본 서버의 IP 주소 및 기타 특성을 숨길 수 있습니다. 따라서 웹사이트의 원본 서버는 익 명성을 더 잘 유지하여 보안을 크게 강화할 수 있습니다.

2. 리버스 프록시는 메인 서버에 도달하기 전에 모든 트래픽을 수신하므로 공격자나 해커가 DDoS 공격 과 같은 보안 위협으로 웹사이트를 공격하기가 더 어려워집니다.

• Global Server Load Balancing (GSLB 글로벌 서버 로드 밸런싱)
  GSLB는 전 세계에 전략적으로 배치된 많은 서버 간에 웹 사이트 트래픽을 분산하기 위한 고급 로드 밸런싱 방법입니다. 일반적 으로 Reverse Proxy가 클라이언트와 서버 간의 가장 빠른 이동 시간을 기준으로 서버 노드를 선택하는 애니캐스트 라우팅 기술을 통해 수행됩니다.

• 암호화 (Encryption)
  SSL 암호화에도 좋습니다. 서버가 클라이언트들과 통신을 할때 SSL,TSL로 암호화, 복호화를 는 많은 비용이듭니다.
  하지만 리버스 프록시를 사용하면 들어오는 요청을 모두 복호화하고 나가는 응답을 암호화해주므로 클라이언트와 안전한 통신을 할수 있으며 본래 서버의 부담을 줄여줄 수 있다.

그 밖에도 밑에와 같은 기능이 있습니다.

• Powerful Caching
• 우수한 압축
• 최적화된 SSL 암호화
• 더 나은 A/B 테스트
• 트래픽 모니터링 및 로깅
  그 외에도 다양한 프록시 서버가 있습니다.
• 사이트 속도 향상
  프록시를 사용하면 캐싱을 통해 성능을 향상시킬 수 있습니다.

차이점

둘의 차이를 간단히 요약 해보면

• Forward Proxy는 클라이언트의 정보를 감춥니다. 요청 받는 서버는 클라이언트 정보를 모릅니다. 단 클라이언트가 요청하는 엔드 포인트는 실제 url입니다.
  클라이언트와 프록시 서버간의 소통이며

• Reverse Proxy는 서버의 정보를 감춥니다. 프록시 서버 url로만 접근이 가능 하므로 본서버의 IP정보를 숨길수 있습니다.
  WEB/WAS 앞 단 에있습니다. 프록시와 내부서버의 통신이라고 보면됩니다.

로드 밸런싱 (Load Balancing)

트래픽이 증가할때 대응 방법으로 서버를 물리적인 하드웨어 성능을 올리는 Scale-up 방식이 있고 여러대의 서버가 나눠서 일하는 방식의 Scale-oup 방식이 있습니다.
이 때 서버의 트래픽을 여러 곳으로 분리시키는 로드 밸런싱이 필수적입니다.

로드 밸런싱(Load Balancing)은 트래픽을 여러 대의 서버로 분산시켜서 성능을 향상시키는 개념을 의미합니다.

로드 밸런싱은 트래픽을 상황에 맞게 분산 시키는 알고리즘이 중요합니다.
대표적으로는 라운드로빈 방식,최소 연결 방식등이 있습니다.

L4 로드밸런싱과 L7 로드밸런싱

로드 밸런싱 중 가장 많이 활용되는 로드밸런싱은 L4와 L7으로
OSI 7계층의 레이어를 의미합니다. 즉 각 로드밸런싱이 Transport layer나 Application layer 계층에서 헤더를 부하 분산에 이용하는 것입니다.

• L4 로드밸런서는 IP, Port, Session 등을 바탕으로 부하를 분산
  L4는 가상 IP단위만 로드밸런싱 합니다.
• L7 로드밸런서는 URL, payload, cookie, HTTP 헤더 등을 통해 부하를 분산
  Application 레이어에서 동작하고 payload를 분석하여 정교한 로드밸런싱이 가능합니다.

L7은 비정상적인 트래픽을 필터링할수 있지만 L4에 비해 성능이 느립니다. 보통 말하는 기본적인 로드밸런서는 L7을 말합니다.

NginX(리버스프록시 서버)가 소프트웨어에서 로드밸런싱을 한다고 보시면됩니다.

캐시

검색 엔진 최적화(SEO)는 페이지 속도가 웹사이트 순위를 매기는 주요합니다현대 웹사이트는 복잡해지고 무거워지고 있습니다. 캐싱은 필수적이라 할수 있습니다. 캐시를 사용하는 다양한 방법들을 간단하게 알아보겠습니다.

캐시를 다루는 기술

• Browsers,Devices
  CPU 장치와 브라우저의 앱은 종종 스토리지와 RAM을 사용하여 데이터를 캐시합니다.
• Apps
• Servers
  더 빠른 실행 및 처리를 위해 서버 데이터 중 일부를 저장하고 불러올 수 있습니다. 예시로는 Redis 캐시가 있습니다.
• Domain Name Server (DNS) caching
  이미 방문한 도메인 이름의 DNS 레코드(IPv4 주소용 A 레코드, IPv6용 AAAA 레코드)를 포함하는 장치(컴퓨터, 스마트폰, 서버 등)의 임시 DNS 저장소입니다. TTL(Time-to-Live) 에 따라 해당 레코드를 유지합니다.

TTL(Time to Live)은 레코드가 캐시된 상태로 유지되는 기간을 나타냅니다.
레코드 저장소를 DNS 캐시 라 부릅니다. 레코드를 저장하는 행위를 캐싱이라고 합니다

참고자료 > https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/

https://kinsta.com/blog/reverse-proxy/#how-to-set-up-nginx-as-a-reverse-proxy
https://www.geeksforgeeks.org/difference-between-apache-and-nginx/
https://kinsta.com/blog/nginx-vs-apache/
https://www.baeldung.com/nginx-forward-proxy