성능

제품 정의 단계에서 사용자 기대치를 수집하고 비즈니스 요구 사항을 정량화한 다음 이를 이후 제품 아키텍처와 설계의 기반으로 활용하세요.

잘 설계된 솔루션의 구성 요소는 독립적으로 확장할 수 있습니다. 예를 들어 서비스 인스턴스를 하나 더 추가할 수 있습니다. 그러나 구성 요소를 추가하거나 제거하면 솔루션의 다른 부분에 연쇄적인 영향이 발생할 수 있습니다. 예를 들어 웹 트래픽이 급증했을 때 웹 서버를 하나 더 추가하면 백엔드 서비스와 통신하기 위한 메시지 큐가 더 필요할 수 있습니다. 확장 의존성을 미리 이해하면 솔루션의 운영 동작을 파악하고 단일 리소스를 과도하게 확장하여 리소스가 고갈되는 상황을 방지하는 데 도움이 됩니다.

잘 설계된 하이브리드 클라우드 솔루션은 멀티 플랫폼 아키텍처와 확장 및 버스팅 전략을 활용하여 성능뿐 아니라 보안, 운영 비용 및 최종 사용자 기대치를 최적화합니다. 예를 들어 강력한 성능 보장과 고정 운영 비용을 제공하는 온프레미스 인프라에서 워크로드를 실행하고 피크 워크로드 시에는 퍼블릭 클라우드 서비스 제공업체로 버스팅 또는 확장할 수 있습니다.

데이터 이동에는 많은 비용이 듭니다. 잘 설계된 솔루션은 컨테이너화된 워크로드의 이동성과 이식성을 활용하여 서비스가 사용하는 데이터에 최대한 가까운 위치에 서비스를 배치합니다.

솔루션은 아키텍처의 가치를 극대화하기 위해 적절한 플랫폼과 리소스를 선택해야 합니다. 하이브리드 클라우드 솔루션은 온프레미스 인프라를 포함한 여러 클라우드에 걸쳐 운영될 수 있으므로 아키텍트는 솔루션의 성능 요구 사항을 충족하기 위한 최적의 리소스 조합을 선택할 수 있습니다.

솔루션은 서버에 CPU를 추가하는 것처럼 기존 장치의 용량을 변경하는 방식이 아니라 서버, 서비스, 네트워크 인터페이스와 같은 개별 단위를 추가하거나 제거하여 처리 용량을 늘리거나 줄일 수 있도록 설계되어야 합니다. 이를 위해 솔루션은 다음과 같은 아키텍처 원칙을 채택해야 합니다.

• 상태 비저장 컴포넌트는 상호 작용 사이에서 클라이언트 또는 세션 상태(예: 사용자 ID 또는 이전 호출에서 제공된 데이터 입력)를 유지하지 않는 컴포넌트로 클라이언트와 특정 컴포넌트 인스턴스 간의 의존성을 제거합니다. 컴포넌트와 해당 서비스를 사용하는 소비자 간의 이러한 의존성 부족은 컴포넌트 인스턴스를 추가하거나 제거하여 서비스를 사용하는 소비자에게 영향을 주지 않고도 솔루션을 확장하거나 축소할 수 있음을 의미합니다. 상태 비저장 컴포넌트의 좋은 예는 식료품점의 계산원입니다. 최소 한 명의 계산원이 있는 한 고객은 계산을 하고 결제를 할 수 있으며 고객 수에 따라 계산원을 추가하거나 줄일 수 있습니다. 이와 반대되는 경우는 고객이 쇼핑을 시작할 때 특정 계산원에게 배정되는 경우입니다. 배정된 계산원이 바빠지거나 더 나쁜 경우 이용할 수 없게 되면 고객은 기다리거나 처음부터 다시 시작해야 하며 식료품점의 전체 성능(시간당 고객 수로 측정)이 저하됩니다.

