ELB (Elastic Load Balancer)

ELB(Elastic Load Balancer)란 애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS서버 환경을 운용하는데에 도움을 주는 서비스다. EC2뿐만 아니라 컨테이너(ECS), AWS Lambda 등으로 다양한 서비스와 연계하여 부하를 분배할수 있다.

ELB는 서로 다른 EC2 인스턴스에 대한 하나의 엔드포인트를 제공한다. 그래서 사용자는 실제 요청이 처리되는 백엔드 인스턴스에 대한 고려 없이, 동일한 엔드포인트로 요청을 전송할 수 있다.

거기다 부하분산뿐만 아니라 부하 분산 대상에 대한 헬스 체크(Health Check), 고정 세션(Sticky), SSL Offload(SSL 암복호화), 헬스 체크를 통한 다운 서버 제외 등이 가능하다.

로드 밸런싱(Load Balancing) 이란?

오토 스케일링을 이해하기위해 스케일링이 무엇인지 알아봤었던 것 처럼, ELB를 이해하기위해 우선 로드 밸런싱이 무슨 역할을 하는지 부터 알아보자.

Load(부하) Balancing(분산)이란 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다.

말그대로 부하를 분산해 트래픽이 과도하게 몰려 서비스가 중단되는 현상을 막기 위한 기술이다. 그래야 지연 없이 작업을 처리하고 속도를 낼 수 있다.
회사에서 팀장이 외부로부터 받아 처리해야 할 업무를 팀원들에게 나누어 주어 기간안에 일을 처리하는 행위 또한 부하 분산으로 볼 수 있다.

로드 밸런서는 이런 부하를 분산하는 것 뿐만 아니라, 스케일 아웃에 대한 하나의 엔드포인트를 제공하기도 한다.

우리는 오토스케일링 그룹을 통해 다수의 인스턴스를 생성(스케일 아웃)하고 관리함으로써 고가용성을 확보할 수있고 안정적인 서비스를 제공할 수 있게 되었다.

그렇지만 이것을 사용하는 유저 입장에서는 증설된 각각의 인스턴스는 모두 다 일종의 컴퓨터이니 IP 주소를 갖고 있을테고, 이들을 관리하기 위해선 일일히 주소를 백업해 하나하나 접속하면서 관리해야 된다.

뿐만아니라, 만약 인스턴스 하나가 떨어지고 다시 새로 인스턴스가 올라가게 된다면, IP주소가 바뀌게 되고 이에 대해 별도의 조치를 취해야한다.

더군다나 만약에 인스턴스가 8개가 아니라 엄청 많을 때는 관리비용이 엄청 증가 하게 된다.

따라서, 오토스케일링 그룹 자체는 혁신적인 방법이지만 별도의 로드 밸런싱, 부하를 분산해주는 서비스 없이는 활용 불가이기 때문에 그래서 나온 서비스가 Elastic Load Balancing 인 것이다.

참고
ELB(Elastic Load Balancing)는 AWS에서 운용하는 로드 밸런서(Load Balancer)를 지칭 하는 것으로 보면 된다.

로드 밸런서(Load Balancer)에서 트래픽을 하나의 경로로 받아서 다수의 인스턴스에 분산하게 되어, 유저 입장에서는 각각의 인스턴스에 일일히 접근해서 관리하는게 아닌 하나의 주소로 접속해서 관리할 수 있게 된다.

인스턴스가 떨어져나가거나 오류가 나서 트래픽을 수신하지 못할 때에도 로드밸런서가 스마트하게(health check / monitoring) 알아서 트래픽을 전송하지 않게 하고, 새로운 인스턴스가 등록이 되면 자동으로 분산을 시켜준다.

ELB & 오토 스케일링 조합

오토 스케일링은 트래픽을 몰릴때 인스턴스(컴퓨터) 수를 자동으로 늘림으로서 서버 사이즈를 조절해 서비스가 원할히 유지되게 하며, 또한 트래픽이 적을경우 인스턴스를 감소시켜 비용 낭비를 막아주는 서비스이며,

