본문 바로가기
Infrastructure/Certificate

[SAA] High Availability and Scalability: ELB

RoyOps 2022. 11. 1. 22:22

High Availability and Scalability: ELB

이번 장에서는 SAA를 준비하며 높은 확장성과 고가용성을 위한 ELB에 대해서 알아보도록 한다.

확장성(Scalability) & 고가용성(HA, High Availability)

  • 확장성은 애플리케이션과 시스템이 더 큰 부하를 처리할 수 있음을 의미한다.
  • 확장성에는 수직적 확장과(Vertical)와 수평적 확장(Horizontal, Elasticity) 두 가지가 존재한다.
  • 확장성은 연결되어 있지만 고가용성과는 다르다.

Vertical Scalability

  • 수직 확장성은 인스턴스의 크기를 늘리는 것을 의미한다.
  • 예를 들어, 애플리케이션이 t2.micro에서 실행되고 있을 때, 해당 애플리케이션이 수직 확장한다는 것은 t2.large에서 실행되도록 변경하는 것을 의미한다.
  • 수직 확장성은 데이터베이스와 같은 비분산 시스템에서 매우 일반적이며, RDS, ElastiCache는 수직 확장이 가능한 서비스다.
  • 일반적으로, 수직 확장에는 하드웨어 제한으로 인해 확장할 수 있는 양에 제한이 있다.

Horizontal Scalability

  • 수평적 확장성은 애플리케이션에 대한 인스턴스/시스템의 수를 늘리는 것을 의미한다.
  • 수평적 확장은 분산 시스템을 의미하며, 웹 애플리케이션/현대 애플리케이션에 매우 일반적이다.
  • AWS와 같은 클라우드 제품을 통해서 간단한 수평적 확장이 가능하다.

High Availability

  • 고가용성은 일반적으로 수평적 확장과 밀접한 관련이 있다.
  • 고가용성은 최소 2개의 데이터 센터(==가용 영역)에서 애플리케이션/시스템을 실행하는 것을 의미한다.
  • 고가용성의 목표는 데이터 센터에 문제가 발생하더라도 서비스는 중단되지 않는 것이다.
  • RDS를 다중 가용지역에 걸쳐 배포하는 방식과 같이 수동으로 설정할 수 있다.

EC2에서의 고가용성 및 확장성

  • Vertical Scaling: 인스턴스 크기 증가(= Scale Up/Down)
    • 예를 들어, t2.nano(0.5GiB, 1 vCPU)를 u-12tb1.metal(12.3TiB 448vCPU)로 변경
  • Horizontal Scaling: 인스턴스 수 증가(= Scale Out/In)
    • Auto Scaling Group
    • Load Balancer
  • High Availability: 다중 가용지역에서 동일한 애플리케이션에 대한 인스턴스 실행
    • Auto Scaling Group multi AZ
    • Load Balancer multi AZ

부하 분산(Load Balancing)

  • 부하 분산은 트래픽을 인스턴스와 같은 여러 서버에 다운스트림으로 전달하는 서버이다.

  • 로드 밸런서를 사용하는 이유는 아래와 같다.
    • 여러 다운스트림 인스턴스에 부하를 분산
    • 애플리케이션에 대한 단일 액세스 지점(DNS) 노출
    • 다운스트림 인스턴스의 오류를 원활하게 처리
    • 인스턴스에 대한 정기적인 상태 확인 수행
    • 웹사이트에 SSL(HTTPS) 제공
    • 쿠키를 통해 고정적인 결과를 강화
    • 영역간 고가용성
    • 개인 트래픽에서 공용 트래픽 분리
  • ELB(Elastic Load Balancer)를 사용하는 이유는 아래와 같다.
    • AWS에서 관리하는 완전관리형 로드 밸런서다.
      • AWS는 로드 밸런서가 작동하고 있는 것을 보장한다.
      • AWS는 로드 밸런서의 업그레이드, 유지관리, 고가용성을 관리한다.
      • AWS는 몇 가지 구성 노브만 제공한다.
    • 자체 로드 밸런서를 설정하는 것이 비용은 적게 들지만 관리자의 더 많은 노력이 필요하다.
    • AWS의 많은 제품/서비스와 통합된다.
      • EC2, EC2 ASG, ECS
      • ACM(AWS Certificate Manager), CloudWatch
      • Route 53, AWS WAF, AWS Global Accelerator

