AWS Application Load Balancer 쉽게 이해하기 #1

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

출처: OSI 7 Layer 쉽게 이해하기
 [네트워크 엔지니어 환영의 AWS 기술블로그]

Application Layer는 OSI 7 Layer 중 최상단 계층에 해당하는 Layer입니다. 위 설명처럼 사용자와 직접 접하는 계층이죠. 여러분이 이 블로그를 접속할 수 있도록 도와주는 브라우저, 그 브라우저가 사용하는 프로토콜 역시 Application Layer에 해당하는 HTTP입니다. Application Layer에는 HTTP뿐만 아니라 FTP, DNS, DHCP 등 다양한 프로토콜이 존재합니다. 각각의 프로토콜들 모두 사용자가 직접 영향을 받는 프로토콜이죠. Application Layer에 속하는 프로토콜의 종류는 매우 많습니다. F5 Networks L4 스위치의 L7 Virtual Server의 성격(프로토콜)을 정의하는 'Profile'을 항목을 보면 더욱 확실히 알 수 있죠.

<F5 Networks의 L7 Virtual Server Profile>

위 그림은 L7 Virtual Server(Standard Type)의 성격(프로토콜)을 정의하는 'Profile' 목록입니다. 어느 Profile을 적용하느냐에 따라 Virtual Server의 기능이 달라지는데 L7 Virtual Server인 만큼 Application Layer의 Protocol을 지정할 수 있습니다. 종류가 매우 많죠? HTTP뿐만 아니라 FTP, DNS, SIP, WebScoket도 보입니다. Profile이 많다는 것은 Layer 7의 프로토콜이 많다는 것을 의미합니다. 저 수많은 Profile 중의 하나를 선택하면 L7 Virtual Server는 선택된 Profile(프로토콜)의 기능을 수행하게 됩니다. 즉 Application Layer를 다루는 로드밸런서라 함은 저 프로토콜들을 다룰 수 있는 로드밸런서라 할 수 있습니다.

 

Application Load Balancer(ALB)란?

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

- 출처 : AWS 설명서 -

<Application Load Balancer(출처 : AWS 한국 블로그)>

Application Load Balancer(이하 ALB)는 AWS에서 제공하는 4가지 로드밸런서 중 하나로 OSI 7 Layer에서 일곱 번째 계층에 해당하는 Application Layer를 다루는 로드밸런서입니다. 왜 이름이 Application Load Balancer인지 감이 오시지요? 그렇지만 위에서 설명했던 수많은 프로토콜의 Profile이 적용되는 L7 Virtual Server를 사용하는 L4 스위치와는 달리 HTTP와 HTTPS, WebSocket을 활용하는 로드밸런서라는 것이 가장 큰 특징입니다. 아래 그림은 로드밸런서의 선택 화면인데요, 빨간색 박스가 ALB입니다. HTTP와 HTTPS 트래픽을 사용하는 웹 애플리케이션을 위한 로드밸런서임을 설명하고 있죠.

<Application Load Balancer 선택화면>

(설정 화면 : EC2 서비스 - 로드밸런서 - 로드밸런서 생성)

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

<ALB를 통해 사용 가능한 라우팅(부하분산) 방법>

(설정 화면 : EC2 서비스 - 로드밸런서 - 리스너 - 규칙 - ALB 규칙 보기/편집 - '+' 버튼 - 규칙 삽입)

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

위의 내용을 종합해보면 Application Load Balancer는 TCP를 기반으로 하는 HTTP, HTTPS, WebSocket 등을 활용하며, HTTP의 주요 특징인 HTTP Header, Host Header, 요청 메서드 등에 기준을 적용하여 기준에 맞는 적절한 대상그룹으로 라우팅 할 수 있는 로드밸런서입니다. 그럼 이제 ALB의 특징에 대해 하나씩 살펴보도록 하겠습니다.

 

Application Load Balancer의 주요 특징

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

<ALB를 통해 사용 가능한 라우팅(부하분산) 방법>

위에서도 지속적으로 언급했지만 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는 이 요청 메서드를 기준으로 규칙을 생성하여 각 규칙에 맞는 적절한 대상그룹으로 라우팅을 실시할 수 있습니다. 

그 밖의 라우팅 규칙으로 요청 경로에 따라 다른 대상 그룹으로 라우팅을 실시하는 '경로', 사용자의 IP에 따라 다른 대상그룹으로 라우팅을 실시하는 '소스 IP', 쿼리 문자열의 Parameter를 기준으로 라우팅을 실시하는 '쿼리 문자열'이 있습니다.

 

로드밸런싱(부하 분산) 방식

<ALB의 부하 분산 방식>

(설정 화면 : EC2 서비스 - 로드밸런서 - 대상그룹 - 그룹 상세 - 속성 - 로드밸런싱 알고리즘)

규칙에 의해 라우팅이 결정된 대상 그룹 내 EC2 인스턴스에 부하 분산을 실시할 때의 알고리즘을 뜻합니다. 기본 알고리즘은 Round Robin(이하 라운드 로빈)으로 요청을 EC2 인스턴스에 순서대로 할당합니다. 그럼 요청이 고르게 분산되겠죠. 하지만 매번 그렇지는 않습니다. 일부의 EC2 인스턴스에 할당된 요청의 작업이 오래 걸려 아직 끝마치지 못한 상태에서 지속적으로 요청이 유입된다면 균형이 깨질 가능성이 있습니다.