ELB(Elastic 로드 밸런서)는 트래픽을 오토 스케일링을 통해 늘린 수만개의 인스턴스들에게 부하(트래픽)를 분산하는 서비스 이다.

즉, 이 둘은 형제자매 처럼 뗄레야 뗄수야 없는 관계이며, 같이 유기적으로 연동되어 EC2를 보다 효과적이게 이용 할 수 있게 한다. 그리고 실제로 이둘은 AWS 매니저에서 같이 설정하는 편이다.

ELB 서비스 구성 & 특징

ELB 구성요소 (리스너 / 룰 / 대상그룹)

ELB는 Virtual Private Network(VPC)에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스(EC2 등)에 적절히 부하 분산한다.

ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성되며 ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있다.

부하 분산 대상인 대상 그룹 내 리소스들은 헬스 체크(Health Check)를 활용해 끊임없이 상태를 확인받게 된다.

리스너는 외부의 요청을 받아들이기 때문에 서비스 포트(Service Port)를 보유하고 있으며 외부의 요청은 서비스 포트로 접속하는 요청만을 처리한다.

대상 그룹 또한 서비스 포트를 보유하고 있으며 부하 분산 대상인 EC2는 해당 포트가 열려있어야 한다.

그리고 대상그룹의 포트는 꼭 리스너와 포트가 같은 필요는 없다. (뒤의 실습에서 자세히 다룬다)

요청을 검토한 리스너가 요청이 적합한 경우 대상그룹에게 이를 전달할 때 대상 그룹의 포트로 'Port Translation'을 실시하기 때문이다.

리스너(Listener)

리스너는 프로토콜과 포트를 기반으로 요청을 받아 검사하고 이를 적절한 타겟으로 전달하는 기능을 수행한다.

그래서 이름에 'Listen' 이 붙는 것이다.

모든 로드 밸런서는 최소 1개 이상의 리스너를 필요로 하며, 최대 10개까지 설정할 수 있다.

뿐만 아니라 SSL 인증서를 게시하여 SSL Offload를 실시할 수도 있다.

Elastic Load Balancer-ELB

규칙(Rule)

리스너 룰은 리스너와 타겟 그룹 사이의 트래픽 분배를 위한 라우팅 규칙에 해당한다.

룰은 우선순위, 액션, 조건 등의 정보를 담고 있으며, 조건이 만족되었을 때, 지정된 액션을 수행하는 방식으로 작동한다.

리스너 룰에는 path, host, HTTP header, source IP, query parameter 등의 다양한 조건을 제공한다.

리스너는 최초 생성 시, default rule을 포함하고 있다. 디폴트 룰은 별도의 조건을 가질 수 없으며, 다른 룰로 처리되지 않고 남은 모든 요청에 적용된다.

대상그룹 (Target Group)

대상그룹은 리스너가 전달한 요청을 처리하기 위한 부하분산 대상들의 모임이다.

즉, ELB가 분산을 할 때 어디로 분산할 것이냐를 모은 그룹들이 대상그룹 이다. (만일 dashboard.mydomain.com으로 요청이 오면 대시보드 대상그룹으로 트래픽을 전송)

그렇기에 대상 그룹에 등록된 EC2의 각종 정보(인스턴스 ID, Port, AZ)가 적혀있고, 이 EC2가 전달받은 요청을 처리할 수 있는지를 체크하는 '헬스 체크(Health Check)' 기능과, 이 대상 그룹에 요청 처리가 가능한 EC2가 몇 개인지, 불가능한 EC2는 몇 개인지를 확인하는 요청 처리에 관련된 '모니터링(Monitoring)' 기능이 있다.

