This is why it’s vital to have end-to-end visibility for your applications, infrastructure, reliability, and team health in your DevOps environment. Sharing key performance metrics with all stakeholders in your digital business lets everyone monitor your DevOps efforts and prove success at every stage. Leaders benefit from knowing that everyone is aligned and moving forward towards the same goals. And shared insights help teammates collaborate easier and quicker.

측정 사항

진정한 데브옵스의 성공은, 강력한 고객 환경을 제공하는 신뢰 가능한 고성능 소프트웨어를 보다 빠르고 자주 제공하기 위해 팀의 속도와 민첩성을 향상시킨다는 것을 의미합니다. 인프라와 애플리케이션의 성능에서 안정성과 팀 상태에 이르기까지, 전체 기술 스택에서 실시간 및 과거 데이터에 액세스하고 공유하는 것이 필수적입니다.

데브옵스 여정을 추적하기 위해서는 많은 측정 가능한 메트릭이 존재하지만, 아래의 17개 메트릭은 좋은 시작점이 될 수 있으며, 이는 크게 세 가지 기능 영역으로 분류됩니다 :

  1. 기본 애플리케이션 및 인프라 상태에 대한 데브옵스 측정
  2. 안정성 및 시스템 상태에 대한 데브옵스 측정
  3. 데브옵스 및 데브옵스 팀의 상태 측정

이 목록의 순서는 특정한 나열을 의미하지 않습니다. 일반적인 측정에서 특정한 측정으로 이동하며, 적절하게 계획된 데브옵스 이니셔티브는 세 그룹 모두에서 메트릭을 추적합니다.

기본 애플리케이션 및 인프라 상태에 대한 데브옵스 측정

데브옵스 팀은 문제가 발생하여 고객에게 영향을 미치기 전에 신속하게 이를 파악하기 위해 끊임없이 노력합니다. 여러 주요 애플리케이션의 성능 및 인프라 메트릭을 추적하고 모니터링하여 이러한 작업을 수행합니다. 이러한 메트릭은 데브옵스 조직의 소프트웨어 개발자와 운영 엔지니어 모두와 관련되어야 합니다.

Apdex

Apdex는 웹 애플리케이션 및 서비스의 응답 시간에 대한 고객 만족도를 측정합니다. 특히 만족스러운 응답 시간과 불만족스러운 응답 시간의 비율을 측정합니다. 응답 시간은 고객이 요청할 때 시작되고 요청이 완료되면 종료됩니다.

애플리케이션에 대한 Apdex를 측정하려면 애플리케이션 'T'에서 먼저 성능 기준에 따라 응답 시간의 임계값을 정의해야 합니다.

Apdex는 세 가지 다른 수준에서 세 가지 응답 수를 추적합니다.

  1. 만족: 응답 시간이 T보다 작거나 같습니다.

  2. 허용: 응답 시간이 T보다 크고 4T보다 작거나 같습니다.

  3. 좌절: 응답 시간이 4T보다 큽니다.

예를 들어, T가 1.2 초이고 응답이 0.5초 내에 완료되면, 사용자는 만족한 것으로 간주됩니다. 1.2초를 초과하는 응답은 사용자가 불만족한 것으로 간주됩니다. 4.8초 이상의 응답은 사용자를 좌절하게 만든 것입니다.

이 메트릭을 추적하는 방법에 대한 보다 자세한 내용은 Apdex에 대한 이해 및 Apdex: 사용자 만족도 측정 비디오를 시청해보시기 바랍니다.

평균 응답 시간

응답 시간은 애플리케이션이 트랜잭션을 처리하는 데 걸리는 시간입니다. 이 메트릭은 고객이 웹사이트를 어떻게 경험하는지를 보여주는 좋은 지표입니다. 이 메트릭을 여러 위치에서 테스트하되, 사용자가 웹사이트 또는 앱과 상호작용하는 방법으로 테스트하는 것이 중요합니다. (예를 들어, 로그인 요청의 응답 시간은 파일 다운로드 응답 시간과는 다르기 때문에, 각 상호작용에 대해 응답 시간이 허용 가능한 범위 내에 있는지를 확인해야 합니다.)

