AWS - ELB & ASG

ELB(Elastic Load Balancer)

ASG(Auto Scaling Group)

 

확장성

: Application System의 조정을 통해 더 많은 양을 처리할 수 있음

 

1) 수직 확장성

- 인스턴스의 크기를 확장하는 것 

예1. 주니어 개발자가 시니어 개발자로 성장시키는 것

예2. 인스턴스 타입, 디스크 용량 확장(t2.micro -> t2.large)

 

언제 사용?

- 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용하며, RDS, ElasticCache 등의 데이터베이스가 예시이다.

하위 인스턴스의 유형을 업그레이드하는 것이 수직적으로의 확장이다.

 

한계

- 하드웨어 상의 제약이 있다.

 

2) 수평 확장성

- Application에서 Instance를 늘리거나 System 수를 늘리는 것

예1) 주니어 개발자를 시니어 개발자로 성장시키기 보다는 주니어 개발자를 더 채용해서 업무를 분할하여 수행하는 것

예2) 콜센터(A)에서 진행하던 콜업무를 콜센터(B)를 두어서 콜업무를 분할하여 병렬적으로 동시 수행하는 것

- 분배 시스템이 내부적으로 있음

 

언제 사용?

- 웹이나 현대적 Application은 대부분 분배 시스템으로 구성되어 있으며, EC2 덕에 수평적 확장이 더욱 수월함

 

High Availability (고사용성)

: 보통 수평확장과 함께 사용되는 개념이지만 항상은 아님 

- Application or System이 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동중임을 말함

- 데이터 센터에서의 손실을 막고자 하며, 센터 하나가 다운되어도 다른 센터가 있기 때문에 지속해서 작동함

 

예:) 판교 데이터 센터랑 김포 데이터 센터 중구 데이터센터가 있다할 때 판교 데이터 센터가 다운되어도 나머지

두 센터가 있어서 기존 돌아가는 업무 자체는 다운되지 않고 잘 기동된다. ( > 가용성이 높다 = 고사용성)

 

 

고사용성

- 수동적

: RDS가 다중 AZ를 갖추고 있다면 수동형 고가용성을 확보한 것

- 능동적

: 수평적 확장으로, 콜센터  부서를 추가해서 작업을 병렬 및 동시적으로 수행하는 것을 의미

 

정의: 동일한 Application의 동일 Instance를 다수의 AZ에 걸쳐 실행하는 경우이며 다중 AZ가 활성화된 자동 스케일러 그룹이나 

로드 밸런서에서도 사용됩니다.

 

 

---

Load Balancer

: 서버나 서버 셋으로 트래픽을 백앤드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할

사용자가 AWS Cloud로 접근할 때 가상 사설 클라우드로 선 접근하고 여기서 정의된 게이트웨이라든지 라우터라든지 설정된 

환경에 맞게 접근합니다.

그러면 서브넷을 통해 트래픽이 들어오고 이 트래픽을 각 인스턴스에 보내주는 것이 ELB의 역할입니다.

유연하게 로드 밸런서 역할을 한다고 생각하면 됩니다.

 

사용자가 많을수록 EC2 인스턴스로 가는 부하가 더욱 분산되지만, 사용자는 자기가 어떤 인스턴스에 연결된 지를 알 수 없습니다.

사용자들은 자신들이 ELB에 연결되면 한 엔드포인트에 연결된다는 것만 알고 있습니다.

 

 

왜 ELB를 사용해야 하는가?

: ELB는 사용하는 것이 좋다.     트래픽을 분산시켜 부하를 막고 효율적으로 업무 처리가 가능하기 때문이다.

 1) Application에서 단일 액세스 지점(DNS)을 노출하게 되고 Down Stream Instances의 장애를 원활하게 처리할 수 있습니다.

2) Load Balancer가 현재 인스턴스 상태를 확인하는 메커니즘을 통해 로드 상태를 체크하고 각 인스턴스의 컨디션에 따라

트래픽을 어디에 보내야하고 어디에 보내면 안될 지를 정의합니다.

3) SSL 종료도 가능하며, 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있습니다.

4) 쿠키로 고정도를 강화할 수 있습니다.

5) 영역에 걸친 고사용성을 지닙니다.

6) Cloud 내의 개인 트래픽과 공공 트래픽을 분리할 수 있습니다.

7) 로드 밸런서를 관리하는 형태로, 어떠한 경우에도 작동을 보장하며 AWS에서 자체적으로 관리합니다.

8) AWS가 업그레이드와 유지 관리 및 고사용성을 책임지며, 로드 밸런서의 작동 방식을 ELB가 수정할 수 있게함

 

Load Balancer는 다수의 AWS Services와 통합되어 있습니다.

- EC2, EC2 Auto Scaling Group, Amazon EC2 Instance와 인증서 관리(ACM), CloudWatch, Route 53

WAF Global Accelerator 등에서 사용

 

로드 밸런서는 포트와 라우트에서 인스턴스의 상태를 체크합니다.

[Router 설정]
Protocol : HTTP
Port : 4567
End Point : /health

이렇게 로드 밸런서가 인스턴스에게 신호를 보낼 때 상태값으로 200이 오지 않는다면, 상태가 좋지 못하다고 여겨 해당 인스턴스에

트래픽을 보내지 않습니다.

 

 

AWS - ELB (관리형 로드 밸런서 = 로드 밸런서를 관리하는 총괄 역할)

1) Classic Load Balancer

- v1 (Old Generation)

- 2009년형 

- CLB라 부름

- HTTP, HTTPS, TCP, SSL, Secure TCP를 지원

- 콘솔에선 더이상 사용하지 않지만 수동적으로 만들 순 있음(권장하지 않음)

 

2) Application Load Balancer

- v2(New Generation)

- 2016년형

- ALB라 부름

- HTTP, HTTPS, Web Socket Protocol 지원

 

3) Network Load Balancer

- v2(New Generation)

- 2017년형

- NLB라 부름

- TCP, TLS(Secure TCP), UDP Protocol 지원

 

4) Gateway Load Balancer

- 2020년형

- GWLB라 부름

- 네트워크 레이어 3계층에서 활용됨

- IP Protocol에서 작동

 

 

일부 Load Balancer는 내부에 설정될 수 있어 네트워크에 개인적인 접근이 가능하며, 웹 사이트나 공공 Applicaiton 등

여러 다양한 곳에서도 사용 가능한 외부 공공 로드 밸런서도 있습니다.

 

 

사용자가 로드 밸런서에 접근하는 건 어떠한 경우에도 접근 가능하도록 해야합니다.

그래야 사용자가 HTTP, HTTPS 프로토콜을 통해 어디서든 접근할 수 있기 때문입니다.

따라서 사용자와 로드밸런서 사이에서의 Security Group은 HTTP : TCP : 80번포트 : 0.0.0.0/0

과 HTTPS : TCP : 443번포트 : 0.0.0.0/0 으로 구성되게 됩니다.

 

 

하지만 Load Balancer는 EC2 인스턴스에 트래픽을 보낼 때, EC2 인스턴스는 로드 밸런서에 대해서만 허용해야 하므로

(Application Security Group: Allow Traffic only from Load Balanceer)

HTTP : TCP : 80번포트 : 지정 보안그룹과 HTTPS : TCP : 443번포트 : 지정 보안그룹을 가지게 됩니다.

즉, EC2 인스턴스의 보안 그룹을 로드 밸런서의 보안 그룹으로 연결하는 것이고 따라서 로드 밸런서를 통해 들어오는

트래픽에 대해서만 EC2 인스턴스는 허용하기 때문에 강화된 보안 메커니즘을 가지게 되는 것입니다.