[4일차] 고가용성 및 스케일링성: ELB 및 ASG

soyeon·2023년 3월 28일
0

SAA

목록 보기
4/6
post-thumbnail

Scalability & High Availability

Scalability(확장성)

애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다는 의미이다.

확장성의 종류

  • Vertical Scalability(수직 확장성)
    : 인스턴스의 크기를 확장하는 것
    신입 교환원 → 경력직 교환원

    데이터베이스와 같이 분산되지 않은 시스템에서 사용된다.(RDS, ElastiCache)
    하지만, 확장할 수 있는 정도에 한계가 있다. 하드웨어 제한이 걸려 있다.

  • Horizontal Scalability(수평 확장성) = clasticity(탄력성)
    : 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 것
    교환원을 여러명 고용

    수평 확장을 하는 것은 분산 시스템을 의미한다.

🤔 확장성과 고가용성은 서로 다른 개념 이다.

High Availability

: 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중을 의미한다.

  • 고가용성의 목표
    • 데이터 센터에서의 손실에서 살아남는 것
    • 센터 하나가 멈춰도 계속 작동이 가능한 것

High Availability & Scalability For EC2

  • Vertical Scaling : 인스턴스 크기 늘리기 (=scale up / down)
  • Horizontal Scaling : 인스턴스 수 늘리기 (=scale out / in)
  • High Availability : 다수의 AZ에 걸쳐서 동일 애플리케이션의 동일 인스턴스를 실행한다.

Elastic Load Balancing

What is load balancing?

로드 밸런서는 트래픽을 백엔드 서버들(다운스트림 EC2 인스턴스)로 전달하는 역할을 하는 서버

더 많은 유저가 연결될 수록 EC2 인스턴스로 가는 부하가 더욱 분산된다.
하지만 유저는 자신들이 백엔드 인스턴스 중 어떤 것에 연결되어 있는지 알 수 없다.

Why use a load balancer?

  • 부하를 다수의 다운스트림 인스턴스로 분산한다.
  • 애플리케이션에 단일 액세스 지점(DNS)을 노출한다.
  • 다운스트림 인스턴스의 장애를 원활하게 처리한다.
  • health check로 인스턴스의 상태를 확인한다.
  • SSL 종료를 통해 암호화된 HTTPS 트래픽을 가진다.
  • 고가용성을 가진다.
  • 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리한다.

Health Checks
상태 확인은 로드밸런서에서 매우 중요하다. 인스턴스가 제대로 작동하는 중이 아니면 해당 인스턴스로는 트래픽을 보낼 수 없기 때문이다.

상태확인은 포트와 라우트에서 이루어진다.

인스턴스가 200으로 응답하지 않으면, 인스턴스 상태가 좋지 않다로 기록되고, 그쪽으로 트래픽을 보내지 않게 된다.

Why use an Elastic Load Balancer?

Elastic Load Balancer
: 관리형 로드밸런서

AWS가 관리하고, 어떤 경우에도 작동할 것을 보장한다. 업그레이드와 유지 관리, 고가용성을 책임진다. 작동 방식을 수정할 수도 있다.

자체 로드밸런서를 마련하는 것보다 저렴하고, 직접 관리하기 어렵기 때문에 ELB를 쓰는 것이 좋다.

또, 다수의 AWS 서비스와 통합되어 있다.(EC2, ASG, ECS, CloudWatch, Route53, WAF, …)

AWS Load Balancer 종류

  1. Classic Load Balancer(CLB)
  2. Application Load Balancer(ALB)
  3. Network Load Balancer(NLB)
  4. Gateway Load Balancer(GWLB)

Load Balancer Security Groups

유저는 HTTP나 HTTPS를 사용해 어디서든 로드 밸런서에 접근이 가능하다. 따라서 보안 그룹의 규칙은 아래와 같을 것이다.

EC2 인스턴스로드 밸런서를 통해 들어오는 트래픽만을 허용해야 하기 때문에 EC2 인스턴스의 보안 그룹 규칙은 조금 다르다.