즉, 오토스케일링을 하기위해서 인스턴스들을 그룹으로 묶어 오토스케일링 그룹으로 만든 것처럼, 로드 밸런싱 하기위 해서 대상 인스턴스들을 묶어 놓은 그룹이라고 이해 하면된다.

그리고 이 대상그룹을 오토스케일링 그룹으로도 만들 수 있다. (ELB + Auto Scaling 조합)

유휴 제한 시간(Connection Time Out)

사용자가 ELB를 거쳐 EC2에 접근하여 서비스를 접속하면 'Connection(이하 커넥션)'이 생성 되게 된다.

그리고 이 커넥션을 통해 사용자와 EC2가 통신을 하는 것이다.

만일 더 이상의 통신이 없을 땐, 유휴 제한 시간이 작동하게 되고, 그 시간(60초)이 지나면 커넥션이 사라진다.

즉, 유휴 제한 시간이란, 일정 시간동안 통신이 없을 때 커넥션을 삭제할 것인가를 뜻하는 것이다.

ELB 기능 & 특징

고가용성 및 탄력성 (자동 확장/축소)

• ELB는 접속 부하에 맞게 자동적으로 리소스의 확장/축소를 수행한다.
  따라서 대량의 요청이 발생해도 ELB로 인해 병목 현상이 발생하는 상황은 거의 일어나지 않는다.
• 하지만 순간적으로 접근이 증가하면 리소스 자동 확장까지 일정한 시간이 걸리므로, 일시적으로 병목 현상이 걸릴 수 있다.
  만약 캠페인, 이벤트, TV 방영 등으로 인해 순간적인 요청 증가가 예상된다면, AWS 서포트에 미리 신청해서 ELB 리소스를 확장하는 것이 좋다.
  또한 수신되는 트래픽을 단일 가용 영역 또는 여러 가용 영역의 Amazon EC2 인스턴스 전체에 걸쳐 배포할 수 있다.
• ELB의 확장/축소는 스케일업/스케일다운과 스케일아웃/스케일인이라는 2가지 방식이 상황에 맞게 이루어진다.

도메인 기반 접근

• ELB는 지속적으로 IP주소가 바뀌며 IP 고정 불가능하여 따라서 항상 도메인 기반으로 사용해야 한다
• 자동 확장/축소 함에 따라 ELB 접근 IP가 변경되므로, ELB에 접근하는 경우 ELB를 생성할 때에 생성되는 도메인 이름을 사용해 접근하도록 구성해야 한다.
• 단, 뒤에서 소개할 네트워크 로드밸런서는 탄력적 IP로 고정 가능하다.
• 즉, DNS 이름을 통해 접속하면 ELB는 요청을 대상 그룹에 전달할 것이고 대상 그룹의 EC2가 요청을 처리하는 것이다.

[ELB의 요청 처리 과정]

• 사용자가 로드밸런서에 접근하기 위해 Amazon의 DNS 서버에 로드밸런서의 도메인 해석을 요청
• Amazon의 DNS 서버가 로드밸런서 노드 IP 리스트를 사용자에게 전달
• 사용자는 전달받은 IP 중 하나를 선택하여 로드밸런서에 접근(+ Port 입력)
• 사용자는 로드밸런서의 (Port가 일치하는) 리스너에 접근하게 되며 리스너는 이 요청을 받아들여 적절한 대상그룹으로 전달
• 리스너로부터 전달받은 요청을 EC2가 처리한 후 다시 사용자에게 반환

Cross-Zone Load Balancing

위 그림에서는 각 AZ마다 탑재되어있는 로드밸런서 노드와 로드밸런서 노드에 연결된 다수의 EC2로 구성 되어있다.

문제없이 각 인스턴스에 로드 밸런서가 붙어있어 잘 부하 분산을 시켜줄 것 같지만 아니다.

로드밸런서 노드와 EC2 사이의 각각의 선에 숫자가 적혀 는데, 저 숫자를 모두 합쳐보면 100이라는 숫자가 나온다.

