Elastic Load Balancer (ELB)

오토스케일링을 통해서 다수의 인스턴스를 생성하여 안정적인 서비스를 제공할 수 있다. 

auto scaling은 부하를 분산해주는 서비스가 없이는 활용이 거의 불가능하다.

그래서 나온 서비스가 Elastic Load Balancer (ELB)이다. 

 

꼭 오토스케일링 그룹이 아니더라도 다수의 인스턴스들을 한 대로 묶어서 트래픽을 하나의 경로로 알아서 분산해 주는 서비스가 바로 로드밸런서다. 

유저 입장에서는 각각의 인스턴스의 IP 주소로 접근하는 것이 아니라 하나의 주소로 접속하기만 해도 이 로드밸런서가 알아서 통신 트래픽들을 분산해 준다. 

인스턴스가 unhealthy면 알아서 해당 인스턴스에 트래픽을 전송하지 않는다. 

또 새로운 인스턴스들이 등록이 되면 자동으로 분산을 시켜준다. 

그래서 로드밸런서의 기능은 간단하게 말하면 부하를 분배해주는 것이다. 

 

"Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소, Lambda 함수와 같은 여러 대상에 자동으로 분산시킵니다. Elastic Load Balancing은 단일 가용 영역 또는 여러 가용 영역에서 다양한 애플리케이션 부하를 처리할 수 있습니다. Elastic Load Balancing이 제공하는 세 가지 로드 밸런서는 모두 애플리케이션의 내결함성에 필요한 고가용성, 자동 확장/축소, 강력한 보안을 갖추고 있습니다. "

 

*정리

- 다수의 서비스에 트래픽을 분산 시켜주는 서비스

- Health Check: 직접 트래픽을 발생시켜 instance가 살아있는지 체크 

- Autoscaling과 연동 가능 

- 여러 가용영역에 분산 가능 

- 지속적으로 IP 주소가 바뀌며 IP 고정 불가능 : 항상 도메인 기반으로 사용  

- 총 4가지 종류

    - 1. Application Load Balancer

    - 2. Network Load Balancer   → IP고정 

    - 3. Classic Load Balancer

    - 4. Gateway Load Balancer

 

1. Application Load Balancer

- 똑똑한 녀석

- 트래픽을 모니터링하여 라우팅 가능

    - 예: image.sample.com → 이미지 서버로, web.sample.com → 웹 서버로 트래픽 분산

    - ㄴ 유저가 어떤 주소로 접속했느냐에 따라서 다른 경로로 라우팅이 가능하다.

 

2. Network Load Balancer

- 빠른 녀석

- TCP 기반 빠른 트래픽 분산

- Elastic IP 할당 가능 

 

3. Classic Load Balancer

- 옛날 녀석

- 현재는 잘 사용되지 않음

 

4. Gateway Load Balancer

- 먼저 트래픽을 체크하는 녀석

- 가상 어플라이언스 배포/확장 관리를 위한 서비스 

클라이언트가 Gateway Load Balancer를 통해서 EC2에 접속을 할 때, 트래픽을 먼저 네트워크 어플라이언스로 전달을 해서 트래픽을 가지고 무언가를 한다. 트래픽을 검사, 분석, 인증, 로깅하는 작업을 먼저 수행할 수 있도록 도와주는 서비스다. 

 

 

# 대상그룹 (Target Group)

- ALB(Application Load Balancer)가 라우팅 할 대상의 집합 

- 구성

    - 3+1가지 종류

        - Intance

        - public IP

        - Lambda

        - ALB

    - 프로토콜 (HTTP, HTTPS, gRPC 등)

    - 기타 설정

        - 트래픽 분산 알고리즘, 고정 세션 등

 

 

 

 

# 실습

1. 시작 템플릿

앞에 오토스케일링 때 만들었던 시작 템플릿 그대로 이용

작업 -> 새 버전 생성 

다른거 다 필요없고 쭉 내려서 '고급 세부 정보' 토글을 열고 

#!/bin/bash
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
yum install httpd -y
echo ""$INSTANCE_ID"" >> /var/www/html/index.html
service httpd start

 

이 스크립트를 EC2 인스턴스가 생성될 때 자동으로 실행하겠다는 뜻이다. 

그리고 생성. 생성하면 버전 몇인지 다음 화면에서 알려줄 것이다. 지금 이거 실습할 때는 2였다. 

 

 

