2021.07.22

"모든 분석이 같은 결과를 가져오지 않는다" 분석 등급별 다른 용도와 특징

Lee Atchison | InfoWorld
분석(Analytics)은 모든 현대 SaaS 애플리케이션의 핵심이다. SaaS 애플리케이션을 성공적으로 운영하기 위해서는 애플리케이션의 성능이 어느 정도인지, 무슨 일을 하는지, 목표 달성에 얼만큼 성공하고 있는지를 모니터링해야 한다.
 
ⓒ Getty Images Bank

그러나 현대 애플리케이션이 모니터링하고 점검해야 할 분석의 유형은 많다. 분석의 목적과 가치, 정확성, 신뢰성은 어떻게 측정하고 사용되는지, 그리고 누가 사용하는지에 따라 크게 좌우된다. 기본적으로는 3가지 클래스의 분석이 있으며 각각의 사용례는 확연히 다르다.


클래스 A 분석, 미션 크리티컬한 애플리케이션 운영

클래스 A 분석은 애플리케이션의 미션 크리티컬 메트릭이다. 이 분석이 없으면 애플리케이션 작동이 즉시 멈출 수 있다. 애플리케이션 운영을 평가하고 성능을 조정하고 동적으로 수정해 애플리케이션 기능을 유지하는 데 사용되는 메트릭이다.

분석은 애플리케이션 운영 환경을 지속적으로 모니터링하고 개선하는 피드백 루프의 일부분이다.

클래스 A 분석의 대표적인 예는 오토스케일링(autoscaling)에 사용되는 메트릭이다. 이와 같은 메트릭은 애플리케이션의 부하가 변동함에 따라 현재의 수요를 충족 또는 초과하도록 인프라 크기를 동적으로 변경하는 데 사용된다.

잘 알려진 예로 AWS 오토스케일링(Auto Scaling) 클라우드 서비스가 있다. 이 서비스는 특정 아마존 클라우드워치(CloudWatch) 메트릭을 자동으로 모니터링하면서 트리거와 임계치를 관찰한다. 

특정 메트릭이 특정 조건에 도달하면 AWS 오토스케일링은 아마존 EC2 인스턴스를 애플리케이션에 추가 또는 제거해 애플리케이션을 운영하는 데 사용되는 자원을 자동으로 조정한다. 더 많은 자원이 필요하면 인스턴스를 추가하고, 메트릭에 자원이 더 이상 필요없는 것으로 나타나면 인스턴스에서 리소스를 제거한다.

AWS 오토스케일링을 활용하면 원하는 수의 EC2 인스턴스로 구성된 서비스를 만든 다음, 트래픽과 부하 요구사항에 따라 자동으로 서버를 더하거나 뺄 수 있다. 트래픽이 낮으면 그만큼 적은 수의 인스턴스가 사용되고 트래픽이 높으면 더 많은 인스턴스가 사용된다.

예를 들어 AWS 오토스케일링은 한 서비스에 사용 중인 모든 인스턴스의 평균 CPU 부하를 측정하는 클라우드워치 메트릭을 사용할 수 있다. CPU 부하가 특정 임계치를 넘어서면 AWS 오토스케일링이 서비스 풀에 서버 하나를 더 추가한다.

참고로, 어떤 이유로 아마존 클라우드워치 메트릭을 사용할 수 없는 상태가 되거나 메트릭이 부정확한 경우에는 알고리즘이 기능을 수행할 수 없게 된다. 이렇게 되면 너무 많은 인스턴스가 서비스에 추가되어 돈이 낭비되거나 너무 적은 인스턴스가 서비스에 추가되어 애플리케이션 성능이 저하되거나 완전히 작동을 멈추게 된다.

당연히 이와 같은 메트릭은 매우 중요하다. 메트릭의 가용성과 정확성이 확보되지 않으면 애플리케이션의 운영 자체가 위태롭다. 따라서 클래스 A 메트릭으로 분류된다.

AWS 일래스틱 로드 밸런싱(Elastic Load Balancing) 역시 좋은 예다. AWS는 각 로드 밸런서로 가는 현재 트래픽의 양에 따라 특정 사용례의 트래픽 로드 밸런싱 서비스를 운영하는 데 필요한 인스턴스의 크기와 수를 자동으로 조정한다. 

