[AWS/SAA-03] 로드 밸런서 (Load Balancer)

 

💝 로드 밸런서 (Load Balancer)

✅ 확장성 & 높은 가용성

✅ 로드 밸런서 (Load Balancer)

✅ 탄력적 로드 밸런서 - CLB & ALB & NLB & GWLB

✅ 고정 세션 / 쿠키

✅ SSL / TLS

 

 

 

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

✤ 확장성 : 더 많은 양을 처리 - 애플리케이션/시스템이 적응을 통해 더 큰 부하를 처리할 수 있음을 의미
✤ 확장성의 2가지 종류
  • 수직 확장성
  • 수평적 확장성 (=탄력성)
✤ 확장성은 연결되어 있지만 고가용성과는 다르다

 

수직 확장성 (Vertical Scalability)

  • 인스턴스의 크기를 확장하는 것을 의미 (scale up : 확장 / scale down : 축소)

  • 수직확장을 통해 매우 작은 인스턴스로부터 대규모로 확장 가능

  • 예를 들어 애플리케이션이 t2.micro에서 실행될 때, 수직 확장성을 하면 애플리케이션을 t2.large에서 실행하는 것을 의미
  • 수직적 확장성은 데이터베이스와 같은 비분산 시스템에서 매우 일반적
  • RDS, ElastiCache는 수직 확장이 가능한 서비스이다
  • 일반적으로 수직으로 확장할 수 있는 정도에는 제한이 있다 (하드웨어 제한)

 

수평 확장성 (Horizontal Scalability)

  • 애플리케이션의 인스턴스/시스템 수 증가를 의미 (scale in : 인스턴스 수⬇️ / scale out : 인스턴스 수⬆️)

  • 분산 시스템을 의미
  • 웹 애플리케이션/최신 애플리케이션에서 매우 일반적
  • Amazon EC2와 같은 클라우드 서비스 덕분에 수평 확장이 용이하다

 

고가용성 (High Availability)

  • 수평 확장성과 같이 쓰임

  • 동일 애플리케이션의 동일 인스턴스를 다수의 AZ에 걸쳐 실행

  • 최소 2개 이상의 AWS 의 AZ 나 데이터센터(== 가용 영역)에서 애플리케이션/시스템을 실행하는 것을 의미
  • 목표는 데이터센터에서의 손실에서 살아남는 것 - 센터1개가 멈춰도 계속 작동하게끔
  • 고가용성은 수동적일 수 있다 (예: RDS 다중 AZ의 경우)

  • 고가용성을 활성화 할 수 있다 - 수평확장을 하는 경우

  • 자동 AZ 가 활성화된 자동 스케일러 그룹 & 로드 밸런서에 사용

 

 

 

🚨 로드 밸런싱 (Load Balancing)

✤ 트래픽을 분산하는 서비스

✤ 백엔드나 다운스트림, EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상의 서버들로 자동으로 분산 가능

✤ 보안 그룹 

  • HTTPS / HTTP 모두 접근 가능

  • 로드 밸런서에서 들어온 트래픽만을 허용

 

로드 밸런서 (Load Balancer) 를 사용하는 이유

  • 부하 분산

  • 애플리케이션에 단일 액세스 지점(DNS)을 노출

  • 다운스트림 인스턴스의 장애를 원활히 처리

  • 인스턴스 상태 확인 가능

  • SSL 종료 가능 - 웹사이트에 암호화된 HTTPS 트래픽을 가질 수 있다

  • 쿠키를 사용하여 고정성 적용 가능

  • 영역에 걸친 고가용성을 가짐

  • 클라우드 내 개인 트래픽과 공공 트래픽 분리 가능

 

 

 

🚨 탄력적 로드 밸런서 (ELB - Elastic Load Balancer) 를 사용하는 이유

✤ 관리형 로드 밸런서이다 Managed Load Balancer

