AWS-Elastic Load Balancer를 통한 로드밸런서 이해하기

주수호·2021년 8월 20일

scale-out방식으로 서비스가 확장되어 진다면?

서비스의 규모가 커졋을 때에 대처하는 방법에는 크게 두가지가 있습니다.

서버의 스펙을 높인다. (scale-up)
서버를 여러대 증설하여, 동시에 여러작업을 수행 할 수 있도록 한다. (scale-out)

scale-out방식을 취하기 위해서, 여러대의 서버를 증설하였다고 가정하겠습니다. 하지만 거기서 끝이 나는게 아닙니다.

어디서 이 여러대의 서버에 분산처리를 해줄지에 대한 준비가 안되어졌습니다.

이렇게 여러대의 서버에 균등한 작업을 해줄 수 있도록 분산처리를 해주는 솔루션을

로드밸런서라고 합니다.

그렇다면 부하분산은 단순히 어플리케이션(서버)레벨에서만 필요한 개념일까요?

그렇지 않습니다. 부하분산이 필요한 곳은 어플리케이션 레벨일 수도 있고, 네트워크 레벨 일수도 있기에, 다양한 통신계층 레벨을 담당하고 있는 로드밸런서가 있습니다. 그리고 각자의 설정은 그 계층에 관계되는 옵션을 제시하여, 사용자가 컨트롤 할 수 있도록 도와줍니다.

로드밸런서는

ELB

컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미합니다.
가용성 및 응답시간을 최적화 시킬 수 있는 방식입니다.

OSI 7계층

이 모델은 프로토콜을 기능별로 나눈 것을 말합니다.
각 계층은 하위 계층의 기능만을 이용하고, 하위 계층은 상위 계층에게 기능을 제공합니다.
일반적으로 하위 계층들은 하드웨어로, 상위 계층들은 소프트웨어로 구현됩니다.

AWS-ELB

ELB

AWS에서 제공하는 로드밸런서 솔루션
Elastic Load Balancer는 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산처리하도록 합니다.
등록된 대상의 상태를 모니터링하면서 상태가 양호한 대상으로만 트래픽을 라우팅합니다.
Elastic Load Balancer는 수신 트래픽이 시간이 지나고 변경됨에 따라 로드 밸런서를 확장한다. 대다수의 워크로드에 맞게 자동으로 조정할 수 있다.

ELB는 통해 단순 부하 분산을 넘어 HTTP Header를 조작하여 전달 대상을 정하거나 고정 페이지를 반환하며, Amazon Certificate Manager(ACM)의 SSL 인증서를 탑재하여 EC2의 부하를 줄이고, WAF를 앞에 내세워 보안 기능을 강화하거나, Cloudfront (AWS의 CDN 솔루션)를 연결하여 반응 속도를 향상하여 다양한 기능을 활용하는 것이 가능합니다.
사용자가 정한 일정 시간 내 일정 조건을 충족하면 EC2를 추가하거나 삭제하여 필요한만큼의 서버를 유지하며 비용을 최적화할 수 있습니다.
ELB는 이 AutoScaling과 연동하여 추가된 EC2를 자동으로 ELB의 부하분산 대상에 포함시키거나 제외가 가능합니다.

ELB에서 지원하는 계층

다양한 계층에 대한 로드밸런서 솔루션들이 존재하지만, 대표적으로 4계층과 7계층에 대한 로드밸런서를 제공합니다.

4계층 - 전송 계층

전송 계층(Transport layer)은 계층 구조의 네트워크 구성요소와 프로토콜 내에서 송신자와 수신자를 연결하는 통신 서비스를 제공한다.
TCP/IP 참조 모델과 일반적인 네트워크 모델인 개방형 시스템 간 상호 접속 (Open Systems Interconnection, OSI) 모두 포함하고 있다.

7계층 – 응용 계층