• 장시간 실행 작업을 피하세요. 솔루션이 장시간 실행 작업(예: 복잡한 과학 계산)을 지원해야 하는 경우 리소스가 추가되거나 제거될 때 작업을 중단하고 체크포인트를 통해 종료 및 재시작할 수 있도록 설계하여 스케일 인 또는 스케일 아웃을 지원해야 합니다.

• 끝단에 데이터를 배치하세요. 상태 비저장 컴포넌트는 이론적으로 무한히 확장할 수 있으며 여러 클라이언트 간에 재사용할 수 있습니다. 고성능 솔루션은 상태, 즉 사용자 및 애플리케이션 데이터를 솔루션 아키텍처의 끝단에 있는 클라이언트 애플리케이션과 데이터베이스로 이동시키고 중간 아키텍처 계층에는 상태를 유지하지 않습니다.

리소스:
상태 저장 vs 상태 비저장

솔루션을 높은 응집도와 느슨한 결합을 갖는 컴포넌트 집합으로 설계하면 각 컴포넌트가 제공하는 서비스의 수요에 맞춰 독립적으로 확장할 수 있습니다. 서비스 지향 아키텍처와 마이크로서비스와 같은 아키텍처 접근 방식은 이 실천 방법을 핵심 설계 원칙으로 포함하며 이는 높은 수준의 느슨하게 결합된 API를 통해 통신하는 높은 응집도의 서비스 집합을 의미합니다.

솔루션의 구성 요소 간에 데이터를 이동하는 작업은 종종 트랜잭션에서 가장 시간이 많이 소요되는 요소입니다. 구성 요소는 사용 가능한 대역폭에 맞게 통신의 빈도와 양을 최적화하도록 설계해야 합니다. 예를 들어 데이터베이스에서 개별 값을 반복적으로 호출하여 가져오는 애플리케이션은 로컬 네트워크에 배포된 경우에는 ‘충분히 잘’ 작동할 수 있지만 데이터베이스 구성 요소가 클라우드 서비스 제공업체로 이전되면 지연이 발생할 수 있습니다.

웹 기반 애플리케이션에서 일반적으로 사용되는 REST(Representational State Transfer) 아키텍처 스타일은 잘 설계된 솔루션에서 나타나는 균형의 좋은 예입니다. 리소스의 전체 표현 상태가 JSON, XML 또는 기타 문서 형식으로 전송되어 웹 기반 상호 작용의 높은 지연 시간과 전송되는 정보의 양 사이의 균형을 맞춥니다.

캐싱은 데이터를 생성하는 리소스와 서비스에 대한 수요를 제한하는 데 도움이 됩니다. 수명이 길고 비교적 정적인 데이터 또는 생성 비용이 높은 데이터에 대해 캐싱 사용을 고려하세요. 잘 설계된 솔루션은 솔루션 아키텍처의 모든 계층에 캐싱 메커니즘을 구현하며 소비자와 캐시 간의 통신을 최소화하고 전체 응답 시간을 개선하기 위해 캐시를 가능한 한 소비자와 가까운 위치에 배치합니다.

아키텍트는 캐싱이 과도하게 사용될 수 있다는 점을 염두에 두어야 합니다. 잘못 설계된 캐싱 메커니즘이나 지나치게 큰 캐시는 솔루션의 전체 성능에 부정적인 영향을 줄 수 있습니다. 아키텍트는 캐싱 유형과 전략을 평가한 후 성능 테스트와 분석 과정에서 캐시의 효과를 측정해야 합니다.

메시지 큐, 콜백 모델 또는 기타 방법을 사용하는 비동기 메시징은 솔루션이 효율적으로 확장될 수 있도록 하고 리소스가 고갈될 경우에도 부하 상황에서 점진적으로 성능이 저하되도록 합니다. 잘 설계된 솔루션은 특히 메시지 큐와 같은 비동기 통신을 활용하여 최종 사용자에게 반응성이 높은 사용자 경험을 제공하고 구성 요소가 실패하더라도 사용자 요청이 ‘유실’되는 것을 방지합니다. 이 동일한 메커니즘은 서로 다른 서비스 수준이나 운영 시간을 가진 시스템을 연결하는 데에도 사용할 수 있습니다. 예를 들어 메시지 큐를 통해 연중무휴 24시간 웹 애플리케이션을 9시부터 5시까지 운영되는 시스템 오브 레코드와 연결하면 시스템 오브 레코드가 사용 불가능한 경우에도 웹 애플리케이션이 최종 사용자 요청을 받을 수 있습니다.

