[AWS] ELB(Elastic Load Balancing)

load balancing(로드 밸런싱)이란?

• Load Balances(로드 밸런서)는 서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할을 한다.
• 필요한 이유
   : 부하를 다수의 다운스트림 인스턴스로 분산시키기 위해서이다.
   : 애플리케이션에 단일 액세스 지점(DNS)을 노출하게 된다.
   : 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다.
   : 인스턴스의 상태를 확인할 수 있다.  (로드 밸런서가 상태 확인 메커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인해주기 때문에)
   : SSL 종료도 할 수 있어서 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있다.
   : 영역에 걸친 고가용성을 가진다.
   : 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다.

(출처 : 구글이미지)

• 예를 들어 EC2 인스턴스가 위의 이미지처럼 세 개가 있다고 하고, 인스턴스 앞에는 ELB(일래스틱 로드 밸런서)가 있고 뒤에는 서버셋이 있다. 위의 예시에서 세 유저들은 ELB로 바로 연결된다.
• 첫 번째 유저의 로드는 백엔드 EC2 인스턴스 중 하나로 연결이 된다.
   그리고 로드 밸런싱 덕분에 이때 다른 유저가 ELB에 연결된 경우, 이 로든느 다른 EC2 인스턴스로 보내지게 된다.
   마지막으로 세 번째 유저가 일래스틱 로드 밸런서에 연결되면 로드 밸런싱에 의해 세 번째 EC2 인스턴스로 보내진다.
• 그러니 더 많은 유저가 연결될 수록 EC2 인스턴스로 가는 부하가 더욱 분산 되는 것이다.
   하지만 유저는 자신들이 백엔드 인스턴스 중 어떤 것에 연결되어 있는지 알 수 없다.
   유저들은 단지, 자신들이 ELB에 연결되면 한 엔드 포인트에 연결이 된다는 것만 알고 있다.

 

Health Checks(상태 확인)

• ELB가 EC2 인스턴스의 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용된다.
• 만약 제대로 작동하는 중이 아니라면, 해당 인스턴스로는 트래픽을 보낼 수 없기 때문에 로드 밸런서에겐 인스턴스의 상태가 아주 중요하다.
• 상태 확인은 port(포트)와 route(라우트)에서 이뤄진다.
• 만약, EC2 인스턴스가 괜찮다는 신호, 즉 HTTP 상태 코드로 200으로 응답하지 않는다면, 인스턴스 상태가 좋지 않다고 기록된다.

(출처 : 구글이미지)

• 위의 이미지 예시에서 프로토콜은 HTTP이고, 포트는 4567, 엔드포인트는 /health이다.
    : 이런 라우트가 애플리케이션 입장에서는 애플리케이션의 상태를 확인하기 쉬울 수 있다.

 

 ELB(Elastic Load Balancing)

• managed load balancer(관리형 로드 밸런서)이다.
   - AWS가 관리하며, 어떤 경우에도 작동할 것을 보장한다.
   - AWS가 업그레이드와 유지 관리 및 고가용성을 책임진다.
   - AWS가 로드 밸런서의 작동 방식을 수정할 수 있게끔 일부 구성 knobs(놉)도 제공한다.
   - 애플리케이션에 사용 가능한 정적 DNS 이름을 제공한다.
• ELB는 무조건 쓰는 편이 좋다.
   : 자체 로드 밸런서를 마련하는 것보다 저렴하고 자체 로드 밸런서를 직접 관리하려면 확장성 측면에서 굉장히 번거롭기 때문이다.
• 다수의 AWS의 서비스들과 통합되어 있다. (그래서 aws 로드 밸런싱에는 무조건 ELB를 사용하는 것이 좋다)
   - EC2 인스턴스,  스케일링 그룹, Amazon ECS, 인증서 관리(ACM), CloudWatch, Route 53, AWS WAF, AWS Global Accelerator등

 

 AWS의 관리형 로드 밸런서 (4종류)

• 더 많은 기능을 가지고 있는 신형 로드밸런서를 사용하는 것이 권장도니다.
• 일부 로드 밸런서들은 내부에 설정될 수 있어 네트워크에 개인적 접근이 가능하고, 
   웹사이트와 공공 애플리케이션 모두에 사용이 가능한 외부 공공 로드 밸런서도 있다.

CLB(Classic Load Balancer) - 2009

• HTTP, HTTPS, TCP, SSL와 secure TCP를 지원한다.
• 이제는 AWS에서 이 로드 밸런서의 사용을 권장하지 않고 있기 때문에 콘솔에서 더 이상 사용할 수 없는 것으로 나오지만, 사용이 가능하기는 하다

ALB(Application Load Balancer) - 2016

• HTTP, HTTPS와 WebSocket 프로토콜을 지원한다.

NLB(Network Load Balancer) - 2017

• TCP, TLS, secure TCP와 UDP 프로토콜을 지원한다.

GWLB(Gateway Load Balancer) - 2020

• 3계층과 IP 프로토콜에서 자동하는 것이다.

 

 

Load Balancer Security Groups(로드밸런서 보안 그룹)

• 유저는 HTTP나 HTTPS를 사용해 어디서든 로드 밸런서에 접근이 가능하다.
   따라서 보안 그룹의 규칙은 밑의 이미지에 보이는 형태가 될 것이다.

(출처 : 구글이미지)

• 포트 범위는 80, 혹은 443이고, 소스는 0.0.0.0/0인데 어디든 가능하다는 뜻이다.
   로드 밸러서에 유저의 연결을 허용한다는 것이다.
• 위에 이미지에서 EC2 인스턴스는 로드 밸런서를 통해 곧장 들어오는 트래픽만을 허용해야 하기 때문에 EC2 인스턴스의 보안 그룹 규칙은 조금 달라야 한다.(맨 밑의 이미지)
   : 포트 80에서 HTTP 트래픽을 허용하며 소스는 IP범위가 아니라 보안 그룹이 된다.
   : EC2 인스턴스의 보안 그룹을 로드 밸런서의 보안 그룹으로 연결하는 것이다.
   = 이렇게 함으로써, EC2 인스턴스는 로드 밸런서에서 온 트래픽만을 허용하게 되는, 강화된 보안 메커니즘이 되는 것이다.