AWS Section 7-2. ELB + AS

📌 Network Load Balancer (NLB)

• 4계층 로드 밸런서이므로 TCP와 UDP 트래픽을 처리할 수 있음
  • 7계층은 HTTP
  • 4계층은 TCP와 UDP
  • 네트워크 로드 밸런서는 굉장히 고성능!! (초당 수백만 건의 요청 처리 가능)
  • 지연시간도 ALB에 비해 짧음
• 가용 영역 당 하나의 고정 IP만 있음
  • (각 가용 영역에 탄력적 IP를 할당할 수 있음)
  • IF 시험에 >> 애플리케이션 1개 혹은 서로 다른 2개, 3개의 IP로만 액세스 가능하다고 나온다면 네트워크 로드 밸런서 떠올리기!
• AWS 프리티어 아님

 

• 대상 그룹을 생성하면 NLB가 그쪽으로 리디렉션함.
• 그러면 TCP 트래픽이나 백엔드는 HTTP를 사용하면서 프론트엔드는 여전히 TCP를 사용할 수도 있음

 

 

네트워크 로드 밸런서의 대상 그룹이 될 수 있는 것

• EC2 instances
• IP Addresses – must be private IPs
• ALB 앞에 NLB를 둘 수 있음
  • NLB는 고정 IP를 제공하고, ALB는 HTTP 트래픽 처리와 관련된 모든 규칙을 처리.

 

Health Check (상태 확인):

• NLB는 TCP, HTTP, HTTPS 프로토콜을 지원하는 상태 확인을 수행.
• 백엔드가 HTTP나 HTTPS를 지원하면, 해당 프로토콜을 기준으로 상태 확인을 정의 가능

 

📌 Gateway Load Balancer (GWLB)

• 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 fleet(?) 관리에 사용됨
  • ex: 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템, 일부 페이로드 조작(네트ㅂ워크 수준에서) 등...에 사용됨
• 중요🌟

  

• ALB는 트래픽을 애플리케이션에 바로 전달하지만, Gateway Load Balancer (GWLB)는 트래픽이 애플리케이션에 도달하기 전에 모든 트래픽을 검사함

 

🩺 트래픽 검사 프로세스:

• Gateway Load Balancer 를 생성하면 이면에서는 라우팅 테이블이 업데이트 됨
• 라우팅 테이블이 수정되면, 모든 사용자 트래픽은 GWLB를 통과함
• GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산
• >> 모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 분석하고 처리함 (ex - 방화벽, 침입 탐지 등)  
  • 이상이 없으면 다시 GWLB로 보내고
  • 이상이 있으면 트래픽을 drop 시킴

GWLB의 목적

- 네트워크 트래픽 분석 및 보안 강화.
- 애플리케이션에 도달하기 전 트래픽을 검사해 잠재적인 위협을 차단하고, 안전한 트래픽만 허용. 

 

 

 

💡 원리 💡

