3) Reliability
- 안정성은 인프라나 서비스 중단에서 복구하고 수요를 충족하기 위해서 컴퓨팅 리소스를 동적으로 확보해
잘못된 구성이나 일시적 네트워크 문제와 같은 중단 문제를 완화시키는 것으로
어떤 상황에서도 애플리케이션이 실행되도록 함 - 안정성을 위한 설계 원칙이 존재
- 복구 절차를 테스트해야 하므로 다양한 장애를 자동으로 시뮬레이션하거나 이전에 장애를 일으킨 시나리오를 다시 생성
- 장애를 자동으로 복구해야 하므로 장애가 발생하기 전에 예측하고 조치를 취함
- 시스템 가용성을 높이거나 로드를 늘려야 하는 경우에는 수평으로 확장하고 용량을 추측하지 않으며 오토 스케일링을 사용
- 모든 것을 자동화로 변경해야 하며 이를 통해 안정성이나 롤백이 가능한지를 확인할 수 있음
Reliability AWS Services
- AWS 서비스 측면에서의 안정성
- 안정성 기반
IAM이 될 것이며 이는 계정에 피해를 줄 수 있는 너무 많은 권한을 갖지 않도록 하며 VPC는 네트워크의 강력한 기반
Service Limits(현재는 Service Quotas)는 서비스 제한 설정이 적합한지 확인하며 적당한 서비스 제한을 설정하고 모니터링해
서비스 제한에 도달하기 직전에 서비스를 중단할 수 없기 때문에 AWS에 연락해서 시간에 따라 서비스 제한을 늘림
Trusted Advisor는 서비스 제한을 보는 방식이나 강력한 기반을 얻기 위해 다른 항목을 살펴보는 방식에 관한 것 - 변경 관리
전반적인 변화를 관리하기 위해 오토 스케일링을 사용
CloudWatch는 데이터베이스와 애플리케이션의 지표를 확인해 안정성을 갖도록 하며 CPU 사용률이 높아지면 조치를 취함
CloudTrail과 Config는 보안의 측면에서 API 호출 추적이 안전한지 확인 - 장애 관리
백업을 사용해서 나쁜 상황이 발생한 경우 애플리케이션을 복구할 수 있는지 확인
CloudFormation은 한 번에 전체 인프라를 다시 생성하는 것
S3로 모든 데이터를 백업하며 S3 Glacier는 장기적으로 사용하지 않는 아카이브에 관한 것
안정성 있고 고가용성의 글로벌 DNS 시스템을 사용하기 위해서는 Route 53를 사용하며
장애가 발생한 경우 Route 53이 새 애플리케이션 스택을 가리키도록 해 애플리케이션이 재해 복구 메커니즘을 가질 수 있게 함
'Cloud > AWS' 카테고리의 다른 글
| [SAA] 다섯 번째 Pillar : 비용 최적화 (0) | 2022.05.07 |
|---|---|
| [SAA] 네 번째 Pillar : 성능 효율성 (0) | 2022.05.07 |
| [SAA] 두 번째 Pillar : 보안 (0) | 2022.05.07 |
| [SAA] 첫 번째 Pillar : 운영 효율성 (0) | 2022.05.07 |
| [SAA] Well Architected 프레임워크와 Well Architected 도구 개요 (0) | 2022.05.07 |
