☁️⟪AWS⟫ 로드 밸런싱(Load Balancing)과 ELB & ALB
로드 밸런싱(Load Balancing) 이란?
ELB를 이해하기위해 우선 로드 밸런싱이 어떤 역할인지부터 araboza.
Load(부하) Balancing(분산)이란 컴퓨터 네트워크 기술의 일종으로, 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다.
말그대로 부하를 분산해 트래픽이 과도하게 몰려 서비스가 중단되는 현상을 막기 위한 기술이다. 그래야 지연 없이 작업을 처리하고 속도를 낼 수 있다.
회사에서 팀장이 외부로부터 받아 처리해야 할 업무를 팀원들에게 나누어 주어 기간안에 일을 처리하는 행위 또한 부하 분산으로 볼 수 있다.
로드 밸런서는 이런 부하를 분산하는 것 뿐만 아니라, 스케일 아웃에 대한 하나의 엔드포인트를 제공하기도 한다.
우리는 오토스케일링 그룹을 통해 다수의 인스턴스를 생성(스케일 아웃)하고 관리함으로써 고가용성을 확보할 수있고 안정적인 서비스를 제공할 수 있게 되었다.
그렇지만 증설된 각각의 인스턴스는 모두 다 일종의 컴퓨터이니 IP 주소를 갖고 있을테고, 이것을 사용하는 유저 입장에서는 이들을 관리하기 위해서 일일이 주소를 백업해 하나하나 접속하면서 관리해야 된다.
뿐만 아니라 만약 인스턴스 하나가 떨어지고 다시 새로 인스턴스가 올라가게 된다면, IP주소가 바뀌게 되고 이에 대해 별도의 조치를 취해야한다.
더군다나 만약에 인스턴스가 8개가 아니라 엄청 많을 때는 관리비용이 엄청 증가 하게 된다.
따라서, 오토스케일링 그룹 자체는 혁신적인 방법이지만
별도의 로드 밸런싱, 부하를 분산해주는 서비스 없이는 활용 불가이기 때문에 그래서 나온 서비스가 Elastic Load Balancing 인 것이다.
Tip
ELB(Elastic Load Balancing)는 AWS에서 운용하는 로드 밸런서(Load Balancer)를 지칭 하는 것으로 보면 된다.
로드 밸런서(Load Balancer)가 트래픽을 하나의 경로로 받아서 다수의 인스턴스에 분산한다.
유저 입장에서는 각각의 인스턴스에 일일히 접근해서 관리하는게 아닌 하나의 주소로 접속해서 관리할 수 있게 된다.
인스턴스가 떨어져나가거나 오류가 나서 트래픽을 수신하지 못할 때에도 로드밸런서가 스마트하게(health check / monitoring) 알아서 트래픽을 전송하지 않게 하고, 새로운 인스턴스가 등록이 되면 자동으로 분산을 시켜준다.
ELB (Elastic Load Balancer)
ELB(Elastic Load Balancer)란 애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS서버 환경을 운용하는데에 도움을 주는 서비스다. EC2뿐만 아니라 컨테이너(ECS), AWS Lambda 등으로 다양한 서비스와 연계하여 부하를 분배할수 있다.
ELB는 서로 다른 EC2 인스턴스에 대한 하나의 엔드포인트를 제공한다. 그래서 사용자는 실제 요청이 처리되는 백엔드 인스턴스에 대한 고려 없이, 동일한 엔드포인트로 요청을 전송할 수 있다.
거기다 부하분산뿐만 아니라 부하 분산 대상에 대한 헬스 체크(Health Check), 고정 세션(Sticky), SSL Offload(SSL 암복호화), 헬스 체크를 통한 다운 서버 제외 등이 가능하다.
ELB 구성요소 (리스너 / 룰 / 대상그룹)
ELB는 Virtual Private Network(VPC)에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스(EC2 등)에 적절히 부하 분산한다.
ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성되며 ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있다.
부하 분산 대상인 대상 그룹 내 리소스들은 헬스 체크(Health Check)를 활용해 끊임없이 상태를 확인받게 된다.
리스너는 외부의 요청을 받아들이기 때문에 서비스 포트(Service Port)를 보유하고 있으며 외부의 요청은 서비스 포트로 접속하는 요청만을 처리한다.
대상 그룹 또한 서비스 포트를 보유하고 있으며 부하 분산 대상인 EC2는 해당 포트가 열려있어야 한다.
그리고 대상그룹의 포트는 꼭 리스너와 포트가 같은 필요는 없다. (뒤의 실습에서 자세히 다룬다)
요청을 검토한 리스너가 요청이 적합한 경우 대상그룹에게 이를 전달할 때 대상 그룹의 포트로 'Port Translation'을 실시하기 때문이다.
ALB (Application Load Balancer)
Application Load Balancer는 OSI 7 Layer에서 최상단 일곱 번째 계층에 해당하는 Application Layer를 다루는 로드밸런서 이다.
사용자와 직접 접하는 계층으로서 여러분이 브라우저를 통해 이 블로그를 접속할 수 있도록 사용하는 프로토콜 역시 Application Layer에 해당하는 HTTP/HTTPS인 것이다.
Application Layer에는 HTTP/HTTPS뿐만 아니라 FTP, DNS, DHCP, WebSocket 등 다양한 프로토콜이 존재한다.
ALB는 단순 부하분산뿐만 아니라 HTTP/HTTPS의 헤더 정보를 이용해 부하분산을 실시할 수 있다. (지능적인 라우팅 기능)
즉, HTTP 헤더의 값들을 보고 이 요청은 어느 대상그룹으로 보낼지 저 요청은 어느 대상 그룹으로 보낼지를 판단할 수 있다는 뜻이다.
예를들어 위의 구식 CLB같은경우는 각 대상 그룹 주소 마다 로드 밸런서를 각각 두었다.
하지만 ALB는 로드 밸런서 하나만 설정하면, 트래픽을 모니터링하여 각 대상그룹에 라우팅을 하게 해준다.
/user path 경로로 오면 람다 대상그룹에 보내주고, /shop path로 오면 회원관리 대상그룹에 보내주는 식이다.
이처럼 유저가 어떤 서버로 접속함에 따라서 다른 경로로 스마트하게 라우팅이 가능하다.
따라서 로드밸런서의 갯수를 줄일수 있고 이는 곧 비용 절감으로 이어진다.
ALB는 path(경로) 뿐만 아니라 port(포트)에 따라 다른 대상그룹으로 맵핑할 수도 있다.
각각의 포트에 따라 다르게 구성할 수 있으며 동일한 포트라도 path(경로)등에 따라 다르게 분기할 수도 있다
특히 포트 단위로 연결해줄 수 있는 것은 도커 컨테이너 환경에서 아주 유용하게 작동할 수 있고 하나의 대상그룹에 더 많은 컨테이너를 넣어 비용을 최적화할 수 있다.
ALB는 대상을 EC2 인스턴스 뿐만 아니라 람다, IP로도 연결이 가능하며 특정한 요청에 대해서는 서버없이 직접 응답메세지를 작성할 수 있기때문에 마이크로아키텍쳐를 구성하기에 좋다.
그리고 SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암호화/복호화를 대신 진행할 수 있다.
위의 내용을 종합해보면 Application Load Balancer는 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 적용이 가능
출처::
https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-ELB-Elastic-Load-Balancer-%EA%B0%9C%EB%85%90-%EC%9B%90%EB%A6%AC-%EA%B5%AC%EC%B6%95-%EC%84%B8%ED%8C%85-CLB-ALB-NLB-GLB