트래픽이 증가하면 해당 로드 밸런서는 자동으로 더 크거나 많은 수의 인스턴스로 이동한다. 트래픽이 감소하면 자동으로 규모가 더 작거나 수가 적은 인스턴스로 이동한다. 이 모든 과정은 특정 클라우드워치 메트릭을 활용하는 내부 알고리즘을 기반으로 자동으로 수행된다. 따라서 메트릭의 가용성이나 정확성이 떨어지면 로드 밸런서의 조정이 적절히 이뤄지지 않고 트래픽 부하 처리 역량이 저하된다.


클래스 B 분석, 시스템 중단을 예방하거나 복구 

클래스 B 분석은 비즈니스 크리티컬한 분석은 아니지만 곧 닥칠 문제의 조기 지표로 사용되거나 문제 발생 시 해결하는 데 사용된다. 클래스 B 분석은 시스템 중단을 예방하거나 중단에서 복구할 때 중요하다.

클래스 B 메트릭은 일반적으로 애플리케이션 또는 서비스의 내부 동작에 대한 통찰력을 제공하거나, 애플리케이션 또는 서비스를 운영하는 인프라 내부에 대한 통찰력을 제공한다. 이와 같은 통찰력을 선제적 또는 대응적으로 사용해 애플리케이션이나 서비스의 운영을 개선할 수 있다.

선제적인 사용의 경우, 클래스 B 메트릭을 모니터링해서 애플리케이션 또는 서비스의 잘못된 동작을 나타내는 추세를 파악할 수 있다. 이와 같은 추세를 기반으로 메트릭을 사용해 운영 팀이 시스템을 점검해서 잘못된 부분을 찾도록 알리는 경보를 트리거할 수 있다.

대응적인 사용례를 보면, 시스템 장애 또는 성능 저하가 발생하는 경우 현재까지의 클래스 B 메트릭 기록을 조사해 장애 또는 성능 문제를 야기한 요소가 무엇인지를 파악하고 문제의 해결책을 마련할 수 있다. 이런 메트릭은 사이트 장애 상황과 사후 조사에서 자주 사용된다.

장애 이벤트 중에 클래스 B 메트릭은 어떤 부분이 잘못됐는지, 문제를 어떻게 수정해야 하는지를 신속하게 파악하는 데 사용된다. 장애 이벤트 이후에는 중단 상황에서 문제를 찾는 데 소요되는 평균 시간인 평균 탐지 시간(MTTD)과 중단 상황에서 문제를 수정하는 방법을 파악하는 데 소요되는 시간인 평균 복구 시간(MTTR)을 개선하는 데 사용된다. 이 두 가지 모두 고성능 SaaS 애플리케이션의 핵심적인 목표다.

그러나 이와 같은 메트릭의 중요도는 클래스 A 메트릭보다는 낮다. 클래스 A 메트릭이 실패하면 애플리케이션이 멈출 수 있다. 그러나 클래스 B 메트릭이 실패하더라도 애플리케이션이 멈추지는 않는다. 다만 클래스 B 메트픽이 제대로 동작하지 않을 경우 애플리케이션에 문제가 있을 때 문제를 찾아서 수정하는 데 소요되는 시간이 더 길어질 수 있다.

클래스 B 메트릭의 예는 많고, 이와 같은 메트릭을 생성하는 데 초점을 두는 기업도 앱다이나믹스(AppDynamics), 데이터도그(Datadog), 다이나트레이스(Dynatrace), 뉴 렐릭(New Relic)을 비롯해 다수다. 또한 일래스틱(Elastic), 스플렁크(Splunk)와 같은 기업의 로깅 및 기타 메트릭도 클래스 B 메트릭에 포함될 수 있다.

 
클래스 C 분석, 비즈니스 분석과 전략 결정

클래스 C 분석에서 다루는 메트릭은 오프라인 애플리케이션 분석과 장기 계획 프로세스에 사용되는 메트릭이다. 클래스 C 분석은 애플리케이션의 전략과 제품 방향을 결정하는 데 자주 사용된다.

클래스 C 메트릭은 클래스 A 및 클래스 B 메트릭과 마찬가지로 실시간으로 조사할 수도 있고 주, 월 또는 분기 단위로 정기적으로 생성해 조사할 수도 있다.

클래스 C 메트릭은 고객 트래픽 패턴 분석, 사이트에 머무는 시간, 방문자를 보낸 사이트, 이탈률 분석과 같은 비즈니스 분석에 사용된다. 영업 보고서와 영업 유입경로를 파악하는 데 사용할 수 있으며, 재무 보고서 및 감사 용도로도 사용 가능하다.