사용자에게 가장 가까운 계층
클라이언트(실유저)와 어플리케이션 간의 연결고리 계층이다
이메일, 웹, 파일, SSH등이 대표적이다
여러 하위 통신 프로토콜 개체에 대하여 사용 관점의 사용자 인터페이스를 제공

AWS-ELB의 OSI LAYER 7계층 로드밸런서 - ALB (Application Load Balancer)

HTTP, HTTPS의 특성을 주로 다루는 로드밸런서.

다시 말해 단순 부하분산뿐만 아니라 HTTP의 헤더 정보를 이용해 부하분산을 실시하는 것이 ALB의 가장 중요한 특징입니다. HTTP 헤더의 값들을 보고 이 요청은 어느 대상그룹으로 보낼지 저 요청은 어느 대상그룹으로 보낼지를 판단할 수 있습니다.

또한 SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암호화/복호화를 대신 진행할 수 있습니다. (ELB를 사용하는 두번째 이유이기도 하다.)

Application Load Balancer의 주요 특징

HTTP를 활용한 라우팅(부하분산)

HTTP Header
첫 번째는 'HTTP Header'(이하 헤더)로 HTTP 헤더에는 표준 헤더, 요청 헤더, 응답 헤더, 일반 헤더가 존재합니다. 요청 상황, 응답 상황에 따라 다른 헤더를 가지며 그 헤더에는 다양한 정보가 들어있습니다. 그리고 사용자는 헤더에 자신의 정보를 담아 서버에 전송할 수 있고 서버는 헤더에 담긴 정보를 보고 사용자의 요구 사항을 알 수 있습니다.

요청 메서드
두 번째는 HTTP 요청 메서드입니다. 요청 메서드는 사용자가 웹서버에게 자신의 요청 목적 혹은 요청 종류를 알리는 수단으로 GET, HEAD, POST, PUT 등이 있습니다. ALB는 이 요청 메서드를 기준으로 규칙을 생성하여 각 규칙에 맞는 적절한 대상그룹으로 라우팅을 실시할 수 있습니다.

요청 경로
그 밖의 라우팅 규칙으로 요청 경로에 따라 다른 대상 그룹으로 라우팅을 실시하는 '경로', 사용자의 IP에 따라 다른 대상그룹으로 라우팅을 실시하는 '소스 IP', 쿼리 문자열의 Parameter를 기준으로 라우팅을 실시하는 '쿼리 문자열'이 있습니다.

ALB 로드밸런싱(부하 분산) 설정

Round Robin
EC2 인스턴스에 순서대로 할당합니다. 그럼 요청이 고르게 분산되겠죠. 하지만 매번 그렇지는 않습니다. 일부의 EC2 인스턴스에 할당된 요청의 작업이 오래 걸려 아직 끝마치지 못한 상태에서 지속적으로 요청이 유입된다면 균형이 깨질 가능성이 있습니다.

Least Outstanding Requests
처리되지 않은 요청을 가장 적게 가지고 있는 EC2 인스턴스에게 할당하는 방식입니다. 즉 요청을 처리할 여유가 가장 많은 EC2 인스턴스 혹은 처리 능력이 비교적 더 우수한 EC2 인스턴스에게 전달하는 방식입니다.

암호화 통신을 해야하는 경우
EC2 인스턴스의 부담을 줄이기 위해 ALB가 대신하여 SSL 인증서를 이용해 암호화 통신을 실시합니다. 물론 이를 실현하기 위해서는 사전작업으로 Route 53를 통해 자신이 사용할 도메인을 발급받는 일과 AWS의 SSL 인증서 발급 서비스인 ACM(AWS Certificate Manager)를 통해 SSL 인증서를 발급받는 일이 필요합니다.

AWS-ELB의 OSI LAYER 4계층 로그밸런서 - NLB(Network Load Balancer)

연결(OSI) 모델의 네 번째 계층에서 작동합니다. 초당 수백만 개의 요청을 처리할 수 있습니다.

Load Balancer 중 성능적으로 최적의 로드밸런싱을 지원합니다.