뉴렐릭 APM의 기본 개요 페이지에는 웹 트랜잭션 시간 차트의 일부로 모든 애플리케이션에 대해 평균 응답 시간이 표시됩니다. 또한 NRQL 쿼리를 생성하여 뉴렐릭 Insights 위젯이 각 애플리케이션의 평균 응답 시간을 추적하도록 만들 수 있습니다.

일정 기간 동안 애플리케이션의 평균 응답 시간을 알고 싶다면, 뉴렐릭 API Explorer(v2)를 사용할 수 있습니다.

CPU 사용률(%)

CPU 사용양은 앱의 가용성을 추적하는 데 매우 중요한 측정치입니다. 온프레미스 환경에서 CPU 사용량이 증가하면 앱 성능이 저하되어 고객 경험에 문제가 발생할 수 있습니다. 그러나 클라우드를 사용하면서도 CPU 사용량을 극대화하고 있지 않다면, 지불되는 비용 만큼 리소스를 제대로 활용하지 않고 있을 가능성이 높습니다. 뉴렐릭 APM에서 CPU 사용률(%)은 특정 서버에 있는 앱 또는 서비스의 모든 인스턴스에 대한 CPU 사용량을 집계한 수치입니다. 뉴렐릭 Infrastructure에서는 호스트 또는 프로세스별 CPU 사용률을 나타냅니다. CPU 사용률(%) 메트릭은 기본적으로 수집되어 Infrastructure의 호스트 성능 차트에 표시됩니다.

또한 단일 호스트의 애플리케이션의 경우, 뉴렐릭 REST API(v2)를 사용해 평균 CPU 사용량을 확인할 수 있습니다.

오류율

일반적으로 처리되지 않은 예외는 오류로 간주됩니다. 오류율은 특정 기간 동안 오류를 야기한 트랜잭션의 비율을 추적합니다. 예를 들어, 특정 기간 동안 애플리케이션이 1,000건의 트랜잭션을 처리하고, 그 중 50건이 처리되지 않은 예외였다면, 오류율은 50/1000, 즉 5%입니다.

뉴렐릭은 APM 오류율 차트, 뉴렐릭 Browser 자바스크립트 오류 분석 등 주요 오류율을 추적할 수 있는 다양한 방법을 제공합니다.

로드 평균

이 메트릭은 CPU를 위해 대기 상태 및 준비 상태에 있는 시스템 프로세스, 스레드 또는 작업의 평균 수를 측정합니다. 로드 평균을 모니터링하면, 시스템이 과부하되었는지 또는 지나치게 많은 리소스를 소비하는 프로세스가 있는지를 이해하는 데 도움이 됩니다. 뉴렐릭 Infrastructure를 사용하면, 1분, 5분 또는 15분 간격으로 로드 평균을 추적할 수 있습니다. 데이터는 Infrastructure 호스트 페이지에 표시됩니다.

메모리 사용률(%)

호스트에서 메모리를 너무 많이 사용하면 애플리케이션 성능이 저하될 수 있지만, 클라우드에서 메모리를 너무 적게 사용하고 있다면 고비용의 리소스를 충분히 활용하지 못하고 있는 것입니다.

메모리 사용률은 사용 가능한 메모리 바이트 양을 인프라의 각 호스트에 사용된 메모리 바이트 양과 비교한 것입니다. 메모리 사용률 메트릭은 기본적으로 수집되며, Infrastructure의 호스트 성능 차트에 표시됩니다.

단일 호스트 애플리케이션의 경우, 뉴렐릭 REST API(v2)를 사용해 평균 메모리 사용량을 확보할 수 있습니다.

