IT 팀이 앱 모니터링에 사용하는 APM 메트릭 8가지

우수한 고객 경험(CX)은 정확하고 시기적절한 애플리케이션 성능 모니터링(APM) 지표를 기반으로 구축됩니다. CX를 개선하기 위해 앱이나 시스템을 미세 조정하려면 먼저 문제가 무엇인지 또는 기회가 어디에 있는지 알아야 합니다.

APM 솔루션은 일반적으로 분석 및 비교할 수 있는 실시간 성능 지표와 인사이트를 집계하는 중앙 집중식 대시보드를 제공합니다. 또한 실제 또는 잠재적 성능 문제를 나타내는 편차를 시스템 관리자에게 경고하는 기준선을 설정합니다. 그러면 IT 팀, DevOps 및 사이트 안정성 엔지니어가 애플리케이션 문제를 신속하게 식별하고 해결할 수 있습니다.

애플리케이션 성능 모니터링은 애플리케이션 성능 관리의 초기 단계입니다. 모니터링은 앱의 성능을 추적하고 해당 앱을 관리할 수 있도록 해줍니다. APM 솔루션은 관리자에게 데이터를 신속하게 수집하고 근본 원인 분석을 수행하는 데 필요한 계측 도구를 제공합니다. 그런 다음 해당 문제를 격리하고 해결합니다.

선택할 수 있는 지표는 여러 가지가 있지만, IT 조직 내에서 최대한의 이점을 얻으려면 이 8가지 지표에 집중하는 것이 좋습니다.

1. Apdex 및 SLA 점수

애플리케이션 성능 지수(Apdex)와 서비스 수준 계약(SLA) 점수는 우수한 고객 경험의 기반이 되는 점수부터 살펴보겠습니다. 측정할 속도와 피드는 빠른 성능을 위해 합산되어야 하는 구체적인 측면이지만, 이는 수단이지 목적이 아닙니다. 고객 만족이 곧 매출 증대로 이어지는 목표입니다.

Apdex 및 SLA 점수는 최종 사용자 경험 모니터링을 보는 가장 인기 있는 방법입니다. Apdex 점수는 웹 요청 또는 트랜잭션이 정상적으로 소요되는 시간에 대한 목표를 지정하여 앱의 성능을 추적합니다. SLA는 고객 계약의 지표이며 정의된 SLA보다 낮으면 CX가 떨어질 위험이 있습니다(그리고 미리 정의된 페널티가 발생할 수 있음).

2. 애플리케이션 가용성(가동 시간 또는 웹 성능 모니터링이라고도 함)

가장 기본적인 지표는 '불이 켜져 있는가?'입니다. 애플리케이션이 온라인 상태이고 사용 가능한지 모니터링하고 측정하고 있습니다. 대부분의 기업은 이를 사용하여 서비스 수준 계약(SLA) 규정 준수를 측정합니다. 가동 시간은 전반적인 시스템 안정성과 상황을 평가하기 위한 줄임말인 경우가 많습니다. 과도한 다운타임은 온라인 서비스를 제공하는 조직의 사용자 만족도에 부정적인 영향을 미칠 수 있습니다. 웹 애플리케이션의 경우 정기적으로 예약된 간단한 HTTP 확인을 통해 가용성을 확인할 수 있습니다.

3. CPU 사용량(리소스 사용량이라고도 함)

애플리케이션이 CPU 용량의 높은 비율을 사용한다는 것은 성능 문제의 신호일 수 있습니다. CPU 사용량이 갑자기 급증하면 응답 시간이 느려질 수 있습니다. 앱에 대한 수요 변동은 애플리케이션 인스턴스를 더 추가해야 한다는 신호일 수도 있습니다. 일반적인 규칙은 CPU 사용량이 30% 이상의 시간 동안 70%를 초과하면 CPU 용량이 부족할 수 있다는 것입니다.

