기본 콘텐츠로 건너뛰기

[ APM ] APDEX 가 뭘까?

APM (Application Performance Mangement) 과 관련해서 나오는 용어들 중에  APDEX라는 것이 있다. 보통 서비스 품질이라는 것은 IT 서비스를 제공하는 IT 부문과 IT 서비스를 이용하는 사용자 사이에 반응 시간 (Response Time)  등의 수치적인 지표를 이용해서 서로 수용 가능한 조건에서 이해하고 이용하는 기준으로 삼는 것이 필요하다.

ITIL (IT Infrastructure Library) 에서는 이런 기준이 될 수 있는 지표들을 IT 부문이 관리하는 IT  기반의 기술적인 관점에서 측정 및 관리하려고 하는 반면에 “업무나 사용자 관점에서도 이런 지표들이 필요하지 않을까?” 하는 사고방식에 근거해서 나오는 서비스 관리를 APM이라고 할 수 있고, 이 APM을 실시하는 방법으로 APDEX (Application Performance inDEX) 라는 지표를 이용해서 “사용자 시점의 IT 서비스 관리가 ITIL 과 같이 표준 프로세스화 할 수 있는 것이 아닐까?” 라고 생각하고 이것을 추진하는 사람들이 모인 Apdex Alliance 라는 그룹이 미국에 등장했다.

업무나 사용자 관점에서 IT 서비스 관리를 비즈니스 서비스 매니지먼트 (BSM  - Business Service Management) 이라고 표현하고 이를 위해서는  ITIL 과점의 기술적인 서비스 매니지먼트 (TSM - Technical Service Management) 에 융합시켜 가는 것이 필요하다고 소개하고 있다.

그럼 Apdex Alliance 가 주창하고 있는 Apdex 지표는 무엇일까?

Apdex 란?

Apdex는 제공되는 IT 서비스에 대해 사용자의 만족도를 수치적인 지표로 잡을 수 있도록 하기 위한 것으로 측정된 데이터에 대해서 0 (불만족) ~ 1 (만족) 사이의 만족도를 표현하기 위한 것이다.
이 지표는 사용자가 실행하는 업무 (Task 라고 표현) 에서 측정된 각 반응 속도 (Response Time)을 0 ~ 1 사이의 값으로 수치화 한다. 반응 속도라고 하는 것은 결국 사용자가 화면을 클릭해서 작업을 시작하고 결과가 사용자의 눈에 보이기까지 기다리는 시간을 기준으로 한다고 생각하면 된다.
이런 관점에서 데이터를 수집하고 각 작업에 대해서 IT 서비스가 만족되는 범위내에 있는지 또는 만족할 수 없는 수준인지를 Apdex Score 하는 지표를 사용하여 수치화하고 관리해 나가자는 것이다.

Apdex Score 란?

수치화 방법은 아주 간단하게 표현이 가능하다.

  • 만족 S (Satisfied) - 사용자가 업무 처리를 수행하는 전혀 문제가 없는 T (허용 기준 치) 초 미만의 수치
  • 허용 T (Tolerating) - 사용자가 업무 처리를 수행하는데 느리다는 느낌을 받기는 하지만 처리는 수행 가능한 상태로 T 초 이상 F (허용 불가 기준 치로 보통 T의 4배) 초 미만의 수치
  • 불만 F (Frustrated) - 사용자가 업무 처리를 수행하는데 도저히 처리가 불가능하다고 생각하는 상태로 F 초 이상의 수치

Apdex Score 의 산출 방법은 계측 시간 동안에 측정된 각 업무 처리를 만족/허용/불만족 으로 분류하고 각 수치를 아래와 같은 계산식에 적용하여 구하게 된다.

Apdex Score = ((전체 작업 중에 만족한 횟수 * 1) + (전체 작업 중에 허용 횟수 * 0.5)) / 전체 작업 수

위의 계산을 거치면 0 ~ 1 사이의 수치가 나오게 된다. 0 이라는 말은 전체 작업이 모두 불만족 상태라는 것이고, 1 이라는 말은 전체 작업이 모두 만족하는 상태라는 것이다. 만일 모든 작업이 허용 상태였다면 0.5의 값이 나오게 된다. 예를 들어 보면 더 쉽게 이해할 수 있다. 어떤 작업을 100번 실행했을 때 T 를 3초라고 하면 F 는 12초가 된다. 작업이 T 미만이 60개, T 와 F 사이가 30 개, F 이상이 10 개 였다고 하면 Apdex Score = ((60 * 1) + 30 * 0.5)) / 100 = 0.75 가 된다.

