성능 효율성 디자인 원칙

성능 효율성은 워크로드가 수요의 변화에 맞게 조정하는 기능입니다. 워크로드는 사용자 환경을 손상시키지 않고 부하 증가를 처리할 수 있어야 합니다. 반대로 부하가 감소하면 워크로드는 리소스를 보존해야 합니다. 리소스 가용성(CPU 및 메모리)을 나타내는 용량은 중요한 요소입니다.

워크로드 디자인은 사전 프로비전된 용량에만 의존해서는 안 되며, 이는 특정 한도까지 성능을 보장합니다. 해당 제한을 초과하면 워크로드에 성능 문제가 있거나 가동 중단이 발생할 수 있습니다. 부하가 해당 한도 미만이면 리소스가 불필요하게 계속 실행되어 비용이 발생합니다.

시간이 지남에 따라 성능 목표를 유지하기 위한 포괄적인 전략이 필요합니다. 성능 고려 사항은 디자인 프로세스에서 사후 고려가 아니어야 하며 프로덕션에서 문제가 발생할 때만 해결되어야 합니다. 대신 디자인 초기 단계에서 성능이 중요한 고려 사항인 사고방식을 채택합니다. 처음에는 특정 성능 목표 없이 시스템을 빌드합니다. 그러나 여기에서 각 개발 단계에서 성능을 테스트하고 측정하여 진행률과 효율성을 보장합니다. 프로세스 전체에서 이러한 대상을 지속적으로 최적화하고 프로덕션에서 배운 교훈을 통합하면 잠재적인 문제를 사전에 크게 완화할 수 있습니다.

이러한 디자인 원칙은 예상 사용량에 대한 비즈니스 요구 사항을 충분히 충족하기 위해 리소스 용량을 관리하기 위한 전략을 구축하는 데 도움이 될 수 있습니다. 또한 사용량이 많은 시간에 낭비를 줄입니다. 전략을 결정한 후 성능 효율성 검사 목록을 사용하여 디자인을 공고히 합니다.

성능 효율성은 워크로드 리소스의 효과적인 사용에 관한 것입니다. 좋은 전략이 없으면 사용자 요구를 예측하고 충족하지 못할 수 있습니다. 클라우드 플랫폼을 최대한 활용할 수 없는 장기 예측 및 미리 프로비전된 용량의 접근 방식에 의존해야 할 수도 있습니다.

현실적인 성능 목표 협상

의도된 사용자 환경이 정의되어 있으며, 벤치마크를 개발하고 미리 설정된 비즈니스 요구 사항에 대한 목표를 측정하는 전략이 있습니다.

성능 관점에서 디자인 프로세스를 시작하기 위해 잘 정의된 성능 목표를 갖는 것이 이상적입니다. 이러한 목표를 설정하려면 비즈니스 요구 사항과 워크로드가 제공할 것으로 예상되는 서비스 품질을 잘 이해해야 합니다. 비즈니스 관련자와 공동으로 기대치를 정의합니다. 기술 메트릭에만 집중하는 대신 키 흐름에 대한 사용자 환경에 허용되는 영향을 결정합니다.

순환 종속성이 있습니다. 정의하지 않은 항목을 측정할 수 없으며 측정 없이는 정의할 수 없습니다. 따라서 단체 합의로 허용 가능한 임계값의 만족스러운 정의를 달성할 때까지 워크로드 성능을 측정하는 것도 중요합니다.

성능 및 안정성 목표 간에는 강력한 상관 관계가 있어 성능, 가용성 및 복원력 측면에서 서비스 품질을 결정하는 데 도움이 됩니다. 명확한 정의가 없으면 성능을 측정, 경고 및 테스트하기가 어렵습니다. 시간이 지남에 따라 테스트를 통해 대상을 설정하고 실제 숫자를 식별한 후에는 이러한 대상에 대한 지속적인 테스트를 위한 자동화를 구현할 수 있습니다.

대략적인 대상이거나 범위 내에 있더라도 매크로 수준에서 대상을 정의하는 모범 사례를 준수합니다.

