7분 만에 지연 시간을 적절하게 측정하는 방법

지연 시간을 적절하게 측정하려면 양질의 데이터가 필요합니다. KPMG의 2016년 글로벌 CEO 전망(ibm.com 외부 링크)에 따르면 CEO의 84%가 의사 결정의 근거로 사용하는 데이터의 품질에 대해 우려하고 있으며, 그 이유는 데이터가 종종 오해의 소지가 있기 때문인 것으로 나타났습니다.

데이터에 관심을 갖는 기업과 그렇지 않은 기업의 차이는 엄청납니다. MIT 연구원들은(ibm.com 외부 링크) 데이터 기반 설계를 채택한 기업이 다른 투자와 정보 기술 사용을 고려할 때 예상했던 것보다 5~ 6% 더 높은 아웃풋을 보인다는 사실을 발견했습니다. 이러한 이유만으로도 지연 시간을 이해하는 것은 비즈니스 성공에 매우 중요합니다.

단 7분 만에 지연 시간 측정에 대해 알아야 할 모든 것을 배울 수 있습니다.

• 지연 시간 측정 방법
• 적절한 측정이 중요한 이유
• 지연 시간 데이터를 확인할 때의 일반적인 함정
• 즉각적인 피드백의 중요성
• 샘플링되지 않은 데이터가 필요한 이유

Dictionary.com(ibm.com 외부 링크)은 지연 시간을 “하드웨어 시스템의 한 구성 요소가 다른 구성 요소에 의해 작업이 실행되기를 기다리는 지연 시간”으로 정의합니다. 간단히 말해서 함수 호출과 실제 실행 사이의 시간을 의미합니다. 지연 시간은 모든 시스템에 내재되어 있습니다. 완벽한 시스템이 존재하지 않는다고 해도 컴퓨터의 전자가 트랜지스터를 켜기에서 끄기로 또는 그 반대로 전환하는 데 걸리는 시간만큼 지연 시간이 존재합니다.

소규모 작업의 지연 시간은 큰 문제가 되지 않지만 수백만 개의 작업을 처리할 때는 수백만 개의 지연 시간이 빠르게 누적됩니다. 지연 시간은 작업 단위와 시간으로 정의되는 것이 아니라 작동 방식에 따라 정의됩니다. 모니터링 툴은 함수 시작부터 함수 종료까지 걸리는 시간을 다시 보고합니다.

지연 시간은 비즈니스에 큰 영향을 미칠 수 있습니다. 예를 들어(ibm.com 외부 링크): “모바일 속도에서는 매초가 중요합니다. 모바일 페이지를 로드하는 데 1초가 더 걸릴 때마다 전환율이 최대 20%까지 떨어질 수 있습니다.”

지연 시간은 거의 정상적인 가우스 또는 포아송 분포를 따르지 않습니다. 지연 시간이 이러한 분포 중 하나를 따른다고 해도 지연 시간을 관찰하는 방식 때문에 평균, 중앙값, 심지어 표준 편차까지 무용지물이 됩니다. 예를 들어 페이지 로드를 측정하는 경우 99.9999999999% 로드가 중앙값보다 나쁠 수 있습니다. 무작위로 지연을 샘플링하면 데이터가 부정확해지는 이유도 여기에 일부 포함됩니다. 이 주제에 대해서는 뒤에서 더 자세히 설명하겠습니다.

이쯤 되면 표준 편차를 사용하지 않는다면 지연 시간을 어떻게 의미 있게 설명할 수 있을지 의문이 들 수 있습니다. 답은 백분위수와 최댓값을 살펴봐야 한다는 것입니다. 대부분의 사람들은 이렇게 생각합니다. “좋아, P95를 보면 ‘일반적인 경우’를 이해할 수 있겠구나.” 이 방법의 문제점은 P95가 모든 나쁜 내용을 숨긴다는 것입니다. Azul Systems의 CTO인 Gil Tene는 다음과 같이 말합니다. “이것은 '마케팅 시스템'입니다. 누군가 속고 있습니다."

