탁월한 고객 경험(CX)은 정확하고 시기적절한 APM(애플리케이션 성능 모니터링) 지표를 기반으로 구축됩니다. 문제가 무엇인지, 기회가 어디에 있는지 알기 전까지는 CX 개선을 위해 앱이나 시스템을 미세 조정할 수 없습니다.

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

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

모니터링할 주요 APM 지표

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

1. Apdex 및 SLA 점수

우수한 고객 경험의 기초가 되는 애플리케이션 성능 지수(Apdex)와 서비스 수준 계약(SLA) 점수부터 시작해 보겠습니다. 측정할 속도와 피드는 빠른 성능을 위해 추가되어야 하는 특정 측면이지만 이는 끝이 아니라 수단입니다. 행복한 고객이 귀하의 목표입니다. 바라건대 매출 증대로 이어지길 바랍니다.

Apdex 및 SLA 점수는 최종 사용자 경험 모니터링을 보는 가장 널리 사용되는 방법입니다. Apdex 점수는 웹 요청 또는 트랜잭션에 일반적으로 소요되는 시간에 대한 목표를 지정하여 앱의 상대적 성능을 추적합니다. SLA는 고객 계약의 지표이며 정의된 SLA보다 낮은 모든 항목은 CX 저하(사전 정의된 페널티 포함) 위험을 초래합니다.

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

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

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

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

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

4. 오류율

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

5. 쓰레기 수거

GC(가비지 수집)는 Java 또는 기타 언어의 지속적인 과도한 메모리 사용량을 식별하고 제거하여 성능을 향상시킬 수 있습니다. 좋은 소식은 GC 자동화가 애플리케이션에서 더 이상 사용되지 않는 사용되지 않거나 중복된 개체 또는 데이터에 할당된 메모리를 회수한다는 것입니다. 사용하지 않는 개체나 데이터는 삭제되고 활성 개체는 차세대 메모리 풀에 복사됩니다. 이는 행복한 중간에 유지하려는 측정항목입니다. GC가 너무 자주 실행되면 너무 많은 오버헤드가 필요할 수 있습니다. 그러나 GC가 자주 실행되지 않으면 시스템에 메모리가 너무 적게 남을 수 있습니다.

6. 인스턴스 수

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

7. 요청률

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

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

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

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

추가 애플리케이션 측정항목

애플리케이션 성능 모니터링과 관련된 보다 포괄적인 측정항목 세트를 찾고 있는 경우 다음 측정항목을 고려해 볼 수 있습니다.

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

APM 솔루션 선택 시작하기

IBM Instana 관찰 가능성 누구나, 누구나 사용할 수 있는 실시간 관찰성을 제공합니다. 관찰 가능성 전략이 현재와 미래의 환경의 역동적인 복잡성을 따라잡을 수 있도록 보장하면서 빠른 가치 실현 시간을 제공합니다. 모바일에서 메인프레임까지 Instana는 250개 이상의 기술을 지원하며 성장하고 있습니다.

IBM Instana를 사용한 애플리케이션 성능 모니터링에 대해 자세히 알아보기