Load Balancer란 단어 그대로 Load(부하)를 적절하게 분배해서 균형을 맞춰주는(Balancing) 서비스이다. 한 대의 서버에 부하가 어느 수준이상 가해지면 서버가 다운될 수 있다. 이 때 로드 밸런서가 다른 인스턴스로 부하를 적절하게 나눠줘 시스템 서버가 죽지 않도록 관리해준다.
AWS의 Elastic Load Balancer는 아래와 같은 특징이 있다.
- 트래픽 분산 : load balancer 기능
- 자동 확장 : AutoScaling이 알아서 된다
$ sudo node app.js- 인스턴스 상태를 감지하고 있다가 오류가 있는 인스턴스에는 부하를 나누지 않는다.
* 아래에 나오는 실습을 위해 다음과 같은 설정이 필요하다. - EC2 두 대 만들기. 이 때 이 둘의 subnet을 서로 다르게 설정한다.
- 각 인스턴스에 다음과 같은 설정을 한다(Ubuntu 기준) $ sudo apt update && sudo apt install -y npm => apt(advanced packaging tool) 을 깔고 업데이트한다 $ sudo npm install -g http os=> http와 os를 설치한다 $ vim app.js => app.js에 아래 내용을 작성한다, 아래 내용은 80번 포트를 열고 Hello World를 출력한다.
const http = require('http'); const hostname = '0.0.0.0'; const port = 80; var os = require("os");
var networkInterfaces = os.networkInterfaces(); var ip = networkInterfaces["eth0"][0].address; console.log(ip);
const server = http.createServer((req, res) => { res.statusCode = 200; res.setHeader('Content-Type', 'text/plain'); var _url = req.url; console.log(_url); if (_url == '/hello') res.write('Hello World !\n');
res.write(ip); res.end('\n');
});
server.listen(port, hostname, () => { console.log(`Server running at http://${hostname}:${port}/`); })
$ sudo node app.js => app.js 를 실행한다.
2. CLB (Classic LoadBalancer)란? + 실습
클래식 로드 밸런서는 이미 EC2에서 프로그램이 실행되고 있는 경우 이 들 사이에 로드 밸런싱을 하려는 경우에 사용한다.
[생성]
- EC2 의 왼쪽 바를 보면 로드밸런싱 카테고리가 있다. 여기에서 로드밸런서를 선택하고 생성하기를 한다.
- 로드밸런서 생성 페이지 가장 하단에 토글(삼각형)을 누르면 Classic Load Balancer-previous generation을 누른다.
- Create를 누른다
[정의, 보안그룹, 보안설정 구성]
- 이름은 CLB로 정하고 LoadBalaner 프로토콜은 HTTP 80번포트만 열고 넘어간다(기본으로 설정되어있다)
- 보안 그룹은 인스턴스를 만든 보안 그룹으로 설정한다. 보안 설정을 ssl 또는 https로 하라는 안내가 나오는데 ELB를 실습하는 것이므로 이 부분은 넘어간다
[상태검사 구성]
ping을 / (landing page)로 설정한다
[EC2 인스턴스 추가]
[ELB의 상태검사]
app.js를 실행하면(서버 구동) 그림과 같이 30초마다 한번씩 인스턴스의 상태를 검사한다.
[ELB 실행 확인]
ELB 접속 주소를 이용해 curl로 접속을 해보면 다음과 같이 접속 부하를 두 인스턴스에 고르게 나누는 것을 확인할 수 있다. 이 때 하나의 컴퓨터를 컴퓨터를 다운시켜보면 하나의 EC2로만 접속되 것을 확인할 수 있다.
3. NLB (Network LoadBalancer)란? + 실습
Network LoadBalancer는 TCP, UDP 트래픽을 대상으로 한다.
[NLB] 기본설정
이름은 NLB로 설정하고
기존 VPC를 선택하고 subnet 네 가지를 모두 선택한다.
[라우팅 설정]
자세한 설정을 위해 Create target group을 선택한다
EC2 Instance를 대상으로 하기 때문에 target type을 Instance로 설정한다. 이름입력하고 TCP 80 포트를 대상으로 한다.
여기에서 health check를 설정할 수 있다.
[target Instace 선택]
아직 target group setting 중이다. Next를 누르면 선택할 인스턴스 목록이 나온다. 미리 준비한 인스턴스 두 개를 선택한다. 80번 포트를 열어두었으므로 Ports for the selected instances는 80으로 그대로 둔다. Create target group을 한다.
다시 로드밸런서 설정으로 돌아와서 TG를 설정해준다.
[로드밸런싱 확인]
NLB가 생성된 것을 확인한다. DNS를 확인하고 로컬컴퓨터(자기 컴퓨터)의 실행창(bash.exe등)을 실행한다.
밸런싱하는 것을 확인하는 방법은 CLB와 동일하다.
4. ALB (ApplicationLoadBalancer)란? + 실습
[ALB]는 NLB와 설정이 거의 비슷하다. 다만 HTTP 프로토콜을 대상으로 밸런싱(부하나누기) 하기 때문에 이 프로토콜을 대상으로 하는 Target Group을 새로 만들어야한다.
로드밸런싱 작동 확인은 위 CLB와 동일하니까 생략한다.
5. 그러면 언제 무엇을 써야할까?
정말 실무에서 사용하기 위해서는 각각이 어디에 왜 사용되는 지 정확하게 알아야한다.
우선 CLB는 이전 버전 load balancer로 네트워크 레이어 4,7 둘다 지원한다. 따라서 TCP, HTTP, HTTPS, SSL을 모두 지원한다는 의미이다. 아래의 그림을 보면 layer4 가 전송계층(Transport Layer)로 TCP, UDP를 확인, 전송하는 계층이고, layer7 이 application layer라는 것을 확인할 수 있다. 위의 실습에서 NLB와 ALB를 나눠 사용했는데 이 두 가지를 모두 짬뽕해 놓은 LB라고 생각할 수 있다. 그러나 여러 계층의 전송을 모두 한 번에 다루는 것은 보안 과 자원 측면에서 모두 낭비라고 할 수 있다.
https://shlee0882.tistory.com/110
[NLB 가 밸런싱하는 내용]
Layer 4 는 IP주소와 포트번호를 보고 스위칭한다. TCP, UDP 프로토콜의 헤더를 보고 해당지점으로 패킷을 전송한다. 예를 들면 http:// 라면 TCP/80으로 https://는 TCP/443 으로 보내는 것이다. ftp 또한 이곳에서 스위칭된다. (참고로 이 level에서 RoundRobin 알고리즘을 사용해 연결된 서버에 순차적으로 접속하도록 한다.) (라운드로빈 알고리즘 설명과 PS 문제 링크)
[ALB가 밸런싱하는 내용]
ALB는 layer 7에서 작동하는 밸런싱으로 L4가 패킷의 내용을 열어보지 않고 스위칭하는 것에 비교해 HTTP/HTTPS 레벨에서 헤더를 보고 적절한 서버로 패킷을 보낸다.
따라서 내가 Balancing하는 서비스의 대상이 어떤 레이어인지 확인하고 선택하면 된다.
