워크로드 이해

프레임워크를 적용하려면 먼저 분석하려는 워크로드를 이해해야 합니다. 시스템 아키텍처 다이어그램은 시스템의 가장 관련성이 높은 세부 정보를 문서화하기 위한 출발점을 제공합니다. 그러나 많은 시스템에 수많은 구성 요소와 상호 작용이 있기 때문에 전체 워크로드를 분석하는 것은 복잡할 수 있습니다. 대신 다음 사항에 집중하는 것이 좋습니다.사용자 스토리,최종 사용자의 관점에서 작성된 소프트웨어 기능에 대한 비공식적이고 일반적인 설명. 소프트웨어 기능이 고객에게 가치를 제공하는 방법을 설명하는 것이 목적입니다. 그런 다음 아키텍처 다이어그램과 데이터 흐름 다이어그램을 사용하여 이러한 사용자 스토리를 모델링하여 설명된 비즈니스 기능을 제공하는 기술 구성 요소를 더 쉽게 평가할 수 있습니다. 예를 들어, 다음 다이어그램과 같이 인앱 모바일 게임 구매 솔루션에는 '인앱 크레딧 구매'와 '인앱 환불 받기'라는 두 개의 사용자 스토리가 있을 수 있습니다. (이 예제 아키텍처는 시스템을 사용자 스토리로 분해하는 방법을 중점적으로 설명하지만 복원력이 뛰어난 애플리케이션을 나타내기 위한 것은 아닙니다.)

각 사용자 스토리는 코드 및 구성, 인프라, 데이터 저장소, 외부 종속성 등 4가지 공통 구성 요소로 구성됩니다. 다이어그램에는 이러한 구성 요소가 모두 포함되어야 하며 구성 요소 간의 상호 작용이 반영되어야 합니다. 예를 들어, Amazon API Gateway 엔드포인트에 과도한 부하가 발생하는 경우 해당 부하가 시스템의 다른 구성 요소 (예:) 에 어떻게 캐스케이드되는지 생각해 보십시오.AWS Lambda함수 또는 Amazon DynamoDB 테이블. 이러한 상호 작용을 추적하면 장애 모드가 사용자 스토리에 어떤 영향을 미칠 수 있는지 이해하는 데 도움이 됩니다. 이전 그림과 같이 데이터 흐름도를 사용하거나 아키텍처 다이어그램에서 간단한 흐름 화살표를 사용하여 이 흐름을 시각적으로 캡처할 수 있습니다. 각 구성 요소에 대해 전송되는 정보의 유형, 수신되는 정보, 통신이 동기식인지 비동기식인지 여부, 넘어가는 장애 경계와 같은 세부 정보를 캡처해 보세요. 이 예제에서 DynamoDB 테이블은 두 사용자 스토리에서 공유됩니다. 화살표를 보면 인앱 환불 스토리의 Lambda 구성 요소가 인앱 구매 스토리의 DynamoDB 테이블에 액세스한다는 것을 알 수 있습니다. 즉, 인앱 구매 사용자 스토리로 인한 실패가 운명 공유의 결과로 인앱 환불 사용자 스토리로 연쇄적으로 이어질 수 있습니다.

또한 각 구성 요소의 기본 구성을 이해하는 것도 중요합니다. 기본 구성은 초당 평균 및 최대 트랜잭션 수, 페이로드의 최대 크기, 클라이언트 제한 시간, 리소스의 기본 또는 현재 서비스 할당량과 같은 제약 조건을 식별합니다. 새 설계를 모델링하는 경우 설계의 기능 요구 사항을 문서화하고 한계를 고려하는 것이 좋습니다. 이렇게 하면 구성 요소에서 고장 모드가 어떻게 나타날 수 있는지 이해하는 데 도움이 됩니다.

마지막으로, 사용자 스토리가 제공하는 비즈니스 가치를 기반으로 사용자 스토리의 우선 순위를 정해야 합니다. 이 우선 순위를 지정하면 워크로드의 가장 중요한 기능에 먼저 집중할 수 있습니다. 그런 다음 해당 기능의 중요 경로에 속하는 워크로드 구성 요소에 분석을 집중하여 프레임워크를 활용하여 더 빠르게 가치를 실현할 수 있습니다. 프로세스를 반복하면서 우선 순위가 다른 추가 사용자 사례를 검토할 수 있습니다.