애플리케이션 성능 지수(Apdex) 점수는 사용자가 조직의 웹 애플리케이션 및 서비스의 응답 시간에 얼마나 만족하는지 측정하는 개방형 표준 정량적 메트릭입니다.
성능을 더 잘 이해하고, 문제를 감지하며, 해당 애플리케이션의 전반적인 상태를 개선할 방법을 파악하기 위해서는 IT 애플리케이션과 관련된 많은 성능 메트릭을 캡처하는 것이 좋습니다. 이러한 모든 메트릭은 전반적인 사용자 만족도 향상에 기여할 수 있습니다. 그러나 애플리케이션이 제대로 작동하는지 여부를 간단히 파악하기 위해 다양한 메트릭을 취합하는 것이 어려울 때도 있습니다. 이 경우 애플리케이션 응답 시간이 설정된 임계값보다 낮거나 높은지를 기준으로 고객 만족도를 파악하는 Apdex 점수를 사용할 수 있습니다.
Apdex 점수는 애플리케이션 성능 모니터링이라고도 하는 애플리케이션 성능 관리(APM)의 구성 요소로 자주 사용됩니다.
Apdex 결과는 0~1(0: 불만족, 1: 만족)의 일률적인 척도로 사용자 만족도를 수치로 나타낸 값입니다. 이는 평균 응답 시간 수치보다 로드 시간에 대한 사용자 만족도를 더 균형 있게 파악할 수 있도록 하기 위해 설계되었지만, 한 번의 느린 로드(예: 1분)으로 인해 왜곡될 수 있습니다. Apdex 점수는 하나의 총점을 집계하는 대신 각 응답 시간 인스턴스를 개별적으로 처리합니다.
NetForecast의 설립자인 Peter Sevcik은 애플리케이션 품질을 측정하기 위한 간단하고 통일된 오픈 표준의 가능성을 처음으로 제시했습니다1. 그는 업계 전문가 그룹을 이끌며 Apdex 기술 사양을 만들었습니다. 얼마 지나지 않아 Apdex Alliance는 현재 많은 조직에서 사용하는 Apdex 표준을 채택했습니다.
Apdex 점수를 유지하는 것은 많은 조직에서 거의 실시간에 가까운 핵심 성과 지표(KPI)입니다. 우수한 사용자 경험을 제공하는 것을 최종 목표로 하여 애플리케이션 응답 시간을 보고하고, 벤치마크하고, 점수를 매겨 사용자 만족도를 평가하는 프레임워크를 만듭니다.
Apdex 점수를 식별하는 것은 조직에서 허용 가능한 응답 시간을 나타내는 Apdex 임계값을 설정하는 것으로 시작됩니다. 일정한 임계값을 사용하면 시간 경과에 따른 변경 사항을 조직에서 더 쉽게 추적할 수 있습니다. 모든 조직에서 사용할 수 있는 보편적인 임계값은 없으므로 모든 조직은 자체 응답 시간 임계값을 파악해야 합니다.
조직은 일반적으로 다음과 같은 몇 가지 요소에 따라 자체 임계값을 결정합니다.
Apdex 공식은 설정된 임계값을 기반으로 애플리케이션 로드 시간을 결정하기 위한 비율 점수입니다. 각 사용자 경험은 사용자가 경험한 로드 시간을 기반으로 Apdex 점수에 기여합니다.
사용자 경험은 다음 세 가지 카테고리 중 하나로 분류됩니다.
그런 다음 만족스러운 응답 시간(만족 횟수)에 허용 가능한 응답 시간(허용 횟수)의 절반을 더한 후 총 샘플 수로 나누어 Apdex 점수를 결정합니다.
Apdex 점수는 0(만족하는 사용자가 없음)에서 1(모든 사용자가 만족)까지의 범위로 표현됩니다. Apdex 점수가 낮다는 것은 조직이 APM, 문제 관리 및 사이트 안정성 엔지니어링과 같은 관행을 통해 문제를 해결하고 성능을 최적화하는 능력을 개선해야 한다는 뜻일 수 있습니다.
낮은 Apdex 점수는 조직의 현재 IT 운영에 문제가 있다는 신호일 수 있습니다. 다음은 조직이 Apdex 점수를 개선할 방법에 대한 몇 가지 예와 사용 사례입니다.
코드 및 데이터베이스 쿼리 최적화: 데이터베이스를 제대로 구성하지 않고 비효율적인 코드를 사용하는 조직은 Apdex 점수가 낮을 수 있습니다. 예를 들어 표준 이하의 코드는 필요 이상으로 많은 CPU 및 메모리 리소스를 요구하여 로드 시간이 느려질 수 있습니다. 코드 및 데이터베이스 쿼리를 최적화하는 것이 Apdex 점수를 높이는 가장 좋은 방법입니다.
외부 요청 최소화: 타사 서비스에 API를 호출하면 웹 서비스에 상당한 부담을 주고 대기 시간이 길어질 수 있습니다. Apdex 점수가 낮은 조직은 외부 요청을 재검토하여 요청이 필요하고 가치가 있으며 대기 시간을 크게 늘리지 않는지 확인해야 합니다.
콘텐츠 전송 네트워크(CDN) 사용: CDN은 기업이 사용자에게 가장 가까운 서버를 통해 요청을 완료하여 사용자에게 콘텐츠를 더 빠르게 제공하기 위해 사용하는 지리적으로 분산된 서버 시스템입니다. 예를 들어, 독일에 있는 사용자가 뉴욕에서 호스팅되는 콘텐츠가 포함된 웹 페이지의 콘텐츠에 액세스하려는 경우 사용자의 요청은 뉴욕에 있는 서버가 아닌 유럽에 있는 회사의 엣지 서버에서 처리됩니다. 그 결과 데이터가 이동해야 하는 거리가 줄어들어 지연 시간이 줄어듭니다.
과중한 작업에는 비동기 처리 사용: 비동기 처리를 사용하면 상호 통신 환경의 시스템 간에 애플리케이션에 필요한 처리를 분산할 수 있습니다. 비동기 처리에서는 과중한 작업을 별도의 프로세스로 오프로드하여 메인 스레드가 사용자 요청을 처리할 수 있도록 리소스를 확보합니다.
트래픽 수요 증가에 맞춰 서버 확장: 서버 용량을 늘리거나 부하 분산 기능을 사용하지 않는 상태에서 트래픽이 크게 증가하면 응답 시간이 느려질 수 있습니다. IBM® Turbonomic®과 같이 실시간 수요를 기반으로 네트워크 리소스 할당을 사전 예방적으로 자동화하는 플랫폼을 사용하면 이 문제를 완화하는 데 도움이 될 수 있습니다.
Apdex 점수를 사용하여 성과를 추적하는 조직은 다음과 같은 여러 가지 이점을 얻을 수 있습니다.
웹 응답 시간 단축: Apdex 점수를 추적하면 애플리케이션 및 서비스 성능을 보다 정확하게 파악할 수 있습니다. 이 정보는 응답 시간을 단축하고 조직이 사용자에게 관련 콘텐츠를 더 빠르게 전달하는 데 도움이 됩니다.
사용자 만족도 향상: Apdex 점수에 중점을 두는 조직은 사용자 경험을 더 잘 인식하고 이를 충족할 가능성이 높습니다. Apdex 점수를 지속적으로 모니터링하고 개선하면 불만을 느끼는 사용자가 줄어들고 고객 만족도가 높아져 고객이 조직의 든든한 옹호자가 될 수 있습니다.
서비스 수준 계약 (SLA) 준수: 조직의 SLA는 애플리케이션을 로드하는 데 걸리는 시간을 지정할 수 있습니다. 로드 시간이 SLA에 명시된 것보다 긴 상황이 지속되면 조직이 사용자와의 계약을 위반하고 있는 것일 수 있습니다.
데이터 기반 의사 결정: Apdex 점수를 추적하면 비즈니스 리더가 웹 애플리케이션 성능에 관한 의사 결정을 내리는 데 도움이 되는 신뢰할 수 있는 데이터를 얻을 수 있습니다. 정확도가 떨어지는 메트릭이나 일화에 의존하는 것보다 더 체계적인 고객 만족도 추적 시스템을 구축할 수 있습니다.
IBM Instana Observability로 전체 애플리케이션 스택을 자동으로 관찰, 모니터링 및 수정하세요.
맞춤형 애플리케이션의 포트폴리오 전반에 걸쳐 최고의 성능과 높은 사용자 만족도를 제공하세요.
풀스택 관측 가능성을 자동화된 애플리케이션 자원 관리와 연결하여 성능 문제가 고객 경험에 영향을 미치기 전에 해결하세요.
1 The History of Apdex, Apdex.org