# AWS Well-Architected 프레임워크
<a name="welcome"></a>

발행일: **2024년 11월 6일**([문서 수정](document-revisions.md))

AWS Well-Architected Framework를 활용하면 AWS에서 시스템을 구축하면서 내리게 되는 결정의 장단점을 이해할 수 있습니다. 이 프레임워크를 사용하면 클라우드에서 신뢰할 수 있고 안전하며 효율적이고 경제적이면서 지속 가능한 시스템을 설계하고 운영하기 위한 아키텍처 모범 사례를 알아볼 수 있습니다.

## 소개
<a name="introduction"></a>

 AWS Well-Architected Framework를 활용하면 AWS에서 시스템을 구축하면서 내리게 되는 결정의 장단점을 이해할 수 있습니다. 이 프레임워크를 사용하면 AWS 클라우드에서 안전하고 신뢰할 수 있으며 효율적이고 경제적이면서 지속 가능한 워크로드를 설계하고 운영하기 위한 아키텍처 모범 사례를 알아볼 수 있습니다. 또한 모범 사례와 비교하여 아키텍처를 지속적으로 측정하고 개선할 영역을 파악할 수 있습니다. 아키텍처를 검토하는 프로세스는 아키텍처 관련 결정사항에 대한 건설적인 대화이며, 감사 메커니즘이 아닙니다. 시스템을 제대로 설계하면 비즈니스 성공 가능성을 높일 수 있습니다.

 AWS 솔루션스 아키텍트는 광범위한 업종 및 사용 사례에 걸쳐 오랫동안 솔루션을 설계해 왔습니다. AWS는 수천 고객의 자사 아키텍처를 설계하고 검토해 왔습니다. 그리고 이러한 경험을 바탕으로 클라우드 시스템 설계의 모범 사례와 핵심 전략을 밝혀냈습니다.

 AWS Well-Architected Framework에는 특정 아키텍처가 클라우드 모범 사례에 적합한지를 파악하는 데 도움이 되는 기본적인 질문이 다수 수록되어 있습니다. 이 프레임워크를 이용하면 클라우드 기반의 현대적 시스템에 대해 고객이 기대하는 품질 기준에 따라 일관적인 방식으로 시스템을 평가하고 그러한 품질을 달성하기 위해 필요한 수정 조치를 확인할 수 있습니다. AWS가 진화를 거듭하고 고객과의 협력을 통해 점점 더 많은 지식을 쌓아가면서 앞으로도 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 지식을 보유하고 있으며, 이를 통해 워크로드를 검토하고 개선하는 데 도움을 줄 수 있습니다.

# 정의
<a name="definitions"></a>

 AWS의 전문가들은 매일 고객과 함께 클라우드의 모범 사례를 활용하여 시스템을 설계합니다. 설계의 진화에 발맞춰 고객의 아키텍처에 더할 것과 뺄 것을 결정할 수 있도록 지원합니다. 그리고 고객이 이러한 시스템을 실제 환경에 배포하는 과정에서 해당 시스템의 성능 수준과 그러한 결정의 결과를 배우게 됩니다.

 자사는 이렇게 얻은 교훈을 토대로 고객 및 파트너가 아키텍처를 평가할 수 있는 일관적인 모범 사례 및 아키텍처가 AWS 모범 사례에 얼마나 잘 맞는지 평가할 수 있는 여러 가지 질문을 제공하는 AWS Well-Architected Framework를 개발했습니다.

 AWS Well-Architected Framework는 운영 우수성, 보안, 신뢰성, 성능 효율성, 비용 최적화 및 지속 가능성이라는 6가지 원칙을 기반으로 합니다.

 **표 1. AWS Well-Architected Framework 원칙** 