접근 방식	이점
기술 개념을 이해하고, 사용 가능한 인프라를 사용하여 디자인 가능성을 탐색하고, 구체적인 실험(가능한 경우)의 결과를 사용하여 효과적인 협상을 준비합니다. 기록 데이터를 사용하여 사용 패턴 및 병목 상태에 대한 가시성을 얻습니다. 시장 분석, 전문가 및 업계 표준의 입력과 같은 외부 요인에서 인사이트를 가져옵니다.	실용적인 인사이트를 기반으로 정보에 입각한 결정을 내릴 수 있습니다. 성능 목표는 실현 가능한 것, 업계 모범 사례 및 현재 시장 동향을 기반으로 하는 사용자 환경에 초점을 맞추고 있습니다.
해당하는 경우 비즈니스 소유자와 협력하여 품질 및 규정 준수 측면에서 사용자 약속을 이해합니다. 광범위한 관점을 유지하고 이 단계에서 세부적인 세부 정보로 다이빙하지 않도록 합니다. 투자에 따라 허용되는 성능을 나타내는 항목에 대해 명시적으로 설명합니다. 비즈니스 컨텍스트 및 예상 성장을 이해합니다.	비즈니스 목표에 맞지 않을 수 있는 가정을 하지 않습니다. 또한 워크로드 팀 내에서 명확성과 동기를 부여합니다. 기능 및 비기능 요구 사항에 대한 비즈니스 컨텍스트를 사용하면 다른 Azure Well-Architected 핵심 요소의 디자인 변경 내용을 파악하고 정보에 입각한 장단을 만드는 데 도움이 될 수 있습니다. 초기에 매개 변수를 정의하면 나중에 잠재적인 솔루션 재설계와 관련된 비용을 방지할 수 있습니다. 이를 통해 성능 목표가 향후 예측을 포함하도록 하여 현재의 노력을 장기적인 목표에 맞출 수 있습니다.
워크로드 흐름을 식별하고 아키텍처 다이어그램에서 흐름의 우선 순위를 지정합니다. 각 흐름의 성능 허용 오차 를 포부에서 허용되지 않는 성능까지의 범위로 정의합니다. 경로의 중요도, 사용 빈도 및 아키텍처 강도를 고려하여 각 흐름의 진입점과 종료 지점을 평가합니다.	흐름의 우선 순위를 지정하면 사용자 및 비즈니스 결과에 가장 큰 영향을 주는 중요한 영역에 리소스를 집중할 수 있습니다. 시스템을 해당 부분 및 종속성으로 세분화하여 각 구성 요소의 기능과 성능에 미치는 영향을 이해합니다. 잠재적인 문제도 알게 됩니다. 성능 기준 및 드라이브 최적화를 설정하는 데 도움이 됩니다.
성능 모델 빌드 시작 사용 패턴이 계절 또는 일별 변형을 표시하는지 여부를 고려합니다. 비즈니스에 대한 비용, 운영 및 중요도를 고려합니다. 업계 표준을 사용하여 백분위수 사용과 같은 메트릭 및 집계 방법을 정량화합니다. 비즈니스 제약 조건이 적용하는 수요 및 공급 기대치 및 제한 사항을 평가합니다. 성장 전망을 통합합니다.	성능 모델은 리소스의 최적 사용에 대한 인사이트를 제공하고 전략적 계획에 도움이 됩니다. 업계 표준은 벤치마킹에 도움이 됩니다. 향후 언어 교정은 성능 목표가 관련성을 유지하고 변경에 적응할 수 있도록 합니다.

용량 요구 사항을 충족하도록 디자인

예상 수요를 해결하기에 충분한 공급을 제공합니다.

성능을 사전에 측정하는 것이 중요합니다. 성능 측정에는 기준을 측정하고 시스템의 어떤 구성 요소가 문제를 야기할 가능성이 있는지를 예비 이해해야 합니다. 전체 성능 테스트를 수행하거나 세분화된 최적화를 통해 수행할 수 있습니다. 이러한 초기 단계를 수행하여 개발 수명 주기 초기에 효과적인 성능 관리를 위한 기반을 설정합니다.

개별 구성 요소에 집중하지 않고 시스템 전체를 검사합니다. 이 단계에서는 미세 조정을 사용하지 마세요. 세분화된 성능을 개선하면 다른 영역에서 절충이 발생합니다. 수명 주기를 진행하고 사용자 승인 테스트를 시작하거나 프로덕션으로 전환할 때 추가 최적화가 필요한 영역을 빠르게 식별할 수 있습니다.