즉, 요청이 100개라면 각 EC2에 할당된 요청의 비율을 뜻하는 것이다. (AZ A에 각각 25개를, AZ B에 각각 6.25개를 전달)

부하 분산이란 트래픽을 대상들에게 고르게 트래픽을 전달하는 것을 말한다.

하지만 위의 구성에서는 AZ에따라 부하가 고르게 요청이 전달되지 않고 있다. 이렇게 된다면 AZ A의 EC2들에게 부하가 심하게 걸리게 된다.

이 대상 그룹에 요청 처리가 가능한 EC2가 몇 개인지, 불가능한 EC2는 몇 개인지를

이를 보완하기 위한 기능이 바로 교차 영역 로드밸런싱(Cross Zone Load Balancing)이다.

교차 영역 로드밸런싱을 활성화하면 위 그림과 같이 AZ를 가리지 않고 고르게 부하를 분산한다.

다음에 배울 ELB 종류중에 하나인 Application Load Balancer의 경우 기본적으로 교차 영역 로드밸런싱이 활성화되어있으며, Network Load Balancer는 기본적으로 비활성화 되어있다.

참고
정리하자면, 교차 영역 로드밸런싱은 Zone별로 사용하는 EC2 개수에 차이가 있는 경우 사용하면 좋은 기능이다.

Health Check (상태 검사)

• 직접 트래픽을 발생시켜 인스턴스가 살아있는지 체크하는 기능이다.
• 타겟 그룹에 대한 헬스 체크를 통해 현재 정상적으로 작동하는 인스턴스로만 트래픽을 분배한다.
• 인스턴스의 상태를 자동으로 감지해서 오류가 있는 시스템은 배제 → 인스턴스가 회복되면 LB가 자동으로 감지하여 인스턴스에 트래픽을 보내준다.
  • 이를 통해 장애가 전파되는것을 방지하여 고가용성을 확보할 수 있다..
  • 상태 확인 개선을 통해 상세한 오류 코드를 구성할 수 있다.
  • 새로운 지표로 EC2 인스턴스에서 실행되는 각 서비스의 트래픽을 파악할 수 있다.
• 헬스 체크는 두가지 상태로 나뉘어진다
  • InService(서비스 살음) / OutofService(서비스 죽음)
• 제한 시간이나 간격, 성공 판단 횟수 등을 정의할 수 있다.

헬스 체크 방법은 해당 포트의 Listen 상태를 감시하는 포트 감시, HTTP 또는 HTTPS의 경우 실제 HTML 파일 접근 가능 여부를 확인하는 서비스 감시라는 두가지 종류가 있다.

[HTTP/HTTPS 체크 방식]

[포트 감시 방식]

임계값(Threashold) 만큼 Health check가 실패하면 load balancer를 서비스에서 Target을 제외시키고, 다시 해당 Target이 Healthy 상태가 되면 서비스에 추가시킨다. (자동)

보안 그룹

• VPC를 사용할 경우 EC2 인스턴스 처럼 ELB와 관련된 보안 그룹을 생성 및 관리하여 로드 밸런서를 위한 추가 네트워킹 및 보안 옵션을 제공할 수 있다.
• 로드밸런서 노드 또한 네트워크 인터페이스의 형태를 띄기 때문.
  다시 말해 보안 그룹은 네트워크 인터페이스에 적용되는 것이므로 네트워크 인터페이스를 갖는 ELB 또한 보안그룹을 가질 수 있는 것.
• 원하는 Load Balancer를 인터넷과 연결되도록 구성하거나 퍼블릭 IP 주소 없이 로드 밸런서를 생성하여 인터넷에 연결되지 않은 내부 로드 밸런서로 사용할 수 있다.
• EC2에도 보안 그룹이 있지만, 외부에 있는 ELB에 한번더 보안그룹을 설정해 외부의 공격(디도스)에 대해 강력하게 대비하는 개념으로 생각하면 된다.
  

