성능 달성 및 유지
 시스템이 사용 중이고 발전하는 동안 성능 저하로부터 보호합니다. |
|---|
개발은 일회성 작업이 아닙니다. 이는 진행 중인 프로세스입니다. 기능이 변경되면 성능도 달라질 것으로 예상합니다. Azure Well-Architected의 다른 핵심 요소에서 최적화가 변경되더라도 사용자 패턴과 프로필에는 차이가 있습니다. 어떠한 변화도 워크로드 리소스에 부담을 줄 수 있습니다.
성능 목표가 후퇴하는 것을 방지하기 위해 시스템을 변화로부터 보호합니다. 개발 프로세스에 테스트와 모니터링을 통합합니다. 실제 부하를 사용하여 프로덕션에서 시스템 성능을 테스트하고, 프로덕션에 앞서 자동화된 테스트로 해당 부하를 시뮬레이션합니다. 두 경우 모두 검증 목적으로 모니터링 사례를 갖춰야 합니다.
개발 수명 주기 전체에서 여러 단계에서 여러 형식의 테스트를 수행합니다. 초기 단계에서는 개념 증명을 테스트하여 성능 결과가 전혀 예기치 못한 것이 아닌지 확인합니다. 개발이 진행됨에 따라 벤치마크를 확립하기 위해 수동적이고 활동이 적게 드는 테스트를 실시합니다. 빌드 단계에서는 테스트 계획에 정의된 대기 시간, 스트레스 수준, 부하 용량 및 기타 특성을 평가하는 자동화된 루틴 성능 테스트를 개발하기 시작합니다.
모니터링은 격리된 활동이 아니라 그러한 활동의 필수적인 부분이 되어야 합니다. 시간이 지남에 따라 시스템과 리소스가 어떻게 작동하는지 확인할 수 있습니다. 그런 다음 이를 미세 조정하여 가치를 최대화하고 성능 표준을 지속적으로 충족하도록 할 수 있습니다.
성능 목표는 시간이 지남에 따라, 그리고 변화에 응답하여 달라진다는 점을 유념해야 합니다. 테스트 및 모니터링된 메트릭을 기반으로 성능 모델을 업데이트합니다. 흐름 성능에 미치는 영향이 증가, 감소 또는 전혀 없음을 명확하게 나타냅니다.
항상 기업 관련자와 재협상하고 기대치를 다시 설정할 준비가 되어 있어야 합니다.
예제 시나리오
Contoso Event Solutions에서는 이벤트 입장 담당자가 모바일 디바이스에서 티켓을 검사하고 허가받은 사람에게 티켓이 매진된 장소에 빠르게 입장을 허가하는 데 사용할 수 있는 제품을 제공합니다. 이 시스템은 완전 오프라인 모드와 티켓 중복을 걱정하는 장소를 위한 클라우드 연결 버전으로 제공됩니다. 오프라인 모드는 매우 성능이 좋지만 온라인 모드는 성능 목표를 달성하지 못했습니다. 개발팀은 최근 몇 차례의 개발 주기를 투자해 이 작업을 진행했고, 지금은 성능이 크게 개선되어 목표를 달성하고 있습니다. 기업 관련자들은 조만간 대규모 장소를 지원하기 위해 고객 기반을 확대하려고 합니다.
개발에서의 성능 테스트
릴리스 승격과 프로덕션에 대한 최종 배포를 승인하거나 거부할 수 있는 품질 게이트로 성능 테스트를 공식화합니다.
이러한 검사점은 다음 단계로 넘어가기 전에 배포의 각 단계가 필요한 성능 표준을 충족하는지 확인합니다. 검사점은 의도치 않은 성능 회귀를 방지하는 데 도움이 됩니다. 예를 들어, 성능이 기대치에 크게 못 미치는 경우 개선이 이루어질 때까지 릴리스를 차단할 수 있습니다.
Contoso의 과제
- 팀은 온라인 버전의 애플리케이션에 대해 허용 가능한 성능을 달성하기 위해 상당한 시간과 활동을 투자했지만 현재로서는 회귀를 방지하기 위한 시스템이 없습니다.
- 추가하려고 계획하고 있는 다음 기능은 장소에서 추가 확인을 위해 참석자의 그림과 함께 검사를 보여줄 수 있는 기능을 제공하는 것입니다. 추가로 사진을 검색하고 다운로드하면 프로세스가 느려질 위험이 있습니다.
- 공식적인 프로세스가 없으면 추가 기능으로 인해 온라인 및 오프라인 버전의 성능이 부정적인 영향을 가져오고 대상에 미치지 못할 위험이 있습니다.
접근 방식 및 결과 적용
- 팀은 자동화된 성능 테스트를 빌드 파이프라인에 통합합니다. 빌드 파이프라인에 엄격한 성능 기반 "이동/이동 없음" 기준을 구현함으로써 팀은 새로운 기능이 성능 회귀 없이 릴리스될 가능성이 더 높아졌습니다.
- 빌드의 최신 버전에서 버그를 발견했기 때문에 팀이 이 테스트를 구현한 것은 현명한 결정이었습니다. 이 버그로 인해 스캐너가 오프라인 모드로 설정되어 있는 동안 앱이 이미지를 다운로드하기 위해 인터넷에 연결하려고 시도했고, 이로 인해 티켓을 검사할 때마다 시간 제한이 발생했습니다. 자동화된 테스트로 이 버그를 포착하여 팀에서 새로운 버전을 출시하기 전에 버그를 수정할 수 있었습니다.
가시성을 통한 최적화
프로덕션 프로세스에서 실제 트랜잭션과 성능 목표에 대한 편차를 모니터링하는 반복 가능한 프로세스를 설정합니다. 또한 프로덕션에서 가상 트랜잭션을 사용하고 성능 회귀에 대한 모니터링 경고를 설정합니다.
테스트를 통해 시뮬레이션할 수 없는 실제 부하에서 시스템의 실제 성능에 대한 인사이트가 필요합니다. 그러면 잠재적인 병목 현상, 활용도가 낮은 리소스, 기타 문제 등 문제와 개선 영역을 적극적으로 파악할 수 있습니다.
Contoso의 과제
- 온라인 티켓 유효성 검사를 사용하는 이벤트에서는 백 엔드 시스템이 많이 사용됩니다.
- APM(애플리케이션 성능 모니터링) 시스템은 있지만, 운영 트랜잭션의 상태를 모니터링하는 데 사용되지 않았습니다.
접근 방식 및 결과 적용
- 팀은 상태 메트릭을 더 잘 파악하기 위해 업데이트된 프로세스를 채택하기로 결정했습니다.
- 성능 백분위수와 성능 이상값에 따라 경고를 구성합니다. 경고가 없다는 것은 시스템이 대부분 티켓 검사에 대해 허용 범위 내에서 작동하고 있음을 나타냅니다.
- 오프라인 이벤트가 완료되면 티켓 검사를 위한 원격 분석 데이터가 일괄 처리로 업로드되고, 이러한 메트릭도 허용 가능한 성능과의 차이를 찾기 위한 프로세스를 거칩니다.
- 또한 해당 팀은 성능 모니터링을 강화하기 위해 가상 트랜잭션 테스트도 구현합니다. 거의 모든 이벤트가 주말과 저녁에 진행되기 때문에 팀은 주중 내내 가상 트랜잭션 테스트를 사용하여 더 일관된 성능 기준을 생성합니다.
워크로드 변경 내용을 지능적으로 처리합니다.
사용량이 늘어나고, 기능이 변경되고, 시간이 지남에 따라 데이터가 누적되어 성능이 저하되는 문제를 해결하여 성능을 유지합니다. 미세 조정으로 단기적 이익만 가져올 수 있다면 기대치를 다시 설정하고 새로운 목표를 설정합니다.
이 방식을 채택하면 허용 범위를 넘어 사용자 환경에 부정적인 영향을 미치는 문제로 저하되기 전에 성능 상태를 보존할 수 있습니다.
목표를 변경하면 성능 모델이 다시 설정되고, 이미 용량에 도달한 시스템을 최적화하는 데 시간을 낭비하지 않게 됩니다.
Contoso의 과제
- 영업팀은 적극적으로 새로운 이벤트 장소를 시스템에 온보딩해 왔습니다. 비즈니스가 잘 됩니다.
- 워크로드 모니터링 시스템은 새로운 기능을 도입하지 않아도 시간이 지남에 따라 성능 예산이 점점 더 많이 소모되는 것을 알아차리기 시작했습니다.
- 변화가 없다면 이러한 궤적은 성능에서 허용할 수 없는 회귀로 이어질 수 있으며, 인시던트가 발생했을 때 워크로드가 중단될 위험에 처하게 됩니다.
접근 방식 및 결과 적용
- 팀은 점점 더 많은 고객이 온보딩함에 따라 온라인 이벤트에 대한 데이터 조회 메커니즘이 많은 쿼리에 대해 데이터에 대한 방대한 검사를 수행하고 있다는 사실을 깨닫습니다.
- 일부 쿼리 최적화는 사용 증가로 인한 추가적인 피해를 막는 데 도움이 됩니다. 앞으로 몇 달 동안 팀은 쿼리 검사의 필요성을 줄이기 위해 다양한 이벤트를 각기 다른 데이터 파티션으로 나눌 계획입니다. 이는 워크로드의 지속적인 크기 조정을 지원합니다.
- 또한 오래된 이벤트의 티켓팅 데이터를 제거하면 시스템을 더욱 최적화하여 성장할 수 있다는 사실을 깨닫습니다. 이전 이벤트를 검색하는 것은 티켓 유효성 검사 시스템에서 수행해야 할 작업이 아니므로, 데이터를 보고 및 과거 조회 전용 저장소로 옮길 수 있습니다.