[AWS] Solutions Architect Associate 실습 26일차 - Application Load Balancer (ALB)

1. Application Load Balancer (v2)

• Application load balancers is Layer 7 (HTTP)
• Load balancing to multiple HTTP applications across machines (target groups)
• Load balancing to multiple applications on the same machine (ex: containers)
• (동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다)
• Support for HTTP/2 and WebSocket
• Support redirects  (from HTTP to HTTPS for example
• ALB are a great fit for micro services & container-based application  (example: Docker & Amazon ECS)
• Has a port mapping feature to redirect to a dynamic port in ECS
• In comparison, we'd need multiple Classic Load Balancer per application
• (CLB는 애플리케이션 개수만큼 필요하지만 하나의 ALB로 다수의 애플리케이션 처리 가능)

Routing tables to different target groups

• Routing based on path in URL (example.com/users & example.com/posts)
• 두 개의 다른 경로 URL을 다른 대상 그룹에 리다이렉트 할 수 있다.
• Routing based on hostname in URL (one.example.com & other.example.com)
• 만약 로드밸런서가 두 개의 다른 호스트 네임에 접속 가능하다면 이 두 개의 다른 대상 그룹에 라우팅
• Routing based on Query String, Headers (example.com/users?id:123&order=false)
• 쿼리스트링이랑 헤더에 기반해서 라우팅 가능

 

2. HTTP Based Traffic

 
현재 두 개의 독립된 마이크로서비스가 서로 다른 작업을 처리하고 있으며, 이 두 서비스는 애플리케이션 로드 밸런서(ALB)를 통해 연결되고 있다.

첫 번째 대상 그룹 (/user 경로)

• 유저 애플리케이션을 담당
• 해당 요청은 첫 번째 EC2 인스턴스로 라우팅됨

두 번째 대상 그룹 (/search 경로)

• 검색 애플리케이션을 담당
• 해당 요청은 두 번째 EC2 인스턴스로 라우팅됨

📌 외부에서 들어오는 요청을 ALB가 경로 기반으로 구분하여 각각의 EC2 인스턴스에 맞는 서비스로 전달하는 구조이다.
 

3. Target Groups 

• EC2 instances (can be managed by an Auto Scaling Group) - HTTP
• ECS tasks (managed by ECS itself) - HTTP
• Lambda functions - HTTP request is translated into a JSON event
• 람다함수는 AWS에서 무서버로 불리는 것들의 기반이 되는 함수이다.
• IP Addresses - must be private IPs
• ALB can route to multiple target groups
• Health checks(상태확인) are at the target group level

 

4. Query Strings/ Parameters Routing

ABL와 두 개의 대상 그룹이 있다.
첫 번재는 AWS 기반의 EC2 인스턴스이고 두 번째 대상 그룹은는 데이터 센터  내부의 온 프레미스 개인 서버이다.
 
대상 그룹이 존재하기 위해서는, 등록을 위해 서버의 사설 IP가 대상 그룹에게 지정되어야 한다.
ALB를 통해 요청을 처리하는 애플리케이션이 있다고 가정 해 보자.
첫 번째 대상 그룹으로는 모바일 기반 트래픽 전체를 그리고 두 번째 대상 그룹으로는 데스크탑 기반 트래픽 전체를 보내는 상황이다. 이런 경우 쿼리 문자열이나 매개변수 라우팅을 사용하면 된다. 
URL에 ?Platform=Mobile 이 있는 경우 첫 번째 대상 그룹으로 리다이렉팅 되도록 ALB 에서 리다이렉션 라우팅 규칙을 만들 수 있고 ?Platrofm=Desktop이 있는 경우 두 번재 대상 그룹으로 리다이렉트 하도록 구성 할 수 있다.
 

5. Good to Know

• Fixed hostname (XXX.region.elb.amazonaws.com) - CLB 처럼 고정 호스트 이름이 부여됨
• The application servers don't see the IP of the client directly
• → The true IP of the client is inserted in the header X-Forwarded-For
• →  We can also get Port (X-Forwarded-Port) and proto (X-Forwarded-Proto)

If Client IP (12.34.56.78) is directly talking to a load balancer which perform something called a connection termination,  and when your load balancer talks to your EC2 Instance, it's going to use a load balancer IP which is private IPs into your EC2 Instance, and So for the EC2 Instance to know the client IP, It will have to look at the extra Header in your HTTP request called X-Forwarded Prort and Protocol
 
위 내용을 한글로 알고 싶으신 분은 아래의 블로그를 참고하시길 바랍니다. ▼
 
https://ysh2.tistory.com/120

[AWS] ALB (AWS의 관리형 로드 밸런서 中)

 

---

6. ALB 실습

6-1. ALB 생성하기

인스턴스 생성 후 실습하려고 했는데 인스턴스는 돌아가는데 서버 접속이 안 되는 문제
일단 이 문제부터 해결하고 실습은 나중에 다시 해야겠다

인바운드 룰을 설정해야 하는데 아웃바운드로 설정해서 안 된 거였음 

instance A 실행

instance B 실행

 
먼저 Instance A와 Instance B를 생성한다. 여기서 SSH key는 필요 없고, 대신 보안 규칙을 선택하는데 인바운드 규칙에 SSH랑 HTTP 허용하는 규칙을 선택해 준다. 
 
이제 우리가 하려는 실습은 하나의 URL 로 이 두 EC2 인스턴스에 접속하고 둘 사이의 부하를 분산하려는 것이다.
그렇게 하려면 로드 밸런서(부하 분산기)가 필요하다. 
 

6-2. Load Balancer 생성하기

오늘 실습할 로드 밸런서는 Application Load Balancer이다. 아마존 AWS 에서 지원하는 로드 밸런서의 경우 Application Load Balancer, Network Load Balancer, Gateway Load Balancer이 있다. ALB는 HTTPS나 HTTP 타입의 트래픽을 위한 것이다. 그리고 NLB는 UCP, UDP 프로토콜 또는 TCP 기반의 TLS를 위한 것이다. (이건 초고성능 환경을 구축할 때 사용한다. 지연 시간을 최소로 유지하면서 초당 수백만 건의 요청을 처리하는 것이다.) 그리고 마지막으로 게이트웨이 로드 밸런서는 GWLB라고 하는데 보안, 침입 탐지, 방화벽에 특화되어 있다. 그래서 네트워크 트래픽을 분석하기 위한 로드밸런서라고 할 수 있다. 마지막으로 저번 포스팅에 언급한 CLB(Classic Load Balancer)은 이제 아마존에서 지원하지 않는다. 

Application Load Balancer의 원리

EC2 대시보드 > Load Balancer > create load balancer > ALB > 체계(Scheme)은 인터넷 연결(Internet-facing) > 주소는 IPv4 > Network mapping 에서 로드밸런서를 배포할 곳과 가용 영역을 선택한다(모두 선택해 줌) > Security Group 탭에서는 HTTP만 허용하는 Inbound rule을 가진 demo-sg-load-balancer 선택해줌 > Listeners and routing 에서 타겟 그룹 설정 (이 때 Create target group으로 인스턴스와 포트, 프로토콜 선택해야 함)

 

Listeners and routing

Default action에서 대상 그룹(target group)을 선택한다.
 
대상 그룹이라는 것은 내가 만든 EC2 인스턴스들을 뜻한다. 라우팅을 하려면 먼저 Create target group 링크를 클릭해서 그룹을 만들어야 한다. 인스턴스들을 선택하고 HTTP와 80포트로 지정해 준다. 그리고 나서 다시 두 EC2 인스턴스를 모두 포트 80에 대기(pending) 상태로 추가한다. 이렇게 Targets이 생성되었으면 다시 Listeners and routing으로 돌아가서 Default action의 Forward to 에서 해당 타겟 그룹을 선택하고 로드 밸런서 생성을 완료한다. 이렇게 하면 이 대상 그룹이 나의 로드 밸런서의 80포트에 있는 리스너와 연결된다.
 

 

6-2. 로드밸런서 DNS 네임으로 서버 접속하기

이렇게 로드 밸런서가 생성되면 아래와 같이 DNS name 이 부여된다.

 
이 DNS name을 복사해서 새 페이지에 붙여 넣기 하면 서버에 접속가능하다.

 

페이지를 계속 새로고침하면 Instance A 가 실행되기도 하고 Instance B가 실행되기도 하는데, 즉, 내가 만든 애플리케이션 로드 밸런서가 두 EC2 인스턴스로 요청을 재전송하고 있는 것이다. 실제로 부하 분산이 일어나고 있는 것이다. 다시 Target Group 탭으로 돌아오면 두 인스턴스가 모두 정상(healthy) 상태로 뜨는 것을 확인가능하다. 즉, ALB가 대상 그룹을 통해 트래픽을 두 인스턴스로 고르게 전송하고 있다는 뜻이다.

 
만약 여기서 두 개의 인스턴스 중 하나의 인스턴스를 중지하면 ?
첫번째로 만든 인스턴스인 My First Instance / http://54.252.158.104/ 를 중지했다.
 
Target Grouop으로 가면 인스턴스가 중지되었기 때문에 타겟의 상태가 비정상으로 바뀐 걸 확인할 수 있다. 
왜냐하면 더 이상 들어오는 트래픽에 응답할 수 없기 때문이다.
인스턴스가 중지되면 Health status는 Unused 상태가 된다. 
 
그리고 다시 ALB 화면으로 돌아와서 새로고침 하면 정상적으로 동작하고 있는 인스턴스에서만 응답 메세지를 보낸다.
이게 바로 로드 밸런서의 장점이다. 타겟의 상태가 정상인지 아닌지 알고 있다.
 
그리고 다시 인스턴스를 돌리면 인스턴스의 상태가 Initial (초기화) 상태로 전환된 후 다시 Healthy 상태가 된다. 그리고 ALB 창에서 새로 고침하면 Instance A(http://54.252.158.104)와 Instance B(http://3.106.212.20/)에 고르게 연결된다. 

 

6-3. 로드밸런서에서 오는 트래픽만 허용하기

EC2 대시보드 > Security Groups  > launch-wizard-1 인바운드 규칙을 살펴보면 현재 EC2 인스턴스로 허용되는 유일한 트래픽은 모든 트래픽이다. 이 트래픽을 로드밸런서에서 오는 트래픽만 허용으로 바꾸기, 기존의 HTTP를 삭제하고 새 HTTP를 추가하는데 이 때 Source는 우리가 허용하려는 로드밸런서의 보안 그룹 으로 설정해 준다.

 

이제 Instance 의 IP주소로 열려 있는 서버를 새로고침하면, 시간 초과가 발생한다. (무한 로딩) 왜? 인스턴스에 액세스 할 수 없기 때문이다. 인스턴스에 직접 액세스하는 건 이제 불허된 상태다. 반면 로드 밸런서에서 새로고침하면 로드 배 ㄹ런서는 여전히 인스턴스에 액세스 할 수 있다. 보안그룹에 생성한 규칙에서 허용했기 때문이다. 

 

6-4. Listener rules 

EC2 > Load balancers > DemoALB (로드밸런서 이름) > Listeners 탭 > HTTP:80 listener 클릭 

여기서 리스너 규칙을 추가 할 수 있다. 기본 규칙은 모든 요청을 ALB의 데모 대상 그룹으로 보내라는 것이다. 이 페이지에서 Add rule을 클릭해서 새로운 규칙을 추가할 수 있다. 

이제 컨디션 룰을 정해야 한다. Host Header는 도메인 주소를 추가하는 것이고, Path 옵션은 경로를 설정하는 것이다. /이하를 실행한다. HTTP 요청 메소드를 get 또는 post 등 원하는 대로 설정할 수도 있다. 소스 IP를 기준으로 필터링하고 조건을 지정할 수 있고, 쿼리 문자열과 HTTP 헤더도 설정할 수 있다. 아주 다양한 기능이 있다. 하지만 실습에서는 path를 사용할 것이다. 그리고 /error 로 경로지정을 해 준다. 

 

Action 에는 세 가지 옵션이 있다. 각 옵션은 목적에 맞게 사용하면 된다. 트래픽을 실제 서버로 보내야 하면 "Forward",
클라이언트가 새 URL로 이동해야 하면 "Redirect", ALB에서 즉시 응답을 줘야 하면 "Fixed Response"를 선택한다. 나는 /error 경로로 가면 404 not foundm custom error! 메세지가 표시되도록 설정 해 주었다.

 

1. Forward to Target Groups

요청을 Target Group으로 전달하는 방식으로 ALB (Application Load Balancer)와 NLB (Network Load Balancer)에서 사용 가능하다.

• ALB: HTTP/HTTPS 요청을 여러 Target Group으로 보낼 수 있음 (가중치 기반 분배 가능)
• NLB: 하나의 Target Group으로만 포워딩 가능
• 일반적으로 서버 또는 컨테이너로 트래픽을 전달할 때 사용된다. 
• ✅ 사용 예시
  특정 경로(/api/*)의 요청을 API 서버(Target Group 1)로,
  다른 경로(/static/*)는 정적 파일 서버(Target Group 2)로 전달
  
  

2. Redirect to URL

요청을 지정된 URL로 리디렉션하는 방식이다. HTTP 응답 코드를 301 (Permanent Redirect) 또는 302 (Temporary Redirect)로 설정 가능하다.  도메인 변경, HTTP → HTTPS 리디렉션 등에 사용된다.

• ✅ 사용 예시
  http://example.com → https://example.com (HTTPS 강제 적용)
  example.com/old-page → example.com/new-page (페이지 이동)

 

3. Return Fixed Response

요청을 특정한 HTTP 상태 코드 및 응답 메시지와 함께 즉시 응답하도록 설정하는 방식이다. 
서버까지 요청을 전달하지 않고, ALB에서 직접 응답을 보낸다. JSON, HTML 등의 응답 본문을 설정할 수 있다.

• ✅ 사용 예시
  유지보수 모드일 때 503 Service Unavailable 응답을 반환한다. 
  특정 URL에 대한 접근을 차단함 (403 Forbidden 응답)
  단순한 헬스체크 응답 으로는 (200 OK)

 

마지막으로 우선순위를 설정할 수 있는데 1-50,000 사이의 값을 입력하고 낮은 값일 수록 우선순위가 낮다. 이대로 Listener rules 생성을 완료하고 이제 테스트 해 볼 차례이다. 

 

로드밸런서의 dns이름을 복사해서 주소창에 붙여넣기하고 끝에 지정한 경로인 '/error'을 붙여준다. 그러면 아래처럼 설정해 둔 에러 메세지를 반환한다. 실습 끝!

DemoALB-114116703.ap-southeast-2.elb.amazonaws.com/error