AWS Well-Architected Framework 백서 (번역/요약)

🗓 2018/07/13 ⏰ 소요시간 7 분

이 포스트는 AWS 자격증 스터디에서 AWS Well-Architected Framework 백서(2018/06)를 한글로 번역 및 요약한 자료입니다. 해당 포스트는 계속해서 업데이트 됩니다.

마지막 업데이트 : 2018/07/12

소개

AWS Well-Architected Framework 는 AWS 상에서 시스템을 구축하면서 내리게 될 결정의 장단점을 이해하도록 도와줄 것이다.
아키텍처를 지속적으로 평가하고 모범 사례에서 배운 내용을 적용하도록 도와준다.
더 많은 정보는 AWS Well-Architected homepage 를 참고한다.

정의

AWS Well-Architected Framework 는 5가지 기본 원칙을 기반으로 한다.
운영 우수성, 보안, 신뢰성, 성능 효율성 그리고 비용 최적화.

AWS Well-Architected Framework 의 5가지 원칙

운영 우수성 : 시스템을 실행하고 모니터링하여 비즈니스 가치 및 지속적인 지원을 개선하는 프로세스 및 절차
보안 : 위험 평가를 통해 비즈니스 가치를 제공하는 동시에 정보, 시스템 및 자산을 보호하는 기능 및 완화 전략
신뢰성 : 시스템이 인프라 또는 서비스 중단으로부터 복구하고, 동적으로 컴퓨팅 리소스를 확보하여 수요를 충족하고, 잘못된 구성이나 일시적인 네트워크 문제와 같은 장애를 완화
성능 효율성 : 변화하는 요구사항과 기술 진화에 따른 시스템 요구사항을 충족하고 유지하기 위해 컴퓨팅 리소스를 효율적으로 사용
비용 최적화 : 비즈니스 가치를 가장 낮은 가격에 제공하기 위해 시스템을 운영

솔루션을 설계할 때 비즈니스 상황에 맞춰 이 5가지 원칙을 절충해야 한다.
안정성을 조금 희생해서 비용을 절감할 수 있다.
안정성이 중요한 경우에는 비용 증가를 감수해서 안정성을 기준으로 최적화할 수도 있다.
전자 상거래 솔루션의 경우 성능이 고객 구매 결정 요소이기도 하다.
하지만 보안 및 운영 우수성은 일반적으로 다른 원칙과 절충하지 않는 원칙이다.

설계에 대해

기술 아키텍처팀은 Technical Architect(인프라), Solution Architect(소프트웨어), Data Architect, Networking Architect(네트워크), Security Architect(보안)와 같은 역할로 구성된다.
하지만 AWS 에서는 이런 중앙 집중식 팀보다는 기능 단위로 팀을 나누는 것을 선호한다.
이렇게 분산된 의사 결정 권한에 대한 리스크를 감소하는 방법은
- 전문가 배치
- 자동화된 검사 매커니즘
- Amazon leadership principles 참고
모든 팀이 잘 설계된 아키텍처를 적용하고 모범 사례를 따를 수 있도록 커뮤니티를 만들고 액세스 할 수 있도록 한다.(커뮤니티, 교육, 런치 타임 토크 등)
이러한 접근 방식을 통해 기술 리더(CTO, 관리자 등)는 기술 포트폴리오의 리스크를 잘 이해할 수 있고, 엔지니어들이 다양한 주제에 대해 생각을 공유할 수 있다.

일반적인 설계 원칙

클라우드 시스템의 일반적인 설계 원칙

필요 용량 산정 필요 없음: 클라우드에서는 필요한 인프라 용량을 미리 추측할 필요가 없다. 수요에 따라 필요한 만큼 용량을 늘리거나 줄일 수 있다.
제품 규모의 테스트 시스템: 클라우드에서는 온디맨드 방식으로 테스트 환경을 만들고 테스트 환경을 실행하는 동안만 비용을 지불하고 다 테스트 종료 후 폐기할 수 있다.
자동화를 통한 아키텍처 실험: 자동화를 통해서 수작없 없이 저렴한 비용으로 시슽메을 만들고 복제할 수 있다. 필요하면 이전 파라미터로 쉽게 돌릴 수 있다.
아키텍처의 지속적 혁신: 기존 환경에서는 초기에 결정한 아키텍처 때문에 변경된 요구사항을 충족시키기 어려운 경우가 있다. 하지만 클라우드에서는 온디맨드 방식의 자동화 및 테스트 기능이 있어서 설계 변경에 따르는 위험이 줄어들고 지속적으로 혁신할 수 있다.
데이터 기반 아키텍처: 클라우드에서는 아키텍처 선택이 미치는 각종 데이터를 수집할 수 있다. 이런 데이터를 기반으로 워크로드 개선 방향을 결정할 수 있다. 클라우드 인프라는 코드이므로 이 데이터를 장기적으로 아키텍처 선택 및 개선을 위한 정보로 활용할 수 있다.
실전을 통한 개선: 정기적으로 실전 연습(game days)을 통해 테스트하고 개선하는 경험을 쌓을 수 있다.