다음 그래프를 예로 들어 보겠습니다.

이 그래프를 보면 중앙값과 평균이 실제 의미가 없는 이유를 명확하게 알 수 있습니다. 95번째 백분위가 왼쪽으로 급격히 치솟는 것을 보면, 문제의 핵심을 보고 있다고 생각하게 됩니다. 물론, 그건 사실이 아닙니다. 프로그램이 왜 갑자기 딸꾹질(일시적 멈춤)이 있었는지 조사할 때, 여러분은 발생한 일 중 가장 나쁜 5%를 보지 못하고 있는 것입니다. 이런 종류의 스파이크가 나타나려면, 데이터의 상위 5%가 상당히 더 나빠져야 합니다.

이제 99.99번째 백분위수를 보여주는 동일한 그래프를 살펴보세요.

빨간색 선은 95번째 백분위수이고 녹색 선은 99.99번째 백분위수입니다. 보시다시피, 95번째 백분위는 22개의 문제 중 단 2개만 보여줄 뿐이며, 그렇기 때문에 전체 데이터를 모두 살펴봐야 합니다.

많은 사람들은 데이터의 마지막 5%가 그다지 중요하지 않다고 생각할 수 있습니다. 물론, 이것이 단순히 가상 머신(VM) 재시작이거나 시스템의 작은 딸꾹질(일시적 멈춤)일 수도 있습니다. 하지만 이를 무시한다는 것은, 실제로는 가장 먼저 해결해야 할 중요한 문제일 수도 있음에도 불구하고, 그런 일은 일어나지 않는다고 간주하는 것과 같습니다.

Gil Ten은 다음과 같이 말합니다. "절대 제거해서는 안 되는 가장 중요한 지표는 최댓값입니다. 이는 노이즈가 아니라 신호입니다. 나머지는 소음입니다." 최댓값은 실제로 대규모 시스템에서 훌륭한 단일 값이지만 최댓값만 추구하는 것은 종종 실용적이지 않습니다. 완벽한 시스템은 없으며 딸꾹질은 발생하기 마련입니다. 대규모 실용 시스템에서는 최대 사례만 추구하는 것이 개발팀을 소진시키는 좋은 방법인 경우가 많습니다.

99.99번째 백분위를 볼 때는 대부분의 고객에게 어떤 일이 발생하는지를 확인하는 것이며, 그 지점에서 보이는 스파이크는 실제 문제라는 것을 알 수 있는 반면, 최댓값에서 보이는 스파이크는 시스템에서 발생한 작은 일시적 이상일 수 있습니다. DevOps 팀이 이러한 작은 일시적 이상에 노력을 집중하면, 더 큰 문제를 해결하지 못하게 되어 큰 기회비용이 발생합니다.

99.99번째 백분위와 최댓값이 매우 가깝고 둘 다 스파이크가 발생했다면, 이는 팀이 반드시 해결해야 할 문제라는 강력한 신호입니다. 이런 의미에서 최댓값이 좋은 신호라는 점은 Gil이 맞지만, 나머지 데이터가 단순한 잡음이라는 주장은 잘못되었습니다. 이 그래프에서 보듯, 이전 예시의 99.99번째 백분위와 최대값은 정확히 일치합니다. 이는 보고 있는 것이 단순한 일시적 이상이 아니라 실제 버그라는 강력한 신호입니다.

사람들이 95번째 백분위수를 보는 것보다 더 나쁜 함정은 자신의 백분위수가 평균이라는 것을 인식하지 못하는 것입니다. 백분위수를 평균하는 것은 통계적으로 터무니없으며, 보고 있는 데이터에서 모든 의미를 제거합니다. 우리는 이미 평균값이 지연을 살펴볼 때 적절하지 않다는 것을 보여드렸으며, 평균화된 백분위수를 보고 있다면 결국 다시 원점으로 돌아가는 것일 뿐입니다. 많은 소프트웨어 프로그램은 백분위수의 평균을 구합니다. 다음 Grafana 차트를 예로 들어 보겠습니다.