접근 방식	혜택
식별된 흐름에 대한 탄력성 요구를 평가합니다. 애플리케이션과 기본 컴퓨팅 및 데이터 계층을 고려하여 기술 스택 전체에서 구현할 수 있는 디자인 패턴을 살펴봅니다.	더 많은 용량이 필요한 기존 구성 요소와 부하를 분산하기 위해 추가 구성 요소가 필요한 영역에 대한 확장성 요구 사항을 정의 할 수 있습니다. 시스템의 잠재적인 병목 상태를 인식하고 캐싱 기능을 추가하여 대기 시간 및 시스템 부하를 줄이는 것과 같은 보상 컨트롤을 설계합니다.
기술 스택에서 올바른 리소스를 선택하면 성능 목표를 충족하고 시스템과 통합할 수 있습니다. 확장성 요구 사항을 충족할 수 있는 기능을 고려합니다. 예기치 않은 급증을 효율적으로 처리하기 위해 리소스 할당과 시스템 요구 사항 간의 적절한 균형을 찾습니다.	리소스의 다양한 기능을 분석하여 각 구성 요소가 시스템의 전반적인 기능과 성능에 기여하는지 확인합니다. 크기 조정 작업을 자동으로 트리거하는 기본 제공 기능을 활용할 수 있습니다. 적절한 크기 조정 리소스는 과잉 프로비저닝 없이 수요 변화를 충족할 수 있으므로 비용을 절감할 수 있습니다.
수요 및 선택한 리소스의 기능에 따라 용량 계획을 수행하여 성능 모델을 보강합니다. 예측 모델링 기술을 사용하여 예측 가능하고 예기치 않은 변경으로 발생할 수 있는 용량의 예상 변경 내용을 예측합니다. 기술 요구 사항으로 변환할 수 있는 성능 목표를 정의합니다.	리소스를 효율적으로 사용하고 과도하게 프로비전하지 않고 수요를 충족하여 불필요한 비용을 방지할 수 있습니다. 디자인 선택이 성능에 미치는 영향을 이해합니다.
기술 요구 사항 및 디자인 선택 사항의 유효성을 검사하는 개념 증명을 구현합니다.	개념 증명은 디자인의 유효성을 검사하여 시스템이 성능 목표를 충족할 수 있는지, 그리고 이러한 대상이 현실적인지 확인하는 데 중요한 역할을 합니다. 예상 부하에 따라 예상 용량이 성능 목표를 충족할 수 있는지 여부를 확인할 수 있습니다. 또한 디자인 선택 항목의 비용 영향을 확인합니다.
성능 테스트 전략을 문서화합니다. 사용 사례, 다양한 방법론 및 테스트 계획의 주기를 포함합니다. 성능 테스트 계획에 설명된 작업에 대한 프로세스를 정의합니다. 계획에서 테스트 사례를 심사하고 우선 순위를 지정합니다. 성능 목표에 대한 중요한 인사이트를 제공하고 용량 계획을 조정하는 사례에 집중합니다.	시스템의 올바른 측면이 테스트되었는지 확인합니다. 리소스를 효과적으로 할당하고 비즈니스 우선 순위 및 요구 사항에 맞는 방식으로 테스트를 수행할 수 있습니다.
성능 모니터링 전략을 문서화합니다. 식별된 각 흐름에 대해 서로 다른 추상화 수준에서 메트릭을 평가합니다.	개발 주기 동안 성능 목표 달성에 대한 진행 상황을 추적 할 수 있습니다.

성능 달성 및 유지

시스템이 사용 중이고 발전하는 동안 성능 저하로부터 보호합니다.

개발은 일회성 노력이 아닙니다. 진행 중인 프로세스입니다. 기능이 변경됨에 따라 성능이 변경되는 것을 예상합니다. 사용자 패턴 및 프로필에는 차이가 있으며, 다른 Azure Well-Architected 핵심 요소의 최적화 변경도 있습니다. 변경하면 워크로드 리소스에 부담을 줄 수 있습니다.

