애플리케이션 계층
HTTP, FTP, DHCP, SMTP, DNS 등은 사용자가 UI를 통해 접하는 애플리케이션과 관련된 계층입니다.
이 범주에 속하는 프로토콜은 어떤 방식으로든 사용자와 직접 접촉하게 됩니다.
애플리케이션 계층7개의 OSI 계층 중 최상위 계층에 해당하는 계층입니다.
위에서 설명한 것처럼 사용자에게 직접 닿는 레이어입니다.
이 블로그에 액세스하는 데 도움이 되는 브라우저와 이 브라우저에서 사용하는 프로토콜도 애플리케이션 계층에 해당하는 HTTP입니다.
응용 계층에는 HTTP 외에도 FTP, DNS 및 DHCP와 같은 다양한 프로토콜이 있습니다.
이러한 각 프로토콜은 사용자의 직접적인 영향을 받습니다.
Application Load Balancer(ALB)란 무엇입니까?
Application Load Balancer는 OSI(Open Systems Interconnection) 모델의 일곱 번째 계층인 애플리케이션 계층에서 작동합니다.
로드 밸런서는 요청을 받으면 우선 순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음 규칙 작업의 대상 그룹에서 대상을 선택합니다.
수많은 프로토콜의 프로파일이 적용된 L7 가상 서버를 사용하는 L4 스위치와 달리 HTTP, HTTPS 및 WebSocket가장 큰 특징은 . 다음 그림은 로드 밸런서 선택 화면을 보여줍니다.
빨간 상자알바입니다.
HTTP 및 HTTPS 트래픽을 사용하는 웹 애플리케이션용 로드 밸런서입니다.
그래서 ALB는 사용자 요청은 HTTP 헤더 및 요청 방법(로드 밸런싱)을 사용하여 적절한 대상에게 라우팅될 수 있으며 규칙의 우선 순위를 지정하고 순차적으로 적용할 수 있습니다.
아래 이미지에서 사용 가능한 ALB는 ‘규칙‘(라우팅을 평가하는 기준)이며, 각 요소를 살펴보면 HTTP의 속성을 사용하고 있음을 알 수 있습니다.
물론 HTTP도 TCP 기반 프로토콜이기 때문에 ALB는 연결을 설정하기 위해 라우팅하기 전에 3방향 핸드셰이크를 수행해야 합니다.
7계층 로드밸런서는 4계층(TCP, UDP)을 무시하지 않고 4계층의 프로토콜(protocol)을 충분히 만족시킨 후 HTTP를 통한 라우팅을 구현합니다.
OSI 7계층에 대해 잘 이해하고 있다면 이는 명백합니다.
Application Load Balancer의 주요 기능
HTTP를 통한 라우팅(로드 밸런싱)
위에서 언급했듯이 ALB의 가장 큰 특징은 HTTP의 속성을 활용한다는 것입니다.
처음에는 ‘HTTP 헤더HTTP 헤더에는 표준 헤더, 요청 헤더, 응답 헤더 및 일반 헤더가 포함됩니다.
요청 및 응답 상황에 따라 다른 정보를 포함하는 헤더가 있는 다른 헤더가 있습니다.
또한 사용자는 자신의 정보를 헤더에 넣어 서버로 보낼 수 있으며, 서버는 헤더에 포함된 정보를 보고 사용자의 요청을 인지할 수 있다.
ALB는 다음을 포함하여 라우팅 규칙에서 이 HTTP 헤더를 사용합니다.
요청 헤더그리고 일반 제목활용. 요청 헤더를 구성하는 주요 요소는 ‘호스트 헤더(규칙의 ‘호스트 헤더’와 동일)‘, ‘Cookie Header’, ‘User-agent Header’, ‘Accept Header’ 등은 사용자 상태 정보 또는 사용자가 사용하는 장치 정보를 포함할 수 있습니다.
그리고 일반 헤더에 속하는 대표적인 헤더는 “X-Forwarded-For” 헤더에 사용자의 IP를 담고 서버로 전달하는 헤더이다.
두 번째는 HTTP 요청 방법보지마. 요청 방식은 사용자가 요청의 목적이나 성격을 웹 서버에 알리는 수단으로 GET, HEAD, POST, PUT 등이 있다.
ALB는 이 요청 방법을 기반으로 규칙을 생성하고 각 규칙에 대해 적절한 대상 그룹에 전달할 수 있습니다.
SSL 인증서 탑재 가능
사용자와 서버가 암호화된 통신을 위해 HTTPS를 사용하려면, SSL 인증서암호화된 메시지는 SSL 핸드셰이크를 통한 인증 및 협상을 통해 전송되어야 합니다.
그리고 이 작업은 많은 리소스를 소비하기 때문에 서버에 많은 부하를 줍니다.
따라서 현장에서는 L4 스위치가 사용자와의 암호화된 통신을 위한 에이전트 역할을 하고 L4 스위치와 서버는 일반 텍스트 통신을 수행합니다.
그만큼 SSL 오프로드말하다.
ALB에도 그런 기능이 있습니다.
사용자와 EC2 인스턴스 간에 암호화된 통신이 필요한 경우 ALB는 SSL 인증서를 사용하여 EC2 인스턴스를 대신하여 암호화된 통신을 수행하여 EC2 인스턴스의 부하를 줄입니다.
물론 이를 실현하기 위해서는 사전 작업으로 Route 53을 통해 사용할 도메인을 확보하고 AWS에서 제공하는 SSL 인증서 발급 서비스인 ACM(AWS Certificate Manager)을 통해 SSL 인증서를 받아야 합니다.
프록시 서버 역할
프록시 서버는 클라이언트가 다른 네트워크 서비스에 간접적으로 액세스할 수 있도록 하는 컴퓨터 시스템 또는 응용 프로그램입니다.
실제로 서비스를 제공하는 것은 서버이지만 사용자와 통신하는 것은 ALB입니다.
즉, 사용자는 ALB와 통신하고 서버는 ALB와 통신합니다.
ALB가 중간에 서 있습니다.
프록시 서버양측과 소통하기 위해. ALB가 프록시 서버로 작동하는 방식은 트래픽 흐름을 통해서도 볼 수 있습니다.
아래 이미지를 살펴보자. 아래에 이 그림은 ALB(Internet Load Balancer)와 ALB에 연결된 대상 그룹의 두 EC2 인스턴스(웹 서버)를 보여줍니다.
AWS 웹 애플리케이션 방화벽(WAF)과 통합
AWS WAF는 공격을 차단하고 내부 리소스를 보호하기 위해 웹 서버로 들어오는 트래픽을 검사하는 AWS의 웹 애플리케이션 방화벽 서비스입니다.
AWS WAF는 ALB, Cloudfront, API Gateway에 적용할 수 있으며, 세 가지 서비스 모두 인터넷과 관련되어 있어 서비스의 목적을 이해할 수 있습니다.