EC2 인스턴스의 보안 그룹을 로드 밸런서의 보안 그룹으로 연결한다.

Application Load Balancer(ALB)

: 7계층, 즉 HTTP 전용 로드 밸런서

  • 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용된다. 이러한 머신들은 대상 그룹으로 묶인다.
  • 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다.
  • HTTP/2와 WebSocket, 리다이렉트를 지원한다. HTTP에서 HTTPS로 트래픽을 자동 리다이렉트하려는 경우 로드 밸런서 레벨에서 가능하다.
  • 경로 라우팅을 지원한다.
    • path에 기반한 라우팅(example.com/users & example.com/posts)
    • hostname에 기반한 라우팅(one.example.com & other.example.com)
    • Query String, Header에 기반한 라우팅(example.com/users?id=123&order=false)
  • 마이크로서비스, 컨테이너 기반 애플리케이션에 가장 좋다.
    • Docker, Amazon ECS

➡️ 애플리케이션 로드 밸런서 하나만으로도 다수의 애플리케이션을 처리할 수 있다.

Target Groups(대상 그룹)

  • EC2 인스턴스 오토 스케일링 그룹에 의해 관리될 수 있다.
  • ECS task
  • Lambda function
  • IP 주소 무조건 사설 IP 주소여야 한다.

Network Load Balancer(NLB)

: 4계층, 즉 TCP와 UDP 로드 밸런서

  • 성능이 매우 좋다. 초당 수백만 건의 요청을 처리할 수 있고, ALB보다 지연시간도 짧다.
  • 가용 영역별로 하나의 고정 IP를 가진다. 탄력적 주소를 각 AZ에 할당할 수 있다.
  • 여러개의 고정 IP를 가진 애플리케이션을 노출할 때 좋다.
  • 고성능, TCP, UDP, 정적 IP에서 사용한다.
  • 네트워크 로드 밸런서 사용은 AWS 프리 티어에 포함되지 않는다.

Gateway Load Balancer(GWLB)

: 3계층, 즉 네트워크 트래픽 분석 로드 밸런서

  • 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
  • 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나, 침입 탐지 및 방지 시스템에 사용한다.

  • GWLB 기능
    • Transparent Network Gateway
    • Load Balancer
  • 6081번 포트의 GENEVE 프로토콜을 사용한다.

Sticky Sessions(Session Affinity)

로드 밸런서에 2가지 요청을 수행하는 클라이언트의 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다.

고정성을 활성화하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있다.

  • Custom Cookie
    애플리케이션에서 생성된다.
    애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다.
    AWSALB, AWSALBAPP, AWSALBTG와 같은 이름은 사용할 수 없다.

  • Application Cookie
    로드밸런서에서 생성된다.
    이름은 AWSALBAPP

로드밸런서에서 생성된다.
ALB에서는 이름이 AWSALB이며 CLB에서는 AWSELB이다.

Cross Zone Load Balancing

두 가용 영역이 있다. 한쪽에는 EC2 인스턴스가 많고, 한쪽에는 적다. 클라이언트가 이 로드 밸런서에 접속하고, 부하를 고르게 분배한다.

교차 영역 로드 밸런싱을 사용하면, 가용 영역에 상관없이 받은 트래픽을 동일하게 분배한다.

  • ALB 교차 영역 로드 밸런싱이 기본으로 활성화되어 있다. 데이터를 다른 AZ로 옮기는데 비용이 들지 않는다.
  • NLB & GWLB 교차 영역 로드 밸런싱이 비활성화되어 있다. 활용화하려면 비용을 지불해야 한다.
  • CLB 교차 영역 로드 밸런싱이 비활성화되어 있다. AZ간 데이터 이동에 비용이 들지 않는다.

SSL/TLS

SSL
: '보안 소켓 계층'을 의미하고 연결을 암호화하는 데 사용한다.

