Well-Architected Framework Review(WAFR)를 수행하는 방법- 1부

이 글은 AWS Cloud Operations & Migrations Blog에 게시된 How to perform a Well-Architected Framework Review- Part 1 by Ebrahim (EB) Khiyami을 한국어로 번역 및 편집하였습니다.

‘제 워크로드가 잘 설계가 되어 있나요?’

‘저희 팀이 클라우드의 모범 사례를 따르고 있나요?’

‘다른 고객들은 X 솔루션을 구현할 때 어떻게 해요?’

‘Y 서비스 구성할 때 가장 좋은 방법은 무엇인가요?’

이 질문들은 고객분들의 아키텍처가 AWS의 모범 사례에 잘 부합 하는지 검증하고 싶어하는 고객들로 부터 제가 주로 받는 질문 예시입니다. 이러한 질문들에 대한 답은 고객이 운영하는 기술 도메인의 유형에 따라 달라 지지만, 일반적으로 입증된 설계 원칙들이 있고, 이를 따른다면, 고객이 구축하는 시스템이 기대하는 기능들을 제공할 수 있게 될 것입니다.이 설계 원칙과 모범 사례들은 AWS Well-Architected Framework의 핵심이며, 운영 우수성(Operational Excellence), 보안(Security), 안정성(Reliability), 성능 효율성(Performance Efficiency), 비용 최적화(Cost Optimization), 지속 가능성(Sustainability) 6대 원칙(Pillar)에 걸쳐 있습니다.

AWS에는 모든 것에 대한 모범 사례가 존재하고, 워크로드에 대한 Well-Architected Framework Review(WAFR)를 실행하는 것 또한 예외가 아닙니다. WAFR은 팀의 경험, 워크로드의 복잡도, 검토하려는 원칙, 뒤에 논의할 다른 요소들과 같이 여러 요인들에 의해 많은 시간이 필요할 수 있습니다. 팀이 검토에 투자한 시간이 아키텍처의 위험을 식별하고 그것을 해결하는 기대 효과로 이어지기 위해서는, 이러한 모범 사례를 아는 것이 중요합니다. 이 3부로 된 블로그 시리즈에서는 고객들과 많은 WAFR을 실행 하면서 얻은 교훈들을 공유합니다. 1부에서는 WAFR을 준비하는 방법을 설명합니다. 2부에서는 WAFR을 실행하는 방법을 다루고, 3부에서는 아키텍처 위험을 식별하고 이를 해결하기 위한 계획을 수립하는 방법을 다룹니다.

시작에 앞서, WAFR은 무엇인가요?

기술 시스템을 구축하는 것은 다른 제품을 만드는 것과 다르지 않습니다. 산업 표준에 맞는 제품을 만들 때 따라야 하는 관행과 규칙이 있습니다. 그러나 관행이 있다는 것만으로는 충분하지 않습니다. 팀이 이러한 관행에 대해 인지하고, 그것들을 따르도록 보장하는 매커니즘을 만드는 것이 필요합니다.

AWS 모범 사례를 학습하고, 이러한 모범 사례와 비교해서 아키텍처를 측정하고, 아키텍처 위험을 식별하고, 이를 해결하기 위한 개선 계획을 세우는 일관된 프로세스를 우리는 AWS Well Architected Framework Review라고 합니다.

그림 1 – Well-Architected Framework Review 주기

WAFR의 목표는 무엇인가요? 왜 그것을 해야 할까요?

WAFR의 궁극적인 목표는 여러분의 시스템이 비즈니스 요구사항을 더 잘 지원할 수 있도록 시스템의 아키텍처를 개선하는 것입니다. 아키텍처 개선 프로세스는 현재의 아키텍처를 검토하고, 모범 사례와 비교하는 것으로 시작합니다. 검토 질문들에 대해 답을 하면 됩니다. 각 원칙(Pillar)들에는 일련의 질문들이 있습니다. 이 질문들은 특정 모범 사례가 아키텍처 내에 구현이 되어 있는지 여부를 검증합니다. 답변을 바탕으로, AWS Well-Architected Tool(AWS WA Tool)의 도움을 받아 아키텍처에서 위험도가 상, 중, 하인 영역을 식별합니다. – 이에 대해서는 뒤에 더 설명합니다. 다음 단계는 이들 위험 중 가장 높은 영향도를 식별하여 우선순위 기반 접근 방식으로 위험들을 해결하는 작업을 시작하는 것입니다. 그런 다음 이를 해결하기 위한 개선 계획을 수립합니다. 이 게시글과 다음 시리즈에 이어서 각 단계의 세부 내용들을 살펴 보도록 하겠습니다.

