Summry
본 문서에서는 AWS Academy Cloud Foundations module 9(클라우드 아키텍처)를 정리한다.
서비스 별 기능과 개요에 대해 정리된 문서이므로 해당 서비스를 사용하기 위해선 AWS 가이드를 참조할 것
send me email if you have any questions.
AWS Well-Architected Framework
- 아키텍처는 큰 구조물을 설계하고 구축하는 예술이자 과학이다. 대규모 시스템의 아키텍트는 시스템의 규모와 복잡성을 관리해야 한다.
- AWS는 수많은 고객의 AWS 기반 아키텍처를 검토한 끝에 Well-Architected Framework를 개발했다. 아래 다섯 가지 원칙으로 구성되며 각 원칙에는 일련의 설계 원칙과 모범 사례가 포함되어 있다. 또한 Well-Architected 를 위한 체크리스트를 제공한다.
- 운영 우수성
- 보안
- 안정성
- 성능 효율성
- 비용 최적화
1. 운영 우수성 원칙
-
비즈니스 가치를 실현하고 지원 프로세스 및 절차를 지속적으로 개선하기 위해 시스템을 실행 및 모니터링 한다.
-
운영 우수성 설계 원칙
- 코드로 작업을 수행하면 인적 오류를 제한하고 이벤트에 일관되게 응답할 수 있다.
- 빌드가 나올 때마다 주석이 추가된 설명서를 생성하는 작업을 자동화하는 데 중점을 둔다.
- 구성 요소의 주기적 업데이트가 가능하도록 워크로드를 설계해야 한다. 실패할 경우 되돌릴 수 있는 작은 단위로 변경을 수행한다.
- 운영 절차를 변경하면서 이러한 절차를 개선하고 업데이트할 기회를 모색한다. 가능한 실패 원인을 탐색하여 사전에 제거하거나 완화한다. 정기적으로 장애 시나리오를 테스트하고 이러한 장애의 영향을 이해하고 있는지 검증한다.
- 습득한 내용을 팀과 조직 전체에 공유한다.
-
운영 우수성 체크리스트
2. 보안 원칙
-
위험 평가 및 완화 전략을 통해 비즈니스 가치를 제공하면서 정보, 시스템 및 자산을 보호한다.
-
보안 설계 원칙
- 최소 권한의 원칙을 구현하고 AWS 리소스와의 각 상호 작용에 적절한 권한을 부여함으로써 직무 분리를 시행한다.
- 환경에서 수행되는 작업과 변경 사항에 대한 실시간 모니터링 알림 및 감사 기능을 사용, 로그와 지표를 시스템에 통합하여 자동으로 대응하고 조치를 취한다.
- 심층 방어를 적용하고 아키텍처의 모든 계층, 예를 들어 엣지 네트워크, 가상 사설 클라우드, 서브넷 및 로드 밸런서, 모든 인스턴스 운영체제 및 애플리케이션에 보안 제어를 적용한다.
- 보안 메커니즘을 자동화하여 확장 및 축소를 신속하고 경제적이며 안전하게 수행하는 기능을 개선한다.
- 데이터를 민감도에 따라 분류하고 암호화, 토큰화 및 액세스 제어와 같은 메커니즘을 적절히 사용한다.
- 인적 오류로 인해 민감한 데이터가 손실되거나 수정되는 위험을 줄여야 함. 데이터에 직접 액세스하거나 데이터를 수동으로 처리해야 하는 필요성을 줄이거나 없애는 메커니즘과 도구를 만든다.
- 조직의 요구 사항에 적합한 Incident(사건, 사고) 관리 프로세스를 마련할 것. Incident 대응 시뮬레이션을 실행하고 자동화를 포함한 도구를 사용하여 탐지, 조사 및 복구 속도를 높인다.
-
보안 원칙 체크리스트
3. 안정성 원칙
-
장애를 예방하고 신속하게 복구하여 비즈니스 및 고객의 요구를 충족
-
안정성 원칙
- 시스템 장애를 테스트하고 복구 절차를 검증한다.
- 시스템의 주요 성능 지표를 모니터링하고 임계값 위반 시 자동 복구를 트리거하도록 시스템을 구성한다.
- 단일의 대규모 리소스를 다수의 소규모 리소스로 대체하고 이러한 소규모 리소스에 요청을 분산하여 단일 지점의 장애가 전체 시스템에 미치는 영향을 줄인다.
- 수요 및 시스템 사용량을 모니터링하고 리소스 추가 또는 제거를 자동화하여 수요를 충족하는 최적의 수준을 유지한다.
- 자동화를 사용하여 인프라 변경을 수행하고 자동화를 통해 변경을 관리한다.
-
안정성 원칙 체크리스트
4. 성능 효율성 원칙
-
컴퓨팅 리소스를 효율적으로 사용하여 시스템 요구 사항을 충족하고, 수요가 변하고 기술이 진화함에 따라 이러한 효율성을 유지한다.
-
성능 효율성 설계 원칙
- 기술을 서비스로 소비한다. 예를 들어 SQL Database, 미디어 트랜스코딩, 머신 러닝과 같은 기술은 기술 커뮤니티에서 쉽게 찾을 수 없는 전문성이 요구되는 기술이다. 클라우드에서는 이러한 기술을 서비스로 사용할 수 있다. 기술을 소비함으로써 팀은 리소스 프로비저닝 및 관리 대신 제품 개발에 집중할 수 있다.
- 여러 AWS 리전에 시스템을 배포하여 지연 시간을 줄이고 최소한의 비용으로 고객 경험을 선사한다.
- 서버 실행 및 유지 관리로 인한 운영 부담 없이 기존의 컴퓨팅 활동을 수행할 수 있다. 관리형 서비스는 대규모로 운영되기 때문에 서버리스 아키텍처에서는 트랜잭션 비용도 절감된다.
- 다양한 유형의 인스턴스, 스토리지 또는 구성을 비교하는 테스트를 수행한다.
- 달성하려는 목표에 가장 적합한 기술 접근 방식을 사용한다. 예를 들어 데이터베이스 또는 스토리지에 대한 접근 방식을 선택할 때는 데이터 액세스 패턴을 고려한다.
-
성능 효율성 체크리스트
5. 비용 최적화 원칙
-
가장 낮은 가격으로 비즈니스 가치를 제공하도록 시스템을 실행한다.
-
비용 최적화 설계 원칙
- 필요한 컴퓨팅 리소스에 대해서만 비용을 지불한다. 정교한 예측을 사용하는 대신 비즈니스 요구 사항에 따라 사용량을 늘리거나 줄인다.
- 워크로드의 비즈니스 결과를 측정하고 이 결과를 실현하는 것과 관련된 비용을 측정한다. 이 측정을 사용하여 결과를 늘리고 비용을 줄여 얻을 수 있는 이점을 파악한다.
- AWS는 서버를 랙에 설치하고, 스태킹하고 전원을 공급하는 등의 작업 부담을 덜어준다. 따라서 IT 인프라가 아니라 고객과 비즈니스 프로젝트에 집중할 수 있다.
- 클라우드에서는 시스템 사용량과 비용을 쉽고 정확하게 파악하고 IT 비용을 개별 워크로드 사용자에게 알릴 수 있다. 이 기능을 사용하면 투자 수익률을 측정하고 워크로드 소유자에게 리소스를 최적화하고 비용을 줄일 수 있는 기회를 제공할 수 있다.
- 클라우드에서 관리형 및 애플리케이션 수준 서비스는 이메일 전송이나 데이터베이스 관리 등의 작업을 위해 서버를 유지 관리해야하는 운영상의 부담을 해소해준다. 관리형 서비스는 클라우드 규모에서 운영되기 때문에 클라우드 서비스 공급자가 더 저렴한 트랜잭션 또는 서비스당 비용을 제공할 수 있다.
-
비용 최적화 체크리스트
안정성 및 가용성
- AWS Well-Architected Framework에서 제시하는 모범 사례 중 하나는 장애 즉, 애플리케이션/워크로드 중지에 대비한 계획을 수립하는 것이다.
- 클라우드 아키텍트가 장애를 견디도록 아키텍처를 설계할 때 고려하는 두 가지 중요한 요소는 안정성과 가용성이다.
안정성
- 모든 것에서 항상 장애가 발생할 수 밖에 없으므로 통계적 방식으로 안정성을 생각해야 한다.
-
안정성 지표 이해
- 월요일 정오에 온라인 상태로 전환되는 애플리케이션이 있고 정상 작동하다가 금요일 정오에 장애가 발생한다. 금요일 정오부터 월요일 정오까지 애플리케이션에서 장애가 발생한 이유를 진단하여 복구한다.
- 평균 장애 시간(MTTF) 또는 애플리케이션을 사용할 수 있는 시간은 96시간
- 평균 복구 시간(MTTR)은 72시간
- 평균 장애 간격(MTBF)은 168시간 또는 1주일.
- 월요일 정오에 온라인 상태로 전환되는 애플리케이션이 있고 정상 작동하다가 금요일 정오에 장애가 발생한다. 금요일 정오부터 월요일 정오까지 애플리케이션에서 장애가 발생한 이유를 진단하여 복구한다.
가용성
- 시스템 구성 요소의 장애는 시스템 가용성에 영향을 미친다.
- 예정된 중단과 예정되지 않은 중단을 포함하여 애플리케이션이 정상적으로 작동하지 않을 때마다 가용성이 저하된다.
- 일반적으로 가용성을 개선하면 비용이 증가한다.
- 환경의 가용성을 높일 방법을 고려할 때는 개선 비용과 사용자에게 돌아가는 혜택 간에 균형을 맞추는 것이 중요하다.
-
가용성 계층
-
가용성에 영향을 미치는 요인
고가용성
- 고가용성 시스템이란 성능이 어느 정도 저하되더라도 시스템이 사용 가능한 상태로 유지되는 시스템을 말한다.
- 고가용성 시스템에서는 가동 중지 시간이 최소화되고 사람의 개입이 거의 필요하지 않는다.
- 고가용성 시스템은 서로 유기적으로 작동하면서 필수 서비스를 보장하는 시스템 전체의 공유 리소스 집합이라고 할 수 있다.
AWS Trust Advisor
-
AWS에서 아키텍처를 설계하고 검토하는 데 사용할 수 있는 도구
- Cost Optimization - 리소스 사용량을 분석하고 사용하지 않는 유휴 리소스를 제거하거나 예약 용량을 약정하여 비용을 최적화할 수 있도록 권장 사항을 제시
- Performance - 서비스 제한을 점검하고 프로비저닝된 처리량을 확인하며 초과 사용되는 인스턴스를 모니터링하여 서비스 성능을 개선하는 권장 사항을 제시할 수 있다.
- Security - 기능 공백 및 활성화가 필요한 다양한 AWS 보안 기능을 식별하여 애플리케이션의 보안을 개선하는 데 도움이 되는 권장 사항을 제기한다. 사용자의 권한도 검사한다.
- Fault Tolerance(내결함성) - 자동 조정, 상태 확인, 다중 AZ 배포 및 백업 기능을 활용하여 AWS 애플리케이션의 가용성과 이중화를 개선할 수 있는 권장 사항을 제시한다.
- Service Limits - 서비스 제한의 80%가 넘는 서비스 사용량이 있는지 점검한다. 값은 스냅샷을 기반으로 하므로 현재 사용량과 다를 수 있다. 제한 및 사용량 데이터의 변경 사항이 반영되는 데 최대 24시간이 걸릴 수 있다.
PREVIOUSmodule 8(데이터베이스)