Application Layer / 응용 계층
사용자가 UI로 접하는 응용 프로그램과 관련된 계층으로 HTTP, FTP, DHCP, SMTP, DNS등이 있습니다. 여기에 속한 프로토콜들은 어떠한 방법으로든 사용자와 직접 접하게 됩니다.
Application Layer는 OSI 7 Layer 중 최상단 계층에 해당하는 Layer입니다. 위 설명처럼 사용자와 직접 접하는 계층입니다. Application Layer에는 HTTP 뿐만 아니라 FTP, DNS, DHCP 등 다양한 프로토콜이 존재합니다. 각각의 프로토콜들 모두 사용자가 직접 영향을 받는 프로토콜입니다. Application Layer에 속하는 프로토콜의 종류는 매우 많습니다. F5 Networks L4 스위치의 L7 Virtual Server의 성격(프로토콜)을 정의하는 Profile 항목을 보면 더욱 확실히 알 수 있습니다.
Profile항목에는HTTP,HTTP Compression,Web Acceleration,FTP,TFTP,DNS,RTSP,ICAP,Request Adapt,Response Adapt,Diameter,DHCPv4,DHCPv6,RADIUS,SIP,SMTP,SMTPS,Client LDAP,Server LDAP,iSession,Access,Connectivity,Rewrite,XML,HTTP/2,SPDY,SOCKS,FIX,GTP,WebSocket등이 있습니다.
어느 Profile을 적용하느냐에 따라 Virtual Server의 기능이 달라지는데 L7 Virtual Server인 만큼 Application Layer의 Protocol을 지정할 수 있습니다. Profile이 많다는 것은 Layer 7의 프로토콜이 많다는 것을 의미합니다. 저 수많은 Profile 중의 하나를 선택하면 L7 Virtual Server는 선택된 Profile(프로토콜)의 기능을 수행하게 됩니다. 즉 Application Layer를 다루는 로드밸런서라 함은 저 프로토콜들을 다룰 수 있는 로드밸런서라고 할 수 있습니다.
Application Load Balancer (ALB)란 ?
Application Load Balancer는 개방형 시스템 간 상호 연결(OSI) 모델의 일곱 번째 계층인 애플리케이션 계층에서 작동합니다. 로드 밸런서는 요청을 받으면 우선순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음, 규칙 작업의 대상 그룹에서 대상을 선택합니다.
Application Load Balancer(이하 ALB)는 AWS에서 제공하는 4가지 로드밸런서 중 하나로 OSI 7 Layer에서 일곱 번째 계층에 해당하는 Application Layer를 다루는 로드밸런서입니다. 왜 이름이 Application Load Balancer인지 감이 오시나요? 그렇지만 위에서 설명했던 수많은 프로토콜의 Profile이 적용되는 L7 Virtual Server를 사용하는 L4 스위치와는 달리 HTTP와 HTTPS, WebSocket을 활용하는 로드밸런서라는 것이 가장 큰 특징입니다.
그렇기에 ALB는 HTTP의 Header, 요청 Method 등을 이용해 사용자의 요청을 적절한 대상그룹으로 라우팅(부하분산) 할 수 있으며 규칙에 우선순위를 두고 차례대로 적용할 수 있습니다.
물론 HTTP 또한 TCP 기반의 프로토콜이기 때문에 ALB는 라우팅 실시 이전에 커넥션 생성을 위한 3-way handshake를 실시해야 합니다. Layer 7의 로드밸런서라고 해서 Layer 4(TCP, UDP)를 무시하는 것이 아니라 Layer 4의 규약(프로토콜)을 충분히 이행한 후 HTTP를 이용한 라우팅을 실시하는 것입니다. OSI 7 Layer에 대해 제대로 이해하고 있다면 이는 당연한 것입니다.
위의 내용을 종합해보면 Application Laod Balancer는 TCP를 기반으로 하는
HTTP,HTTPS,WebSocket등을 활용하며, HTTP의 주요 특징인 HTTP Header, Host Header, 요청 메서드 등에 기준을 적용하여 기준에 맞는 적절한 대상그룹으로 라우팅 할 수 있는 로드밸런서입니다.
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는 이 요청 메서드를 기준으로 규칙을 생성하여 각 규칙에 맞는 적절한 대상그룹으로 라우팅을 실시할 수 있습니다.
그 밖의 라우팅 규칙으로 요청 경로에 따라 다른 대상 그룹으로 라우팅을 실시하는 경로, 사용자의 IP에 따라 다른 대상그룹으로 라우팅을 실시하는 소스 IP, 쿼리 문자열의 Parameter를 기준으로 라우팅을 실시하는 쿼리 문자열이 있습니다.
로드밸런싱(부하 분산) 방식
규칙에 의해 라우팅이 결정된 대상 그룹 내 EC2 인스턴스에 부하 분산을 실시할 때의 알고리즘을 뜻합니다. 기본 알고리즘은 Round Robin(이하 라운드 로빈)으로 요청을 EC2 인스턴스에 순서대로 할당합니다. 그럼 요청이 고르게 분산되겠죠. 하지만 매번 그렇지는 않습니다. 일부의 EC2 인스턴스에 할당된 요청의 작업이 오래 걸려 아직 끝마치지 못한 상태에서 지속적으로 요청이 유입된다면 균형이 깨질 가능성이 있습니다.
그 문제를 해결하기 위한 방식이 존재하며 그것은 라운드 로빈의 아래 항목인 Least Outstanding Requests입니다. 처리되지 않은 요청을 가장 적게 가지고 있는 EC2 인스턴스에게 할당하는 방식입니다. 즉 요청을 처리할 여유가 가장 많은 EC2 인스턴스 혹은 처리 능력이 비교적 더 우수한 EC2 인스턴스에게 전달하는 방식입니다. ALB와 EC2 간 생성된 커넥션 개수를 기준으로 커넥션 수가 가장 적은 EC2에 전달하는 게 아닌가 싶습니다.
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 인증서를 발급받는 일이 필요합니다.
✅ Tip
AWS에서 Certificate Manager에서 SSL 인증서를 발급받을 때 지역이 서울일 경우, 레코드를 생성하지 않으면 발급이 상당히 지연돼서 레코드 생성 없이 버지니아 북부에서 ACM을 발급받으면 늦어도 5분 이내로 발급 받을 수 있습니다. 또한 ACM을 발급 받기 위해서는 도메인을 가지고 있어야 합니다.
✅ region 서울의 경우 꼭 레코드를 생성해야지만 발급이 진행됩니다 !
도메인과 SSL 인증서가 다 준비되었다면 이를 ALB에 적용하기만 하면 됩니다. 리스너에서 서비스 포트의 프로토콜을 443으로 변경하면 하단에 보안 정책과 SSL 인증서가 나타납니다. 보안 정책을 통해 사용하고자 하는 Cipher Suite와 SSL 인증서를 선택하고 편집을 완료하면 됩니다. 마지막으로 대상그룹의 EC2 인스턴스들의 포트를 80으로 설정해햐 합니다. HTTPS 통신(Port 443)은 ALB가 하므로 EC2 인스턴스는 평문 통신만 하면 되기 때문에 대상그룹의 EC2 인스턴스 포트는 80으로 설정되어야 합니다.
Cipher Suite는 사용자와 ALB가 사용할 암호화 통신 프로토콜에 대해 협상하는 것으로 중요한 항목입니다.
프록시 서버로서의 역할
프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 가리킵니다.
실질적으로 서비스를 제공하는 것은 서버이지만 사용자와 통신하는 것은 ALB입니다. 즉 사용자는 ALB와 통신하며 서버도 ALB와 통신하죠. ALB가 중간에 서서 프록시 서버로서 양쪽과 통신하는 것입니다. ALB가 어떻게 프록시 서버로 작동하는지는 Traffic Flow(이하 트래픽 플로우)를 통해서도 확인할 수 있습니다. 아래 그림에는 ALB(Internet Load Balancer)와 ALB에 연결된 대상그룹 내 2개의 인스턴스 (Web Server)가 있습니다.
저는 웹서비스에 접속하기 위해 브라우저를 켜고 인터넷을 통해 ALB에 접속합니다. 그리고 3-way Handshake를 실시합니다. ALB는 프록시 서버로서 동작하기 때문에 3-way Handshake를 위한 과정을 서버에 넘기지 않고 자신과 사용자의 3-way Handshake를 먼저 실시합니다. ALB 자신과 우선적으로 협상하지 않으면 서버에게 넘기지 않겠다는 뜻입니다.
- 사용자와 ALB의 3-way handshake 실시
- ALB와 EC2 인스턴스의 3-way handshake 실시
- 사용자가 요청을 ALB에 전달하면 ALB가 이를 EC2 인스턴스에 전달
AWS Web Application Firewall(WAF) 연동
AWS WAF는 Amazone CloudFront 배포, Amazon API Gateway REST API, Application Load Balancer 또는 AWS AppSync GraphQL API에 전달되는 HTTP(S) 요청을 모니터링할 수 있게 해주는 웹 애플리케이션 방화벽입니다.
AWS WAF는 AWS의 웹 애플리케이션 방화벽 서비스로, 웹서버로 유입되는 트래픽을 검사하여 공격을 차단하고 내부 리소스를 보호하는 역할을 하는 서비스입니다. AWS WAF는 ALB, Cloudfront, API Gateway에 적용 가능합니다. 3가지 서비스 모두 웹과 관련된 서비스임을 볼 때 서비스의 존재 목적을 알 수 있습니다.
ALB는 HTTP를 위한 로드밸런서이므로 웹 관련 공격에서 자유로울 수 없습니다. 그렇기에 AWS WAF를 연결하여 ALB로 유입되는 웹 공격으로부터 EC2 인스턴스들을 보호할 수 있습니다.
