[AWS] ALB - Application Load Balancer

ALB - Application Load Balancer

ALB란?

ALB는 AWS에서 제공하는 로드밸런서 중 하나로 OSI Layer7인 어플리케이션 계층에서 동작하는 로드밸런서이다.

부하(Load), 즉 트래픽을 균형있게 나누어준다(Balance)는 의미로 로드 밸런서라고 부른다.

 

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html

위 사진과 같이 Load Balancer, Listener, Target Group으로 나누어져 있다.

 

기능

• 어플리케이션의 트래픽을 여러 가용 영역으로 분산한다.
• 리스너를 통해 RL, 호스트, 헤더, 메소드 등을 기반으로 요청의 규칙을 구성하여 처리할 수 있다.
• 트래픽 부하에 따라 자동으로 스케일업,스케일 다운을 수행한다.
• 하나 이상 타겟 그룹에 라우팅할 수 있으며 가중치 설정이 가능하다.
• SSL Offloading(SSL Termination)을 지원한다.
• 디폴트 로드밸런싱 알고리즘은 라운드 로빈이며, 최소 미해결 요청 라우팅 알고리즘을 지원한다.
• 교차 영역 로드밸런싱을 통해 Availability Zone의 모든 타켓 그룹에 고르게 트래픽을 분산한다.

 

Listener (리스너)

리스너의 규칙에 따라 요청을 라우팅하는 방법이 결정된다.

각 규칙은 우선 순위에 따라 평가된다.

 

규칙

리스너의 규칙은 다음과 같이 IF와 THEN으로 이루어져 있다.

IF 의 조건이 만족하면 THEN 의 작업을 한다.

 

IF

규칙	설명		예시
host header	요청의 호스트 이름을 기반으로 라우팅		ex1.com, ex2.com
http header	요청의 HTTP 헤더 기반으로 라우팅		User-Agent: Chrome
http request method	요청의 HTTP 메소드 기반으로 라우팅		GET, PUT
path pattern	요청 URL의 경로 패턴을 기반으로 라우팅		/img/*
query string	쿼리 문자열의 키/값 페어 또는 값 기반으로 라우팅		?name=product
source IP	요청의 소스 IP 주소 기반으로 라우팅

•  

 

THEN

규칙	설명
authenticate cognito	Amazon Cognito를 사용하여 사용자 인증을 한다.
authenticate oidc	OpenID Connect, 즉 OAuth 2.0 으로 사용자 인증을 한다.
fixed response	사용자가 정의한 HTTP 응답을 반환한다.
forward	요청을 대상 그룹으로 전달한다.
redirect	요청을 다른 URL로 리다이렉션 한다.

•  

 

 

Target Group (대상 그룹)

로드 밸런서가 요청을 처리하는 대상의 기준이며, 타겟 그룹으로 등록한 대상에 대해 상태를 확인(health check)한다.

리스너에서 규칙 조건이 충족되면 해당하는 타겟 그룹으로 트래픽이 전달된다.

같은 VPC 내의 로드밸런서는 타겟 그룹으로 등록할 수 없다.

 

 

 

Load Balancing vs Reverse Proxy

https://www.bitslovers.com/aws-api-gateway-with-nginx-and-waf/

네트워크 아키텍처를 보다보면 AWS ALB 아래에 Reverse Proxy 역할을 위해 Nignx를 두는 것을 찾아볼 수 있다. (물론 ALB 없이 Nginx가 LB와 Reverse Proxy 역할을 둘 다 하기도 한다.) ALB와 Reverse Proxy가 유사한 역할을 하고 있어 로드 밸런서와 Reverse Proxy의 차이점이 뭘까 찾아봤는데 좋은 정리를 볼 수 있었다.

 

Load Balancing

요청을 서버 그룹간 분산하여 선택한 서버에서의 응답을 반환한다. 로드 밸런서의 역할은 서버의 과부하를 방지하며 클라이언트에 가장 빠른 응답을 제공하는 것이다.

클라이언트가 보는 오류 응답을 줄이는 것에 의미가 있는데, 헬스 체크를 지속적으로 수행하여 다운된 서버엔 요청을 보내지 않는다거나 트래픽이 많아진다면 서버 인스턴스를 증가하는 것이 그 예시이다.

Sticky Session, Session Clustering 등을 통해 세션 지속성을 제공해준다.

 

Reverse Proxy

요청을 수락하고 이를 수행할 수 있는 서버로 포워딩한 후 응답을 반환한다. 로드 밸런서는 서버를 여러 개 사용했을때만 의미가 있다면, 리버스 프록시는 서버가 하나 뿐인 경우에도 의미가 있다. 리버스 프록시엔 다음과 같은 장점들이 있는데,

 

보안성

특정 클라이언트 IP를 거부하거나 연결의 개수를 제한함으로써 DDoS 공격으로 부터 보호할 수 있다.

클라이언트는 리버스 프록시 IP만 알고 있기 때문에 백엔드 서버 변경에 자유롭다.

 

웹 가속화

응답의 크기가 크다면 클라이언트로 반환하기 전에 압축하여 전송 속도를 높일 수 있다.

SSL Termination 지원을 통해 서버에서 SSL 인증 오버헤드를 줄여준다.

응답을 캐시에 저장하여 동일한 요청일 경우 자체적으로 응답을 제공해줄 수 있다.

 

 

물론 ALB처럼 Load Balancer에서 SSL Termination을 해주기도 하고 Nginx 처럼 Reverse Proxy에서 트래픽 분산을 담당해주면서 둘의 역할을 동시에 하기도 한다. 둘의 역할을 명확히 나눈다기 보다 서비스의 적합한 아키텍처에 따라 적절히 역할을 나누는 것 같다.

 

 

 

 

 

 

참조

 

https://ssungkang.tistory.com/entry/DevOps-Reverse-Proxy-vs-Load-Balancer-리버스-프록시-vs-로드-벨런서

https://isn-t.tistory.com/35

https://inpa.tistory.com/entry/AWS-📚-ELB-Elastic-Load-Balancer-개념-원리-구축-세팅-CLB-ALB-NLB-GLB