응답 시간 모니터링

응답 속도가 별도의 알림을 받을 만한 이유

표준 가동 시간 알림은 이진 신호(업/다운)에 의존합니다. 그 사이의 회색 지대, 즉 "업이긴 한데 느림"은 실제로 대부분의 최신 장애가 발생하는 곳입니다. 잘못 구성된 데이터베이스 쿼리는 50ms 대신 4초가 걸리기 시작합니다. 메모리 누수로 인해 garbage collection이 급격히 증가합니다. 백엔드가 호출하는 외부 API가 불안정해집니다. 이 중 어떤 것도 사이트를 완전히 망가뜨리지는 않지만, 사용할 수 없게 만듭니다. 그리고 이는 1~2시간 뒤에 올 실제 장애의 초기 신호입니다.

응답 시간 모니터링은 장애로 이어지기 전 느려짐을 포착합니다. 각 모니터마다 임계값을 설정할 수 있고, 응답 시간이 연속 여러 번 임계값을 초과하면 알림을 받게 됩니다. 알림이 오기 전에도 어느 정도 여유가 있어서 원인을 조사하거나, 스케일을 늘리거나, 문제 호출을 제한하거나, 문제가 된 배포를 롤백할 수 있습니다.

DiagnoSEO Uptime Monitoring의 임계값 작동 방식

각 모니터는 rt_threshold_ms와 rt_threshold_breaches 두 가지 파라미터로 설정할 수 있습니다. 첫 번째는 허용 가능한 응답 시간(밀리초)입니다. 두 번째는 알림을 보내기 위해 연속적으로 몇 번을 초과해야 하는지입니다. 기본적으로 임계값은 비활성화되어 있고, 초과 횟수는 세 번입니다.

이중 파라미터 디자인은 오탐 방지에 도움을 줍니다. 네트워크 지터가 발생할 수 있습니다. garbage collection 일시 중지도 발생할 수 있습니다. 평소 200ms에서 1초로 한 번 튀는 경우 새벽 3시에 호출받을 일은 아닙니다. 그러나 세 번 연속 1초라면, 이것은 일시적 현상이 아니라 지속되는 느려짐입니다. 평소의 행태와 여유 마진을 기준으로 임계값을 선택하세요. p95가 보통 400ms라면 1000ms, p95가 50ms(내부 API)라면 200ms.

어떤 신호와 조합하면 좋은가

응답 시간 알림은 다른 모니터 신호와 함께 쓸 때 가장 효과적입니다. 전체적인 그림: 응답 시간 임계값은 시스템이 점점 느려진다는 신호를 주고, HTTP 코드는 실제로 깨졌을 때를 알려주며, SSL/도메인 경고는 만료 장애를, DNS 변경 알림은 설정 드리프트를 알립니다. 이 네 가지 신호를 한 모니터에 합치면 단순한 “동작/비동작” 대신 풍부한 관측성을 얻을 수 있습니다.

대시보드 역시 도움이 됩니다. 각 모니터는 최근 응답 시간을 sparkline으로 보여주고, 즉각적인 속도 저하 패턴도 시각적으로 확인할 수 있습니다. 확장된 뷰에서는 24시간, 7일, 30일 평균 응답 시간을 볼 수 있습니다. 만약 주차별로 평균값이 점점 올라간다면, 임계값 알림이 뜨기 전 조사해볼 만한 조기 신호입니다.

페이지 유형별 실전 임계값

• 마케팅 랜딩 페이지: 1500ms가 합리적입니다. 이미지와 추적 스크립트가 많기 때문에 절대적 속도보다는 안정성이 더 중요합니다.
• 이커머스 상품/카테고리 페이지: 800~1200ms. 느린 이커머스는 전환을 저하시킵니다. 더 낮은 임계값으로 더 빠르게 문제를 포착하세요.
• 앱 대시보드: 500~800ms. 사용자는 즉각적인 반응을 기대합니다. 느린 대시보드는 제품이 고장난 것처럼 보입니다.
• 퍼블릭 API: 단순 endpoint는 200~400ms, 연산이 많은 것은 더 높게. 티어를 나누세요.
• 내부 마이크로서비스 헬스 체크: 50~100ms. 거의 즉시 응답이 필요하며, 느리면 거의 항상 진짜 문제입니다.

무엇을 선택하든 한 번 정하고 잊지 마세요. 실제로 보이는 트렌드를 기준으로 분기마다 다시 평가하세요. 임계값 초과 알림을 자주 받는데 실제 문제가 아니라면 임계값이 너무 촘촘한 것입니다. 반대로 사전 알림 없이 장애가 발생한다면 임계값이 너무 느슨했던 것입니다.

알림 라우팅

임계값 초과 알림은 다운/복구 알림과 동일한 채널로 전달됩니다: Email, Telegram, Slack, Discord, SMS. 동일한 야간 조용 시간도 적용됩니다. 같은 알림 테이블에 기록됩니다. 단지 이벤트 타입("threshold" 대신 "down")과 메시지 내용만 다르며, 현재 응답 시간과 설정된 임계값이 포함되어 있어 한눈에 얼마나 초과했는지 알 수 있습니다.

설정 방법

모든 모니터를 편집할 수 있습니다. 폼에서 "응답 시간 임계값 (ms)"에 원하는 값을 입력하세요. 기본값 3회가 맞지 않으면 "연속 초과 횟수"도 조정하세요. 저장하세요. 다음 점검부터는 각 측정값이 임계값과 비교되고, 설정한 횟수만큼 연속으로 초과하면 알림이 발송됩니다.

자주 묻는 질문

• 어떤 응답 시간 지표가 기록되나요?

  Time To First Byte (TTFB) — 요청을 보낸 순간부터 첫 바이트가 수신될 때까지 걸린 밀리초. 여기에 전체 응답을 모두 받는 데 소요된 총 시간도 포함됩니다. 서버 헬스 상태에서 TTFB가 가장 실용적인 단일 지표입니다.

• "좋은" 응답 시간이란 얼마인가요?

  위치와 콘텐츠에 따라 다릅니다. CDN 기반 정적 사이트의 경우 100ms 이하는 매우 빠르고, 300ms 이하는 괜찮습니다. 동적 애플리케이션은 500ms 이하면 우수, 1000ms 이내면 허용, 2000ms를 넘기면 느려 보입니다. 절대값보다는 본인 사이트의 과거 평균과 비교하세요.

• 응답 시간이 임계값을 넘기면 알림받을 수 있나요?

  네. 각 모니터마다 응답 시간 임계값을 선택할 수 있습니다. 연속 3회 체크에서 임계값 초과 시 "slow response" 알림이 발송됩니다. 3회 체크 조건이 있어 단발성 네트워크 이상에 따른 오탐을 막아줍니다.

• 응답 시간은 어디서 측정하나요?

  저희의 13개 지리적 체크 포인트(유럽, 북미, 아시아, 남미, 오세아니아)에서 측정됩니다. 단일 리전 모니터의 경우 가장 가까운 위치에서 시간 측정. 멀티 리전은 각 지역이 독립적으로 측정되어, 지역별 CDN 문제 파악에 유용합니다.

• 대시보드에서 응답 시간 트렌드를 볼 수 있나요?

  네 — 30일간 이동 평균, 일별 최대/최소 및 퍼센타일(p50, p95)이 제공됩니다. 용량 계획에 유용합니다. 만약 p95가 한 달 만에 800ms에서 1500ms로 늘었다면, 가동률이 100%여도 서버는 이미 과부하 상태일 수 있습니다.