Go, Vantage point
가까운 곳을 걷지 않고 서는 먼 곳을 갈 수 없다.
Github | https://github.com/overnew/
Blog | https://everenew.tistory.com/
티스토리 뷰
일반적인 3Tier에서의 ALB
AWS에서 3Tier를 구성하는 경우, 일반적으로 ALB를 Presentaion Tier(Web Server)와 Application Tier(WAS) 사이에 하나씩 배치한다.
Interfacing ALB는 Web server에 트래픽을 분산한다.
만약 동적인 페이지가 필요하다면, Internal ALB로 WAS로 다시한번 트래픽을 분산하는 설계이다.
이를 위해서는 모든 동적 페이지 요청과 응답이 Web server를 거치도록 프록시 설정이 되어야 한다.
또한 Internal ALB가 추가로 배치되어 비용이 발생한다.
본인의 토이 프로젝트처럼, 단순히 WAS용 페이지(예를 들면 로그인, 회원가입, 개인정보 페이지)와 Web server용 페이지(메인 정적 페이지)가 따로 있다면 Web server와 중간의 Internal ALB를 거쳐야만 할까?
결국 단순히 Web server가 프록시의 역할만 해주기 위해 거쳐간다면, 불필요한 오버헤드가 발생한다.
우리는 Interfacing ALB라는 Endpoing가 이미 존재하기 때문에, Interfacing ALB가 바로 WAS로 트래픽을 전달해 주면 문제가 해결된다.
이를 위해서 ALB의 Path Routing 기능을 사용하면 된다.
ALB Path Routing
Client가 접근하는 URL Path에 따라서 다른 대상 그룹으로 트래픽을 전달한다.
기본적인 정적 페이지 접근이라면 /* 은 모두 web server로 전송하지만,
/sign*, /myprofile* 과 같은 경로로 접근한다면 바로 WAS로 전달하여 오버헤드를 줄인다.
로드벨런서의 리스너를 확인해 보자.
이곳에서 리스너의 규칙에 경로 패턴을 설정하여, 서로 다른 대상그룹 (Web server와 WAS)으로 전송할 수 있다.
Path 이외에도 헤더나 query string을 활용해 대상을 다르게 지정할 수 있다.
'Cloud > AWS' 카테고리의 다른 글
Lambda의 VPC 접근을 위한 Hyperplane ENI (0) | 2024.07.19 |
---|---|
[AWS] Lambda의 Cold Start와 Concurrency 문제 해결 (0) | 2024.07.15 |
AWS Code Build buildspec , 컨테이너 빌드 및 ECR 전송 (Terraform) (0) | 2024.07.06 |
AWS ECS Fargate 모니터링 (2) - AWS Grafana(SAML) (0) | 2024.07.03 |
AWS ECS Fargate 모니터링 (1) - Side car (otel), AMP (0) | 2024.07.02 |