메뉴

문서정보

목차

이 문서는 AWS ELB 의 소개 문서다. 활용 정보는 담고 있지 않다.

Elastic Load balancing는 무엇인가 ?

Elastic Load balancing는 여러개의 가용영역(Availability)에 존재하는 아마존 EC2 인스턴스, 컨테이너와 IP 주소와 같은 목적지로 네트워크 트래픽을 분산해서 전달하는 일을 한다. Elastic Load balancing는 애플리케이션으로 향하는 트래픽을 골고루 분산히키며, 트래픽이 애플리케이션의 처리 용량을 초과할 경우 자동으로 스케일아웃할 수 있다.

로드밸런스의 이점

로드 밸런서는 가상 서버와 같은 여러 개의 컴퓨터 자원으로 워크로드를 분산한다. 로드밸런서를 이용해서 애플리케이션의 가용성(availability)와 내결함성(Fault tolerance)를 높일 수 있다.

사용자는 필요에 따라서 로드 밸런서가 관리하는 컴퓨터 리소스를 "애플리케이션의 중단과 같은 방해 없이" 추가하거나 제거 할 수 있다.

사용자는 헬스 체크(health check)기능을 이용해서 컴퓨터 리소스에 대한 모니터링을 수행 할 수 있다. 만약 컴퓨터 리소스에 문제가 생기면, 로드밸런서는 해당 리소스에 요청을 전송하지 않는다. 또한 로드밸런서는 인터넷 트래픽에 대한 암호화/복호화를 수행한다. SSL offloading 이라는 기능을 로드밸런서에 맡김으로서 애플리케이션 본연의 작업에만 집중하게 할 수 있다.

Elastic Load Balancing의 기능

Elastic Load Balancing는 Application Load Balancer, Network Load Balancer, Class Load Balancers, 3가지 타입의 로드밸런서를 제공한다. 사용자는 애플리케이션 요구사항에 맞춰서 로드밸런서를 선택 할 수 있다.

기능 Application Load Balancer Network Load Balancer Classic Load Balancer
Protocol HTTP, HTTPS TCP, UDP, TLs TCP, SSL/TLS, HTTP, HTTPS
Platform VPC VPC EC2-Classic, VPC
Health checks
CloudWatch metircs
Logging
Zonal fail-over
Connection Draining
같은 인스턴스의 여러 포트로 로드밸런싱
IP 주소를 타겟으로 사용 ✔ (TCP, TLS)
Load balancer deletion protection
configuration idle connection timeout
Cross-zone load balancing
Stick sessions
Static IP
Preserve Source IP address
Resource-based IAM Permissions
Tag-based IAM permissions
Slow start
WebSocket
PrivateLink Support ✔(TCP, TLS)
Source IP address CIDR-base routing
Layer 7
기능 Application Load Balancer Network Load Balancer Classic Load Balancer
Path-Based Routing
Host-Based Routing
Native HTTP/2
Redirects
Fixed response
Lambda functions as targets
HTTP header-based routing
HTTP method-based routing
Query string parameter-based routing
Security
기능 Application Load Balancer Network Load Balancer Classic Load Balancer
SSL offloading
Server Name Indication(SNI)
Back-end server encryption
User authentication
Custom Security Policy
각 로드 밸런서에 대한 자세한 사용방법은 아래 문서를 참고하자.
  1. What Is an Application Load Balancer
  2. What Is an Network Load Balancer
  3. What Is a Classic Load Balancer

Access Elastic Load Balancing

사용자는 아래의 방법들을 이용해서 로드밸런스의 생성, 접근, 관리, 삭제 등의 작업을 수행 할 수 있다.

관련 서비스

Elastic Load Balancing은 아래의 서비스와 함께 작동하면서 가용성과 확장성을 향상시킨다.

Elastic Load Balancing 의 작동원리

로드밸런스는 클라이언트로 부터 입력되는 트래픽을 받아서 하나 이상의 가용 영역(Availability Zones)에 등록된 타켓(EC2 인스턴스 혹은 컨테이너)으로 라우팅한다. 로드밸런서는 타겟에 등록된 자원들의 상태를 모니터링해서 정상적으로 작동하는 타겟에만 트래픽을 라우팅한다. 로드밸런서가 문제가 되는 타켓 자원을 감지하면 해당 타켓으로의 라우팅을 중지시킨다. 타겟이 다시 정상작동한다면, 라우팅을 수행한다.