|  **\$1.Name**  |  **설명**  | 
| --- | --- | 
|  운영 우수성  |  효과적인 개발 및 워크로드 실행을 지원하고, 작업에 대한 인사이트를 얻으며, 지원 프로세스 및 절차를 지속적으로 개선하여 비즈니스 가치를 제공할 수 있는 능력입니다. | 
|  보안. | 보안 원칙은 보안 태세를 개선할 수 있는 방식으로 클라우드 기술을 활용하여 데이터, 시스템 및 자산을 보호하는 방법을 설명합니다. | 
|  신뢰성  |  신뢰성 원칙에서는 워크로드의 기능이 필요한 때에 기능을 정확하고 일관되게 수행하는 역량에 대해 다룹니다. 여기에는 전체 수명 주기에 걸쳐 워크로드를 운영 및 테스트할 수 있는 기능이 포함됩니다. 이 백서는 AWS에서 안정적인 워크로드를 구현하기 위한 세부적인 모범 사례 지침을 제공합니다. | 
|  성능 효율성  |  컴퓨팅 리소스를 시스템 요구 사항에 맞게 효율적으로 사용하고, 수요 변화 및 기술 진화에 발맞춰 그러한 효율성을 유지하는 능력입니다. | 
|  비용 최적화. |  가장 낮은 가격으로 비즈니스 가치를 제공하도록 시스템을 실행하는 능력입니다. | 
|  지속 가능성  |  프로비저닝된 리소스의 이점을 극대화하고 필요한 총 리소스를 최소화하여 워크로드의 모든 구성 요소에서 에너지 소비를 줄이고 효율성을 높임으로써 지속 가능성에 미치는 영향을 지속적으로 개선할 수 있습니다. | 

 AWS Well-Architected Framework에서는 다음 용어를 사용합니다.
+  **구성 요소**는 요구 사항을 충족하는 코드, 구성 및 AWS 리소스입니다. 구성 요소는 대개 기술 소유권의 단위이며 각기 분리되어 있습니다.
+  **워크로드**라는 용어는 비즈니스 가치를 제공하는 일련의 구성 요소를 가리키는 데 사용됩니다. 워크로드는 일반적으로 비즈니스 및 기술 책임자가 언급하는 수준의 디테일에 해당합니다.
+  **아키텍처**는 워크로드에서 구성 요소가 연동되는 방식이라고 볼 수 있습니다. 아키텍처 다이어그램에는 구성 요소의 통신 및 상호 작용 방식에 초점이 맞춰집니다.
+  **마일스톤**은 설계, 구현, 테스트, 출시 및 프로덕션으로 이어지는 제품 수명 주기 전반에 걸쳐 아키텍처가 개선되는 과정에서 발생하는 주요 변화 시점을 표시합니다.
+  조직 내에서 **기술 포트폴리오**는 기업을 운영하는 데 필요한 워크로드 모음입니다.
+ **작업 수준**은 구현에 필요한 작업 시간, 활동 및 복잡성을 분류하는 것입니다. 각 조직이 조직의 유효 작업 수준을 적절하게 분류하려면 팀의 규모와 전문성, 추가 컨텍스트의 워크로드 복잡성을 고려해야 합니다.
  + **높음:** 이 작업을 완료하는 데는 몇 주 또는 몇 달이 걸릴 수 있습니다. 여러 스토리, 릴리스 및 작업으로 나눌 수 있습니다.
  + **중간:** 이 작업을 완료하는 데는 며칠 또는 몇 주가 걸릴 수 있습니다. 여러 릴리스 및 작업으로 나눌 수 있습니다.
  + **낮음:** 이 작업을 완료하는 데는 몇 시간 또는 며칠이 걸릴 수 있습니다. 여러 작업으로 나눌 수 있습니다.

 워크로드를 설계할 때는 업무 상황에 따라 이러한 원칙들을 절충해야 합니다. 이러한 비즈니스 의사결정에 따라 엔지니어링 우선 순위가 달라질 수 있습니다. 개발 환경의 신뢰성이 다소 낮아지더라도 지속 가능성에 미치는 영향을 개선하고 비용을 절감하도록 최적화하거나, 미션 크리티컬 솔루션의 경우 비용 및 지속 가능성에 미치는 영향이 증가하는 상황을 감수하고 신뢰성을 기준으로 최적화할 수 있습니다. 전자 상거래 솔루션의 경우 성능이 매출과 고객 구매 성향에 영향을 미칠 수 있습니다. 보안 및 운영 우수성은 일반적으로 다른 원칙과 절충 관계에 있지 않습니다.

