어떤 LB를 사용해야 할지 결정하기 위해, 각 LB가 각각 어떻게 다르고, 어떤 기능을 하며, 사용 비용이 어느정도로 예상 되는 지 정리해보기 위해 작성된다.
1. LB란 2. AWS ELB란 3. AWS ELB - NLB란 4. AWS ELB - ALB란 5. ALB, NLB 요금 정책
Load Balancer
Load Balancer는 Load(부하) Balancing(분산) 기술을 제공해주는 장치 혹은 기술을 의미한다.
Load Balancing은 인터넷 서비스에 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버에 부하가 집중되지 않도록 하는 기술이다.
LB는 부하 분산 뿐만아니라 scale out에 대한 하나의 엔드포인트를 제공하기도 하는데, 오토스케일링 그룹을 통해 여러개의 인스턴스를 생성(scale out)하고 관리함으로 고가용성을 확보하고, 안정적인 서비스를 제공할 수 있다.
부하 분산을 위한 LB는 OSI 7 계층 중 어느 계층에서 동작하는지에 따라서
NLB(Network LoadBalancer)와ALB(Application LoadBalancer)로 나뉜다.LB에서 트래픽을 하나의 경로로 받아서 다수의 인스턴스에 분산하게 되어, 유저 입장에서는 각각의 인스턴스에 일일히 접근해서 관리하는게 아닌 하나의 주소로 접속해서 관리 할수 있게 된다. 만약 인스턴스가 오류가 나거나 종료되어 트래픽을 수신하지 못하게 되면 LB가 알아서
(health check / monitoring)트래픽을 전송하지 않고, 새로운 인스턴스가 등록되면 자동으로 분산을 시킨다.
ELB
Elastic Load Balancing(ELB)은 AWS에서 제공하는 4가지 유형의 로드 밸런서를 지원한다. 애플리케이션 요구 사항에 따라 적절한 로드 밸런서를 선택할 수 있다.
ELB의 종류는 다음과 같다.
Application Load Balancer (ALB) Network Load Balancer (NLB) Gateway Load Balancer (GWLB) Classic Load Balancer (CLB) - 2022년 8월 15일에 EC2-classic 네트워크를 종료합니다.부하분산을 하는 로드밸런서라는 점은 동일하지만 역할이 각각 다르다.
ELB는 VPC에 탑재되며, 사용자의 요청을 받고 VPC 내 리소스(EC2)에 부하 분산한다.
ELB는 외부의 요청을 받아들이는
리스너(Listener)와 요청을 분산할 리소스의 집합인대상 그룹(Target Group)으로 구성되며, ELB는 다수의리스너와대상 그룹을 거느릴 수 있다.부하 분산 대상인
대상 그룹내 리소스들은헬스 체크(Health Check)를 활용해 끊임없이 상태를 확인받게 된다.
리스너는 외부의 요청을 받아들이기 때문에서비스 포트(Service Port)를 보유하고 있으며 외부의 요청은서비스 포트로 접속하는 요청만을 처리한다.
대상 그룹또한서비스 포트를 보유하고 있으며 부하 분산 대상인 EC2는 해당 포트가 열려있어야 한다. 그리고대상 그룹의 포트는 꼭리스너와 포트가 같은 필요는 없다. 요청을 검토한리스너가 요청이 적합한 경우대상 그룹에게 이를 전달할 때 대상 그룹의 포트로'Port Translation'을 실시하기 때문이다.대상 그룹 레벨에서 사용되는 라우팅 알고리즘을 구성할 수 있다. 기본 라우팅 알고리즘은 라운드 로빈이다.
LB를 사용하면 오토스케일링 그룹을 사용할 수 있는데, 오토스케일링 그룹 자체는 혁신적인 방법이지만 별도의 로드 밸런싱, 부하를 분산해주는 서비스 없이는 활용 불가이기 때문에 그래서 나온 서비스가 Elastic Load Balancing 인 것이다.
라운드 로빈
라운드 로빈(RR; Round Robin) 또는 라운드 로빈 스케줄링(Round Robin Scheduling)은 시분할 시스템을 위해 설계된 선점형 스케줄링의 하나로서, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간 단위로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘이다.
가중 라운드 로빈(Weighted Round Robin Method)
각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분한다.
주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식이며, 예를 들어 A라는 서버가 5라는 가중치를 가지고 B라는 서버가 2라는 가중치를 가진다면, 로드밸런서는 라운드로빈 방식으로 A서버에 5개 B서버에 2개의 요청을 전달한다.
그렇다면 로드 밸런서는 어떤 노드가 더 높은 용량을 가지고 있는지 어떻게 알 수 있을까?
기본적으로 부하 분산 장치를 설정할 때 각 노드에 "가중치"를 할당한다. 물론 사양이 높은 노드에 더 높은 가중치를 부여해야 한다.
Cross-Zone Load Balancing
각 가용 영역마다 LB가 있고, 그 각각의 LB에 연결된 다수의 EC2가 구성되어 있을때, EC2에 LB가 붙어 부하 분산을 문제없이 시켜줄 것 같지만 그렇지 않다.
만약 A LB에는 EC2가 2개가 있고, 다른 B LB에 EC2가 8개 있을때 요청 수가 100개라 가정하면 A에는 각각 25개를 B에는 6.25개를 전달한다.
부하 분산은 트래픽을 대상들에게 고르게 전달하는 것인데 위의 구성에서는 가용역역에 따라 부하가 고르게 요청이 전달되지 않고 있어 A의 EC2에게 부하가 심하게 걸리게 된다.
이를 보완하기 위한 기능이 바로 교차 영역 로드밸런싱(Cross Zone Load Balancing)이다.
교차 영역 로드밸런싱(Cross Zone Load Balancing)을 사용하게 되면 가용영역을 가리지 않고 고르게 부하를 분산한다. ALB의 경우는 교차 영역 LB가 활성화 상태이며, NLB는 기본적으로 비활성화 되어 있다.
Cross Zone Load Balancing 이 무료다. AWS는 기본적으로 AZ간 데이터 통신은 과금이 되는데, ALB는 AZ간 Load Balancing을 하더라도 별도의 데이터 통신빈용이 발생하지 않는다.가중 라운드 로빈(Weighted Round Robin Method)은 용량에 비례하여 가중치를 지정하고 각 서버에 맞는 요청 수를 분산한다 Cross-Zone Load Balancing은 서버의 수에 비례하여 모두 동일한 요청 수를 분산한다.
리스너(Listener)
프로토콜과 포트를 기반으로 요청을 받아 검사하고 이를 적절한 타겟으로 전달하는 기능을 수행한다.(대상 그룹(가중치 ), 리디렉션 대상, 고정 응답 반환)
모든 LB는 최소 1개 이상의 리스너가 필요하며, 최대 10개까지 설정할 수 있다.
SSL 인증서를 게시하여, SSL Offload를 실시할 수도 있다.외부에서 HTTP 8080 포트로 접속하면, 리스너에서 이를 리스닝하여 대상 그룹 HTTP 80포트로 보내준다.
리스너 룰(Rule)
리스너 룰은 리스너와 타겟 그룹 사이의 트래픽 분배를 위한 라우팅 규칙에 해당한다.
룰은 우선순위, 액션, 조건 등의 정보를 담고 있으며, 조건이 만족되었을때 지정된 액션을 수행하는 방식으로 동작한다.리스너 룰에는 path, host, HTTP header, source IP, query parameter 등의 다양한 조건을 제공한다.
리스너는 최초 생성 시, default rule을 포함하고 있다. default rule은 별도의 조건을 가질 수 없으며, 다른 룰로 처리되지 않고 남은 모든 요청에 적용된다.
대상 그룹(Target Group)
대상 그룹은 리스너가 전달한 요청을 처리하기 위한 부하분산 대상들의 모임이다.대상 그룹에 등록된 EC2의 각종 정보(인스턴스 ID, Port, AZ)가 적혀있고, 이 EC2가 전달받은 요청을 처리할 수 있는지를 체크하는
'헬스 체크(Health Check)'기능과, 이 대상 그룹에 요청 처리가 가능한 EC2가 몇 개인지, 불가능한 EC2는 몇 개인지를 확인하는 요청 처리에 관련된'모니터링(Monitoring)'기능이 있다.즉, 오토스케일링을 하기위해서 인스턴스들을 그룹으로 묶어 오토스케일링 그룹으로 만든 것처럼, 로드 밸런싱 하기위 해서 대상 인스턴스들을 묶어 놓은 그룹이라고 이해 하면된다.
그리고 이 대상그룹을 오토스케일링 그룹으로도 만들 수 있다. (ELB + Auto Scaling 조합)
Health Check (상태 검사)
직접 트래픽을 발생시켜 인스턴스가 살아있는지 체크하는 기능이다.
타겟 그룹에 대한 헬스 체크를 통해 현재 정상적으로 작동하는 인스턴스로만 트래픽을 분배한다.
인스턴스의 상태를 자동으로 감지해서 오류가 있는 시스템은 배제한다. 인스턴스가 회복되면 LB가 자동으로 감지하여 인스턴스에 트래픽을 보내준다.
- 이를 통해 장애가 전파되는것을 방지하여 고가용성을 확보할 수 있다..
- 상태 확인 개선을 통해 상세한 오류 코드를 구성할 수 있다.
- 새로운 지표로 EC2 인스턴스에서 실행되는 각 서비스의 트래픽을 파악할 수 있다.
헬스 체크는 두가지 상태로 나뉘어진다
- InService(서비스 살음) / OutofService(서비스 죽음)
헬스 체크, 방법은 해당 포트의 Listen 상태를 감시하는 포트 감시 방식과 실제 HTML 파일 접근 가능 여부를 확인하는 HTTP/HTTPS 체크 방식으로 총 두가지 종류가 있다.
포트 감시 방식
- 임계값(Threashold) 만큼 Health check가 실패하면 load balancer를 서비스에서 Target을 제외시키고, 다시 해당 Target이 Healthy 상태가 되면 서비스에 추가시킨다. (자동)
보안 그룹
VPC를 사용할 경우 EC2 인스턴스 처럼 ELB와 관련된 보안 그룹을 생성 및 관리하여 로드 밸런서를 위한 추가 네트워킹 및 보안 옵션을 제공할 수 있다.
원하는 Load Balancer를 인터넷과 연결되도록 구성하거나 퍼블릭 IP 주소 없이 로드 밸런서를 생성하여 인터넷에 연결되지 않은 내부 로드 밸런서로 사용할 수 있다.
EC2에도 보안 그룹이 있지만, 외부에 있는 ELB에 한번더 보안그룹을 설정해 외부의 공격(디도스)에 대해 강력하게 대비하는 개념으로 생각하면 된다.
SSL 지원
SSL 암호화를 간편하게 구성 지원
따라서 SSL 증명서를 인스턴스들에 따라 설정할 필요가 없어진다.
통신의 암호화/복호화를 각각의 인스턴스에서 수행할 필요가 없으므로, 인스턴스의 부하를 낮출 수 있다.
또한, SSL 증명서를 ELB에서만 관리하면 되므로, 운용 측면에서의 장점도 가지게 된다.
로그 추출 기능
ELB로 처리한 요청 로그를 추출 할 수 있다.
추출한 로그는 S3에 저장된다.
장애 발생 또는 통신 오류가 발생하면, 인스턴스 로그를 하나하나 확인하는 것보다 ELB 로그를 확인하는 것이 원인을 조사하기에 좋다.
CloudWatch 연동
ELB는 1분 단위로 로드 밸런서와 타겟 그룹에 대한 메트릭을 제공한다. 이를 통해, CloudWatch와 연동하고 안정적으로 서비스를 모니터링 할 수 있다.
Amazon CloudWatch가 ALB와 CLB에 대해 요청 횟수, 오류 횟수, 오류 유형, 요청 지연 시간 등의 지표를 보고한다.
기능 및 특징
고가용성 및 탄력성(자동 확장/축소)
ELB는 접속 부하에 맞게 자동적으로 리소스의 확장/축소를 수행한다.
수신되는 트래픽을 단일 가용 영역 또는 여러 가용 영역의 Amazon EC2 인스턴스 전체에 걸쳐 배포할 수 있다.
ELB의 확장/축소는 스케일업/스케일다운과 스케일아웃/스케일인이라는 2가지 방식이 상황에 맞게 이루어진다.
NLB
NLB는 AWS에서 제공하는 4가지 LB 중 하나로, OSI 모델 4계층인 Transport 계층에서 작동하며 TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시한다.
단, HTTP가 아닌 하위 Layer인 TCP Layer에서 처리하므로 HTTP 헤더를 해석하지 못한다.
LB가 연결 요청을 받으면 기본 규칙의 대상 그룹에서 대상을 선택하고 리스너 구성에 지정된 포트에서 선택한 대상에 대한 TCP 연결을 열려고 시도한다.
고성능을 요구하는 환경에서의 부하분산에 적합하며, 낮은 레이턴시로 초당 수백만 건의 요청을 처리할 수 있으며 갑작스러운 트래픽 증대 및 변화에도 최적화 되어있다.
EIP로 공인 IP를 고정 할 수 있다. 그래서 ALB와 달리 로드밸런서에 접근 할때 아이피나 DNS 둘다 사용이 가능하다.NLB는 L4단의 로드 밸런서를 지원 NLB는 TCP/IP 프로토콜의 헤더를 보고 적절한 패킷으로 전송 NLB는 IP + 포트번호를 보고 스위칭 NLB는 할당한 Elastic IP를 Static IP로 사용이 가능하여 DNS Name과 IP주소 모두 사용이 가능 NLB는 SSL 적용이 인프라 단에서 불가능하여 애플리케이션에서 따로 적용해 주어야 함
ALB
ALB는 AWS에서 제공하는 4가지 LB 중 하나로, OSI 모델 7계층인 애플리케이션 계층에서 작동한다.사용자와 직접 접하는 계층으로, Application Layer에는 HTTP/HTTPS뿐만 아니라 FTP, DNS, DHCP, WebSocket 등 다양한 프로토콜이 존재한다.
ALB는 단순 부하분산뿐 아니라 HTTP/HTTPS의 헤더 정보를 이용해 지능적으로 라우팅(부하분산)을 할 수 있다. 즉, HTTP 헤더의 값들을 보고 어느 대상 그룹으로 보낼지를 판단할 수 있다.
예를 들면, LB 하나만 설정하면 트래픽을 모니터링하여 각 대상 그룹에 라우팅을 하게 해준다.
/user 경로로 오면 람다 대상 그룹에 보내주고, /shop 으로 오면 회원관리 대상 그룹에 보내주는 식이다.
따라서 LB의 갯수를 줄일수 있고 이는 곧 비용 절감으로 이어진다.ALB는 path(경로) 뿐만 아니라 port(포트)에 따라 다른 대상그룹으로 맵핑할 수도 있다. 각각의 포트에 따라 다르게 구성할 수 있으며, 동일한 포트라도 path(경로)등에 따라 다르게 분기할 수도 있다.
특히 포트 단위로 연결해줄 수 있는 것은 도커 컨테이너 환경에서 아주 유용하게 작동할 수 있고 하나의 대상 그룹에 더 많은 컨테이너를 넣어 비용을 최적화할 수 있다.
ALB는 대상을 EC2 인스턴스 뿐만 아니라 람다, IP로도 연결이 가능하며 특정한 요청에 대해서는 서버없이 직접 응답메세지를 작성할 수 있기때문에 마이크로아키텍쳐를 구성하기에 좋다. 그리고 SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암호화/복호화를 대신 진행할 수 있다.
ALB는 L7단의 로드 밸런서를 지원 ALB는 HTTP/HTTPS 프로토콜의 헤더를 보고 적절한 패킷으로 전송 ALB는 IP주소 + 포트번호 + 패킷 내용을 보고 스위칭 ALB는 IP 주소가 변동되기 때문에 Client에서 Access 할 ELB의 DNS Name을 이용 ALB는 L7단을 지원하기 때문에 SSL 적용이 가능
도메인 기반 접근
ALB는 지속적으로 IP주소가 바뀌며 IP 고정 불가능하여 따라서 항상 도메인 기반으로 사용해야 한다.
자동 확장/축소 함에 따라 ALB 접근 IP가 변경되므로, ALB에 접근하는 경우 ALB를 생성할 때에 생성되는 도메인 이름을 사용해 접근하도록 구성해야 한다.
단, 네트워크 로드밸런서(NLB)는 탄력적 IP로 고정 가능하다.
즉, DNS 이름을 통해 접속하면 ALB는 요청을 대상 그룹에 전달할 것이고 대상 그룹의 EC2가 요청을 처리하는 것이다.
CNAME CNAME은 Canonical Name의 약자로 도메인 주소를 또 다른 도메인 주소로 매핑 시키는 형태의 DNS 레코드 타입이다.A Record A 레코드(A Record)는 DNS에 저장되는 정보의 타입으로 도메인 주소와 서버의 IP 주소가 직접 매핑시키는 방법이다.
NLB ALB 복합 구성
ALB와 NLB를 직접 통합하여 복합 구성할 수 있다.
클라이언트는 DNS 주소를 해석하여 ALB를 이용하여 문제없이 연결할 수 있다. 하지만, ALB의 IP 주소목록은 추가되거나 변경될 수 있기 때문에 클라이언트가 인터넷 상에서 항상 ALB의 동일한 모든 IP주소로 연결할 수 있지 않고, 이 때문에 오래된 디바이스를 쓰고 있거나 보안에 엄격한 네트워크 관리자에겐 ALB가 까다롭게 여겨질 수 있다. 고정 IP는 이런 문제를 해결해 줄 수 있으며 클라이언트가 임시 해결적으로서 현재 IP 주소들을 업데이트하거나 방화벽에 넣어주는 스크립트를 실행할 필요가 없어진다.
NLB는 각 가용영역에 고정 IP주소들을 두고 쓸 수 있다. 이러한 고정 IP주소들은 변하지 않기 때문에 방화벽의 화이트리스트( All Deny and Some Permit )에 추가될 수 있다. 하지만 NLB는 TCP 통신만 허용하기 때문에 HTTPS를 처리하지 않으며, ALB의 7계층 관련 기능들이 없다.
그렇기 때문에, NLB를 ALB 앞에 둠으로서 두 가지 장점을 모두 가지는 방법을 사용할 수 있다.
요금 정책
NLB - 실행된 시간 또는 부분 시간 그리고 시간당 사용된 로드 밸런서 용량 단위(NLCU)에 대해 요금이 부과
NLCU는 Network Load Balancer가 트래픽을 처리하는 차원을 측정한다(시간당 평균).
NLB 사용량(NLCU)는 1) 새 연결 또는 흐름 수, 2) 활성 연결 또는 흐름 수, 3) 데이터 크기 로 이루어져 있다.
각각의 max값이 있고, 특정 시간동안 가장 많이 사용한 항목을 기준으로 NLCU를 계산한다.Network Load Balancer 시간(또는 부분 시간)당 0.0225 USD NLCU 시간(또는 부분 시간)당 0.006 USD
[예1]
예와 같은 상황일때 (사용시간) + (사용량)을 시간 단위와 월 단위로 계산해보면 아래와 같다.
시간으로 계산하게되면 시간당 총 요금 0.0289 USD (NLCU 이용 시간 요금 0.0225 USD + 3개중 가장 많이 사용한 요금(NLCU) 0.00648 USD) 가 청구된다.
월로 계산하게 되면 월 총 요금 20.86 USD (시간당 총 요금 0.0289 USD 24시간 30일).이 청구된다.[예2]
[예3]
ALB - 실행된 시간 또는 부분 시간 그리고 시간당 사용된 로드 밸런서 용량 단위(LCU)에 대해 요금이 부과
기본적인 가격정책은 (사용시간) + (사용량)으로 이루어져 있다.
ALB 사용량(LCU)는 1) 새 연결수, 2) 활성 연결수, 3) 데이터 크기, 4) 규칙평가 로 이루어져 있다.
각각의 max값이 있고, 특정 시간동안 가장 많이 사용한 항목을 기준으로 LCU를 계산한다.AWS 리전에서 Application Load Balancer를 사용하는 경우: Application Load Balancer 시간(또는 부분 시간)당 0.0225 USD LCU 시간(또는 부분 시간)당 0.008 USD Outposts에서 Application Load Balancer를 사용하는 경우: Application Load Balancer 시간(또는 부분 시간)당 0.0225 USD LCU 시간(또는 부분 시간)당 0.00 USD
[예1]
예와 같은 상황일때 (사용시간) + (사용량)을 시간 단위와 월 단위로 계산해보면 아래와 같다.
시간으로 계산하게되면 시간당 총 요금 0.03114 USD (ABL 이용 시간 요금 0.0225 USD + 4개중 가장 많이 사용한 요금(LCU) 0.00864 USD) 가 청구된다.
월로 계산하게 되면 월 총 요금 22.42 USD (시간당 총 요금 0.03114 USD + 24시간 * 30일)이 청구된다.[예2]
[예3 - AWS Lambda만을 대상으로 하는 Application Load Balancer]
[예4 - Amazon EC2와 AWS Lambda를 모두 대상으로 하는 Application Load Balancer]
