여러 시스템에서 다양한 HTTP 앱으로 라우팅 가능하며, 이런 시스템들은 목표 그룹으로 그룹화
동일한 시스템의 여러 애플리케이션에 대한 로드 밸런싱을 제공 예) 컨테이너와 ECS를 사용
HTTP/2와 WebSocket, 리디렉션 (HTTP → HTTPS) 도 지원
다른 목표 그룹에 기반하여 라우팅(라우팅 테이블)을 지원 예1) URL 대상경로(path)에 기반하여 라우팅 (example.com/users & example.com/posts) 예2) URL의 호스트명에 기반하여 라우팅 (one.example.com & other.example.com) 예3) 쿼리 스트링과 헤더에 기반하여 라우팅 (example.com/users?id=123&order=false)
ALB는 마이크로 서비스와 컨테이너 기반 앱을 가졌을 때 유용하며 포트 매팡 기능을 통해 ECS 인스턴스의 동적 포트로 리디렉션한 후, 다시 ECS 섹션에 직접 리디렉션 (ECS의 동적 포트로 리디렉션하는 포트 매핑 기능) 예) Docker와 Amazon ECS
앱 당 여러 CLB를 가지는 것과 달리, ALB는 많은 앱에 앞서 하나의 앱 로드 밸런서만 가질 수 있음
HTTP Based Traffic
외부 앱 로드 밸런서가 존재하고 그 뒤에는 EC2 인스턴스로 만들어진 첫 번째 목표 그룹이 존재하며 사용자 앱이 될 것이므로, 이는 Route /user를 위해 라우팅 두 번째 목표 그룹도 EC2 인스턴스로 만들어졌으며 검색 앱이 될 것이므로, Route /search를 위해 라우팅 → 같은 앱 로드 밸런서 뒤에서 URL에 사용되는 경로를 기반으로 목표 그룹에 지능적으로 라우팅하며, 상태 체크를 포함
Target Groups
EC2 인스턴스 (Auto Scaling 그룹에서 관리 가능) – HTTP
ECS 작업 (ECS 자체에서 관리) – HTTP
Lambda 함수 – HTTP 요청이 JSON 이벤트로 변환됨
IP 주소 – 반드시 개인 IP여야 함
ALB는 다중 목표 그룹에 라우팅할 수 있고 상태 확인은 목표 그룹 레벨에서 수행
Query Strings/Parameters Routing
첫 번째의 경우 AWS의 EC2 인스턴스에 기반, 두 번째의 경우 데이터 센터 온프레미스의 사적 서버에 존재 목표 그룹에 대해 존재하기 위해서는 서버의 개인 IP를 목표 그룹에 지정하고 등록되도록 선택
ALB를 통해 요청 역할을 하는 앱이 있다고 가정할 때, 모바일 기반 트래픽은 첫 번째 목표 그룹에 데스트탑 기반 트래픽은 두 번째 목표 그룹에 보내길 원할 때, 쿼리 스트링이나 매개변수 라우팅을 사용하고 ALB 리디렉션 룰과 라우팅 룰을 사용
Good to Know
CLB처럼 고정된 호스트 명을 앱 로드 밸런서와 함께 가져야 함
앱 서버는 고객의 IP를 직접적으로 볼 수 없으며, 고객의 진짜 IP는 X-Forwarded-For라고 불리는 헤더에 삽입됨
X-Forwarded-Ports를 사용하는 포트와 X-Forwarded-Proto를 사용하는 프로토콜 가질 수 있음
예) 고객의 IP는 12.34.56.78이고 로드밸런서에 이를 직접적으로 이야기하고 연결 종료를 수행 로드밸런서가 EC2 인스턴스에 이야기할 때 EC2 인스턴스에 대한 개인 IP인 로드 밸런서 IP를 사용해 이야기하므로 고객의 IP를 알기 위해서는 X-Forwarded-Port와 Proto라고 불리는 HTTP 요청 안의 여분의 헤더를 살펴봐야 함
<ALB 실습>
로드 밸런서 콘솔에서 HTTP와 HTTPS 유형의 애플리케이션 로드 밸런서 생성 이름은 DemoALB로 하며 애플리케이션에 공공으로 액세스하기 때문에 인터넷 경계 체계인 Internet-facing을 사용하며 로드 밸런서에 액세스하기 위해 IPv4 유형의 스택을 사용
이후 네트워크 매핑에서 실행할 VPC를 지정하고 서브넷을 모두 선택하면 자동으로 올바른 서브넷에 할당됨
로드 밸런서에 보안 그룹을 할당하기 위해 이전의 my-fist-load-balancer 보안 그룹을 할당하고 80번 포트에서 HTTP 프로토콜로 로드 밸런서에 액세스를 시도하면 허용하도록 리스너와 라우팅을 지정한 후 이에 대한 타깃 그룹으로 새 대상 그룹을 생성하기를 누른 후 인스턴스를 선택해 my-fist-target-group 이름으로 위와 동일하게 상태 확인을 변경하여 생성한 후 2개의 인스턴스를 등록 이후 리스너와 라우팅을 방금 생성한 것으로 선택해 ALB가 네트워크 트래픽으로 데이터를 EC2 인스턴스로 보내도록 함
타깃 그룹ALB
애플리케이션 로드 밸런서 작동 확인 이후 DNS 이름으로 가서 열어 보면 Hello World가 나타나며, 새로 고침하면 다른 EC2 인스턴스의 Hello World가 나오게 됨 즉, ALB도 앞의 CLB처럼 작동하고 있다는 것을 확인할 수 있음
ALB는 추가 장점이 존재 이를 보기 위해 타깃 그룹에서 my-second-target-group이라는 이름으로 동일하게 두 번째 대상 그룹을 생성한 후, 인스턴스에서 아까 선택되지 않은 하나의 인스턴스를 선택하여 생성 이 후 ALB로 돌아가서 여러 대상 그룹으로 리디렉션되는 다양한 리스너가 있을 때, 첫 번째 대상 그룹으로 가는 80번 포트의 리스너를 확인하고 규칙 보기/편집을 클릭해 방금 생성한 다른 대상 그룹에도 적용하며 이외에도 고정응답이 반환되는 404 에러 경로를 설정 이로 인해 /test로 일치하면 두 번째 대상 그룹으로 이동하며, 그렇지 않으면 첫 번째 대상 그룹으로 라우팅됨
이제 DNS 이름에 /constant를 붙여서 입력하면 Constant error response!가 나타나게 되며 /test를 입력하면 EC2 인스턴스가 /test 유형의 쿼리에 응답하도록 구성되지 않았기 때문에 실행되지 않음
두 번째 대상 그룹 생성80번 포트 규칙보기/편집에 두 번째 타깃 그룹과 고정 응답 반환을 추가
리스너에 생성한 /test와 고정 응답 반환 규칙을 삭제하고 두 번째 그룹을 삭제 그리고 첫 번째 대상 그룹에 이전에 추가하지 않았던 인스턴스를 하나 더 추가하면 총 3개의 인스턴스에서 Hello World를 얻을 수 있게 됨