처리량

처리량은 모니터링되는 애플리케이션의 사용자 활동을 측정합니다. 뉴렐릭 APM에서 처리량은 애플리케이션에 대한 분당 RPM(요청)을 추적합니다. 예를 들어, 처리량을 추적하면 새로운 기능이나 개선 사항 또는 아키텍처 변경으로 인해 애플리케이션이 요청을 처리하는 방식이 변경되었는지를 확인할 수 있습니다.

웹 애플리케이션 및 비웹 애플리케이션 처리량이 포함된 앱의 경우, 뉴렐릭 REST API(v2)를 사용해 평균 처리량을 확인할 수 있습니다. 이 수치는 APM의 앱 개요 페이지에 있는 처리량 차트에 표시됩니다.

안정성 및 시스템 상태에 대한 데브옵스 측정

데브옵스 팀은 몇 가지 주요 메트릭을 사용해 시스템의 안정성, 품질 및 전반적인 상태를 추적할 수 있습니다. 데브옵스 조직에서는 사이트 안정성 엔지니어, 운영 엔지니어, 소프트웨어 개발자, 프로젝트 관리자 및 엔지니어링 리더십이 모두 이러한 측정에서 가치를 찾을 수 있습니다.

결함 측정 지표

이 메트릭은 운영 중인 소프트웨어에서 보고된 문제나 버그의 수, 또는 소프트웨어 배포 중에 발생하는 문제를 추적합니다. 이러한 문제는 인프라, 애플리케이션, 모바일 앱 또는 브라우저에서 발생할 수 있습니다. 결함은 일반적으로 버그 티켓 또는 지원 티켓의 형태로 추적됩니다.

뉴렐릭을 Atlassian JIRA, Lighthouse 또는 Pivotal Tracker 등의 ‘버그 추적' 시스템과 통합하면, 뉴렐릭에서 발견된 성능 문제에 대한 티켓, 문제 및 스토리를 빠르게 생성할 수 있습니다.

평균감지시간(MTTD)

이 메트릭은 문제의 시작과 문제 감지 사이에 걸린 시간, 그리고 조치가 취해진 시점을 추척합니다. 데브옵스 팀은 MTTD를 가능한 한 짧게 유지해야 합니다. 팀 전체에 적절한 계측, 경고 및 알림 채널이 마련되어 있으면, 감지된 오류에 더욱 신속하게 대응할 수 있습니다.

MTTD에는 실제로 문제를 해결하는 데 필요한 시간은 포함되지 않습니다.

뉴렐릭 Alerts를 사용해 조건 및 알림 정책을 설정하면, 개발자, 운영 담당자 및 소프트웨어 소유자가 최신 상황을 인지하고 문제 발생 시 즉각적인 조치를 취할 수 있습니다. 알림은 오류 감지와 문제 예방에 대한 소통을 지원하는 Slack 또는 PagerDuty 같은 notification 솔루션과 함께 사용할 때 특히 유용합니다.

평균복구시간(MTTR)

MTTR은 장애가 감지된 순간부터 시스템이 다시 정상적으로 작동하는 시점까지 고장난 구성요소를 수리하는 데 걸리는 평균 시간을 추적합니다. 이 메트릭을 사용하면 복구 프로세스에서 커뮤니케이션 메커니즘을 측정하고 개선할 수 있습니다. 직접적인 통신 채널이 있는 경우, 수정 사항을 보다 신속하게 파악, 테스트, 검증 및 배포하여 시스템의 다운타임을 최소화할 수 있습니다.

예를 들어, 뉴렐릭 Infrastructure는 호스트 성능의 변경 사항을 인프라의 구성 변경 사항에 연결함으로써 MTTR 감소에 도움을 주는 실시간 메트릭을 수집합니다. 시스템에 영향을 미칠 수 있는 잠재적인 문제를 파악하기 위해 수집하는 Infrastructure 메트릭에 뉴렐릭 Alerts를 설정할 수 있습니다.