✤ AWS 가 관리. 어떤 경우에도 작동할 것을 보장

✤ 로드밸런서의 자동 방식을 수정하게끔 일부 구성 놉(knobs) 제공

✤ 저렴. 확장성 용이. AWS 서비스들과 통합되어 있다

✤ EC2 인스턴스와 통합 가능

 

 

 

🚨 상태 확인 (Health Checks)

✤ ELB 가 EC2 인스턴스의 작동이 올바르게 되고있는지의 여부를 확인하기 위해 사용

✤ 트래픽을 전달하는 인스턴스가 요청에 응답할 수 있는지 확인할 수 있다

✤ 포트 및 라우트(경로)에서 상태 확인을 수행함

✤ 응답이 200 이 아니면 unhealthy

 

 

 

🚨 AWS 에서 탄력적 로드 밸런서의 4가지 종류

✤ AWS 에서 관리형 로드 밸런서의 4가지 종류

  • 클래식 로드 밸런서 CLB (Classic Load Balancer)

  • 애플리케이션 로드 밸런서 ALB (Application Load Balancer)

  • 네트워크 로드 밸런서 NLB (Network Load Balancer)

  • 게이트웨이 로드 밸런서 GWLB (Gateway Load Balancer)

✤ 최신 로드 밸런서를 사용하는 것을 권장한다

✤ 일부 로드 밸런서는 프라이빗 또는 퍼블릭 ELB 로 설정 가능 

 

클래식 로드 밸런서 CLB (Classic Load Balancer)

  • AWS 에서 지원 X, 권장 X

 

애플리케이션 밸런서 ALB (Application Load Balancer)

  • 7계층(응용 계층 - Application Layer), 즉 HTTP 전용 로드 밸런서

  • 머신 간 다수 HTTP 애플리케이션의 라우팅에 사용. 이러한 머신들은 대상그룹이라는 그룹으로 묶인다

  • 동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산

  • HTTP/2, 웹소켓, 리다이렉트 지원

  • HTTP 에서 HTTPS 로 트래픽을 자동 리다이렉트 하려는 경우 로드 밸런서 레벨에서 가능

  • 경로 라우팅 지원

  • 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서

  • 포트 매핑 가능 O

  • 하나로 다수의 애플리케이션 처리 가능 O

  • 대상 그룹(Target Groups)

     - EC2 인스턴스 : HTTP

     - Lambda 함수 : HTTP 요청은 json 이벤트로 변환됨

     - IP 주소 : IP 주소들 앞에 위치 가능. 사설 주소만

  • 여러 대상 그룹으로 라우팅 가능

  • 상태 확인(Health Checks) 은 대상 그룹 레벨에서 이루어진다

  • 고정 호스트 이름이 부여됨

  • 애플리케이션 서버는 클라이언트의 IP 를 직접 볼 수 X

  • 클라이언트의 실제 IP는 헤더 X-Forwarded-For 에 삽입된다

 

네트워크 밸런서 NLB (Network Load Balancer)

  • 4계층(전환 계층 - Transport Layer)

  • TCP & UDP 트래픽을 다룰 수 있다 (HTTP를 다루는 L7 보다 하위 계층)

  • 성능 Good. 지연 시간 짧다

  • 1~3개의 IP 로만 액세스할 수 있는 애플리케이션을 만들 때 고려된다

  • 가용영역별로 하나의 고정 IP 를 갖는다

     - 탄력적 IP 주소를 각 AZ 에 할당 가능

     - 여러개의 고정 IP 를 가진 애플리케이션 노출 시 유용

  • 고성능

  • TCP, UDP, 정적 IP 에 사용됨

  • 사용료는 AWS 프리티어에 포함 X

  • 대상 그룹(Target Groups)

     - EC2 인스턴스

     - IP 주소 : IP 는 하드코딩되어야 하고 프라이빗해야 함

     - Application Load Balancer : ALB 앞에 사용 가능. ALB 덕분에 HTTP 유형의 트래픽을 처리하는 규칙을 얻을 수 O

  • 상태 확인(Health Checks) 은 TCP, HTTP, HTTPS 프로토콜을 지원한다.

 