솔루션은 시간이 지남에 따라 변화하며 그에 따라 성능도 변할 수 있습니다. 개발, 테스트 및 운영 팀이 애플리케이션의 성능 지표를 비침투 방식으로 수집할 수 있도록 성능 계측을 내장하면 근거 기반 방법을 활용하는 견고한 제품을 개발하고 테스트하는 데 도움이 됩니다. 이러한 계측은 기능 테스트와 결함 분석에도 도움이 되며 솔루션의 성능을 유지하고 프로덕션 환경에서 성능 문제의 원인을 정확히 찾아내는 데 중요한 역할을 합니다. 구성 가능하고 비침투적인 계측은 제품 모니터링을 지원하여 운영 환경에서 솔루션의 관측 가능성을 보장하고 DevOps 및 SRE 팀을 지원합니다.

비즈니스 관점에서 보면 솔루션 전체의 성능이 중요하며 이는 포괄적인 비기능 요구 사항에 반영되어야 합니다. 그러나 단위 수준 성능 테스트, 시프트 레프트 패러다임을 적용한 초기 성능 테스트 및 성능 문제의 근본 원인 분석을 위해서는 개별 호출의 지속 시간이나 네트워크 지연과 같은 저수준 요구 사항을 지정해야 할 수 있습니다.

따라서 높은 수준의 성능 요구 사항은 일반적으로 프로세스 또는 트랜잭션 수준에서 정의됩니다. 예를 들어 “대출 생성 프로세스는 2분 이내에 완료되어야 한다”와 같이 정의되며 개별 프로세스 단계나 하위 프로세스의 성능이 최종 결과에 어떻게 기여하는지는 고려하지 않습니다. 개발 단계에서 프로세스 내 각 단계에 목표를 할당하는 성능 예산을 수립하면 기능 개발 팀에 측정 가능한 목표를 제공하고 잠재적인 문제 영역을 식별하며 성능 최적화와 개선 노력을 가장 효과적인 영역에 집중할 수 있도록 도와줍니다.

성능 예산은 하드웨어부터 애플리케이션 코드까지 솔루션의 모든 계층을 고려해야 합니다. 이 중 어느 하나라도 제외하면 솔루션이 사용자 기대치를 충족하지 못할 위험이 있습니다.

성능을 테스트할 때는 결과로 증명해야 하며 즉 엔드투엔드 솔루션을 테스트해야만 요구 사항을 충족하는지 확인할 수 있습니다. 이는 성능 분석의 전체적인 특성을 반영합니다. 개별 구성 요소(예: 데이터베이스, 미들웨어 등)를 테스트하면 솔루션 성능 분석에 유용한 통찰을 제공하고 성능 병목 지점을 파악하는 데 도움이 됩니다. 그러나 구성 요소 테스트만으로는 충분하지 않으며 구성 요소 간 상호 작용으로 인해 예상치 못한 병목 현상이나 다른 장애 요인이 발생하여 최적이 아닌 결과가 나타날 수 있습니다.

사용자 인식에 집중한다는 것은 주로 체감 응답 시간과 사용자 인터페이스의 전반적인 반응성에 초점을 맞춘다는 의미입니다. 용량 저하는 일반적으로 제품 성능에 영향을 미치기 전까지 사용자에게 보이지 않습니다. 1968년 연구에 따르면 인간과 컴퓨터의 상호작용에는 세 가지 뚜렷한 시간 규모가 존재합니다.