SSL 지원

• SSL 암호화를 간편하게 구성 지원
• 따라서 SSL 증명서를 인스턴스들에 따라 설정할 필요가 없어진다.
• 통신의 암호화/복호화를 각각의 인스턴스에서 수행할 필요가 없으므로, 인스턴스의 부하를 낮출 수 있다.
• 또한, SSL 증명서를 ELB에서만 관리하면 되므로, 운용 측면에서의 장점도 가지게 된다.
  SSL 지원
  

고정 세션 (Sticky Session)

• 만일 서버가 여러개일경우, 사용자가 서버 인스턴스에 접근해 로그인을 하려고 할때 어느 서버의 인스턴스에 접근될지 모른다.
  예를들어 A 인스턴스로 로그인하고 다음날 다시 서버에 접근하려는데 로드 밸런싱에 의해서 B 인스턴스로 가버려 세션이 없어 또 로그인해야 하는 상황이 올 수 도 있다. 인스턴스가 수십개면 수십번 로그인을 해야한다.
• 따라서 유저에게 쿠키를 생성해 접속정보를 갖고있도록 하고, ELB자체에서도 공간을 만들어 정보를 저장한다.
• 즉, 사용자 세션을 특정 인스턴스에 고정시킴으로서 자신이 이전에 접속했던 인스턴스로 다시 접속할 수 있도록 해준다.
  

로그 추출 기능

• ELB로 처리한 요청 로그를 추출 할 수 있다.
• 추출한 로그는 S3에 저장된다.
• 장애 발생 또는 통신 오류가 발생하면, 인스턴스 로그를 하나하나 확인하는 것보다 ELB 로그를 확인하는 것이 원인을 조사하기에 좋다.

CloudWatch 연동

• ELB는 1분 단위로 로드 밸런서와 타겟 그룹에 대한 메트릭을 제공한다. 이를 통해, CloudWatch와 연동하고 안정적으로 서비스를 모니터링 할 수 있다.
• Amazon CloudWatch가 ALB와 CLB에 대해 요청 횟수, 오류 횟수, 오류 유형, 요청 지연 시간 등의 지표를 보고한다.

HTTP/2 지원

• ALB에서는 별도의 설정 없이 HTTP/2를 지원하기 때문에 웹 브라우저에서 페이지 로딩시간을 개선할 수 있다.

ELB 요금 정책

유형	정책
CLB	실행된 각 시간 또는 한 시간 미만, 그리고 로드 밸런서를 통해 전송된 각 GB 단위 데이터에 대해 비용이 청구
NLB	실행된 시간 또는 부분 시간 그리고 시간당 Network Load Balancer에서 사용된 로드 밸런서 용량 단위(LCU)에 대해 요금이 부과
ALB	실행된 시간 또는 부분 시간 그리고 시간당 사용된 로드 밸런서 용량 단위(LCU)에 대해 요금이 부과

ELB 로드밸런서 종류 (CLB / ALB / NLB / GLB)

ELB는 대표적으로 4가지의 로드밸런서가 존재한다.

• Application Load Balancer(ALB)
• Network Load Balancer(NLB)
• Classic Load Balancer(CLB)
  -Gateway Load Balancer(GLB)
  이 넷 모두 부하분산을 하는 로드밸런서라는 점은 동일하지만 역할이 각각 다르다.

aws에서 설정할때 이 셋 중 하나를 선택하여 로드밸런서를 생성하고 그 기능을 사용하게 된다.

CLB (Classic Load Balancer)

Classic Load Balancer는 가장 기본적인 형태이자 초기에 제공되던 서비스이다.

가장 기본적인 로드 밸런서의 역할을 수행하지만, CLB의 단점은 서버의 기본주소가 바뀌면 Load Balancer를 새로 생성해야하며 하나의 주소에 하나의 대상 그룹으로 밖에 못 보낸다.

