[Network] 서버의 액세스가 증가할 때 어떻게 처리할까? - 캐시 서버와 포워드 프록시, 리버스 프록시

🌱 DNS 서버를 통해 다중 서버로 분산 처리하기

서버의 액세스가 증가한다면 단순히 회선을 빠르게 하는 것으로도 부족할 수 있다.

단일 서버의 한계를 극복하기 위해서는, 여러 대의 서버를 이용하여 처리를 분산시킬 수 있는데 이를 '분산 처리'라고 한다.

클라이언트의 리퀘스트를 어떻게 하면 여러 대의 서버로 분배할 수 있을까?

 

바로, DNS 서버를 통해 분배하는 것이다.

DNS 서버에 동일한 이름으로 여러 대의 웹 서버를 등록해둔다면, 조회가 있을 때마다 조회된 IP 서버를 차례로 반환한다.

이때, 라운드 로빈 방식을 통해 균등하게 액세스를 분산시킬 수 있도록 돕는다.

💡 aaa.com이라는 도메인에 대해 192.0.2.60, 192.0.2.70, 192.0.2.80이 있다면 아래와 같은 순서로 반환한다.
- 192.0.2.60, 192.0.2.70, 192.0.2.80
- 192.0.2.70, 192.0.2.80, 192.0.2.60
- 192.0.2.80, 192.0.2.60, 192.0.2.70

 

하지만, 만약 이중 하나의 웹 서버가 오류가 발생하여 응답이 불가능한 상태라면 어떨까?

DNS 서버는 웹 서버가 고장났는지 확인할 수 없기 때문에 고장난 서버의 IP 주소를 반환해버릴수도 있다.

 

---

 

🌱 부하 분산 장치 / 로드 밸런서 사용하기

DNS 서버를 이용한 라운드 로빈 웹 서버 분배 방식의 단점을 극복하기 위해 별도의 부하 분산 장치를 사용할 수 있다.

DNS 서버에 웹 서버 자체가 아닌, 부하 분산 장치를 대신 등록한다.

그렇다면 클라이언트가 DNS 서버에서 IP 주소를 받아갈 때 부하 분산 장치의 IP 주소를 받아가기 때문에 부하 분산 장치 쪽으로 요청을 보내게 될 것이다.

부하 분산 장치는 웹 서버의 부하 상태를 판단하여 액세스를 위임하게 되는데, 기본적으로 웹 서버와 정기적으로 정보를 교환하여 CPU나 메모리 사용량 등을 수집하여 부하 상태를 확인한다. (혹은 패킷을 전송하여 응답 시간을 바탕으로 판단할 수도 있다.)

 

하지만, 만약 클라이언트의 요청과 서버의 요청이 연속되어 진행되어야 하는 상황이라면 어떻게 해야 할까?

ex) A라는 사용자가 상품을 주문 (주문 요청) -> 결제하고 (결제 요청) -> 결제 완료 창 띄워주기 (결제 완료 반환)

 

기본적으로 HTTP는 리퀘스트 메시지를 보내기 전에 TCP 접속 동작을 진행하고, 응답 메시지를 반환하면 연결을 끊는다.

이전 상태에 대한 정보가 없기 때문에 (stateless) 서로 관계있는 요청인지 알 수 없는 것이다.

이를 위해서 쿠키나 세션, 토큰 등의 인증 방식이 있는데 이에 대해서는 다른 포스팅에서 다루었기 때문에 패스하도록 하겠다 😊

 

아래는 정리했던 내용이다 ㅎ_ㅎ

🍪 쿠키 / 세션 방식 정리

⭐️ JWT 인증 방식 정리

 

---

 

🌱 캐시 서버 이용하기

같은 기능의 여러 대의 서버를 설치하는 것은 아무래도 부담이 클 수 있다. (사실 뭐든 스케일 아웃이 가장 좋은 방법이긴 하니까...)

그래서 같은 기능의 서버를 설치하는 대신, 캐시 서버를 두어서 다른 역할을 주는 방법도 있다.

일반적으로 캐시 서버의 경우 '프록시'라는 구조를 사용하여 데이터를 캐시에 저장하게 된다.

 