• GWLB는 모든 로드 밸런서보다 낮은 수준에서 실행됨
• (IP 패킷 _ L3(네트워크 계층)
• GWLB는 2가지 기능을 갖게됨
  1. Transparent Network Gateway
     1. VCP의 모든 트래픽이 GWLB가 되는 단일 엔트리와 출구를 통과하기 때문
  2. Load Balancer
     1. target group의 가상 어플라이언스 집합에 전반적으로 그 트래픽을 분산해 로드 밸런서가 됨
  • *** 시험 볼 때 6081번 포트의* GENEV 로토콜을 사용해라 >> 바로 GWLB 가 된다!!**

 

GWLB의 대상 그룹이 될 수 있는 것

• EC2 instances
• IP Addresses – must be private IPs

 

 

 

 

📌 ELB - Sticky Sessions _고정 세션

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

• 클라이언트가 처음 요청을 보내서 특정 EC2 인스턴스에 연결되면, 그 후의 요청도 동일한 인스턴스로 연결됨. (예: Client 1이 첫 번째 인스턴스에 연결된 후, 다음 요청도 같은 인스턴스에 연결)
• 이 동작은 CLB와 ALB 모두에서 설정할 수 있음
• 이를 가능하게 하는 것이 쿠키
  • 쿠키는 클라이언트가 로드 밸런서로 요청을 보낼 때 전송되는 데이터 (고정성, 만료기간 존재)
  • 쿠키 만료 시, 클라이언트는 다른 EC2 인스턴스로 리디렉션될 수 있음

Use Case:

• 사용자가 세션 데이터를 잃지 않기 위해 동일한 백엔드 인스턴스에 계속 연결될 수 있도록 활용
• 하지만 고정성을 활성화하면 부하 불균형이 발생할 수 있음. 일부 인스턴스는 고정 사용자를 갖기 때문!

 

 

🍪 쿠키의 유형

1. Application-based Cookies (애플리케이션 기반 쿠키):
   • 사용자 정의 쿠키로, 백엔드 대상 그룹에서 생성.
   • 애플리케이션에 필요한 모든 사용자 지정 속성을 포함할 수 있으며, 쿠키 이름을 지정해야 합니다.
   • AWSALB, AWSALBAPP, AWSALBTG는 사용 불가 (ELB가 사용하기 때문).
2. Duration-based Cookies (기간 기반 쿠키):
   • 로드 밸런서에서 생성된 쿠키.
   • ALB에서는 AWSALB, CLB에서는 AWSELB라는 이름을 가집니다.
   • 특정 기간을 기반으로 만료되며, 로드 밸런서가 자동으로 생성.

• 클라이언트가 로드 밸런서에 요청을 보내면, 기존의 쿠키(request cookie)를 다시 로드 밸런서에 전송해, 고정성이 유지됨!!
• 쿠키가 만료되지 않는 한, 클라이언트는 같은 EC2 인스턴스로 연결

 

 

📌 Cross-Zone Load Balancing

교차 영역 로드 밸런싱이 적용되면 각 로드 밸런서 인스턴스는 모든 가용 영역에 등록된 모든 인스턴스에 고르게 분포됨

 

📌 Cross Zone Load Balancing

 

>> 각 로드 밸런서 인스턴스는 모든 AZ의 등록된 모든 인스턴스에 고르게 분산됨

• 가용영역이 2개 있고
• 1번에는 EC2 인스턴스가 2개
• 2번에는 EC2 인스턴스가 8개 존재
• 클라이언트가 이 로드 밸런서에 접근하려하면..!!
  • Cross Zone Load Balancing이 적용되면
    • >> 각 로드 밸런서 인스턴스는 모든 가용 영역에 등록된 모든 인스턴스에 고르게 분포됨.
      • 1번에 트래픽의 50%, 2번에 50%
      • 각 ALB는 이 트래픽을 10개 (2개 + 8개)의 EC2 인스턴스에 리디렉션 (즉 10%씩)

 

📌 Without Cross Zone Load Balancing

 

>> Cross Zone Load Balancing이 없으면 요청은 탄성 로드 밸런서의 노드 인스턴스에 분산됨

• 1번, 2번 각각 50%씩 분포됨
• 여기에서는 1번 ALB가 해당 영역에 있는 인스턴스로만 트래픽을 전송함 ( 2 / 50 )
• 2번도 마찬가지 ( 8 / 50 )

정답은 없고 상황에 따라 적절히 골라 적용하면 됨💡

 

 

Application Load Balancer

• 기본적으로 활성화됨 (대상 그룹 수준에서 비활성화할 수 있음)
• 가용 영역으로 넘어가도 데이터에 대한 요금 없음 
• >> 교차 영역 로드 밸런싱이 기본적으로 활성화돼 있기에 AZ를 교차하는 데이터에 대한 비용은 부과되지 않음

 

Network Load Balancer 및 Gateway Load Balancer

• 기본적으로 비활성화됨
• 활성화된 경우 AZ 간 데이터에 대한 요금($)을 지불

 

Classic Load Balancer

• 기본적으로 비활성화됨
• 활성화된 경우 AZ 간 데이터에 대한 요금 없음

 

 

📌 SSL / TLS - Basic

• SSL 인증서는 클라이언트와 로드 밸런서 간의 트래픽이 암호화되도록 해줌
  • 즉, 데이터가 네트워크를 통과하는 동안 암호화되어, 발신자와 수신자만이 데이터를 해독할 수 있음
• SSL은 '보안 소켓 계층'을 의미하며, 연결을 암호화하는 데 사용됨
  • TLS는 SSL의 최신 버전으로, 전송 계층 보안을 의미
  • 오늘날 주로 TLS 인증서가 사용되지만, 여전히 SSL이라는 용어가 널리 쓰임
• Public SSL 인증서는 CA(인증 기관)에서 발급되며, 대표적인 기관으로 Comodo, Symantec, GoDaddy, Globalsign, Digicert 등이 있음
• SSL 인증서를 로드 밸런서에 첨부하면, 클라이언트와 로드 밸런서 간의 연결이 암호화됨
• SSL 인증서는 만료일이 있으므로, 정기적으로 갱신해야 함.

 

 

<작동 방식🦾>

• 사용자는 HTTPS를 통해 로드 밸런서에 연결하며, 'S'는 SSL 인증서를 사용하여 암호화된 안전한 연결임을 의미
• 공용 인터넷을 통해 로드 밸런서에 연결.
• 로드 밸런서는 내부적으로 SSL을 종료하고, 이후의 통신은 암호화되지 않은 HTTP로 EC2 인스턴스와 통신함
• 백엔드에서는 HTTP로 EC2 인스턴스와 통신하며, 암호화는 없음.
• 하지만 이 트래픽은 VPC의 프라이빗 네트워크를 통해 안전하게 전송됨!!
• AWS ACM(AWS 인증서 관리자)를 사용하여 SSL 인증서를 관리할 수 있음

 

📌 SSL – Server Name Indication (SNI)

SNI

• 하나의 웹 서버에 여러 SSL 인증서를 로드하여, 다양한 웹사이트를 지원할 수 있도록 해줌

SNI의 동작 원리:

• 클라이언트가 SSL 핸드셰이크 초기 단계에서 연결하려는 서버의 호스트 이름을 표시.
• (클라이언트가 ‘이 웹사이트에 연결하고 싶다’고 하면 서버는 어떤 인증서를 로드해야 하는지 알 수 있음)
• 서버는 클라이언트가 연결하려는 웹사이트에 맞는 SSL 인증서를 로드하여 트래픽을 암호화.
• 최신 로드 밸런서 (ALB, NLB) 및 CloudFront에서 사용 가능.
  • 구세대 클래식 로드 밸런서(CL)에서는 지원하지 않음.

• 클라이언트가 ALB에 연결하여 www.mycorp.com을 요청하면, ALB는 해당 도메인에 맞는 SSL 인증서로 트래픽을 암호화.
• 동일한 ALB에서 다른 클라이언트가 Domain1.example.com을 요청하면, ALB는 그에 맞는 SSL 인증서를 로드하고, 적절한 대상 그룹으로 트래픽을 연결.

SNI를 사용하면 여러 웹사이트에 대해 다른 SSL 인증서를 사용하면서도, 하나의 로드 밸런서로 여러 대상 그룹을 관리할 수 있음.

SNI를 사용하면 다른 SSL 인증서를 사용하는 서로 다른 웹사이트를 위한 여러 대상 그룹을 가질 수 있음

SNI를 통해 하나의 로드 밸런서가 여러 도메인에 대한 다양한 SSL 인증서를 사용할 수 있으며,
각 도메인에 맞는 대상 그룹과 연결해 줌으로써 웹사이트 트래픽을 안전하게 처리할 수 있음

 

 

 

😶 SSL 인증서에 지원되는 것

 

Classic Load Balancer (v1)

• 하나의 SSL 인증서만 지원
• 여러 SSL 인증서로 여러 호스트 이름을 사용하고 싶으면 클래식 로드 밸런서를 여러 개 쓰면 됨

Application Load Balancer (v2)

• 여러 SSL 인증서로 여러 리스너를 지원할 수 있음 (SNI 활용)

Network Load Balancer (v2)

• 여러 SSL 인증서로 여러 리스너 지원 가능 (SNI 활용)