[DevOps] Reverse Proxy vs Load Balancer, 리버스 프록시 vs 로드 벨런서

서버 아키텍쳐를 공부하던 중에 비슷한 두 개의 개념을 접하게 되었습니다.

리버스 프록시와 로드 밸런서.

얼핏 봐서는 두 개념이 비슷해보이고 명확하게 구분이 안되서 각각에 대해서 정리하고 두 개의 차이점을 알아보도록 하겠습니다.

 

Reverse Proxy

우선 Reverse Proxy 부터 알아보도록 합시다.

Proxy의 뜻은 대리로서 이 경우 서버와 클라이언트 사이의 대리자 역할을 말합니다.

이후 포스팅에서 다루겠지만 여러 클라이언트에 대한 proxy를 Forward Proxy 라고 하고 여러 서버에 대한 proxy를 Reverse Proxy라고 합니다.

Reverse Proxy

위 그림은 Reverse Proxy에 대한 그림으로서 사용자의 요청을 Reverse Proxy가 받아들이고 이를 서버에서 대리합니다.

Reverse Proxy의 특징을 알아보도록 하겠습니다.

• 백앤드 infra를 숨김

  • 서버는 어느 클라이언트에서 요청이 왔는지 모르고 클라이언트도 어느 서버로 요청을 보내야 하는지 모릅니다. 다만 reverse proxy를 매개로 요청과 응답을 주고 받을 뿐이죠. 따라서 백앤드가 어떻게 구성되어 있는지 클라이언트는 알 수가 없습니다.

• 캐싱

  • reverse proxy에서 캐싱함으로서 웹사이트 엑세스 시간을 줄입니다. 단순히 웹사이트 엑세스 시간을 줄일 뿐 아니라 각 서버에 요청을 줄여 서버의 트래픽을 줄여준다.

• canary deployment

  canary deployment는 새로운 버전을 릴리즈 할 시 일부 사용자에게만 이를 적용하는 배포 방법입니다. 이를 통해 새로운 버전에서 문제가 발생했을 때 대규모의 사용자들이 이를 사용하기 전에 문제를 파악하고 대처할 수 있습니다.

canary deployment

 

• 보안

  보안에 대해서 설명하기 위해서 먼저 DMZ라는 개념을 짚고 넘어갑시다.

  DMZ란 Demilitarized Zone의 약자입니다. 내부 네트워크와 외부 네트워크 사이에 위치한 중간지점으로 외부로 부터 내부 자원을 보호하기 위해서 접근제한을 수행하는 영역입니다.

  
  

  만약 reverse proxy가 없고 WAS가 직접 DMZ에서 서비스를 하고 있다면 혹여나 WAS가 털릴 경우 WAS와 연결된 DB 등 여러 자원들도 연이어 털리게 됩니다.

  하지만 DMZ에는 reverse proxy가 존재하고 WAS는 내부 네트워크에 존재하면서 혹여나 reverse proxy가 털려도 내부망으로 연결이 불가능하기 때문에 보안의 문제점을 해결했다고 볼 수 있습니다.

DMZ

 

 

Load Balancer

다음으로 Load Balancer에 대해서 알아봅시다.

로드 밸런서는 리버스 프록시에 한 종류입니다. 따라서 위에서 말한 리버스 프록시의 특징들을 모두 포함합니다.

추가적으로 이름 그대로 요청을 서버에 분산시키는 역할을 하게 됩니다.

왜 서버에 요청을 분산해야 할까요?

아래와 같이 클라이언트가 매우 많아졌다고 가정합시다.

Load Balancer

서버는 모든 사람들에게 응답을 해주기 위해 노력하지만 서버의 자원은 한정되어 있기 때문에 서버는 동작을 못하게 됩니다. 흔히 서버가 터진다고 말하죠.

이러한 현상을 방지하기 위해 동일한 서버를 여러 개 두고 이에 적절하게 요청을 분산합니다.

그렇다면 어떤 알고리즘으로 여러 서버에 요청을 분산할까요?

 

Load Balancing Algorithm

• Round Robin

  요청을 순서대로 각 서버에 균등하게 배분

• Least Connection

  서버에 연결되어 있는 수가 가장 적은 서버에 연결

• Weighted Least Connection

  서버의 처리 능력에 가중치를 부여하여 가중치와 Least Connection 을 종합적으로 판단하여 적절한 서버에 연결

• Fastest Response Time

  가장 빨리 응답하는 서버에 연결

• Hashing

  사용자의 IP를 hashing하여 연결함으로서 동일한 사용자는 동일한 서버에 연결

이 외에도 다양한 Load Balancing Algorithm이 존재합니다.

 

L4 Load Balancer와 L7 Load Balancer

Load Balancer도 종류가 있습니다.

제목에서 언급한 두 종류는 OSI 7 계층에서 어느 layer에서 로드 밸런싱을 수행할 건지에 따라 나뉩니다.

표를 통해서 각각의 차이점을 비교해봅시다.

	L4 Load Balancer	L7 Load Balancer
OSI 7 layers	Layer 4: Transport layer	Layer 7: Application layer
protocol	TCP, UDP	HTTP, SMTP, FTP
장점	데이터 안을 확인하지 않고 패킷 레벨에서만 밸런싱하기 때문에 속도가 빠름 데이터의 내용을 복호화할 필요가 없어 안전 L7 Load Balancer에 비해 가격이 저렴	Application Layer에서 밸런싱하기 때문에 더 섬세한 라우팅이 가능 캐싱 기능을 제공 비정상적인 트래픽을 사전에 필터링 할 수 있어 서비스 안정성이 높음
단점	패킷의 내용을 볼 수 없기 때문에 섬세한 라우팅이 힘듦 사용자의 IP가 수시로 바뀌는 경우라면 연속적인 서비스를 제공하기 어려움	패킷의 내용을 복호화해야 하기에 더 높은 비용을 지불 클라이언트가 Load Balancer와 인증서를 공유해야하기 때문에 공격자가 Load Balancer를 통해서 클라이언트에 데이터에 접근할 보안 상의 위험성이 존재

 

 

 

Load Balancing 장점

Load Balancer 를 사용함으로서 다음과 같은 이점을 얻을 수 있습니다.

• 비용 절감

  서버의 자원이 사용자의 요청을 감당하지 못하는 경우, 서버의 스택을 늘리거나 (scale up) 서버의 개수를 늘려야(scale out) 합니다. 전자보다는 후자가 비용적으로 더 저렴합니다.

• SPOF 해결

  서버가 한 대라면 해당 서버가 에러 발생 시 모든 동작이 멈추게 됩니다. 즉 SPOF, 단일 장애점인 것이죠. 하지만 여러 대의 서버를 운영한다면 하나의 서버가 에러가 발생해도 나머지 서버로 분산해서 사용자는 서버의 에러를 체감하지 못합니다.

• 확장 용이성

  추후에 더 많은 사용자에 대해 서버를 확장할 때도 보다 쉽게 가능해집니다.