TCP, UDP 등의 서버를 구축할 때 해당 프로토콜들에 대해 굉장히 낮은 지연 시간으로 최적의 성능을 보여줍니다.

NLB를 사용 할 때의 이점

TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시합니다. 예를 들어 HTTP도 TCP 기반의 프로토콜이기 때문에 ALB를 사용하지 않고 NLB를 사용한다면 이를 받아들여 부하 분산을 실시합니다. 다만 상위 Layer인 HTTP가 아닌 하위 Layer의 TCP Layer에서의 처리이므로 HTTP 헤더를 해석하지 못합니다.

NLB는 Layer 4 너머의 프로토콜을 이해할 필요 없이 TCP와 UDP만을 이해만 되기에 ALB보다 시스템 리소스 소모가 적을 수밖에 없습니다.

연결 수준에서 작동하는 Network Load Balancer는 안전하게 초당 수백만 개의 요청을 처리하면서도 극히 낮은 지연 시간을 유지할 수 있습니다.

Network Load Balancer의 주요 특징

TCP/UDP 기반 라우팅

로드밸런싱 방식

부하분산을 실시함과 동시에 사용자와 EC2 인스턴스의 커넥션을 생성하도록 돕고 자신 또한 커넥션을 가지며 관리합니다.

TCP, UDP, TCP_UDP, TLS가 있습니다.

TCP의 경우
사용자와 EC2 인스턴스가 커넥션을 생성하기 위해서 3-way handshake(SYN, SYN/ACK, ACK)를 반드시 실시해야 합니다. NLB는 TCP를 이해하고 있기에 사용자와 EC2의 3-way handshake가 제대로 진행되고 있는지를 확인합니다. 3-way handshake가 정상적으로 진행되었다면 사용자와 EC2 인스턴스 모두 커넥션을 갖게 되고 NLB 또한 커넥션을 생성하여 관리합니다. 또한 커넥션을 보유한 기존 사용자가 아니거나 새로운 요청이 아닌 뜬금없는 Request Packet이 날아올 경우, NLB는 Reset Packet을 날려 이를 거부합니다.

UDP의 경우
위에서 언급한 것처럼 데이터의 전송/상태 등을 확인하지 않고 요청이 있으면 즉시 전달하는 프로토콜이기에 별다른 협상 과정을 거치지 않습니다. 다만 아무리 사용자와 EC2 인스턴스간 별도의 커넥션이 필요 없다고 하더라도 NLB는 Source IP(사용자)와 Destination IP(EC2 인스턴스)를 관리합니다. (별도의 테이블이 있는 것으로 예상)

TCP_UDP의 경우
TCP와 UDP 모두를 사용하는 프로토콜을 부하 분산할 때 주로 사용합니다. 대표적인 예가 DNS입니다. UDP 기반 프로토콜인 DNS는 패킷의 크기가 512bit가 넘어가면 TCP를 사용합니다. 그러니 리스너를 구성할 때 TCP_UDP로 해야 NLB를 통한 원활한 통신이 가능해집니다. DNS가 아니어도 TCP와 UDP 모두를 사용해야 한다면 프로토콜을 TCP_UDP로 지정해야 하지요.

SSL 인증서 탑재 가능(TLS)

TLS란?
TLS는 클라이언트/서버 응용 프로그램이 네트워크로 통신을 하는 과정에서 도청, 간섭, 위조를 방지하기 위해서 설계되었다. 그리고 암호화를 해서 최종단의 인증, 통신 기밀성을 유지시켜줍니다.

NLB 또한 ALB처럼 SSL Offload를 실시할 수 있습니다. EC2 인스턴스를 대신하여 SSL Handshake를 실시하여 암호화 통신 협상을 완료하고 암호화 패킷을 주고 받으며, EC2와의 통신에서는 평문을 주고 받습니다. 이를 통해 EC2 인스턴스의 부담을 줄여줍니다.