[SAA] Load Balancer

확장성

• 시스템이 부하에 맞춰 적절히 조절됨 (확장 혹은 축소)
• 수평적 확장: 인스턴스의 개수를 확장. 탄력적
• 수직적 확장: 인스턴스의 성능을 확장. 간단함

가용성

• 서비스를 오래 유지해서 운영하는 것
• 서비스 가용시간과 밀접한 관계

고가용성

• 일반적으로 수평적 확장과 밀접한 연관
• 애플리케이션이 2개 이상의 데이터 센터 또는 가용영역에서 운영되는 것을 의미

서비스 별 고가용성

• EC2
  • 성능을 높여서 수직적 확장
  • Auto Scaling group을 멀티 AZ로 적용하여 수평적 확장 (로드 밸런서가 멀티 AZ)
• RDS
  • 이중화로 멀티 AZ 지원

---

로드 밸런서

• 서버에 트래픽 분산
• 공개된 접근 포인트를 노출
• 장애, 부하 핸들링
• 헬스 체크
• 고가용성
• pubilc 트래픽을 private으로 분할하는 역할 (라우터처럼)

헬스 체크

• 인스턴스가 요청을 받을 수 있는 상태인지 확인
• 포트 번호 + 루트로 구성 (domain.com:[port]/[root])
• HTTP 상태 코드를 기준으로 판단 (ex. 201 created를 반환하면 일반적으로 정상값이지만, 헬스 체크를 200 ok로 받으면 201도 실패라고 판단)

Elastic Load Balancer

• AWS에서 제공하는 관리형 로드 밸런서
• 유연성은 떨어지지만 가격과 관리 효율이 좋다.
• Security Group을 기반으로 요청 허용 여부 핸들링

---

Classic Load Balancer

• deprecated
• TCP, HTTP, HTTPS 지원 (4, 7 계층)
• 고정된 호스트 이름

---

Application Load Balancer

• HTTP, HTTPS, Web Socket 지원 (7계층)
• 여러 머신(Target group)에 대해 부하를 분산시킴
• 한개 머신의 여러 인스턴스에 부하를 분산시킴 (컨테이너 등에 사용, 1개의 노드 내의 n개의 파드)
• HTTP/2, Web socket 지원
• 리다이렉트 지원
• 호스트 명 고정
• 타겟 그룹 IP는 외부 공개 X
• IP 대신 호스트 기준이라 유연함
• 인스턴스는 헤더의 X-Forwarded-[]를 사용하여 클라이언트(ALB)의 IP, 포트를 알 수 있다.

ALB 라우팅

• CLB와 다르게 ALB는 로드 밸런싱 + 라우팅 기능을 제공
• 타겟 그룹은 라우팅 테이블 별로 구성
• 타겟 그룹들은 url 기반, host명 기반, 쿼리 스트링 / 헤더 기반으로 라우팅 구분 가능

ALB - Target Group

• EC2 인스턴스 - HTTP 기반 타겟 그룹
• EC2 태스크
• 람다 함수
• IP 주소 (private)
• 하나의 ALB가 여러 타겟 그룹과 엮일 수 있다. (라우팅)
• 헬스 체크는 타겟 그룹 단위로 진행 (타겟 그룹 내부의 하나 인스턴스에 대해 체크)

ALB 사용

• Container 기반 애플리케이션
• 마이크로 서비스
• ECS의 다이나믹 포트에 대응하기 위해 포트 매핑 지원 (포트포워딩)
• 1 ALB per 1 인스턴스가 필요 없음 (그룹을 통해)
• 즉, 하나의 ALB가 있으면 알맞게 요청을 흘려 보냄

---

Network Load Balancer

• TCP, TLS, UDP 지원 (4계층)
• ALB보다 빠른 지연시간 (layer가 낮으므로. C가 python보다 빠른 것과 같다)
• 고성능 워크로드를 설계할 때 사용함. (게임을 C로 짜는 것처럼)
• 프리 티어로는 사용 불가
• target group과 TCP 또는 HTTP로 통신
• 클라이언트와는 TCP 기반으로 통신
• 여러 개의 target troup과 상호작용 가능

