Application Load Balancer의 구성 요소
ALB에는 크게 3가지 요소가 있습니다. 먼저 사용자에게서 요청을 받아들여 이 요청을 처리할 적절한 대상그룹으로 전달하는 리스너, 어느 대상그룹에 전달할지 판단하는 기준이 되는 규칙, 마지막으로 요청을 처리할 EC2가 모여 있는 대상그룹입니다.
위의 그림은 ALB를 도식화한 그림입니다. 로드밸런서 아래 다수의리스너,규칙,대상그룹, `헬스 체크가 있는 것을 확인할 수 있습니다. 하나의 ALB는 여러개의 리스너를 거느릴 수 있고, 리스너 안에 다수의 규칙을 보유할 수 있으며 하나의 리스너는 여러 대상 그룹을 거느릴 수 있음을 알 수 있습니다.
리스너
ALB의 리스너는 HTTP와 HTTPS에 해당하는 요청을 받아들이며, HTTP 관련 정보를 해석할 수 있습니다. 그 정보를 기반으로 어느 대상그룹에 요청을 전달할 것인지 규칙을 세우고 라우팅을 실시합니다. 그렇기에 HTTP / HTTPS 리스너는 공통적으로 자신의 이름에 해당하는 리스너 ID, 대상그룹에 사용자의 요청을 건네줄 판단 기준이 되는 규칙을 보유합니다. 또한 ALB의 HTTPS 리스너는 암호화된 HTTP 요청을 받아들여 수행하기 때문에 이를 충족하기 위해 자신의 신원을 보증해 줄 SSL 인증서와 주고받을 데이터의 암호화 방안인 보안 정책을 추가로 보유합니다. 즉 HTTPS 리스너를 사용하기 위해서는 SSL 인증서는 필수임을 의미합니다.
HTTP 리스너의 포트는 기본적으로 80이며 HTTPS 리스너의 포트는 기본적으로 443입니다. ALB의 리스너가 사용 가능한 포트 범위는 1 ~ 65535이기 때문에 HTTP/HTTPS 리스너 또한 포트 번호를 변경할 수 있습니다. HTTPS 리스너는 기본 포트인 443을 사용하지만 HTTP 리스너는 '80'번 포트가 이미 사용중이라면 '8080' 및 '8888'을 쓰는 방식으로 새로운 HTTP 리스너를 생성하여 사용할 수도 있습니다.
규칙
규칙은 사용자의 요청을 받은 리스너가 헤더에 담긴 HTTP 관련 정보를 해석한 뒤 그 정보를 기반으로 어느 대상그룹에 전달할지 판단하는 기준이 되는 요소입니다. 규칙은 규칙 조건과 규칙 작업으로 나뉩니다. 사용자의 요청을 전달받은 규칙 조건에 대조해보고 적합한 규칙에 연결된 규칙 작업을 실시합니다. IF에 해당하는 부분이 규칙 조건이며 THEN에 해당하는 부분이 규칙 작업입니다. 이러한 규칙은 몇 가지 특징을 지닙니다.
- 첫 번째, 규칙이 여러 개 존재하면 가장 상단의 규칙부터 순서대로 한 개씩 비교합니다.
- 두 번째, 규칙 조건
(IF)은 여러 개(최대 5개)가 포함될 수 있으며 모든 규칙 조건을 충족시켜야 합니다.- 세 번째, 규칙 작업
(THEN)은 규칙 조건을 충족한 요청을 처리하기 위한 라우팅 작업이며 3가지 작업이 존재합니다.전달 대상,리디렉션 대상,고정 응답 반환3가지가 있습니다.
규칙 작업 (전달 대상)
전달 대상은 EC2로 이루어진 그룹인 대상그룹으로 전달하는 것을 의미합니다. 즉 대상그룹을 지정하여 사용자의 요청을 보내는 것을 의미합니다. 또한 하나의 리스너에 여러 개의 대상그룹을 지정할 수 있으며 각 대상그룹의 요청 처리 비중을 정할 수 있습니다.
규칙 작업 (리디렉션 대상)
리디렉션 대상은 사용자의 요청을 또 다른 URL로 전달하는 것을 의미합니다. 예를 들어 사용자가 HTTP 리스너에 접속하고 입력한 URL이 ec2.aws.com일 경우 www.naver.com로 연결하여 네이버 웹페이지를 띄워야 한다면 다음과 같이 설정할 수 있습니다. 아래 그림에서는 규칙 조건에 맞다면 리디렉션 대상을 https://www.naver.com으로 지정하여 영구 (응답 코드 301) 혹은 임시 (응답 코드 302)로 리디렉션할 수 있으며 경로와 쿼리까지 지정할 수 있습니다.
규칙 작업 (고정 응답 반환)
고정 응답 반환은 대상그룹으로 전달하거나 리디렉션하는 것이 아닌 사용자가 정한 html, css, javascript, json 등 형식의 웹페이지를 HTTP 응답 코드(2xx, 3xx, 4xx)와 함께 전달하는 것입니다. 사용자가 원하는 방식의 콘텐츠 유형과 응답 코드를 자유롭게 설정할 수 있어 매우 편리합니다. 아래 그림은 200 OK 응답 코드와 함께 평문을 사용자에게 전달합니다.
고정 응답 반환은 잘못된 경로로 진입한 사용자에게 주의 메시지를 전달하거나 장애 혹은 사용자 폭주로 일시적으로 서비스가 마비되었을 경우 고정 응답 반환을 이용해 사용자에게 공지할 수 있습니다.
대상 그룹 (Target Group)
대상그룹은 사용자의 요청을 처리할 EC2의 집합입니다. '전달 대상'에 포함된 대상그룹이 리스너에게 요청을 전달받아 작업을 실시합니다. ALB 대상그룹의 특징은 기본 설정(Basic Configuration)과 헬스 체크(Health Check)에서 드러납니다. ALB의 대상그룹이기에 'Protocol: Port'는 HTTP 혹은 HTTPS를 사용합니다. 이는 이 대상그룹에 소속된 EC2들이 설정된 'Protocol: Port'만 받는다는 것을 의미합니다. 대상그룹의 프로토콜과 포트를 정의하는 것이죠. 예를 들어 HTTP:80으로 설정하면 이 대상그룹에 소속된 EC2 들은 80 포트로 설정된 요청만을 받아들인다는 의미가 됩니다. 물론 리스너의 포트번호(8080)와 대상그룹의 포트번호(80)를 다르게 설정할 수 있으며 리스너에서 대상그룹으로 요청이 전달될 때 포트번호가 변경됩니다.
헬스 체크는 대상그룹에 소속된 EC2들의 상태를 점검할 때 HTTP 혹은 HTTPS를 사용하겠다는 것을 의미합니다. HTTP를 사용하기 때문에 3-way handshake를 통한 상태 체크에서 끝나지 않고 사용자가 원하는 웹페이지를 요청하여 상태 체크를 실시할 수 있고 경로 또한 지정할 수 있습니다.
모니터링 역시 HTTP에 대한 항목이 포함되어 있습니다. HTTP 2xx, 3xx, 4xx 응답 코드에 대한 모니터링을 제공하는 것이 특징입니다. HTTP를 지원하는 ALB의 대상그룹이기에 가능한 것입니다.
Application Load Balancer의 주요 라우팅 규칙
ALB의 라우팅 규칙은 위에서 설명한 규칙, 사용자가 전달한 요청을 어느 대상그룹에 전달할 것인가를 판단하는 것으로 규칙 작업에 전달하는 기준이 됩니다. ALB는 HTTP 헤더를 활용할 수 있는 로드밸런서이기에 매우 다양합니다. 그중에서 HTTP 헤더 활용에 해당하는 호스트 헤더, 경로 HTTP 헤더, HTTP 요청 메서드 등의 사용에 대해 설명하고자 합니다.
호스트 헤더
호스트 헤더는 HTTP 헤더 중 하나인 호스트 헤더(도메인 네임)를 기준으로 삼아 라우팅을 결정하는 규칙입니다. 사용자가 입력한 도메인 네임을 읽고 정확히 일치하는 규칙을 결정합니다.
경로 (Path)
경로(Path)는 호스트가 제공하는 자원이 존재하는 위치를 뜻합니다. 사용자가 도메인 네임과 함께 경로를 입력하면 리스너는 그 경로를 읽고 규칙 조건으로 삼을 수 있습니다.
HTTP 헤더
HTTP 헤더는 위에서 봤던 호스트 헤더와 경로를 포함한 모든 HTTP 헤더를 의미합니다. 즉 사용자가 원하는 공통 헤더 혹은 요청 헤더를 골라 지정하여 라우팅 규칙으로 삼을 수 있습니다.
HTTP 요청 메서드
HTTP 요청 메서드는 사용자가 서버에게 자신의 요청 목적 혹은 종류를 알리는 수단을 의미합니다. 종류에는
GET,POST,HEAD,PUT,DELETE등이 있습니다. 예를 들어GET메서드는 서버의 리소스 전달을 요청하는 메서드이고HEAD메서드는 메시지 헤더, 문서 정보를 요청하는 메서드입니다. 이처럼 요청 메서드를 규칙 조건으로 삼아 규칙 작업을 실시할 수 있습니다. 또한 사용자가 만든 사용자 정의 메서드도 여기에 포함시킬 수 있습니다. HTTP 요청 메서드를 이용해 라우팅을 실시한다는 점에서AWS API Gateway를 연상케하는 기능입니다.
Application Load Balancer의 기타 기능
Connection Timeout (유휴 제한 시간)
Connection Timeout(이하 유휴 제한 시간)은 사용자의 요청으로 생성된 사용자와 서버 간의 커넥션이 유지되는 시간을 뜻합니다. ALB의 기본 유휴 제한 시간은 60초로 지정되어 있습니다. 60초가 지날 때까지 커넥션이 사용되지 않는다면 ALB가 보유하고 있는 사용자와 서버 간의 연결을 끊습니다.
사용자가 요청한 리소스를 서버가 모두 전달하면 사용중인 커넥션을 닫는 HTTP의 특성상, 60초는 짧은 시간이 아닙니다. HTTP/1.1의 고질적인 문제점인Head of line blocking을 겪지 않을 충분한 시간입니다.
Sticky
Sticky는 사용자가 한 번 접속한 적이 있는 서버를 기억해두고 커넥션이 사라진 상태에서 사용자가 다시 접속하더라도 기존 커넥션이 있었던 서버로 연결해주는 기능입니다. ALB 역시 로드밸런서이기에 이 기능을 지원하며 Cookie(이하 쿠키)를 이용하여 스티키를 지원합니다.
사용자가 ALB에 요청을 전달하고 EC2가 응답을 보낼 때 ALB가 쿠키를 응답 헤더에 쿠키를 포함시켜 사용자에게 전달합니다. 그리고 사용자는 ALB에 요청을 재차 전달할 때마다 해당 쿠키를 동봉하여 전달하고 ALB는 커넥션이 생성되었던 대상그룹의 EC2를 기억하고 다시 연결합니다. 스티키 유지 시간은 1초에서 7일까지 다양하게 설정할 수 있습니다.
원래 ALB가 생성하는 쿠키만이 스티키에 사용되었으나 21년 2월 업데이트에서 사용자 정의 쿠키도 사용할 수 있도록 기능이 추가되었습니다. Application-based cookie가 바로 그것입니다.
스티키를 사용하기 위해서는 해당 대상 그룹이 연결된 리스너에서 그룹 수준 고정(Group-level stickiness)을 활성화시켜야 합니다.
X-Forwarded-For
X-Forwarded-For는 HTTP 헤더 중 하나로 요청을 전달한 사용자의 IP를 담고 있는 헤더입니다. 그 밖에도 프로토콜을 알려주는X-Forwarded-Proto, 포트를 알려주는X-Forwarded-Port도 있습니다. ALB는 사용자의 요청을 대상그룹으로 전달할 때 기본적으로 X-Forwarded-For 헤더를 탑재하여 전달하게 됩니다.
X-Forwarded-For 헤더가 필요한 이유는 바로 ALB가 사용자의 요청을 EC2로 전달할 때 자신의 사설 IP로 Source IP NAT를 실시하기 때문입니다. 즉 EC2로 요청이 전달될 때에는 사용자의 IP가 아닌 ALB의 IP가 Source IP로 보이기 때문에 실제 사용자의 IP를 EC2가 알 길이 없습니다. 그리하여 X-Forwarded-For 헤더를 사용하여 사용자 IP를 전달하는 것입니다. 그리하면 해당 헤더를 통해 사용자 IP를 구별할 수 있게 됩니다.
HTTP/2
HTTP/2는 월드 와이드 웹에서 쓰이는 HTTP 프로토콜의 두 번째 버전이다. 웹 브라우저의 페이지 로드 속도 개선을 목적으로 개발되었다.
다음과 같은 방법들을 이용하여 지연 시간을 감소시켜 웹 브라우저의 페이지 로드 속도를 개선하였다.
- HTTP 헤더 데이터 압축
- 서버 푸시 기술
- 요청을 HTTP 파이프라인으로 처리
- HTTP 1.x의 HOL blocking 문제 해결
- TCP 연결 하나로 여러 요청을 다중화 처리
HTTP/2는 HTTP의 두 번째 버전으로 현재 가장 많이 사용하고 있는 HTTP/1.1의 다음 버전입니다. HTTP/1.1이 가지고 있는 문제점들을 해결하기 위해 탄생하였습니다. Head of line blocking 문제가 해결된 버전이 바로 'HTTP/2'입니다.
ALB 또한 속도 향상을 위해 기본적으로 HTTP/2이 활성화 되어있습니다. HTTP/2 활용을 위해서는 로드밸런서뿐만 아니라, 대상그룹에서도 '요청 프로토콜'을 설정해야 합니다. 'HTTP2'를 설정해야 HTTP/2를 사용하여 대상으로 요청을 전송합니다. 로드밸런서에서 HTTP/2를 지원한다고 하더라도 대상그룹의 프로토콜 버전이 'HTTP1'로 설정되어 있다면 HTTP/1을 사용하여 요청을 전송하게 됩니다. 물론 서버도 HTTP/2를 지원해야 합니다.
