퍼포먼스 엔지니어링

Performance engineering


퍼포먼스 엔지니어링에는 퍼포먼스에 관한 비기능 요건(스루풋, 레이텐시, 메모리 사용량 등)을 충족하기 위해 시스템 개발 라이프 사이클 중에 적용되는 기술이 포함됩니다.시스템 엔지니어링 내에서는 시스템 퍼포먼스 엔지니어링, 소프트웨어 엔지니어링 내에서는 소프트웨어 퍼포먼스 엔지니어링 또는 애플리케이션 퍼포먼스 엔지니어링이라고도 불립니다.

애플리케이션 성공과 비즈니스 성공 사이의 연관성이 특히 모바일 공간에서 계속 인식됨에 따라 애플리케이션 성능 엔지니어링은 소프트웨어 개발 라이프 사이클 내에서 예방적이고 완벽한[1] 역할을 수행하게 되었습니다.따라서 이 용어는 일반적으로 도입 전에 비기능 요건을 효과적으로 테스트하고 서비스 수준을 준수하며 애플리케이션 성능을 최적화하기 위해 필요한 프로세스, 인력 및 기술을 설명하기 위해 사용됩니다.

퍼포먼스 엔지니어링이라는 용어는 소프트웨어와 지원 인프라스트럭처뿐만 아니라 매크로 관점에서 퍼포먼스 엔지니어링이라는 용어를 사용하는 것이 좋습니다.비기능 요건에 대한 준거도 실가동 시스템을 감시함으로써 도입 후 검증됩니다.이는 IT 서비스 관리의 일부입니다(ITIL도 참조).

퍼포먼스 엔지니어링은 많은 대기업에서 독립된 분야가 되어 시스템 엔지니어링과 병행하여 업무를 수행하고 있습니다.이는 여러 조직 단위에서 온 사람들이 참여하지만, 주로 IT 조직 내에서 발생합니다.

퍼포먼스 엔지니어링 목표

  • 시스템이 필요한 기간 내에 트랜잭션을 처리할 수 있도록 함으로써 비즈니스 수익 증대
  • 퍼포먼스 목표 장애로 인해 시스템 개발 작업을 폐기 및 탕감해야 하는 시스템 장애 배제
  • 퍼포먼스 문제로 인한 시스템 도입 지연 배제
  • 성능 문제로 인한 피할 수 있는 시스템 재작업 배제
  • 피할 수 있는 시스템 조정 작업 불필요
  • 불필요한 하드웨어 추가 구입 비용 회피
  • 생산 시 성능 문제로 인한 소프트웨어 유지보수 비용 절감
  • 애드혹 퍼포먼스 수정의 영향을 받는 소프트웨어로 인한 소프트웨어 유지보수 비용 절감
  • 성능 문제로 인한 시스템 문제 처리에 대한 추가 운영 오버헤드 감소
  • 프로토타입에 대한 시뮬레이션을 통해 향후 병목 현상 파악
  • 서버 기능 향상

퍼포먼스 엔지니어링 어프로치

이 원칙은 여러 방법론에서 적용되기 때문에 다음과 같은 활동이 서로 다르게 지정된 단계에서 발생합니다.단, Rational Unified Process(RUP; 합리적 통합 프로세스) 단계를 프레임워크로 사용하는 경우 다음과 같은 작업이 수행됩니다.

프로그램 또는 프로젝트의 첫 번째 개념 단계에서는 중요한 비즈니스 프로세스가 식별됩니다.일반적으로 매출액, 비용 절감액 또는 기타 할당된 비즈니스 가치에 따라 중요한 것으로 분류됩니다.이 분류는 IT 조직이 아닌 사업부에 의해 이루어집니다.현시점에서는 시스템 퍼포먼스에 영향을 줄 가능성이 있는 높은 수준의 리스크가 특정되어 설명됩니다.예를 들어 특정 벤더 시스템의 알려진 성능 위험을 들 수 있습니다.마지막으로, 퍼포먼스 액티비티, 역할, 성과물이 Elvolation 단계에서 특정됩니다.액티비티와 자원 로딩은 Elvolation 단계 프로젝트 계획에 포함됩니다.

정교

이 정의 단계에서 중요한 비즈니스 프로세스는 중요한 사용 사례로 분해됩니다.프로브 케이스는 필요에 따라 한 페이지(화면) 전환으로 더욱 분해됩니다.이러한 사용 사례는 스크립트 기반 성능 테스트의 대상이 됩니다.