또한, 데이터를 수정/변경할 수 없어 포트, 헤더 등의 변경을 하지 못한다.

이러한 구조는 서버의 구성과 아키텍처가 커지고 복잡해진다. 따라서 Load Balancer의 필요 개수, 비용이 증가하게 된다.

현재에는 CLB(Classic LoadBalancer)를 많이 사용하지 않아 레거시로 분류되었고, 주로 NLB 또는 ALB를 사용하여 구성하는 추세이다.

Info
쿠팡에서 회원관리(shop) 인스턴스와 주문(order) 인스턴스가 따로 존재한다고 하자.
로그인 후 주문을 하기 위해서는 그림 처럼 각각 다른 Load Balancer를 거쳐 해당 인스턴스로 접속해야 하므로 서버 개수, 비용이 증가하게 된다.

ALB (Application Load Balancer)

Application Load Balancer는 OSI 7 Layer에서 최상단 일곱 번째 계층에 해당하는 Application Layer를 다루는 로드밸런서 이다.

사용자와 직접 접하는 계층으로서 여러분이 브라우저를 통해 이 블로그를 접속할 수 있도록 사용하는 프로토콜 역시 Application Layer에 해당하는 HTTP/HTTPS인 것이다.

Application Layer에는 HTTP/HTTPS뿐만 아니라 FTP, DNS, DHCP, WebSocket 등 다양한 프로토콜이 존재한다.

ALB는 단순 부하분산뿐만 아니라 HTTP/HTTPS의 헤더 정보를 이용해 부하분산을 실시할 수 있다. (지능적인 라우팅 기능)

즉, HTTP 헤더의 값들을 보고 이 요청은 어느 대상그룹으로 보낼지 저 요청은 어느 대상 그룹으로 보낼지를 판단할 수 있다는 뜻이다.

예를들어 위의 구식 CLB같은경우는 각 대상 그룹 주소 마다 로드 밸런서를 각각 두었다.

하지만 ALB는 로드 밸런서 하나만 설정하면, 트래픽을 모니터링하여 각 대상그룹에 라우팅을 하게 해준다.

/user path 경로로 오면 람다 대상그룹에 보내주고, /shop path로 오면 회원관리 대상그룹에 보내주는 식이다.
이처럼 유저가 어떤 서버로 접속함에 따라서 다른 경로로 스마트하게 라우팅이 가능하다.

따라서 로드밸런서의 갯수를 줄일수 있고 이는 곧 비용 절감으로 이어진다.

ALB는 path(경로) 뿐만 아니라 port(포트)에 따라 다른 대상그룹으로 맵핑할 수도 있다.

각각의 포트에 따라 다르게 구성할 수 있으며 동일한 포트라도 path(경로)등에 따라 다르게 분기할 수도 있다

특히 포트 단위로 연결해줄 수 있는 것은 도커 컨테이너 환경에서 아주 유용하게 작동할 수 있고 하나의 대상그룹에 더 많은 컨테이너를 넣어 비용을 최적화할 수 있다.

ALB는 대상을 EC2 인스턴스 뿐만 아니라 람다, IP로도 연결이 가능하며 특정한 요청에 대해서는 서버없이 직접 응답메세지를 작성할 수 있기때문에 마이크로아키텍쳐를 구성하기에 좋다.

그리고 SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암호화/복호화를 대신 진행할 수 있다.

위의 내용을 종합해보면 Application Load Balancer는 TCP를 기반으로 하는 HTTP, HTTPS, WebSocket 등을 활용하며, HTTP의 주요 특징인 HTTP Header, Host Header, 요청 메서드 등에 기준을 적용하여 기준에 맞는 적절한 대상그룹으로 라우팅 할 수 있는 로드밸런서 이다.

