🐹 로드밸런서

Proxy란?

: 남을 대신해서 일을 처리

Proxy Server

: 클라이언트와 서버간의 중계 서버로 통신을 대리 수행하는 서버(네트워크상 의미)

캐시/보안/트래픽 분산 등 여러 장점을 가질 수 있음

Proxy의 종류

Forward Proxy / Reverse Proxy

Forward Proxy

일반적으로 우리가 말하는 proxy는 forward proxy를 말함

Forward Proxy란 클라이언트와 인터넷 사이에 위치한다. Forward Proxy가 사이에서 흐름을 대신 처리해준다.

Forward Proxy의 특징 1 - 캐싱

클라이언트가 요청한 내용을 캐싱

• 캐싱을 간단히 설명하자면
  1. 3개의 클라이언트 존재
  2. 1번 클라이언트가 서버에 오늘의 날씨 정보 질문
  3. 서버가 오늘의 날씨를 응답해준 후 1번 프록시 서버를 통해 1번 클라이언트에게 전달 (이때 프록시 서버는 오늘의 날씨에 대한 응답을 저장)
  4. 2번 클라이언트가 오늘의 날씨 요청
  5. 프록시 서버는 해당 요청에 대한 응답을 저장해두었으므로 웹서버에 요청하지 않고 바로 응답값을 반환
  6. 이후의 모든 같은 질문에 5번과 같이 진행

[ 장점 ]

• 전송 시간 절약
• 불필요한 외부 전송 X
• 외부 요청 감소 → 네트워크 병목 현상 방지

Forward Proxy의 특징 2 - 익명성

익명성 : 클라이언트가 보낸 요청을 감춤

클라이언트가 서버로 직접 호출할 때는 우리(클라이언트)가 요청하라고 하는 정보를 서버에 그대로 전달해준다.

예를 들면 IP를 받거나, 장비 정보, OS 정보 등을 받을 수 있다.

하지만 만약 중간에 Proxy 서버를 넣게 되면

우리(클라이언트)가 요청했지만 마치 Forward Proxy가 요청을 한 것처럼 서버들에게 Forward Proxy의 정보를 전달해 줄 수가 있다.

⇒ Server는 응답 받은 요청을 누가 보냈는지 알 수 없다. (익명성)

⇒ Server가 받은 요청 IP = Proxy IP

Reverse Proxy

Forward Froxy와 다르게 인터넷과 서버들 사이에 위치한다.

Reverse Proxy의 특징 1 - 캐싱

: 클라이언트가 요청한 내용을 캐싱

Forward Proxy와 동일

Reverse Proxy의 특징 2 - 보안

: 서버 정보를 클라이언트로부터 숨김

1) 클라이어트 입장에서 진짜 서버를 알지 못하고, Reverse Proxy에게 요청을 전달한다.

2) Reverse Proxy가 자신이 알고 있는 서버에게 요청을 전달한다.

Client는 Reverse Proxy를 실제 서버라고 생각하여 요청한다.

⇒ 실제 서버의 IP가 노출되지 않는다.

Reverse Proxy의 특징 3 - Load Balancing

이것은 선택적으로 하는 경우도 있고, 하지 않는 경우도 있다.

Load Balancing

: 부하 분산(해야할 작업을 나누어 서버의 부하를 분산시키는 것)

인바운드 트래픽 : 외부에서 서버 내부로 데이터가 유입될 때 발생하는 트래픽 (반대는 아웃 바운드)

위 사진처럼 로드밸런서는 서버들에게 요청을 나누어 준다.

Load Balancer가 나타난 배경

서버 1개를 사용하던 서비스

1. 서비스 사용자는 1명이었다.
2. 사용자가 늘어나게 되면서 서버는 부하가 생김
3. Scale Up을 하자! (서버의 성능을 높이는 것) → 고급 서버로 변경
4. 다시 요청을 잘 소화하고 있음
5. 다시 사용자가 매우 많아짐
6. 다시 Scale Up을 하자! → 메모리를 꽂을 수 있는 소켓이 한정적이기 때문에 불가능
7. 여러 대의 서버가 나눠서 일을 하게 끔 만들자! (Scale Out)
8. 로드밸런서를 적용하여 서버를 뒤에 여러 대를 두었다.

⇒ 여러 대의 서버가 분산(나누어) 처리할 수 있도록 요청을 나누어주는 서비스

Load Balancer 종류

OSI 7 Layer 기준으로 어떤 것을 나누는지에 따라 다름

L2, L3, L4, L7

• L2 : Mac 주소를 바탕으로 나눔
• L3 : IP주소를 바탕으로 나눔

• L4 : Transport Layer(IP & Port) Level에서 로드밸런싱 (TCP/UDP)

  ex) https://www.naver.com/로 접근 시 서버 A, 서버 B로 요청을 고르게 로드밸런싱(나눠줌)

• L7 : Application Layer(User Request) Level에서 로드밸런싱 (HTTPS/HTTP/FTP)

  ex) https://www.naver.com/로 접근 시 /category와 /search를 담당 서버들로 로드밸런싱(나눠줌)

  → url에 따라 혹은 query param에 따라 애플리케이션 요청 방법에 따라 어떤 서버로 로드밸런싱 할 지 결정

Load Balancing 알고리즘

1) 정적 로드 밸런싱