그 문제를 해결하기 위한 방식이 존재하며 그것은 라운드 로빈의 아래 항목인 Least Outstanding Requests입니다. 처리되지 않은 요청을 가장 적게 가지고 있는 EC2 인스턴스에게 할당하는 방식입니다. 즉 요청을 처리할 여유가 가장 많은 EC2 인스턴스 혹은 처리 능력이 비교적 더 우수한 EC2 인스턴스에게 전달하는 방식이죠. 자세한 방식을 알 수는 없습니다만 ALB와 EC2간 생성된 커넥션 개수를 기준으로 커넥션 수가 가장 적은 EC2에 전달하는 게 아닌가 싶습니다. 서버 부하 분산 방식에 대해서는 서버 부하 분산 쉽게 이해하기를 참조하세요!

 

SSL 인증서 탑재 가능

HTTPS 통신과정 쉽게 이해하기 #1(우리는 구글에 어떻게 들어가는가)를 필두로 한 HTTPS 시리즈에서 SSL 암호화 / 복호화에 대한 이야기를 하였습니다. 클라이언트와 서버가 데이터를 어떻게 암호화하는지 복호화하는지에 대한 이야기였는데요. 요즘 대부분의 웹페이지가 HTTPS를 통해 제공되고 있기에 웹 서비스를 제공하는 서버라면 SSL 암호화 / 복호화는 필수적입니다.

출처: L4 스위치 쉽게 이해하기 7
 [네트워크 엔지니어 환영의 AWS 기술블로그]

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

<On-premise에서의 SSL Offload>

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

<SSL Offload를 위한 인증서 적용>

(설정 화면 : EC2 인스턴스 - 로드밸런서 - 리스너 - 리스너 편집)

도메인과 SSL 인증서가 다 준비되었다면 이를 ALB에 적용하기만 하면 됩니다. 리스너에서 서비스 포트의 프로토콜을 443으로 변경하면 아래 보안 정책과 SSL 인증서가 나타납니다. 보안 정책을 통해 사용하고자 하는 'Cipher Suite'와 SSL 인증서를 선택하고 편집을 완료하면 됩니다. (Cipher Suite는 사용자와 ALB가 사용할 암호화 통신 프로토콜에 대해 협상하는 것으로 중요한 항목입니다. 자세한 사항은 HTTPS 통신과정 쉽게 이해하기 #4(Cipher Suite, 암호문의 집합)을 확인하세요!). 마지막으로 대상그룹의 EC2 인스턴스들의 포트를 '80'으로 설정해야 합니다. HTTPS 통신(Port 443)은 ALB가 하므로 EC2 인스턴스는 평문 통신만 하면 되기 때문에 대상그룹의 EC2 인스턴스 포트는 '80'으로 설정되어야 하지요.

 

프록시 서버로서의 역할

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

- 출처 : 위키백과 -

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

<ALB와 EC2의 구성도>

저는 웹서비스에 접속하기 위해 브라우저를 켜고 인터넷을 통해 ALB에 접속합니다. 그리고 3-way handshake를 실시하겠지요. ALB는 프록시 서버로서 동작하기 때문에 3-way handshake를 위한 과정을 서버에 넘기지 않고 자신과 사용자의 3-way handshake를 먼저 실시합니다. ALB 자신과 우선적으로 협상하지 않으면 서버에게 넘기지 않겠다는 뜻이죠. 아래 그림을 보시면 사용자(192.168.0.11)와 ALB(13.124.250.163)가 3-way handshake을 실시한 것을 확인할 수 있습니다. 이것이 첫 번째 동작입니다.

(사용자가 사설 IP로 나타나는 이유는 공유기를 통해 인터넷으로 넘어가기 이전의 사설 네트워크에서 패킷을 캡처했기 때문입니다.)

<사용자와 ALB의 트래픽 플로우>

그리고 ALB(10.0.1.205, ip-10-0-1-205.ap-northeast-2.compute,internal.55746)는 자신이 부하 분산할 대상그룹과 EC2 인스턴스(10.0.0.68, ip-10-0-0-68.ap-northeast-2.compute.internal.http)를 정하겠죠. 그다음에 ALB는 VPC 내 자신의 사설 IP를 활용하여 EC2 인스턴스와 3-way handshake를 실시합니다. 이것이 두 번째 동작입니다. 아래 그림을 통해 확인하실 수 있습니다. 

([S]는 SYN Flag를, [S.]는 SYN/ACK Flag를, [.]는 ACK Flag를 의미합니다.)

<ALB와 EC2 인스턴스의 트래픽 플로우>

이 두 가지 동작이 끝난 후 사용자가 'GET' HTTP 요청 Method를 통해 ALB에게 웹페이지 전달을 요청합니다. 그리고 ALB는 서버에 요청하며, 서버는 이에 대한 응답을 사용자에게 전달합니다. 이를 종합해보면 다음과 같습니다.

1. 사용자와 ALB의 3-way handshake 실시
2. ALB와 EC2 인스턴스의 3-way handshake 실시
3. 사용자가 요청을 ALB에 전달하면 ALB가 이를 EC2 인스턴스에 전달

 

AWS Web Aplication Firewall(WAF) 연동

AWS WAF는 Amazon CloudFront 배포, Amazon API Gateway REST API, Application Load Balancer 또는 AWS AppSync GraphQL API에 전달되는 HTTP(S) 요청을 모니터링할 수 있게 해주는 웹 애플리케이션 방화벽입니다.

- 출처 : AWS WAF -

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

(출처 : https://blog.cloudthat.com)

ALB는 처음에 소개드렸듯이 HTTP를 위한 로드밸런서이므로 웹 관련 공격에서 자유로울 수 없습니다. 그렇기에 AWS WAF를 연결하여 ALB로 유입되는 웹 공격으로부터 EC2 인스턴스들을 보호할 수 있습니다.

Application Load Balancer의 소개와 특징에 대해 말씀드렸습니다. 다음 문서에서는 처음에 언급했던 ALB의 HTTP 활용, ALB의 구성 요소, 기타 기능에 대해 다루어보도록 하겠습니다. 감사합니다.