📌 로드밸런싱 (load balancing)

로드 밸런싱은 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법이다. 최신 애플리케이션은 수백만 명의 사용자를 동시에 처리하고 정확한 텍스트, 비디오, 이미지 및 기타 데이터를 빠르고 안정적인 방식으로 각 사용자에게 반환해야한다.

이렇게 많은 양의 트래픽을 처리하기 위해 대부분의 애플리케이션에는 데이터가 중복되는 리소스 서버가 많이 있다.

로드 밸런서는 사용자와 서버 그룹 사이에 위치하며 보이지 않는 촉진자 역할을 하여 모든 리소스 서버가 동일하게 사용되도록 하는 디바이스다.

📌 로드 밸런서 (load balancer)

로드 밸러싱의 툴인 로드 밸런서는 총 4가지의 종류를 갖고 있으며 쓰임새가 각각 다르다.

CLB (Classic Load Balancer) - 2009년에 출시된 로드 밸런서로 HTTP, HTTPS, TCP, SSL, secure TCP 프로토콜을 지원하지만 권장하지 않는 밸런서이다.
ALB (Application Load Balancer) - 2016년에 출시된 로드 밸런서로 HTTP, HTTPS, WebSocket 프로토콜을 지원한다
NLB (Network Load Balancer) - 2017년에 출시된 로드 밸런서로 TCP, TLS ,secure TCP, UDP 프로토콜을 지원한다.
GLB (Gateway Load Balancer) - 2020년에 나온 게이트웨이 로드 밸런서로 3계층의 네트워크 레이어 IP 프로토콜에서 작동한다.

유저는 HTTP 나 HTTPS를 통해 어디서든 로드 밸런서에 접근이 가능하므로 보안 그룹의 규칙의 80 포트와 443 포트는 항시 열려 있어야하며 0.0.0.0/0 모두에게 열려있어야 한다. 여기서 EC2 인스턴스는 로드밸런서를 통한 트래픽만을 허용해야하기 때문에 EC2 인스턴스의 보안 그룹 규칙은 HTTP포트인 80포트만 개방하며 소스는 IP 범위가 아니라 로드밸런서의 보안그룹으로 연결해야 한다. 이렇게 함으로써 EC2 인스턴스는 로드 밸런서에서 온 트래픽만을 허용하게 된다.

📌 ALB(Application Load Balancer)

어플리케이션 로드 밸런서는 7계층 , 즉 HTTP 전용 로드 밸런서로 URL 라우팅, URL의 호스트 이름에 기반한 라우팅, 쿼리 문자열과 헤더에 기반한 라우팅이 가능하다. ALB는 마이크로 서비스나 컨테이너 기반 어플리케이션에 가장 좋은 로드 밸런서이다.

외부 애플리케이션에 로드 밸런서가 있다고 가정하자. EC2 인스턴스들로 구성된 첫 번째 대상 그룹은 Route/ user로 라우팅되고 두 번째 대상 그룹은 검색 어플리케이션으로 Route/ search로 라우팅된다면 두 개의 독립된 마이크로 서비스가 첫 번째는 유저 어플리케이션으로 두 번째는 검색 어플리케이션으로써 서로 다른 작업을 처리하게 될 것이다. 이들은 URL에서 사용되는 라우팅을 기반으로 해 각 대상 그룹으로 지능적으로 라우팅하는 방법을 알고 있는 동일 애플리케이션 로드 밸런서의 뒤에 있는 것이다.

ALB를 사용하게 되면 고정 호스트 이름이 부여된다. 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못하며 클라이언트의 실제 IP는

X-Forwarded-For 라는 헤더에 삽입된다. X-Forwarded-Port를 사용하는 포트와 X-Forwarded-Proto에 의해 사용되는 프로토콜도 얻게 될텐데 만약 클라이언트 IP인 12.34.56.78이 로드밸런서와 통신 할 때 EC2 인스턴스가 클라이언트의 IP를 알기 위해서는 HTTP 요청에 추가 헤더인 X-Forarded-Port와 Proto를 확인하여 알 수 있다.

📌 NLB(Network Load Balancer)

NLB는 L4 로드 밸런서이므로 TCP와 UDP 트래픽을 다룰 수 있다. 네트워크 로드 밸런서의 성능은 매우 높아 초당 수백만 건의 요청을 처리할 수 있고 ALB에 비해 지연 시간도 짧다. NLB는 AZ 별로 하나의 고정 IP를 가지며 탄력적 IP 주소를 각 AZ에 할당할 수 있어 여러 개의 고정 IP를 가진 어플리케이션을 노출할 때 유용하다.

작동 방식은 ALB와 비슷하다. 대상 그룹을 생성하면 네트워크 로드 밸런서가 대상 그룹을 리다이렉트하여 백엔드, 프론트엔드 모두 TCB 트래픽을 사용하거나 백엔드에서는 HTTP를 프론트에서는 TCP를 사용할 수 있다.

EC2 인스턴스가 대상 그룹일 때 NLB는 TCP 또는 UDP 트래픽을 EC2 인스턴스로 리다이렉트할 수 있다. 또한 IP 주소를 등록할 수도 있는데 이 때 IP 주소는 반드시 하드 코딩되어야 하고 프라이빗 IP여야 한다.(프라이빗 IP로 연결하는 것은 ALB도 가능)

NLB를 ALB 앞에 배치하는 경우도 가능하다. 이러한 경우에는 NLB 덕분에 고정 IP 주소를 얻고 ALB의 HTTP 유형의 트래픽을 처리하는 규칙을 얻는 설계가 가능하다.

📌 GWLB (Gateway Load Balancer)

GWLB는 모든 로드 밸런서보다 낮은 수준인 L3 네트워크 계층으로 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다. GWLB는 네트워크이 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다. 그래서 IDPS 나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다.

이미지처럼 애플리케이션에 액세스하는 사용자가 있다고 가정했을 때, 모든 트래픽을 검사하려면 어플리케이션에 도달하기 전에 EC2 인스턴스와 같은 타사 가상 어플라이언스를 배포 후 GWLB를 거치게 해야한다. VPC에서 라우팅 테이블이 업데이트되면 모든 사용자들은 맨 처음으로 GWLB를 통과하게 되고 GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산한다. 그래서 모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 방화벽이나 침입 탐지의 역할로 분석,처리하게 되는데 이상이 없으면 다시 GWLB로 통과하여 최종 어플리케이션으로 보내고 이상이 있으면 트래픽을 드랍한다.

이제 GWLB는 2가지 기능을 갖게 된다. 첫 번째는 VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구로 통과하게 되는 투명 네트워크 게이트웨이의 기능을 하게 되고, 두 번째로는 대상 그룹의 가상 어플라이언스 집합에 그 트래픽을 분산하는 로드밸런서의 기능을 하게 된다. 포트는 6081번 포트의 GENEVE 프로토콜을 사용한다.