AWS Section 7-1. ELB + ASG

📌 Scalability & High Availability _ 확장성 및 고가용성

• 확장성은 애플리케이션/시스템이 적응하여 더 많은 부하를 처리할 수 있음을 의미합니다.
• 확장성에는 두 가지 종류가 있습니다:
  • Vertical Scalability _ 수직 확장성
  • Horizontal Scalability _ 수평 확장성(= 탄력성)
• 확장성과 고가용성은 연결된 개념이지만 다름

 

📌 Vertical Scalability _ 수직 확장성

• 인스턴스의 크기를 늘려 성능을 향상시키는 방식
  • ex) t2.micro 인스턴스를 t2.large로 업그레이드.
• 수직 확장성은 데이터베이스와 같은 비분산 시스템에서 매우 일반적
• RDS나, ElastiCache와 같은 수직적으로 확장할 수 있는 서비스에서 사용
• 하드웨어 성능에 따라 확장 가능 범위에 제한이 있음.

 

📌 Horizontal Scalability _ 수평 확장성(= 탄력성)

• 인스턴스나 시스템의 수를 늘려 처리 능력을 확장하는 방식
  • ex) 교환원을 추가 고용하여 더 많은 업무를 처리하게 하는 방식.
• 수평 확장은 분산형 시스템을 의미
  • 웹 애플리케이션이나 클라우드 환경(예: EC2)에서 주로 사용됨.

 

📌 High Availability _ 고가용성

• 시스템이 여러 데이터 센터(가용성 영역, AZ)에서 실행되어 장애 시에도 계속 작동하는 상태를 의미
• 고가용성은 수평 확장과 함께 사용되거나 RDS의 다중 AZ 구성처럼 수동형으로도 적용될 수 있음
• 데이터 센터 손실에도 애플리케이션을 지속적으로 실행할 수 있게 보장하는 것이 목표

 

 

 

📌 EC2의 고가용성 및 확장성

• Vertical Scaling: 인스턴스 크기 증가(= 위/아래로 확장)
• Horizontal Scaling: 인스턴스 수 증가(= 스케일아웃/인)
  • 자동 스케일링 그룹 / 로드 밸런서 사용
• 고가용성: 다중 AZ에서 동일한 애플리케이션을 실행.
  • 자동 스케일링 그룹과 멀티 AZ 로드 밸런서를 통해 고가용성 구현.

 

📌 Load Balancing

• 사용자는 Elastic Load Balancer(ELB)에 직접 연결되며, EC2 인스턴스 중 하나로 트래픽이 전달됨
  • 사용자는 자신이 어느 EC2 인스턴스로 연결되었는지 알 수 없음.
• 로드 밸런서는 여러 사용자가 접속할 때, 각기 다른 EC2 인스턴스로 트래픽을 분산시킴으로써 부하를 분산함

즉 많은 유저가 있을 수록 EC2 인스턴스로 가는 부하가 분산되는 것

 

🧐 로드 밸런서가 필요한 이유 !

 

• 부하 분산: 여러 다운스트림 인스턴스로 트래픽을 분산시켜 시스템 효율성을 높임.
• 단일 액세스 지점 제공: 애플리케이션에 대한 단일 DNS 노출을 통해 관리가 용이해짐.
• 인스턴스 장애 처리: 장애 발생 시 다른 인스턴스로 원활하게 트래픽 전환 가능.
• 상태 확인: 인스턴스가 요청을 처리할 수 있는지 정기적으로 확인.
• SSL 종료: 웹사이트에서 HTTPS 암호화를 지원.
• 쿠키 고착화: 사용자가 동일한 인스턴스에 연결되도록 고정 가능.
• 가용성 향상: 여러 구역에서 트래픽을 분산시켜 고가용성 보장.
• 공공 및 개인 트래픽 분리: 각각의 트래픽을 효과적으로 관리 가능.
• Elastic Load Balancer는 관리형 로드 밸런서이기도 함
  • AWS가 관리하며 어떤 경우에도 작동할 것을 보장함
  • AWS가 업그레이드아 유지 관리 및 고가용성을 책임지고
  • 로드 밸런서의 작동 방식을 수정할 수 있게끔 일부 구성 knob도 제공함
  • Elastic Load Balancer는 무조건 쓰는 편이 좋음
    • 자체 로드 밸런서를 마련하는 것보다 저렴하고
    • 자체 로드 밸런서를 직접 관리하면 확장성 측면에서 번거러움
    • AWS는 인스턴스와도 통합 가능하며
      • EC2, Auto Scaling Group, Amazon ECS
      • (인증서 관리) ACM, CloudWatch
      • Route 53, AWS WAF, AWS Global Accelerator 등 앞으로 더 늘어날 것

 

 

