솔루션 아키텍처 만들기

올바른 아키텍처를 만들기 위해서는 대체 아키텍처 전략을 조사하는 작업이 필요합니다. 대체 전략의 이점은 선택한 플랫폼, 사용되는 기술 및 코드 재사용 여부에 따라 달라집니다. 각 전략을 구상한 후에는 각 전략의 비용과 이점을 보다 상세하게 조사하기 위해 개념 증명을 확립합니다. 제품 및 품질 요구 사항을 기준으로 전략을 평가하고 최종적으로 제품을 구현하는 데 사용할 전략을 선택합니다. 마지막으로, 보안과 성능은 전체 제품에 대해 어떤 작업을 수행해야 하는지와 관련된 아키텍처 문제입니다.

항목 내용

• 대체 아키텍처 분할 디자인 만들기

• 시스템 아키텍처 배포 디자인

• 개념 증명 만들기

• 대체 전략 평가

• 아키텍처 선택

• 성능 모델 개발

대체 아키텍처 분할 디자인 만들기

문제를 분석하고, 여러 가지 방법을 고려합니다. 비즈니스 및 기술과 관련된 중요한 문제를 나타내는 요구 사항 그룹을 선택합니다. 레거시 시스템의 통합과 같은 이러한 문제의 특징을 조사하고, 현재의 요구 사항을 기반으로 한 향후 요구 사항, 코드의 재사용 가능성 및 유지 관리 비용을 예측합니다.

응용 프로그램 다이어그램 작성

도메인 모델과 요구 사항을 입력 정보로 사용하여 시스템의 핵심 논리 요소를 나타내는 응용 프로그램 다이어그램을 만듭니다. 이 다이어그램은 나중에 시스템 다이어그램으로 분할할 것입니다. 대체 분할 스키마를 고려하고 평가해야 합니다.

응용 프로그램 다이어그램을 나타내는 한 가지 방법은 UML(Unified Modeling Language) 사용 사례 다이어그램을 사용하는 것입니다. 이 유형의 다이어그램은 주요 하위 시스템과 해당 종속성을 표시할 수 있습니다. 또한 각 하위 시스템에 사용 사례를 포함하여 각 사용자 시나리오를 관리하는 하위 시스템을 표시할 수 있습니다.

평가 기준 설정

중요한 아키텍처 문제를 나타내는 요구 사항 및 시나리오를 식별하는 데 사용할 기준을 결정합니다. 기존 엔터프라이즈 아키텍처 문서의 기준을 참조합니다. 비즈니스 요구 사항, 기술 요구 사항 및 새 응용 프로그램에 적용해야 하는 엔터프라이즈 표준을 검토합니다. 아키텍처와 관련하여 중요한 것으로 알려진 추가 기준을 파악합니다. 이러한 기준에는 레거시 시스템과의 통합, 코드의 재사용 가능성, 기존 공급업체 라이브러리 및 플랫폼의 재사용, 유지 관리 비용 제어 등이 있습니다. 기술 솔루션을 구현할 때의 위험 및 비용을 나타내는 추가 기준을 파악합니다.

후보 요구 사항 그룹 선택

평가 기준에 따라 각 서비스 품질 요구 사항과 제품 요구 사항을 평가합니다. 요구 사항이 아키텍처 문제를 나타내는 경우 이를 모델링 후보로 고려합니다. 예를 들어 새 제품이 기존의 고객 데이터베이스를 지원해야 한다는 요구 사항은 레거시 시스템과의 통합 기준을 충족합니다. 이러한 요구 사항은 통합 작동 방식을 모델링하기 위한 후보가 됩니다.

후보 시나리오 그룹 선택

평가 기준에 따라 각 시나리오를 평가합니다. 시나리오가 아키텍처 문제를 나타내는 경우 이를 모델링 후보로 고려합니다. 예를 들어 사용자가 클라이언트 업데이트를 다운로드하는 시나리오는 유지 관리 비용과 관련된 기준을 충족합니다. 이러한 시나리오는 클라이언트 업데이트를 가장 잘 처리할 방법을 모델링하기 위한 후보가 됩니다.

후보 그룹 줄이기

후보 시나리오 및 요구 사항을 검토합니다. 평가 기준이 중복되거나 다른 시나리오 및 요구 사항으로 더 잘 나타낼 수 있는 시나리오 및 요구 사항은 제거합니다. 후보 그룹을 정리하여 새 응용 프로그램의 주요 아키텍처 문제, 위험 및 비용을 나타내는 핵심 그룹을 만듭니다. 즉, 평가 기준을 가장 잘 나타내고, 가장 많은 위험이 있으며, 기술 솔루션을 설계할 때의 잠재적 비용이 가장 많은 시나리오 및 요구 사항을 유지합니다. 또한 응용 프로그램에서 가장 포괄적이거나 핵심적인 부분인 시나리오 및 요구 사항을 유지합니다.