상태 확인(Health Checks)

  • 로드 밸런서의 역할 중에 상태 확인은 상당히 중요하며, 이를 통해 로드 밸런서는 트래픽을 전달하는 인스턴스가 요청에 응답할 수 있는지 알 수 있다.
  • 상태 확인은 포트 및 지정된 경로(/health)에서 수행된다.
  • 응답이 200(OK)가 아닌 경우 인스턴스가 비정상이라고 판단한다.

로드 밸런서 유형

  • AWS에는 4가지 종류의 관리형 로드 밸런서가 있다.
    • Classic Load Balancer(v1 - 이전 세대, 2009, CLB): HTTP, HTTPS, TCP SSL
    • Application Load Balancer(v2 - 차세대, 2016, ALB): HTTP, HTTPS, WebSocket
    • Network Load Balancer(v2 - 차세대, 2017, NLB): TCP, TLS, UDP
    • Gateway Load Balancer(2020, GWLB): Layer 3(Network Layer)에서 작동, IP 프로토콜
  • 전반적으로 더 많은 기능을 제공하는 최신 세대 로드 밸런서를 사용하는 것이 좋다.
  • 일부 로드 밸런서는 내부(Private) 또는 외부(Public) ELB로 설정할 수 있다.
  • 아래의 이미지처럼 로드 밸런서에 보안 그룹을 설정하고 애플리케이션 보안 그룹에는 로드밸런서의 트래픽만 허용하도록 구성할 수 있다.

클래식 로드밸런서(v1)

  • TCP(Layer 4), HTTP & HTTPS(Layer 7)을 지원한다.
  • 상태 검사(Health Check)는 TCP 또는 HTTP 기반으로 이루어진다.
  • XXX.region.elb.amazonaws.com과 같은 고정된 호스트 이름을 사용한다.

애플리케이션 로드밸런서(v2)

  • 애플리케이션 로드 밸런서는 Layer 7(HTTP)에서 작동한다.
  • 여러 시스템(대상 그룹)에 걸쳐 여러 HTTP 애플리케이션에 대한 로드 밸런싱을 한다.
  • 컨테이너와 같은 동일한 시스템에 있는 여러 애플리케이션에 대한 로드 밸런싱을 지원한다.
  • HTTP/2 및 WebSocket을 지원하며 리디렉트를 지원한다.
  • 서로 다른 대상 그룹으로 테이블 라우팅을 한다.
    • URL 경로 기반의 라우팅(example.com/users&example.com/posts)
    • URL 호스트 이름 기반 라우팅(one.example.com 및 other.example.com)
    • 라우팅 쿼리 문자열, 헤더 기반(example.com/users?id=123&order=false)
  • ALB는 Docker, ECS와 같은 마이크로서비스 및 컨테이너 기반 애플리케이션에 적합하다.
  • ECS의 동적 포트로 리디렉션하는 포트 매핑 기능이 있다.
  • 반면, Classic Load Balancer는 하나의 애플리케이션에 여러 개의 로드 밸런서가 필요하다.

애플리케이션 로드밸런서 대상 그룹(Target Groups)

  • EC2 인스턴스(ASG에서 관리 가능): HTTP
  • ECS 작업(ECS 자체에서 관리): HTTP
  • Lambda 함수: HTTP 요청이 JSON 이벤트로 변환됨
  • IP 주소: 프라이빗 IP여야 함
  • ALB는 여러 대상 그룹으로 라우팅할 수 있다.
  • 상태 확인은 대상 그룹 수준에서 이루어진다.
  • 아래의 그림은 ALB의 쿼리 문자열/매개변수 라우팅의 예시이다.

  • ALB를 사용할 때 아래의 사항들을 기억해두면 좋다.
    • 고정 호스트 이름을 사용한다.(XXX.region.elb.amazonaws.com)
    • 애플리케이션 서버는 클라이언트의 IP를 직접 바라보지 않는다.
      • X-Forwarded-For 헤더에 클라이언트의 실제 IP가 삽입된다.
      • Port(X-Forwarded-Port) 및 Proto(X-Forwarded-Proto)도 얻을 수 있다.

