Basics
이번 장에서는 Well-Architected Framework란 무엇인지에 대해서 알아본다.
Well-Architected의 목적
- 정보에 근거한 의사 결정을 한다.
- 클라우드 네이티브 방식으로 생각한다.
- 잠재적인 영향을 파악한다.
- 고객이 소홀이 할 때가 많은 기본 영역을 고려하고 있는지 확인한다.
Well-Architected Framework
- 아키텍처 모범 사례에 대한 인식을 개선한다.
- 소홀히 하기 쉬운 기본 영역을 다룬다.
- 워크로드 아키텍처를 평가하는 일관된 접근 방식을 제공한다.
- Well-Architected 프레임워크의 3대 요소는 아래와 같다.
- 질문
- 원칙
- 설계 원칙
- 워크로드: 비즈니스 또는 운영 가치를 제공하는 AWS에서 실행되는 상호관련된 애플리케이션, 인프라, 정책, 거버넌스 및 운영의 모음으로 정의된다.
기존 환경에서의 고객
- 인프라 요구 사항을 추측해야 한다.
- 대규모로 테스트할 여유가 없다.
- 변화에 대한 두려움이 있다.
- 실험의 타당성을 제시할 수 없다.
- 아키텍처가 시간이 지나도 진척될 기미를 보이지 않는다.
클라우드 환경에서의 고객
- 필요 용량에 대한 추측 불필요하다.
- 프로덕션 규모로 테스트가 가능하다.
- 자동화를 통한 보다 간편한 테스트가 가능하다.
- 아키텍처의 진화를 허용한다.
- 데이터 기반의 아키텍처를 구축할 수 있다.
- 게임 데이를 통해 개선이 가능하다.
Well-Architected 원칙
기술 솔루션 개발은 실제 건물을 세우는 것과 매우 비슷하기 때문에 기초가 단단하지 않으면 구조적 문제를 발생시킨다.
이러한 문제는 건물의 무결성과 기능을 저해할 수 있다.
아래의 원칙을 지키면서 설계를 진행하면 안정적이고 효율적인 시스템을 개발하는 데 도움이 되어, 기능적 요건 충족에 집중할 수 있게 된다.
운영 우수성
보안
안정성
성능 효율성
비용 최적화
운영 우수성 원칙
비즈니스 가치를 제공하고 지원 프로세스 및 절차를 지속적으로 개선하기 위해 시스템을 실행 및 모니터링하는 능력이다.
운영 우수성 원칙에서의 중점 영역은 아래와 같다.
- 조직: 고객은 조직의 우선 순위, 조직 구조 및 팀 구성원이 비즈니스 성과를 지원할 수 있도록 조직이 팀 구성원을 지원하는 방법을 이해해야 한다.
- 준비: 고객은 운영 아키텍처를 설계해야 한다.
아키텍처를 실제로 구현하거나 대폭적으로 변경해야할 시점에 정보에 근거한 의사 결정을 하려면 워크로드와 팀의 준비 상태를 살펴야 한다. - 운영: 고객은 워크로드 운영 방법을 알고 워크로드 및 운영 활동의 상태를 이해해야 한다.
이를 통해 조직 및 비즈니스 성과를 달성하는 데 어려움이 있을 때를 구분하여 적절하게 대응할 수 있다. - 진화: 고객은 워크로드 및 운영 활동의 지속적인 개선을 위한 프로세스를 보유해야 한다.
여기에서 피드백 루프를 구현하여 경험을 통해 학습한 후 개선하고 학습 내용을 공유하여 조직 전체에 도움을 제공할 수 있는 프로세스도 포함된다.
보안 원칙
보안 원칙은 정보 및 시스템을 보호하는 능력에 중점을 둔다.
보안 원칙에서 핵심 영역은 아래와 같다.
- 자격증명 및 액세스 관리를 통해 누가 무엇을 할 수 있는지 관리한다.
- 탐지 제어를 통해 보안 이벤트를 탐지한다.
- 인프라 보호를 통해 시스템을 보호한다.
- 데이터의 기밀성 및 무결성을 보장한다.
- 보안 이벤트에 대한 대응을 한다.
안정성 원칙
안정성 원칙은 아래의 영역에서 장애로부터 복구하고 요구를 충족할 수 있는 기능에 중점을 둔다.
- 설정 및 교차 프로젝트 요구 사항을 포함하는 기본 요소
- 분산 시스템 설계 시 선택할 수 있는 아키텍처
- 변경 사항 처리 방법
- 장애 관리를 통한 장애 복구
성능 효율성 원칙
컴퓨팅 리소스를 효율적으로 사용하여 시스템 요구 사항을 충족하고 수요가 변하고 기술이 진화함에 따라 이러한 효율성을 유지하는 능력이다.
성능 효율성 원칙은 IT 리소스를 효율적으로 사용하는 능력을 중심으로 한다.
성능 효율성 원칙에서의 중점 영역은 아래와 같다.
- 선택: 컴퓨팅, 스토리지, 데이터베이스, 네트워킹에 대한 적절한 리소스 유형 선택
- 검토: AWS가 새로운 리소스 유형 및 기능을 통해 혁신을 계속함에 따라 선택 사항을 검토
- 모니터링: 리소스가 실행되는 방법 파악
- 절충: 아키텍처 절충을 통해 성능 효율성 극대화
비용 최적화 원칙
가장 낮은 가격으로 비즈니스 성과를 달성할 수 있는 능력
비용 최적화 원칙은 가장 낮은 가격으로 비즈니스 성과를 달성하는 능력에 대한 모든 것이다.
비용 최적화 원칙에서의 중점 영역은 아래와 같다.
- 클라우드 재무 관리: 비용 및 사용량을 최적화하여 비즈니스 가치와 재정 안정성 실현
- 지출 및 사용 인식: 비용이 지출되고 있는 곳을 제어 및 이해
- 비용 효율적인 리소스: 예약 인스턴스 및 스팟 등의 비용 효율적인 리소스 유형 선택
- 수요 및 공급 리소스 관리: 수요 관리 및 Auto Scaling, 캐싱 또는 대기열과 같은 리소스를 제공
- 시간을 두고 최적화: 시간이 지나면서 새로운 서비스 또는 기능을 이용해 최적화
Well-Architected 용도
- Well-Architected의 일반적인 용도는 아래와 같다.
- 클라우드 네이티브 아키텍처를 구축하는 방법에 대해 팀 교육
- 개선 사항의 백로그를 작성하여 기술 부채 및 위험 완화
- 출시 전 통과 의례로서 거버넌스 위원회 또는 기타 내부 프로세스 심사
- 서로 다른 팀 및 제품의 역량 또는 성숙도 비교
- 새 조직을 인수할 경우 프로세스를 사용하여 현재 아키텍처의 상태를 확인할 수 있다.
AWS-Architected 핵심 사항
- 클라우드 아키텍처에 대해 정보에 의거한 의사 결정을 하고 이러한 의사 결정이 미치는 잠재적인 영향을 파악
- 설계 원칙을 활용하여 클라우드 네이티브 아키텍처의 구성을 파악
- 질문으로 시작하여 “가상” 및 “장애 시나리오”를 적극적으로 생각해야 한다.
- 항상 “Yes or No”로 답변할 수 있는 것은 아니기 때문에 후속 질문을 추가로 생각해야 한다.
참고 자료
'Infrastructure > Cloud Computing' 카테고리의 다른 글
| [Well-Architected] Security Pillar (0) | 2022.11.15 |
|---|---|
| [Well-Architected] Operational Excellence Pillar (0) | 2022.11.15 |
| [Cloud Computing] 다중 플랫폼 사용에 대한 고찰 (0) | 2022.04.04 |
| [AWS] Reserved Instance (0) | 2022.02.28 |
| [AWS] Lightsail (0) | 2022.02.19 |