NLB - Target Group

• EC2
• IP 주소 (private)
• ALB

---

Gateway Load Balancer

• IP 지원 (3계층)
• 가상 어플라이언스를 위한 로드밸런서
• 배포, 확장, 관리 용이성을 위해 설계
• 단일 인입 / 반환 지점
• GENEVE 프로토콜(port 6081) 사용

GWLB - Target Group

• EC2
• IP 주소 (private)

---

Sticky Session

• 동일한 클라이언트가 동일한 인스턴스에서 이어서 처리하도록 유도
• 세션 유지 시간 설정 가능
• 사용 시 트래픽 분할이 분균등할 수 있음 -> 세션 유지 시간 적절히 조정할 것.
• CLB / ALB에서는 쿠키를 기반으로 동일 클라이언트에 대한 요청 확인

Sticky Session - 쿠키

• 애플리케이션 별로 커스텀 쿠키 세팅 가능 (다양한 용도에 맞게)
• 타겟 그룹 내에서는 독립적인 이름 필요
• AWSALBAPP은 자동으로 생성되는 쿠키이름
• AWSALB는 자동으로 생성되는 기간단위 쿠키 이름

---

Cross-Zone Load Balancing

• 가용 영역 간 로드 밸런싱이 가능한가?

ALB

• 기본적으로 사용 설정이 켜져 있음
• 대상 그룹 단위로 껐다 킬 수 있음
• AZ 간 데이터 전달에 추가 비용이 발생하지 않음.

NLB, GWLB

• 기본으로 사용 설정 꺼짐
• 켜면 추가 비용 발생

CLB

• 기본으로 꺼짐
• 켜도 비용 없음

---

SSL, TLS

SSL

• 클라이언트와 LB 간의 통신을 암호화
• 연결을 암호화하기 위한 용도
• CA를 통해 발급
• 만료일자가 지나면 주기적으로 업뎃
• 보통 레거시에서 사용

TLS

• SSL보다 최신임. 이걸 씁시다.

HTTPS 리스너

• 기본 인증서 설정 필요
• 도메인 별로 추가적인 인증서 등록 가능. (ALB의 경우 여러 도메인이 적용될 수 있으므로 전부 따로 셋팅 가능)
• 클라이언트는 SNI를 통해 도착지 호스트명 식별 가능
• 레거시 인증서에 대한 지우너

SNI

• 여러개의 SSL 인증서가 하나의 웹서버에서 동작할 때 적절한 인증서를 로딩하기 위해 사용
• ex. ALB가 하나인데, 서로 다른 두 도메인으로 라우팅하고, 별도의 인증서가 필요한 경우
• SSL 핸드쉐이크 초기화 과정에서 진행함.
• ALB / NLB / Cloudfront에서 사용 가능.
• CLB에서는 동작하지 않음. 어차피 호스팅 없으므로

LB에서의 SSL 인증

• AWS에서 관리하는 AWS Certified Manager를 통해 인증 관리 가능
• 회사에서 갖고 있는 인증이 있으면 그거 사용 가능
• 로드 밸런서에 HTTPS 리스너를 장착하게 됨

CLB에서의 SSL 인증

• SSL 인증만 지원
• 호스트네임이 다르면 인증서도 여러개 필요함 ㅋㅋ

ALB, NLB에서의 SSL 인증

• SNI를 통해 여러개의 리스너와 인증서 등록 가능

---

Connection Draining

• 요청을 처리하는 과정 중에 인스턴스가 내려간 경우, 즉 인스턴스가 unhealthy한 상태에서 연결된 요청을 종료하는 방식
• unhealthy한 인스턴스에 대해 요청 중단 (de-register)
• [0, 3600]초만큼 요청 완료되기까지 대기 (설정하면 기본적으로 30초, 0초면 설정 안하는 것)
• 적절한 값을 셋팅하자.