AWS Well-Architected Framework
AWS Well-Architected Framework는 지짐서, 가이드라인이다.
- 특정 아키텍쳐가 클라우드 모법 사례와 잘 맞는지 이해할 수 있도록 설계 원칙 및 모범 사례를 문서화하고 있다.
- 6가지 pillars 구성
- 운영의 우수성( operational excellent)
비지니스의 가치가 충실하게 갖추어졌는가
원칙)
- 운영 업무 코드화
- 업데이트 조금식 되돌리기 가능
- 실패 가능성 예측
- 과거의 실패 사례를 축적해서 개선
(조직, 작동, 준비, 진화)
- 보안
보호하고 모니터링하는 시스템인가
원칙)
- 권한 정책 강력하게 구현
- 잘 추척하기
- 모든 레이어에 보안 적용하기
- 보안 적용 자동화
- 데이터 나가고 들어올 때 잘 보존
- 가능한 개발자, 관리자의 데이터 접근 최소화
- 보안 침해 대비
(보안,ID 및 액세스 관리, 탐지, 인프라 보호, 데이터 보호, 사고 대응)
- 안정성
시스템 일부가 오작동이나 망가지면 회복이 되는가?
(원칙)
- 장애 발생 시 자동 복구되도록
- 복구과정에서 test가능해야 한다.
- 사용자가 몰려 수요가 늘어나 워크로드의 처리량이 늘어나면 => 수평적 scaling적용
- 용량을 예측하지 않고 요구량의 증가에 따라서 scaling적용
- 업데이트 자동처리
(파운데이션, 워크로드 아키텍쳐, 변경관리, 고장 관리)
- 성능 효율성 (performance efficiency)
AWS 리소스를 효율적으로 사용하는가?
원칙)
- 최신 기술을 제공하는지 조사
- 성능
- lamdba와 같은 serverless를 많이 사용한다.
- 자주 실행해서 의사 결정해라
(선택, 장단점, 모니터링, 트레이드오프)
- 비용 최적화
불필요한 비용을 없애라
원칙)
- cloud financial management를 사용해라
- 비용 모델
- 비용 효율 계산
- 돈 낭비를 막아라
(클라우드 재무 관리 실습, 지출 및 사용에 대한 인식, 비용 효율적인 리소스, 수요 및 공급 리소스 관리)
- 유지
안정성과 가용성
Reliability
안정성 : 유저가 원할 떄 서비스의 기능을 제공할 수 있는지에 대한 지표
지정된 기간 동안 전체 시스템이 의도한 대로 작동할 확률
하드웨어, 펌웨어, 소프트웨어 포함 모두 시스템 구성
평균 고장 간격(MTBF) :
= 서비스 지속 시간/고장 횟수
= MTTF(실패시간) + MTTR(수리시간)
= 서비스로 구동되는 시간 + 고장으로 서비스 작동 안하는 시간
Availability
가용성 : 시스템이 정상적으로 작동하거나 시스템이 예상되는 작업을 올바르게 수행하는 시간의 백분율
정상 가동 시간 / 총시간 (1에 가까울 수록 좋음)
99.999999...%로 나타내면 9의 개수가 가용성을 의미
- High availability
고가용성 : 시스템은 사용 가능한 상태로 유지되는 동안 어느 정도의 성능 저하를 견딜 수 있음
최소한의 인력 개입
99% 는 분석관련 작업에서는 감당 가능
99.999%는 ATM등 금융 감당 가능
가용성의 원인
- 내결함성(fault tolerance) : 중단되어도 운영 상태 유지할 수 있는 기능
- 확장성(scalability) : 설계 변경하지 않고 용량 요구사항 증가 수용
- 복구가능성(recoverability) : 재해 발생 후 서비스 복원
워크로드와 애플리케이션의 가용성을 높이도록 설계가능하지만 비용 고려해야 한다.
AWS Trusted Advisor
온라인 에이전트로 자동으로 정보를 분석하고 보여준다.
5가지 범주에서 실시간 권장 사항을 제공한다. (비용 최적화, 성능, 보안, 내결함성, 서비스 제한)
(문제)
1. 다음 중 AWS Well-Architected 프레임워크의 성능 효율성 핵심 4가지 영역 중 하나가 아닌 것은 무엇입니까?
- 장단점
- 선택
- 추적 가능성
- 모니터
(추적 기능은 AWS Well-Architected 프레임워크의 성능 효율성 핵심 요소의 4가지 영역 중 하나가 아니다.- 4가지(장단점, 선택, 모니터, 트레이브오프)
- 다음 중 클라우드 기반 시스템을 설계할 때의 원칙은 무엇입니까?
- 긴밀하게 결합된 구성 요소 구축
- 빈번하지 않은 대규모 배치 변경
- 모든 구성 요소에서 장애가 발생한다고 가정
- 가능한 한 많은 서비스 이용
(모든 구성 요소에서 장애가 발생한다고 가정해야 합니다.)
- 다음 중 AWS Well-Architected 프레임워크의 원칙은 무엇입니까? (3개 선택)
- 보안
- 지속성
- 운영 우수성
- 비용 최적화
(AWS Well-Architected 프레임워크의 원칙은 운영 우수성, 보안 및 비용 최적화입니다.)
- 성능 효율성을 고려할 때 권장되는 설계 원칙은 무엇입니까?(2개 선택)
- 수요와 공급의 일치
- 서비리스 아키텍처 사용
- 고급 기술 대중화
- 추척 기술 활성화
- 지출 분석 및 귀속
(서버리스 아키텍처 사용 및 고급 기술 대중화는 성능 효율성을 고려할 때 권장되는 설계 원칙입니다.)
- AWS Trusted Advisor는 AWS 계정의 어떤 5가지 범주와 관련하여 통찰력을 제공합니까?
- 성능, 비용 최적화, 보안, 내결함성, 서비스 제한
- 보안, 액세스 제어, 고가용성, 성능, 서비스 제한
- 보안, 내결함성, 고가용성, 연결, 서비스 제한
- 성능, 비용 최적화, 액세스 제어, 연결, 보안
- AWS Well-Architected 프레임워크는 몇 개의 원칙으로 구성되어 있습니까?
- 3
- 4
- 6
- 위 항목 모두 해당하지 않음
- AWS 클라우드로 이전한 후에는 올바른 보안 설정이 적용되도록 해야 합니다. 보안 규정 준수에 도움이 되는 온라인 도구는 무엇입니까?
- Amazon Kinesis
- AWS Support
- AWS Trusted Advisor
- Amazon CloudWatch
(AWS trusted advisor는 aws 환경을 최적화함으로써 비용을 절감하고, 성능을 향상하며, 보안을 강화하는 데 도움이 되는 온라인 리소스이다.)
- 다음 중 사용자가 원하는 경우 기능을 제공할 수 있는 시스템의 능력을 측정하는 척도는 무엇인가요?
- 가용성
- 내결함성
- 안정성
- 성능 효율성
- 시스템의 일부 구성 요소가 작동하지 않아도 해당 시스템이 계속 작동할 수 있는 기능으로 정의되는 것은 무엇입니까?
- 높은 내구성
- 내결함성
- 고가용성
- 높은 내구성
(내결함성 fault tolerance는 시스템의 일부 구성요소가 작동하지 않아도 시스템이 계속 작동할 수 있는 기능이다.)
- 다음 중 어느 정도 성능 저하를 견디고, 가동 중지 시간을 최소화하며, 사람의 개입을 최소화할 수 있는 시스템을 가장 잘 설명한 것은 무엇입니까?
- 확장성
- 내결함성
- 탄력성
- 고가용성
(고가용성 시스템은 사람의 개입 없이도 항상 가용성이 보장된다.)
Hello