분할 기준 만들기

요구 사항을 동기 요소로 사용하여 외관 또는 모델-뷰-컨트롤러 등의 수립된 아키텍처 패턴을 분석하고 잠재적 구현 후보를 파악합니다. 해당 동기 요소를 통해 후보 패턴을 파악하고, 결합, 응집력, 확장성, 적응성 및 융통성과 관련한 디자인 상충 관계를 고려합니다. 평가에 대한 대안으로 구현 후보 집합을 선택합니다.

시스템 아키텍처 및 배포 디자인

시스템 아키텍처는 응용 프로그램 다이어그램에 식별된 요소의 그룹화 및 구성을 정의합니다. 가능한 각 아키텍처 접근 방법에 대한 시스템 아키텍처를 나타내는 시스템 다이어그램을 만듭니다. 배포 다이어그램에서는 종속성과 핵심 기능을 기반으로 한 배포 단계를 보여 줍니다. 인프라 설계자는 응용 프로그램이 배포될 데이터 센터의 논리적 구조를 나타내는 논리 데이터 센터 다이어그램을 만듭니다. 이 논리 데이터 센터 다이어그램을 기준으로 배포 다이어그램의 유효성을 검사하여 시스템이 배포 가능한지 확인합니다.

시스템 모델 만들기

설계자와 수석 개발자는 응용 프로그램 다이어그램에서 시스템 다이어그램을 만듭니다. 시스템 다이어그램을 통해 재사용 가능한 응용 프로그램 시스템을 배포 단위로 디자인할 수 있습니다. 이때 배포 단위는 응용 프로그램 다이어그램의 요소로 구성합니다. 다른 시스템이 포함된 보다 크고 복잡한 시스템을 분산 시스템 시나리오에서 사용하고 응용 프로그램의 세부 사항을 이러한 시스템으로 추출할 수 있도록 디자인할 수도 있습니다. 새로운 각 다이어그램 파일은 버전 제어에 체크 인합니다.

Visual Studio에서 다음과 같은 방법으로 시스템 다이어그램을 나타낼 수 있습니다.

• 사용 사례 다이어그램: 주요 사용자 시나리오는 사용 사례로 나타내고 해당 시스템의 주요 구성 요소는 하위 시스템으로 표시합니다. 각 사용 사례는 해당 사용 사례를 처리하는 하위 시스템에 포함할 수 있습니다. 자세한 내용은 UML 사용 사례 다이어그램: 지침을 참조하십시오.

• UML 구성 요소 다이어그램: 이러한 다이어그램을 사용하여 구성 요소 간의 통신 채널과 종속성을 표시할 수 있습니다. 클래스 다이어그램을 만들어 구성 요소에 대한 인터페이스에서 볼 수 있는 형식을 기술할 수 있으며, 시퀀스 다이어그램을 만들어 형식의 상호 작용을 표시할 수도 있습니다. 자세한 내용은 UML 구성 요소 다이어그램: 지침, UML 클래스 다이어그램: 지침 및 UML 시퀀스 다이어그램: 지침을 참조하십시오.

• 레이어 다이어그램: 레이어 다이어그램에서는 응용 프로그램의 블록 구조를 나타냅니다. 이 다이어그램에서는 구성 요소와 구성 요소 간의 종속성만 보여 줍니다. 이 다이어그램을 사용하면 코드를 작성한 후 다이어그램을 기준으로 코드와 종속성의 유효성을 검사할 수 있다는 이점이 있습니다. 자세한 내용은 레이어 다이어그램: 지침을 참조하십시오.

각 하위 시스템에 대해 시스템의 형식과 동작을 보다 세부적으로 기술하는 패키지를 만들 수 있습니다. 자세한 내용은 패키지 및 네임스페이스 정의를 참조하십시오.

개념 증명 만들기

아키텍처 개념 증명을 만들면 프로젝트에 발생할 수 있는 위험의 상당수를 완화할 수 있습니다. 프로젝트에서는 아키텍처의 기본적인 부분을 수정하기가 아직 쉬울 때 핵심 전략 및 아키텍처 관련 사항을 결정할 수 있도록 가능한 한 일찍 위험을 해결하는 것이 중요합니다. 개념 증명을 일찍 만들면 전반적인 프로젝트 위험과 알 수 없는 문제를 줄일 수 있습니다. 프로젝트 위험이 낮고 알 수 없는 문제가 적을수록 이후 반복에서의 계획 및 예측이 정확해집니다. 개념 증명은 일시적으로 사용하다가 문제가 처리된 후에 삭제할 수도 있고, 핵심 아키텍처의 기초로 삼을 수도 있습니다.

