AWS SAA - Scalability & Availability

Scalability & High Availability

확장성 : 어플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있는 정도

• Vertical Scalability
  • 인스턴스의 크기를 확장
  • 데이터베이스 등 분산되지 않은 인스턴스에 적합
  • 한계가 존재한다
• Horizontal Scalability (elasticity)
  • 인스턴스의 개수를 확장
  • 분배 시스템이 있다는 것을 의미

고가용성 : 어플리케이션이 자신의 기능을 정해진 시간 동안 충분히 제공하는 능력

• 다수의 AZ나 리전에 걸쳐서 어플리케이션을 운영
• 분산 배치 방식을 사용한 EC2 인스턴스

Load Balancing

Load Balancing 이란 서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스로 전달해주는 역할을 한다.

어플리케이션에 단일 액세스 지점 (DNS) 를 노출하게 된다.

다운스트림 인스턴스들의 장애를 쉽게 대응할 수 있다.

Health Checks

인스턴스가 정상적으로 동작하고 있는지 확인하기 위해 사용된다.

protocol, port, endpoint 를 이용하여 확인하고, 헬스 체크 결과가 정상이 아니면 트래픽을 전송하지 않는다.

Classic Load Balancer

2009년에 만들어진, HTTP, HTTPS, TCP, SSL, secure TCP를 지원하는 구형 로드 밸런서이다.

즉, 레이어 4와 레이어 7을 동시에 로드 밸런싱한다.

따라서 상태 확인 또한 TCP 혹은 HTTP 기반으로 이루어진다.

Deprecated 되었다.

Application Load Balancer

2016년에 만들어진, HTTP, HTTPS, Web Socket 프로토콜을 지원하는 로드 밸런서이다.

레이어 7 전용 로드 밸런서이다.

여러 타겟 그룹간 다수 HTTP 어플리케이션의 라우팅에 사용된다.

경로 라우팅을 지원한다.

• URL 대상 경로에 기반한 라우팅
• URL의 hostname 에 따른 라우팅
• 쿼리 문자열과 헤더에 따른 라우팅

따라서 마이크로서비스나 컨테이너 기반 어플리케이션에 가장 좋은 로드 밸런서이다.

Network Load Balancer

2017년에 만들어진, TCP, TLS (secure TCP), UDP 프로토콜을 지원하는 로드 밸런서이다.

레이어 4의 로드밸런서이며, TCP와 UDP를 인스턴스로 전달한다.

매우 고성능이며 ALB보다 지연 시간이 훨씬 짧다.

가용 영역당 1개의 고정 IP (혹은 EIP)를 외부에 노출한다.

CLB나 ALB같이 호스트네임 기반이 아니라, IP 기반의 접근이다.

ALB와 결합하게 되면, 고정 IP를 가질 수 있다는 장점이 있다.

Gateway Load Balancer

2020년에 만들어진, 네트워크 레이어 (레이어3)에서 작동하는 로드 밸런서이다.

배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.

사용자의 트래픽 요청을 서드파티 security virtual appliance 타겟 그룹으로 보낸 다음,
이상이 없다면 다시 해당 트래픽을 받아서 어플리케이션에게 전송한다.

네트워크 트래픽을 분석하는 데에 주로 쓰인다.

IP 패킷의 네트워크 계층인 레이어 3에서 작동한다.

GENEVE 프로토콜을 포트 6081에서 실행한다.

Sticky Sessions

로드 밸런서에 한 사용자는 기존과 같은 인스턴스로 연결됨을 의미한다.

이는 CLB나 ALB에서 작동하는 방식이다.

cookie가 이러한 stickiness를 달성하는 데 사용된다.

사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않게끔 한다.

Application-based Cookie

• Custom cookie
  • 어플리케이션에서 생성됨
  • AWSALB, AWSALBAPP, AWSALBTG 등의 이름을 사용하면 안된다.
• Application cookie
  • 로드밸런서에 의해 생성됨
  • 쿠키 이름은 AWSALBAPP이다.

Duration-based Cookie

• 로드밸런서에 의해 생성됨
• AWSALB 혹은 AWSELB 이름을 가진다.

Cross-Zone Load Balancing

교차 영역 로드 밸런싱을 활성화하면, 전체 가용 영역에 등록된 모든 인스턴스에 전반적으로 고르게 트래픽이 분포된다.

이를 활성화하지 않으면, 트래픽은 ELB가 존재하는 노드의 인스턴스에게로만 분배된다.

• ALB에서 항상 활성화되어있다. (끌 수 없다)
  • 다른 가용 영역으로 데이터가 이동한다고 비용이 추가되지는 않는다.
• NLB에서 기본으로 꺼져 있지만 킬 수 있다.
  • 만약 사용하게 되면 가용 영역간 데이터 이동은 비용이 부과된다.
• CLB에서 기본으로 꺼져 있지만 킬 수 있다.
  • 다른 가용 영역으로 데이터가 이동한다고 비용이 추가되지는 않는다.

SSL 인증서

