Cross-Zone Load Balancing

- 교차 영역 로드 밸런싱을 쓰면, 각각의 로드 밸런서 인스턴스가 모든 가용 영역에 등록 된 인스턴스에 트래픽을 50씩 균등하게 분배
- 인스턴스 수가 10개니까 균등하게 10씩 할당 받음

- 영역을 교차하지 않고 부하를 분산, Elastic 로드 밸런서 노드의 인스턴스로 분산
- 트래픽 분산 방법은 사진과 같음, 특정 영역에 트래픽이 더 분산됨
- 정답은 없다, 상황에 맞게 고려해서 사용하면 된다
- ALB는 기본적으로 교차 영역 로드 밸런싱이 활성화
- 따라서 AZ 간의 데이터 이동에 비용이 들지 않음
- NLB와 GWLB는 기본적으로 교차 영역 로드 밸런싱이 비활성화
- 활성화 하려면 비용 지불해야 함, AZ 사이 데이터를 옮기려면 비용이 발생하므로
- CLB는 기본적으로 교차 영역 로드 밸런싱 비활성화
- 활성화시켜도 AZ 간 데이터 이동 비용 발생하지 않음
SSL/TLS
- SSL 인증서
- 클라이언트와 로드 밸런서 사이 트래픽이 이동하는 동안 암호화 ( in-flight encrypton )
- 데이터는 네트워크 이동 중 암호화, 송신자와 수신자 측에서만 복호화 가능
- SSL은 '보안 소켓 계층'을 의미, 연결을 암호화 하는 데 사용
- TLS는 '전송 계층 보안'을 의미, 새로운 버전의 SSL
- 최근에 주로 사용, 하지만 여전히 SSL이라고 불림, 같은 의미
- 퍼블릭 인증서는 인증 기관(CA)에서 발급
- 퍼블릭 SSL 인증서를 로드 밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화 가능
- SSL 인증서는 만료 날짜 존재, 주기적으로 갱신 필요
SSL 동작

- 사용자가 HTTPS 통해 접속 (S가 붙은 건 SSL 인증서 사용해 암호화 되어 있다는 뜻)
- 인터넷을 통해 로드 밸런서 접속시, 로드 밸런서 내부에서 SSL Termination 수행
- 백엔드에서는 HTTP로 EC2 인스턴스와 통신 ( 암호화 X 상태 )
- 로드 밸런서는 X.509 인증서 사용, SSL or TLS 서버 인증서라고 부름
- AWS에는 해당 인증서들을 관리하는 ACM (AWS 인증서 관리자)가 있음
- 개인이 소유하고 있는 인증서를 ACM에 업로드 가능
- HTTP listener
- 기본 인증서 지정
- 다중 도메인 지원을 위해 다른 인증서 추가 가능
- 클라이언트는 SNI (서버 이름 지정)을 사용해 접속할 호스트 이름을 지정 가능
- 사용자가 원하는 보안 정책 지정 가능
SNI
- 여러 개의 SSL 인증서를 하나의 웹 서버에 로드
- 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있게 해줌
- 확장된 프로토콜, 클라이언트가 Target 서버 호스트 이름을 지정하도록 함
- 클라이언트가 지정하면 서버는 어떤 인증서를 로드해야 하는지 알 수 있다
- ALB, NLB, CloudFront에서만 작동
- 즉, 어떤 로드 밸런서에 SSL 인증서가 여러 개 있다면 ALB or NLB라는 뜻

SSL 실습
- EC2 > Load balancers > LB name > Add listener
- 각종 설정 사항 선택 ( 포트 번호, SSL 보안 정책 등 ..)

Connection Draining (시험 출제 !! )
- Deregistration Delay - for ALB & NLB
- 인스턴스가 등록 취소, 혹은 비정상 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 활성 요청( in-flight requests )를 완료할 수 있도록 하는 기능
- Connection Draining되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않음

- Connection Draining 파라미터는 매개변수로 표시 가능
- 1 to 3600 second (default : 300 seconds )
- 이 값을 0으로 설정하면 비활성화
- 짧은 요청의 경우 낮은 값으로 설정하면 좋음
- 그래야 EC2 인스턴스가 빠르게 드레이닝되고, 오프라인 상태가 되어 교체 작업을 할 수 있음
Auto Scaling Group (ASG)
- 증가한 로드에 맞춰 EC2 인스턴스 추가 (Scale out)
- 감소한 로드에 맞춰 EC2 인스턴스 제거 (Scale in)
- 따라서 ASG 크기는 시간이 지나면서 변함
- 또한 ASG에서 실행되는 EC2 인스턴스의 최소 및 최대 개수를 설정할 수도 있음
- 로드 밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결 됨