리소스 사용량에는 메모리와 디스크 사용량도 포함될 수 있습니다. RAM을 추적하면 장애 또는 더 큰 메모리의 필요성으로 이어질 수 있는 메모리 누수를 식별하는 데 도움이 됩니다. 디스크 사용량 지표는 앱이 실패할 수 있는 영구 스토리지가 부족하여 앱을 실행하는 것을 방지하는 데 도움이 될 수 있습니다. 높은 디스크 사용량은 비효율적인 백엔드 데이터 스토리지 또는 잘못된 데이터 보존 정책의 신호일 수도 있습니다.

4. 오류율

APM 지표 소프트웨어는 애플리케이션을 모니터링하여 실패로 이어지는 요청의 비율을 기록해야 합니다. 이를 통해 사용자 경험에 영향을 미치는 문제를 식별하고 해결 우선순위를 정할 수 있습니다. 애플리케이션 오류에는 서버 오류, 404 응답 또는 웹 앱의 시간 초과가 포함될 수 있습니다. 오류율이 설정된 매개변수를 초과하면 알림을 보내도록 APM 솔루션을 구성할 수 있습니다. 예를 들어 이전 25개 요청 중 2.5%가 오류로 발생했을 때 경고를 보냅니다.

5. 가비지 컬렉션

가비지 컬렉션(GC)은 Java 또는 기타 언어의 지속적인 메모리 사용량을 파악하고 제거하여 성능을 향상시킬 수 있습니다. 좋은 소식은 GC 자동화가 애플리케이션에서 더 이상 사용되지 않는 사용되지 않거나 중복된 객체 또는 데이터에 전념하는 메모리를 회수한다는 것입니다. 사용하지 않는 개체나 데이터는 삭제되고 라이브 개체는 차세대 메모리 풀에 복사됩니다. 이는 만족스러운 중간 상태를 유지하려는 지표입니다. GC를 너무 자주 실행하면 오버헤드가 너무 많이 발생할 수 있고, GC를 충분히 자주 실행하지 않으면 시스템에 메모리가 너무 적게 남을 수 있습니다.

6. 인스턴스 수

인스턴스 추적을 사용하면 언제든지 실행 중인 앱 또는 서버 인스턴스 수에 따라 실제 사용자 수요에 맞게 애플리케이션을 확장할 수 있습니다. 이는 클라우드 애플리케이션에서 특히 중요할 수 있습니다. 자동 스케일링을 사용하면 최신 애플리케이션 확장을 통해 수요를 충족하고 사용량이 적은 시간대에 예산을 절약할 수 있습니다. 이로 인해 인프라 모니터링에 어려움이 발생할 수도 있습니다. 예를 들어 앱이 CPU 사용량에 따라 자동으로 확장되는 경우 CPU 사용량이 증가하지 않을 수 있습니다. 대신 호스팅 비용과 함께 서버 인스턴스 수가 너무 많이 증가할 수 있습니다.

7. 요청 비율

애플리케이션이 수신하는 트래픽을 측정하여 현저한 감소, 증가 또는 일치하는 사용자를 식별할 수 있습니다. 요청 비율과 다른 애플리케이션 성능 지표의 상관관계를 파악하면 소프트웨어 애플리케이션의 확장성을 이해하는 데 도움이 됩니다. APM 소프트웨어는 트래픽을 모니터링하여 이상을 식별할 수도 있습니다. 예기치 않은 요청 증가를 보여주는 사용자 모니터링은 서비스 거부(DoS) 공격일 수 있습니다. 동일한 사용자의 요청이 많으면 계정이 해킹되었음을 나타낼 수 있습니다. 비정상적으로 낮은 요청도 비활성 상태이거나 트래픽이 전혀 없는 것은 시스템의 거의 모든 부분에서 장애가 발생했음을 의미할 수 있습니다.

8. 응답 시간(지속 시간이라고도 함)