사용자는 하나 이상의 리스너를 지정해서 입력 트래픽을 허용하도록 로드밸런서를 구성한다. 리스너는 연결 요청을 확인하는 프로세스다. 리스너는 클라이언트와 로드밸런서를 연결하기 위한 프로토콜과 포트번호로 구성된다. 또한 클라이언트 연결을 타겟으로 라우팅하기 위한 타겟의 프로토콜과 포트번호도 구성된다. Elastic Load Balancing는 아래 세 가지 유형의 로드 밸런서를 지원한다.

가용 영역과 로드밸런서 노드들

Elastic Load Balancing에 대해서 가용영역(Availability Zone)을 활성화하면, 가용영역에 걸쳐서 로드밸런서를 만들 수 있다. 가용영역을 사용하려면 가용영역을 활성화 해야 한다. 당연하지만 가능하면 여러 가용 영역을 활성화 하는 것이 좋다.(Application Load Balancer는 반드시 여러 가용 영역을 활성화해야만 한다.) 이런 구성은 단일 장애점(single point of failure)를 제거함으로써 로드 밸런서가 가능한 중지 없이 작동하게 할 수 있다. 예를 들어 한 가용 영역이 사용 할 수 없는 경우에도 다른 가용 영역의 로드밸런서가 대신해서 라우팅을 할 수 있다.

크로스 존 로드 밸런싱

로드 밸런서는 클라이언트의 요청을 등록된 대상(Target)으로 분배한다. 크로스 존 로드 밸런싱(Cross-zone load balancing)를 활성화 하면, 로드 밸런서는 활성화된 모든 가용영역의 등록된 타겟으로 트래픽을 분산시킨다. Application load balancing는 크로스 존 로드 밸런싱이 할상 활성화 된다.

아래 그림을 보자. 각 가용 영역에 노드의 개수가 다르다. 크로스 존 로드 밸런싱이 활성화되면 10개의 타겟이 10% 씩 트래픽이 분산된다.

 크로스 존 로드 밸런싱

크로스 존 로드 밸런싱이 비활성화된다면 아래와 같은 일이 발생한다. 왜냐하면 가용 영역 A와 B로 50%씩의 트래픽이 흐르기 때문이다.

 크로스 존 로드 밸랜싱 disable

Network Load Balancer은 크로스 존 로드 밸런싱이 기본적으로 비활성화 된다. Network Load Balancer은 생성한 후 언제든지 크로스 존 로드 밸런싱을 활성화 할 수 있다.

Classic Load Balancer는 로드 밸런서를 만드는 방법에 따라서 크로스 존 로드 밸런싱의 설정이 달라진다. API와 CLI를 이용하면 크로스 존 로드 밸런싱이 기본적으로 비활성화 된다. AWS Management Console의 경우 크로스 존 로드 밸런싱을 활성화 하는 옵션이 있다. 일단 생성한 후에는 언제든지 크로스 존 로드 밸런싱을 활성화 할 수 있으니, 약간만 주의하면 사용하는데 큰 문제는 없다. 크로스 존 로드 밸런싱을 꺼야 하는 경우는 없을 것이다. 굳이 찾는다면 Weight를 다르게 하고 싶은 경우인데, 이런 필요가 있을지는 모르겠다.

라우팅 요청

클라이언트는 DNS(Domain Name System)을 이용해서 로드밸런서를 확인한다. 로드 밸런서는 Amazon에서 제어하는 amazonaws.com 도메인을 사용한다. Amazon DNS 서버는 하나 이상의 IP 주소를 클라이언트로 반환하고 클라이언트는 이 주소로 접근을 한다.

Network Load Balancer의 경우, 각 가용 영역에 로드밸런서 노드가 만들어진다. 가용 영역의 각 로드 밸런서 노드는 이 네트워크 인터페이스를 이용해서 고정 IP 주소를 만들 수 있다. 사용자는 EIP(Elastic IP)주소를 각 네트워크 인터페이스에 연결 할 수 도 있다. 때때로 네트워크 보안 정책 때문에 고정 IP를 요구하는 경우에 사용 할 수 있다.

애플리케이션에 대한 트래픽이 늘어나면 Elastic Load Balancing는 로드밸런서를 자동으로 확장하고 DNS 항목을 업데이트 한다. DNS는 TTL을 60초 지정하는데, 이를 통해서 트래픽의 갑작스러운 변화에 신속하게 대응 할 수 있다.

라우팅 알고리즘

