정의
AWS의 전문가들은 매일 고객과 함께 클라우드의 모범 사례를 활용하여 시스템을 설계합니다. 설계의 진화에 발맞춰 고객의 아키텍처에 더할 것과 뺄 것을 결정할 수 있도록 지원합니다. 그리고 고객이 이러한 시스템을 실제 환경에 배포하는 과정에서 해당 시스템의 성능 수준과 그러한 결정의 결과를 배우게 됩니다.
AWS는 이렇게 얻은 교훈을 토대로 고객 및 파트너가 아키텍처를 평가할 수 있는 일관적인 모범 사례 및 아키텍처가 AWS 모범 사례에 얼마나 잘 맞는지 평가할 수 있는 여러 가지 질문을 제공하는 AWS Well-Architected Framework를 개발했습니다.
AWS Well-Architected Framework는 운영 우수성, 보안, 신뢰성, 성능 효율성, 비용 최적화 및 지속 가능성이라는 6가지 원칙을 기반으로 합니다.
테이블 1. AWS Well-Architected Framework의 원칙
| 이름 | 설명 |
|---|---|
| 운영 우수성 | The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value. |
| 보안 | The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture. |
| 신뢰성 | The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS. |
| 성능 효율성 | The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve. |
| 비용 최적화 | The ability to run systems to deliver business value at the lowest price point. |
| 지속 가능성 | The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required. |
AWS Well-Architected Framework에서는 다음 용어를 사용합니다.
-
구성 요소는 요구 사항에 맞춰 함께 제공되는 코드, 구성 및 AWS 리소스입니다. 구성 요소는 대개 기술 소유권의 단위이며 각기 분리되어 있습니다.
-
워크로드는 비즈니스 가치를 제공하는 일련의 구성 요소를 식별하는 데 사용되는 용어입니다. 워크로드는 일반적으로 비즈니스 및 기술 책임자가 전달하는 세부 정보의 수준입니다.
-
아키텍처는 워크로드에서 구성 요소가 연동되는 방식입니다. 아키텍처 다이어그램은 주로 구성 요소들의 통신 및 상호 작용 방식을 중점적으로 다룹니다.
-
마일스톤은 설계, 구현, 테스트, 가동 및 프로덕션으로 이어지는 제품 수명 주기 전반에 걸쳐 아키텍처가 개선되는 과정에서 발생하는 주요 변화 시점을 표시합니다.
-
조직 내에서 기술 포트폴리오는 기업을 운영하는 데 필요한 워크로드 모음입니다.
-
작업 수준은 구현에 필요한 작업 시간, 활동 및 복잡성을 분류하는 것입니다. 각 조직이 조직의 유효 작업 수준을 적절하게 분류하려면 팀의 규모와 전문성, 추가 컨텍스트의 워크로드 복잡성을 고려해야 합니다.
-
높음: 이 작업을 완료하는 데는 몇 주 또는 몇 달이 걸릴 수 있으며, 여러 스토리, 릴리스 및 작업으로 나눌 수 있습니다.
-
중간: 이 작업을 완료하는 데는 며칠 또는 몇 주가 걸릴 수 있으며, 여러 릴리스 및 작업으로 나눌 수 있습니다.
-
낮음: 이 작업을 완료하는 데는 몇 시간 또는 며칠이 걸릴 수 있으며, 여러 작업으로 나눌 수 있습니다.
-
워크로드를 설계할 때는 업무 상황에 따라 이러한 원칙들을 절충해야 합니다. 이러한 비즈니스 의사 결정에 따라 엔지니어링 우선순위가 달라질 수 있습니다. 개발 환경의 신뢰성이 다소 낮아지더라도 지속 가능성에 미치는 영향을 개선하고 비용을 절감하도록 최적화하거나, 미션 크리티컬 솔루션의 경우 비용 및 지속 가능성에 미치는 영향이 증가하는 상황을 감수하고 신뢰성을 기준으로 최적화할 수 있습니다. 전자 상거래 솔루션의 경우 성능이 매출과 고객 구매 성향에 영향을 미칠 수 있습니다. 보안 및 운영 우수성은 일반적으로 다른 원칙과 절충 관계에 있지 않습니다.