네트워크 로드밸런서(v2)

  • 네트워크 로드밸런서는 Layer 4(TCP, UDP)에서 작동한다. 
    • TCP 및 UDP 트래픽을 인스턴스로 전달한다.
    • 초당 수백만 건의 요청을 처리할 수 있다.
    • 100ms 미만의 지연 시간(ALB의 경우 400ms의 지연 시간)
  • NLB는 가용지역당 하나의 고정 IP를 가지며 탄력적 IP 할당을 지원한다. 특정 IP 허용 목록에 유용하게 사용된다.
  • NLB는 극한의 성능을 위한 TCP 또는 UDP 트래픽에 사용된다.

네트워크 로드밸런서 대상 그룹(Target Groups)

  • EC2 인스턴스
  • IP 주소 - Private 주소
  • 애플리케이션 로드밸런서

게이트웨이 로드밸런서

  • AWS에서 서드파티 네트워크 가상 어플라이언스를 배포, 확장 및 관리한다. 예를 들어, 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템, 페이로드 조작이 있다.
  • Layer 3(Network Layer) IP에서만 동작한다.
  • 아래와 같은 기능을 결합한다.
    • 투명한 네트워크 게이트웨이: 모든 트래픽에 대한 단일 진입/출구
    • 로드 밸런서: 트래픽을 가상 어플라이언스로 분산
  • 포트 6081에서 GENEVE 프로토콜을 사용한다.

게이트웨이 로드밸런서 대상 그룹(Target Groups)

  • EC2 인스턴스
  • IP 주소 - Private 주소

고정 세션(Sticky Sessions, 세션 선호도)

  • 동일한 클라이언트가 항상 로드 밸런서 뒤의 동일한 인스턴스로 리디렉션되도록 고정성을 구현하는 것이 가능하다.
  • 이러한 기능은 클래식 로드 밸런서와 애플리케이션 로드 밸런서에서 작동한다.
  • 세션 고정에 사용되는 “쿠키”에는 사용자가 관리하는 만료일이 있다.
  • 세션 고정은 사용자가 세션 데이터를 잃지 않도록 하기 위해 사용된다.
  • 단, 고정 세션을 활성화하면 인스턴스의 부하에 불균형이 발생할 수 있다.

고정 세션 - 쿠키 이름

  • 애플리케이션 기반의 쿠키
    • 사용자 지정 쿠키
      • 대상에 의해 성성된다.
      • 애플리케이션에 필요한 모든 사용자 지정 속성을 포함할 수 있다.
      • 쿠키 이름은 각 대상 그룹에 대해 개별적으로 지정해야 한다.
      • AWSALB, AWSALBAPP 또는 AWSALBTG와 같이 예약된 이름은 사용해서는 안된다.
    • 애플리케이션 쿠키
      • 로드 밸런서에 의해 쿠키가 생성되며 이름은 AWSALBAPP이다.
  • 기간 기반 쿠키
    • 로드 밸런서에 의해 쿠키가 생성된다.
    • 쿠키의 이름은 ALB의 경우 AWSALB, CLB의 경우 AWSELB이다.

교차 영역(Cross-Zone) 로드 밸런싱

  • 교차 지역 로드 밸런싱을 사용하는 경우 각 로드 밸런서 인스턴스는 모든 AZ의 등록된 모든 인스턴스에 고르게 분산된다.

  • ELB 노드에 요청이 고르게 분산되지만 모든 인스턴스에 고르게 분산되지는 않는다.

  • 애플리케이션 로드 밸런서: 교차 영역 로드 밸런싱은 항상 활성화되어 있으며 비활성화할 수 없다.
    가용지역 간의 데이터 통신 요금은 발생하지 않는다.
  • 네트워크 로드 밸런서: 교차 영역 로드 밸런싱은 기본적으로 비활성화 되어 있으며 활성화하는 경우 가용지역 간의 데이터 통신 요금이 발생한다.
  • 클래식 로드 밸런서: 교차 영역 로드 밸런싱은 기본적으로 비활성화되어 있으며 활성화하더라도 추가비용은 발생하지 않는다.

