AWS SAA - The Reliability Pillar (안정성 원칙)

The Reliability Pillar (안정성 원칙)

AWS Certified Solutions Architect Study Guide - Associate (SAA-C02) EXAM 요약

 

개요

안정성 (reliability) & 복원성 (resiliency) : 어플리케이션이 실패를 회피하거나 실패 발생 시 신속히 회복할 수 있는 능력

가용성 계산하기

가용성은 100%에서 해당 인스턴스들의 실패 비율을 차감하는 방식으로 계산.
세 개의 EC2 인스턴스로 중복구현되어 있을 때, 개별 EC2 인스턴스 가용성이 90%이라면
100% - (10% * 10% * 10%) = 99.9%

전통적인 or 네이티브 어플리케이션

전통적인 어플리케이션의 가용성

기존 Linux 또는 Windows 에서 실행되는 어플리케이션
EC2 인스턴스를 통해 실행되며, 데이터베이스를 직접 관리하거나 RDS를 사용하기도 함.

강한 의존성 관계

hard dependencies

중복구현 요소

redundant components

클라우드 네이티브 어플리케이션의 가용성

AWS와 같은 특정 클라우드 플랫폼의 리소스를 활용하기 위해 만들어진 어플리케이션
Lambda 함수를 활용한 서버리스 어플리케이션이나, S3에 객체를 저장하거나 DynamoDB를 사용하는 경우.

리소스 용량 제한의 파악

용량 제한 (service limits) 은 서비스에 따라 다르다.

• 네트워크 처리용량
• 초당 S3 PUT 요청횟수
• 리전당 인스턴스의 수
• 리전당 일래스틱 IP 주소의 수

AWS Trusted Advisor를 사용해 서비스 용량 제한을 확인.

가용성 높이기

실제 어플리케이션의 가용성 수준은 버그 발생, 메모리 누수, 데이터베이스 오류 등으로 더욱 낮아질 수 있다.

하나의 대규모 인스턴스에서 호스팅하지 말고, 서로 다른 AZ에 다수의 중소규모 인스턴스를 분산 배치하자.
또한, 적절한 시기에 실패한 인스턴스를 대체하는 새로운 인스턴스를 배포해야 한다.

 

EC2 Auto Scaling

수요 증가세에 맞추어 인스턴스를 추가
어플리케이션의 실패 상황에 대한 대응 및 신속한 복원 기능 또한 제공

시작 환경설정과 시작 템플릿을 사용하여 Auto Scaling 구현.

Auto Scaling Group

스케일링 그룹 생성 시, 시작 환경설정 또는 시작 템플릿을 이용해 그룹을 생성.

• 최소 용량 (Minimum) : 성능을 유지하기 위해 지켜야 할 최소 인스턴스
• 최대 용량 (Maximum) : 성능을 유지하기 위해 지켜야 할 최대 인스턴스
• 희망 용량 (Desired Capacity) : 그룹 크기라고도 하며, 온도 조절기처럼 작동함

스케일링 그룹 생성 시, ALB 타겟 그룹에 추가하면 추후 생성되는 인스턴스들이 자동으로 ALB 타겟 그룹에 추가됨

인스턴스의 헬스 체크

특정 인스턴스의 상태가 나빠질 경우 Auto Scaling은 해당 요소를 폐기하고 새 인스턴스를 추가.

로드 밸런서를 사용하는 경우, 로드 밸런서의 타겟 그룹에 대한 헬스 체크를 하도록 설정할 수 있다.
Auto Scaling Group이 이들 헬스 체크 정보를 반영할 수 있다.

Auto Scaling Option

수동 스케일링

그룹 생성 후 최소 용량, 최대 용량, 희망 용량을 직접 조절하면 그 즉시 반영.

동적 스케일링

성능 지표에 따라 사전 정의한 정책에 의해 스케일링

심플 스케일링

지표가 기준치를 초과하면 아래 조정 수칙만큼 증가

• ChangeInCapacity : 지정된 수량만큼 용량을 증가
• ExactCapacity : 지정된 수량으로 인스턴스 총 개수를 조절
• PercentChangeInCapacity : 현재 용량의 대한 비율로 수량을 증가

위 증감 작업이 끝나면, 기본 300초인 cooldown period 를 가진다.

스텝 스케일링

기준치를 초과하는 성능에 맞추어 다양한 단계별로 조절.

각 단계별 조절 (step adjustment) 은 다음과 같은 내용으로 이루어진다.

• 경계 하한선
• 경계 상한선
• 조정 타입
• 희망 용량 증가분

기본 300초인 warm-up time 을 설정하여 새로운 인스턴스를 추가하기 전 대기 시간 설정이 가능.

타겟 추적 정책

지표와 목표 값을 설정하면 CloudWatch Alarm 및 스케일링 정책을 생성하고 해당 지표의 목표 값에 맞춰 조절.

스케일 아웃은 물론, 지표 수준에 맞춰 인스턴스의 수를 줄이는 스케일 인 또한 지원.

warm-up 타임을 설정할 수 있다.

예약 작업

예약 작업은 워크로드 패턴이 예측 가능할 때 유용.

• 최소 및 최대 용량, 희망 용량
• 시작 날짜 및 시간

위 두 가지를 설정함으로서, 트래픽의 주기적 급증 혹은 마케팅 이벤트 등에 유연하게 대응 가능.

 

데이터 백업과 복원

