[AWS] AWS 기술 정리 4편 고가용성 및 스케일링성(ELB, ASG) - (AWS SAA, Udemy 강의 정리)

https://aws.amazon.com/ko/certification

 

 이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate

 

고가용성과 확장성

`확장성 : 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있다.

  - 수직 확장성 : 인스턴스의 크기를 확장하는 것(scale up)... DB(RDS, ElastiCache)와 같은 분산되지 않는 시스템에서 사용... 하지만 하드웨어 한계로 고점 있음

  - 수평 확장성(탄력성) : 인스턴스나 시스템의 수를 늘리는 것(scale out), 분배 시스템이 있다는 것

 

`고가용성 : 애플리케이션 또는 시스템이 둘 이상의 AZ나 데이터 센터에서 가동 중인 것

 - 손실에서 살아남는게 목표

 - 자동일 필요는 없음 '수동형'도 있다.

 

ELB

로드밸런서

서버 혹은 서버셋으로 트래픽을 백엔드나 다수의 다운스트림 EC2 인스턴스 또는 서버로 전달하는 역할

- 단일 엑세스 지점을 제공

- 각 인스턴스의 정기적 health check 진행 ( 장애를 원활히 처리할 수 있음 )

- SSL 종점을 제공

- 쿠키로 고정도를 강화할 수 있음

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

 

Elastic Load Balancer

관리형 로드 밸런서, AWS가 관리어떤 경우에도 작동할 것을 보장 : AWS가 업그레이드, 유지 관리 및 고가용성 책임짐 / 다수의 AWS 서비스와 통합... EC2, ASG, ECS, ACM...

 

Health Checks : 제대로 작동 안하는 EC2에 대해 트래픽을 보내지 않음.. port와 route(/health)로 체크

- 200코드 미응답시, 상태가 좋지 않다 판단

 

ELB 종류

- Classic Load Balancer(v1, 2009) - CLB : 사용 권장 안함 HTTP/HTTPS, TCP, SSL

- Application Load Balancer(v2, 2016) - ALB : HTTP/HTTPS, WebSocket

- Network Load Balancer(v2, 2017) - NLB : TCP, TLS, UDP

- Gateway Load Balancer(2020) : GWLB : 3계층과 IP 프로토콜에서 작동

 

일부 로드밸런서 내부에 설정할 수 있어, 네트워크의 개인적 접근 가능

 

유저는 HTTP, HTTPS로 어디서든 LB에 접근가능

SG 설정상 아래와 같은 형태가 되어야 강력한 보안을 가짐.

 유저 - LB : 80/443 ANYWHERE 허용

 LB - EC2 : 80 LB에 대해서만 접근 허용(LB의 SG 자체를 Source로 설정)

 

ALB

7계층, HTTP 전용 로드 밸런서로 target 그룹으로 묶인 머신들 간 다수 HTTP 애플리케이션의 라우팅에 사용

동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산(컨테이너와 ECS 사용)

HTTP/2, WebSocket, redirects(HTTP로 들어오면 HTTPS로 트래픽 자동 리다이렉트) 지원

 

경로 라우팅 지원

- URL 대상 경로에 기반한 라우팅  (ex. example.com/users & example.com/posts)

- URL 호스트 이름에 기반한 라우팅 (ex. one.example.com & two.example.com)

- 쿼리 문자열과 헤더에 기반한 라우팅 ( example.com/users?id=1 )

 

마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 좋은 LB(Docker & EC2)

 - 포트 매핑 기능이 있어, ECS 인스턴스의 동적 포트로의 리다이렉션이 가능하기 때문

하나만으로 다수의 애플리케이션 처리 가능하단 장점

ALB는 탄력적 IP 주소를 연결할 수 없어서, 만약 쓰고 싶다면 NLB를 써야함(ALB는 정적 DNS 이름만 사용가능)

 

Target Group

- EC2 인스턴스 (ASG에 의해 관리) - HTTP

- ECS tasks (ECS에 의해 관리) - HTTP

- Lambda function 

- IP 주소 - 무조건 private IPs

 

ALB는 여러 대상 그룹으로 라우팅할 수 있으며, health check는 TG 레벨에서 이뤄짐

 

고정호스트 이름이 부여됨 (ex. XXX.region.elb.amazonaws.com)

애플리케이션 서버는 클라이언트의 IP를 직접 못 봄..

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

 - X-Forwarded-Port에서 포트, X-Forwarded-Proto에서 프로토콜이 삽입됨

 

리스너 규칙으로 조건을 추가해서 어떤 요청을 어디로 보낼지 설정할 수 있음

- ex) /error로 들어오는 요청을 다 고정응답으로 바꿀 수 있음

 

 

NLB

- 4계층, L4 로드밸런서로 TCP/UDP 트래픽을 다룰 수 있음

- 고성능 로드밸런서, 초당 수백만 건 요청 처리 + 지연시간도 100ms로 ALB(400ms)에 비해 짧음

