ELB?
애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS 서버 환경을 운영하는데 도움을 주는 서비스.
EC2 뿐만 아니라 컨테이너(ECS), AWS Lambda 등으로 다양한 서비스와 언계해 부하 분배
ELB는 서로 다른 EC2 인스턴스에 대한 하나의 엔드포인트 제공.
그래서 사용자는 실제 요청이 처리되는 백엔드 인스턴스에 대한 고려없이,
동일한 엔드포인트로 요청을 전송할 수 있다.
부하분산뿐만 아닌 부사 분산에 대한 헬스체크(Health Check), 고정 세션(Sticky), SSL OFFload(SSL 암복호화), 헬스체크를 통한 다운 서버 제외 등 가능.
ELB 내부 구성 요소
Virtual Private Network(VPC)에 탑재,
사용자의 요청을 받고 이를 VPC 내의 리소스(EC2 등)에 적절히 부하 분산.
ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성, ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있다.
리스너(Listener)
프로토콜과 포트를 기반으로 요청을 받아 검사,
이를 적절한 타겟으로 전달하는 기능 수행.
리스너는 외부의 요청을 받아들여 모든 로드 밸런서는 최소 1개 이상의 리스너를 필요로 하며, 최대 10개까지 설정 가능.
SSL 인증서를 게시해 SSL Offload를 실시할 수도 있다.
규칙(Rule)
리스너 룰은 리스너와 타겟 그룹 사이의 트래픽 분배를 위한 라우팅 규칙에 해당.
룰은 우선순위, 액션, 조건 등의 정보를 담고 있으며, path, host, HTTP header, source IP, query parameter 등 다양한 조건이 만족되었을 때 지정된 액션을 수행하는 방식으로 작동.
대상 그룹(Target Group)
대상 그룹은 리스너가 전달한 요청을 처리하기 위한 부하분산 대상들의 모임.
즉, ELB가 분산할 때 어디로 분산할 것이냐를 모은 그룹
대상 그룹에 등록된 EC2의 각종 정보(인스턴스 ID, Port, AZ)가 적혀있고,
이 EC2가 전달받은 요청을 처리할 수 있는지를 체크하는 헬스체크 기능과, 이 대상 그룹에 요청 처리가 가능한 EC2가 몇 개 인지, 불가능한 EC2는 몇개인지 확인하는 요청 처리에 관련된 모니터링 기능이 들어있다.
-> 오토스케일링을 하기 위해 인스턴스들을 그룹으로 묶어 오토스케일링 그룹으로 만든 것처럼,
로드밸런싱 하기 위해 대상 인스턴스들을 묶어 놓은 그룹.
이걸 다시 오토스케일링 그룹으로 만들수도 있다(ELB + Auto Scaling)
유휴 제한 시간(Connection Time Out)
사용자가 ELB를 거쳐 EC2에 접근해 서비스를 접속하면 Connection이 생성됨.
이 커넥션을 통해 사용자와 EC2가 통신.
만일 더이상 통신이 없을 때는, 유휴 제한 시간이 작동,
그 시간이 지나면 커넥션이 사라짐.
즉, 일정시간동안 통신이 없을때 커넥션을 삭제할 것인가를 뜻함
ELB 기능 및 장점
고가용성 및 탄력성(자동 확장 및 축소)
ELB는 접속 부하에 맞게 자동적으로 리소스의 확장/축소 수행.
대량의 요청이 발생해도 ELB로 인해 병목 현상이 발생하는 상황은 거의 일어나지 않음.
하지만, 순간적으로 접근이 증가하면 리소스 자동 확장까지 일정 시간이 걸려 일시적인 병목현상이 발생할수도 있음.
이럴땐, AWS 서포트에 미리 신청해 ELB 리소스를 확장하는게 좋음.
또한, 수신되는 트래픽을 단일 가용 영역 or 여러 가용 영역의 Amazon EC2 인스턴스 전체에 걸처 배포 가능.
ELB의 확장 축소는
스케일업/스케일다운 스케일아웃/스케일인 -> 상황에 맞게 이루어짐
도메인 기반 접근
ELB는 지속적으로 IP주소가 바껴 IP 고정 불가능.
따라서 항상 도메인 기반으로 사용해야함.
자동 확장/축소 함에 따라 ELB 접근 IP가 변경되어,
ELB에 접근하는 경우 ELB를 생성할 때 생성되는 도메인 이름을 사용해 접근하도록 구성해야함.
즉, DNS 이름을 통해 접속하면 ELB는 요청을 대상 그룹에 전달할 것이고 대상 그룹의 EC2가 요청을 처리.
(But, 네트워크 로드밸런서(NLB)는 탄력적 IP로 고정 가능)
ELB 요청 처리 과정
- 사용자가 로드밸런서에 접근하기 위해 Amazon DNS 서버에 로드밸런서 도메인 해석 요청
- Amazon의 DNS 서버가 로드밸런서 노드 IP 리스트를 사용자에게 전달
- 사용자는 전달받은 IP 중 하나를 선택해 로드밸런서에 접근(+ Port 입력)
- 사용자는 로드밸런서의 (Port가 일치하는) 리스너에 접근하게 되며 리스너는 이 요청을 받아들여 적절한 대상 그룹으로 전달.
- 리스너로부터 전달받은 요청을 EC2가 처리한 후 다시 사용자에게 반환
Cross-Zone Load Balancing
교차 영역 로드 밸런싱.
Availability Zone별로 사용하는 EC2 개수에 차이가 있는 경우 사용하면 좋음.
Application Load Balancer의 경우 기본적으로 교차 영역 로드밸런싱 활성화.
Network Load Balancer는 기본적으로 비활성화.
Health Check(상태검사)
ELB에 연결된 인스턴스에 직접 트래픽을 발생시켜 인스턴스가 살아있는지 체크하는 기능
현재 정상적으로 작동하는 인스턴스로만 트래픽을 분배.
이를 통해 장애가 전파되는걸 방지, 고가용성 확보, 상태확인개선을 통해 상세한 오류 코드 구성.
새로운 지표로 EC2인스턴스에서 실행되는 각 서비스 트래픽 파악.
- InService(서비스 실행중)
- OutofService(서비스 죽음)
HTTP/HTTPS 체크방식
상태 확인을 HTTP/HTTPS 프로토콜 통해서 확인가능
포트 감시 방식
임계값(Threashold) 만큼 Health check가 실패하면 load balancer를 서비스에서 Target을 제외시키고, 다시 해당 Target이 Healthy 상태가 되면 서비스에 추가시킴.
추가적인 보안 그룹 설정
로드밸런서 또한 네트워크 인터페이스 형태를 띔.
EC2 인스턴스처럼 ELB와 관련된 보안 그룹을 생성 및 관리해 로드밸런서를 위한 추가 네트워킹 및 보안옵션 제공.
EC2에도 보안그룹이 있지만, 외부에 있는 ELB에 한번 더 보안그룹을 설정해 외부의 공격(디도스)에 대해 강력하게 대비하는 개념으로 생각하면 됨.
원하는 Load Balancer를 인터넷과 연결되도록 구성하거나 퍼블릭 IP 주소 없이 로드 밸런서를 생성하여 인터넷에 연결되지 않은 내부 로드 밸런서로도 사용할 수 있다.
SSL 지원
SSL 암호화를 간편하게 구성 지원함.
따라서 SSL 증명서를 인스턴스들에 따라 설정할 필요X
통신의 암호화/복호화를 각각의 인스턴스에서 수행할 필요가 없어,
인스턴스의 부하를 낮출 수 있다.
또한, SSL 증명서를 ELB에서만 관리하면 되어, 운용 측면에서의 장점도 가지게 된다.
고정 세션(Sticky Session)
사용자 세션을 특정 인스턴스에 고정시킴으로써 자신이 이전에 접속했던 인스턴스로 다시 접속할 수 있도록 해줌
로그 추출 기능
ELB로 처리한 요청 로그를 추출할 수 있다.
추출한 로그는 S3에 저장.
장애 발생 또는 통신 오류가 발생 시, 인스턴스 로그 하나하나 확인하는 것 보다 ELB 로그를 확인하는 것이 원인을 조사하기에 좋다.
CloudWatch 연동
ELB는 1분 단위로 로드 밸런서와 타겟 그룹에 대한 메트릭 제공.
이를 통해, CloudWatch와 연동하고 안정적으로 서비스를 모니터링 가능
Amazon CloudWatch가 ALB와 CLB에 대해 요청 횟수, 오류 횟수, 오류 유형, 요청 지연 시간 등 지표 보고
HTTP/2 지원
ALB에서는 별도의 설정 없이 HTTP/2를 지원해서 웹 브라우저에서 페이지 로딩시간을 개선할 수 있다.
ELB 서비스 종류
Application Load Balancer(ALB)
OSI 7계층에서 최상단 일곱번째 계층에 해당하는 Application Layer를 다룸
사용자와 직접 접하는 계층,
우리가 브라우저를 통해 접속할 수 있도록 하는 프로토콜 역시 Application Layer에 해당하는 HTTP/HTTPS다.
지속적인 라우팅 기능
ALB는 단순 부하분산뿐만 아니라 HTTP/HTTPS의 헤더 정보를 이용해 부하분산을 실시.
즉 HTTP헤더의 값들을 보고 이 요청은 어느 대상그룹으로 보낼지 저 요청은 어느 대상 그룹으로 보낼지를 판단할 수 있다는 뜻. -> 지능적인 라우팅
ALB는 로드밸런서 하나만 설정하면, 트래픽을 모니터링해 각 대상그룹에 라우팅하게함
-> 로드밸런서의 갯수를 줄일 수 있고 비용절감으로 이뤄짐
ALB는 path(경로) 뿐만 아닌 port(포트)에 따라 다른 대상그룹으로 맵핑할 수도 있다.
각각의 포트에 따라 다르게 구성할 수 있으며, 동일한 포트라도 path(경로) 등에 따라 다르게 분기될 수도 있다.
특히 포트 단위로 연결해줄 수 있는 것은 도커 컨테이너 환경에서 아주 유용하게 작동할 수 있고, 하나의 대상그룹에 더 많은 컨테이너를 넣어 비용을 최적화할 수 있다.
ALB는 대상을 EC2 인스턴스 뿐만 아니라 람다, IP로도 연결이 가능하며 특정한 요청에 대해서는 서버없이 직접 응답메세지를 작성할 수 있어 마이크로아키텍쳐를 구성하기 좋다.
SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신해 SSL 암호화/복호화를 대신 진행할 수 있다.
-> ALB는 TCP를 기반으로 하는 HTTP/HTTPS, WebSocket 등을 활용해,
HTTP의 주요 특징인 HTTP Header, Host Header, 요청 메서드 등에 기준을 적용해 기준에 맞는 적절한 대상그룹으로 라우팅 할 수 있는 로드밸런서.
- ALB는 L7단위 로드밸런서 지원
- ALB는 HTTP/HTTPS 프로토콜의 헤더를 보고 적절한 패킷으로 전송
- ALB는 IP주소 + 포트번호 + 패킷 내용을 보고 스위칭
- ALB는 IP주소가 변동되기 때문에 Client에서 Access할 ELB의 DNS Name 이용
- ALB는 L7단을 지원해 SSL 적용 가능
Network Load Balancer(NLB)
NLB는 AWS에서 제공하는 4가지 로드밸런서 중 하나로,
OSI 7 Layer에서 네번째 계층에 해당하는 Transport LAYER를 다루는 로드밸런서.
NLB는 TCP/UDP를 사용하는 요청을 받아들여 부하분산 실시.
그래서 NLB가 ALB보다 성능이 더 빨라 고성능을 요구하는 환경에서의 부하분산에 적합한 솔루션.
낮은 레이턴시(대기시간)로 초당 수백만 건의 요청을 처리할 수 있고,
갑작스러운 트래픽 증대 및 변화에도 최적화.
단, HTTP가 아닌 하위 Layer인 TCP Layer에서 처리해 HTTP 헤더를 해석하지 못함.
IP 고정 기능
ALB와 비교해 NLB의 가장 큰 특징은 EIP 공인 IP를 고정할 수 있다는 점.
그래서 ALB와 달리 로드밸런서에 접근할 때 아이피나 DNS 둘 다 사용 가능
TCP 세션은 350초 정도 유지, 로드밸런서가 연결 요청을 받으면 기본 규칙의 대상 그룹에서 대상을 선택하고 리스너 구성에 지정된 포트에서 선택한 대상에 대한 TCP 연결을 열려고 시도.
ALB VS NLB
ALB : 클라이언트가 웹화면을 요청하는 상황일 때 (HTTP, HTTPS 프로토콜을 사용해 어플리케이션 레벨 접근시)
NLB : 내부로 들어온 트래픽을 처리, 내부의 인스턴스로 트래픽을 전송
7계층까지 확인하는 ALB의 기능이 더 많다.
NLB는 network 계층까지만 확인해서 ALB보다 빠름.
따라서, 단순한 라우팅이 필요하고 트래픽이 극도로 많은 경우 ALB보다는 NLB를 사용하는 것이 적합.
ALB는 path-based routing이 가능해 path를 확인해 특정 서버로 라우팅 시켜줘야하는 경우에 적합
=> ALB처럼 똑똑하게 주소로 보내주는게 아닌 단순한 라우팅이 필요하고 트래픽이 극도로 많은 경우 ALB보다는 NLB를 사용하는 것이 적합
NLB의 특징
1. L4단의 로드밸런서 지원
2. TCP/IP 프로토콜의 헤더를 보고 적절한 패킷으로 전송
3. IP + 포트번호를 보고스위칭
4. 할당한 Elastic IP를 Static IP로 사용이 가능, DNS Name과 IP주소 모두 사용 가능
5. SSL 적용이 인프라 단에서 불가능하여 애플리케이션에서 따로 적용해줘야함.
GWLB(Gateway Load Balancer)
OSI 모텔의 3번째 계층인 네트워크 계층에서 작동.
GWLB 사용시 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 확장 및 관리 가능.
즉, 트래픽을 EC2에 도달하기 전에 먼저 트래픽을 검사하거나 분석하거나 인증하거나 로깅하는 작업을 먼저 수행할 수 있게하는 서비스.
-> 일반적인 로드밸런서의 역할과는 다름, 트래픽을 체크한다라고 이해하면 됨.
Classic Load Balancer(CLB)
이 넷 모두 부하분산을 하는 로드밸런서라는 점은 동일하지만 역할이 각각 다르다.
aws에서 설정할 때 이 셋 중 하나를 선택해 로드밸런서를 생성하고 그 기능을 사용하게 된다.
CLB는 아주 초창기때 나온 로드밸런서로 지금은 지원이 끊겨 deprecated 처리됨