📌 Health Checks _ 상태 확인

• 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용
• 인스턴스가 트래픽을 처리할 수 있는지 확인 후, 상태가 좋지 않으면 트래픽을 보내지 않음.
• 상태 확인은 일반적으로 /health 경로에서 이루어지며, 200 응답이 아닌 경우 문제로 기록.

 

 

📌 AWS는 4 종류의 Load Balancers가 있음

• Classic Load Balancer (v1 - old generation) – 2009 – CLB
  • HTTP, HTTPS, TCP, SSL (secure TCP)를 지원 (더 이상 사용 X)
• Application Load Balancer (v2 - new generation) – 2016 – ALB
  • HTTP, HTTPS, WebSocket를 지원
• Network Load Balancer (v2 - new generation) – 2017 – NLB
  • TCP, TLS (secure TCP), UDP를 지원
• Gateway Load Balancer – 2020 – GWLB
  • Operates at layer 3 (Network layer) – IP Protocol를 지원
• 결론적으로 더 많은 기능을 가지고 있는 최신 세대 로드 밸런싱 장치사용을 권장
• 일부 로드 밸런서는 내부(비공개) 또는 외부(공개) ELB로 설정할 수 있음 (내부 : 네트워크에 개인적 접근 가능)

 

 

📌 Load Balancer Security Grops

 

사용자와 로드 밸런서:

• 사용자는 HTTP/HTTPS로 어디서든 로드 밸런서에 접근 가능.
• 포트 범위: HTTP(80), HTTPS(443).
• 소스: 0.0.0.0/0으로 모든 위치에서의 연결을 허용.

EC2 인스턴스와 로드 밸런서:

• EC2 인스턴스는 로드 밸런서를 통한 트래픽만 허용해야 하므로 보안 규칙이 다름.
• 포트 80에서 HTTP 트래픽을 허용하지만, 소스는 특정 보안 그룹(로드 밸런서의 보안 그룹)만 허용.
• 즉, EC2 인스턴스의 보안 그룹을 로드 밸런서의 보안 그룹으로 연결하여, EC2가 로드 밸런서에서 오는 트래픽만을 허용하게 만듦.

EC2 인스턴스는 로드 밸런서만을 통해 들어오는 트래픽을 허용하며, 이는 보안을 강화하는 메커니즘임 !!

 

 

📌 Application Load Balancer(v2)

• 애플리케이션 로드 밸런싱 장치는 7계층에서 작동하는 HTTP 전용 로드 밸런서
• 여러 HTTP 애플리케이션 간의 트래픽을 라우팅하는 데 사용됨
• 여러 애플리케이션에 부하 분산: 동일한 EC2 인스턴스 상에서 여러 애플리케이션의 트래픽을 분산하며, 컨테이너와 ECS와 같은 기술을 지원.
• HTTP/2 및 웹소켓 지원
• 리디렉션도 지원(예: HTTP에서 HTTPS로 트래픽을 자동 리다이렉트 하려는 경우 로드 밸런서 레벨에서 가능하다는 의미)

라우팅 기능:

• 다양한 대상 그룹에 따른 라우팅으로 예를들면
  • 경로 기반 라우팅: URL 경로에 따라 트래픽 분산 (example.com/users 및 example.com/posts)
  • 호스트 이름 기반 라우팅: 호스트 이름에 따라 트래픽 분산 (one.example.com 및 other.example.com )
  • 쿼리 문자열 및 헤더 기반 라우팅: 쿼리 매개변수나 헤더에 따라 트래픽 라우팅 (example.com/users?id=123&order=false)

적합한 환경:

• 마이크로 서비스 및 컨테이너 기반 애플리케이션(예: 도커, 아마존 ECS)에 가장 적합.
• ECS와 통합된 포트 매핑 기능을 통해 동적 포트로 트래픽을 리다이렉션 가능.

비교:

• 클래식 로드 밸런서는 애플리케이션마다 별도의 로드 밸런서가 필요하지만,
• Application Load Balancer는 하나의 ALB로 다수의 애플리케이션을 처리할 수 있음.

• 외부 애플리케이션 로드 밸런서는 공공 대상을 위한 로드 밸런서
• 로드 밸런서가 여러 EC2 인스턴스로 트래픽을 분배하며, 각기 다른 대상 그룹에 트래픽을 라우팅함

