AWS Application Load Balancer(ALB) 이해하기

Application Layer
사용자가 UI로 접하는 응용 프로그램과 관련된 계층으로 HTTP,FTP,DHCP,SMTP,DNS 등이 있습니다. 여기에 속한 프로토콜들은 어떠한 방법으로든 사용자와 직접 접하게 됩니다.

Application Layer는 OSI 7 Layer 중 최상단 계층에 해당하는 Layer입니다.
위 설명처럼 사용자와 직접 접하는 계층이죠. 여러분이 이 블로그를 접속할 수 있도록 도와주는 브라우저, 그 브라우저가 사용하는 프로토콜 역시 Application Layer에 해당하는 HTTP입니다. Application Layer에는 HTTP뿐만 아니라 FTP, DNS, DHCP 등 다양한 프로토콜이 존재합니다.
각각의 프로토콜들 모두 사용자가 직접 영향을 받는 프로토콜이죠.

Application Load Balancer(ALB)란?

Application Load Balancer는 개방형 시스템 간 상호 연결(OSI) 모델의 일곱 번째 계층인 애플리케이션 계층에서 작동합니다. 로드 밸런서는 요청을 받으면 우선순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음, 규칙 작업의 대상 그룹에서 대상을 선택합니다.

수많은 프로토콜의 Profile이 적용되는 L7 Virtual Server를 사용하는 L4 스위치와는 달리 HTTP와 HTTPS, WebSocket을 활용하는 로드밸런서라는 것이 가장 큰 특징입니다. 아래 그림은 로드밸런서의 선택 화면인데, 빨간색 박스가 ALB입니다. HTTP와 HTTPS 트래픽을 사용하는 웹 애플리케이션을 위한 로드밸런서임을 설명하고 있습니다.

그렇기에 ALB는 HTTP의 Header, 요청 Method 등을 이용해 사용자의 요청을 적절한 대상그룹으로 라우팅(부하분산)할 수 있으며 규칙에 우선순위를 두고 차례대로 적용할 수 있습니다. 아래 그림에서 ALB의 사용 가능한 '규칙'(라우팅을 판단하는 기준)을 보실 수 있으며, 각 항목을 살펴보면 HTTP의 특징을 활용하고 있음을 알 수 있습니다. 

물론 HTTP 또한 TCP 기반의 프로토콜이기 때문에 ALB는 라우팅 실시 이전에 커넥션 생성을 위한 3-way handshake를 실시해야 합니다. Layer 7의 로드밸런서라고 해서 Layer 4(TCP, UDP)를 무시하는 것이 아니라 Layer 4의 규약(프로토콜)을 충분히 이행한 후 HTTP를 이용한 라우팅을 실시하는 것입니다. OSI 7 Layer에 대해 제대로 이해하고 있다면 이는 당연한 것입니다.

 

Application Load Balancer의 주요 특징

HTTP를 활용한 라우팅(부하분산)

위에서도 지속적으로 언급했지만 ALB의 가장 큰 특징은 HTTP의 특성을 활용한다는 것입니다. 첫 번째는 'HTTP Header'(이하 헤더)로 HTTP 헤더에는 표준 헤더, 요청 헤더, 응답 헤더, 일반 헤더가 존재합니다. 요청 상황, 응답 상황에 따라 다른 헤더를 가지며 그 헤더에는 다양한 정보가 들어있습니다. 그리고 사용자는 헤더에 자신의 정보를 담아 서버에 전송할 수 있고 서버는 헤더에 담긴 정보를 보고 사용자의 요구 사항을 알 수 있습니다.

ALB는 이 HTTP 헤더를 라우팅 규칙에 활용하게 되는데 그중에서도 요청 헤더와 일반 헤더를 활용합니다. 요청 헤더를 이루는 주요 항목은 'Host Header(규칙 중 '호스트 헤더' 해당)', 'Cookie Header', 'User-agent Header', 'Accept Header' 등으로 사용자의 상태 정보나 사용자가 사용하는 디바이스의 정보를 담을 수 있습니다. 그리고 일반 헤더에 속하는 대표적인 헤더는 'X-Forwarded-For'로 사용자의 IP를 헤더에 담아 서버에게 전달합니다.

두 번째는 HTTP 요청 메서드입니다. 요청 메서드는 사용자가 웹서버에게 자신의 요청 목적 혹은 요청 종류를 알리는 수단으로 GET, HEAD, POST, PUT 등이 있습니다. ALB는 이 요청 메서드를 기준으로 규칙을 생성하여 각 규칙에 맞는 적절한 대상그룹으로 라우팅을 실시할 수 있습니다. 

SSL 인증서 탑재 가능

사용자와 서버가 HTTPS를 이용하여 암호화 통신을 하고자 할 경우, SSL 인증서를 이용한 인증, SSL Handshake를 통한 협상을 통해 암호화된 메시지를 전달해야 합니다. 그리고 그 작업은 리소스 소모가 크기 때문에 서버에 큰 부담이 됩니다. 그리하여 On-premise에서는 L4 스위치를 그 작업을 대행하여 사용자와의 암호화 통신을 실시하고 L4 스위치와 서버는 평문 통신을 하지요. 이를 SSL Offload라고 합니다.

ALB 또한 그러한 기능을 보유하고 있습니다. 사용자와 EC2 인스턴스가 암호화 통신을 해야 하는 경우, EC2 인스턴스의 부담을 줄이기 위해 ALB가 대신하여 SSL 인증서를 이용해 암호화 통신을 실시합니다. 물론 이를 실현하기 위해서는 사전작업으로 Route 53를 통해 자신이 사용할 도메인을 발급받는 일과 AWS의 SSL 인증서 발급 서비스인 ACM(AWS Certificate Manager)를 통해 SSL 인증서를 발급받는 일이 필요합니다.

프록시 서버로서의 역할

프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킵니다.

실질적으로 서비스를 제공하는 것은 서버이지만 사용자와 통신하는 것은 ALB입니다. 즉 사용자는 ALB와 통신하며 서버도 ALB와 통신하지요. ALB가 중간에 서서 프록시 서버로서 양쪽과 통신하는 것입니다. ALB가 어떻게 프록시 서버로서 작동하는지는 Traffic Flow(이하 트래픽 플로우)를 통해서도 확인할 수 있습니다. 아래 그림을 통해 살펴볼까요? 아래 그림에는 ALB(Internet Load Balancer)와 ALB에 연결된 대상그룹 내 2개의 EC2 인스턴스(Web Server)가 있습니다. 

AWS Web Aplication Firewall(WAF) 연동

AWS WAF는 AWS의 웹 애플리케이션 방화벽 서비스로, 웹서버로 유입되는 트래픽을 검사하여 공격을 차단하고 내부 리소스를 보호하는 역할을 하는 서비스입니다. AWS WAF는 ALB, Cloudfront, API Gateway에 적용 가능한데요, 3가지 서비스 모두 웹과 관련된 서비스임을 볼 때 서비스의 존재 목적을 알 수 있습니다.  

 

 

출처 https://aws-hyoh.tistory.com/134