요청에 대한 평균 응답 시간(즉, 애플리케이션이 리소스 요청을 반환하는 데 걸리는 시간)을 추적하면 앱 성능을 평가할 수 있습니다. 이러한 요청에는 웹 페이지를 로드하는 요청과 같이 최종 사용자가 시작한 트랜잭션이 포함될 수도 있고, 디스크나 메모리에서 데이터를 요청하는 프로세스나 마이크로서비스와 같이 애플리케이션의 한 부분에서 다른 부분으로의 내부 요청이 포함될 수도 있습니다. 총 응답 시간에는 서버 응답 시간(서버가 요청을 처리하는 데 걸리는 시간)과 네트워크 지연 시간(요청이 네트워크를 통해 이동하는 데 걸리는 총 시간)이 포함됩니다.

관련 지표로는 웹페이지가 브라우저에 로드되는 데 걸리는 시간을 측정하는 페이지 로드 시간이 있습니다. 페이지 로드 시간을 추적하면 애플리케이션 성능 모니터링 툴이 페이지 로딩 속도를 유발하는 문제를 식별한 다음 디지털 경험을 개선할 수 있습니다. 페이지 로드 속도가 느리면 페이지 이탈과 비즈니스 손실이 발생할 수 있습니다. APM 솔루션은 이 지표에 대한 성능 기준에 대해 설정한 다음 해당 벤치마크가 충족되지 않을 때 경고할 수 있습니다.

애플리케이션 성능 모니터링과 관련된 보다 포괄적인 지표 세트를 찾고 있는 경우 다음 지표를 고려할 수 있습니다.

• 데이터베이스 쿼리: 애플리케이션이 데이터베이스에서 요청한 쿼리 수를 측정합니다. APM 도구가 애플리케이션의 성능을 저하시키는 느리거나 비효율적인 쿼리를 식별하는 데 도움이 될 수 있습니다.
• I/O (입력/아웃풋): I/O는 앱이 데이터를 읽거나 쓰는 속도를 보여줍니다. 영구 스토리지 미디어(예: HDD 또는 SSD)의 성능과 메모리 또는 가상 디스크의 I/O 속도를 추적할 수 있습니다.
• 네트워크 사용량: 네트워크 사용량은 애플리케이션에서 사용하는 총 네트워크 대역폭을 나타냅니다. 네트워크 사용량이 증가하면 성능 문제, 애플리케이션 응답 시간 속도 저하 또는 병목 현상을 나타낼 수 있습니다.
• 노드 가용성: 인스턴스 수와 유사한 측정값은 노드 가용성이지만, 이는 클라우드에만 해당합니다. Kubernetes 클러스터에 앱을 배포할 때 클러스터의 전체 노드 중 사용 가능하고 응답하는 노드 수는 인프라 내의 문제를 식별하는 데 도움이 될 수 있습니다. API 호출, 클라우드 기반 가상 머신(VM)의 실행 시간, 총 데이터 송신 속도를 추적하여 클라우드 비용을 실시간으로 파악할 수 있는 클라우드 지출 지표도 중요할 수 있습니다.
• 처리량: 처리량은 앱과 사용자 또는 다른 시스템 간에 전송할 수 있는 데이터의 양입니다. 앱이 예상 트래픽 양을 처리할 수 있는지 확인하는 데 사용할 수 있습니다.
• 트랜잭션 추적: 애플리케이션에서 수행한 단일 트랜잭션에 대한 그림을 제공합니다. 캡처되는 데이터에는 데이터베이스 호출, 외부 호출 및 함수 호출이 포함될 수 있으며, 트랜잭션 요청을 처음부터 끝까지 모니터링합니다.
• 트랜잭션 볼륨: 트랜잭션 볼륨은 애플리케이션에서 처리한 트랜잭션 수를 측정합니다. 이를 통해 APM 도구는 확장성 및 용량 계획과 관련된 문제를 식별할 수 있습니다.

IBM® Instana Observability는 누구나 사용할 수 있는 실시간 관측 가능성을 제공합니다. 신속한 가치 실현 시간을 제공하는 동시에 여러분의 관측 가능성 전략이 현재 및 미래 환경의 역동적인 복잡성을 따라잡을 수 있도록 보장합니다. Instana는 모바일에서 메인프레임에 이르기까지 250여 개의 기술을 지원하며 지속해서 성장하고 있습니다.