일부 기업은 고객에게 두 가지 이상의 기능 버전을 보여준 다음 메트릭을 분석해 어느 버전이 더 효과적인지를 확인하는 방법으로 새로운 애플리케이션 기능이나 웹사이트의 새로운 문구를 테스트한다. 이것을 A/B 테스트라고 하며, 클래스 C 메트릭이 사용된다.

클래스 C 메트릭을 제공하는 기업은 많지만 단연 가장 유명한 클래스 C 메트릭 제공업체는 구글 애널리틱스(Google Analytics)다.


분석의 분류가 중요한 이유

메트릭마다 소비자가 다르다. 다음과 같이 특정 메트릭의 소비자는 그 메트릭이 속한 범주에 따라 분류된다.
  
  • 클래스 A 메트릭은 주로 자동화된 시스템에 의해 소비되며 시스템 및 프로세스에서 내부적으로 사용된다. 시스템을 정상 상태로 유지하고 적절히 확장되도록 하기 위해 핵심 운영 자원을 동적으로, 자동으로 업데이트하는 데 사용된다.
  •  
  • 클래스 B 메트릭은 대부분 운영 및 지원 팀, 그리고 개발 팀에서 사고 대응 프로세스 중에 사용된다. 팀이 문제를 찾고 수정하는 과정에서 즉각적인 도움이 되고, 일반적으로 문제가 발생하기 전에 예방하는 데도 유용하다.
  •  
  • 클래스 C 메트릭은 대부분 비즈니스 계획자, 제품 관리자 및 기업 경영진에 의해 소비된다. 장기적인 비즈니스 의사 결정, 비즈니스 모델링, 제품 설계 및 기능 우선순위 결정에 사용된다.

또한 가장 중요한 부분이라고 할 수 있는 점은 분석을 수집하고 처리하는 시스템에 따라 애플리케이션 내에서의 우선순위가 다르다는 것이다. 클래스 A 메트릭을 수집하는 문제는 운영에 미션크리티컬한 문제다. 클래스 A 메트릭이 실패할 경우 자동화된 인프라 도구가 잘못 동작하고 궁극적으로 성능 저하나 전면적인 중단으로 이어질 수 있다.

반면 클래스 C 메트릭을 수집하는 문제는 반드시 경고로 이어지지는 않으며 클래스 C 문제를 해결하는 작업은 몇 시간, 며칠 또는 그 이상 연기도 가능하다.

메트릭을 사용하는 방법을 결정할 때는 신중을 기해야 한다. 메트릭을 맞지 않는 용도로 사용할 경우 큰 문제로 이어질 수 있기 때문이다. 예를 들어 동적으로, 자동으로 시스템 자원을 할당할(서버 자원 오토스케일링 등) 목적으로 “애플리케이션 지연”과 같은 클래스 B 메트릭을 사용해서는 안 된다. 이와 같은 미션크리티컬 사용례에 클래스 B 메트릭을 사용할 경우 애플리케이션에 불필요한 위험이 더해진다.

예를 들어 애플리케이션 성능 모니터링 업체로부터 일반적으로 클래스 B 메트릭으로 분류되는 메트릭을 받는다고 가정해 보자. 이와 같은 메트릭이 보고하는 “애플리케이션 지연”을 사용해 자원 확장/축소를 결정할 경우 잠재적인 문제에 노출된다. 애플리케이션 성능 모니터링 업체의 시스템이 중단되는 경우 리소스를 올바르게 확장할 수 없고 시스템 중단이 발생할 수도 있다. 이는 문제를 진단하는 용도로 유용하고 가치있는 정도의 애플리케이션 성능 모니터링이 이제 자사 애플리케이션의 미션크리티컬 구성요소가 되었다는 의미다.

다른 예로, 장바구니 서비스의 운영 가용성 문제를 확인할 때 “장바구니 포기율”과 같은 클래스 C 메트릭에 주로 의존해서는 안 된다. 이 메트릭은 문제로부터 너무 멀리 떨어져 있어 해결이 필요한 문제를 적시에 알려주지 못할 가능성이 높다. “장바구니 포기 증가로 인해 이번 주 판매량이 감소한다”는 보고서는 장바구니 서비스 문제를 조기에 해결하기에는 정보도 너무 적고 시기도 너무 늦다.

적절한 메트릭을 적절한 용도로 사용하면 분석의 효용성이 높아지고 적시 보고가 가능하고 애플리케이션과 비즈니스의 위험이 낮아진다. editor@itworld.co.kr 