- NLB는 AZ별로 하나의 고정 IP를 가짐, 탄력적 IP 주소를 각 AZ에 할당할 수도 있음, 여러 개의 고정 IP를 가진 애플리케이션을 노출할 때 유리함

ex) 1~3개의 IP로만 액세스할 수 있는 애플리케이션을 만들려면? NLB를 옵션으로 고려해야함

 

NLB 키워드 : 고성능, TCP/UDP, 정적IP

 

Target Group

- EC2 인스턴스

- IP 주소 - 반드시 하드코딩 & private IP

- ALB

 

`상태확인 프로토콜 

TCP / HTTP / HTTPS 프로토콜 지원

 

GWLB

배포, 확장, 타사 네트워크, 가상 어플라이언스 플릿 관리에 사용됨

네트워크 모든 트래픽이 방화벽을 통과하게 하거나, 침입 탐지 및 방지에 사용됨

VPC의 네트워크 라우팅 테이블이 업데이트 됨

- 모든 사용자 트래픽은 GWLB를 통과 

- 타겟그룹(서드파티 보안장비)로 트래픽이 분산됨

- 이상없으면 다시 GWLB로 보내지고, 최종적으로 어플리케이션으로 들어옴

 

L3, 네트워크 레이어에서 IP 패킷 단에서 동작

 

GWLB 역할

1. 투명 네트워크 게이트웨이 :  VCP의 모든 트래픽이 GWLB라는 단일 엔트리와 출구를 통과하기 때문

2. 로드밸런싱 : 대상 그룹의 가상 어플라이언스 집합에 전반적으로 트래픽 분산

 

`- UDP 6081번 포트 GENEVE 프로토콜 : 네트워크 가상화 지원하는 프로토콜로 GWLB가 이걸씀

 

Target Group

- EC2 인스턴스

- IP 주소 - 무조건 private IP

 

 

Sticky Session

고정성

- 로드밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것 (ex. A,B,C 유저가 있고 ALB로 묶인 인스턴스a,b가 있을 때, 유저A가 보낸 요청을 ALB가 인스턴스 a로 요청을 보냈다면, ALB에서 두번째 요청을 실행할 때도  같은 인스턴스로 보내는 것.)

- 쿠키를 써서 고정성과 만료기간 컨트롤

- 사용자 로그인과 같은 중요한 정보를 취하는 데이터를 잃지 않기 위해, 사용자가 동일한 백엔드 인스턴스에 연결되게함

- 고정성을 활성화하면, 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있는 단점 존재

 

고정성에 사용되는 쿠기

1. 애플리케이션 기반 쿠키

사용자 정의 쿠키

- 대상으로 생성됨

- 애플리케이션에 필요한 모든 사용자 정의 속성 포함 가능

- 쿠키 이름은 각 대상 그룹별로 개별적으로 지정해야함(단, AWSALB, AWSALBAPP, AWSALBBLG는 예약된 이름으로 사용 못함)

애플리케이션 쿠키

- 로드밸런서 자체에서 생성 ( 생성된 쿠키이름 : AWSALBAPP )

 

2. 기간 기반 쿠키

- 로드밸런서에서 자체 생성 ( AWSALB, AWSELB )

- 특정 기간을 기반으로 만료, 로드밸런서에서 정해줌.. (애플리케이션 기반 쿠키는 기간 지정 가능)

 

 

Cross-Zone Load Balancing

교차 영역 로드 밸런싱 : 각각의 로드밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배함 (ex. A 가용영역에 인스턴스 2개, B 가용영역에 인스턴스 8개 있을 때, 가용영역 상관없이 10%씩 트래픽을 받는 원리, 만약 안쓰면 A 가용영역 인스턴스는 25% 트래픽 부담, B 가용영역은 6.25%를 부담하는 원리)

 

ALB

기본적으로 교차 영역 로드 밸런싱이 활성화 되어 있음(TG에서 비활성화 가능)

데이터를 다른 AZ로 넘기는데 비용 안듬

 

NLB & GWLB

기본적으로 비활성화되어 있음

활성화하면, AZ 사이 데이터를 넘겨야해서 비용 발생

 

 

SSL/TLS

SSL 인증서 : 클라이언트와 로드밸런서 사이에서 트래픽이 이동하는 동안 암호화해줌(전송 중 암호화라고 함)

SSL이란 '보안 소켓 계층'을 의미하고 연결을 암호화하는데 사용함, TLS는 새로운 버전의 SSL로 '전송 계층 보안'을 의미. 최근에는 TLS가 많이 쓰이지만 편의상 SSL이라고 많이 부름

Public SSL 인증서는 CA(인증 기관)에서 발급함, 퍼블릭 SSL 인증서를 LB에 추가하면, 클라이언트와 로드밸런서 사이의 연결을 암호화할 수 있음

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

 

동작원리

