AWS 기술 블로그

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

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

그림1 – Well-Architected Framework Review 단계

준비 단계의 권장 사항을 이행했다면, 대상 워크로드와 스폰서를 식별하였을 것이고, 검토할 원칙(Pillar)과 우선 순위, 사용할 렌즈(있는 경우)와 검토 세션의 형식에 대한 결정이 완료 되었을 것 입니다. 또한 검토 단계의 질문에 답하기 위해 워크로드에 대한 필요한 데이터 수집 역시 완료 되었을 것 입니다.

WAFR의 목표

성공적인 WARF를 위한 몇 가지 권장 사항을 자세히 살펴보기 전에 검토의 궁극적인 목표는 시스템 아키텍처를 개선하여 시스템이 비즈니스 요구 사항을 더 잘 지원할 수 있도록 하는 것임을 다시 한 번 상기하는 것이 중요합니다. 아키텍처 개선 프로세스는 현재 아키텍처를 검토하고 모범 사례와 비교하는 것으로 시작됩니다. 이는 검토 질문에 답하는 것으로 시작됩니다. 각 원칙(Pillar)에 대한 일련의 질문입니다. 답변을 바탕으로 고위험 문제(HRI) 및 중간 위험 문제(MRI)라고 표현하는 개선해야 할 영역을 식별합니다. 이후 우선순위에 기반한 접근 방식을 사용하여 파악된 위험을 해결하기 위한 개선 계획을 수립합니다.

WAFR 모범 사례

1- 기대치를 설정합니다. WAFR은 모든 참여 구성원에게 중요한 시간입니다. 시간을 내어 주요 이해관계자들과 미리 대화를 나누고 검토 전, 검토 중, 검토 후의 기대치와 역할을 명확히 파악하세요. 그들의 지지를 얻어야 합니다.

2- 감사가 아닌 대화를 해야 합니다. WAFR 세션에서 가장 좋은 결과는 이해관계자가 체크리스트나 채점 연습이 아닌 대화로 만들어지게 됩니다. 그래야 모든 팀원이 모범 사례를 놓쳤다고 비난받지 않고 시스템에 대해 공개적으로 이야기하도록 장려할 수 있습니다. 이는 구조적 위험을 발견하는 데도 도움이 됩니다.

3- 팀원 모두가 역할을 수행해야 합니다. 예를 들어, 원칙(Pillar)에 대한 스폰서는 각 원칙의 모든 질문에 올바르게 답할 수 있도록 해야 합니다. 그런 다음 스폰서는 검토 중에 식별된 위험에 대한 개선 계획에 책임감을 가져야 합니다. 이는 여러 팀이 우선순위를 정하고 식별된 위험에 대한 해결책을 찾는 개선 단계에 대해 논의할 때 더욱 중요해집니다. 이에 대해서는 이 블로그 시리즈의 3부에서 설명합니다.

4- 일회성 점검이 아닌 지속적인 점검이 필요합니다. 항상 상황은 변하기 때문에 지속적으로 점검해야 합니다. 조직 내에 WAFR(또는 맞춤형 버전)을 정기적으로 수행하거나, 테스트에서 프로덕션으로 전환하는 것과 같은 워크로드의 수명 주기에서 주요한 마일스톤를 따르는 것도 추천하는 방식입니다.

5- 빠를 수록 좋습니다. 프로덕션이 아닌 설계 단계에 있을 경우, 의사 결정에 영향을 미치며 변경을 추진하는 것이 더 쉽기 때문입니다.

6- AWS Well-Architected Tool (AWS WA Tool) 사용

WAFR 질문은 백서로 제공됩니다. 그러나 검토 과정에서는 AWS WA Tool을 사용하는 것이 좋습니다. 이 도구를 사용하면 질문을 추적하고, 메모를 작성하고, 다양한 마일스톤을 만들고, 질문의 맥락을 이해하고, 검증 중인 모범 사례를 이해할 수 있으며, 블로그나 re:Invent 강연 또는 공식 문서에서 모범 사례에 대한 추가 리소스를 탐색할 수 있습니다.

AWS WA Tool을 사용하면 사용자 지정 렌즈를 만드는 데도 도움이 됩니다. 사용자 지정 렌즈를 사용하면 자신만의 원칙(Pillar), 질문 및 모범 사례를 만들 수 있습니다. 사용자 지정 렌즈의 질문을 특정 기술에 맞게 조정할 수 있으므로 조직 내 거버넌스 요구 사항을 충족하는 데 도움이 됩니다.

다음 예시를 확인하세요:

검토 단계에서는 특정 모범 사례가 적용되었는지 여부를 설명하는 데 필요한 메모를 작성하는 것이 중요합니다. 모범 사례가 구현되어 있으면 질문의 체크박스를 체크합니다. 구현되지 않은 경우에는 메모 영역에 메모를 작성하여 구현되지 않은 이유를 작성합니다. 로드맵에 포함되어 있나요? 다른 요구 사항과 충돌하나요? 단순히 누락된 것인가요? 이러한 질문에 대한 답변은 나중에 팀이 개선 계획을 수립하는 데 도움이 됩니다. 또한 팀과 담당자가 변경될 수 있으므로 다른 검토자에게도 도움이 됩니다.

마일스톤은 제가 추천하는 또 다른 기능입니다. 마일스톤은 특정 시점의 워크로드 상태를 기록합니다. 여러 세션을 진행하거나 개선 항목에 대해 작업할 때 마일스톤을 저장하여 진행 상황을 측정할 수 있습니다.

7- 시간 관리

WAFR은 짧아야 하며 며칠이 아닌 몇 시간 내에 완료해야 합니다. 검토 프로세스를 간결하게 유지하려면 모범 사례를 검증하기 위한 후속 질문과 심도 있는 기술 토론에 너무 많은 시간을 소비하지 않고 질문의 맥락에 머무르는 것 사이에서 균형을 유지하는 것이 중요합니다.

예를 들어 모니터링은 6개의 원칙(Pillar) 모두에 걸쳐 언급되는 주제입니다. 하지만 그 맥락은 각 원칙(Pillar)마다 다를 수 있습니다. 운영 우수성 원칙을 검토할 때 모니터링은 메트릭과 KPI를 설정하여 통합 가시성을 확보하고 워크로드의 상태를 이해하는 것에 관한 것입니다. 보안 원칙에서 말하는 모니터링은 환경 감사, 악의적인 활동 추적, 승인되지 않은 행동에 대한 이해하는 것 입니다.

또 한 가지 주의할 점은 검토 중에 기술적인 논의로 깊이 들어가는 것을 피해야 한다는 것입니다. 예를 들어, 서비스에 대한 구성 세부 정보를 살펴보는 것을 피해야 합니다. 또한 검토 중에 그 자리에서 올바른 솔루션을 추천하기에는 시간과 필요한 세부 정보가 충분하지 않을 수 있으므로 솔루션 제안에 깊이 들어가지 말아야 합니다. 대신 메모를 해 두었다가 3부에서 살펴보게 될 개선 단계의 일부로 이 주제에 대한 후속 조치를 취하세요.

8- 불명확한 사항에 대한 메모

어떤 경우에는 팀이 모범 사례가 구현되었는지 여부를 확신하지 못할 수도 있습니다. 이 경우 구현되지 않은 모범 사례를 고려하여 WA Tool의 메모에 이를 문서화해야 합니다. 이렇게 하면 개선 단계의 일부로 후속 조치로 솔루션(또는 추가 검증)을 포함할 수 있습니다.

9- 필요에 따라 확장 및 자동화

워크로드가 많은 대규모 조직의 경우 워크로드를 검토하고, 위험을 식별하고, 이를 해결하기 위해 자동화되고 확장 가능한 프로세스를 구축하는 것을 고려하세요.

다음은 제 동료들이 만든 WAFR을 조직에 통합하는 방법에 대한 몇 가지 예입니다. 이러한 솔루션은 조직에 맞게 조정하고 재사용할 수 있습니다.

요약

이 블로그 게시물에서는 다양한 업계의 고객과 함께 Well-Architected Framework Review를 수행하면서 얻은 몇 가지 교훈을 공유했습니다. WAFR의 궁극적인 목표는 아키텍처 내 위험 요소를 식별하고 이를 해결하는 것입니다. 이를 위해서는 먼저 AWS 모범 사례에 따라 워크로드 아키텍처를 검토해야 합니다. WAFR을 실행할 때 따라야 할 몇 가지 권장 사항과 피해야 할 방지 패턴이 있습니다. 검토는 대화식으로 솔직하고 문서화되어야 하며 몇 주가 아닌 며칠 내에 완료되어야 합니다. 여러 워크로드에 대한 검토를 실행하는 경우 조직의 모범 사례에 따라 프로세스를 자동화하고 확장해야 합니다. 이를 위한 몇 가지 예시를 보여드리기 위해 저희 SA와 고객이 제공한 리소스를 공유했습니다. 다음 단계에서는 위험을 식별한 후 이를 해결하기 위한 개선 계획을 만들어야 합니다. 이 부분은 3부에서 다룰 예정입니다.

Kyungshik Shin

Kyungshik Shin

신경식 솔루션즈 아키텍트는 다년간 컨테이너 기반의 서비스 구축/운영과 다양한 산업 분야의 고객사에게 기업향 서비스 연동 및 구축을 지원한 경험을 보유하고 있습니다. 이러한 경험을 바탕으로 고객이 AWS 상에서 비즈니스에 적합한 클라우드 아키텍처를 설계하고 구축할 수 있도록 돕는 역할을 수행하고 있습니다.