이는 일종의 웹 서버와 클라이언트 사이의 액세스 동작에 대한 중개자 역할을 하는데, 클라이언트의 동일한 요청에 대해서 웹 서버에 조회한 이력이 있다면 다시 웹 서버를 들리지 않고 캐시 서버에서 바로 반환하는 역할을 할 수 있다. (이때 사용한 데이터가 '캐시')

 

물론, 캐시를 이용할 때는 데이터 정합성을 늘 고려해야 한다.

그래서 TTL 등을 통해 계속 데이터를 보관하는 대신, 일정 시간이 지나면 캐시 서버의 데이터를 초기화하는 경우가 많다.

 

캐시 서버도 마찬가지로 부하 분산 장치에 실제 웹 서버 대신에 DNS 서버에 등록된다.

그러면 사용자는 캐시 서버에 HTTP 리퀘스트 메시지를 보내게 된다.

만약, 캐시에 저장되어 있지 않다면 Via 헤더에 프록시 서버 정보를 추가하여 웹 서버에 리퀘스트를 전송한다.

이 정보는 그렇게 중요하지는 않으며, 단순히 웹 서버에게 프록시 서버를 경유했음을 알리기 위해 사용한다.

(참고로, 그림에서는 캐시 서버 -> 웹 서버에서만 Via가 추가되었는데 캐시 서버 -> 클라이언트로 갈 때도 추가한다!)

 

이때, 하나의 캐시를 여러 대의 서버에서 공유하고 있다면 리퀘스트 메시지의 내용에 따라서 웹 서버를 판단한다.

- 보통 리퀘스트의 URI를 바탕으로 서버를 결정하고는 한다. (⭐️ 사전에 설정해둔 웹 서버에만 전송할 수 있도록 지정하는 것.)

 

반대로, 캐시에 데이터가 저장되어 있었다면 웹 서버 측에게  데이터가 변경되었는지 조사하기 위해 If-Modified-Since라는 헤더 필드를 추가하여 웹 서버에 전송한다.

웹 서버는 If-modified-since 필드 값과 데이터의 최종 갱신 일시를 비교하여 변경이 없다면 변경이 없었다는 응답을 반환한다.

이때 데이터를 포함하지 않기 때문에 비교적 응답 메시지가 빠르게 전송된다.

캐시 서버는 변경사항이 없음을 파악했기 때문에 캐시 서버에 저장된 데이터를 반환하게 된다.

 

반면에, 수정된 사항이 있다면 수정된 리소스와 함께 반환하게 된다. 

그리고 반환된 데이터는 다시 캐시 서버에 저장해두고, 클라이언트에게 반환한다!

참고로, If-Modified-Since 헤더의 경우 GET이나 HEAD 요청에서만 사용할 수 있다!

 

---

 

🌱 포워드 프록시 / 리버스 프록시 / 트랜스페어런트 프록시

💬 포워드 프록시

앞서 말했던 내용은 웹 서버 측에 캐시 서버 두고 사용한 것이었는데, 클라이언트 측에도 캐시 서버를 둘 수 있다.

보통 클라이언트 측에 둔 프록시의 경우 방화벽처럼 원하는 패킷만 전송하도록 하는 것이었다.

패킷 필터링형 방화벽의 경우 IP 주소나 포트 번호 정보만 보지만, 프록시는 HTTP 리퀘스트 내용까지 함께 볼 수 있기 때문에 조금 더 세미하게 액세스 제한을 걸 수 있다는 것이다.

포워드 프록시를 하게 되면 URL의 내용에 관계 없이 클라이언트의 요청은 전부 프록시 쪽으로 전송된다.

- 클라이언트의 요청이 직접 인터넷에 가지 않는다.

또한, 기존에는 URI 정보만 리퀘스트 URI에 기록하지만, 포워드 프록시를 활용하면 URL 전부를 기록하게 된다.

그렇기 때문에 캐시 서버처럼 URI에 따라 전송할 웹 서버를 사전에 지정해줄 필요도 없이, 모든 웹 서버에서 전송할 수 있게 된다.

💡 포워드 프록시는 보통 다음과 같은 상황에서 많이 사용한다.
- 접속 제한 회피 : 방화벽을 통해 제한된 액세스를 제공하는 사이트에 대해서 회피하여 이용 가능
- 특정 컨텐츠 제한: 특정 클라이언트가 특정 리소스에 접근하는 것을 막을 수 있음
- 캐싱: 요청의 응답값을 웹 서버까지 가지 않더라도 프록시에서 반환 가능
- IP 우회: 웹 서버 측은 클라이언트의 정보를 알지 못하고 프록시에 대한 정보만 받을 수 있게 된다.

 

 

