☁️ ELB(Elastic Load Balancer) 구성 & 사용법 가이드

ELB (Elastic Load Balancer) 이란

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

ELB는 서로 다른 EC2 인스턴스에 대한 하나의 엔드포인트를 제공한다. 그래서 사용자는 실제 요청이 처리되는 백엔드 인스턴스에 대한 고려 없이, 동일한 엔드포인트로 요청을 전송할 수 있다. 거기다 부하분산뿐만 아니라 부하 분산 대상에 대한 헬스 체크(Health Check), 고정 세션(Sticky), SSL Offload(SSL 암복호화), 헬스 체크를 통한 다운 서버 제외 등이 가능하다.

---

Load Balancing 기능

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

 

1. 부하 분산 처리

Load(부하) Balancing(분산)이란 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다. 말그대로 부하를 분산해 트래픽이 과도하게 몰려 서비스가 중단되는 현상을 막기 위한 기술이다. 그래야 지연 없이 작업을 처리하고 속도를 낼 수 있다. 회사에서 팀장이 외부로부터 받아 처리해야 할 업무를 팀원들에게 나누어 주어 기간안에 일을 처리하는 행위 또한 부하 분산으로 볼 수 있다.

클라이언트 사용자의 무수히 많은 요청들을 각 서버에 적절히 분산한다

 

2. 엔드포인트 역할 제공

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

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

그렇지만 이것을 사용하는 유저 입장에서는 증설된 각각의 인스턴스는 모두 다 일종의 컴퓨터이니 IP 주소를 갖고 있을테고, 이들을 관리하기 위해선 일일히 주소를 백업해 하나하나 접속하면서 관리해야 된다. 뿐만 아니라, 만약 인스턴스 하나가 떨어지고 다시 새로 인스턴스가 올라가게 된다면, IP주소가 바뀌게 되고 이에 대해 별도의 조치를 취해야한다. 더군다나 만약에 인스턴스가 8개가 아니라 엄청 많을 때는 관리비용이 엄청 증가 하게 된다. 따라서 오토스케일링 그룹 자체는 혁신적인 방법이지만 별도의 로드 밸런싱, 부하를 분산해주는 서비스 없이는 활용 불가이기 때문에 그래서 나온 서비스가 Elastic Load Balancing 인 것이다.

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

로드 밸런서(Load Balancer)에서 트래픽을 하나의 경로로 받아서 다수의 인스턴스에 분산하게 되어, 유저 입장에서는 각각의 인스턴스에 일일히 접근해서 관리하는게 아닌 하나의 주소로 접속해서 관리할 수 있게 된다. 인스턴스가 떨어져나가거나 오류가 나서 트래픽을 수신하지 못할 때에도 로드밸런서가 스마트하게(health check / monitoring) 알아서 트래픽을 전송하지 않게 하고, 새로운 인스턴스가 등록이 되면 자동으로 분산을 시켜준다.

---

오토 스케일링과 조합

오토 스케일링은 트래픽을 몰릴때 인스턴스(컴퓨터) 수를 자동으로 늘림으로서 서버 사이즈를 조절해 서비스가 원할히 유지되게 하며, 또한 트래픽이 적을경우 인스턴스를 감소시켜 비용 낭비를 막아주는 서비스이며, ELB(Elastic 로드 밸런서)는 트래픽을 오토 스케일링을 통해 늘린 수만개의 인스턴스들에게 부하(트래픽)를 분산하는 서비스 이다.

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

---

ELB 내부 구성 요소

ELB는 Virtual Private Network(VPC)에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스(EC2 등)에 적절히 부하 분산한다. ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성되, ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있다.

 

리스너(Listener)

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

리스너는 외부의 요청을 받아들이기 때문에 모든 로드 밸런서는 최소 1개 이상의 리스너를 필요로 하며, 최대 10개까지 설정할 수 있다. 뿐만 아니라 SSL 인증서를 게시하여 SSL Offload를 실시할 수도 있다.

 

규칙(Rule)