- 한 인스턴스가 비정상이면 종료하고 대체할 새 인스턴스를 생성
- ASG는 무료..!!, EC2 인스턴스와 같은 하위 리소스에 대한 비용만 지불하면 됨

- Launch Template

- +Min / Max Size / Initial Capacity
- +Scaling Policies
CloudWatch Alarms & Scaling
- Cloudwatch 경보 기반으로 ASG를 Scale in&out 가능
- 사용자 정의 지표(Custom Metric)을 통해 경보가 울림
- 평균 CPU 등을 지표로 설정
- 경보에 의해 내부적으로 자동적인 스케일링(in&out) 이루어짐

Auto Scaling Group (ASG) 실습
- 모든 인스턴스 종료
- EC2 > Auto Scaling 그룹 > Auto Scaling 그룹 생성
- 각 단계별 설정 후 생성

- 새로운 인스턴스가 스케일 아웃 (생성) 됨을 확인할 수 있다
- ASG 생성시 설정 용량에 맞게 생성 됨


- Target Group에서 ASG에 의해 생성된 EC2인스턴스가 ALB에 등록되어 있음을 확인 가능

- 만약 인스턴스가 계속 비정상 상태면 해당 인스턴스 종료 후 새 인스턴스 생성, (생성시 ASG가 비정상 인스턴스 종료하도록 설정했음)
- 생성후에도 편집을 통해 용량을 조정할 수 있음

Auto Scaling Group (ASG) 정책
- Dynamic Scaling Policies
- Target Tracking Scaling
- 가장 단순하고 설정하기 쉬움
- ex) 평균 CPU 사용률 추적하여 40%에 머물수 있게함
- 기본 기준선을 세우고 상시 가용이 가능하도록 하는것
- Simple / Step Scaling
- CloudWatch 경보를 설정, 한 번에 추가할 유닛의 수와, 제거할 유닛의 수를 단계별 설정 필요
- ex) 전체 ASG에 대한 CPU 사용률이 70% 초과하는 경우 2개의 유닛을 추가하도록 설정 가능, 그 반대도 가능하다
- Scheduled Actions
- 나와 있는 사용 패턴을 바탕으로 스케일링을 예상
- ex) 금요일 오후 5시 큰 이벤트가 예정되어 있다
따라서, ASG 최소 용량을 매주 금요일 오후 5시마다 자동으로 10까지 늘리도록 설정하는 것
- Predictive Scaling
- load를 보고 다음 스케일링을 예상하는 것
- 예측을 기반으로 스케일링 작업이 예약됨

Good metrics to scale on

Scaling Cooldown
- 스케일링 작업이 끝날 때 마다 (추가 삭제 상관 없이) Cooldown period를 가짐 ( default 300 seconds )
- cooldown 기간에는 ASG가 추가 인스턴스를 실행 또는 종료할 수 없음
- 스케일링 작업 발생시 기본적으로 설정된 Cooldown이 있는지 확인 필요
Auto Scaling Group (ASG) 정책 실습
- 스케일링 종류 3가지 확인

- Scheduled Actions

- Predictive Scaling
- 머신러닝 기반 스케일링

- 지표 선택 종류

- Dynamic Scaling Policies

- Target Tracking Policy 생성한 모습

- CPU 사용률 100% 되도록 Stress 주어 스케일링 작동 상태 확인
- Google에 'install stress Amazon Linux2' 입력
- 깃헙에 들어가 두 번째 명령 복사해서 인스턴스에 입력, stress 설치 (2023 ver 부터는 두 번째 명령만 설치하면 됨)
- ' sudo yum install stress -y '

- ' stress -c 4 ' 명령 실행으로 4개의 vCPU 사용하게끔 동작 (사용률 100 %)

- 경보 발생 확인

- Target Tracking Policy에 따른 추가 인스턴스 생성 확인

- CloudWatch > 경보에서 동작 상태 확인 가능
- 인스턴스 재부팅 후(CPU 동작 정상화) 인스턴스 삭제 되는 모습