ELB에서의 SSL 적용 절차는 다음과 같은 특성을 가진다.

• 로드 밸런서가 X.509 인증서(SSL/TLS server certificate) 를 불러온다.
• AWS 에서 ACM을 사용해 SSL을 관리할 수 있다.
• 또다른 외부 인증서 또한 ACM으로 업로드할 수 있다.
• HTTPS 리스너를 지정할 때는 기본 인증서를 지정해야 한다.
  • 클라이언트는 SNI (Server Name Indication) 를 통해 도달하는 호스트 이름을 지정할 수 있다.
• 원하는 경우 HTTPS에 특정한 보안 정책을 설정할 수 있다.

SNI : Server Name Indication

한 웹 서버 상에 다수의 SSL을 발급해 한 웹 서버 상에 다수의 SSL 인증서를 발급해 단일 웹 서버가 여러 개의 웹 사이트를 제공하도록 하는 문제를 해결한다.

클라이언트가 어떤 호스트로 연결하고자 하는지 명시해야 해당 SSL로 handshake가 이루어진다.

ALB나 NLB, CloudFront에서만 적용이 가능하다.

CLB에서는 다수의 SSL 인증서에 따른 여러 hostname을 지원하려면 CLB가 여러 개 존재해야 한다.

Connection Draining

CLB에서는 이 기능을 Connection Draining (연결 드레이닝) 이라고 하며, ALB나 NLB에서는 이를 Deregistration Delay (등록 취소 지연) 이라고 부른다.

인스턴스가 등록 취소, 혹은 비정상적인 상태에 있을 때, 인스턴스에 어느 정도에 시간을 주어 활성 요청을 완료할 수 있도록 하는 기능이다.

등록 취소 상태가 된 인스턴스에게로는 ELB가 트래픽을 보내지 않게 된다.

Auto Scaling Group

웹사이트나 어플리케이션을 배포할 때 수시로 변화하는 로드에 따라 인스턴스 생성 종료를 자동화하는 기능이다.

• 로드 증가 시 스케일 아웃 (EC2 인스턴스 증가)
• 로드 감소 시 스케일 인 (EC2 인스턴스 감소)
• 동작 중인 EC2 인스턴스 수의 최소 최대 값 설정
• 로드 밸런서에 새로운 인스턴스를 자동으로 등록
• 인스턴스의 헬스 체크를 통해 새 EC2 인스턴스로 교체 가능

ELB가 EC2 인스턴스에 대해 Health Check를 시행하고 이 결과를 Auto Scaling Group에 전달할 수 있다.

Attributes

인스턴스 속성을 기반으로 ASG를 생성하는 일련의 규칙 정의

Launch Configuration은 deprecated 되었다. 이는 한번 작성되면 수정이 불가능하며, 새로 재작성해야한다.

Launch Template 의 구성 요소는 다음과 같다.

• AMI + Instance type
• EC2 User Data
• EBS Volumes
• Security Groups
• SSH Key Pair
• IAM Roles for your EC2 Instances
• Network + Subnets Information
• Load Balancer Information
• and so on..

Minimum Capacity : ASG 내의 최소 인스턴스 용량

Desired Capacity : ASG 내의 희망 용량

Maximum Capacity : ASG 내의 최대 인스턴스 용량

Scaling Policies : 스케일링 정책

CloudWatch Alarm에 따라서 ASG가 스케일될 수 있다.

CloudWatch의 메트릭 요소 (평균 CPU활성화율 등) 를 감시하고, 기준점이 넘으면 스케일링이 트리거된다.

Dynamic Scaling Policies

• Target tracking scaling : 대상 추적 스케일링
• Simple / Step scaling : 단순 / 단계 스케일링
• Scheduled actions : 스케쥴된 스케일링

Predictive Scaling

지속적으로 자동으로 추후 로드를 예측하고 스케일링을 계획하는 것

Good metrics to scale on

• CPUUtilization
  • 평균 CPU 활성화율
• RequestCountPerTarget
  • 대상별 요청의 수
• Average Network In/Out

Scaling Cooldowns

인스턴스의 추가삭제를 막론하고 스케일링 작업이 끝나면, 기본적으로 5분의 쿨다운 기간을 가지는 것이다.

ASG Advanced

ASG Default Termination Policy

가장 많은 인스턴스가 있는 AZ를 찾고 나서, 가장 오래된 launch configuration이나 launch template 가 있는 인스턴스를 종료한다.

ASG Lifecycle Hooks

ASG에서 인스턴스가 실행되자마자 서비스가 시작되지만, 인스턴스를 실행할 때 발생하는 긴 프로세스가 존재한다.

따라서 인스턴스가 실행되면 보류 상태가 되고, 보류 상태에서 수명 주기 후크를 정의하면 보류:대기, 보류:진행 단계를 거치게 된다.
종료 또한 종료:대기, 종료:진행 단계를 거치게 된다.

이를 이용하면 특별한 소프트웨어 설치나, 로그 전송 등 특수한 작업을 정의할 수 있다.