• ALB는 L7단의 로드 밸런서를 지원
• ALB는 HTTP/HTTPS 프로토콜의 헤더를 보고 적절한 패킷으로 전송
• ALB는 IP주소 + 포트번호 + 패킷 내용을 보고 스위칭
• ALB는 IP 주소가 변동되기 때문에 Client에서 Access 할 ELB의 DNS Name을 이용
• ALB는 L7단을 지원하기 때문에 SSL 적용이 가능

NLB (Network Load Balancer)

Netowrk Load Balancer(이하 NLB)는 AWS에서 제공하는 4가지 로드밸런서 중 하나로 OSI 7 Layer에서 네 번째 계층에 해당하는 Transport Layer를 다루는 로드밸런서이다.

따라서 NLB는 TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시한다.

단, HTTP가 아닌 하위 Layer인 TCP Layer에서 처리하므로 HTTP 헤더를 해석하지 못한다.

TCP 세션은 350초 유지한다고 한다.

로드 밸런서가 연결 요청을 받으면 기본 규칙의 대상 그룹에서 대상을 선택하고 리스너 구성에 지정된 포트에서 선택한 대상에 대한 TCP 연결을 열려고 시도한다.

네트워크 로드 밸런서는 고성능을 요구하는 환경에서의 부하분산에 적합한 솔루션이다.

낮은 레이턴시로 초당 수백만 건의 요청을 처리할 수 있으며 갑작스러운 트래픽 증대 및 변화에도 최적화 되어있다.

ALB과 비교하여 NLB의 가장 큰 특징은 바로 EIP로 공인 IP를 고정 할 수 있다는 점이다.

그래서 ALB와 달리 로드밸런서에 접글 할때 아이피나 DNS 둘다 사용이 가능하다.

정리하자면 ALB처럼 똑똑하게 주소로 보내주는게 아닌 단순한 라우팅이 필요하고, 트래픽이 극도로 많은 경우에는 ALB 보다는 NLB를 사용하는 것이 적합하다고 할 수 있다.

• NLB는 L4단의 로드 밸런서를 지원
• NLB는 TCP/IP 프로토콜의 헤더를 보고 적절한 패킷으로 전송
• NLB는 IP + 포트번호를 보고 스위칭
• NLB는 할당한 Elastic IP를 Static IP로 사용이 가능하여 DNS Name과 IP주소 모두 사용이 가능
• NLB는 SSL 적용이 인프라 단에서 불가능하여 애플리케이션에서 따로 적용해 주어야 합니다.

ALB vs NLB 비교

• nlb에 비해 7계층까지 확인하는 alb의 기능이 더 많다.
• 그러나, nlb는 network 계층까지만 확인하므로 alb 보다 빠르다.
  따라서 단순한 라우팅이 필요하고, 트래픽이 극도로 많은 경우에는 alb 보다는 nlb를 사용하는 것이 적합하다.
• alb는 path-based routing이 가능하므로 path를 확인하여 특정 서버로 라우팅을 시켜주어야 하는 경우에 적합하다 (api gw)

  참고
  ALB : 클라이언트가 웹화면을 요청하는 상황일때 (HTTP,HTTPS 프로토콜을 사용해서 어플리케이션 레벨 접근할때
  NLB : 내부로 들어온 트래픽을 처리하고, 내부의 인스턴스로 트래픽을 전송할때

GWLB (Gateway Load Balancer)

GWLB(Gateway Load Balancer)는 OSI(Open Systems Interconnection) 모델의 3 번째 계층인 네트워크 계층에서 작동한다.

GWLB를 사용하면 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 확장 및 관리할 수 있다.

즉, 트래픽을 EC2에 도달하기전에 먼저 트래픽을 검사하거나 분석하거나 인증하거나 로깅하는 작업을 먼저 수행할 수 있게 하는 서비스이다.

위에서 배운 일반적인 로드밸런스 역할과는 다르니, 그냥 트래픽을 체크하는 녀석이라고 이해하고 넘어가도 된다.

레퍼런스