• 응답 시간이 100ms이면 즉각적인 반응으로 인식됩니다. 인간의 평균 반응 시간은 250ms이므로 그보다 짧은 응답 시간은 매우 빠르거나 즉각적인 반응으로 인식됩니다.
• 응답 시간이 1초 이하이면 일반적으로 사용자가 시스템 성능 때문에 작업 속도가 느려졌다고 느끼지 않을 만큼 충분히 빠른 것으로 인식됩니다.
• 응답 시간이 10초를 초과하면 사용자는 완전히 집중력을 잃게 됩니다.

이 연구에서는 2초의 응답 시간이 이상적이라고 제안했으며 가능하다면 하이브리드 클라우드 솔루션에서 2초 또는 약간 더 긴 정도의 응답 시간을 목표로 하는 것이 바람직합니다. 물론 사용자 기대치는 수행 중인 작업에 따라 달라집니다. 예를 들어 버튼 클릭 애니메이션이 2초 동안 지속될 것이라고 기대하는 사람은 없지만 사용자 대상 애플리케이션에서는 일반적으로 2~3초 정도가 적절한 응답 시간 목표가 됩니다.

이 원칙을 확장하여 솔루션은 사용자 인터페이스 테스트 툴을 사용해 사용자 응답 시간 테스트를 품질 보증 사이클의 일부로 포함해야 합니다. 전체 제품 성능에서 API 호출 지연 시간도 중요하지만 사용자가 체감하는 성능이 사용자 기반을 확보하고 유지하는 핵심 요소입니다.

사용자는 무엇이 "좋은" 성능을 의미하는지에 대해 서로 다른 기대치를 가지고 있는 경우가 많습니다. 예를 들어 하루에 여러 번 애플리케이션을 사용하는 ‘파워 사용자’는 같은 애플리케이션을 한 달에 한 번 정도 사용하는 사용자와 매우 다른 성능 기대치를 가지고 있습니다. 사용자는 ‘좋은’ 성능이 무엇을 의미하는지 정량적으로 정의하는 데 어려움을 겪는 경우가 많으며, 종종 "충분히 빠름"과 같은 요구 사항에 머무르게 됩니다(이는 충족하기 어려운 목표입니다). 또한 사용자에게 노출되는 제품 성능에 대한 개인의 인식은 사람마다 다릅니다. 예를 들어 일부 사용자에게는 로그인 시간이 10초인 것이 허용될 수 있습니다(특히 이것이 단발성 이벤트인 경우). 그러나 다른 사용자에게는 지나치게 느리게 느껴질 수 있습니다(특히 로그인이 워크플로의 빈번한 부분인 경우).

사용자 기대치를 정량화하고 관리하기 위해 다음을 권장합니다.

•  사용자 기반과 일반적인 애플리케이션 사용 패턴을 충분히 이해한 상태에서 비기능 요구 사항을 정의하세요.
  
  
• 솔루션 설계 초기 단계에서 사용자와 소통하여 어떤 기능을 자주 사용하며 빠른 응답성을 기대하는지, 그리고 어떤 기능은 사용 빈도가 낮아 더 느린 응답 시간도 허용할 수 있는지 파악하세요.
  
  
• 평균 또는 중앙값 응답 시간 기준을 정의할 때 백분위수를 사용하세요. 이 방법을 사용하면 제품 응답성의 불가피한 무작위 변동을 허용하면서도 소수의 이상치 때문에 전체 제품 승인에 실패하는 상황을 방지할 수 있습니다.
  
  
•  초기 솔루션 릴리스와 프리뷰 단계에서 현실적인 응답 시간 테스트와 피드백을 포함하세요. 성능 테스트를 솔루션 개발의 마지막 단계로 미루면 솔루션 아키텍처의 상당 부분을 되돌리지 않고서는 성능 문제를 해결할 수 없는 상황이 발생할 수 있습니다. 개발 주기 후반에 성능 문제를 해결하는 것은 비용이 많이 듭니다.
  
  
• UI 설계에 스피너와 상태 표시줄과 같은 요소를 포함하여 애플리케이션이 정상적으로 작동하고 처리 중임을 사용자가 인지할 수 있도록 하세요. 이를 통해 제품이 느리게 작동한다고 느껴질 때 발생하는 불필요한 사용자 불만을 줄일 수 있습니다.
  
  
• 필요한 경우 유사한 ‘최고 수준’ 솔루션을 조사하고 업계 동향과 관련 자료를 분석하며 주제 전문가와 인터뷰를 진행하여 적절한 응답 시간 및 용량 목표를 수립하세요.

