고가용성과 확장성
- 확장성 : 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있음
- 수직 확장성
- 인스턴스의 크기를 확장하는 것
- 예시 : 신입은 5개 처리할 때 경력직은 10개 처리 -> 신입을 경력직으로 대체
- t2.micro -> t2.large
- 데이터베이스와 같이 분산되지 않은 시스템에서 사용(RDS, ElastiCache)
- 하드웨어 제한이 걸려있음
- 스케일 업/ 다운
- 수평 확장성(탄력성)
- 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 것
- 예시 : 신입 5명을 신입 10명으로 확장
- 분산 시스템에 사용
- 스케일 아웃(인스턴스 수가 늘어날 때) / 인
- 고가용성
- 보통 수평 확장과 함께 사용되는 개념
- 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서의 손실에서 생존하는 것
- 예시 : A 지역에서 문제가 발생해도 B 지역에서는 계속 동작
- 다중 AZ가 활성화된 자동 스ㅔ일러 그룹이나 로드 밸런서에서 사용
로드 밸런서
- 서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할
- A, B, C 사용자 -> 일래스틱 로드 밸런서 -> EC2 A, EC2 B, EC2 C
- 사용자가 많아질 때 부하를 분산시키기 위한 목적
- 애플리케이션에 단일 액세스 지점(DNS)을 노출 -> 다운스트림 인스턴스의 장애를 원활히 처리
- 상태 확인 매커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인 가능(인스턴스 상태 확인 가능)
- SSL 종료 가능 -> 웹 사이트에 암호화된 HTTPS 트래픽을 가질 수 있음
- 클라우드 내에서 개인 트래픽과 공공 트래픽 분리 가능
Elastic Load Balancer
- 관리형 로드 밸런서
- AWS가 관리하며, 어떤 경우에도 작동할 것을 보장
- AWS가 업그레이드와 유지 관리 및 고가용성을 책임
- 무조건 쓰는 편이 좋음
- 자체 로드 밸런서를 마련하는 것보다 저렴 및 확장 편리
AWS 4 종류 로드 밸런서
- Classic Load Balancer(v1) - 2009년 - CLB - AWS에서 사라짐
- HTTP, HTTPS, TCP, SSL (secure TCP)
- Application Load Balancer(v2) - 2016 - ALB - AWS는 사용 권장O
- Network Load Balancer(v2) - 2017 - NLB
- TCP, TLS (secure TCP), UDP
- 레이어 4
- 높은 성능
- 각 AZ 하나 당 하나의 고장 IP
- 각 AZ에 탄력적 IP 할당 가능
- NLB -> ALB(NLB가 ALB 앞에 배치) : 고정 IP 주소를 얻을 수 있기 때문
- 상태 검사에서 세 가지 프로토콜 지원 : TCP, HTTP, HTTPS
- Gateway Load Balancer - 2020 - GWLB
- 3계층과 IP 프로토콜에서 동작(네트워크층에서 동작)
Load Balancer 보안 그룹
- 사용자 -> Load Balancer : Source : 0.0.0.0/0
- Load Balancer -> EC2 : Source : LoadBalancer의 보안 그룹
- Load Balancer IP(Private IP)
Application Load Balancer(ALB)
- HTTP 전용 로드 밸런서(7계층)
- 다수 HTTP 애플리케이션의 라우팅에 사용
- 컨테이너와 ECS 사용
- HTTP/2, WebSocket 지원
- 리다이렉트 지원(HTTP -> HTTPS로 트래픽 자동 리다이렉트 가능)
- 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 로드 밸런서(ECS, Docker)
- port 매핑 기능(ECS 인스턴스의 동적 포트로 리다이렉션)
- 하나로 다수의 애플리케이션 처리 가능
ALB 생성 화면(보안 그룹 추가 + 대상 그룹 추가
새로고침 할 때마다 다른 EC2 인스턴스가 활성화 되는 것을 확인할 수 있는 화면(1)
새로고침 할 때마다 다른 EC2 인스턴스가 활성화 되는 것을 확인할 수 있는 화면(2)
EC2 인스턴스의 보안 그룹
- launch-wizard-1 보안 그룹은 http, 0.0.0.0/0 이므로, 로드 밸런서의 DNS와 EC2 인스턴스의 퍼블릭 IPv4 주소 모두 접근 가능
- 로드 밸런서를 통해서만 인스턴스에 접근 가능하게 하려면 보안 그룹을 변경해야 함
launch-wizard-1 보안 그룹 소스를 sg-demo-load-balance로 변경
- 해당 화면 처럼 변경하면 로드 밸런서의 DNS 주소로만 인스턴스에 접근 가능함
ALB 리스너 규칙 추가
설정한 리스너를 보여주는 화면
/error path로 설정된 리스너
Sticky Session
- 클라이언트가 로드 밸런서에 두 번 요청할 때 백엔드에서 동일한 인스턴스가 요청에 응답하도록 함
- 예 : 요청자A, 요청자 B -> Load Balance -> EC2 Instance A, B일 때 요청자 A가 EC2 Instance A에 한 번 연결됐으면, 다음 요청도 Instance A로 전송
- 클라이언트가 로드 밸런서로 요청을 보낼 때 Cookie(스티키니스, 만료 날짜)도 전송
- 애플리케이션 기반 쿠키
- 커스텀 쿠키
- 사용자 정의 속성을 포함
- 쿠키 이름은 각 타겟 그룹마다 개별정 지정
- AWSALB, AWSALBAPPOR, AWSALBTG 이름 사용X(이미 ELB 자체에서 사용중)
- 애플리케이션 쿠키
- 로드 밸런서 자체에서 생성
- ALB에서 사용되는 쿠키 : AWSALBAPP
- 애플리케이션 자체에서 지속 시간 설정 가능
- 지속 시간 기반 쿠키
- 로브 밸런서에서 생성
- ALB에서 사용되는 쿠키 : AWSALB
- CLB에서 사용되는 쿠키 : AWSELB
- 특정 지속 시간에 따라 만료
Cookie 설정
AWSALB 쿠키가 요청 및 응답에 존재하는 것을 확인
SSL/TLS
- SSL(Secure Sockets Layer)
- 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 시킴 = 전송 중(in-flight) 암호화
- 데이터는 네트워크를 이동하는 중에는 암호화되고, 송신자와 수신자 측에서만 이를 복호화 가능
- 보안 소켓 계층을 의미하고 연결을 암호화는데 사용
- 만료 날짜가 존재해, 주기적으로 갱신해서 인증 상태 유지
- TLS(Transport Layer Security)
Load Balancer - SSL
- Users -(HTTPS) -> Load Balancer -HTTP private VPC-> EC2 Instance
- X.509 인증서 사용(SSL or TLS 서버 인증서)
- HTTPS
- HTTP 리스너를 구성할 때 반드시 HTTPS 리스너로 등록
- 클라이언트는 SNI(Server Name Indication)을 사용하여 접속할 소트의 이름을 알릴 수 있음
SNI
- 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해, 하나의 웹 서버가 여러 개의 웹 사이트 지원할 수 있게 함
- NLB, ALB, CloudFront만 지원
ASG(Auto Scaling Group)
- 웹 사이트나 애플리케이션을 배포할 때 웹 사이트 방문자가 갈수록 많아지면 로드가 바뀔 수 있는데, 이를 자동화
- Scale out : 증가한 로드에 맞춰 EC2 인스턴스 추가
- Scale in : 감소한 로드에 맞춰 EC2 인스턴스 제거
- 최소 및 최대 개수를 보장하기 위해 매개변수 정의 가능
- 로드 밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결
- 한 EC2 인스턴스가 비정상적으로 종료되면 이를 대체할 새 EC2 인스턴스 생성
- 무료(EC2 인스턴스와 같은, 생성된 하위 리소스에 대한 비용만 지불)
- 시작 템플릿 구성 요소
- AMI + 인스턴스 유형
- EC2 User Data
- EBS Volumes
- 보안 그룹
- SSH Key pair
- EC2 인스턴스의 IAM 역할
- 네트워크 및 서브넷 정보
- 로드 밸런서 정보 등
- 스케일링 정책 정의해야 함
CloudWatch Alarms & Scaling
- Alarm 기반으로 ASG를 Scale-in/out 가능
- 예 : 세 개의 EC2 인스턴스를 포함한 ASG가 존재할 때 경보가 울리면 Scale-out
- Alarm 기준 : 지표(모니터링 할 수 있는 평균 CPU나 원하는 사용자 지정 지표)
- ASG 전체의 평균 CPU가 너무 높으면 EC2 인스턴스 추가가 필요 -> Alarm -> ASG 스케일링 활동
ASG 생성
Auto Scaling Groups - 스케일링 정책
- 동적 스케일링
- 설정이 매우 간단
- CPU 사용률을 40%로 목표를 정하면 ASG가 40% 유지할 수 있게, 확장 축소
- 단순 또는 단계 스케일링도 존재
- 예약 스케일링
- 알려진 사용 패턴을 기반으로 스케일링 예상 가능
- 매주 일요일 마다 사용자가 급증하므로, 매주 일요일 마다 최소 용량 증가
- 예측 스케일링
- 지속적으로 부하를 예측한 다음 미리 예약을 시작하는 경우
- 반복되는 패턴이 있을 때 좋음(주기적 데이터)
CPU 과부화 테스트