위험 조사

위험 또는 아키텍처 결정 사항을 파악할 수 있게 해 주는 요소를 이해해야 합니다. 관련 시나리오와 서비스 품질 요구 사항을 조사합니다. 또한 대상 환경 구현을 확인합니다.

접근 방법 계획

필요한 개념 증명의 형식을 결정합니다. 응용 프로그램 및 시스템 다이어그램을 사용하면 계획을 쉽게 세울 수 있습니다. 위험으로 식별된 아키텍처 문제만 해결합니다. 가장 간단한 해결 방법을 찾습니다.

개념 증명 빌드 및 실행

개념 증명을 빌드합니다. 응용 프로그램 다이어그램에서 개념 증명을 구현할 수 있습니다. 해결할 문제에 초점을 맞춥니다. 논리 데이터 센터 다이어그램과 일치하는 실제 환경에 개념 증명을 배포해야 합니다. 실제 환경은 논리 데이터 센터 다이어그램의 설정과 가능한 한 일치해야 합니다. 위험도가 높은 문제를 기준으로 개념 증명을 테스트합니다.

대체 전략 평가

LAAAM(Lightweight Architecture Alternative Analysis Method)은 응용 프로그램을 빌드하기 위한 여러 아키텍처 전략 중 하나를 결정하는 데 사용됩니다. LAAAM을 완료하는 데는 일반적으로 하루가 소요됩니다. 먼저 요구 사항을 기반으로 한 응용 프로그램의 핵심 품질 및 기능 드라이버를 나타내는 유틸리티 트리를 만듭니다. 각 드라이버는 상황, 자극 및 반응으로 작성된 서술문 형태를 취하는 시나리오로 작성됩니다. 평가 매트릭스를 사용하여 각 전략이 각 시나리오를 얼마나 잘 처리할지 평가합니다.

유틸리티 트리 만들기

서비스 품질 요구 사항과 제품 요구 사항을 조사하여 응용 프로그램의 품질 및 기능을 향상시킬 수 있는 핵심 요소를 결정합니다. 응용 프로그램의 전반적인 품질을 나타내는 유틸리티 트리를 구성합니다. 트리의 루트 노드에는 유틸리티라는 레이블을 지정합니다. 하위 노드에는 일반적으로 수정 가능 여부, 가용성 및 보안과 같은 표준 품질 용어로 레이블을 지정합니다. 이 트리는 품질의 계층적 특성을 나타내고 우선 순위를 지정하기 위한 기초를 제공해야 합니다. 트리의 각 수준은 보다 세부적인 품질을 나타냅니다. 최종적으로 이러한 품질은 시나리오가 됩니다.

평가 매트릭스 구성

유틸리티 트리의 각 리프에 대해 시나리오를 작성합니다. 이 시나리오는 예를 들어 "일반적인 작업에서 100밀리초 미만으로 데이터베이스 트랜잭션을 수행합니다."와 같이 상황, 자극 및 반응의 형태로 표현됩니다.

스프레드시트나 표를 만들고, 각 시나리오를 이 평가 매트릭스의 한 행으로 입력합니다. 각 아키텍처 전략은 열로 입력합니다. 전략과 시나리오가 교차하는 각 셀에는 1부터 4까지의 등급을 입력합니다.

등급을 입력할 때는 다음 요소를 고려해야 합니다.

• 개발 비용: 이 솔루션을 구현하기가 쉽습니까, 어렵습니까? 비용이 다른 영역에 미치는 영향은 무엇입니까?

• 작동 비용: 런타임에 이 솔루션을 작동하기가 쉽습니까? 아니면 이로 인해 효용성, 성능 등에 부정적인 영향이 있습니까?

• 위험: 이 솔루션으로 해당 시나리오를 잘 해결할 수 있는 것이 확실합니까? 아니면 알 수 없는 비용이 있습니까? 이 솔루션으로 인해 팀이 이후의 향상된 내용을 요구 사항에 포함하는 데 부정적인 영향을 받을 수 있습니까?

개념 증명이 전략을 위해 만들어진 경우 해당 개념 증명의 정보를 사용하면 등급을 쉽게 결정할 수 있습니다.

표의 맨 밑에는 시나리오의 등급 합계를 표시합니다. 이러한 수치는 대체 아키텍처에 대한 사항을 결정하기 위한 토론에서 기초 자료로 사용합니다.