고객에게 성능 한계를 모니터링하고 전달하세요.

제품 또는 솔루션 구성 요소의 오용이나 잘못된 구성은 성능 저하와 부정적인 사용자 경험의 원인이 될 수 있습니다. 이러한 상황을 방지하기 위해 아키텍트는 다음을 수행해야 합니다.

• 솔루션 내의 성능 제약을 인지하고 이를 사용자에게 사전에 적극적으로 전달하세요. 예를 들어 솔루션이 느리거나 낮은 대역폭의 통신 채널을 사용하는 경우 고해상도 이미지를 다운로드할 때 성능 저하가 발생할 수 있음을 최종 사용자에게 알리세요.

• 가능한 경우 요청이 솔루션 설계 범위를 벗어났을 때 이를 감지하고 사용자에게 알릴 수 있도록 시스템을 구성하세요. 예를 들어 느린 채널에서 대용량 파일을 다운로드하려 할 때 시스템이 사용자에게 경고하도록 할 수 있습니다.

성능 테스트의 일반적인 접근 방식은 솔루션이 예상되는 최대 부하에서 응답 시간 목표를 충족하는지 테스트하는 것입니다. 최대 예상 부하에서 성능이 좋다면 그보다 낮은 부하에서도 잘 작동할 것이라는 가정에 기반합니다. 이 접근 방식의 문제는 테스트된 최대 부하마다 하나의 데이터 포인트만 제공한다는 점이며 이는 마치 통과 또는 실패 시험과 같은 방식입니다.

잘 설계된 솔루션은 다양한 부하 크기, 사용자 유형 조합, 테스트 기능 조합을 포함한 여러 부하 범위에서 탐색적 접근 방식을 사용해 응답성을 테스트합니다. 이 방법은 솔루션 구성 요소 간 상호 작용이 성능에 어떤 영향을 미치는지, 잠재적 병목 지점이 어디인지, 그리고 더 적거나 더 많은 워크로드를 처리하기 위해 솔루션을 어떻게 확장해야 하는지에 대한 다각적인 정보를 솔루션 팀에 제공합니다.

이 접근 방식은 예상 부하 목표가 변경되어 다른 부하 조건에서 성능 지표를 수집해야 할 때 추가 테스트를 수행하는 것을 피할 수 있게 해줍니다. 부하 규모에 따른 기존 성능 의존성을 보간 또는 외삽하면 초기 테스트된 부하 범위(0부터 브레이크포인트 수준 및 그 이상)에 포함된 모든 부하에 대한 성능 지표를 계산할 수 있습니다.

일반적인 성능 테스트 접근 방식은 “주어진 부하 또는 처리량에서 응답 시간을 측정한다”는 단순화된 패턴을 따릅니다. 이 접근 방식은 최대 부하에서 핵심 트랜잭션의 응답 시간이 기존 서비스 수준 계약(SLA)을 충족하는지 여부를 확인하는 데 도움이 됩니다. 또한 일반적으로 테스트되는 부하 수준은 “낮음”, “피크”, “스트레스”로 제한됩니다. 이 접근 방식은 일반적인 부하에서의 응답 시간에 대한 질문에는 답할 수 있지만 모든 운영 상황에서 시스템 성능의 전체적인 모습을 제공하지는 않습니다.