Application Load Balancer는 아래의 프로세스를 이용해서 라우팅을 결정한다.
  1. 리스너(listener)의 룰을 우선해서 평가한다.
  2. 라우든로빈 알고리즘을 이용해서 타겟 그룹에서 타겟(노드)를 선택한다.
Network Load Balancer은 아래의 프로세스를 사용한다.
  1. 흐름 해시 알고리즘(flow hash algorithm)을 이용해서 타겟 그룹에서 타겟을 선택한다. 이 알고리즘은 아래의 데이터를 기반으로 한다.
    • 프로토콜
    • Source(출발지) IP address와 Source port
    • Destination(목적지) IP adress와 Destination port
    • TCP sequence number
  2. TCP 연결이 지속되는 동안에는 단일 대상으로 라우팅한다.
클라이언트는 하나 이상의 TCP 연결을 만들 수 있다. 이들은 서로 다른 소스포트와 sequence number를 가지기 때문에 서로 다른 타겟으로 라우팅 될 수 있다.

Classic Load Balancer를 아래의 방법으로 라우팅한다.

HTTP Connections

Classic Load Balancer는 pre-open connections를 허용한다. 하지만 Application Load Balancer는 허용하지 않는다. 사전 개방 연결(Pre-open connections)는 클라이언트가 LB에 연결하기전에 Classic load balancer가 타겟 노드와 미리 TCP 연결을 맺어 놓는 것을 의미한다. 클라이언트 요청이 들어오면 이 TCP 세션을 사용하기 때문에, 요청 처리시간을 줄일 수 있다.

Classic Load Balancer과 Application Load Balancer는 모두 Multiplex connection을 이용해서 다수의 클라이언트의 요청을 단일 백엔드 연결을 통해서 지정된 대상으로 라우팅 할 수 있다.

Application Load Balancer는 HTTP/0.9, HTTP/1.0, HTTP/1.1 및 HTTP/2 프로토콜을 지원한다. HTTPS 리스너에서만 HTTP/2를 사용 할 수 있으며 하나의 HTTP/2 연결을 사용하여 최대 128개의 요청을 병렬로 보낼 수 있다. Application Load Balancer는 HTTP에서의 WebSocket으로의 업그레이드도 지원한다.

Application Load Balancer과 Class Load Balancer는 백앤드 연결로 HTTP/1.1을 사용한다. 연결유지(Keep-alive)는 기본적으로 지원한다. 호스트(Host) 헤더가 없는 클라이언트의 HTTP/1.0 요청의 경우 로드밸런서는 백앤드에 연결된 HTTP/1.1 요청에 대한 호스트 헤더를 생성한다. Application Load Balancer의 경우 호스트 헤더에는 로드밸런서의 DNS이름이 포함된다. Class Load Balancer의 경우 호스트 헤더에 로드 밸런서의 IP 주소가 포함된다.

Application Load Balancer과 Classic Load Balancer는 모두 idle timeout을 설정할 수 있다. 기본 값은 60초다. Application Load Balancer의 경우 프론트 엔드 연결에만 적용된다. Classic Load Balancer의 경우 연결이 휴유 시간 초과를 초과할 경우 연결이 끊기고 클라이언트는 오류 응답을 받는다.

Application Load Balancer 및 Classic Load Balancer는 프런트 연결에 대해서 pipelined HTTP를 지원한다. 백앤드 연결에 대해서는 pipelined HTTP를 지원하지 않는다.

HTTP Headers

Application Load Balancer과 Classic Load Balancer는 X-Forwarded-For, X-Forwarded-Proto 및 X-Forwarded-Port 헤더를 지원한다. HTTP/2를 사용하는 프런트 엔드 연결의 경우 헤더 이름은 소문자이다.

HTTP Header Limits

Application Load Balancers는 아래와 같은 헤더크기 제한이 있다.

HTTP/1.x 헤더 HTTP/2 헤더

Load Balancer Scheme

로드 밸런서는 internal load balancerinternet-facing load balancer 2개 타입이 있다. EC2 Classic 타입에 대한 Classic Load Balancer는 항상 internet-facing load balancer 이어야 한다.

Internet-facing load balancer는 인터넷에 노출되는 로드밸런서로 퍼블릭 IP 주소가 부여된다. 로드밸런서의 DNS 이름을 룩업해서 로드밸런서 노드의 퍼블릭 IP 주소를 확인 할 수 있다. 따라서 internet load balancer는 인터넷에서 전송되는 요청을 라우팅 할 수 있다.