2021.07.22

"모든 분석이 같은 결과를 가져오지 않는다" 분석 등급별 다른 용도와 특징

Lee Atchison | InfoWorld
분석(Analytics)은 모든 현대 SaaS 애플리케이션의 핵심이다. SaaS 애플리케이션을 성공적으로 운영하기 위해서는 애플리케이션의 성능이 어느 정도인지, 무슨 일을 하는지, 목표 달성에 얼만큼 성공하고 있는지를 모니터링해야 한다.
 
ⓒ Getty Images Bank

그러나 현대 애플리케이션이 모니터링하고 점검해야 할 분석의 유형은 많다. 분석의 목적과 가치, 정확성, 신뢰성은 어떻게 측정하고 사용되는지, 그리고 누가 사용하는지에 따라 크게 좌우된다. 기본적으로는 3가지 클래스의 분석이 있으며 각각의 사용례는 확연히 다르다.


클래스 A 분석, 미션 크리티컬한 애플리케이션 운영

클래스 A 분석은 애플리케이션의 미션 크리티컬 메트릭이다. 이 분석이 없으면 애플리케이션 작동이 즉시 멈출 수 있다. 애플리케이션 운영을 평가하고 성능을 조정하고 동적으로 수정해 애플리케이션 기능을 유지하는 데 사용되는 메트릭이다.

분석은 애플리케이션 운영 환경을 지속적으로 모니터링하고 개선하는 피드백 루프의 일부분이다.

클래스 A 분석의 대표적인 예는 오토스케일링(autoscaling)에 사용되는 메트릭이다. 이와 같은 메트릭은 애플리케이션의 부하가 변동함에 따라 현재의 수요를 충족 또는 초과하도록 인프라 크기를 동적으로 변경하는 데 사용된다.

잘 알려진 예로 AWS 오토스케일링(Auto Scaling) 클라우드 서비스가 있다. 이 서비스는 특정 아마존 클라우드워치(CloudWatch) 메트릭을 자동으로 모니터링하면서 트리거와 임계치를 관찰한다. 

특정 메트릭이 특정 조건에 도달하면 AWS 오토스케일링은 아마존 EC2 인스턴스를 애플리케이션에 추가 또는 제거해 애플리케이션을 운영하는 데 사용되는 자원을 자동으로 조정한다. 더 많은 자원이 필요하면 인스턴스를 추가하고, 메트릭에 자원이 더 이상 필요없는 것으로 나타나면 인스턴스에서 리소스를 제거한다.

AWS 오토스케일링을 활용하면 원하는 수의 EC2 인스턴스로 구성된 서비스를 만든 다음, 트래픽과 부하 요구사항에 따라 자동으로 서버를 더하거나 뺄 수 있다. 트래픽이 낮으면 그만큼 적은 수의 인스턴스가 사용되고 트래픽이 높으면 더 많은 인스턴스가 사용된다.

예를 들어 AWS 오토스케일링은 한 서비스에 사용 중인 모든 인스턴스의 평균 CPU 부하를 측정하는 클라우드워치 메트릭을 사용할 수 있다. CPU 부하가 특정 임계치를 넘어서면 AWS 오토스케일링이 서비스 풀에 서버 하나를 더 추가한다.

참고로, 어떤 이유로 아마존 클라우드워치 메트릭을 사용할 수 없는 상태가 되거나 메트릭이 부정확한 경우에는 알고리즘이 기능을 수행할 수 없게 된다. 이렇게 되면 너무 많은 인스턴스가 서비스에 추가되어 돈이 낭비되거나 너무 적은 인스턴스가 서비스에 추가되어 애플리케이션 성능이 저하되거나 완전히 작동을 멈추게 된다.

당연히 이와 같은 메트릭은 매우 중요하다. 메트릭의 가용성과 정확성이 확보되지 않으면 애플리케이션의 운영 자체가 위태롭다. 따라서 클래스 A 메트릭으로 분류된다.

AWS 일래스틱 로드 밸런싱(Elastic Load Balancing) 역시 좋은 예다. AWS는 각 로드 밸런서로 가는 현재 트래픽의 양에 따라 특정 사용례의 트래픽 로드 밸런싱 서비스를 운영하는 데 필요한 인스턴스의 크기와 수를 자동으로 조정한다. 