2. Auto Scaling 그룹 편집

버전을 방금 생성한 Latest로 하고 '업데이트' 버튼 클릭

 

다시 원하는 용량 2로 늘려서 인스턴스 생성.

그러면 이제 인스턴스 2개가 생성되기 시작할 것이다. 

 

 

3. 대상 그룹 생성

인스턴스를 선택 후 '아래에 보류 중인 것으로 포함' 누르고 '대상 그룹 생성'

이제 이 대상 그룹으로 로드 밸런싱을 해보자

 

 

4. 로드밸런서 생성 

Application Load Balancer를 누른다 

 

대상 그룹에 방금 우리가 만든 걸 지정한다. 

그리고 생성.

상태가 '프로비저닝 중'인데, 여기서 좀 기다려야 한다. 

 

*결과:

로드밸런서가 두개의 인스턴스를 번갈아가면서 트래픽 분산을 해주는 것을 확인할 수 있다. 

 

 

 

---

이제 우리가 만든 로드밸런서를 오토스케일링에 붙여보자. 

오토스케일링 그룹 세부로 들어가면, 아래 사진과 같이 로드밸런싱 섹션이 있다. 

편집을 누르고, 

대상 그룹을 선택하고 업데이트를 누른다. 

그러면 이제부터 오토스케일링을 통해 생성되는 모든 인스턴스들은 대상 그룹에 등록이 될 것이다. 

확인해 보기 위해 원하는 용량을 3개로 늘려보자. 

인스턴스가 하나 더 늘어나고 있는걸 볼 수 있다. 

 

이제 대상 그룹에 가서 확인을 해보면,

등록하는데 10~20초 정도 걸리는 것 같다. 

상태 확인이 healthy가 되었으면, 

새로 추가된 인스턴스가 로드밸런서에 의해 연결된 것을 볼 수 있다. 

 

 

 

---

근데, 오토스케일링 그룹에서는 정상인데, ELB 입장에서는 비정상이면 어떡할까? 이게 뭔소리고

예를 들어, EC2 인스턴스는 올라가 있는데 웹서버는 죽는 경우.

로드밸런서 입장에서는 웹서버가 죽으면 뭔가 보여줄게 없기 때문에 비정상이다. 

그런데 오토스케일링 입장에서는 웹서버가 살았는지 죽었는지 관심은 없고 EC2만 정상적으로 올라가 있으면 상관이 없다. 

그러면 어떤 상황이 발생하게 되느냐?

새로고침 할때마다 잘 되다가 갑자기 502 BAD GATEWAY 뜸.

 

그럼 뭘 해줘야 하는데? 

바로 health check

 

실습을 위해 3개의 EC2 인스턴스 중 하나의 웹서버를 꺼보자.

그러면 대상그룹의 상태확인을 보면 하나가 unhealthy일 것이다. 

왜? 트래픽을 달라했는데 아무것도 안주고 있기 때문.

그런데, 오토스케일링 그룹에 들어가서 인스턴스들을 보면, 

모두 healthy 상태이다. 오토스케일링 그룹 입장에서는 인스턴스만 켜져있으면 자기 할 일 한거거든요. 

 

 

오토스케일링 그룹으로 들어가서 '상태 확인' 세션에서 '편집' 클릭 

'Elastic Load Balancer 상태 확인 켜기' 클릭!!

 

아 안된다. 

왜냐? t2.micro는 ap-northeast-2a랑 2c에서만 되기 때문에 2d는 안된다고 뭐라뭐라 하는데, 내가 오토스케일링 그룹에 abcd 다 넣어줘서 그런 것 같다. 

시작 템플릿에서 템플릿 수정으로 t3.micro로 변환한 후 새 버전을 만들어서 오토 스케일링 그룹에 다시 반영을 해보자. 

 

 

0a로 시작하는 인스턴스의 웹 서버를 껐더니 unhealthy 로 바뀌었다. 

오토 스케일링 그룹으로 들어가보자. 

바로 들어가더니 아직 전부 다 healthy 인데, 

조금 더 기다리니 0a가 unhealthy가 되었고, 로드밸러서 도메인 주소로 접속하여 계속 새로고침을 해보면, 죽은 인스턴스의 웹서버(502 bad gateway)가 뜨지 않았다.