Internal load balancer는 private IP 주소만 있다. Internal load balancer에 대한 DNS 룩업을 하면 private IP 주소가 리턴된다. 따라서 Internal load balancer는 VPC 내부에서만 사용 할 수 있다.

Internet-facing Load balancer과 interlan Load balancer 모두 private IP를 이용해서 라우팅한다. 따라서 타겟은 내부 또는 외부의 요청을 수신하기 위한 퍼블릭(public) IP가 필요하지 않다.

만약 애플리케이션이 멀티 티어 구성을하고 있다면, 인터넷과 내부 모두에서 로드밸런서를 사용하는 아키텍처를 설계 할 수 있다. 예를 들어 클라이언트 프로그램은 Internet-facing Load balancer를 이용해서 웹 서버에 연결하고, 웹 서버는 internal load balancer를 이용해서 API 서버 혹은 데이터베이스등에 연결 할 수 있다.

Elastic Load Balancing 다루기

Amazon은 Application Load Balancers, Network Load Balancers, Classic Load Balancers 세 가지 타입의 로드밸런서를 제공한다. 사용자는 애플리케이션 요구사항에 따라서 적당한 로드밸런서를 선택할 수 있다. 로드 밸런서 타입에 대한 자세한 설명은 Elastic Load Balancing 기능문서를 참고하자.

로드 밸런서에 대한 설정은 Elastic Load Balancing Demos를 참고하자.

만약 Classic Load Balancer를 사용하고 있다면 Application Load Balancer 이나 Network Load Balancer로의 마이그레이션을 고려해 볼 수 있다.

Application Load Balancer 생성

Application Load Balancer은 AWS 관리 콘솔(Management Console)로 만들 수 있다. 자세한 내용은 Getting Started with Application Load Balancers문서를 참고하자.

Application Load Balancer는 AWS CLI로 만들 수도 있다. 자세한 내용은 Create an Application Load Balancer Using the AWS CLI문서를 참고하자.

Network Load Balancer 생성

Network Load Balancer는 AWS 관리 콘솔로 만들 수 있다. 자세한 내용은 Getting Started with Network Load Balancers문서를 참고하자.

Network Load Balancer는 AWS CLI로도 만들 수 있다. 자세한 내용은 Create a Network Load Balancer Using the AWS CLI문서를 참고하자.

Classic Load Balancer 생성

Classic Load Balancer는 AWS 관리 콘솔로 만들 수 있다. 자세한 내용은 Create a Classic Load Balancer문서를 참고하자.

로드밸런서에서의 인증(Authentication)과 접근제어(Access Control)

AWS는 보안 자격 증명(Security credentials)을 사용해서 사용자를 식별하고 AWS 리소스에 대한 접근권한을 부여한다. 그리고 AWS IAM(Identity and Access Management)를 이용해서 다른 사용자와 서비스, 애플리케이션의 접근을 허용 할 수 있다.

기본적으로 IAM 사용자는 AWS 리소스의 생성, 확인, 수정의 권한이 없다. IAM 유저가 로드 밸런서와 같은 리소스에 접근하고 작업을 수행하도록 하기 위해서는 아래의 작업을 수행해야 한다.
  1. IAM 유저가 특정 리소스와 API작업을 할 수 있는 IAM 정책을 만든다.
  2. IAM 유저자 혹은 IAM 유저가 포함된 그룹에 IAM 정책을 Attach 한다.
IAM 유저는 개인 이나 시스템 혹은 애플리케이션이 될 수 있다.

IAM 정책을 이용해서 권한 부여

IAM 정책을 만들어서 유저 혹은 그룹에 attach 하는 것으로 특정 리소스에 원하는 작업을 할 수 있는 권한을 부여하거나 거부 할 수 있다. IAM 정책은 아래와 같은 JSON으로 정의한다.
{
	"Version": "2012-10-17",
	"Statement":[{
		"Effect": "effect",
		"Action": "action",
		"Resource": "resource-arn",
		"Condition": {
			"condition": {
				"key":"value"
			}
		}
	}]
}
IAM에 대한 자세한 내용은 IAM User Guide를 참고하자.

Application Load Balancer

