[Network] 4/7 TIL : 아키텍처의 구성요소들

프록시

프록시 서버는 원 서버를 대리해서 클라이언트와 통신해 중계 역할을 하는 서버를 말한다.

프록시 서버가 클라이언트와 서버 중간에 있기 때문에 클라이언트는 프록시 서버를 '서버'라고 인식하고, 서버 입장에서는 '클라이언트'로 인식한다.

 

 

프록시의 종류

• 리버스 프록시(reverse proxy) :  클라 - 서버 구조에서 서버를 대리해서, 클라이언트 <== 서버 방향의 요청을 중계한다.
• 포워드 프록시(forward proxy) : 클라 - 서버 구조에서 클라이언트를 대리해서, 클라이언트 ==> 서버 방향의 요청을 중계한다.

 

프록시의 장점

1. 로드 밸런싱: 프록시 서버는 여러 백엔드 서버 간의 트래픽을 분산시키는 로드 밸런싱 역할을 할 수 있다. 그래서 더욱 안정적인 서비스를 제공하는데 도움이 된다.
2. 캐싱: 프록시 서버는 자주 사용되는 웹 콘텐츠를 캐시하여 응답 시간을 엄청나게 단축시킬 수 있다. 그래서 원 서버의 리소스를 덜 잡아먹을 수 있고, 네트워크 사용량을 절약해 결국 서비스 제공자 입장에서 서비스 유지 비용을 아낄 수 있다.
3. 보안: 프록시 서버는 웹 애플리케이션 방화벽(WAF) 역할을 하여 원 서버를 외부 공격으로부터 보호할 수 있다. 그리고 사용자의 IP 주소를 숨기거나 SSL/TLS 암호화를 구현해 클라이언트와 서버 간의 통신 보안을 강화할 수 있다. Ddos와 같은 트래픽 부하 공격에게서도 원 서버를 보호해줄 수 있다.
4. 압축: 프록시 서버는 웹 콘텐츠를 압축하여 클라이언트에게 전송할 수 있다. 그래서 데이터 전송 시간이 단축되고, 대역폭 사용량이 감소한다.
5. 지역 제한 우회: 프록시 서버를 사용하면 특정 지역에서만 접근 가능한 웹 콘텐츠에 대한 접근을 우회할 수 있다. 사용자는 프록시 서버를 통해 해당 지역에서 차단된 웹사이트에 접속할 수 있다.(ㅎㅎㅎㅎ...)
6. 성능 모니터링 및 로깅: 프록시 서버를 사용하면 웹 트래픽에 대한 로그를 수집하고, 성능 모니터링을 통해 시스템의 개선점을 찾을 수 있다.

 

로드 밸런서(Load Balancer)

규모가 큰 서비스의 경우에는 서버 한 대로 모든 서비스를 수용하는 것이 불가능하다. 또한 서버 1대로 서비스를 제공하는 것에 문제가 없다고 하더라고 서비스의 시스템을 단일 서버에 구축하면 해당 서버에 문제가 발생했을 때, 서비스를 제공하는데 제한이 될 수 있다.

 

그래서 서비스 가용성(availability)를 높이기 위해서 1개 서비스는 보통 여러대의 서버로 구성한다. 여기서 각 서버는 ip주소가 달라서 같은 서비스를 이용하더라도 다른 ip로 접속하는 경우가 생길 수 밖에 없는데, 여기서 1개의 서버가 문제가 생겼다면 해당 서버를 통해 서비스를 이용하던 사용자들에게 서비스 장애가 생길 수 있다. 이문제를 로드 밸런서를 사용해 해결할 수 있다.

 

로드 밸런서에는 동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청을 분산시켜 부하를 분산시킨다.

 

 

프록시 캐시

 프록시 캐시는 프록시 서버에서 원 서버가 제공하는 서비스 내용 중 일부를 저장해둬서 사용자가 해당 서비스 내용을 요청하면, 프록시 서버에서 바로 해당 서비스를 제공할 수 있도록 하는 저장공간을 말한다.

 즉, 프록시 서버가 작동하는 과정에서 프록시 서버 - 원 서버 사이의 통신시간을 절약해 훨씬 빠른 서비스 반응속도를 보여줄 수 있다.

 

이 프록시 캐시와 관련된 캐시 헤더는

 

• Cache-Control: public 
  • 응답이 public 캐시에 저장될 수 있다.
• Cache-Control: private
  • 응답이 private 캐시에 저장되어야한다.(특정 사용자만 사용할 수 있어야한다.)
• Cache-Control: s-maxage
  • 프록시 캐시 전용 max-age
• Age: 60 (HTTP 헤더)
  
  • 원 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

이고, 캐시를 무효화할 수 있는 헤더는

• Cache-Control: no-cache 
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용한다.
• Cache-Control: no-store 
  • 데이터에 민감한 정보가 있으므로 저장하면 안된다.
• Cache-Control: must-revalldate 
  • 캐시 만료 후 최초 조회 시 원 서버에 검증해야한다.
  • 원 서버 접근 실패 시 반드시 오류가 발생해야한다. 504오류(Gateway Timeout)
  • must-revalldate는 캐시 유효 시간이라면 캐시를 사용한다.
• Pragma:no-cache
  • HTTP 1.0 하위 호환

 

---

 

참고 : https://simplicable.com/IT/proxy-server