# AWS Well-Architected Framework
게시 날짜: **2023년 4월 10일**([문서 개정](document-revisions.md))
AWS Well-Architected Framework를 활용하면 AWS에서 시스템을 구축하면서 내리게 되는 결정의 장단점을 이해할 수 있습니다. 이 프레임워크를 사용하면 클라우드에서 안정적이고 안전하며 효율적이고 경제적이며 지속 가능한 시스템을 설계하고 운영하기 위한 설계 모범 사례를 알아볼 수 있습니다.
## 소개
AWS Well-Architected Framework를 활용하면 AWS에서 시스템을 구축하면서 내리게 되는 결정의 장단점을 이해할 수 있습니다. 이 프레임워크를 사용하면 AWS 클라우드에서 안전하고 안정적이며 효율적이고 경제적이면서 지속 가능한 워크로드를 설계하고 운영하기 위한 설계 모범 사례를 알아볼 수 있습니다. 또한 모범 사례를 기준으로 아키텍처를 일관적으로 측정하고 개선할 영역을 식별할 수 있습니다. 아키텍처 검토 프로세스는 아키텍처 결정에 대한 구조적인 대화이며 감사 메커니즘이 아닙니다. 시스템을 제대로 설계하면 비즈니스 성공 가능성을 높일 수 있습니다.
AWS 솔루션스 아키텍트는 광범위한 업종 및 사용 사례에 걸쳐 오랫동안 솔루션을 설계해 왔습니다. AWS(은)는 수천 고객의 AWS 아키텍처를 설계하고 검토해 왔습니다. 그리고 이러한 경험을 바탕으로 클라우드 시스템 설계의 모범 사례와 핵심 전략을 밝혀냈습니다.
AWS Well-Architected Framework 설명서에는 특정 아키텍처가 클라우드 모범 사례에 적합한지를 파악하는 데 도움이 되는 기본적인 질문이 다수 수록되어 있습니다. 이 프레임워크를 이용하면 클라우드 기반의 현대적 시스템에 대해 고객이 기대하는 품질 기준에 따라 일관적인 방식으로 시스템을 평가하고 그러한 품질을 달성하기 위해 필요한 수정 조치를 확인할 수 있습니다. AWS(이)가 진화를 거듭하고 Amazon이 고객과의 협력을 통해 점점 더 많은 지식을 쌓아가면서 앞으로도 Well-Architected 개념을 더욱 정교하게 가다듬고자 합니다.
이 프레임워크는 최고 기술 책임자(CTO), 아키텍트, 개발자와 같은 기술 업무 담당자와 운영 팀원을 위해 작성되었습니다. 클라우드 워크로드를 설계하고 운영할 때 사용할 AWS 모범 사례와 전략에 대해 설명하고 구현 세부 정보 및 아키텍처 패턴에 대한 링크를 제공합니다. 자세한 내용은 [AWS Well-Architected 홈페이지](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp)를 참조하세요.
AWS에서는 워크로드 무료 검토 서비스도 제공됩니다. [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/?ref=wellarchitected-wp)(AWS WA Tool)은 AWS Well-Architected Framework를 사용하여 아키텍처를 검토 및 측정하는 일관된 프로세스를 제공하는 클라우드 서비스입니다. AWS WA Tool은 워크로드를 더 안정적이고 안전하며 효율적이고 경제적으로 만드는 권장 사항을 제공합니다.
모범 사례를 적용할 수 있도록 모범 사례를 구현한 실무 경험이 포함된 설명서 및 코드 리포지토리를 제공하는 [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp)를 만들었습니다. 또한 [AWS Well-Architected 파트너 프로그램](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp)의 멤버인 AWS 파트너 네트워크(APN) 파트너를 선택하여 팀을 구성했습니다. 이러한 AWS 파트너는 풍부한 AWS 지식을 보유하고 있으며, 이를 통해 워크로드를 검토하고 개선하는 데 도움을 줄 수 있습니다.
# 정의
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 리소스입니다. 구성 요소는 대개 기술 소유권의 단위이며 각기 분리되어 있습니다.
+ **워크로드**는 비즈니스 가치를 제공하는 일련의 구성 요소를 식별하는 데 사용되는 용어입니다. 워크로드는 일반적으로 비즈니스 및 기술 책임자가 전달하는 세부 정보의 수준입니다.
+ **아키텍처**는 워크로드에서 구성 요소가 연동되는 방식입니다. 아키텍처 다이어그램은 주로 구성 요소들의 통신 및 상호 작용 방식을 중점적으로 다룹니다.
+ **마일스톤**은 설계, 구현, 테스트, 가동 및 프로덕션으로 이어지는 제품 수명 주기 전반에 걸쳐 아키텍처가 개선되는 과정에서 발생하는 주요 변화 시점을 표시합니다.
+ 조직 내에서 **기술 포트폴리오**는 기업을 운영하는 데 필요한 워크로드 모음입니다.
+ **작업 수준**은 구현에 필요한 작업 시간, 활동 및 복잡성을 분류하는 것입니다. 각 조직이 조직의 유효 작업 수준을 적절하게 분류하려면 팀의 규모와 전문성, 추가 컨텍스트의 워크로드 복잡성을 고려해야 합니다.
+ **높음:** 이 작업을 완료하는 데는 몇 주 또는 몇 달이 걸릴 수 있으며, 여러 스토리, 릴리스 및 작업으로 나눌 수 있습니다.
+ **중간:** 이 작업을 완료하는 데는 며칠 또는 몇 주가 걸릴 수 있으며, 여러 릴리스 및 작업으로 나눌 수 있습니다.
+ **낮음:** 이 작업을 완료하는 데는 몇 시간 또는 며칠이 걸릴 수 있으며, 여러 작업으로 나눌 수 있습니다.
워크로드를 설계할 때는 업무 상황에 따라 이러한 원칙들을 절충해야 합니다. 이러한 비즈니스 의사 결정에 따라 엔지니어링 우선순위가 달라질 수 있습니다. 개발 환경의 신뢰성이 다소 낮아지더라도 지속 가능성에 미치는 영향을 개선하고 비용을 절감하도록 최적화하거나, 미션 크리티컬 솔루션의 경우 비용 및 지속 가능성에 미치는 영향이 증가하는 상황을 감수하고 신뢰성을 기준으로 최적화할 수 있습니다. 전자 상거래 솔루션의 경우 성능이 매출과 고객 구매 성향에 영향을 미칠 수 있습니다. 보안 및 운영 우수성은 일반적으로 다른 원칙과 절충 관계에 있지 않습니다.
# 아키텍처
온프레미스 환경에서 고객은 종종 다른 제품 또는 기능 팀에 대한 중첩되는 역할을 통해 모범 사례를 따르는지를 확인하는 기술 아키텍처에 대한 중앙 집중형 팀을 보유하고 있습니다. 일반적으로 기술 아키텍처 팀에는 테크니컬 아키텍트(인프라), 솔루션스 아키텍트(소프트웨어), 데이터 아키텍트, 네트워킹 아키텍트 및 보안 아키텍트와 같은 일련의 역할이 포함됩니다. 이러한 팀에서는 대개 [TOGAF](http://pubs.opengroup.org/architecture/togaf9-doc/arch/?ref=wellarchitected-wp) 또는 [Zachman Framework](https://www.zachman.com/about-the-zachman-framework?ref=wellarchitected-wp)를 엔터프라이즈 아키텍처 기능의 일부로 사용합니다.
AWS(은)는 해당 기능을 중앙 팀을 두어 집중화하지 않고, 각각의 개별 팀에 나눠 주는 것을 선호합니다. 의사 결정 권한을 분산하게 될 경우, 개별 팀이 내부 기준을 충족하도록 관리해야 하는 등 여러 위험 요소가 생기게 됩니다. AWS는 2가지 방법으로 이러한 위험을 완화합니다. 첫째로, 각 팀이 해당 기능을 갖추는 방법을 중점적으로 설명하는 *사례*(작업 수행 방식, 프로세스, 표준 및 용인된 규범)를 도입하고, 팀이 충족해야 하는 표준에 대한 기준을 높일 수 있는 전문가를 배치합니다. 둘째, 자동화된 검사를 수행하여 표준이 충족되는지 확인하는 *메커니즘*을 구현합니다.
****
“좋은 의도만으로는 부족합니다. 무언가를 해내려면 좋은 메커니즘이 필요한 법이죠.“ - Jeff Bezos.
이 말은 사람의 노력을 규칙이나 프로세스 준수 여부를 확인하는 메커니즘(종종 자동화됨)으로 대체하는 것을 의미합니다. 이러한 분산된 접근 방식은 [Amazon 리더십 원칙](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp)에 근간을 두고 있으며, 고객으로부터 출발하는 *거꾸로 일하는* 문화를 모든 역할에 걸쳐 조성합니다. 거꾸로 일하기는 혁신 프로세스의 기본 요소입니다. AWS는 고객 및 고객이 원하는 것에서부터 출발하며, 이를 기반으로 작업을 정의하고 방향을 잡습니다. 고객 중심의 팀은 고객의 요구 사항에 대응하여 제품을 개발합니다.
아키텍처 측면에서, 이는 모든 팀이 아키텍처를 생성하고 모범 사례를 따르는 기능을 갖추고 있음을 의미합니다. AWS는 새로운 팀이 이러한 기능을 확보하거나 기존 팀이 기준을 높이도록 돕기 위해, 설계를 검토하고 AWS 모범 사례가 무엇인지 이해하는 데 도움을 주는 수석 엔지니어 가상 커뮤니티에 액세스할 수 있게 해줍니다. 수석 엔지니어 커뮤니티는 모범 사례를 가시화하고 쉽게 액세스할 수 있도록 최선을 다합니다. 예를 들어 모범 사례를 실제 사례에 적용하는 데 중점을 둔 간략한 회의를 통해 이를 수행합니다. 이러한 회의 내용은 기록되어 새 팀원을 위한 온보딩 자료의 일부로 사용할 수 있습니다.
AWS의 모범 사례는 수천 개의 시스템을 인터넷 규모로 운영한 경험에서 비롯된 것입니다. AWS는 데이터를 사용하여 모범 사례를 정의하는 것을 선호하지만, 수석 엔지니어와 같은 주제 전문가를 활용하여 설정하기도 합니다. 수석 엔지니어가 새로운 모범 사례를 확인하게 되면 커뮤니티로 활동하여 팀이 이를 따를 수 있도록 안내합니다. 시간이 지나면서 이러한 모범 사례는 내부 검토 절차 및 규정 준수를 시행하는 메커니즘으로 공식화됩니다. Well-Architected 프레임워크는 내부 검토 프로세스를 고객 중심으로 구현한 결과이며, 주요 현장에서 활동하는 솔루션스 아키텍처 및 내부 엔지니어링 팀에서 엔지니어링 사고를 체계화한 것입니다. Well-Architected 프레임워크는 이러한 결과를 활용할 수 있는 확장 가능한 메커니즘입니다.
AWS는 아키텍처를 분산 담당하는 주요 엔지니어링 커뮤니티의 접근 방식을 따르면, 고객 요구 사항 중심 Well-Architected 엔터프라이즈 아키텍처가 실현될 수 있다고 믿습니다. 모든 워크로드 전반에 걸쳐 Well-Architected 검토를 수행하는 기술 리더(CTO 또는 개발 관리자)를 두면, 기술 포트폴리오의 위험을 더 효과적으로 이해할 수 있습니다. 이 접근 방식을 사용하면 수석 엔지니어가 특정 영역에 대한 사고방식을 여러 팀과 공유할 수 있는 메커니즘, 교육 또는 간략한 회의를 통해 조직에서 해결 가능한 전반적인 주제를 식별할 수 있습니다.
# 일반 설계 원칙
Well-Architected Framework는 다음과 같은 여러 가지 일반 설계 원칙을 확립하여 우수한 클라우드 설계를 촉진합니다.
+ **필요 용량에 대한 추측 불필요**: 워크로드를 배포할 때 용량을 잘못 결정하면 결과적으로 고가의 유휴 리소스를 방치하게 되거나 제한된 용량으로 인한 성능 문제를 처리해야 하는 이중고를 겪습니다. 하지만 클라우드 컴퓨팅에서는 이러한 문제가 사라집니다. 필요한 만큼 용량을 많이 또는 적게 사용하다가 자동으로 확장하거나 축소할 수 있기 때문입니다.
+ **프로덕션 규모의 테스트 시스템**: 클라우드에서는 온디맨드 방식으로 프로덕션 규모의 테스트 환경을 만들고, 테스트를 완료한 다음 해당 리소스를 폐기할 수 있습니다. 테스트 환경을 실행하는 동안에만 비용을 지불하면 되기 때문에 온프레미스 테스트 비용의 몇분의 일에 불과한 가격으로 실제 환경을 시뮬레이션할 수 있습니다.
+ **자동화를 통해 아키텍처 실험 수행 과정 간소화**: 자동화를 사용하면 적은 비용으로 워크로드를 생성하고 복제할 수 있으며, 수작업으로 인한 비용을 줄일 수 있습니다. 자동화 과정의 변경 사항을 추적하고, 그 효과를 감사하고, 필요하면 이전의 파라미터로 되돌릴 수 있습니다.
+ **아키텍처의 지속적인 혁신**: 기존 환경에서는 정해진 방식의 일회성 이벤트로 아키텍처를 결정하는 경우가 많고 시스템의 수명 주기 중 메이저 버전 업그레이드는 몇 차례 이루어지지 않습니다. 기업과 경영 상황은 계속 변화하는데, 시스템이 변화무쌍한 비즈니스 요구 사항을 만족하도록 혁신할 때 초기의 오판이 두고두고 발목을 잡을 수 있습니다. 그러나 클라우드에는 온디맨드 방식의 자동화 및 테스트 기능이 있어 설계 변경에 따른 위험이 줄어듭니다. 따라서 시간이 지날수록 시스템은 진화하고, 기업은 혁신을 표준 사례로 활용할 수 있게 됩니다.
+ **데이터를 사용하여 아키텍처 구동**: 클라우드에서는 아키텍처 선택에 따른 워크로드 동작에 미치는 영향에 대한 데이터를 수집할 수 있습니다. 그러므로 사실에 근거하여 어떻게 워크로드를 개선할지 결정할 수 있습니다. 클라우드 인프라는 코드이므로 이 데이터를 장기적으로 아키텍처 선택 및 개선을 위한 정보로 활용할 수 있습니다.
+ **게임 데이를 통한 개선**: 프로덕션 환경에서 이벤트를 시뮬레이션하기 위한 게임 데이를 정기적으로 실시하여 아키텍처 및 프로세스가 어떻게 작동하는지 테스트할 수 있습니다. 그러면 어느 분야에서 개선이 필요한지 파악하고, 조직이 이벤트에 대처하는 경험을 쌓도록 도울 수 있습니다.