5가지 설계 원칙

다섯 가지 기반 원칙에 대해 각각의 정의, 모범 사례, 질문, 고려사항을 소개한다.

운영 우수성

비즈니스 가치를 제공하기 위한 시스템을 실행 및 모니터하고 지원 프로세스 및 절차를 지속적으로 개선
시스템 운영에 대한 내용
Operational Excellence Pillar

디자인 원칙

코드를 사용한 작업 수행: 클라우드에서는 인프라를 코드로 관리할 수 있다. 운영 절차를 스크립트로 작성하고 이벤트에 대응하여 트리거해서 실행을 자동화할 수 있다. 작업을 코드로 수행하면 사용자 오류를 제한하고 이벤트에 대해 일관된 응답을 사용할 수 있다.
자동화된 문서: 클라우드에서는 빌드 후 주석이 있는 문서를 자동으로 생성할 수 있다.
빈번하게, 작게, 되돌릴 수 있는 변화를 만들기: 한 번에 큰 변화가 아닌, 정기적으로 구성 요소를 조금씩 업데이트하도록 설계한다.
실패 예상: 정기적인 실전 연습(game days)를 통해서 잠재적 고장 원인을 파악해 제거하거나 완화한다.
모든 운영 실패(장애)에서 배우기: 모든 운영 이벤트와 장애로부터 교훈을 배우고 개선하고 공유한다.

정의

준비 Prepare
운영 Operate
진화 Evolve

모범사례

Prepare

효과적인 준비가 운영 우수성을 이끈다.
워크로드 또는 변경사항이 운영 환경으로 이동할 준비가 되었는지 확인하고 지원할 수 있는 매커니즘을 만들어야 한다.
AWS 를 이용하면 클라우드에서 코드로 안전하게 실험하고, 운영 절차를 개발하고 실패를 연습할 수 있다. AWS CloudFormation 을 이용해 일관되고, 템플릿화, 샌드박스 개발, 테스트, 운영 환경을 구축할 수 있다.
AWS 를 이용하면 모든 레이어에서 다양한 로그 컬렉션으로 워크로드를 볼 수 있다. (Amazon CloudWatch, AWS CloudTrail, VPC Flow Logs)

운영 우수성을 위한 질문

OPS 1: 운영에서 우선순위를 결정하는 요인은 무엇인가?
- 비즈니스 성과 달성을 위한 운영 지원을 알아보기 위해 운영 우선순위를 정할 때 비즈니스팀과 개발팀을 모두 참여시킨다.
- 컴플라이언스 요구사항이나 산업 표준 등 외부 요소를 고려해서 정한다.
- 상충되는 여러 요소 (가격, 스피드 등)의 리스크를 평가해 결정한다.
OPS 2: 작동 가능성을 높이기 위해 어떻게 설계할 것인가?
- 복잡도를 줄이고 개발 편의를 최대화할 수 있는 표준 설계를 만들고, 지속적으로 개선해나간다.
- 모범 사례와 지침을 공유한다.
- 클라우드의 이점을 활용한 설계 (탄력성, 온디맨드 확장성, 쓴만큼만 내는 과금, 자동화 등)
- 고객의 행동을 도구들(logs, metric, counters 등)로 측정하고, 인사이트를 발견해 고객 경험을 향상시킨다
- 결함을 줄이고 문제 해결을 간소화하며 플로우를 개선하는 방법을 구현해야 한다. 빠른 피드백, 리팩토링 등
- 배포의 리스크를 줄인다 : 자동화된 테스트, 작은 사이즈로 조금씩 자주 배포, 테스트, canary 배포, one-box 배포, blue-green 배포 등
OPS 3: 워크로드를 지원할 준비가 되었는지 어떻게 알 수 있나?
- 45페이지

Cloud

목차

소개

정의