OSI 모델에 따르면 로드밸런서는 Layer 4(전송 계층)과 Layer 7(애플리케이션 계층) 두 가지 타입이 있다. 전송계층의 대표적인 프로토콜들들로 TCP, UDP, RDP, SPX, SCTP있다. L4 로드밸런서는 TCP와 UDP를 주로 로드밸런싱 한다. 애플리케이션 계층은 FTP, HTTP, DNS, HTTPS, NTP, POP와 같은 인터넷 애플리케이션들이 사용하는 프로토콜들을 다룬다. 즉 L7 로드밸런서라 하면, HTTP와 HTTPS의 (헤더와 본문)내용을 읽어서 로드밸런싱 할 수 있는 기능을 가졌음을 의미한다. 대표적인 기능들은 Host 기반 라우팅, URL 경로 기반 라우팅, HTTP 요청 메서드, 출발지 IP, 쿼리 문자열, HTTP 헤더등 다양한 방식으로 라우팅을 수행 할 수 있다. 이러한 라우팅 기능은 REST 기반의 MSA 애플리케이션을 개발하는데 큰 도움을 준다.

Application Load Balancer를 이용하면 아래와 같은 구성이 가능하다.

 ALB 응용

경로기반 라우팅 기능을 이용해서 아래와 같이 이미지를 처리하는 웹 애플리케이션을 개발한다.
  1. POST /wiki/image 는 이미지를 업로드하는 API다. POST /wiki/image 경로로의 요청은 Image Target Group으로 라우팅한다.
  2. POST,GET /wiki/doc 는 웹 페이지를 서비스한다. POST,GET /wiki/doc 경로로의 요청은 App Target Group으로 라우팅한다.
Image Target Group과 App Target Group에 최적화된 인스턴스를 배치하는 식으로 서비스의 품질과 비용을 관리 할 수 있다.

Application Load Balancer과 Lambda

2018년 11월 Application Load Balancer 에서도 람다(Lambda) 함수를 호출해서 HTTP(S)를 호출할 수 있게 됐다. 이제 개발자는 Serverless(서버가 없는) 애플리케이션을 만들 수 있게 됐다.

Network Load Balancer

NLB는 Layer 4에서 작동하는 로드밸런서다. 로드 밸런서로드는 고정된(Static) Public IP, 즉 EIP 를 가질 수 있다. 어떤 인터넷 서비스들은 보안을 위해서 목적지 IP를 제한하기도 하는데, 이러한 경우 유용하게 사용 할 수 있다.

모든 애플리케이션은 추상화 단계가 높아질 수록 성능이 떨어지는 문제가 있다. NLB는 Layer 4에서 작동하기 때문에, Application Load Balancer 보다 훨씬 빠른 속도로 트래팩을 처리 할 수 있다. 반면 SSL 오프로딩, 호스트기반 라우팅, cross-zone 로드 밸런싱등의 기능을 사용 할 수 없기 때문에 목적에 맞게 사용하는게 중요하다.

용어 정리

Connection multiplexing

사용자가 클라이언트(웹 브라우저)로 요청을 보낼 경우, 웹 페이지의 여러 요소를 가져오기 위해서 여러 개의 요청을 웹 서버에 전송한다. 따라서 클라이언트와 서버 간에 많은 수의 연결을 만들 수 있다. 웹 서버에 대한 각 연결은 일반적으로 수명이 짧기 때문에, 연결 관리에 대한 오버헤드가 발생한다.

HTTP 1.1는 하나의 연결을 통해서 여러 요청을 처리하는 방식으로 오버헤드를 줄일 수 있다. 그러나 대량의 컨텐츠를 제공하는 인터넷 서비스 업체의 경우에는 이 것으로 부족 할 수 있다.

TCP 멀티플렉싱(TCP multiplexing)는 이미 열린 TCP 연결을 재 사용하는 기술이다. TCP 연결과 해제에는 많은 네트워크 오버헤드가 발생한다. 많은 네트워크 장비들은 서버와의 연결을 한 번 설정하고 이를 사용해서 클라이언트의 여러 요청을 처리함으로써 서버의 응답시간을 단축하고 처리 용량을 높인다.

 TCP Multiplexing

HTTP pipelining

TCP 연결과 종료는 자원을 소비하기 때문에 이러한 단순한 모델을 사용하는 것은 성능의 제약을 가져온다. HTTP/1.1도 TCP를 기반으로 하기 때문에 동일한 문제를 가진다. 이 문제를 해결하기 위해서 HTTP/1.1은 Persistent connection 과 HTTP Pipelining으 두 가지 연결 모델을 제공한다.

 HTTP Pipelining

Persitent connection은 연속적인 요청을 하나의 컨넥션으로 유지하며 새 연결을 만드는데 필요한 시간을 줄인다. HTTP pipeline은 연속적인 요청을 보내서 네트워크 지연을 더욱 줄일 수 있다.

참고