서비스 수준 계약(SLA)

단일 개발 팀을 관리하든, 전체 조직을 관리하든, SLA는 기업과 사용자 또는 고객 간에 적용되는 (때로는 법적 구속력이 있는) 계약입니다.

Apdex, 평균 응답 시간 등, 이 가이드에서 설명하는 몇 가지 메트릭은 모두 SLA에 포함되어야 합니다. 뉴렐릭 APM은 애플리케이션 성능을 더 잘 이해할 수 있도록 시간 경과에 따른 애플리케이션의 다운타임과 트렌드를 추적한 SLA 보고서를 제공합니다. 또한 APM의 주요 트랜잭션과 Synthetics 모니터에 대한 SLA 보고서를 제공합니다.

서비스 수준 목표(SLO)

SLO는 가용성, 성능, 오류율 및 기타 합의된 모든 측정에서 기업과 고객이 시스템에서 기대할 수 있는 사항을 정해 놓은 팀의 목표입니다. SLO에는 팀이 실제로 지원하기로 약속한 내용, 조직이 실제로 지원하기로 약속한 내용, 기술적 현실을 기반으로 실제로 지원할 수 있는 내용이 반영되어야 합니다. 예를 들어, API 서비스를 제공하는 팀의 SLO에는 잘 구성된 페이로드 99.99%를 허용한다고 명시될 수 있습니다.

물론 SLO는 시간이 지남에 따라 변경될 수 있습니다. 예를 들어, 시스템이 미숙한 경우 비교적 간단한 SLO로 시작하여 시간이 지남에 따라 SLO를 늘리는 것이 좋습니다.

뉴렐릭은 기본 애플리케이션 및 인프라의 상태 메트릭을 측정하여 CPU 사용률, 가용성, 오류율, 평균 응답 시간 등을 포괄하는 SLO를 설정할 수 있는 효과적인 방법을 제공합니다.

팀 상태를 위한 데브옵스 측정

성공적인 데브옵스 조직은 단순히 기술 메트릭을 추적하는 것이 아니라, 팀의 상태와 성과의 측정치도 고려합니다. 이러한 측정은 데브옵스 조직의 소프트웨어 개발자, 운영 엔지니어, 프로젝트 관리자 및 엔지니어링 리더십에 특히 중요합니다.

코드 커밋

아티팩트를 프로덕션에 배포하기 전에 개발 라이프사이클에 있는 아티팩트에 대해 팀이 수행하는 커밋을 추적함으로써, 이 메트릭은 팀 속도와 코드 품질을 나타내는 지표로 사용될 수 있습니다. 커밋이 너무 많거나 반대로 충분하지 않은 경우, 팀 구성원이 프로젝트를 제대로 관리하지 못하고 있을 수 있습니다. 예를 들어, 커밋 수가 많다는 것은 문제 해결 방향이 명확하지 않아 팀원들이 해결책을 찾기 위해 계속 애를 쓰고 있음을 의미할 수 있습니다. 커밋이 너무 적으면 다른 의무 사항이나 노력으로 인해 정작 중요한 작업에는 집중하지 못하고 있음을 의미할 수 있습니다.

뉴렐릭의 Insights API를 사용해 각 git 커밋에 대한 커스텀 이벤트를 생성하고, NRQL 쿼리로 이를 추적해 대시보드에 결과를 표시할 수 있습니다. 또한 뉴렐릭 Rest API v2을 사용해 배포를 기록함으로써 커밋을 추적할 수 있습니다. 

배포 시간 및 배포 빈도

신속한 반복과 연속 배포(소프트웨어 배포에 걸리는 시간과 배포 빈도)는 데브옵스의 성공을 나타내는 간접적인 측정치로 간주됩니다. 데브옵스 전문가이자 데브옵스 핸드북의 공동 저자인 진 킴은 이러한 메트릭이 데브옵스 조직의 긍정적인 결과와 연관이 있다고 생각합니다.

