[AWS ELB]란 무엇인가

지난 글에 이어 AWS에서 제공하는 ELB에 대해서 정리해보겠다.

https://haksae.tistory.com/200

[Load Balancing]이란 무엇인가

1. Elastic Load Balancer

• ELB는 AWS의 로드밸런서 서비스로서, 주된 기능은 특정 서버에 부하가 몰리지 않도록 적절히 분산시키는 것이다.
• 주된 기능 외에도 ELB는 아래와 같은 다양한 기능을 수행한다. (L4 스위치처럼)
  • 헬스 체크(Health Check)를 통한 서버 제어
  • 고정 세션(Stickky)
  • SSL 암복호화(SSL Offload) : ACM 탑재하여 EC2 서버 부하 감소
  • WAF를 통한 보안 강화
  • CloudFront를 연결하여 반응 속도 향상
  • GSLB의 기능 활성화 등등

 

2. ELB의 구성 요소

1) Listener(리스너)

사용자의 요청을 받아들이고, 적절한 대상 그룹으로 라우팅하는 역할

• L4 스위치에서 Virtual Server 역할에 해당한다.
• 서비스 포트(Service Port)를 보유하고 있으며 외부의 요청은 서비스 포트로 접속하는 요청만을 처리한다.
  • 보통 웹 서비스의 경우 80 포트(http)를 사용한다.
• 로드밸런서에 접근한다는 것은 해당 리스너의 포트로 접근하는 것이기에 리스너는 접근을 위한 리스터 ID에 포트를 명시한다.
• 한개의 로드 밸런서에는 다수의 리스너를 보유할 수 있다.
• SSL 인증서를 게시하여 SSL Offload를 실시 할 수도 있다.

2) 대상 그룹

리스너가 전달한 요청을 처리하기 위한 부하 분산 대상들의 모임

• L4 스위치에서 Pool에 해당
• 서비스 포트(Service Port)를 보유하고 있으며 부하 분산 대상인 EC2는 해당 포트가 열려있어야함
• 대상 그룹의 포트는 꼭 리스너의 포트와 같을 필요는 없다.
  • 요청 검토한 리스너가 요청이 적합한 경우 대상 그룹에게 이를 전달할 때 대상 그룹의 포트로 Port Translation을 한다.
• 포함되어 있는 정보
  • 대상 그룹에 등록된 EC2의 각종 정보 (인스턴스, ID, Port, AZ)
  • EC2가 전달받은 요청을 처리할 수 있는지를 나타내는 헬스 체크(Health Check)
    • 부하 분산 대상인 대상 그룹 내 리소스들은 헬스체크를 활용해 끊임없이 상태를 확인 받는다.
  • 요청 처리에 관련한 모니터링 (monitoring)
    • 요청 처리에 관련된 모니터링이라 함은 이 대상 그룹에 요청 처리가 가능한 EC2가 몇 개인지, 불가능한 EC2는 몇개인지를 뜻함

3) 보안 그룹

• 로드밸런서는 보안 그룹을 가질 수 있다.
  • 보안 그룹은 네트워크 인터페이스에 적용되는 것이다.
  • EC2처럼 로드밸런서 노드 또한 네트워크 인터페이스 형태를 띄기 때문에 보안 그룹을 가질 수 있다.
  • 사용자가 전달하는 요청을 처리하기 위해서는 해당 요청의 포트를 보안 그룹에서 열어두어야한다.
• 대상 그룹의 EC2도 로브밸런서 노드가 있는 서브넷에서 오는 요청을 처리할 수 있도록 EC2의 보안 그룹 또한 작업을 해야한다.(로드밸런서 노드에 적용된 보안 그룹에서의 요청을 허용해야한다.)

4) 상태 체크(Health Check)

• 로드밸런서는 대상 그룹의 EC2의 상태를 수시로 체크하여, 인스턴스의 OS나 어플리케이션의 문제로 인해 연결 장애나 서비스 가능 여부에 대한 Health Check를 지속적으로 수행한다.
• 상태 체크에 통과하지 못한 EC2는 더이상 요청을 전달 받지 못한다.
• ELB의 상태 체크는 TCP, HTTP, HTTPS가 있으며, 트래픽이 유입되는 포트(서비스 포트)로 상태 체크를 한다. (그렇지 않은 포트로의 상태 체크도 가능하다.)
• 또한 제한 시간이나 간격, 성공 판단 횟수 등을 정의할 수도 있다.

5) 유휴 제한 시간(Connection Time Out)

• 사용자가 ELB를 거쳐 EC2에 접근하여 서비스를 접속하면 "Connection"이 생성된다. 이 커넥션을 통해 사용자와 EC2가 통신한다.
• 커넥션은 더이상의 통신이 없을 때 유휴 제한 시간이 작동되어, 사라진다.
• 즉 어느 정도의 시간동안 통신이 없을 때 커녁센을 삭제할 것인가를 설정하는 것이 유휴 제한 시간이다.

 