더 고급 방식인 *탐색적 성능 테스트* 접근 방식은 테스트 대상 솔루션의 *성능 스냅샷* 생성을 목표로 합니다. 이 스냅샷에는 단일 사용자 측정부터 브레이크포인트 이후 부하(시스템이 중단되지 않는 경우 가능한 범위까지)에 이르기까지 지원되는 가장 넓은 부하 범위에서 수집된 종합적인 성능 지표 세트가 포함됩니다. 여기에는 증가하는 부하 조건에서 수집된 트랜잭션 응답 시간, 트랜잭션 및 데이터 처리량, 그리고 리소스 소비 데이터가 포함됩니다. 여기에서 "트랜잭션"은 시스템이 수행하는 유한한 작업 단위를 의미하며 로그인이나 계정 업데이트와 같은 매크로 트랜잭션부터 로그인 트랜잭션 내의 인증 호출과 같은 개별 하위 트랜잭션, 또는 단순한 http 요청까지를 포함합니다.

이 종합적인 성능 데이터 세트인 성능 스냅샷에는 낮은 부하의 “선형” 구간(개별 처리 스레드가 서로의 존재에 영향을 받지 않아 부하 증가에도 응답 시간이 증가하지 않는 구간), 부하 증가에 따라 응답 시간이 증가하는 “비선형” 구간, 부하 증가에도 처리량이 더 이상 증가하지 않고 포화 상태에 도달하는 포화 지점, 그리고 처리량이 최대에 도달한 이후 성능이 저하되고 응답 시간이 SLA 수준을 초과하는 브레이크포인트 이후 구간의 성능 지표가 포함됩니다.

전체 부하 범위를 테스트하는 것은 일반적으로 “피크” 및 “스트레스” 수준 테스트와 내구성 테스트만 수행하는 것보다 더 많은 노력이 필요하지 않습니다. 동일한 테스트 스크립트를 사용하기 때문이며 실제로 가장 큰 노력은 이러한 스크립트를 만드는 데 들어가기 때문입니다. 이와 같은 성능 스냅샷을 생성하면 다음과 같은 장점이 있습니다.

• ‘적절한’ 트랜잭션 처리량(“피크” 또는 “스트레스”)을 생성하는 올바른 테스트 구성을 추측하는 데 시간과 노력을 들일 필요가 없습니다. 부하를 점진적으로 증가시키면서 지원되는 *모든* 부하 수준과 처리량을 테스트하면 됩니다.

• 응답 시간이 어느 부하 수준에서 증가하기 시작하는지, SLA 수준을 초과하는 시점이 어디인지, 그리고 처리량이 최대 수준에 도달하는 지점을 확인할 수 있습니다.

• 이를 통해 시스템 용량을 직접 측정할 수 있습니다. 예를 들어 브레이크포인트 조건이 발생하는 부하 수준(응답 시간이 SLA를 초과하거나, 처리량이 최대 수준에 도달하거나, 시스템 리소스 사용량이 지정된 “레드 존”에 들어가는 경우, 예: CPU 사용률이 90%에 도달하거나 시스템이 중단되는 경우 등 먼저 발생하는 조건)을 확인할 수 있습니다. 이는 용량 분석 및 계획에서 일반적으로 사용되는 추측 기반 접근 방식을 사용할 필요가 없음을 의미합니다.

• 프로덕션 운영의 예상 조건이 변경되는 경우(예: 비즈니스에서 평균 또는 피크 부하를 재정의하는 경우) 성능 테스트를 다시 실행할 필요가 없습니다. 기존 테스트 결과를 보간 또는 외삽하여 다양한 부하 수준에 대한 성능 지표를 계산할 수 있습니다.

• 몇 가지 사전 정의된 부하 수준만 테스트하는 대신 전체 부하 범위를 테스트하면 시스템 성능을 전체적으로 파악할 수 있으며 극단적인 조건에서 테스트하지 않아 발생할 수 있는 성능 문제를 놓치지 않을 수 있습니다.

• 테스트에 시스템 성능 한계 지점을 실제로 도달하는 단계가 포함되도록 하면 성능 병목이 어디에 있는지, 부하가 증가할 때 어떤 링크, 구성 요소 또는 계층이 가장 먼저 실패하는지 파악할 수 있습니다. 이를 통해 제품의 안정성과 성능을 개선할 수 있도록 아키텍처 및 설계 팀에 근거 기반의 유용한 피드백을 제공할 수 있습니다.