WAFR의 단계들

WAFR에는 3단계: 준비, 검토, 개선이 있습니다. 다음 섹션 에서는 각 단계를 자세히 살펴보고, 이를 최대한 활용하기 위한 몇 가지 모범 사례를 알려 드리겠습니다.

그림 2 – Well-Architected Framework Review 단계

준비하기

WAFR 준비는 평균적으로 실제 검토 일자 약 3주 전에 시작합니다. 이것은 검토 팀을 구성하기 위한 시간, 검토할 원칙의 수, 검토를 완료하기 위해 조직에서 주어진 우선 순위와 같은 요소에 따라 달라집니다. 이 단계에서는 검토 세션에 초대하려는 팀, 검토 대상 워크로드, 검토 세션 형식을 결정합니다. 또한, 검토 질문들에 답하는 데 도움이 되는 아키텍처 관련 필요한 데이터를 수집해야 합니다.

각 단계를 자세히 살펴보겠습니다.

1- 워크로드 정의하기

WAFR을 준비하는 첫번째 단계는 검토 대상 워크로드를 식별하는 것입니다. 워크로드는 조직에 비즈니스 가치를 제공하는 구성 요소(기술, 사람, 프로세스)의 집합입니다. 그것은 리더들이 커뮤니케이션할 때 정도의 비즈니스와 기술 수준입니다. 예를 들어, 고객이 주문을 하고 이를 확인하는 웹사이트와 백엔드를 지원하는 인프라와 프로세스가 하나의 워크로드입니다.

2-핵심 팀(스폰서) 정의하기

성공적인 WARF의 핵심 요소는 처음부터 적합한 사람들을 참여시키는 것입니다.
검토 대상 워크로드를 식별한 후, 워크로드의 주인을 식별해야 합니다. 우리는 때때로 그들을 스폰서라고 부릅니다. 워크로드 스폰서는 워크로드의 성공(또는 실패)을 최종적으로 책임지는 사람(또는 팀)입니다. 이 사람은 검토 결과에서 식별된 아키텍처 위험들을 해결하기 위해 조치를 취하고 영향력을 행사하기 위한 적절한 수준의 권한을 갖고 있어야 합니다. 예로 팀의 우선순위를 바꾸거나 외부 업체를 고용하는 등의 조치가 될 수 있습니다.
또한 각 원칙(Pillar)의 스폰서를 식별해야 합니다. 조직 구조와 규모에 따라 한 사람이 여러 원칙을 담당할 수도 있고, 여러 팀이 하나의 원칙을 담당하거나, 이를 혼합할 수도 있습니다. 여기에서의 목표는 각 원칙 별 검토 질문들에 대해 답하고, 후에 개선 계획 내에서 원칙에서 식별된 위험에 대해 해결할 적임자를 확보하는 것입니다.
검토 하려는 원칙에 대한 종합적인 관점을 갖기 위해서는 여러 팀의 사람들을 모아야 할 수도 있습니다. 예를 들어, 안정성 원칙을 검토 하려면, 데이터베이스, 네트워크, 보안 및 운영 별로 전문가들을 포함해야 할 수 있습니다. 운영 우수성 원칙을 검토 하려면, 엔터프라이즈 아키텍트 및 애플리케이션 개발, 또는 비즈니스나 재무 담당을 포함해야 할 수 있습니다.

3-원칙(Pillar)과 렌즈 결정하기