게이트웨이 밸런서 GWLB (Gateway Load Balancer)

  • 3계층(네트워크 계층 - Network Layer) - IP 패킷

  • 배포 및 확장과 AWS 의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용

  • 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용

  • 네트워크 트래픽 분석

  • 기능

     - 투명 네트워크 게이트웨이(Transparent Network Gateway) : VCP 의 모든 트래픽이 GWLB 가 되는 단일 입구,출구를 통과

     - 로드 밸런서(Load Balancer) : 대상 그룹의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 된다

  • 6081 포트의 GENEVE 프로토콜을 사용해라

  • 대상 그룹(Target Groups)

     - EC2 인스턴스

     - IP 주소 : IP 는 프라이빗해야 함

 

 

 

🚨 고정 세션 - 세션 밀접성 (Sticky Sessions - Session Affinity)

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

✤ 클라이언트가 세션을 유지한 상태라면 모든 요청을 동일한 인스턴스로 유지하는 기능

✤ CLB, ALB 에서 설정 가능

✤ 고정성 O, 만료기간 O

✤ 고정(Stickiness) 에 사용되는 "쿠키(cookie)" 에는 만료기간이 포함되어 있다

  • 쿠키 : 클라이언트에서 LB 로 요청의 일부로서 전송되는것. 쿠키가 만료되면 다른 EC2 인스턴스로 리다이렉트 된다

✤ 사용 사례

  • 세션 만료 사용 시 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결

✤ 고정성 활성화 → 백엔드 인스턴스 부하에 불균형을 초례할 수 있다. 일부 인스턴스는 고정 사용자를 갖게 된다.

 

 

 

🚨 쿠키 (Cookie)

✤ 고정 세션에 포함된다

✤ 고정 세션에는 2가지 유형의 쿠키가 있다

 

애플리케이션 기반 쿠키 (Application-based Cookies)

  • 사용자 정의 쿠키 (Custom Cookie)

     - 대상으로 생성

     - 모든 사용자 정의 속성 포함

     - 쿠키이름은 각 대상 그룹별로 개별적으로 지정

     - AWS, SALB, AWSALBAPP, AWSALBTG 를 이름으로 사용하지 않아야 한다

  • 애플리케이션 쿠키 (Application Cookie)

     - 로드 밸런서 자체에서 생성

     - 쿠키 이름은 AWSALBAPP 이다

 

기간 기반 쿠키 (Duration-based Cookies)

  • 로드 밸런서에서 생성된 쿠키

  • 특정 기간을 기반으로 만료되며 그 시간이 로드 밸런서 자체에서 생성되는 것

  • ALB 에서의 쿠키 이름은 AWSALB, CLB 에서의 쿠키 이름은 AWSELB 이다.

 

 

 

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

✤ 각각의 LB 인스턴스가 모든 가용영역에 등록된 모든 인스턴스 부하를 고르게 분배

✤ 모든 영역에 있는 EC2 인스턴스에 트래픽이 고르게 분배

✤ 교차 영역 X

  • 영역을 분산하지 않고 부하 분산

  • 탄력적 LB 노드의 인스턴스로 분산

✤ Application Load Balancer

  • ALB 에 교차영역LB 가 기본으로 설정되어 있다. 비활성화 가능.

  • AZ 간의 데이터 이동에 비용 X (기본적으로는 AWS 에서 비용 지불 O)

✤ Network Load Balancer & Gateway Load Balancer

  • 비활성화가 default

  • 활성화 하려면 비용 지불 O

✤ Classic Load Balancer

  • 비활성화가 default

  • 활성화해도 AZ 간 데이터 이동에 비용 X

 

 

 

🚨 SSL / TLS