1. 라운드 로빈 방식(Round Robin Method)

   클라이언트의 요청을 여러 대의 서버에 순차적으로 분배하는 방식.

   클라이언트의 요청을 순서대로 분배하기 때문에 서버들이 동일 스펙을 가지고 있고, 서버와의 연결(세션)이 오래 지속되지 않는 경우 활용하기 적합하다.

   • A, B, C의 서버를 가지고 있을 경우 A → B → C → A 순서대로 순회

2. 가중치 기반 라운드 로빈 방식(Weighted Round Robin Method)

   각각의 서버마다 가중치(Weight)를 매기고 가중치가 높은 서버에 클라이언트의 요청을 먼저 배분.

   여러 서버가 같은 사양이 아니고, 특정 서버의 스펙이 더 좋은 경우 해당 서버의 가중치를 높게 매겨 트래픽 처리량을 늘릴 수 있다.

   • 서버 A의 가중치=8, 서버 B의 가중치=2, 서버 C의 가중치=3 → 서버 A에 8개, 서버 B에 2개, 서버 C에 3개의 Request를 할당

3. IP 해시 방식(IP Hash Method)

   클라이언트 IP 주소에 대해 해싱이라고 하는 수학적인 계산을 수행

   클라이언트 IP 주소를 숫자로 변환한 다음 개별 서버에 매핑

   사용자 IP를 해싱하여 부하를 분산하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장

2) 동적 로드 밸런싱

1. 최소 연결 방법(Least Connection Method)

   활성 연결이 가장 적은 서버를 확인하고 해당 서버로 트래픽을 전송

   이 방법에서는 모든 연결에 모든 서버에 대해 동일한 처리 능력이 필요하다고 가정한다.

2. 최소 응답 시간 방법(Least Response Time Method)

   서버의 현재 연결 상태와 응답 시간을 모두 고려하여, 가장 짧은 응답 시간을 보내는 서버로 트래픽을 할당

   각 서버의 가용 가능한 리소스와 성능, 처리 중인 데이터양 등이 상이할 경우 적합하다. 조건에 잘 들어맞는 서버가 있을 시 여유 있는 서버보다 먼저 할당된다. 로드 밸런서는 이 알고리즘을 사용하여 모든 사용자에게 더 빠른 서비스를 보장한다.

AWS 로드밸런서 유형

1) ALB(Application Load Balancer)

복잡한 최신 애플리케이션에는 단일 애플리케이션 기능을 전담하는 여러 서버를 포함하는 서버 팜(Server Farm)이 있다. Application Load Balancer는 HTTP 헤더 또는 SSL 세션 ID와 같은 요청 콘텐츠를 확인하여 트래픽을 리다이렉션한다.

예를 들어, 전자 상거래 애플리케이션에는 제품 디렉터리, 장바구니 및 결제 기능이 있다.

Application Load Balancer가 연결된 전자 상거래 애플리케이션에서는 이미지와 비디오 같은 콘텐츠를 제공하지만, 사용자의 연결을 계속 유지할 필요가 없다. 사용자가 웹사이트에서 제품을 검색하면 ALB는 이 검색 요청을 연결을 유지할 필요가 없는 서버로 전송한다. 이에 비해 많은 클라이언트 연결을 유지가 필요한 장바구니는 데이터를 오랫동안 저장할 수 있는 서버로 요청을 전송한다.

• ALB는 애플리케이션 레벨에서 로드밸런싱을 제공하며, HTTP/HTTPS 트래픽에 적합함
• L7 기반 로드 밸런서를 지원하며 SSL 적용이 가능함

2) NLB(Network Load Balancer)

Network Load Balancer는 IP 주소 및 기타 네트워크 정보를 검사하여 트래픽을 최적으로 리다이렉션한다. 애플리케이션 트래픽의 소스를 추적하고 여러 서버에 고정 IP 주소를 할당할 수 있다. Network Load Balancer는 정적 및 동적 로드 밸런싱 알고리즘을 사용하여 서버 로드를 배포한다.

NLB는 고성능을 요구하는 환경에서 부하분산에 적합한 솔루션이다. 낮은 latency로 초당 수백만 건의 요청을 처리할 수 있으며 갑작스러운 트래픽 증대 및 변화에도 최적화되어 있다.

예를 들어 지적이고 최적화된 연결을 유지하는 것이 중요한 실시간 스트리밍 서비스, 화상 회의 애플리케이션 또는 채팅 애플리케이션에서는 NLB를 사용하여 연결을 관리하는 것이 조금 더 적합하다. NLB를 사용하므로써 세션 지속성을 효과적으로 유지할 수 있다.

• NLB는 네트워크 레벨에서 로드밸런싱을 제공하고, TCP/UDP 트래픽에 적합함
• L4 기반 로드 밸런서를 지원

3) ELB(Elastic Load Balancer)

Elastic Load Balancer는 둘 이상의 가용 영역에서 EC2 인스턴스 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산한다. ELB의 경우 L4와 L7에 대한 부하를 제어할 수 있다. 그리고 서버의 기본 주소가 바뀌면 로드밸런서를 새로 생성해야 하며 하나의 주소에 하나의 타겟 그룹을 보내게 된다. 따라서 타겟 그룹이 많아질수록 더 많은 수의 로드밸런서가 필요하고 비용도 그만큼 더 들어가게 된다.

• ELB는 AWS 환경에서 제공하는 4가지 유형의 로드 밸런서를 지원함
• ELB는 뛰어난 확장성과 유연성을 제공해 사용자의 다양한 요구 사항과 환경에 맞출 수 있음