# 아키텍처
<a name="on-architecture"></a>

 온프레미스 환경에서 고객은 다른 제품 또는 기능 팀이 모범 사례를 충실히 따르도록 전반적으로 관리하는 기술 아키텍처 중앙 팀을 두기도 합니다. 일반적으로 기술 아키텍처 팀에는 테크니컬 아키텍트(인프라), 솔루션스 아키텍트(소프트웨어), 데이터 아키텍트, 네트워킹 아키텍트 및 보안 아키텍트와 같은 일련의 역할이 포함됩니다. 이러한 팀은 종종 [TOGAF](https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework) 또는 [Zachman Framework](https://zachman-feac.com/zachman/about-the-zachman-framework)를 엔터프라이즈 아키텍처 기능의 일부로 사용합니다.

 AWS는 해당 기능을 중앙 팀을 두어 집중화하지 않고, 각각의 개별 팀에 나눠 주는 것을 선호합니다. 의사 결정 권한을 분산하게 될 경우, 예를 들어 팀들이 내부 기준을 충족하도록 확인하는 데 여러 위험 요소가 생기게 됩니다. 저희는 두 가지 방법으로 이러한 위험을 완화합니다. 먼저, 각 팀의 역량 확보를 위한 *관행*(업무 방법, 프로세스, 표준, 수락된 기준 등)을 통해 팀이 충족해야 할 표준에 대한 기준을 높일 수 있도록 전문가를 배치합니다 둘째, 표준에 부합하는지 확인하기 위해 자동화된 검사를 수행하는 *메커니즘*을 구현합니다.

****  
 "좋은 의도만으로는 부족합니다. 무언가를 해내려면 좋은 메커니즘이 필요한 법이죠." - Jeff Bezos.

즉, 사람의 노력을 규칙이나 프로세스 준수 여부를 확인하는 메커니즘(종종 자동화됨)으로 대체하는 것을 의미합니다. 이러한 분산된 접근 방식은 [Amazon 리더십 원칙](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp)에 의해뒷받침되며 고객에서부터 *역방향으로 작업*하는 모든 역할에 걸쳐 문화를 수립합니다. 역방향 작업은 혁신 프로세스의 기본 요소입니다. 저희는 고객 및 고객이 원하는 것에서부터 출발하며, 이를 기반으로 작업을 정의하고 방향을 잡습니다. 고객 중심의 팀은 고객의 요구 사항에 대응하여 제품을 개발합니다.

 아키텍처 측면에서, 이는 모든 팀이 아키텍처를 생성하고 모범 사례를 따르는 기능을 갖추고 있음을 의미합니다. 새로운 팀이 이러한 역량을 확보하거나 기존 팀이 기준을 높일 수 있도록 설계를 검토하고 AWS 모범 사례를 이해하는 데 도움이 되는 수석 엔지니어 가상 커뮤니티에 액세스할 수 있게 해줍니다. 수석 엔지니어 커뮤니티는 모범 사례를 가시화하고 쉽게 액세스할 수 있도록 최선을 다합니다. 예를 들어 모범 사례를 실제 사례에 적용하는 데 중점을 둔 간략한 회의를 통해 이를 수행합니다. 이러한 회의 내용은 기록되어 새 팀원을 위한 온보딩 자료의 일부로 사용할 수 있습니다.

 AWS의 모범 사례는 수천 개의 시스템을 인터넷 규모로 운영한 경험에서 비롯된 것입니다. 그리고 데이터를 사용하여 모범 사례를 정의하는 것을 선호하지만, 수석 엔지니어와 같은 주제 전문가를 활용하여 설정하기도 합니다. 수석 엔지니어가 새로운 모범 사례를 확인하게 되면 커뮤니티로 활동하여 팀이 이를 따를 수 있도록 안내합니다. 시간이 지나면서 이러한 모범 사례는 내부 검토 절차 및 규정 준수를 시행하는 메커니즘으로 공식화됩니다. Well-Architected Framework는 내부 검토 프로세스를 고객 중심으로 구현한 결과이며, 주요 현장에서 활동하는 솔루션스 아키텍처 및 내부 엔지니어링 팀에서 엔지니어링 사고를 체계화한 것입니다. Well-Architected Framework는 이러한 결과를 활용할 수 있는 확장 가능한 메커니즘입니다.

 자사는 아키텍처를 분산 담당하는 주요 엔지니어링 커뮤니티의 접근 방식을 따르면, 고객 요구 사항 중심 Well-Architected 엔터프라이즈 아키텍처가 실현될 수 있다고 믿습니다. 모든 워크로드 전반에 걸쳐 Well-Architected 검토를 수행하는 기술 리더(CTO 또는 개발 관리자)를 두면, 기술 포트폴리오의 위험을 더 효과적으로 이해할 수 있습니다. 이 접근 방식을 사용하면 책임 엔지니어가 특정 영역에 대한 사고 방식을 여러 팀과 공유할 수 있는 메커니즘, 교육 또는 간략한 회의를 통해 조직에서 해결 가능한 전반적인 주제를 식별할 수 있습니다.

# 일반 설계 원칙
<a name="general-design-principles"></a>

 Well-Architected Framework는 다음과 같은 여러 가지 일반 설계 원칙을 확립하여 우수한 클라우드 설계를 촉진합니다.
+  **용량 요구 사항 추적 중지**: 워크로드를 배포할 때 용량을 잘못 결정하면 결국 고가의 유휴 리소스를 방치하게 되거나 제한된 용량으로 인한 성능 문제를 처리해야 합니다. 하지만 클라우드 컴퓨팅에서는 이러한 문제가 사라집니다. 필요한 만큼 용량을 많이 또는 적게 사용하다가 자동으로 스케일 인 및 스케일 아웃할 수 있기 때문입니다.
+  **프로덕션 규모에서 시스템 테스트**: 클라우드에서는 온디맨드 방식으로 프로덕션 규모의 테스트 환경을 만들고, 테스트를 완료한 다음 해당 리소스를 폐기할 수 있습니다. 테스트 환경을 실행하는 동안에만 비용을 지불하면 되기 때문에 온프레미스 테스트 비용의 몇분의 일에 불과한 가격으로 실제 환경을 시뮬레이션할 수 있습니다.
+  **아키텍처 실험을 염두에 둔 자동화**: 자동화를 통해 저렴한 비용으로 워크로드를 생성, 복제하고 수작업의 수고를 덜 수 있습니다. 자동화 과정의 변경 사항을 추적하고, 그 효과를 감사하고, 필요하면 이전의 파라미터로 되돌릴 수 있습니다.
+  **진화하는 아키텍처 고려:** 기존 환경에서는 정해진 방식의 일회성 이벤트로 아키텍처를 결정하는 경우가 많고 시스템의 수명 주기 중 메이저 버전 업그레이드는 몇 차례 이루어지지 않습니다. 기업과 경영 상황은 계속 변화하는데, 이러한 초기의 결정 때문에 변경된 비즈니스 요구 사항을 시스템이 만족시키지 못할 수도 있습니다. 그러나 클라우드에는 온디맨드 방식의 자동화 및 테스트 기능이 있어 설계 변경에 따른 위험이 줄어듭니다. 따라서 시간이 지날수록 시스템은 진화하고, 기업은 혁신을 표준 사례로 활용할 수 있게 됩니다.
+  **데이터를 사용하여 아키텍처 구동**: 클라우드에서는 아키텍처 선택에 따른 워크로드 동작에 미치는 영향에 대한 데이터를 수집할 수 있습니다. 그러므로 사실에 근거하여 어떻게 워크로드를 개선할지 결정할 수 있습니다. 클라우드 인프라는 코드이므로 이 데이터를 장기적으로 아키텍처 선택 및 개선을 위한 정보로 활용할 수 있습니다.
+  **게임 데이를 통한 개선**: 프로덕션 환경에서 이벤트를 시뮬레이션하기 위한 게임 데이를 정기적으로 예약하여 아키텍처 및 프로세스가 어떻게 작동하는지 테스트합니다. 그러면 어느 분야에서 개선이 필요한지 파악하고, 조직이 이벤트에 대처하는 경험을 쌓도록 도울 수 있습니다.