3. ELB의 종류

• AWS의 ELB 종류는 아래와 같이 세 종류이다.
  • CLB(Classic Load Balancer)
  • ALB(Application Load Balancer)
  • NLB(Network load Balancer)
• 3가지의 ELB는 모두 부하 분산을 하는 로드밸런서라는 점은 동일하지만, 역할의 차이가 존재한다.

1) ALB (Application Loac Balancer)

<ALB (출처: AWS 한국 블로그)>

• OSI 7 Layer의 7계층에 해당하는 Application Layer의 특성을 이용하는 로드 밸런서
• OSI 모델 7계층에서 작동하며, HTTP, HTTPS와 같은 고급 로드 밸런싱 서비스에 적합
• 마이크로 서비스 및 컨테이너 기반 어플리케이션, 최신 어플리케이션 서비스에 최적화된 로드밸런싱 제공
• 단순 부하분산 뿐 아니라 HTTP의 헤더 정보를 이용해 부하분산을 실시하는 것이 가장 큰 특징
• SSL/TLS 암호화 및 프로토콜을 사용하여 보안성을 보장한다.
  • SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암호화/복호화를 대신 진행할 수 있음

2) NLB(Network Load Balancer)

• OSI 7 Layer의 4계층에 해당하는 Transport Layer의 특성을 이용하는 로드밸런서
• OSI 모델 4계층에서 작동하며, TCP와 UDP 트래픽의 로드밸런싱 서비스에 적합
• 짧은 지연 시간과 초당 수백만 개의 요청 처리가 가능
• 가용 영역당 1개의 정적 주소를 사용하면서 트래픽의 변동이 심한 서비스에 최적화 (고정 IP를 가진다는 것)
• ALB처럼 HTTP 헤더는 해석하지 못함
  • HTTP도 TCP 기반의 프로토콜이기 때문에 NLB가 부하 분산을 실시 할 수 있음
  • 다만 상위 Layer인 HTTP가 아닌 하위 Layer의 TCP Layer에서의 처리이므로 HTTP 헤더를 해석하지 못한다.
  • 그러므로 HTTP 헤더를 이용한 부하 분산은 불가능하다.

3) CLB(Classic Load Balancer)

• OSI 모델 4계층(Transport Layer), 3계층(Network Layer)에서 작동
• EC2 - Classic 네트워크 내에 구축된 애플리케이션에 적합

 

4. ELB 작동 방식

로드밸런서 종류마다 부하 분산시 사용되는 알고리즘의 차이가 있다.

1) ALB의 작동 방식

a) Round Robin

• 부하 분산시 사용되는 기본 알고리즘은 Round Robin이다.
• 라운드 로빈은 들어오는 요청을 EC2 인스턴스 순서대로 균등하게 할당하는 방식이다.
  • 이러면 매번 고르게 배분될 것 같지만, 매번 그렇지는 않다.
  • 일부의 EC2 인스턴스에 할당된 요청의 작업이 오래 걸려 아직 마치치 못한 상태에서 지속적으로 요청이 유입된다면 균형이 깨질 가능성이 있다.

b) Least Outstanding Requests

• 위의 문제를 해결하기 위한 방식으로, Least Outstanding Requests가 있다.
• 이는 처리되지 않은 요청을 가장 적게 가지고 있는 EC2 인스턴스에 할당하는 방식이다.
• 즉 요청을 처리할 여유가 가장 많은 EC2 인스턴스 혹은 처리 능력이 비교적 더 우수한 EC2 인스턴스에게 전달하는 방식이다.

2) NLB의 작동 방식

• NLB의 로드밸런싱 방식은 트래픽이 TCP인지 UDP인지에 따라 약간의 차이가 있다.
• 기본적으로 NLB의 로드밸런싱 방식은 5-Tuple(Source IP Address, Source Port, Destination IP Address, Destination Port, Protocol)을 기반으로 한 Flow Hash Algorithm이다.
• TCP는 여기에 TCP Sequence Number까지 사용한다.
• NLB은 Flow Hash Algorithm을 사용하여 부하분산을 하되, 5-Tuple의 정보 일치/불일치가 커넥션 생성의 기준이 된다.
• 그렇기 때문에 5-Tuple의 정보 중 하나라도 다르다면 새로운 요청으로 간주되어, 새로운 커넥션을 생성하기 위해 로드밸런싱을 실시한다. (ALB의 비해 작동 방식이 모호하고 어렵다.)

 

참고 자료

https://velog.io/@hyun0820/7%EC%A3%BC%EC%B0%A8.-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%9D%B4%EB%A1%A0

https://aws-hyoh.tistory.com/135

https://aws-hyoh.tistory.com/134

https://aws-hyoh.tistory.com/128

https://aws-hyoh.tistory.com/133