고가용성 및 스케일링성: ELB 및 ASG

📍 SAA 도전 4일차
📍 Udemy-AWS Certified Solutions Architect Associate 섹션 8

---

Scalability & High Availability

• Scability은 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미이다.
• Scability의 종류는 2가지가 있다.
  • Vertical Scalability(수직 확장성)
  • Horizontal Scalability(= elasticity, 수평 확장성, 탄력성)
• Scability와 High Availability는 연관된 개념이지만 서로 다르다.

Vertical Scalability

• 수직 확장성은 인스턴스의 크기를 확장하는 것을 의미한다.
• 예를 들어, 수직 확장성이란 t2.micro에서 동작하던 애플리케이션을 t2.large에서 동작하게 하는 것이다.
• 수직 확장성은 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용된다.
• RDS, ElastiCache 등의 데이터베이스에서 쉽게 찾아볼 수 있다. 이 서비스들은 하위 인스턴스의 유형을 업그레이드해서 수직적으로 확장할 수 있는 시스템들이다.
• 하지만 일반적으로 확장할 수 있는 정도에 한계가 있다. (하드웨어 제한)

Horizontal Scalability

• 수평 확장성이란 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 방법이다.
• 수평 확장을 했다는 건 분배된 시스템을 암시한다.
• 웹이나 현대적인 애플리케이션은 대부분 분배 시스템으로 이루어져 있다.
• 요즘은 Amazon EC2와 같은 클라우드 제공 업체 덕분에 수평적인 확장이 더욱 수월해졌다. 클릭 한번만으로 수평적 확장이 가능하다.

High Availability

• 고가용성은 보통 수평 확장과 함께 사용되는 개념이지만 늘 그런것은 아니다.
• 고가용성이란 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중이라는 걸 의미한다.
• 고가용성의 목표는 데이터 센터에서의 손실에서 살아남는 것이다. 센터 하나가 멈춰도 계속 작동이 가능하게끔 하는 것이다.
• 고가용성은 수동적일 수 있다.
• 고가용성은 활성형도 될 수 있다.

High Availability & Scalability For EC2

• 수직 확장: 인스턴스의 크기를 늘린다. (= scale up/down)
  • From t2.nano To t2.2xlarge
• 수평 확장: 인스턴스의 수를 늘린다. (= scale out/in)
  • Auto Scaling Group
  • Load Balancer
• 고가용성: 동일 애플리케이션의 동일 인스턴스를 다수의 AZ에 걸쳐 실행하는 경우를 의미한다.
  • Auto Scaling Group multi AZ
  • Load Balancer multi AZ

What is load balancing

• 로드밸런서는 서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할을 한다.
  

Why use a load balancer?

• 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서이다.
• 애플리케이션에 단일 액세스 지점(DNS)을 노출하게 되고 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다. 로드밸런서가 상태 확인 메커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인해 주기 때문이다.
• 로드밸런서는 인스턴스의 상태를 확인할 수 있다.
• 웹사이트의 SSL도 종료할 수 있으니 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있다.
• 쿠키로 고정도(stickness)를 강화할 수 있다.
• zone에 걸쳐 고가용성을 가진다.
• 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다.

Why use an Elastic Load Balancer?

• Elastic Load Balancer는 관리형 로드 밸런서이다.
  • AWS가 관리하며, 어떤 경우에도 작동할 것을 보장한다.
  • AWS가 업그레이드와 유지 관리 및 고가용성을 책임지며 로드 밸런서의 작동 방식을 수정할 수 있게끔 일부 구성도 제공한다.
• ELB는 자체 로드 밸런서를 마련하는 것보다 저렴하고 자체 로드 밸런서를 직접 관리하려면 확장성 특면에서 굉장히 번거롭기 때문이다.
• 또한, 로드 밸런서는 다수의 AWS의 서비스들과 통합되어 있다. 그러니 AWS 로드 밸런싱에는 무조건 ELB를 사용하는 것이 좋다.

Health Checks

• 상태 확인은 ELB가 EC2 인스턴스의 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용된다.
• 만약 제대로 작동하는 중이 아니라면 해당 인스턴스로는 트래픽을 보낼 수 없기 때문에 로드 밸런서에겐 인스턴스의 상태가 아주 중요하다.
• 그리고 상태 확인은 포트와 라우트(보통 /health)에서 이뤄진다.
• 만약 EC2 인스턴스가 괜찮다는 신호(HTTP 상태코드 200)를 응답하지 않는다면 인스턴스 상태가 좋지 않다고 기록된다. 그리고 ELB는 그쪽으로 트래픽을 보내지 않게 된다.
  

Types of load balancer on AWS

• AWS는 4 종류의 관리형 로드 밸런서가 있다.
  • Classic Load Balancer(V1 - old generation) - 2009 - CLB
    • HTTP, HTTPS, TCP, SSL(secure TCP)를 지원
    • 하지만 AWS는 이제 이 로드 밸런서의 사용을 권장하지 않고 있기 때문에 콘솔에서 더 이상 사용할 수 없. SAA 시험에서도 제외된다.
  • 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
    • 네트워크 계층(3계층)에서 작동하므로 IP protocol을 지원
• 결론적으로, 더 많은 기능을 가지고 있는 신형 로드밸런서를 사용하는 것이 권장된다.
• 일부 로드 밸런서들은 내부에 설정될 수 있어 네트워크에 개인적 접근이 가능하고 웹사이트와 공공 애플리케이션 모두에 사용이 가능한 외부 공공 로드 밸런서도 있다.

Load Balancer Security Groups