💬 리버스 프록시

하지만, 포워드 프록시의 경우 브라우저 설정이 꼭 필요하기 때문에, 이를 잘못 설정하게 되면 장애가 발생할 수도 있다.

리버스 프록시의 경우 웹 서버 / WAS 앞단에 위치하여, 클라이언트의 요청을 대신 받고, 웹 서버의 응답을 대신 반환해준다.

- 클라이언트의 요청이 인터넷까지는 가지만, 서버에서 받은 데이터를 리버스 프록시가 받아 전달해준다.

포워드 프록시 서버의 경우 서버가 클라이언트를 모른다는 점이 특징이었지만, 리버스 프록시의 경우 클라이언트가 실제 서버를 알 수 없다.

💡 리버스 프록시는 보통 다음과 같은 상황에서 많이 사용한다.
- 로드 밸런싱: 리버스 프록시 서버를 단일 서버 앞에 두어, 특정 서버의 과부하를 막는 방법이다.
- 서버 보안: 서버의 IP 주소를 노출시키지 않기 때문에 DDos 공격 차단에 용이하다.
- 캐싱: 포워드 프록시의 캐싱과 유사하다. 마찬가지로 요청을 웹 서버까지 보내지 않고 바로 응답할 수 있다.

 

포워드 프록시와 리버스 프록시는 비슷한 듯 하지만 꽤 차이가 있다.

 

	포워드 프록시	리버스 프록시
어디에서?	클라이언트 앞단	웹 서버 / WAS 앞단
통신은?	클라이언트 <-> 프록시	프록시 <-> 웹 서버
실제 웹 요청은?	웹 서버	프록시 서버
감춰지는 정보는?	클라이언트 정보	서버 정보

 

포워드 프록시는 네트워크 내부에서 요청을 받아서 다른 곳으로 보내준다.

네트워크 안에 있는 컴퓨터가 인터넷에 접속하려고 할 때, 포워드 프록시는 컴퓨터의 요청을 받아서 대신 인터넷으로 보내준다.

그리고, 인터넷에서 받은 정보도 대신 포워드 프록시가 받아서 컴퓨터로 전달해준다. (네트워크 안에서 시작된 요청을 받아서 전달)

 

반대로 리버스 프록시의 경우, 네트워크 바깥에서 네트워크 내부로 들어오는 요청을 받아서 서버로 전달한다.

밖에서 들어온 요청을 리버스 프록시가 받아서 다시 서버로 보내주고, 요청을 처리한 뒤 응답 역시 리버스 프록시로 보내서 집 밖으로 전달해주는 역할을 해준다. (네트워크 바깥에서 안으로 들어오는 요청 중계)

 

 

💬 트랜스페어런트 프록시

리퀘스트 메시지의 패킷 맨 앞에 기록된 수신처 IP 주소를 조사하여 액세스 대상 웹 서버를 판단하는 방법이 트랜스 페어런트 프록시이다.

브라우저에서 웹 서버로 흘러가는 메시지를 가로채서 인터넷으로 전달하는 방법이다.

마찬가지로 응답 역시 가로채서 사용자에게 전달하는 역할이며, 프록시의 존재를 사용자가 인지하지 못한다는 게 특징이다.

보통 리퀘스트 메시지가 한 개로 수렴하도록 네트워크를 구성하고, 수렴되는 곳에 트랜스페어런트 프록시를 설치한다. (혹은 액세스 회선에 설치하기도 한다.)

 

- 헷갈려서 찾아봤는데... 포워드 프록시는 사용자 컴퓨터에서 웹 서버 접속 시 프록시 서버를 통해 인터넷을 사용하라는 방식으로 설정해야 돼서 클라이언트마다 설정을 해줘야 한다.

하지만 트랜스페어런트 프락시는 '클라이언트 컴퓨터에서 인터넷을 사용하기 위해 반드시 지나가야 하는 게이트웨이'에서 웹 요청을 가로채며 동작하는 방식이라고 한다. (강제로 위임하는 느낌?)