SSL/TLS

  • SSL 인증서를 사용하면 클라이언트와 로드 밸런서 간의 트래픽을 전송 중에 암호화할 수 있다.
  • SSL은 연결을 암호화하는 데 사용되는 SSL(Secure Sockets Layer)을 나타낸다.
  • TLS는 최신 버전인 Transport Layer Security를 의미한다.
  • 최근에는 TLS 인증서를 주로 사용하지만 TLS와 SSL은 따로 구분되지 않고 SSL로 불려진다.
  • 공인 SSL 인증서는 인증 기관(CA, Certificate Authority)에서 발급된다.
    • Comodo
    • Symantec
    • GoDaddy
    • GlobalSign
    • Digicert
    • Letsencrypt
  • SSL 인증서에는 사용자가 설정한 만료 날짜가 있기 때문에 주기적으로 갱신해 주어야 한다.

  • 로드 밸런서는 X.509 인증서(SSL/TLS 서버 인증서)를 사용한다.
  • ACM(AWS Certificate Manager)을 사용하여 인증서를 관리할 수 있다.
  • 자체 인증서를 대신 생성하여 업로드할 수 있다.
  • HTTPS 리스너는 아래와 같은 특징이 있다.
    • 기본 인증서를 지정해야 한다.
    • 여러 도메인을 지원하기 위해 선택적 인증서 목록을 추가할 수 있다.
    • 클라이언트는 SNI(Server Name Indication)를 사용하여 도달하는 호스트 이름을 지정할 수 있다.
    • 특정 보안 정책을 만족시키기 위해 오래된 버전의 SSL/TLS 인증서를 지원한다.

SNI(Server Name Indication)

  • SNI는 여러 SSL 인증서를 하나의 웹 서버에서 여러 웹 사이트를 제공하기 위해 로드하는 문제를 해결해 준다.
  • “최신”프로토콜이며 클라이언트가 초기 SSL 핸드셰이크에서 대상 서버의 호스트 이름을 나타내도록 요구한다.
  • 요청받은 서버는 올바른 인증서를 찾거나 기본 인증서를 반환한다.
  • ALB & NLB와 같은 차세대 로드 밸런서와 CloudFront에서 사용이 가능하고 CLB와 같은 구세대에서는 지원하지 않는다.

ELB의 SSL Certificates

  • 클래식 로드 밸런서(v1)
    • 하나의 SSL 인증서만 지원한다.
    • 여러 SSL 인증서가 있는 여러 호스트 이름에 대해 여러 CLB를 사용해야 한다.
  • 애플리케이션 로드 밸런서(v2)
    • 여러 SSL 인증서가 있는 여러 리스너를 지원한다.
    • SNI를 사용하여 작동한다.
  • 네트워크 로드 밸런서(v2)
    • 여러 SSL 인증서가 있는 여러 리스너를 지원한다.
    • SNI를 사용하여 작동한다.

연결 배수(Connection Draining)

  • 기능 이름 지정
    • Connection Draining: CLB에서 사용된다.
    • Deregistration Delay: ALB, NLB에서 사용된다.
  • 인스턴스가 등록 취소 중이거나 비정상인 동안 “진행 중인 요청”을 완료하는 데 걸리는 시간을 의미한다.
  • 등록 취소 중인 EC2 인스턴스에 새 요청 전송을 중지한다.
  • 1 ~ 3600초 사이에서 설정할 수 있으며 비활성화 또한 가능하다.
  • 요청이 짧은 경우 낮은 값으로 설정하는 것이 권장된다.

참고 자료

저작자표시

'Infrastructure > Certificate' 카테고리의 다른 글

[SAA] AWS Fundamentals - RDS  (0) 2022.11.02
[SAA] High Availability and Scalability: ASG  (0) 2022.11.01
[SAA] EC2 Instance Storage  (0) 2022.11.01
[SAA] EC2 Associate  (0) 2022.11.01
[SAA] EC2 Basics  (0) 2022.11.01

'Infrastructure/Certificate' Related Articles

티스토리툴바