[AWS] 로드밸런싱 - ALB를 통한 로드밸런싱

 

로드밸런싱(Elastic Load Balancing)

- 서버에 가해지는 부하(로드)를, 분산(밸런싱)해주는 기술 또는 장치

- 클라이언트와 서버 중간에 위치

ex. 서버 한 곳(인스턴스 A)에 트래픽이 몰리는 상황이 발생할 때, 이를 막기위해 여러 대의 서버(인스턴스 B, C)로 트래픽 분산

- 종류 : ALB, NLB, CLB

 

---

로드 밸런서는 크게 자신이 서비스하는 대상을 정의하는 1. 리스너 와, 부하 분산 대상을 정의하는 2. 대상 그룹으로 이루어져있다.

 

1. 리스너
- 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스
- 로드 밸런서에서 서비스하고자 하는 프로토콜과 포트를 지정하는 규칙(Rule)을 생성

2. 대상 그룹
- 하나 이상의 대상에 대하여 라우팅하여 부하 분산을 하는데 사용
- 대상 그룹에 속한 대상에 대해 주기적으로 확인하는 Keepalive 프로세스를 통해 상태 확인을 수행함
- 정상적인 상태의 대상에게만 데이터 전달

---

[실습 목표]

 

ELB의 3가지 유형의 로드 밸런싱 중에, ALB와 NLB를 생성하여

부하 분산을 통한 고가용성 환경을 구성하고, 각 로드 밸런서의 차이와 통신 과정을 살펴보자

​

 

---

1. 기본환경

CloudFormation으로 위 아키텍처 구성

(나는 구글 드라이브 - 로드밸런싱 - ALB 폴더에 저장해놓음)

 

ELB-EC2-1와 ELB-EC2-2 인스턴스에는 HTTP와 SNMP 서비스를 설정해놓았다.

​

---

2. ALB(Application Load Balancer) 생성

 

ALB란,HTTP, HTTPS와 같이 웹 어플리케이션에 대한 분산 처리를 제공하는 로드 밸런서

 

[#1. ALB 생성]

EC2 - 로드밸런서 - Application Load Balancer 클릭

로드 밸런서 이름 : 원하는 이름으로 지정

Scheme : Internet-facing

IP address type : IPv4 

VPC : ELB-VPC

Mappings : ap-northeast-2a

Subnet : 서브넷 선택

 

Mappings : ap-northeast-2c

Subnet : 서브넷 선택

Security groups : ELB-VPC의 보안그룹 클릭

리스너 : 프로토콜 HTTP, 포트 80

Default action에서도 지정해주어야 하는데, 생성된 타겟그룹이 없으므로 생성해보자

 

Create target group 클릭

 

[타겟 그룹 생성]

 

EC2 - Target groups - Create Target Group 클릭

유형 : Instances

 

Target group name : 원하는 이름 지정

Protocol : 프로토콜 HTTP / 포트 80

VPC : ELB-VPC

Protocol version : HTTP1

 

Health check protocol : HTTP

Health check path : /

 

지정 후 타겟그룹 생성

타겟그룹 생성 완료

 

[타겟 그룹 내 타겟 지정]

 

 

만들어진 타겟 그룹 클릭 후, Targets 클릭

 

ELB-EC2-1, ELB-EC2-2 인스턴스 두 개 클릭하여

타겟으로 등록

 

[ALB 생성 작업 마무리]

 

타겟 그룹 생성이 완료되었으므로,

ALB 생성 창으로 돌아와서 Default Action에 생성된 타겟 그룹을 넣어준다.

 

ALB 생성 완료

 

생성된 직후는 프로비저닝 중이지만

2~3분 뒤 active 상태로 변경된다.

 

현재까지의 상태를 아키텍처로 구성해보았다.

 

---

3. ALB(Application Load Balancer) 검증 - 로드밸런싱 동작 확인

ALB의 로드 밸런싱 동작을 확인해보고,

추가적인 경로 기반 라우팅 기능도 같이 알아보자

 

ALB의 DNS 주소 복사

 

My-EC2 인스턴스 에서

curl 명령어를 통해 HTTP 접근을 해보면

ELB-EC2-1와 ELB-EC2-2가 번갈아 가며 접속되는 것을 확인 가능

 

 

즉, ALB에서 로드 밸런싱이 되어 2대의 EC2 인스턴스로 부하 분산되고 있음

My-Ec2 → ALB ㅡ ELB-EC2-1

                               ㄴ ELB-EC2-2

ALB가 정상적으로 작동하고있다.

 

---

---

4. ALB(Application Load Balancer) 검증 - 경로 기반 라우팅 기능 확인

 

현재 HTTP 서버는 /index.html 페이지, /dev/index.html, /mgt/index.html 페이지를 가지고 있다

dev 경로 페이지는 ELB-EC2-1만 가지고 있고

mgt 경로 페이지는 ELB-EC2-2만 가지고 있다

​

만약, ALB DNS 주소로 dev 경로 페이지와 mgt 경로 페이지로 접근한다면 어떨까?

 

/dev

/mgt

당연히 한 쪽 서버에서만 응답을 하고, 한 쪽 서버에서는 응답을 하지 않는다.

이러한 현상을 해결하기 위해 '경로기반 라우팅 기능'을 이용해보자

 

* curl 명령어를 통해, HTTP 서비스를 확인할 수 있다.

---

경로기반 라우팅 기능

[1. Dev-Group 생성 → ELB-EC2-1 타겟 추가]

EC2 -> 타겟 그룹 -> 타겟 그룹 생성 클릭

유형 : Instances

​타겟 그룹 이름 : Dev-Group

프로토콜 : HTTP / 포트번호 : 80

VPC : ELB-VPC

 

타겟을 ELB-EC2-1 인스턴스로 지정

 

생성 완료

 

[2. Mgt-Group 생성 → ELB-EC2-2 타겟 추가]

 

EC2 -> 타겟 그룹 -> 타겟 그룹 생성 클릭

유형 : Instances

​타겟 그룹 이름 : Mgt-Group

프로토콜 : HTTP / 포트번호 : 80

VPC : ELB-VPC

타겟을 ELB-EC2-2 인스턴스로 지정

타겟 그룹 생성 완료

두 타겟 그룹을 확인할 수 있다.

 

[3. 리스너 규칙 편입]

로드 밸런서 - ALB-TG(만든 로드밸런서) - 리스너 클릭

생성한 리스너 선택, 편집 클릭

규칙 삽입 클릭

경로 : /dev/*

전달 대상 - 대상 그룹 : Dev-Group

규칙 삽입 클릭

경로 : /mgt/*

전달 대상 - 대상 그룹 : Mgt-Group

규칙 편집 완료

 

ALB 리스너에 2가지 규칙이 추가되었다.

 

1. /dev/ 경로로 향하는 URL 주소는 Dev-Group에 속하는 인스턴스로 전달

2. /mgt/ 경로로 향하는 URL 주소는 Mgt-Group에 속하는 인스턴스로 전달

 

[검증]

 

/dev/index.html → ELB-EC2-1로 접속

/mgt/index.html → ELB-EC2-2로 접속

 

테스트가 잘 된다.

 

/index.html → 인스턴스 1, 2 번갈아가면서 접속됨

​

참고 : 따라하며 배우는 AWS 네트워크 입문

 

 

​