뉴렐릭 REST API v2를 사용하면, 새로운 배포를 기록하고, 이전 배포 목록을 검색하며, 이전 배포를 삭제할 수 있습니다. 일부 에이전트에는 에이전트별로 배포를 자동으로 기록하는 방법도 있습니다. 기록된 배포는 APM 배포 페이지와 개요 페이지의 최근 이벤트 목록에서 확인할 수 있습니다. New Relic APM의 배포 페이지 목록은 최근에 이루어진 배포, 배포 일시, 배포가 엔드유저 및 앱 서버의 Apdex 점수에 미치는 영향, 응답 시간, 처리량 및 오류를 표시합니다. 세부 정보 조회 및 분석, 검색 및 정렬, 오류 숨기기 또는 삭제, 정보 공유, 오류에 대한 지원 티켓 신청도 가능합니다.

반복 길이

이 메트릭을 사용하면 프로젝트를 실행하는 동안 개발 주기 간에 소요된 시간을 추적할 수 있습니다. 최신 애자일 워크플로우에서 개발 주기는 일반적으로 1~2주 동안 지속되며, 각 주기(스프린트)는 계획 및 회고로 표시됩니다. (팀은 각 스프린트 후에 출시 가능한 아티팩트가 있을 수도 있고 없을 수도 있습니다.) 반복 길이를 추적하면 프로젝트의 범위, 팀의 속도 및 워크로드, 프로젝트 진전에 따른 변경 사항에 적응하는 팀의 능력을 더 잘 이해할 수 있습니다.

통과/실패한 유닛 테스트

유닛은 테스트할 수 있는 소프트웨어의 가장 작은 구성 요소입니다. 개발 주기 동안 통과하거나 실패한 유닛 테스트의 수를 추적하면, 팀이 코드를 잘 설계하고 있는지를 확인할 수 있습니다.

예를 들어, PHPUnit을 사용해 유닛 테스트를 관리하고 실행하는 경우, 뉴렐릭 PHP 에이전트는 자동으로 테스트 요약 결과를 수집하여 테스트 데이터를 한 눈에 쿼리 및 시각화할 수 있는 하나의 이벤트로 뉴렐릭 Insights로 전송합니다.

또 다른 접근 방식은 NRQL 쿼리를 사용해, 통과/실패한 유닛 테스트를 추적하는 대시보드 위젯을 생성하는 것입니다.

프로젝트 리드 타임

평균 변경 시간(MTTC)이라고도 하는 이 메트릭은 프로젝트 시작과 해당 프로젝트 아티팩트의 실제 프로덕션 배포 사이의 시간을 캡처합니다. 이는 비즈니스가 발전함에 따라 변화에 적응하는 팀의 능력을 측정하는 데 도움이 될 수 있습니다.

프로젝트 리드 타임을 추적하는 한 가지 방법은, Insights API를 사용해 각 git 커밋에 대해 커스텀 이벤트를 생성한 후, NRQL 쿼리를 사용해 대시보드 위젯을 만드는 것입니다.

데브옵스 여정을 측정할 준비가 되셨습니까?

데브옵스로 전환하는 단계에 관계없이(시작 단계인든, 소규모 파일럿에서 성공을 거두었든, 전체 데브옵스를 운영하는 단계이든), 뉴렐릭 플랫폼은 진행 상황을 추적하고 데브옵스 작업을 최적화할 수 있습니다. 보다 자세한 내용은 뉴렐릭을 사용해 데브옵스 여정을 측정하는 방법을 안내하는 기술 튜토리얼 데브옵스 성공 측정 가이드을 확인하시기 바랍니다.

현대적인 데브옵스 toolset

뉴렐릭은 데브옵스 작업에 필요한 많은 중요한 기술 중 하나에 불과합니다.

Devops