정리 블로그

1. ELB 종류

 지난 블로그에도 적었던 것 처럼 Elastic Load Balancer는 3가지 종류가 있음.

ALB(Application Load Balancer), NLB(Network Load Balancer), CLB(Classic Load Balancer).

각각의 LB는 사용 용도에 따라 선택이 필요하며, 오늘 작성할 내용은 CLB(단순 LoadBalancing 역할)를 작성

2. CLB 생성하기

STEP 1.

- 첫 단계에서는 LB의 이름과 사용 포트를 정함.

CLB는 단순한 포트 포워딩만 가능. 위 캡쳐에서는 LB에 HTTP 80으로 들어온 통신을 LB에 연결된 EC2 80포트로 연결해주는 것을 나타냄.

- 내부에서만 사용하는 시스템에 적용하려면 'Internal Load Balancer'를 클릭 후 생성하면 외부에서 해당 LB를 통해 접속이 불가.(사실 여기서 Internal Load Balancer를 클릭하지 않더라도, LB의 Subnet을 Private으로 하면 외부에서 접속할 수 없음. 외부에서 nslookup 입력 시, 쿼리 확인 불가)

- Available Subnets는 LB가 위치할 Subnet을 추가.(AWS 권장은 LB를 Public에 두고, LB의 뒷 단(EC2)를 Private에 위치시켜 사용하는 방식. 즉, EC2는 외부에서 접속 불가하지만 LB를 통해 접속 가능

STEP 2, 3는 생략.(Security Group 설정)

STEP 4.

- LB는 기본적으로 Health Check를 통해 Healthy인 인스턴스로만 로드밸런싱 함.

- Healthy Check는 루트 경로의 파일의 ping port를 통해 진행되는데, 위와 같이 Ping Path에 해당 파일이 위치하고 있어야 한다. html을 사용하면 문제 없지만, 사용하지 않는 경우에는 'index.html'과 같이 비어있는 html 파일을 넣어둬도 체크가 가능하다.(단, 서비스에 이상이 생겼을 때, Healthy 상태를 유지한다는 단점이 있음.)

위 화면을 보면 조금 더 잘 보임. hello.html은 80포트를 이용하며, 30초 간격으로 Health Check. Timeout은 5초, 2번 체크가 되지 않으면 Unhealthy 상태로 변경되어, 해당 인스턴스는 밸런싱 되지 않음.

STEP 5.

- LB에 Attach 할 인스턴스를 지정하는 화면

- 하단에 Enable Cross-Zone Load Balancing은 해당 LB에 서로 다른 가용영역의 인스턴스를 넣을 수 있게 해줌. 위 화면에서는 둘 다 ap-northeast-2a를 사용했지만(보이지는 않음), ap-northeast-2c 등 다른 가용영역을 함께 사용할 수 있음

- 'Enable Connection Draining' 옵션은 LB에서 특정 인스턴스를 제거할 때, 해당 인스턴스에 신규 접속자는 차단하면서 기존에 인스턴스에 연결되어 서비스를 이용하는 사용자가 설정 시간동안 사용할 수 있도록 함.(위는 300초)

3. 포트 포워딩

* 예제에서 구성한 인스턴스는 80포트를 사용하는 중임.

- 'ELB주소:8080'을 입력하는 것과 'ELB주소:80'을 입력하는 것이 같은 페이지를 출력함.

- '여러 서비스를 사용할 때 쓸수 있나?'라는 생각을 가졌지만, 기본적으로 Health Check에서 80 포트를 체크하기 때문에 한 가지 서비스에 여러가지 포트를 사용할 때만 가능한 것 같다는 생각.(나중에 아닌 경우가 생각나면 수정해라)

4. AutoScaling과 연계

- LB를 설정하고 AutoScaling을 설정하여, 특정 임계치(CPU, Memory, Request Count 등의 지표)에 도달하면 새로운 인스턴스를 생성하여 LB에 Attach를 할 수 있다. 이 부분은 추후 작성예정이지만, 필요한 경우 구글링하면 금방 할 수 있을 것.

- AWS의 ELB는 3개의 세부 항목으로 나뉘어져있으며, 인입되는 트래픽을 EC2, 컨테이너, IP 주소, Lambda 함수와 같은 대상으로 트래픽을 분산시키는 역할을 함. 애플리케이션의 고가용성, 자동 확장/축소, 보안 기능을 함.

- Health Check를 통해 LB 하단의 상태를 체크(EC2 등)

ALB(Application Load Balancer) / NLB(Network Load Balancer) / CLB(Classic Load Balancer)

- Application Load Balancer

  - 프로토콜 HTTP 및 HTTPS 트래픽의 로드 밸런싱에 가장 적합.

  - 마이크로서비스와 컨테이너 등 애플리케이션 아키텍처 전달을 위한 고급 요청 라우팅 기능 제공

     (인입된 트래픽을 PATH에 기반으로 처리)

  - 7계층(어플리케이션 단)에서 작동하며, VPC 내의 대상으로 트래픽을 라우팅

  - 1개의 EC2에서도 여러개의 포트(80, 8080)로 로드밸런싱 가능

  - URL Path 기반, Host 기반, Redirection, HTTP 헤더 기반, 쿼리 문자열 파라미터 기반, 소스 IP주소 CIDR 기반 라우팅을 지원 (Redirection의 경우, 하나의 URL에서 수신되는 요청을 다른 URL로 리디렉션 가능.)

  - Lambda 함수를 대상으로 사용 가능(Lambda 함수를 사용하여 EC2, 컨테이너, 온프레미스 서버 등으로 확장 가능)

- Network Load Balancer

  - 프로토콜 TCP, UDP 및 TLS(Transport Layer Security, 전송 보안 계증) 트래픽의 로드 밸런싱에 가장 적합.

  - 4계층(Transport 단)에서 작동하며, VPC 내의 대상으로 트래픽을 라우팅.

  - 초당 수백만 개의 요청을 처리하며 지연 시간을 매우 낮게 유지

  - 갑작스러운 일시적 트래픽 패턴 처리 최적화

  - 1개의 EC2에서도 여러개의 포트(80, 8080)로 로드밸런싱 가능

  - EC2 인스턴스, 마이크로 서비스 및 ECS로 라우팅 가능.

  - ALB, CLB의 IP는 한번 씩 변경되는 것에 반하여, NLB는 IP 변경이 없음.

- Classic Load Balancer

  - EC2 인스턴스에 기본적인 로드 밸런싱을 제공

  - 기본 로드밸런서라고 생각하면 됨.

** 내용을 정리하고 보니, CLB의 특징이 제일 적어 다른 장점이 많은 LB를 사용할 것이라는 생각을 하실 수도 있겠습니다만, 실제로 사용하다보면 저는 특수한 케이스가 아닌 이상 제일 설정이 간편하다는 이유로 CLB를 많이 사용하고 있습니다 :) AWS에서 제공하는 ELB 개념을 정리해보고자 작성하였으며, 추후 AZURE의 LB에 대해서도 정리를 진행하여 두 개의 서비스를 비교해보면 유익할 것 같습니다.