여기서 중요한 것은 계산된 결과보다도 "T 와 F 의 기준을 어떻게 잡을 것인가?" 가 된다. 이 값은 실제 각 업무와 사용자 부서등의 단위로 세분화가 필요하다. Apdex 에서는 F 를 T 의 4배라고 정하고 있기 때문에 결국 T의 기준을 어떻게 잡느냐가 가장 중요하다. (왜 4배인지는 좀 더 관련 자료를 파악해 볼 필요가 있다) T 를 정하는 기준이라는 것을 찾지는 못했지만 대략적인 값을 설정하여 테스트를 진행하고 사용자와의 협의 통해서 그 기준치를 점차 낮춰가면서 실제 적정한 값을 찾도록 해야 할 듯 하다. (예를 들면 3초 기준으로 했더니 모두 만족이지만 사용자 의견은 좀 느린 것 같다라면 2초로 낮춰서 다시 적용하는 등의 시행 착오)

이처럼 기준을 정해서 업무나 사용자마다 Apdex Score 를 계속적으로 관리하고 리포트를 구성하다보면 문제가 생기는 업무나 사용자를 파악할 수 있게 되고, 이를 기준으로 관련 IT 서비스의 문제가 무엇인지를 조사하는 것으로 어디서 지연이 발생하고 있었는지를 신속하게 조사하는 것이 가능해진다.

BSM 과 TSM?

TSM은 서버 관리나 네트워크 관리 등과 같이 IT Infrastructure를 구성하는 많은 기술들 (Firewall, IDS, LAN, Load Balancer, Web Server, Application Server, Database Server, SAN, Storage, Network, Virtual Machine, Virtual Resource Pool, ...) 을 각각 바라보는 것이고, BSM 은 사용자의 입장에서 업무 처리가 어떤 기술들을 거쳐서 결과가 도달하게 되는지를 바라보는 Flow로 보는 견해가 필요할 것이다. 따라서 TSM 은 Vertical 로 BSM 은 Hotizontal 관리라고 표현된다. 결과적으로는 종/횡으로 매트릭스가 그려질 수 있고, 종/횡으로 모두 문제라고 표현되는 곳이 존재한다면 그 것이 바로 문제의 핵심이 되는 것이다.



위의 그림과 같이 TSM  기준의 12 개 기술 요소는 특별한 이상이 없다. (각 1개의 붉은 색만 존재) 그러나 BSM 기준의 Task B 는 여러 개의 붉은 색이 존재하여 문제가 있는 것으로 나타나서 업무 처리 만족도가 나쁘게 나타나고 있다.

Apdex 의 목적?

지금까지 알아보았던 방식으로 IT 서비스에 대한 계량적 수치가 가능하면 IT 부문과 사용자 부문의 합의가 좀 더 쉬울 것이다. 물론 위에서 언급한 것과 같이 T를 제대로 정하지 못하면 이런 것도 무의미하기는 하다.
우선 대략적인 목표를 정해서 수치화하는 작업을 여러 번 진행해서 정상적인 경우의 Apdex Score 가 0.9  정도가 유지되는 값을 찾아내고, 그 값을 기준으로 BSM 을 실시하여 Apdex Score  rk 현저하게 떨어지는 시간대가 있다면 그 시간대에 TSM을 실시하는 등의 관리 룰을 정할 수 있다. 물론 시간대 뿐만 아니라 사용자가 몰리는 시간 (주로 월 결산 등) 에 따라서 측정과 관리를 하는 것도 가능하다.
Apdex 의 진정한 목적은 업무의 차이나 사용자의 차이 및 IT 서비스의 차이나 지역적인 차이에도 불구하고 0 ~ 1 의 기준이 될 수 있는 척도를 기반으로 해서 사용자의 만족도를 나타낼 수 있기 때문에 만족도의 격차나 전환을 잡아내는 것이 가능하고 이를 기반으로 TSM 과 BSM 을 진행하여 서비스의 만족도를 높이기 위한 것이라고 볼 수 있다.

댓글

이 블로그의 인기 게시물

OData 에 대해서 알아보자.

얼마 전에 어떤 회사에 인터뷰를 하러 간 적이 있었다. 당시 그 회사는 자체 솔루션을 개발할 기술인력을 찾고 있었고 내부적으로 OData를 사용한다고 했다. 좀 창피한 이야기일 수도 있지만 나름 기술적인 부분에서는 많은 정보를 가지고 있다고 했던 것이 무색하게 OData란 단어를 그 회사 사장님에게서 처음 들었다. 작고, 단순한 사이트들만을 계속해서 작업을 하다 보니 어느덧 큰 줄기들을 잃어버린 것을 느끼기 시작했다. 명색이 개발이 좋고, 기술적인 기반을 만들려고 하는 인간이 단어조차도 모른다는 것은 있을 수 없는 것이라서 다시 새로운 단어들과 개념들을 알아보는 시간을 가지려고 한다. OData (Open Data Protocol) 란? 간단히 정리하면 웹 상에서 손쉽게 데이터를 조회하거나 수정할 수 있도록 주고 받는 웹(프로토콜)을 말한다. 서비스 제공자 입장에서는 웹으로 데이터를 제공하는 방식으로 각 포탈 사이트들이 제공하는 OPEN API 포맷을 독자적인 형식이 아니라 오픈된 공통규약으로 제공 가능하며, 개발자는 이 정보를 다양한 언어의 클라이언트 라이브러리로 어플리케이션에서 소비할 수 있도록 사용하면 된다. 공식 사이트는 www.odata.org 이며 많은 언어들을 지원하고 있다. 좀더 상세하게 정의를 해 보면 OData는 Atom Publishing Protocol  (RFC4287) 의 확장 형식이고 REST (REpresentational State Transfer) Protocol 이다. 따라서 웹 브라우저에서 OData 서비스로 노출된 데이터를 볼 수 있다. 그리고 AtomPub 의 확장이라고 했듯이 데이터의 조회만으로 한정되는 것이 아니라 CRUD 작업이 모두 가능하다. Example 웹 브라우저에서 http://services.odata.org/website/odata.svc 를 열어 보도록 하자. This XML file does not appear to have any style in...

