워크로드 아키텍처 디자인 사양
워크로드 아키텍처 디자인 사양은 디자인 선택을 설명하고 다이어그램과 함께 제공되는 자세한 사양입니다. 디자인 선택은 기능 및 비기능적 요구 사항을 충족하고 루틴, 임시 및 응급 작업에 대한 프로비저닝을 포함해야 합니다.
다이어그램에 대한 자세한 내용은 아키텍처 디자인 다이어그램을 참조 하세요.
일반적으로 광범위한 워크로드 아키텍처 디자인은 애플리케이션 디자인부터 시작하여 클라우드 서비스 선택으로 진행됩니다. 이러한 단계는 서로에게 상호 알릴 수 있습니다. 결합된 애플리케이션 및 인프라 디자인은 모든 요구 사항을 충족해야 합니다.
모든 요구 사항을 충족하는 솔루션을 달성하는 것은 이해 관계자, 개발자, 테스터, 운영 팀 및 제품 소유자 간의 공동 작업입니다. 디자인 프로세스에는 명확성과 협상을 통해 요구 사항을 구체화해야 합니다. 이 프로세스는 반복적이며 종종 여러 검토가 필요합니다.
디자인 원칙 및 권장 사항 가이드를 포함하는 Azure Well-Architected Framework 기본 지침에 맞게 설계를 조정하고 장단을 인정하는 것이 좋습니다.
궁극적으로 워크로드 아키텍처 디자인 사양은 워크로드 개발 팀에서 구현하므로 명확하고 모호해야 합니다. 사양을 쉽게 사용할 수 있고 워크로드 설명서와 함께 저장해야 합니다.
기능 사양
워크로드에 대한 기능 사양은 개발 중인 시스템 또는 기능의 내용과 이유를 자세히 설명하지만 구현은 자세히 설명하지 않습니다. 이 문서에서는 현재 존재하는 문제와 이 기능 또는 시스템이 해당 환경을 개선하는 방법을 설명해야 합니다. 이 문서에서는 대부분의 비즈니스 요구 사항을 캡처합니다.
설계자는 이 문서를 구체화하는 데 도움을 줄 수 있지만, 주로 제품 소유권의 기능입니다. 설계자는 이 사양에서 캡처된 데이터를 디자인하는 데 도움을 주어야 합니다. 이러한 참여를 통해 기능 사양은 효과적이고 효율적인 기술 설계를 구동합니다.
다음은 이 사양에서 다루어야 하는 몇 가지 예제 항목입니다.
이 디자인의 범위에 무엇이 있는지 자세히 설명하는 것 외에도 범위를 벗어난 인접한 문제에 대해서도 명시해야 합니다. 명확한 범위를 설정하면 기능 주위의 경계를 정의하여 범위 크리프가 줄어듭니다.
이 변경 내용을 측정하는 방법에 대한 세부 정보를 포함하는 것이 유용합니다. 수집해야 하는 측정값과 해당 측정값이 지원하는 비즈니스 목표
사용자 흐름을 명확하게 설명해야 합니다. 낮은 공급 모의뿐만 아니라 도움이 될 수 있습니다. 이러한 흐름에 오류 처리 상황이 중요한 경우 설명된 예상 동작을 확인합니다.
항상 접근성, 규정 준수, 성능, 개인 정보 보호 또는 보안에 대한 특정 요구 사항을 포함합니다.
계획된 출시 전략을 포함합니다. 예를 들어 "이 기능은 전체 릴리스를 결정하기 전에 2개월 동안 베타 사용자가 사용할 수 있습니다."
이 사양에서 특정 기술 구현 세부 정보를 사용하지 않습니다. 이러한 기능 사양은 설계자가 만든 기술 사양을 구동합니다.
기술 사양
기술 사양은 기능 사양에 설명된 범위 및 목표를 기반으로 하는 방법을 설명합니다. 이 사양은 엔지니어링 팀이 구현하는 동안 레코드 계획으로 사용하도록 설계되었습니다.
이 사양에는 다음과 같은 항목이 포함되었습니다.
- 구매, 빌드, 재사용, 확장 또는 서비스 해제를 비롯한 기술 결정
- 이전 버전과의 호환성 구현 전략을 포함한 API 및 데이터 계약(스키마)
- 롤아웃 및 롤백 구현 세부 정보
- 고유한 SDL(보안 개발 수명 주기) 및 개인 정보 구현
- 테스트 계획
- 주요 모니터링 및 경고 신호 원본
- 고려된 대체 디자인
기술 사양은 엔지니어링 작업을 주도합니다. 엔지니어링 작업 항목은 주로 이 사양의 내용에서 만들어집니다. 구현 팀은 작업 항목, 기술 사양 및 기능 사양을 참조하여 최종 결과가 기능 및 비기능 요구 사항을 모두 충족하는지 확인합니다.
재해 복구 계획
워크로드에 대한 안정성 요구 사항을 충족하기 위해 설계자는 RTO(대상 복구 시간 목표) 및 RPO(복구 지점 목표) 목표 내에서 복구할 수 있는 시스템을 설계해야 합니다. 아키텍처 디자인 사양에는 복구 계획이 포함되어야 합니다. 이 계획은 관련된 아키텍처 구성 요소, 장애 조치(failover) 메커니즘 및 사용자 및 데이터 흐름에 미치는 영향, 운영 권장 사항을 포함해야 합니다. 디자인에서 충족되는 복구 대상과 방법을 설명해야 합니다.
초기 계획은 드릴 및 인시던트 후 검토의 인사이트를 기반으로 진화할 것으로 예상되지만 모든 새 아키텍처에 대한 초기 계획을 제공하는 것은 설계자의 책임입니다.
보안 및 규정 준수 설명서
설계자는 관련 보안 및 규정 준수 제약 조건을 준수하는 솔루션을 설계할 책임이 있습니다. 디자인 아티팩트는 이러한 요구 사항을 지원하고 요구 사항을 직접 충족할 수 없는 경우 필요한 보상 컨트롤을 식별하기 위해 디자인에 통합된 어포던스를 강조하는 것이 중요합니다.
일관성
템플릿을 사용하여 워크로드의 다양한 사양을 문서화합니다. 일관성은 사양을 읽을 때 관련자, 책임 있는 당사자 및 구현 팀에 도움이 됩니다.
사양에 다음과 같은 주요 메타데이터 필드가 있는지 확인합니다.
- 상태: 초안, 검토 중 및 승인됨 상태입니다.
- 작업 항목 링크: 팀의 백로그에 있는 기본 작업 항목에 대한 링크입니다.
- 키 교차 링크: 관련 사양 또는 사양을 지원하는 기타 설명서에 대한 링크입니다.
- 주요 개인: 관련된 주요 의사 결정자의 이름을 나열하는 장소입니다. 이 목록에는 비즈니스 분석가, 비즈니스 파트너, 기술 책임자, 사양에 따라 로그오프한 제품 소유자 또는 잠재 고객 등의 역할이 포함될 수 있습니다.