✤ SSL 인증서를 사용하면 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 가능 (전송 중 암호화 in-flight encryption)

✤ 데이터는 네트워크를 이동하는 중에 암호화되고, 송신자 ・ 수신자 측에서만 이를 복호화할 수 있다

✤ SSL : 보안 소켓 계층. 연결을 암호화하는데 사용

✤ TLS : 새로운 버전의 SSL 전송 계층 보안

✤ 요즘은 TLS 인증서를 주로 사용하지만 SSL 인증서를 참조하여 사용한다.

✤ 퍼블릭 인증서는 인증기관 CA 에서 발급한다

✤ 퍼블릭 SSL 인증서를 LB 에 추가하면, 클라이언트와 LB 사이의 연결을 암호화 할 수 있다

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

✤ Classic Load Balancer

  • SSL 인증서를 1개만 만들 수 있다

  • 여러개의 인증서로 여러 호스트 이름을 지원하려면 CLB 자체를 여러개 둬야한다

✤ Application Load Balancer

  • 여러개의 SSL 인증서를 두고 리스너를 여러개 지원 가능

  • SNI 사용

✤ Network Load Balancer

  • 여러개의 SSL 인증서를 두고 다중 리스너 지원 가능

  • SNI 사용

 

로드 밸런서에서의 SSL 인증서 동작

  • 사용자가 HTTPS 를 통해 접속 → 인터넷을 통해 LB 에 접속하면 LB 에서는 내부적으로 SSL 종료 수행 → 백엔드에서는 HTTP 로 EC2 인스턴스와 통신 → VPC 이동하는 트래픽은 프라이빗 네트워크 사용

  • 로드 밸런서는 X.509 인증서 사용

  • ACM(AWS 인증서 관리자 - AWS Certificate Manager) 에서 인증서 관리

  • ACM 에 인증서 업로드 가능

  • HTTP 리스너 구성 시 반드시 HTTPS 리스너로 해야 한다

     - 기본 인증서를 지정해야 함

     - 다중 도메인 지원을 위해 다른 인증서 추가 가능

     - 클라이언트는 SNI(서버 이름 지정) 을 사용해 접속할 호스트의 이름을 알 수 있다

     - 여러분이 원하는대로 보안정책 지정 가능. 구버전의 SSL, TLS, 레거시 클라이언트도 지원 가능

 

SNI (Server Name Indication)

  • 여러개의 인증서를 하나의 웹서버에 로드해 하나의 웹서버가 여러개의 웹사이트를 지원할 수 있게 한다

  • 확장된 프로토콜로, 클라이언트가 최초 SSL 핸드쉐이크 단계에서 대상서버의 호스트 이름을 지정하도록 함

  • 클라이언트가 어느 호스트명에 접속하려는지 서버에 알리는 역할

  • 클라이언트가 접속할 웹사이트를 말할 때 서버는 어떤 인증서를 로드해야 하는지 알 수 있다

  • 모든 로드 밸런서에 지원 X → ALB & NLB & CloudFront 만 지원

  • SSL/TLS 연결 시 웹서버 도메인 헤더 정보와 SSL 인증서 DNS 이름 정보를 매칭해주는 기술

 

 

 

🚨 연결 드레이닝 (Connection Draining)

✤ 인스턴스가 등록 취소, 혹은 비정상적인 상태(in-flight request) 에 있을 때 인스턴스에 어느 정도 시간을 주어 활성요청을 완료할 수 있도록 하는 기능

✤ 기능 이름

  • 연결 드레이닝 (Connection Draining) - CLB 에서 사용

  • 등록취소 지연 (Deregistration Delay) - ALB & NLB 에서 사용

✤ ELB 는 등록취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다

✤ 1~3600초 (기본 300초-5분)

✤ 값이 0 이면 드레이닝 일어나지 X

✤ 짧은 요청의 경우 낮은 값으로 설정하기