퍼포먼스 엔지니어링과 관련된 요건의 유형은 비기능적 요건(NFR)입니다.기능요건은 어떤 비즈니스 운영을 수행해야 하는지에 관한 반면, 성과와 관련된 비기능요건은 정의된 상황에서 해당 비즈니스 운영이 얼마나 빨리 수행되는지와 관련이 있습니다.

건설

이 단계에서는 퍼포먼스 툴 관련 액티비티가 다수 필요합니다.여기에는 다음이 포함됩니다.

  • 선택한 툴의 주요 개발 팀원을 대상 분야의 전문가로 특정합니다.
  • 개발/컴포넌트 유닛 테스트 환경의 프로파일링 도구를 지정합니다.
  • 개발/컴포넌트 유닛 테스트 환경의 자동 유닛(컴포넌트) 성능 테스트 도구를 지정합니다.이 도구는 개발 중인 컴포넌트를 구동하기 위한 GUI가 아직 존재하지 않을 때 사용합니다.
  • 개발/컴포넌트 유닛 테스트 환경의 서버측 유닛(컴포넌트)을 구동하기 위한 자동화 툴을 지정합니다.
  • 개발/컴포넌트 유닛 테스트 환경에 대해 자동화된 다중 사용자 지원 스크립트 기반 엔드 투 엔드 도구를 지정합니다.이 도구는 화면 기반 사용 사례를 실행하기 위해 사용됩니다.
  • 개발/컴포넌트 유닛 테스트 환경의 데이터베이스 테스트 데이터 로드 도구를 특정합니다.이 도구는 데이터베이스 옵티마이저가 올바른 실행 경로를 선택하고 필요에 따라 데이터베이스를 재초기화하고 새로고침할 수 있도록 하기 위해 필요합니다.
  • 개발팀의 퍼포먼스 툴을 도입합니다.
  • 선택한 도구에 대한 프레젠테이션과 교육을 개발 팀원에게 제공해야 합니다.

퍼포먼스 테스트 팀은 통상 개발 환경에서 퍼포먼스 테스트를 실행하는 것이 아니라 계획한 실가동 환경에 최대한 근접하도록 구성된 특수한 도입 전 환경에서 퍼포먼스 테스트를 실시합니다.이 팀은 테스트 케이스에 대한 퍼포먼스 테스트를 실행하여 중요한 사용 사례가 지정된 비기능 요건을 충족하는지 검증합니다.팀은 정상 예상(중간) 부하와 피크 부하에 대한 부하 테스트를 수행합니다.이들은 종종 시스템의 병목현상을 식별하는 스트레스 테스트를 수행합니다.수집된 데이터와 분석은 성능 조정을 수행하는 그룹에 피드백됩니다.필요한 경우, 시스템은 부적합 시험이 비기능 요건을 준수하도록 조정된다.

이 시점까지 프로젝트의 각 반복 단계와 단계에서 퍼포먼스 엔지니어링이 적절히 적용되어 있으면 시스템이 퍼포먼스 인증을 취득하기에 충분합니다.그러나 어떤 이유로(아마도 적절한 성능 엔지니어링 작업 관행이 적용되지 않았을 수 있음) 컴플라이언스에 맞춰 조정할 수 없는 테스트가 있는 경우 리팩터링을 위해 시스템의 일부를 개발로 되돌려야 합니다.경우에 따라서는 하드웨어 증설로 문제를 해결할 수 있지만 하드웨어를 추가하면 수익률이 빠르게 낮아집니다.

전이

이 최종 단계에서는 시스템이 실제 가동 환경에 도입됩니다.몇 가지 준비 단계가 필요합니다.여기에는 다음이 포함됩니다.

  • 기본 체크리스트와 퍼포먼스 테스트 환경에서 특정된 최적화에 따라 운영체제, 네트워크, 서버(애플리케이션, 웹, 데이터베이스, 로드밸런서 등) 및 메시지 큐잉 소프트웨어 구성
  • 모든 퍼포먼스 감시 소프트웨어 도입 및 구성 확인
  • 프로덕션 데이터 로드가 완료된 후 데이터베이스에 대한 통계 실행