C# 에서 Timer 사용할 때 주의할 점.

예전에 알고 지내시던 분의 질문을 받았다. Windows Forms 개발을 하는데, 주기적 (대략 1분)으로 데이터 요청을 하는 프로그램을 작성하기 위해서 Timer 를 사용하는데, 어떤 기능을 처리해야 하기 때문에 Sleep 을 같이 사용했다고 한다. 여기서 발생하는 문제는 Sleep 5초를 주었더니, Timer 까지 5초 동안 멈춘다는 것이다. Timer 라는 것은 기본적으로 시간의 흐름을 측정하는 기능이기 때문에 Sleep 을 했다고 해서 Timer 가 멈추는 일은 생겨서는 안된다. 그러나 실제 샘플을 만들어 보면 ... Timer 가 Sleep 만큼 동작이 멈추는 것을 확인할 수 있다. Windows Forms 는 UI Thread 를 사용하는 것으로 최적화 되어 있으며 여기서 Timer 를 쓰면 UI Thread 에 최적화된 System.Windows.Forms.Timer 가 사용된다. 여기서 문제의 발생이 시작되는 것이다. Sleep 을 사용하게 되면 UI Thread 가 Sleep 이 걸리기 때문에 여기에 속한 Timer 까지도 멈추는 것이다. 이런 문제를 해결하기 위해서는 System.Threading.Timer 를 사용해야 한다. 이 Timer 는 별도의 Thread 에서 동작하기 때문에 Sleep 의 영향을 받지 않는다. 언뜻 보면 쉬운 해결 방법인 것 같지만 Thread 가 분리되었기 때문에 Timer 가 돌아가는 Thread 에서 UI Thread 의 메서드나 컨트롤에 접근하기 위해서는 별도의 명령을 사용해야 하는 문제가 존재한다. 자~ 그럼 여기서 Timer 에 대해서 다시 한번 정리해 보도록 하자. .NET 에서 제공하는 Timer 들 .NET 에서는 기본적으로 3가지 Timer를 제공하고 있다. (MSDN) System.Windows.Forms.Timer - 사용자가 지정한 간격마다 이벤트를 발생시키며 Windows Forms 응용 프로그램에서 사용할 수 있도록 최적화 되어 있다. System...

[Logging] NLog 사용법 정리...

SCSF 에는 기본적으로 Enterprise Library가 사용된다. 예전에도 그랬지만 기능은 훌륭하고 많은 부분에서 최적화(?)된 것일지도 모르지만, 역시나 사용하기에는 뭔가 모르게 무겁고, 사용하지 않는 기능이 더 많다라는 느낌을 지울수가 없다. 이번 프로젝트도 SCSF를 기반으로 하고 있지만, Enterprise Library를 걷어내고 각 부분에 전문화된 오픈 소스를 사용하기로 하였다. 예전에는 Log4Net을 사용했지만, 대량 사용자 환경에서는 메모리 누수와 기타 문제점이 존재한다는 MS 컨설턴트(?)의 전해진 말을 들은 후로는 사용하지 않는다. 대안으로 사용하는 것이 NLog 이다. 조금 후에는 3.0 버전도 나온다고 홈 페이지에 기재되어 있지만, 그 때가 되면 프로젝트는 끝나기 때문에 현재 2.1.0 버전을 사용하기로 했다. [원본 출처] http://cloverink.net/most-useful-nlog-configurations-closed/ 위의 참조 자료에는 다양한 정보들이 존재하므로 꼭 링크를 통해서 관련된 정보를 확인하고 이해하는 것이 좋을 듯 하다. 여기서는 당장 필요한 부분만을 정리하도록 한다. [ Logger 찾기 ] 기본적으로 Logger가 존재하는 클래스를 기반으로 Logger 정보를 구성한다. Logger logger = LogManager.GetCurrentClassLogger(); 주로 Namespace 기반으로 Logger를 설정하는 경우에 유연하게 사용할 수 있다. 또 다른 방법으로는 지정한 문자열로 특정 Logger를 직접 선택하는 방법도 제공된다. 이를 혼용해서 Namespace와 직접 지정 방식을 같이 사용할 수도 있다. 물론 Logger 환경 설정에서 Wildcard (*)를 지정할 수도 있다. Logger logger = LogManager.GetLogger("Database.Connect"); Logger logger = LogManager.Get...