1. 유저가 HTTPS로 LB에 접속하면, LB는 SSL을 종료 시킴

2. 백엔드에서는 HTTP로 EC2인스턴스와 통신(어짜피 private VPC 네트워크기 때문에 안전하게 보호됨)

 

- 로드밸런서는 X.509 인증서를 사용, SSL 또는 TLS 서버 인증서라고 부름

- AWS에는 ACM(AWS 인증서 관리자)가 존재

- 원한다면 내가 가진 인증서를 ACM에 업로드도 가능

- HTTPS 리스너 사용..

  - 다중 도메인 지원하려면 다른 인증서를 추가할 수도 있음

  - 클라이언트는 SNI(서버 이름 지정)를 써서 접속할 호스트의 이름을 알릴 수 있음

  - 원하는 보안 정책을 설정 가능 

 

SNI 

- 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해, 하나의 웹 서버가 여러개의 웹 사이트 지원하게 함

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

- 클라이언트가 접속할 웹사이트를 말했을 때, 서버는 어떤 인증서를 불러올지 알 수 있게 됨

- ALB & NLB & CloudFront에서만 동작함

 

ALB는 CLB와 다르게, SNI를 이용해 여러 개의 SSL 인증서를 두고, 다수의 리스너를 지원하게됨

 

 

`Connection Draining

연결 드레이닝(등록 취소 지연 이라고도 함)

- 인스턴스가 등록 취소, 비정상인 상태일 때, 인스턴스에게 시간을 주어 활성 요청을 완료할 수 있도록 하는 기능

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

(ex. 특정 EC2에 대해 드레이닝 요청을 하면, 기존 연결 및 기존 요청을 완료하고 작업이 끝나면 LB와 연결이 정지됨, 이때 다른 유저가 LB로 접속해도 드레이닝 상태인 EC2 인스턴스에는 요청을 보내지 않음)

- 1~3600초 사이의 값으로 설정(기본 300초).. 0으로 설정하면 비활성화

- 교체 작업 등에 사용

 

 

ASG

오토스케일링 그룹

- 스케일 아웃, 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나, 스케일 인, 감소한 로드에 맞춰 EC2 제거

- ASG에서 실행되는 EC2에 최소 및 최대 개수를 보장하기 위해, 매개변수를 전반적으로 정의할 수도 있음

- 로드밸런서와 연결하면 ASG 內 모든 EC2 인스턴스가 LB에 연결됨

- 비정상적인 인스턴스를 종료하고, 새 EC2 인스턴스를 생성함

 

시작 템플릿

인스턴스 속성 기반으로 ASG 생성시 '시작 템플릿'을 생성

- AMI, 인스턴스 유형 /  EC2 사용자 데이터 / EBS 볼륨 / SG; / Key Pair / IAM / Network&서브넷 / LB...

- 최소용량, 희망용량, 최대용량

- 스케일링 정책

 

CloudWatch 경보와의 통합 : 경보를 기반으로 스케일 아웃 가능, 평균 CPU나 사용자 지정 metric으로 판별함

온디멘드와 스팟 인스턴스 섞을 수도 있음

 

 

스케일링 정책

종류

1. 동적 스케일링

- 목표(대상) 추적 스케일링 : 'CPU 사용률/평균 연결 개수'과 같은 ASG 메트릭을 정의하고, 목표 값을 정하고 유지하는 것

- 단순 / 단계 스케일링 : 클라우드와치 알람을 정의하여, ASG에 용량 단위를 추가 or 제거하고자 할 때 알람이 발생하게 하는 것

 

2. 예약 스케일링

- 알려진 사용 패턴을 기반으로 스케일링을 예상할 수 있음 (ex. 특정 시간에 사용자가 몰리는 것 활용) 

 

3. 예측 스케일링

- 지속적으로 부하를 예측한 다음 미리 예약을 시작하는 경우, 반복되는 패턴이 있을 때 유용함

- 머신러닝 기반 과거 사례 분석으로 예측치를 생성하여 스케일링 작업을 예약함

 

사례

1. CPU 활용도 : 모든 인스턴스 평균 CPU가 높다면 인스턴스 활용도가 높다는 의미

2. 타겟당 요청 수 : 미해결 요청의 개수로 판별

3. 네트워크 사용량

4. 사용자 지정 메트릭 : 애플리케이션 별 고유 메트릭 가능

 

스케일링 쿨다운

- 스케일링 작업(인스턴스 추가/제거) 이후에 기본적으로 5분 쿨다운 시간에 들어감

- 쿨다운 시간 동안 ASG는 추가 인스턴스를 개시하거나 종료하지 않음

- 메트릭 안정화와 새로운 메트릭의 변화를 지켜보기 위함

- AMI를 이용해 EC2 인스턴스 설정 시간을 줄임으로서, 요청을 더 빠르게 처리할 수 있게 하는 것이 좋음(쿨 다운 시간이 줄어듬)