새로운 시스템이 도입되면, 계속적인 운용에 의해서, 다음과 같은 퍼포먼스 액티비티가 생깁니다.

  • 주별 및 월별 성능 보고서를 검증하면 중요한 사용 사례가 지정된 비기능적 요건 기준 내에서 수행됨을 알 수 있습니다.
  • 사용 사례가 NFR 기준을 벗어나는 경우 결함 제출
  • 월별 및 분기별 보고서에서 예상되는 추세를 파악하고 분기별로 용량 계획 관리 활동을 수행합니다.

서비스 관리

운용 도메인(실가동 후 도입)에서 퍼포먼스 엔지니어링은 주로 서비스레벨 관리, 용량 관리, 문제 관리의 3가지 영역에 초점을 맞춥니다.

서비스 수준 관리

서비스 레벨 관리 영역에서는 퍼포먼스엔지니어링이 서비스레벨 어그리먼트 및 관련 시스템모니터링과 관련되어 서비스레벨 컴플라이언스 검증, 문제 검출 및 트렌드 특정에 도움이 됩니다.예를 들어 실제 사용자 감시를 도입하면 지정된 비기능 요건에 따라 사용자 트랜잭션이 실행되고 있는지 확인할 수 있습니다.트랜잭션 응답 시간은 데이터에 대해 쿼리 및 보고서를 실행할 수 있도록 데이터베이스에 기록됩니다.이를 통해 용량 관리에 유용한 추세 분석이 가능합니다.사용자 트랜잭션이 아웃오브밴드(out of band)가 되면 이벤트가 경보를 생성하여 상황에 주의를 기울여야 합니다.

용량 관리

용량 관리를 위해 퍼포먼스 엔지니어링은 시스템이 퍼포먼스에 준거한 상태로 유지되도록 하는 데 중점을 둡니다.즉, 과거 모니터링에서 생성된 데이터에 대한 추세 분석을 실행하여 향후 비준수 시간을 예측할 수 있습니다.예를 들어, 시스템이 트랜잭션 처리 속도를 늦추는 경향을 보이고 있는 경우(데이터 세트 크기 증가, 동시 사용자 수 증가 또는 기타 요인 때문일 수 있음), 어느 시점에서는 시스템이 서비스 수준 계약에서 지정된 기준을 충족하지 못합니다.용량 관리는 트렌드 라인이 리셋되고 시스템이 지정된 성능 범위 내에서 유지되도록 추가 용량(CPU 추가, 메모리 추가, 데이터베이스 색인화 등)을 미리 추가해야 합니다.

문제 관리

문제 관리 영역 내에서 성능 엔지니어링 업무는 성능 관련 문제의 근본 원인을 해결하는 데 초점이 맞춰져 있습니다.여기에는 일반적으로 시스템 튜닝, 운영체제 또는 디바이스 파라미터 변경, 애플리케이션 소프트웨어 리팩터링이 포함됩니다.설계 불량이나 코딩 불량으로 인한 퍼포먼스 저하를 해결하기 위해서입니다.

감시

시스템이 NFR에서 지정된 퍼포먼스 메트릭을 충족하는지 여부를 검증하는 적절한 피드백이 있는지 확인하기 위해 모든 주요 시스템에는 모니터링 서브시스템이 필요합니다.모니터링 서브시스템의 계획, 설계, 설치, 구성 및 제어는 적절하게 정의된 모니터링 프로세스에 의해 지정됩니다.이점은 다음과 같습니다.

  • 유스케이스 레벨에서 서비스 레벨 어그리먼트를 확립할 수 있습니다.
  • 정기적인 시점에서 모니터링을 켜고 끌 수도 있고 문제 해결을 지원할 수도 있습니다.
  • 정기적인 보고서를 생성할 수 있습니다.
  • 사용자 로드의 증가와 데이터 세트의 증가가 사용 사례 수준의 성능에 미치는 영향 등 시간에 따른 추세를 추적할 수 있습니다.

이 추세 분석 구성요소는 저평가될 수 없습니다.이 기능을 적절하게 구현하면 특정 애플리케이션에서 사용자 부하가 점차 증가하고 데이터 세트가 증가하는 시기를 예측할 수 있으며, 특정 사용 사례에 대해 지정된 비기능 성능 요구 사항을 초과할 수 있습니다.이를 통해 시스템을 기능하지 않는 퍼포먼스 요건의 파라미터 내에서 가동시키기 위해 필요한 자원의 적절한 관리 예산 책정, 취득 및 도입을 할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "아웃소싱 테스트 서비스에서 얻은 은행 산업의 교훈" Gartner.2012년 8월 2일

추가 정보