성능 대상에서 뒤로 밀지 않도록 시스템을 변경으로부터 보호합니다. 개발 프로세스에서 테스트 및 모니터링을 통합합니다. 실제 부하를 사용하여 프로덕션 환경에서 시스템의 성능을 테스트하고 프로덕션 전에 자동화된 테스트로 해당 부하를 시뮬레이션합니다. 두 경우 모두 확인을 위해 모니터링 사례가 있어야 합니다.

개발 수명 주기 동안 다양한 단계에서 다양한 유형의 테스트를 수행합니다. 초기 단계에서 개념 증명을 테스트하여 성능 결과가 완전히 예기치 않은 것은 아닌지 확인합니다. 개발이 진행됨에 따라 수동, 저작업 테스트를 수행하여 벤치마크를 설정합니다. 빌드 단계에서 대기 시간, 스트레스 수준, 부하 용량 및 테스트 계획에 정의된 기타 특성을 평가하는 자동화된 일상적인 성능 테스트 개발을 시작합니다.

모니터링은 격리된 운동이 아니라 이러한 노력의 필수적인 부분이어야 합니다. 시스템 및 해당 리소스가 시간이 지남에 따라 어떻게 작동하는지 확인할 수 있습니다. 그런 다음, 값을 최대화하도록 미세 조정하고 성능 표준을 계속 충족하는지 확인할 수 있습니다.

성능 목표는 변경에 따라 시간이 지남에 따라 달라집니다. 테스트 및 모니터링된 메트릭을 기반으로 성능 모델을 업데이트합니다. 흐름의 성능이 증가, 감소 또는 영향을 주지 않음을 명확하게 나타냅니다.

비즈니스 이해 관계자와 항상 재협상하고 기대치를 재설정할 준비가 되어 있습니다.

접근 방식	혜택
Azure Pipelines에서 일상적인 성능 테스트를 통합합니다. 테스트를 통합할 수 있는 파이프라인을 선택합니다. 반대로 파이프라인에 통합할 수 있는 테스트 도구를 선택합니다.	자동화된 테스트는 시간을 절약하고 회귀 또는 개선 사항을 보다 쉽게 검색할 수 있는 일관성을 제공합니다. 이러한 아티팩트에서는 시간 경과에 따른 편차 또는 드리프트를 지속적으로 모니터링할 수 있으므로 일관된 성능과 품질을 유지할 수 있습니다.
성능 테스트를 릴리스 승격 및 프로덕션에 대한 최종 배포를 승인하거나 거부할 수 있는 품질 게이트로 공식화합니다.	이러한 검사점은 다음으로 진행하기 전에 배포의 각 단계가 필요한 성능 표준을 충족 하는지 확인합니다. 검사점은 의도하지 않은 성능 회귀를 방지하는 데 도움이 됩니다. instance 성능이 예상보다 훨씬 낮으면 개선될 때까지 릴리스를 차단할 수 있습니다.
프로덕션에서 실제 트랜잭션을 모니터링하고 성능 목표에 대한 편차를 모니터링하기 위한 반복 가능한 프로세스를 설정합니다. 프로덕션에서 가상 트랜잭션을 사용합니다. 성능 회귀에 대한 모니터링 경고를 설정합니다.	테스트를 통해 시뮬레이션할 수 없는 실제 부하에서 시스템의 실제 성능 에 대한 인사이트를 원합니다. 그런 다음 잠재적인 병목 현상, 사용이 부족한 리소스 및 기타 우려 사항과 같은 문제 및 개선 영역을 사전에 식별할 수 있습니다.
성능 테스트 결과 및 모니터링 데이터를 꼼꼼하게 검토하고 성능 목표를 달성할 때까지 최적화합니다. 이러한 검토에서 파생된 작업의 우선 순위를 지정하고 계획된 실행을 위해 백로그에 추가합니다.	테스트 결과에 따라 데이터를 캡처 및 비교하고 추세 분석을 시작할 수 있습니다. 최적화 작업은 데이터 기반입니다.
성능에 초점을 맞춘 코딩 기술을 빌드합니다. 성능 기반 코딩 패턴을 예시하는 코딩 표준이 있습니다.	성능 문제가 없는 코드는 테스트가 더 중요한 문제에 초점을 맞출 수 있으므로 테스트 주기를 보다 효율적으로 만들 수 있습니다. 코딩 패턴은 재작업을 방지하고 코딩 스타일을 일관되게 유지하는 데 도움이 됩니다.
성능을 유지하기 위해 시간이 지남에 따라 사용량 증가, 기능 변경 및 데이터가 누적됨에 따라 성능 침식 문제를 해결합니다. 미세 조정이 단기적인 이점만 가져오는 경우 기대치를 재설정하고 새로운 목표를 설정합니다.	성능 저하가 허용 범위를 벗어나는 사용자 환경에 부정적인 영향을 주는 문제로 발전하기 전에 성능 상태를 유지할 수 있습니다. 대상을 변경하면 성능 모델이 다시 설정되며 이미 용량에 도달한 시스템을 최적화하는 데 시간을 낭비하지 않습니다.