트래픽이 증가하면 해당 로드 밸런서는 자동으로 더 크거나 많은 수의 인스턴스로 이동한다. 트래픽이 감소하면 자동으로 규모가 더 작거나 수가 적은 인스턴스로 이동한다. 이 모든 과정은 특정 클라우드워치 메트릭을 활용하는 내부 알고리즘을 기반으로 자동으로 수행된다. 따라서 메트릭의 가용성이나 정확성이 떨어지면 로드 밸런서의 조정이 적절히 이뤄지지 않고 트래픽 부하 처리 역량이 저하된다.


클래스 B 분석, 시스템 중단을 예방하거나 복구 

클래스 B 분석은 비즈니스 크리티컬한 분석은 아니지만 곧 닥칠 문제의 조기 지표로 사용되거나 문제 발생 시 해결하는 데 사용된다. 클래스 B 분석은 시스템 중단을 예방하거나 중단에서 복구할 때 중요하다.

클래스 B 메트릭은 일반적으로 애플리케이션 또는 서비스의 내부 동작에 대한 통찰력을 제공하거나, 애플리케이션 또는 서비스를 운영하는 인프라 내부에 대한 통찰력을 제공한다. 이와 같은 통찰력을 선제적 또는 대응적으로 사용해 애플리케이션이나 서비스의 운영을 개선할 수 있다.

선제적인 사용의 경우, 클래스 B 메트릭을 모니터링해서 애플리케이션 또는 서비스의 잘못된 동작을 나타내는 추세를 파악할 수 있다. 이와 같은 추세를 기반으로 메트릭을 사용해 운영 팀이 시스템을 점검해서 잘못된 부분을 찾도록 알리는 경보를 트리거할 수 있다.

대응적인 사용례를 보면, 시스템 장애 또는 성능 저하가 발생하는 경우 현재까지의 클래스 B 메트릭 기록을 조사해 장애 또는 성능 문제를 야기한 요소가 무엇인지를 파악하고 문제의 해결책을 마련할 수 있다. 이런 메트릭은 사이트 장애 상황과 사후 조사에서 자주 사용된다.

장애 이벤트 중에 클래스 B 메트릭은 어떤 부분이 잘못됐는지, 문제를 어떻게 수정해야 하는지를 신속하게 파악하는 데 사용된다. 장애 이벤트 이후에는 중단 상황에서 문제를 찾는 데 소요되는 평균 시간인 평균 탐지 시간(MTTD)과 중단 상황에서 문제를 수정하는 방법을 파악하는 데 소요되는 시간인 평균 복구 시간(MTTR)을 개선하는 데 사용된다. 이 두 가지 모두 고성능 SaaS 애플리케이션의 핵심적인 목표다.

그러나 이와 같은 메트릭의 중요도는 클래스 A 메트릭보다는 낮다. 클래스 A 메트릭이 실패하면 애플리케이션이 멈출 수 있다. 그러나 클래스 B 메트릭이 실패하더라도 애플리케이션이 멈추지는 않는다. 다만 클래스 B 메트픽이 제대로 동작하지 않을 경우 애플리케이션에 문제가 있을 때 문제를 찾아서 수정하는 데 소요되는 시간이 더 길어질 수 있다.

클래스 B 메트릭의 예는 많고, 이와 같은 메트릭을 생성하는 데 초점을 두는 기업도 앱다이나믹스(AppDynamics), 데이터도그(Datadog), 다이나트레이스(Dynatrace), 뉴 렐릭(New Relic)을 비롯해 다수다. 또한 일래스틱(Elastic), 스플렁크(Splunk)와 같은 기업의 로깅 및 기타 메트릭도 클래스 B 메트릭에 포함될 수 있다.

 
클래스 C 분석, 비즈니스 분석과 전략 결정

클래스 C 분석에서 다루는 메트릭은 오프라인 애플리케이션 분석과 장기 계획 프로세스에 사용되는 메트릭이다. 클래스 C 분석은 애플리케이션의 전략과 제품 방향을 결정하는 데 자주 사용된다.

클래스 C 메트릭은 클래스 A 및 클래스 B 메트릭과 마찬가지로 실시간으로 조사할 수도 있고 주, 월 또는 분기 단위로 정기적으로 생성해 조사할 수도 있다.

클래스 C 메트릭은 고객 트래픽 패턴 분석, 사이트에 머무는 시간, 방문자를 보낸 사이트, 이탈률 분석과 같은 비즈니스 분석에 사용된다. 영업 보고서와 영업 유입경로를 파악하는 데 사용할 수 있으며, 재무 보고서 및 감사 용도로도 사용 가능하다.

