ALB
: Application Load Balancer
- 네트워크 레이어 7계층에 속하는 HTTP 전용로드 밸런서입니다.
- 머신 간 다수 HTTP Application의 라우팅에 사용됩니다.
- 머신들은 Target Group으로 묶여서 관리됩니다.
- 동일 EC2 Instance상의 여러 Application에 부하를 분산 ▷ 컨테이너와 ECS를 사용하게 됩니다.
- HTTP/2와 Web Socket을 지원합니다.
- Redirection도 지원하기에 HTTP에서 HTTPS로 트래픽을 자동 리다이렉트하려는 경우 로드 밸런서 수준에서 가능합니다.
※ 경로 라우팅 (ALB)
- Target Group에 따른 라우팅으로 URL 대상 경로에 기반한 방법을 사용하여 각기 다른 그룹에 접근할 수 있습니다.
(post라는 타겟 그룹(인스턴스A, 인스턴스B 가 포함되어 있음)) = example.com/posts
(user라는 타겟 그룹(인스턴스C, 인스턴스D 가 포함되어 있음)) = example.com/users
- URL 호스트 헤더에 기반한 라우팅
: 도메인을 가지고 와야하는데 Route 53에서 생성해도 된다. 이렇게 호스트 헤더로 넣으려면 해당 도메인에 접근할 수 있도록
ALB의 보안 그룹에 해당 도메인에 접근 IP, Port 등을 추가해줘야 합니다. (이 내용은 추후 Route 53 할 때 같이 진행해 볼 예정)
one.example.com (호스트 헤더: one.example.com)
other.example.com (호스트 헤더: other.example.com)
- Query string, Header 기반한 라우팅
example.com/users?ID=123&order=false
users? 다음에 붙는 내용으로 다른 타겟 그룹 라우팅마이크로 서비스나 컨테이너 기반 Application에 가장 좋은 로드 밸런서로 Amazon ECS와 Docker가 예시로 있습니다.
ECS와 Dokcer는 ALB에 가장 적합한 로드 밸런서입니다.
이유는 ECS에는 포트 매핑이라는 특징이 있어서 ECS 인스턴스의 동적 포트로 리다이렉션이 가능하며,
여러 라우트 호스팅을 통해서 분산된 타겟 그룹에 접근하여 Application의 트래픽을 분산시킬 수 있기 때문입니다.
CLB(Classic Load Balancer)와 다른 점은 CLB는 Application과 로드 밸런서가 비례하여 갯수가 증가하지만, ALB는 하나만 가지고도
여러 Application에 접근하여 업무 처리가 가능하기 때문에 더욱 효울적입니다.
2개의 독립된 마이크로 서비스가 서로 다른 작업을 처리하는데 사용자가 Application Load Balancer에만 접근해도
이 로드 밸런서는 각 대상 그룹에 지능적으로 라우팅하는 방법을 알고 있기 때문에 편하게 접근이 가능합니다.
Target Group
1) EC2 Instance가 대상 그룹이 될 수 있고 Auto Scaling을 통해 그룹에 의해 관리될 수 있습니다.
2) ECS에 의해 직접 수행됩니다. (하나의 ALB가 될 수 있음)
(eg. ECS, Docker)
3) Private IP (사설 IP 주소)를 통한 접근
4) Lambda Function
: HTTP 요청 사항을 JSON 이벤트로 변환, 서버리스 형태며 모든 것들의 기반이 되는 함수
ALB 특징
ALB는 여러 대상 그룹으로 라우팅이 가능하며, 상태 확인은 타겟 그룹 수준에서 이루어집니다.
타겟 그룹에 대해 리다이렉션 방법은 다양하며 쿼리 문자열이나 매개변수 라우팅 등 여러 규칙을 정의해 나갈 수 있습니다.
CLB와 동일하게 고정 호스트 이름을 제공하며, Application 서버에서는 Client IP를 직접적으로 확인할 수는 없습니다.
Client IP를 확인하기 위해서는 "X-Forwarded-For" 라고 불리는 헤더에 삽입
따라서 "X-Forwarded-Port", "X-Forwarded-proto"에 의해 사용되는 프로토콜을 얻고 이 추가 해더를 확인하면
사용자의 IP를 알 수 있을 것입니다.
ALB 생성 및 관리 실습
이름을 정의하고 체계는 인터넷 경계로 한다.
(내부면 개인 트래픽에서만 접근이 가능하고 인터넷 경계면 공공, 외부적으로 Application에 접근이 가능한 것을 의미합니다.)
IP주소형은 IPv4만 하거나 IPv4, IPv6 둘 다 할 수 있는데 실습상 IPv4만 진행하겠습니다.
리스너는 로드 밸런서에 인바운드 역할을 하며, Application에서 로드 밸런서에 접근할 때 어떤 프로토콜과 포트로 접근할 지
정의하는 것입니다. 이는 로드 밸런서에 보안그룹과 일치해야 합니다.
타겟 그룹을 인스턴스로 할 경우, 인스턴스는 Application에 각 업무를 처리하는 타겟 그룹 내의 하나의 작업 단위가 되기 때문에
인스턴스 보안그룹도 로드 밸런서의 보안그룹과 일치 시킵니다.
그렇게 해야만, 로드 밸런서가 각 인스턴스를 접근할 수 있고 다시 말하자면 인스턴스가 속한 타겟 그룹에 접근할 수 있게 되는 것입니다.
VPC를 셋팅하고 연결할 AZ를 체크합니다. 관련해서 미리 정의된 서브넷과도 연결합니다.
라우팅 구성할 때 타겟 그룹을 설정하는데 이 때 앞서 타겟 그룹으로 정의할 수 있는 대상을 체크합니다.
이번 케이스 같은 경우는 인스턴스로 진행하고 각 타겟 그룹에 인스턴스를 추가할 것입니다.
리스너에서 정의한 프로토콜과 포트를(HTTP/80번포트) 대상 그룹 프로토콜, 포트를 일치시켜 ALB에 정의된
리스너를 통해 각 대상그룹에 접근할 수 있도록 정의합니다.
고급 상태 검사 설정에 대해서는 앞서 CLB에서 정의했기 때문에 추가 설명은 넘어가도록 하겠습니다.
타겟 그룹으로 인스턴스를 택했기 때문에 그룹에 포함시킬 인스턴스를 정의합니다.
로드 밸런서 탭에서 대상 그룹을 선택해서 새로 대상그룹을 만들 수도 있습니다.
마찬가지로 대상그룹 구성을 인스턴스로 잡고 프로토콜 및 포트 방식 등을 앞에 만든 대상그룹과 일치시킨 뒤
남은 인스턴스를 추가하여 대상 그룹을 만들어봅니다.
ALB는 이제 대상 그룹을 접근할 때 Rule을 관리하면 됩니다.
이 부분이 라우팅 호스팅 하는 부분입니다.
라우팅 호스팅 하는 부분은 여러 방법이 있지만 본 포스팅에서는 경로(URL)로 셋팅하겠습니다.
기본 DNS URL을 / 으로 인식하고 그 다음 경로를 정의해서 대상 그룹을 셋팅하면 됩니다.
경로를 설정하고 작업 추가 부분에 라우트 경로 처리하는 방법이 세 가지가 있는데, 첫 번째는 타겟 그룹 붙이기
두 번째는 리다이렉션 대상 셋팅, 마지막으로 고정 응답 변환이 있습니다.
이번 포스팅에서는 타겟 그룹을 붙일 것이고, ALB DNS 주소가 만약 example.com일 경우
룰에서 정의한 경로를 /group이라 하고 작업 추가에 타겟 그룹2(인스턴스3)을 붙인다면
사용자는 ALB DNS 경로에 접근하고 (example.com) 이 경로는 디폴트로 타겟 그룹1에 붙여져 있기 때문에
타겟 그룹1(인스턴스1, 인스턴스2)이 호출되어 보여질 것입니다.
그렇지만 앞서 리스너 Rule로 추가한 타겟그룹2에 대해서는 example.com/group으로 사용자가 url 호스팅을
통해 접근하면 타겟 그룹2(인스턴스3)이 호출되어 보여질 것입니다.
물론, 인스턴스3에서 /group으로 접근했을때 어떻게 작업 처리를 하고 보여주게 할 것인지 셋팅이 되어 있지 않아
404 오류가 발생할 것입니다.
이외에도 리다이렉션 대상을 셋팅해서 다른 url로 보낸다거나 고정 응답 변환을 정의하여
상태 코드는 503으로 보내고 관련된 내용은 뭘로 보여지게 할 것인지 셋팅할 수 있습니다.
(물론, 상태코드는 개발자 임의로 정의할 수 있습니다)
이상 ALB에 대한 내용과 실습이었습니다. 감사합니다.
'Cloud' 카테고리의 다른 글
| AWS - ELB(GWLB) (0) | 2023.01.17 |
|---|---|
| AWS - ELB(NLB) (0) | 2023.01.17 |
| AWS - ELB(CLB) (2) | 2023.01.17 |
| AWS - ELB & ASG (0) | 2023.01.17 |
| AWS - EFS (1) | 2023.01.17 |
