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