솔루션에 대해 수행할 수 있는 여러 유형의 성능 테스트가 있습니다. 잘 설계된 솔루션은 이러한 모든 테스트를 활용합니다.

• 수동 벤치마킹은 이름 그대로 솔루션 기능을 직접 실행하여 사용자 관점에서 솔루션이 어떻게 반응하는지 직접 확인하는 테스트입니다.
• 보정 테스트는 자동 테스트 툴의 결과를 수동 테스트나 내장된 성능 지표와 비교하여 테스트 스크립트와 테스트 툴 결과의 정확성을 검증하기 위해 수행됩니다.
• 소크 테스트, 또는 지속성 테스트는 솔루션을 장시간 부하 상태에서 테스트하여 솔루션이 부하 상황에서도 안정적으로 유지되고 시간이 지나도 성능이 저하되지 않으며, 안정적으로 운영될 수 있고 예상된 리소스 소비를 보이는지(즉, 메모리 누수가 없는지) 확인하는 테스트입니다.
• 피크 테스트는 예상되는 최대 워크로드(예: 연중 가장 바쁜 날)에서 솔루션을 테스트하여 솔루션의 안정성을 확인하고 최대 예상 부하에서의 응답 시간과 리소스 소비와 같은 핵심 지표를 수집합니다.
• 스트레스 테스트와 스파이크 테스트는 예상 피크 부하의 몇 배(예: 2배 또는 3배) 수준의 부하를 짧은 시간 동안 적용하거나(스트레스 테스트), 매우 짧은 시간 동안 훨씬 높은 부하를 적용하여(스파이크 테스트) 솔루션을 테스트합니다. 이러한 테스트는 솔루션 내 병목 지점을 식별하고 솔루션의 확장 의존성을 파악하는 데 도움이 됩니다.
• 가변 부하 테스트 또는 브레이크포인트 테스트는 다양한 부하 범위에서 솔루션을 테스트하여 서로 다른 부하 수준에서의 성능을 이해하고 솔루션 내 성능 추세와 리소스 한계를 발견하는 데 사용됩니다. 이러한 테스트를 통해 제품의 브레이크포인트를 확인하고 솔루션 용량을 측정하며 가장 먼저 실패할 가능성이 높은 취약 구성 요소를 파악할 수 있습니다.

테스트에서 수집된 다양한 성능 데이터를 최대한 활용하세요.

• 창의적이고 탐색적인 방식으로 테스트 결과를 분석하세요. *What-if* 접근 방식을 사용하여 추가 시나리오를 탐색하세요.
• 성능 결과를 다양한 규모와 아키텍처의 환경에 매핑하여 서로 다른 플랫폼과 배포 환경에서의 솔루션 성능을 예측하세요.
• 예상치 못한 패턴과 추세(예: 부하가 *증가*했는데 트랜잭션 처리율이 *감소*하는 경우)를 감지하여 수집된 성능 데이터의 불일치를 찾아내세요.
• 모델링 기법을 사용하여 가정된 사용 패턴을 기반으로 측정된 시스템 용량을 사용자 기반 규모와 연결하세요.
• 프로덕션 환경에서 동시에 실행될 수 있는 서로 다른 워크플로 간의 성능 영향도 항상 평가하세요.
• 파일럿 프로젝트, 단위 및 기능 테스트, DevOps와 SRE의 골든 시그널까지 다양한 성능 데이터 출처를 활용하세요. 성능 분석에서는 어떤 데이터든 가치가 있습니다.
• 분석 결과를 이해관계자와 더 자주 공유하세요. 이렇게 하면 다른 사람들로부터 유용한 의견을 얻을 수 있고 성능 테스트와 분석 진행 상황에 대한 인식을 높일 수 있으며 성능 및 용량 분석과 같은 *기술적인* 영역에 대한 이해를 돕고 전체 비기능 검증 활동의 가시성을 높일 수 있습니다.