완성된 평가 매트릭스는 프로젝트 포털에 업로드합니다.

아키텍처 선택

평가 매트릭스를 만든 후 검토 회의를 소집하여 다음 반복에 사용할 아키텍처를 결정합니다. 개념 증명을 만들어 찾은 평가 매트릭스 및 정보를 사용하면 의사 결정을 쉽게 할 수 있습니다. 아키텍처를 선택한 후에는 해당 아키텍처의 다이어그램을 참조 솔루션으로 체크 인하고 해당 아키텍처를 선택한 이유를 설명하는 사유서를 만듭니다.

검토 준비

설계자와 수석 개발자는 제안된 아키텍처를 검토하기 위한 적절한 검토자를 지정하고 해당 아키텍처에 대한 설명서를 각 참가자에게 배부합니다.

시스템 아키텍처 및 배포 아키텍처 검토

검토 회의 도중에는 시스템 다이어그램, 배포 보고서 및 논리 데이터 센터 다이어그램을 검토합니다. 검토 목적은 다음 반복에서 구현할 아키텍처를 선택하는 것입니다.

각 아키텍처의 평가 매트릭스 등급을 참조하면 각 아키텍처의 적합성을 쉽게 평가할 수 있습니다. 여러 아키텍처를 구현하는 데 관련된 비용 또는 복잡성과 같이 개념 증명에서 찾은 모든 정보를 고려하십시오. 수정할 수 없는 기존 데이터 센터를 나타내는 논리 데이터 센터 다이어그램은 검토하지 마십시오. 데이터 센터를 만들 때는 다이어그램에서 배포 고려 사항을 검토하고, 사용할 아키텍처를 선택합니다. 시나리오를 기준으로 아키텍처 개념을 검토하여 솔루션이 고객의 요구를 충족하며 완전한지를 확인합니다.

참조 솔루션 만들기

회의의 결정 사항을 설명하는 사유서를 만듭니다. 그런 다음 이를 프로젝트 포털에 업로드합니다. 선택한 아키텍처의 경우, 응용 프로그램, 시스템 또는 논리 데이터 센터 다이어그램을 다음 반복에서 기능을 구현하는 데 사용할 참조 솔루션으로 체크 인합니다. 다음 반복에 대해 선택된 아키텍처와 관련된 결정 사항을 팀 전체와 종속된 팀에 전달합니다.

성능 모델 개발

성능 모델링은 응용 프로그램의 잠재적 성능 문제를 파악하고 해결하는 데 사용됩니다. 성능 모델은 서비스 품질 요구 사항에서 개발된 다음 개발 작업으로 세분됩니다. 각 개발 작업에는 구현을 위한 성능 예산이 할당됩니다.

서비스 성능 품질 요구 사항에 연결되는 시나리오를 식별합니다. 그런 다음 이 시나리오에 개발 작업을 매핑합니다. 서비스 품질 요구 사항 목록에서 응용 프로그램의 작업 부하를 결정합니다. 작업 부하 예상 값과 서비스 품질 요구 사항 목록을 사용하여 각 주요 시나리오의 성능 목표를 식별합니다. 여기에는 응답 시간, 처리량 및 리소스 사용량 같은 목표가 포함됩니다. 성능 목표를 달성하기 위해 예산이 할당된 성능 관련 리소스를 파악합니다. 성능 관련 리소스의 예로는 실행 시간과 네트워크 대역폭이 있습니다. 각 리소스의 허용 가능한 최대 할당을 확인합니다.

예산이 할당된 리소스를 각 시나리오의 처리 단계에 분배합니다. 예산을 어떻게 할당할지 확실히 알 수 없으면 최대한 정밀하게 추정하거나 리소스를 각 단계에 고르게 분배합니다. 예산은 유효성 검사 중에 조정됩니다. 적절한 개발 작업에 대한 할당을 연결하거나 작성합니다.

성능 목표를 충족하는 데 위험이 되는 예산 할당을 찾습니다. 디자인 및 대체 배포 방법 등 성능 목표를 충족하는 데 유용한 장단점을 고려합니다. 필요한 경우 서비스 품질 요구 사항을 다시 평가합니다.

예산 할당을 충족하지 않는 시나리오를 파악하고, 해당 시나리오의 성능을 측정합니다. 코드를 사용할 수 없는 경우 초기 반복에서 프로토타입을 사용합니다. 유효성 검사 중에 얻은 데이터를 사용하여 예산 설정, 평가 및 유효성 검사 단계를 필요한 만큼 반복합니다.

위협 모델 개발

자세한 내용은 Microsoft 웹 사이트의 RemapDBs Command 페이지를 참조하십시오.