대상 그룹:]

• 첫 번째 대상 그룹 (오른쪽 위):
  • EC2 인스턴스로 구성됨.
  • 유저 애플리케이션을 위한 그룹.
  • /user 경로로 라우팅됨.
• 두 번째 대상 그룹 (오른쪽 아래):
  • EC2 인스턴스로 구성됨.
  • 검색 애플리케이션을 위한 그룹.
  • /search 경로로 라우팅됨.
  • 상태 확인(Health Check)을 통해 인스턴스 상태를 모니터링함.

두 개의 독립된 마이크로 서비스가 서로 다른 작업을 처리하며, 
URL 라우팅을 통해 각 대상 그룹으로 트래픽을 분배하는 방식

 

 

📌 Target Group 이란 ?

• EC2 인스턴스: 자동 스케일링 그룹에서 관리 가능 (HTTP).
• ECS 작업: ECS 자체에서 관리 (HTTP).
• 람다 함수: HTTP 요청이 JSON 이벤트로 변환되어 처리됨.
• IP 주소: 개인 IP여야 함.
• ALB는 여러 대상 그룹으로 라우팅할 수 있음 (IP 주소들의 앞에도 위치할 수 있는데 꼭 사설 IP 주소여야 함)
• Health check는 target group level에서 이루어짐

 

1. Target Group 1: AWS 기반의 EC2 인스턴스.
2. Target Group 2: 데이터 센터 내부의 On-Premises 개인 서버.

• 대상 그룹이 존재하기 위해서는 등록을 위해 서버의 사설 IP가 대상 그룹에 지정되어야 함
• ALB는 여러 대상 그룹으로 트래픽을 라우팅할 수 있으며, IP 주소 앞에 위치할 때 반드시 사설 IP 주소여야 함.

라우팅 시나리오:

• 예를 들어, 플랫폼에 따라 트래픽을 분리할 수 있음
  • 모바일 기반 트래픽은 Target Group 1으로, 데스크탑 기반 트래픽은 Target Group 2로 라우팅.
  • 쿼리 문자열이나 매개변수 라우팅을 사용하여 라우팅 가능 (예: ?Platform=Mobile).

 

<알아두면 좋을 것들>

• 애플리케이션 로드밸런서 (ALB)를 사용하는 경우 고정 호스트 이름이 부여됨 (XXX.region.elb.amazonaws.com )
• 애플리케이션 서버가 클라이언트의 IP를 직접 보지 못함
• 클라이언트의 실제 IP는 헤더 X-Forward-For에 삽입됨
• 포트(X-Forward-Port)와 프로토(X-Forward-Proto)도 얻게 됨

 

 

👩🏻‍💻 실습

• URL 하나로 두 EC2 인스턴스에 접근해 인스턴스 간 부하를 균등하게 배포하는 것. 여기에 로드 밸런서를 활용

ALB는 HTTP, HTTPS 트래픽 유형을 위한 것.

👩🏻‍💻 로드 밸런서 활용

• 애플리케이션 로드 밸런서(ALB)가 두 개의 EC2 인스턴스(my first instance와 my second instance)로 트래픽을 균등하게 배분
• 웹 페이지 새로고침 시, IP 뒤의 숫자가 바뀌는 이유는 로드 밸런서가 두 인스턴스를 번갈아가며 리디렉션하기 때문 
• >> 이는 부하가 균등하게 분산되고 있음을 증명

 

👩🏻‍💻 인스턴스 중지 시

• 하나의 인스턴스를 중지시키면, 그 인스턴스의 Health status가 unused로 표시
• 중지된 인스턴스는 더 이상 트래픽을 처리하지 못하므로, 새로고침을 하면 하나의 인스턴스만 응답하게 됨.

 

👩🏻‍💻 EC2 인스턴스 액세스 방법

• EC2 인스턴스에 직접 접근할 수 있지만, 로드 밸런서를 통해 접근하는 것이 권장됨🌟
• 보안 그룹에서 허용된 트래픽만 로드 밸런서가 처리하도록 설정할 수 있음. 이를 통해 직접 인스턴스에 접근하는 것을 차단할 수 있음

 

👩🏻‍💻 규칙 생성

• 예를 들어, URL에 /error를 붙이면 "Not found, custom error!"와 같은 메시지와 함께 404 오류를 반환하도록 규칙을 설정할 수 있음
• 우선순위에 따라 규칙이 적용됨