리스너 룰(rule)은 리스너와 타겟 그룹 사이의 트래픽 분배를 위한 라우팅 규칙에 해당한다. 룰은 우선순위, 액션, 조건 등의 정보를 담고 있으며, path, host, HTTP header, source IP, query parameter 등의 다양한 조건이 만족되었을 때, 지정된 액션을 수행하는 방식으로 작동한다.

 

대상 그룹 (Target Group)

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

만일 dashboard.mydomain.com으로 요청이 오면 ELB가 대시보드 대상그룹으로 트래픽을 전송한다

쉽게 말하자면, 오토스케일링을 하기위해서 인스턴스들을 그룹으로 묶어 오토스케일링 그룹으로 만든 것처럼, 로드 밸런싱 하기위 해서 대상 인스턴스들을 묶어 놓은 그룹이라고 이해 하면된다. 그리고 다시 이 대상 그룹을 오토스케일링 그룹으로도 만들 수 있다. (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를 생성할 때에 생성되는 도메인 이름을 사용해 접근하도록 구성해야 한다. 즉, DNS 이름을 통해 접속하면 ELB는 요청을 대상 그룹에 전달할 것이고 대상 그룹의 EC2가 요청을 처리하는 것이다.

단, 뒤에서 소개할 네트워크 로드밸런서(NLB)는 탄력적 IP로 고정 가능하다.

 

ELB의 요청 처리 과정

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

 

Cross-Zone Load Balancing

아래 그림을 보면 두개의 AZ 영역이 있고 각 영역에 로드 밸런서가 위치하여 영역 내의 ELB 인스턴스를 부하 분산하고 있는 형태이다.

언뜻 보면 문제없이 각 인스턴스에 로드 밸런서가 붙어있어 잘 부하 분산을 시켜줄 것 같지만 현실은 그리 녹록지 않다. 구성도를 보건데 각 AZ 영역마다 위치하고 있는 인스턴스 갯수가 다르다. A 영역에는 인스턴스가 2개 뿐이고, B 영역에는 인스턴스가 8개 이다. 만일 100개의 트래픽이 온다고 하면 이를 단순 수식으로 분산했을 경우 아래와 같이 구성될 것이다.

AZ A에 각각 25개를, AZ B에 각각 6.25개를 전달

애초에 부하 분산이란 트래픽을 대상들에게 고르게 트래픽을 전달하는 것을 말한다. 하지만 위의 구성을 따르면 AZ에따라 부하가 고르게 요청이 전달되지 않고 있다. 만일 AZ A영역에 트래픽이 몰리면 A 영역 내의 EC2들에게 부하가 심하게 걸리게 된다.

따라서 이를 보완하기 위한 기능이 바로 교차 영역 로드밸런싱(Cross Zone Load Balancing)이다. 교차 영역 로드밸런싱을 활성화하면 위 그림과 같이 AZ를 가리지 않고 고르게 부하를 분산한다.

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

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

 

Health Check (상태 검사)

ELB에 연결된 인스턴스에 직접 트래픽을 발생시켜 인스턴스가 살아있는지 체크하는 기능이다. 타겟 그룹에 대한 헬스 체크를 통해 현재 정상적으로 작동하는 인스턴스로만 트래픽을 분배한다.

인스턴스의 상태를 자동으로 감지해서 오류가 있는 시스템은 배제하고, 만일 인스턴스가 회복되면 LB가 자동으로 감지하여 인스턴스에 트래픽을 보내준다.

이를 통해 장애가 전파되는것을 방지하여 고가용성을 확보할 수 있으며, 상태 확인 개선을 통해 상세한 오류 코드를 구성할 수 있다. 또한 새로운 지표로 EC2 인스턴스에서 실행되는 각 서비스의 트래픽을 파악할 수 있다.

헬스 체크는 두가지 상태로 나뉘어진다

• InService(서비스 살음)
• OutofService(서비스 죽음)

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

 

HTTP/HTTPS 체크 방식

 

포트 감시 방식

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

 

추가적인 보안 그룹 설정

로드밸런서 또한 네트워크 인터페이스의 형태를 띄기 때문에 EC2 인스턴스 처럼 ELB와 관련된 보안 그룹을 생성 및 관리하여 로드 밸런서를 위한 추가 네트워킹 및 보안 옵션을 제공할 수 있다.

물론 EC2에도 보안 그룹이 있지만, 외부에 있는 ELB에 한번더 보안그룹을 설정해 외부의 공격(디도스)에 대해 강력하게 대비하는 개념으로 생각하면 된다.

원하는 Load Balancer를 인터넷과 연결되도록 구성하거나 퍼블릭 IP 주소 없이 로드 밸런서를 생성하여 인터넷에 연결되지 않은 내부 로드 밸런서로도 사용할 수 있다.

 

SSL 지원

SSL 암호화를 간편하게 구성 지원한다. 따라서 SSL 증명서를 인스턴스들에 따라 설정할 필요가 없어진다.

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

 

고정 세션 (Sticky Session)

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

🌐 세션(Session) 불일치 문제 및 해결 방법

즉, 사용자 세션을 특정 인스턴스에 고정시킴으로서 자신이 이전에 접속했던 인스턴스로 다시 접속할 수 있도록 해준다.

 

로그 추출 기능

ELB로 처리한 요청 로그를 추출 할 수 있다. 추출한 로그는 S3에 저장된다.  

장애 발생 또는 통신 오류가 발생하면, 인스턴스 로그를 하나하나 확인하는 것보다 ELB 로그를 확인하는 것이 원인을 조사하기에 좋다.

 

CloudWatch 연동

ELB는 1분 단위로 로드 밸런서와 타겟 그룹에 대한 메트릭을 제공한다. 이를 통해, CloudWatch와 연동하고 안정적으로 서비스를 모니터링 할 수 있다.

Amazon CloudWatch가 ALB와 CLB에 대해 요청 횟수, 오류 횟수, 오류 유형, 요청 지연 시간 등의 지표를 보고한다.

 

HTTP/2 지원

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

---

ELB 서비스 종류

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

• Application Load Balancer(ALB)
• Network Load Balancer(NLB)
• Classic Load Balancer(CLB)
• Gateway Load Balancer(GLB)

이 넷 모두 부하분산을 하는 로드밸런서라는 점은 동일하지만 역할이 각각 다르다. aws에서 설정할때 이 셋 중 하나를 선택하여 로드밸런서를 생성하고 그 기능을 사용하게 된다.

Classic Load Balancer(CLB) 는 아주 초창기때 나온 로드밸런서로 지금은 지원이 끊겨 deprecated 처리되었다

---

CLB (Classic Load Balancer)

Classic Load Balancer는 가장 기본적인 형태이자 초기에 제공되던 서비스이다. 가장 기본적인 로드 밸런서의 역할을 수행하지만 서버의 기본주소가 바뀌면 Load Balancer를 새로 생성해야하며 하나의 주소에 하나의 대상 그룹으로 밖에 못 보낸다. 또한, 데이터를 수정/변경할 수 없어 포트, 헤더 등의 변경을 하지 못한다.

이러한 구조는 서버의 구성과 아키텍처가 커지고 복잡해져 비용이 증가하게 된다. 예를 들어 쿠팡에서 회원관리(shop) 인스턴스와 주문(order) 인스턴스가 따로 존재한다고 하자. 로그인 후 주문을 하기 위해서는 그림 처럼 각각 다른 Load Balancer를 거쳐 해당 인스턴스로 접속해야 하므로 서버 개수, 비용이 증가하게 된다. 따라서 현재에는 CLB(Classic LoadBalancer)를 많이 사용하지 않아 레거시로 분류되었고, 주로 NLB 또는 ALB를 사용하여 구성하는 추세이다.

---

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, 요청 메서드 등에 기준을 적용하여 기준에 맞는 적절한 대상그룹으로 라우팅 할 수 있는 로드밸런서 이다. 

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

---

NLB (Network Load Balancer)

Netowrk Load Balancer(NLB)는 AWS에서 제공하는 4가지 로드밸런서 중 하나로 OSI 7 Layer에서 네 번째 계층에 해당하는 Transport Layer를 다루는 로드밸런서이다. 따라서 NLB는 TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시한다. 그래서 NLB는 ALB보다 성능이 더 빠르기 때문에 고성능을 요구하는 환경에서의 부하분산에 적합한 솔루션이다. 낮은 레이턴시로 초당 수백만 건의 요청을 처리할 수 있으며 갑작스러운 트래픽 증대 및 변화에도 최적화 되어있다. 단, HTTP가 아닌 하위 Layer인 TCP Layer에서 처리하므로 HTTP 헤더를 해석하지 못한다.

 

IP 고정 기능

ALB과 비교하여 NLB의 가장 큰 특징은 바로 EIP로 공인 IP를 고정 할 수 있다는 점이다. 그래서 ALB와 달리 로드밸런서에 접근 할때 아이피나 DNS 둘다 사용이 가능하다.

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

 

ALB vs NLB 비교

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

nlb에 비해 7계층까지 확인하는 alb의 기능이 더 많다. 그러나, nlb는 network 계층까지만 확인하므로 alb 보다 빠르다. 따라서 단순한 라우팅이 필요하고, 트래픽이 극도로 많은 경우에는 alb 보다는 nlb를 사용하는 것이 적합하다.

alb는 path-based routing이 가능하므로 path를 확인하여 특정 서버로 라우팅을 시켜주어야 하는 경우에 적합하다

 

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

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

---

GWLB (Gateway Load Balancer)

GWLB(Gateway Load Balancer)는 OSI(Open Systems Interconnection) 모델의 3 번째 계층인 네트워크 계층에서 작동한다. GWLB를 사용하면 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 확장 및 관리할 수 있다. 즉, 트래픽을 EC2에 도달하기전에 먼저 트래픽을 검사하거나 분석하거나 인증하거나 로깅하는 작업을 먼저 수행할 수 있게 하는 서비스이다.

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

---

ELB 서비스 요금 정책

각 ELB 서비스 종류의 요금 정책은 다음과 같다

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

네트워크 트래픽 분산—Elastic Load Balancing 요금 –Amazon Web Services

---

ALB(Application Load Balancer) 생성하기

이 강의는 전 강의인 오토스케일링 포스팅에서 실전 구축한 AWS 시작 템플릿 세팅을 그대로 따라간다. 따라서, 만일 시작 템플릿이 따로 세팅이 안되어있다면 미리 구축하고 오기를 권한다.

[AWS] 📚 Auto Scaling 개념 원리 & 사용 세팅 💯 정리

 

1. 대상 그룹 생성

 

대상 그룹에 등록한 인스턴스 수정

만일 대상 그룹의 인스턴스 멤버들을 수정하고 싶다면, 다시 대상 등록을 해주면 된다.

---

2. 로드 밸런서 생성

로드밸런싱의 리스닝 역할이 어떻게 전개되는지 이해하기 위해 다음과 같이 로드 밸런서에는 81번 포트를, 인스턴스에는 80번 포트를 주어 구성해볼 것이다. 즉, 일반적으로 브라우저를 통해 웹서버에 접속할때 HTTP(80번 포트)를 이용하게 되지만, 로드밸런서로 81번포트로 접속해서 다시 로드밸런서가 80번포트로 대상 그룹 EC2 인스턴스들에게 분배하는 과정을 직접 구현해보는 시간을 가지는 것이다.

 

 

기본 구성

항목	설명
name	Load  Balancer 이름
scheme(제도)	- internet-facing(인터넷 연결) : 인터넷에 연결되는 로드밸런서 - internal(내부의) : 인터넷에 연결 안되는 로드밸런서
ip address type(IP주소 유형)	lb의 ip 주소 형식

ELB는 크게 외부 인터넷에서 접속이 가능한, 공인 IP와 사설 IP 모두를 갖는 인터넷(Internet) 로드밸런서와 내부에서의 접근만을 허용하며 사설 IP를 갖는 내부(Internal) 로드밸런서로 구분된다. 보통 웹서비스를 구성할 때 외부 사용자들의 접근을 위한 웹 서버를 Internet LB의 부하 분산 대상으로 삼고, 내부 애플리케이션 서버를 Internal LB의 부하분산의 대상으로 삼아 구성하는 편이다. 이러한 2개의 ELB를 조합하면, 3계층 시스템(웹서버, APP서버, DB서버)처럼 애플리케이션의 여러 계층으로 요청을 분산하는 아키텍처를 구성할 수 있게 된다.

 

네트워크 매핑

 

보안 그룹 설정

새 보안그룹 생성을 해서 로드밸런서의 인바운드 규칙을 81번 포트만 허용으로 설정하고 적용해준다. (81번 포트를 통해 로드밸런서에 접속할 예정이니까)

 

리스너 & 라우팅 설정

리스너 및 라우팅 항목에서는 로드 밸런서의 포트를 81번으로 놓아보자. 그리고 위에서 생성한 대상 그룹을 등록해준다. 앞으로 인터넷 브라우저에서 웹사이트에 접속할때 인스턴스의 DNS가 아닌 로드 밸런서의 DNS로 접속할텐데, 로드밸런서 도메인:81 번 포트로 접속하면 인스턴스(타겟그룹)에 HTTP(80)번 포트로 보내주겠다는 설정이다.

 

ALB 활성하기

설정을 마쳤으면 로드 밸런서를 생성해준다.

---

3. ALB 작동 테스트

이제 위의 DNS url에 설정했던 포트 81을 붙여서 브라우저에 띄워보면, 대상 그룹에서 설정한 인스턴스 두개가 로드 밸런싱을 통해 랜덤 접근 되어짐을 볼수 있다. (새로고침을 여러번 해보자).

HTTP 프로토콜 포트는 80번이다. 원래라면 인스턴스 DNS에 80번 포트를 붙여야 인스턴스의 웹서버로 접근이 될테지만, 로드벨런서(81번 포트)로 접근을 하면, 위에서 설정했던 대상그룹 세팅(HTTP/ :80)에 따라 알아서 인스턴스 포트 80번으로 가 웹페이지가 뜨게 되는 것이다. 즉, DNS로 로드 밸런서에 접근하면, 로드 밸런서가 대상그룹으로 번갈아가면서 인터넷에서 오는 트래픽을 분산하고 있는 것을 알수 있다.

---

NLB(Network Load Balancer) 생성하기

NLB 만드는 방법 역시 ALB와 별 차이 없다.  UI도 같아서 그냥 위와같이 만들면 된다. 단, NLB는 Layer4 계층에서 동작하기 때문에 반드시 대상 그룹에서 규약을 TCP/UDP로 설정해줘야 NLB에 대상 그룹을 등록할수 있다.

 

1. NLB용 대상 그룹 생성

---

2. 로드밸런서(NLB) 생성

NLB는 ALB과는 달리 보안 그룹 세팅이 없다.

---

ALB 지능적 라우팅 (L7 Header)

여기까지 보면 ALB와 NLB의 차이가 없어 보일수 있다. 물론 ALB는 HTTP/HTTPS를 지원하고 NLB는 TCP/UDP까지만 지원한다는 차이가 있지만, 이는 내부적인 차이이지 외부 사용자 입장에서 둘다 똑같이 로드밸런싱 한다는 점 이외에 별 차이점이 없어 보이는게 사실이다.

사실 NLB는 ALB보다 4계층까지만 IP 패킷을 생성하기때문에 훨씬 빠르다. 따라서 단순히 부하를 분산이 필요하면 NLB를 이용하는 것이 적절하다고 볼 수 있다. 하지만 ALB만의 무기가 있는데 바로 7계층의 헤더를 파악할수 있다는 점이다.

위에서 언급했듯이 포트나 경로에 따라 각 대상그룹으로 보내 훨씬 효율적으로 부하분산을 할수있으며 아키텍쳐 비용역시 아낄수 있다. 그리고 이 설정은 리스너 탭에서 규칙(Rule)을 통해 설정 할 수 있다. (참고로 NLB는 규칙 설정이 없다.)

---

ELB + Auto Scaling 조합 구축하기

앞서 말했듯이 ELB와 오토 스케일링의 조합은 EC2의 꽃이라고 할 수 있을 정도로 강력한 인프라 세팅이다. 아래 구성도를 보면, AWS Cloud 안에 VPC가 있고 다양한 가용영역 안에 오토스케일링 그룹을 통해서 EC2를 분산해놓은 걸 볼 수 있다. 이렇게 구성해놓은 애플리케이션은 고가용성과 장애내구성 확보에 좋다.

지난 시간과 이번 시간에 각각 오토스케일링과 ELB를 성공적으로 구축을 해보았으니 이 둘을 조합해보자.

 

오토 스케일링 그룹 설정

ELB와 오토스케일링을 조합하기 위해선, 로드 밸런싱 세팅을 오토스케일링 그룹에서 설정해야 한다.

그러면 이제부터 다음 그림과 같이 오토스케일링을 통해 증설된 인스턴스들은 자동으로 로드밸런서의 대상 그룹으로 들어가게 되는 것이다. 그래서 로드밸런서의 DNS로 인터넷 브라우저에 접속하게 되면, 대상그룹이자 오토스케일링 그룹의 인스턴스로 가게되며, 만일 트래픽이 더 몰리게 되면 스케일 아웃되어 인스턴스 갯수가 늘어나고 늘어난 인스턴스 갯수만큼 로드밸런싱을 하여 서비스를 유지하는 원리라고 볼 수 있다.

 

ELB + 오토 스케일링 조합 테스트

ELB와 Auto Scaling 이 잘 동작하는지 확인을 위해 오토스케일링 그룹의 용량을 3개로 늘려보자. 

인스턴스가 3개로 스케일 아웃이 되며, 대상그룹에도 추가된 인스턴스가 포함됨을 확인 할 수 있다.

---

ELB와 오토 스케일링 Health Check 차이

앞서 배웠듯이 헬스 체트(Halth Check)는 그룹에 있는 인스턴스가 비정상적인 상태에 있는지 체크하는 것이다. 그런데 ELB + 오토 스케일링 조합 인프라에서 다음과 같은, 오토스케일링 그룹에서는 정상적인데 ELB 입장에서 비정상인 경우가 존재한다. 예를들어 EC2 인스턴스는 잘 실행되고 있는데 인스턴스의 웹서버가 죽으면 어떻게 될까?

$ sudo -s # root권한 획득
$ service httpd stop # 아파치 웹서버 가동 중지

로드밸런서 DNS으로 접속해보면 하나의 인스턴스가 이렇게 502 에러를 내게 된다. (당연히 웹서버를 중지했으니까)

왜냐하면 ELB 입장에서는 헬스 체크를 통해 인스턴스로 트래픽을 보내서 HTTP연결이 잘되는지 안되는지 확인하게되는데 웹서버가 죽게되면 상태 확인이 안되서 이 인스턴스는 건강하지 않는 것으로 판단해 배제버리기 때문이다. 그러나 오토 스케일링 입장에서는 인스턴스의 웹서버가 죽든말든 인스턴스(컴퓨팅)만 잘 돌아가면 정상이기 때문에 정상으로 판단하게 된다.

 

Health Check 통일하기

이처럼 오토스케일링 그룹과 로드밸런서 대상그룹에서 각각 상태 확인하는 기준이 다르게 될수 있다.  오토 스케일링과 로드밸런싱은 둘이 유기적으로 잘 돌아가야 되기 때문에 이 둘의 헬스 체크를 일치화 시켜줄 필요가 있다.

오토 스케일링 그룹에 가서 상태 확인 편집을 누른다.

여기서 ELB를 체크하게 되면, 오토스케일링 그룹에서 EC2 상태 확인 뿐만 아니라 ELB로부터의 상태 확인도 체크하게 된다. 즉, EC2를 체크해봤는데 문제는 없지만, ELB 너가 체크해서 문제가 있다고 하면 네말 듣고 네말대로 할께 라는 뜻이다.

일정 시간이 지나게 되면 (꽤 기다려야 한다), 오토스케일링 인스턴스 관리 탭에서 다음 사진과 같이 인스턴스 하나가 죽게되고(인스턴스 자체는 멀쩡한데 ELB가 이상하다고 하니까 죽인것이다) 새로 하나 생성됨을 확인 할 수 있다. 즉 이 행위는 자동으로 장애를 복구한 고가용성 이라고 말할수 있다.

---

Stickey Session 적용하기

고정 세션은 대상그룹에서 설정이 가능하다.

이제 고정 섹션이 enable이 되서 쿠키를 생성해서 10초동안은 계속 같은 인스턴스에 접속되게 된다.

한번 로드밸런서 DNS로 새로고침을 해보자. 계속 같은 인스턴스 ID가 출력될 것이고, 10초가 지나면 다른 인스턴스 ID가 출력될 것이다.

---

대상그룹 Health Check 설정 항목

health check는 target group에 속한 서비스가 살았는지 죽었는지를 체크할 때 사용된다.

항목	설명
protocol	health check에 사용될 프로토콜 (http)
Path	health check할 page
port	traffic port 설정
Healthy threshold	서비스 상태를 성공으로 간주하는 연속 health check의 횟수 (2-10)
Unhealthy threshold	서비스 상태를 실패로 간주하는 연속 health check의 횟수 (2-10)
Timeout	응답이 없으면 상태 확인이 실패했음을 의미하는 시간(초)(2-120초)
interval	health check 간격 (5-300)
Success Code	health check성공 코드

---

로드밸런서 리스너 설정

로드밸런서 탭의 Listenser를 편집해서 연결되는 대상그룹(target group) 변경 할수 있다.

---

ELB + EC2 보안그룹 설정

보안을 위해 EC2 인스턴스 보안그룹에서 오로지 ELB의 보안그룹을 통과한 트래픽만 받게 하고 싶다. 따로 아이피나 DNS로 EC2 인스턴스에 바로 접속하게 하지말고 무조건 로드밸런서를 통해 접속하도록 설정한다는 개념이다. 하지만, ALB같은 경우 매번 아이피가 바뀌어 IP를 EC2 보안그룹 규칙 입력란에 등록 할수없다.

이때는 보안그룹 소스 입력란에 보안그룹 자체를 지정해주어서 설정해야 한다. 따라서 EC2 보안그룹 규칙 편집에서 소스 입력란에 ELB의 보안그룹 ID를 넣어주면 된다.

보안그룹 규칙 편집에서 소스 입력란에는 아이피만 적어줄수 있는게 아니다. 예를들어 A 보안그룹과 B 보안그룹이 있다면, A 보안그룹 규칙에 B 보안그룹 ID를 설정할수가 있는데, 이 의미는 B 보안그룹을 통과한 트래픽만을 받겠다는 의미이다.

---

# 참고자료

생활코딩 Elastic Load Balancer (ELB)

AWS 강의실 쉽게 설명하는 AWS 기초 강좌

https://ko.wikipedia.org/wiki/%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0

https://www.cloud4u.com/blog/what-is-a-load-balancer-and-its-types/

https://www.kinx.net/service/cloud/compute/autoscaling/

https://medium.com/harrythegreat/aws-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-9fd0955f859e

https://aws-hyoh.tistory.com/128

https://aws-hyoh.tistory.com/133

https://velog.io/@groovejumat/AWS-Elastic-Load-Balancer%EB%A5%BC-%ED%86%B5%ED%95%9C-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

https://dev.classmethod.jp/articles/for-beginner-load-balancer-explanation/