최적화를 통해 효율성 향상

정의된 성능 목표 내에서 시스템 효율성을 개선하여 워크로드 가치를 높입니다.

초기 단계에서 설정된 대상은 다양한 제약 조건을 고려하여 적절한 수준의 사용자 환경을 기반으로 합니다. 환경을 더욱 향상시키기 위해 대상을 재평가하고 조정해야 합니다. 환경을 더욱 향상하려면 시스템이 사용되는 방법, 시스템이 어떻게 발전했는지, 그리고 시간이 지남에 따라 플랫폼 또는 기술이 어떻게 변했는지에 대한 명확한 이해가 필요합니다. 모니터링, 최적화, 테스트 및 배포 주기는 연속 프로세스입니다.

효율성 최적화 작업을 통해 워크로드는 더 낮은 리소스 사용량으로 작업할 수 있습니다. 그러면 워크로드가 여분의 용량으로 과도하게 프로비전된 상태가 될 수 있습니다. 해당 용량을 사용하여 시스템의 안정성을 개선합니다. 시스템 비용을 개선하기 위한 용량을 제거합니다. 또는 기존 리소스에서 새 제품 기능을 지원하기 위해 용량을 다시 용도 변경합니다.

시스템의 효율성이 향상되면 새 성능 목표를 설정하고 유지 관리할 수 있습니다.

접근 방식	혜택
기능 영역에서 비기능 요구 사항 및 최적화를 해결하기 위해 성능 최적화를 위한 전용 주기를 할당합니다. 이 최적화의 대상은 리소스, 코드, 데이터 보존, 데이터베이스 쿼리 등입니다.	성능 기반 최적화의 문화를 구축할 수 있습니다. 팀에서 성능 패턴을 사전에 모니터링하고 애플리케이션을 미세 조정해야 합니다.
제한된 시간 또는 예산으로 인해 이전에 고려하지 않았던 방식으로 성능을 향상시킬 수 있는 새로운 디자인 패턴 및 구성 요소로 아키텍처를 개선합니다.	새로운 디자인 및 구성 요소는 시스템을 최적화 하여 사용자 환경을 향상할 수 있습니다. 예를 들어 캐싱 또는 콘텐츠 배달 네트워크 구성 요소 추가를 사용할 수 있습니다. 또한 장기적인 비용 혜택으로 이어질 수 있습니다.
모니터링 도구를 사용하여 기록 추세를 분석 하고 성능 최적화 노력에서 가장 도움이 되는 흐름 및 코드 구현 경로를 식별합니다. 이 목적을 위해 APM(애플리케이션 성능 모니터링) 도구 및 프로파일러를 사용하는 것이 좋습니다. 시스템의 작업 핫 경로 및 기타 잠재적 병목 상태를 식별합니다.	반복되는 문제가 있는 영역을 식별할 때 팀은 이득이 가장 높은 위치에 집중할 수 있습니다.
최신 상태를 유지하고 성능을 향상시킬 수 있는 기술 혁신을 최신 상태로 유지합니다. 종속 프레임워크 및 라이브러리에 대해 릴리스된 새 버전을 활용합니다. 마찬가지로 플랫폼 리소스가 업데이트 및 패치될 때 새 기능을 사용합니다.	새로운 기술을 채택하는 것은 종종 개선 할 수있는 기회를 찾는 동기 부여 요인이 될 수 있습니다. 과거에 느렸을 수 있는 코드는 이러한 업데이트로 더 빨라질 수 있습니다. 또한 특정 업데이트가 성능에 부정적인 영향을 미치는지 알고 싶습니다.

다음 단계

성능 효율성 검사 목록