TLS
: LS는 새로운 버전의 SSL로, '전송 계층 보안'을 의미한다.

SSL 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화한다. 이를 전송 중(in-flight) 암호화라고 한다. 데이터는 네트워크를 이동하는 중에는 암호화되고, 송신자와 수신자 측에서만 이를 복호화할 수 있다.

퍼블릭 SSL 인증서는 인증 기관(CA)에서 발급한다. 퍼블픽 SSL 인증서를 로드 밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있다.

SSL 인증서에는 만료 날짜가 있어서 주기적으로 갱신해 인증 상태를 유지해야 한다.

SSL이 로드밸런서에서 어떻게 동작할까?

  1. 사용자는 HTTPS를 통해 접속한다.

  2. 인터넷을 통해 로드 밸런서에 접속하면, 로드 밸런서에서는 내부적으로 SSL 종료(SSL Termination)를 수행한다.

  3. 백엔드에서는 HTTP로 EC2 인스턴스와 통신한다. 암호화 되지 않는다. 하지만 VPC로 이동하는 트래픽은 프라이빗 네트워크를 쓰기 때문에 안전하다.

  4. 로드밸런서는 X.509 인증서를 사용한다. AWS에서는 ACM(AWS 인증서 관리자)이 인증서들을 관리한다.

  5. HTTP 리스너를 구성할 때 반드시 'HTTPS' 리스너로 해야 한다.

    기본 인증서를 지정

    클라이언트는 SNI(서버 이름 지정)를 사용하여 접속할 호스트의 이름을 알릴 수 있다.

SNI

여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트 지원할 수 있게 해준다.
확장된 프로토콜로, 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다.
클라이언트가 접속할 웹사이트를 말했을 때, 서버는 어떤 인증서를 로드해야 하는지 알 수 있다.
ALB, NLB, CloudFront에서만 동작한다.

Connection Draining

인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 “in-flight request”(활성 요청)을 완료할 수 있도록 한다.

인스턴스가 드레이닝되면 새로운 요청을 보내지 않는다.

연결 드레이닝 파라미터는 매개변수로 표시할 수 있다.(1~3600초)

Auto Scaling Group

웹사이트나 애플리케이션을 배포할 때 웹사이트 방문자가 갈수록 많아지면서 로드가 바뀐다.

ASG를 통해 EC2 서버를 빠르게 생성하고 종료하는 것을 자동화할 수 있다.

  • Scale out / Scale in
  • ASG에서 실행되는 EC2 인스턴스의 최소 및 최대 개수를 보장한다.
  • 자동으로 로드밸런서에 새로운 인스턴스가 연결된다.
    ELB는 health check을 통해 EC2 인스턴스의 상태를 확인하고 ASG로 전달한다. 로드 밸런서가 비정상이라 판단하는 EC2 인스턴스를 ASG가 종료한다.
  • 무료이다.

ASG 생성

시작 템플릿(Launch Template)을 생성해야 한다.

ASG 내에서 EC2 인스턴스를 시작하는 방법에 대한 정보가 포함되어 있다.

또한 ASG의 최소 크기, 최대 크기 초기 용량을 정의해야 한다.

스케일링 정책 또한 정의해야 한다.

CloudWatch Alarms & Scaling

CloudWatch 경보를 기반으로 ASG를 스케일 인 및 스케일 아웃할 수 있다.
지표에 따라 경보가 울리고 경보가 ASG의 스케일링 활동을 유발한다.

Dynamic Scaling Policy

  • Target Tracking Scaling 기본 기준선을 세우고, 수치가 그 대에 머물 수 있게 한다.
  • Simple / Step Scaling CloudWatch 경보를 설정한다.
  • Scheduled Actions 사용 패턴을 바탕으로 스케일링 한다. 특정 시간에 이벤트가 있으면 그 시간대에 스케일링 한다.

metric

  • CPU 사용률
  • 대상별 요청의 수
  • 평균 네트워크 입출력량

0개의 댓글