AWS는 데이터의 내오류성 및 복원성을 위한 다양한 기법은 물론, 데이터 손실 발생 시 이를 복구하기 위한 백업을 제공한다.

S3

One-Zone IA 를 제외한 모든 S3 스토리지 클래스가 멀티 AZ 에 객체를 분산 저장.

데이터 삭제 및 데이터 손상을 방지하려면 S3 버저닝 기능을 활성화.

멀티 AZ 실패 또는 리전의 실패로부터 데이터를 보호하기 위해 크로스 리전 복제 기능을 활성화.

Elastic File System

EFS 는 EC2 인스턴스와 온프레미서 서버 간의 파일 공유를 가능케 하는 관리형 NFS (Network File System).

EFS 는 리전 내 멀티 AZ 환경에 데이터를 저장.

데이터 손실 또는 변조를 방지하기 위해 개별 파일을 동일 리전 내 S3 버킷 또는 다른 EFS에 백업할 수 있다.
또한 AWS Backup Service를 이용해 정해진 스케쥴에 따라 EFS에 백업 생성이 가능.

Elastic Block Storage

EBS 는 리전 내 멀티 AZ 환경에 볼륨을 자동으로 복제하여 개별 AZ 실패 상황에 대비함
하지만 데이터 변조 위협은 여전히 존재.

EBS 스냅샷을 직접 생성하거나 Amazon Data Lifecycle Manager를 이용해 주기적으로 스냅샷 생성 가능

EBS 볼륨 폐기 시 로컬에 저장된 어플리케이션 로그도 삭제되기에, CloudWatch Logs 를 통해 확인 가능

데이터베이스의 복원성

자체 RDBMS 사용시 해당 데이터베이스 엔진의 백업 기능을 이용한다.
S3 또는 Glacier 에 저장하여 데이터를 보호할 수 있다.

RDS

Amazon RDS 의 경우 데이터베이스 스냅샷만 생성하면 된다.

복원하는 작업은 몇 분이 소요되며, 복원 후 새로운 데이터베이스 인스턴스가 생성됨

복원성을 높이기 위해 멀티 AZ 에 데이터베이스를 배포

기본 인스턴스와 여러 대기 인스턴스를 두며, 동기적으로 복제할 수 있다.

Amazon Aurora 는 세 개 AZ 에 데이터베이스를 저장하고, 최대 15개까지의 복제본을 지원한다.

DynamoDB

멀티 AZ에 테이블을 저장한다.

따라서 저지연성, 고성능의 NoSQL 데이터베이스 서비스 제공 가능

글로벌 테이블을 사용하여 멀티 리전에 테이블 복제 가능

기준시점 복구 (point-in-time recovery) 를 설정해 자동으로 백업 생성 가능

 

복원성 네트워크 생성하기

VPC 셜계 시 고려사항

리소스에 충분한 IP 주소를 할당할 수있도록 충분한 크기의 CIDR 블록 생성하기

서브넷 생성 시 CIDR 블록에 충분한 여유 공간을 두기

• 멀티 티어 아키텍처 구현
• 미래의 AZ 추가 상황에 대응

복원성을 지닌 외부 연결

어플리케이션의 가용성은 네트워크의 가용성에 의존한다.

사용자의 인터넷은 전송 속도나 지연 속성 등에 변동성이 많다.

Direct Connect, VPC Peering, VPN 등을 이용하여 보조 연결이 가능하다.

 

가용성을 고려한 설계

99% 가용성을 위한 설계

• 단일 EC2 인스턴스 : 어플리케이션 및 셀프호스팅 SQL 데이터베이스
• S3 버킷 : 버저닝 기능 활성화를 통해 데이터베이스 백업 지원
• S3 Glacier : 구 버전의 데이터를 저장
• Route 53 : 헬스 체크 및 페일오버 지원

가용성 계산

실패 상황 발생 시 30분간의 분석 및 결정 시간을 가진다.
CloudFormation 템플릿을 이용해 새 인스턴스 생성까지 10분 소요.
데이터베이스 복원에 30분 소요.

총 다운타임, 혹은 복원 목표 시간 (RTO, Recovery Time Objective) 은 70분이 된다.

복원 목표 시점 (RPO, Recovery Point Objective) 은 어플리케이션이 분기당 1회 실패 상황에 놓인다 가정한다.

따라서 총 280분의 실패 대응 시간에, 연간 6회, 각 4시간의 서비스 및 운영체제 업데이트 시간이 있다고 가정하면,
연간 다운타임은 28.6시간이 되고, 이는 99.67%의 가용성을 의미한다.

99.9% 가용성을 위한 설계

• 멀티 AZ 환경, 멀티 인스턴스의 EC2 인스턴스 관리
• ALB 와 AutoScaling 을 이용하여 트래픽 분산 및 증감 대응

99.99% 가용성을 위한 설계

• 두 개의 리전에 인스턴스를 추가하여, 패시브 리전을 운영
• MySQL 또는 MariaDB의 멀티 AZ read replica 기능을 생성해 다수의 리전에 배포

 

코멘트

비용과 작업 난이도가 문제인 것이지, 배운 기능을 때려박을 수록 가용성과 안정성이 높아진다.

대신 각각이 어떤 것에 특화되어 있는지, 제약사항은 무엇인지 알아 두어야 고객이 가장 필요로 하는 것을 선택할 수 있을 터.