6대 원칙 관점에서 워크로드를 종합적으로 살펴보는 것이 가장 이상적 입니다. 그러나 특정 원칙에만 집중해야 하는 상황이 있을 수도 있습니다. 예를 들어, 보안 관행을 변경하고 나서 모범 사례를 계속 따르고 있는지 확인하고 싶을 수 있습니다.이 경우에는 보안 원칙만 검토하도록 선택할 수 있습니다.
또한 Well-Architected Framework에 나열된 원칙 순서를 따르는 것을 추천합니다. 운영 우수성 원칙으로 시작해서 지속 가능성 원칙으로 끝내십시오. 그러나 조직의 우선 순위는 다를 수 있습니다. 이 단계에서는 검토할 원칙의 순서도 결정해야 합니다.
한 가지 더 결정해야 할 것은 AWS Well-Architected Lens를 사용할 것인지 입니다. 렌즈는 Well-Architected에서 제공하는 지침을 특정 산업과 기술 도메인으로 확장합니다. 예를 들어, 워크로드가 주로 서버리스를 사용하는 경우, 서버리스 애플리케이션 렌즈에 대해 검토해야 할 수 있습니다. 데이터 분석 워크로드의 경우에는, 검토에 데이터 분석 렌즈를 포함해야 할 수 있습니다. 사용 가능한 렌즈 목록은 여기에서 확인하세요.

4- 세션 유형 결정하기

선택된 원칙과 팀의 가용성에 따라, 검토 세션의 형식을 결정해야 합니다. 6대 원칙을 하루 종일 할 수도 있고, 선택한 원칙에 대해 며칠에 걸쳐 여러 세션들을 진행할 수도 있습니다. 전일 검토하는 것은 보통 일정을 잡기는 어렵지만, 모든 이해관계자가 함께 모여 모범 사례를 논의할 수 있기 때문에 가장 가치가 있습니다. 보통 이 형식이 개선 기회를 발견하는데 가장 도움이 됩니다.
지리적으로 떨어져 있는 팀이나 팀이 커서 동시에 모이기가 어렵다면, 여러 세션을 진행하는 것이 좋은 선택입니다. 이 접근은 유지 관리가 더 쉽지만 다른 마일스톤에 대해 다른 팀들 간 업데이트를 하려면 약간의 추가 작업이 필요할 수도 있습니다.
검토하는 동안 팀 간 커뮤니케이션은 질문들에 답을 하고 공동으로 이슈를 찾아내는데 도움이 되기 때문에 중요합니다. 그러므로 AWS WA Tool에서 질문에 답하면서 WAFR을 비 동기가 아닌 라이브 세션으로 진행하고, 나중에 이를 공유하는 것을 권장합니다.

5-검토에 필요한 데이터 수집하기

검토 세션을 수행하기 전에, 검토하고 있는 워크로드에 관한 상세 내용들을 수집하는 것이 좋습니다. 예를 들어, 아키텍처 다이어그램이나 시스템의 주요 구성요소, 백엔드, 주요 프로세스와 운영 담당 팀을 설명하는 문서들을 확인합니다.
더 복잡한 워크로드라면, 비용 최적화, 성능, 보안, 내결함성, 서비스 제한에 걸쳐 모범 사례를 자동으로 평가하는 검사를 위해 AWS Trusted Advisor를 활용할 수 있습니다. Trusted Advisor를 활성화하여 AWS 조직의 모든 계정을 검사하도록 할 수 있습니다. 더 자세한 내용은 여기에서 확인하십시오. 그 다음에 Trusted Advisor가 권장하는 작업을 사용해 모범 사례 준수를 더 잘 이해하고, 검토할 때나 향후 개선 계획을 수립할 때 이런 세부 사항을 포함할 수 있습니다. AWS Trusted Advisor와 AWS Well Achitected를 사용해 데이터 기반 비용 최적화를 달성하는 방법에 예시가 있습니다.

요약

이 게시글에서 Well-Architected Framework Review의 첫번째 단계인 준비 단계에 대해 자세히 살펴보았습니다. 몇 가지 과정들과 고객과의 WAFR을 수행하며 배운 교훈에 대해 공유 드렸습니다. 이러한 권장 사항들은 WAFR을 더 원활하게 하고, 모든 참여자들의 시간을 최대한 활용하는데 도움이 될 것입니다. 검토 대상 워크로드 정의, 적합한 핵심 팀과 스폰서 정의, 원칙 및 세션 유형 선택, 마지막으로 필요한 데이터의 사전 수집 단계들이 포함됩니다. 이러한 단계들을 통해 검토하는 날을 준비할 수 있습니다. 이 블로그 시리즈의 2부와 3부에서 이에 대해 더 자세히 살펴보겠습니다.