• 유저는 HTTP나 HTTPS를 사용해 어디서든 로드 밸런서에 접근이 가능하다.
• 따라서 보안 그룹의 규칙은 화면에 보이는 이런 형태가 될 것이다.
  
• EC2 인스턴스는 로드 밸런서를 통해 곧장 들어오는 트래픽만을 허용해야 하기 때문에 EC2 인스턴스의 보안 그룹 규칙은 조금 달라야 한다.
  • EC2 인스턴스는 LB로부터 오는 트래픽만을 허용해야 한다. (강화된 보안 메커니즘)
    • 포트 80에서 HTTP 트래픽을 허용하며 소스는 IP 범위가 아니라 보안 그룹이 된다.
    • EC2 인스턴스의 보안 그룹을 로드 밸런서의 보안 그룹으로 연결한 것이다.
    • 이렇게 함으로써 EC2 인스턴스는 로드 밸런서에서 온 트래픽만을 허용하게 된다.
      

Application Load Balancer(v2)

• 7계층, 즉 HTTP 전용 로드 밸런서이다.
• 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용된다. 이러한 머신들은 대상 그룹이라는 그룹으로 묶이게 된다.
• 컨테이너와 ECS를 사용해서 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.
• HTTP/2와 WebSocket을 지원
• 리다이렉트도 지원하므로 HTTP에서 HTTPS로 트래픽을 자동 리다이렉트 가능
• 경로 라우팅도 지원한다.
  • URL 대상 경로에 기반한 라우팅이 가능하다. (example.com/users & example.com/posts)
  • URL의 호스트 이름에 기반한 라우팅도 가능하다. (one.example.com & other.example.com)
  • 쿼리 문자열과 헤더에 기반한 라우팅도 가능하다. (example.com/users?id=123&order=false)
• ALB는 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서로 이후 배우게 될 도커와 Amazon ECS의 경우에는 ALB가 가장 적합한 로드 밸런서가 될 것이다.
• 포트 매핑 기능이 있어서 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해준다.
• ALB는 하나만으로도 다수의 애플리케이션을 처리할 수 있다.
  

Application Load Balancer(v2) Target Groups

• Target Group(대상 그룹)이란 무엇일까?
  • EC2 인스턴스(Auto Scaling Group에 의해 관리될 수 있다) - HTTP
  • ECS(ECS 자신에 의해 관리된다) - HTTP
  • Lambda functions(AWS에서 무서버로 불리는 모든 것들의 기반이 되는 함수이다 - HTTP request는 JSON event로 변환된다.
  • IP Addresses - 꼭 사설 IP여야 한다. 사설 IP주소 앞에 ALB가 위치할 수 있다.
• ALB는 여러 대상 그룹으로 라우팅할 수 있다.
• 상태 확인(health check)는 대상 그룹 레벨에서 이루어진다.

Application Load Balancer(v2) Query Strings/Parameters Routing

다음과 같이 ALB 사용 예시를 들 수 있다.

Application Load Balancer(v2) Good to Know

• ALB를 사용하는 경우 고정 호스트 이름이 부여된다. (XXX.region.elb.amazonaws.com)
• 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못하며 클라이언트의 실제 IP는 X-Forwarded-For라고 불리는 헤더에 삽입된다. X-Forwarded-Port를 사용하는 포트와 X-Forwarded-Proto를 사용하는 프로토콜을 확인해야 한다.
  • EC2 인스턴스는 client IP를 직접 볼 수 없다. Load Balancer의 사설 IP를 대신 보게 된다.
    

Network Load Balancer(V2)

• NLB는 L4 로드밸런서이므로 TCP와 UDP 트래픽을 다룰 수 있다.
  • TCP & UDP 트래픽이 인스턴스로 가는 것을 다룬다.
  • NLB의 성능은 매우 높다. 초 당 수백만 건의 요청을 처리할 수 있고 ALB에 비해 지연 시간도 짧다. (ALB: 400ms / NLB: 100ms)
• AZ별로 하나의 고정 IP를 갖는다. 또한 탄력적 IP 주소를 각 AZ에 할당할 수 있다. (여러 개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다)
• NLB는 고성능, TCP & UDP 트래픽을 위해 사용된다.
• NLB는 AWS 프리 티어에 포함되지 않는다.

Network Load Balancer(V2) TCP(L4) Based Traffic

• ALB와 유사하다. 대상 그룹을 생성하면 NLB가 대상 그룹을 리다이렉트한다.
  

Network Load Balancer(V2) - Target Groups

• EC2 인스턴스
• IP 주소(반드시 사설 IP)
• ALB(NLB 덕분에 고정 IP 주소를 얻을 수 있고 ALB 덕분에 HTTP 유형의 트래픽을 처리하는 규칙을 얻을 수 있다)
• NLB는 TCP, HTTP, HTTPS 프로토콜에 대해 상태 체크를 지원한다.
  

Gateway Load Balancer

• GWLB는 배포 및 확장과 AWS 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
• GWLB는 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.
• 그래서 IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다.
• GWLB는 살펴봤던 모든 로드 밸런서보다 낮은 수준에서 실행된다. IP 패킷의 네트워크 계층인 L3에서 실행된다.
• GWLB는 2 가지 기능을 갖는다.
  • Transparent Network Gateway - VPC의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과한다.
  • Load Balancer - 대상 그룹의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 된다.
• 6081번 포트의 GENEVE 프로토콜을 사용해라
  

Gateway Load Balancer - Target Groups

• EC2 인스턴스
• IP 주소 - 반드시 사설 IP여야 한다.
  

78. 스티키 세션 내용 추가하기..