일부 기업은 고객에게 두 가지 이상의 기능 버전을 보여준 다음 메트릭을 분석해 어느 버전이 더 효과적인지를 확인하는 방법으로 새로운 애플리케이션 기능이나 웹사이트의 새로운 문구를 테스트한다. 이것을 A/B 테스트라고 하며, 클래스 C 메트릭이 사용된다.

클래스 C 메트릭을 제공하는 기업은 많지만 단연 가장 유명한 클래스 C 메트릭 제공업체는 구글 애널리틱스(Google Analytics)다.


분석의 분류가 중요한 이유

메트릭마다 소비자가 다르다. 다음과 같이 특정 메트릭의 소비자는 그 메트릭이 속한 범주에 따라 분류된다.
  
  • 클래스 A 메트릭은 주로 자동화된 시스템에 의해 소비되며 시스템 및 프로세스에서 내부적으로 사용된다. 시스템을 정상 상태로 유지하고 적절히 확장되도록 하기 위해 핵심 운영 자원을 동적으로, 자동으로 업데이트하는 데 사용된다.
  •  
  • 클래스 B 메트릭은 대부분 운영 및 지원 팀, 그리고 개발 팀에서 사고 대응 프로세스 중에 사용된다. 팀이 문제를 찾고 수정하는 과정에서 즉각적인 도움이 되고, 일반적으로 문제가 발생하기 전에 예방하는 데도 유용하다.
  •  
  • 클래스 C 메트릭은 대부분 비즈니스 계획자, 제품 관리자 및 기업 경영진에 의해 소비된다. 장기적인 비즈니스 의사 결정, 비즈니스 모델링, 제품 설계 및 기능 우선순위 결정에 사용된다.

또한 가장 중요한 부분이라고 할 수 있는 점은 분석을 수집하고 처리하는 시스템에 따라 애플리케이션 내에서의 우선순위가 다르다는 것이다. 클래스 A 메트릭을 수집하는 문제는 운영에 미션크리티컬한 문제다. 클래스 A 메트릭이 실패할 경우 자동화된 인프라 도구가 잘못 동작하고 궁극적으로 성능 저하나 전면적인 중단으로 이어질 수 있다.

반면 클래스 C 메트릭을 수집하는 문제는 반드시 경고로 이어지지는 않으며 클래스 C 문제를 해결하는 작업은 몇 시간, 며칠 또는 그 이상 연기도 가능하다.

메트릭을 사용하는 방법을 결정할 때는 신중을 기해야 한다. 메트릭을 맞지 않는 용도로 사용할 경우 큰 문제로 이어질 수 있기 때문이다. 예를 들어 동적으로, 자동으로 시스템 자원을 할당할(서버 자원 오토스케일링 등) 목적으로 “애플리케이션 지연”과 같은 클래스 B 메트릭을 사용해서는 안 된다. 이와 같은 미션크리티컬 사용례에 클래스 B 메트릭을 사용할 경우 애플리케이션에 불필요한 위험이 더해진다.

예를 들어 애플리케이션 성능 모니터링 업체로부터 일반적으로 클래스 B 메트릭으로 분류되는 메트릭을 받는다고 가정해 보자. 이와 같은 메트릭이 보고하는 “애플리케이션 지연”을 사용해 자원 확장/축소를 결정할 경우 잠재적인 문제에 노출된다. 애플리케이션 성능 모니터링 업체의 시스템이 중단되는 경우 리소스를 올바르게 확장할 수 없고 시스템 중단이 발생할 수도 있다. 이는 문제를 진단하는 용도로 유용하고 가치있는 정도의 애플리케이션 성능 모니터링이 이제 자사 애플리케이션의 미션크리티컬 구성요소가 되었다는 의미다.

다른 예로, 장바구니 서비스의 운영 가용성 문제를 확인할 때 “장바구니 포기율”과 같은 클래스 C 메트릭에 주로 의존해서는 안 된다. 이 메트릭은 문제로부터 너무 멀리 떨어져 있어 해결이 필요한 문제를 적시에 알려주지 못할 가능성이 높다. “장바구니 포기 증가로 인해 이번 주 판매량이 감소한다”는 보고서는 장바구니 서비스 문제를 조기에 해결하기에는 정보도 너무 적고 시기도 너무 늦다.

적절한 메트릭을 적절한 용도로 사용하면 분석의 효용성이 높아지고 적시 보고가 가능하고 애플리케이션과 비즈니스의 위험이 낮아진다. editor@itworld.co.kr 


X