현실적인 성능 목표 협상
 의도된 사용자 환경이 정의되며, 미리 설정된 비즈니스 요구 사항에 대해 벤치마크를 개발하고 목표를 측정하는 전략이 있습니다. |
|---|
성능 관점에서 디자인 프로세스를 시작하기 위해 잘 정의된 성능 목표를 갖는 것이 이상적입니다. 이러한 목표를 설정하려면 비즈니스 요구 사항과 워크로드가 제공할 것으로 예상되는 서비스 품질을 잘 이해해야 합니다. 비즈니스 관련자와 공동으로 기대치를 정의합니다. 기술 메트릭에만 집중하는 대신 키 흐름에 대한 사용자 환경에 허용되는 영향을 결정합니다.
순환 종속성이 있습니다. 정의하지 않은 항목을 측정할 수 없으며 측정 없이는 정의할 수 없습니다. 따라서 단체 동의를 통해 허용 가능한 임계값의 만족스러운 정의를 달성할 때까지 워크로드 성능을 측정하는 것도 중요합니다.
성능 및 안정성 목표 간에는 강력한 상관 관계가 있으므로 성능, 가용성 및 복원력 측면에서 서비스 품질을 결정하는 데 도움이 됩니다. 명확한 정의가 없으면 성능을 측정, 경고 및 테스트하기가 어렵습니다. 시간이 지남에 따라 테스트를 통해 대상을 설정하고 실제 숫자를 식별한 후에는 이러한 대상에 대한 지속적인 테스트를 위한 자동화를 구현할 수 있습니다.
근사값이거나 범위 내에 있더라도 매크로 수준에서 대상을 정의하는 모범 사례를 준수합니다.
예제 시나리오
Contoso Bike는 미국 소비자 자전거 브랜드에 직접 적용됩니다. 개발 팀은 Contoso의 계획된 모바일 자전거 수리 서비스 제공을 지원하기 위해 앱을 빌드하는 작업을 시작했습니다. 앱은 현재 개념 증명 단계에 있습니다. 기술자는 모바일 앱을 사용하여 일정 및 작업 주문을 관리하고 결제를 수행합니다. 고객이 서비스를 예약하는 데 웹 사이트가 사용됩니다. 웹앱, 모바일 앱 및 백 엔드 API는 모두 Azure 앱 서비스에서 호스트될 가능성이 높습니다.
성능 목표 협상 준비
기술 개념을 이해하고, 사용 가능한 인프라를 사용하여 설계 가능성을 탐색하고, 구체적인 실험 결과를 사용할 수 있는 경우 사용하여 효과적인 협상을 준비합니다. 기록 데이터를 사용하여 사용 패턴 및 병목 상태에 대한 가시성을 얻습니다. 시장 분석, 전문가 및 업계 표준의 입력과 같은 외부 요인에서 인사이트를 가져옵니다.
실질적인 인사이트를 기반으로 정보에 입각한 결정을 내릴 수 있습니다.
성능 목표는 실현 가능한 기능, 업계 모범 사례 및 현재 시장 동향을 기반으로 하는 사용자 환경에 초점을 맞추고 있습니다.
Contoso의 과제
- 비즈니스 관련자와 애플리케이션에 대한 논의에서 성능은 아직 논의되지 않았습니다.
- 개발 팀은 Azure를 익숙하지 않으므로 플랫폼의 성능 및 크기 조정 기능에 익숙하지 않습니다.
- 이해 관계자의 지침과 가능한 것에 대한 실질적인 지식이 없으면 팀은 나중에 다시 빌드하기 위해 테스트용 인프라를 배포해야 할 까봐 걱정하고 있습니다.
- 팀은 또한 다음에 만날 때 아무도 현실적인 성과 목표에 대해 이야기 할 준비가되지 않을 까봐 걱정하고 있습니다.
접근 방식 및 결과 적용
- Contoso 비즈니스 분석가와 개발자는 우려 사항에 대해 논의하고 계획을 수립합니다. 비즈니스 분석가는 경쟁 분석 및 비공식 투표를 통해 성능 기대치를 연구하고 개발 팀은 다양한 가격 책정 계층에 대한 Azure의 기능과 옵션을 연구할 것입니다.
- 팀은 컴파일한 데이터를 가져오는 비즈니스 이해 관계자와 다시 그룹화하고 이 데이터를 성능 목표에 대한 협상의 기초로 사용합니다. 잠재적인 성능 기능 및 관련 비용에 대한 논의를 통해 모든 당사자는 워크로드에 App Services를 사용하는 것에 대해 좋은 느낌을 줍니다.
효과적으로 성능 목표 협상
해당하는 경우 비즈니스 소유자와 협력하여 품질 및 규정 준수 측면에서 사용자 약속을 이해합니다. 광범위한 관점을 유지하고 이 단계에서 세부적인 세부 정보로 다이빙하지 않도록 합니다. 투자에 따라 허용되는 성과를 나타내는 것에 대해 명시하고 비즈니스 컨텍스트 및 예상 성장을 이해합니다.
이 접근 방식을 채택하면 비즈니스 목표에 맞지 않을 수 있는 가정을 하지 않습니다. 또한 워크로드 팀 내에서 명확성과 동기를 부여합니다.
기능 및 비기능 요구 사항에 대한 비즈니스 컨텍스트가 있으면 다른 Azure 잘 설계된 핵심 요소의 디자인 변경 내용을 파악하고 정보에 입각한 장단을 만드는 데 도움이 될 수 있습니다.
매개 변수를 초기에 정의하면 나중에 잠재적 솔루션 재설계와 관련된 비용을 방지할 수 있습니다. 이를 통해 성능 목표가 향후 예측을 포함하도록 할 수 있으므로 현재의 노력을 장기적인 목표에 맞출 수 있습니다.
Contoso의 과제
- 아키텍처 팀은 받아들일 수 있는 것에 대한 대략적인 아이디어를 가지고 있지만 아직 구체적인 내용은 없습니다. 건축가들은 일반적으로 자신이 선택한 애플리케이션 플랫폼으로 재작업을 피할 수 있어야 한다고 생각하지만, 지금까지 얻은 것보다 좀 더 특이하게 자신감을 가질 것입니다.
- 이 시점까지 성능 토론은 모호했으며 "웹 사이트는 빠를 필요가 있습니다."와 같은 진술이 있었습니다.
- 좀 더 구체적으로 말하자면, 설계자는 성능을 위해 디자인을 과도하게 설계하거나 릴리스를 프로덕션으로 되돌리는 지연에 직면할 수 있다고 걱정합니다.
접근 방식 및 결과 적용
- 비즈니스 파트너와 기술 팀은 일반적이지만 현실적인 목표와 피해야 할 몇 가지 절대 제한에 대한 합의를 얻기 위해 만납니다. 이러한 기능을 통해 설계자는 초기 설계의 일부로 개념 증명을 수행하여 애플리케이션 플랫폼에 대한 광범위한 합의를 도출하고 성능과 가격 책정에 대한 몇 가지 결과를 제시할 수 있습니다.
- 이 회의의 결과 중 하나는 Contoso Bike가 첫 해 미국 남서부에서만 운영할 계획이지만 2년차에는 전국적으로 확장될 것이라는 것을 알고 있다는 것입니다. 이 정보는 디자인에 고려됩니다.
흐름 중심 포커스를 사용하여 디자인
워크로드 흐름을 식별하고 아키텍처 다이어그램에서 흐름의 우선 순위를 지정합니다. 각 흐름의 성능 허용 오차를 포부에서 허용되지 않는 성능까지의 범위로 정의합니다. 경로의 중요도, 사용 빈도 및 아키텍처 강도를 고려하여 각 흐름의 진입점과 종료 지점을 평가합니다.
흐름의 우선 순위를 지정하면 사용자 및 비즈니스 결과에 가장 큰 영향을 주는 중요한 영역에 리소스를 집중할 수 있습니다.
시스템을 해당 부분 및 종속성으로 분해하여 각 구성 요소의 기능과 성능에 미치는 영향을 이해합니다. 잠재적인 문제도 알게 됩니다.
성능 기준 및 드라이브 최적화를 설정하는 데 도움이 됩니다.
Contoso의 과제
- 지금까지 기술 팀은 관련자와 협력하여 높은 수준의 성능 목표를 식별했지만 아직 개별 흐름에 초점을 맞추지 않았습니다. 디자인 팀이 서비스 로케이터 및 결제 흐름과 같은 흐름을 자세히 살펴볼 수 있도록 하려면 해당 흐름에 대한 요구 사항을 이해해야 합니다.
- 이러한 특정 요구 사항이 없으면 키 흐름에 대한 리소스를 할당하거나 우선 순위가 낮은 흐름에 대한 리소스를 할당할 때 디자인 위험이 있습니다.
접근 방식 및 결과 적용
- 비즈니스에서 사용자 흐름을 검토한 후 아키텍처 팀은 이제 각 흐름에 대해 문서화된 매우 구체적인 목표를 가지고 있습니다. 이제 워크로드의 분해는 흐름당 수용 불가의 포부 범위를 고려합니다.
- 설계자는 추가 기능으로 시간이 지남에 따라 시스템을 개발할 수 있는 공간을 허용하는 동시에 비용 및 기타 비기능적 요구 사항을 제어하기 위해 어느 정도 타협할 수 있도록 설계로 포부 목표를 달성하기 위해 노력할 것입니다.
- 팀은 합의된 대상을 중심으로 설계를 완료할 수 있으며, 이제 구현 팀은 이러한 제한을 준수하고 작업 중인 디자인으로 달성할 수 없는 경우 문제를 제기할 책임이 있습니다.