중간서버와 오리진 서버
실제 클라이언트와 서버는 바로 통신이 되는 것이 아니다.
클라이언트와 서버 사이에는 여러개의 중간 서버가 존재한다. 또한, 한 서버에 문제가 생기더라도 문제없이 동작할 수 있도록 서버를 다중화하여 운영하는 경우도 많다. 이때, 실제 응답을 보내는 서버를 오리진 서버라 한다.
중간서버는 프록시와 게이트웨이로 나눠진다. 프록시는 포워딩 프록시를 의미하고 게이트웨이는 리버스 프록시를 의미한다.
* 포워딩 프록시 : 클라이언트와 가까이 위치해 있으며, 클라이언트를 대신하여 요청을 서버로 전달하는 역할을 한다. (클라이언트 보호)
* 리버스 프록시: 서버와 가까이 위치해 있으며, 클라이언트의 요청을 서버로 전달하고 서버의 응답을 클라이언트에게 전달하는 역할을 한다. (서버 보호)
리버스 프록시
리버스 프록시는 서버의 정보를 보호하기 위해, 중간에서 요청을 대신 받아, 서버에 전달하는 역할을 한다.
직접 서버에 접근하지 못하게 하는 이유는 서버의 실제 IP가 노출되면 해킹 공격의 직접적인 대상이 될 수 있기 때문이다.
리버스 프록시의 주요 기능
1️⃣ 서버 보안
앞서 말했듯이, 서버의 실제 IP주소를 노출시키지 않을 수 있다. 따라서 해커들의 DDoS 공격과 같은 공격을 막는데 유용하다.
* DDoS 공격: 여러 대의 컴퓨터나 서버를 사용하여 특정 서버나 네트워크를 과부하시키는 공격 방식
1. 클라이언트는 인터넷을 통해 리버스 프록시에게 요청을 보낸다.
2. 리버스 프록시는 해당 요청을 실제 서버(오리진 서버)로 전달한다.
3. 클라이언트는 실제 서버의 IP 주소를 모른채 리버스 프록시 IP 주소를 통해 서비스를 이용하게 되고, 이는 본서버의 정보를 숨길 수 있다.
2️⃣ 캐싱
캐싱은 자주 요청되는 데이터를 미리 저장해두고, 이후 요청에 대해 원본 서버에 접근하지 않고 빠르게 응답할 수 있도록 하는 기술이다.
1. 만약 한국에 있는 사용자가 미국에 웹서버를 두고 있는 사이트에 접속할때, 리버스 프록시 서버가 한국에 있다고 가정한다.
2. 그러면 사용자는 리버스 프록시 서버와 통신해서 캐싱되어 있는 데이터를 사용한다.
3. 더 빠른 성능을 보여줄수 있다.
3️⃣ SSL/TLS 종료
리버스 프록시 내에서 암호화/복호화를 하게 되면 서버의 부담을 줄여줄 수 있다.
이유는, 본서버에서 암호화/복호화 작업을 처리하면 모든 서버에 대해 동일한 작업을 반복적으로 수행해야 하므로 중복된 작업이 발생하게 된다. 이로 인해 서버 리소스 소모가 커지게 되며, 성능 저하를 초래하게 된다.
4️⃣ 콘텐츠 압축
리버스 프록시를 사용하여 데이터를 압축함으로서 네트워크 트래픽 사용량을 줄이고 전송 속도를 향상시킬 수 있다.
5️⃣ 로드밸런싱
NGINX와 HAProxy는 리버스 프록시 기능을 제공하며, 해당 기능 안에 로드밸런싱 기능이 내장되어 있다.
로드밸런싱이란, 하나의 서버에 트래픽이 몰려 과부하 현상을 막기 위해, 클라이언트의 요청을 여러 서버로 분배하는 것을 의미한다.
로드밸런싱
로드밸런싱은 트래픽의 고른 분배를 위해 사용되는 기술이다.
예를 들어, 서버를 다중화하더라도 특정 서버에만 트래픽이 몰린다면, 가용성이 떨어질 수 있다. 따라서 로드밸런싱을 이용하여 각각의 서버에 트래픽을 분배해주어야 한다.
*가용성: 시스템이 장애 없이 서비스를 제공할 수 있는 시간을 비율로 나타낸 것.
로드밸런싱 주요 기능
1️⃣ 트래픽 분산
클라이언트 요청을 여러 서버에 나눠서 부하를 분산한다.
L4는 IP/포트 기반, L7은 URL/헤더 기반으로 분배한다.
2️⃣ 헬스 체크
백엔드 서버의 상태를 주기적으로 확인하고, 장애가 발생한 서버를 자동으로 제외시킨다.
L4는 TCP/UDP 연결 여부, L7은 HTTP 응답 상태 코드까지 확인 가능.
3️⃣ 세션 유지
동일 사용자의 요청을 특정 서버로 유지해서 세션 정보를 안정적으로 유지한다.
L4는 IP 해시 기반, L7은 쿠키 기반 방식 등을 사용한다.
4️⃣ Failover 및 고가용성
특정 서버에 장애가 발생하면 정상적인 서버로 자동으로 트래픽을 우회시킨다.
서비스 중단을 최소화하고 높은 가용성을 유지한다.
로드 밸런싱 방식 ( 계층기반 분류 )
로드밸런싱 방식에는 크게 Layer 4, Layer 7로 나눌 수 있다.이렇게 나누는 이유는 각 계층이 트래픽 처리 방식과 응용 분야가 다르기 때문이다. 두 방식을 간단하게 요약하면,
속도가 중요한 시스템일 경우엔 Layer 4가 적합하고 세밀한 제어가 필요한 경우엔 Layer 7이 적합하다.
1️⃣ Layer 4 (전송계층)
Layer 4에서의 로드밸런싱은 전송 계층에서 트래픽을 분배하는 방식이다.
IP 주소와 포트 번호를 기준으로 트래픽을 분배하며, 애플리케이션의 세부적인 내용(예: HTTP 헤더, URL 경로 등)은 확인하지 않는다.
따라서 해당 방식은 빠르고 간단한 트래픽 분배가 필요할 때 유용하다.
🔷 실시간 전송 (UDP)
실시간 사용자의 트래픽을 빠르게 전송해야할때 UDP 프로토콜을 사용한다. 이때, 해당 세부적인 내용을 알 필요 없이 ( HTTP 헤더, URL 경로 등) 그저 데이터를 빠르게 분배하는 것에만 초점을 두었기 때문에 Layer 4 로드밸런서가 많이 사용된다.
🔷 대규모 파일 전송(TCP)
파일 전송은 신뢰성이 중요하기 때문에 TCP 프로토콜을 주로 사용한다. 하지만 이 또한 세부적인 내용 (헤더.쿼리 등)을 확인하고 서버를 나눌 필요가 없다. 따라서 빠르게 분배하는 것에 초점을 두었기 때문에 Layer 4를 사용한다.
2️⃣ Layer 7 ( 애플리케이션 계층)
Layer 4에서의 로드밸런싱은 애플리케이션 계층에서 동작한다.
Layer 7에서의 로드밸런싱은 구체적인 내용을 분석 (HTTP 요청의 URL, 헤더, 쿠키, 쿼리 파라미터 )하여 트래픽을 분배한다.
HTTP와 같은 애플리케이션 계층의 프로토콜에서 상세한 라우팅을 할 수 있기 때문에, 사용자의 요청을 보다 정교하게 분배할 수 있다.
🔷 웹 애플리케이션 (HTTP/HTTPS)
웹 서버에서는 클라이언트의 요청을 URL 경로, 헤더, 쿼리 파라미터 등을 기준으로 처리한다.
예를 들어, example.com/api/로 오는 요청은 API 서버로 보내고, example.com/images/로 오는 요청은 이미지 서버로 보내는 방식이다. 이때 URL 경로나 헤더에 따라 요청을 다른 서버로 라우팅하는 게 Layer 7의 역할이다.
🔷 세션 관리
웹 애플리케이션에서 로그인 상태를 유지해야 할 때, 세션을 관리하는 서버가 필요하다. 사용자가 로그인하면 그 세션을 추적하고, 로그인 상태를 유지하는 서버에 요청을 보내야 한다. 이때 세션 쿠키나 토큰을 기반으로 요청을 올바른 서버로 라우팅하는 역할을 Layer 7 로드밸런서가 한다.
ex. 관리자는 서버1로,일반사용자는 서버2로 분배한다.
로드 밸런싱 알고리즘
1️⃣ Round Robin (라우드 로빈)
Round Robin은 가장 기본적인 로드밸런싱 알고리즘으로, 요청을 순차적으로 서버에 분배하는 방식이다.
즉, 서버가 여러 대가 있을 때 클라이언트의 요청을 순차적으로 각 서버로 전송한다.
서버가 3대가 있다고 가정하면, 첫 번째 요청은 서버1로, 두 번째 요청은 서버 2로, 세 번째 요청은 서버3으로 보내고, 네 번째 요청은 다시 서버 1로 보낸다.
2️⃣ Least Connections (최소 연결 수)
가장 적은 수의 연결을 가진 서버로 요청을 보내는 방식이다.
이 알고리즘은 각 서버의 연결 수를 추적하여, 현재 가장 적은 연결을 가진 서버에 요청을 할당한다.
각 서버의 연결 상태를 실시간으로 추적하고, 서버 간의 연결 수가 가장 적은 서버에 새로운 요청을 전송한다.
연결 수를 기준으로 트래픽을 분배하므로, 서버가 과부하 상태가 되지 않도록 관리할 수 있다.
🤔 서버의 성능이 동일하지 않다면?
지금까지 정리한 내용은 서버의 성능이 동일하다는 전제가 있었다.
그럼 만약 몇개의 서버는 성능이 월등히 높고, 몇개의 서버는 성능이 낮으면 어떻게 해야 할까?
바로 이때는 가중치가 부여될 수 있다.
각각의 알고리즘을 바탕으로 동작하되, 가중치가 높은 서버가 더 많이 선택되어 더 많은 부하를 받도록 할 수 있다.
로드밸런서 종류
로드밸런서는 로드밸런싱을 수행시킨다.
앞서, 로드밸런싱이 어떻게 트래픽을 분산시키는지 살펴보았기 때문에, 로드밸런서의 종류에 대해 알아보겠다.
1️⃣ 하드웨어 로드밸런서
네트워크 장비처럼 직접 물리적인 장비를 설치하여 트래픽을 분산시킨다.
F5, A10, Citrix ADC 등이 존재한다.
고성능을 제공하기 때문에 높은 트래픽을 안정적으로 처리할 수 있지만
초기비용이 매우 높으며 물리적인 장비이기 때문에 유지보수와 공간 확보가 필요하다.
따라서 해당방식은 대규모 트래픽을 처리하는 기업, 금융기관 등에서 주로 사용된다.
2️⃣ 소프트웨어 로드밸런서
서버 (리눅스, 윈도우 등)에 설치하여 실행한다.
일반 서버에 설치하려 운영하는 로드밸런서로, 하드웨어 장비를 구매하지 않아도 쉽게 구축할 수 있다.
Nginx, HAProxy, Envoy 등이 존재한다.
비용이 저렴하고 코드 기반으로 설정을 변경할 수 있기 때문에 관리가 편하다.
그러나 하드웨어 기반보다는 성능이 낮고 직접 설정해야하므로 구성 및 유지보수 작업이 필요하다.
주로 웹서버 등에서 사용된다.
3️⃣ 클라우드 기반 로드밸런서
AWS, GCP, Azure 같은 클라우드 환경에서 제공하는 서비스에서 사용된다.
AWS, GCP, Azure 같은 클라우드 서비스 제공업체에서 제공하는 관리형 로드밸런서를 이용하는 방식이다.
사용자가 직접 서버를 운영하지 않아도 되고, 자동 확장 보안 기능이 포함되어 있어 유지보수 부담이 적다.
그러나 사용량에 따라 요금이 부과되므로 장기적으로 비용이 증가할 가능성이 있다.
클라우드 환경에서 웹 애플리케이션을 운영할때 사용한다.
🤔 클라우드 사용해도 NginX 많이 쓰던데?
클라우드 환경에서도 Nginx를 많이 사용하는 이유는 단순히 로드 밸런서 역할 때문이 아니라, 리버스 프록시, 캐싱, SSL 종료, 압축, DDoS 방어 등 다양한 기능을 제공하기 때문이다.
AWS ELB나 GCP의 Load Balancer 같은 관리형 로드 밸런서 서비스가 널리 사용되지만, 특정한 트래픽 처리 방식이나 세부적인 요청 라우팅을 직접 제어하려면 Nginx를 활용하는 것이 더 유리할 수 있다.
결론적으로, 클라우드 환경에서는 로드 밸런싱 자체는 AWS ELB 등 관리형 서비스가 담당하는 경우가 많지만, 세부적인 요청 라우팅이나 트래픽 제어가 필요할 때 Nginx가 리버스 프록시 등의 역할로 널리 활용된다.
리버스 프록시와 로드밸런싱 정리
리버스 프록시는 서버의 보안을 강화하고 캐싱과 SSL 종료를 통해 성능을 개선한다.
로드밸런싱은 로드밸런서를 이용하여, 로드밸런싱(L4,L7)을 통해 트래픽을 여러 서버에 고르게 분배하여 가용성과 확장성을 높인다.