이전에 깨달았든 깨닫지 못했든 이 차트의 모든 백분위수는 평균입니다. x축 원장에 바로 그렇게 나와 있습니다. 거의 모든 모니터링 서비스는 백분위수를 평균화합니다. 이는 사전 계산 때문에 발생하는 현실입니다. 모니터링 서비스에서 데이터를 수신하면 해당 분의 데이터 백분위수를 계산합니다.

그런 다음 95번째 백분위수를 보면 모든 백분위수의 평균을 보여줍니다. 서비스를 더 빠르게 만들기 위한 이 '좋은' 지름길은 실제로는 데이터에서 모든 통계적 유의성을 제거하는 것입니다.

알든 모르든, 데이터 샘플링 방식으로 동작하는 모니터링 툴들은 결국 평균화된 데이터를 만들어냅니다. 거의 모든 모니터링 툴은 데이터를 샘플링합니다. 예를 들어 Datadog에는 심각한 데이터 손실이 있습니다. 1분 동안 300만 개의 포인트를 보내더라도, 그 툴들은 그 모든 데이터를 받아들이지 않습니다. 대신 포인트를 무작위로 샘플링한 다음 분당 1포인트로 집계합니다.

지연 시간을 정확히 이해하려면 비샘플링 데이터가 반드시 필요합니다. 샘플링된 데이터로는 전체 분포에 접근할 수 없다는 점은 구조적인 한계입니다. 샘플링된 데이터의 최댓값은 실제 최댓값이 아니며, 글로벌 백분위도 실제 상황을 정확하게 보여주지 못합니다.

데이터를 샘플링하면 데이터가 누락됩니다. 예를 들어, 1분에 10,000개의 작업이 발생하고 각각 2개의 데이터 포인트를 모니터링 시스템으로 전송한다고 가정해 보겠습니다. 시스템에 버그가 있고 이러한 데이터 요소 중 하나가 10,000개의 작업당 이 버그를 표시한다고 가정해 보겠습니다. 모니터링 시스템은 이 버그를 최댓값으로 표시하는 데이터 포인트로 선택할 확률이 1/20,000에 불과합니다.

충분히 오랫동안 실행하면 그 데이터 포인트는 결국 나타나겠지만, 그 결과 마치 드문 예외 사례처럼 보이게 됩니다. 비록 실제로는 매분마다 고객 한 명에게 일어나고 있음에도 말이죠. 데이터를 샘플링하지 않은 상태에서 이러한 스파이크 중 하나가 발생하면 99.99번째 백분위수에 명확하게 표시되고 최댓값이 그 근처에 표시되어 프로그램에 버그가 있음을 알립니다. 하지만 데이터를 샘플링하면 그 값이 자주 나타나지 않기 때문에, 이를 버그가 아니라 일시적 딸꾹질(일시적 멈춤) 정도로 보게 됩니다. 이 결과는 엔지니어링 팀이 그 중요성을 깨닫지 못한다는 것을 의미합니다.

모니터링 툴이 지연에서 무슨 일이 일어나고 있는지 알고 있다고 착각하게 만들지 않도록 하세요. IBM Instana 소프트웨어의 주요 기능 중 하나는 지연 시간을 효율적으로 측정할 수 있다는 것입니다. IBM Instana 소프트웨어는 고급 분석 및 머신 러닝(ML)을 사용하여 지연 시간 문제를 실시간으로 자동 감지하므로 개발자와 IT 팀은 성능 문제의 근본 원인을 신속하게 파악하고 사용자에게 영향을 미치기 전에 시정 조치를 취할 수 있습니다.

샘플링된 데이터를 제공하지 않는 툴을 선택하세요. 글로벌 백분위수의 평균을 구하지 않는 툴을 선택하세요.