• 로그인지금 시작하기

사용자의 편의를 위해 제공되는 기계 번역입니다.

영문본과 번역본이 일치하지 않는 경우 영문본이 우선합니다. 보다 자세한 내용은 이 페이지를 방문하시기 바랍니다.

문제 신고

신뢰성 엔지니어링 진단: 애플리케이션 성능 문제 해결을 위한 초보자 가이드

이 가이드는 고객에게 영향을 미치는 문제를 진단하는 기술을 향상시키는 방법을 소개합니다. 이 가이드의 절차를 따르면 애플리케이션 성능 문제를 보다 빠르게 복구할 수 있습니다.

이 가이드는 관찰 가능성 성숙도에 대한 시리즈 의 일부입니다.

전제 조건

이 가이드를 사용하기 위한 몇 가지 요구 사항과 권장 사항은 다음과 같습니다.

원하는 결과

요약

비즈니스 가치는 다음과 같습니다.

  • 업무 중단 사고의 수 감소
  • 문제 해결에 필요한 시간 단축(MTTR)
  • 사고의 운영 비용 절감

IT 운영 및 SRE의 가치는 다음과 같습니다.

  • 이해하고 해결하는 시간 단축

사업성과

Gartner는 IT 다운타임의 평균 비용이 분당 $5,600라고 추정 합니다. 비즈니스에 영향을 미치는 사고의 누적 비용은 파악 시간, 빈도, 수리 시간, 수익 영향, 사고를 분류하고 해결하는 엔지니어 수와 같은 요인에 따라 결정됩니다. 간단히 말해서, 성능에 미치는 영향을 해결하는 데 필요한 인력이 줄어들면서 비즈니스에 영향을 미치는 사고가 줄어들고 사고 기간이 단축되고 진단이 빨라지기를 원합니다.

궁극적으로 비즈니스 목표는 가동 시간을 최대화하고 가동 중지 시간 비용이 다음과 같은 가동 중지 시간을 최소화하는 것입니다.

Downtime minutes x Cost per minute = Downtime cost

다운타임은 비즈니스 중단 사고의 수와 기간에 따라 결정됩니다. 다운타임 비용에는 많은 요소가 포함되지만 가장 직접적으로 측정할 수 있는 것은 운영 비용과 수익 손실입니다.

비즈니스는 다음을 줄여야 합니다.

  • 업무에 지장을 주는 사건의 수
  • 사고의 운영 비용

운영 결과

필요한 운영 결과는 제품 계층 서비스 수준 목표 준수를 유지하는 것입니다. 저하된 서비스 수준을 진단하고, 진단 내용을 전달하고, 신속한 해결을 수행하여 이를 수행합니다. 그러나 예상치 못한 성능 저하와 사고는 항상 발생하므로 신속하고 효과적으로 대응해야 합니다.

이 시리즈의 다른 가이드에서는 알아야 할 시간을 개선하는 데 중점을 둡니다. 경보 품질 관리 가이드 에서는 파악 시간을 개선하기 위한 사후 대응 방법에 중점을 두고 있으며 서비스 수준 관리 가이드 에서는 사전 예방적 방법에 중점을 둡니다.

지금 읽고 있는 가이드에서는 이해하는 데 걸리는 시간과 해결 하는 데 걸리는 시간을 개선하는 데 중점을 둡니다.

핵심 성과 지표 - 운영

"사고 관리" 및 SRE 이론의 세계에서 많은 메트릭이 논의되고 논의됩니다. 그러나 대부분은 핵심 성과 지표의 작은 집합에 집중하는 것이 중요하다는 데 동의합니다.

아래 KPI는 성공적인 SRE 및 인시던트 관리 관행에 사용되는 가장 일반적인 지표입니다.

신뢰성에 대한 최종 사용자의 인식

고객이 제품의 성능을 인식하는 방법은 긴급성과 우선 순위를 측정하는 방법을 이해하는 데 중요합니다. 또한 고객의 관점을 이해하면 비즈니스에서 문제를 보는 방식을 이해하고 영향을 받는 기능을 지원하는 데 필요한 워크플로를 이해하는 데 도움이 됩니다. 고객과 비즈니스에 대한 인식을 이해하면 해당 기능의 안정성에 영향을 미칠 수 있는 요소를 더 잘 이해할 수 있습니다.

궁극적으로 고객 관점의 관찰 가능성은 신뢰성 엔지니어링에서 능동적이고 능숙해지기 위한 첫 번째 단계입니다.

디지털 제품의 성능과 기능에 대한 최종 사용자의 인식에 영향을 미치는 두 가지 주요 경험이 있습니다. 아래 용어는 공통 고객 언어를 사용하는 고객의 관점에서 작성된 것입니다.

가용성, 일명 "작동하지 않음"

가용성은 연결성, 가동 시간, 도달 가능성이라고도 합니다. 그러나 그것은 또한 성공(비 오류)과도 관련이 있습니다.

최종 사용자는 로그인, 찾아보기, 검색, 인벤토리 보기와 같은 필수 기능에 액세스할 수 없다고 말할 수 있습니다. 또는 단순히 전체 서비스를 사용할 수 없다고 명시할 수도 있습니다. 이것은 서비스에 연결할 수 없거나 오류를 반환하는 서비스의 증상입니다.

전통적으로 "가용성" 또는 "가동 시간"은 서비스 연결 능력을 측정함으로써 이진 "UP/DOWN" 방법론으로 측정되었습니다. 기존의 방법은 전체 서비스를 완전히 사용할 수 없게 된 경우에만 측정한다는 점에서 중요한 격차가 있습니다. 신뢰성에 대한 이 고전적인 측정은 상당한 관찰 가능성 격차, 어려운 진단 및 최종 사용자가 대응하기 전에 심각한 영향을 받는 결과를 낳습니다.

가용성은 "가동 시간"이라고도 하는 "서비스에 도달할 수 있는 능력"과 "예상된 응답을 반환하는 서비스 능력"(즉, "오류 없음")으로 측정됩니다. New Relic의 관찰 가능성 성숙도 프레임워크는 입력 성능 (연결성)과 출력 성능 (성공 및 응답 지연)으로 둘을 구분합니다.

성능, 일명 "너무 느림"

성능은 대기 시간 및 응답 시간이라고도 합니다.

최종 사용자는 서비스가 너무 느리다고 말할 수 있습니다.

IT 리더와 비즈니스 리더 모두에게 "성능"이라는 용어는 일련의 문제를 포괄할 수 있습니다. New Relic의 서비스 수준 관리에서 "느림"은 "출력" 및 "클라이언트" 범주 모두에서 측정됩니다. 그러나 대부분의 속도 저하 문제는 전통적으로 "백엔드 서비스"라고 하는 출력 문제로 인해 발생합니다.

근본 원인 대 문제(직접 원인)

문제의 근본 원인은 문제와 동일 하지 않습니다 . 마찬가지로, 문제를 수정한다고 해서 일반적으로 문제의 근본 원인을 수정했다는 의미는 아닙니다. 이 구분을 하는 것은 매우 중요합니다.

성능 문제를 찾을 때 먼저 "무엇이 변경되었습니까?"라는 질문을 통해 문제의 원인을 찾으려고 시도해야 합니다. 변경된 구성 요소 또는 동작은 일반적으로 근본 원인이 아니지만 실제로 먼저 해결해야 하는 문제입니다. 근본 원인을 해결하는 것이 중요하지만 일반적으로 사고 후 소급 논의와 장기적인 문제 관리가 필요합니다.

예: 로그인 기능에 대한 서비스 수준이 갑자기 떨어집니다. 트래픽 패턴이 평소보다 훨씬 높다는 것을 즉시 알 수 있습니다. 성능 문제를 훨씬 더 큰 TCP 연결 대기열을 유발하는 개방형 TCP 연결 제한 구성으로 추적합니다. TCP 제한 증가 및 일부 추가 서버 인스턴스를 배포하여 문제를 즉시 해결합니다. 단기적으로 문제를 해결했지만 근본 원인은 부적절한 용량 계획, 마케팅 커뮤니케이션 누락 또는 로드 밸런서 구성 변경 실패로 인한 것일 수 있습니다.

이러한 구분은 ITIL/ITSM 인시던트 관리문제 관리 에서도 이루어집니다. 근본 원인은 사고 후 대화에서 논의된 다음 장기적인 문제 관리 프로세스에서 해결됩니다.

진단 단계(개요)

1단계: 문제 진술 작성

첫 번째 규칙은 문제 설명을 신속하게 설정하는 것입니다. 문제 진술 작성에 대한 많은 지침이 있지만 간단하고 효과적인 것이 가장 좋습니다. 잘 구성된 문제 진술은 다음을 수행합니다.

  1. 최종 사용자, 고객 또는 소비자를 위해 변경된 사항을 설명하십시오. 최종 사용자나 소비자가 지금 할 수 없는 것보다 먼저 할 수 있는 것은 무엇입니까? 이것이 문제에 대한 고객의 인식입니다.
  2. 제품 기능의 예상되는 동작을 설명합니다. 이것은 문제에 대한 기술적 평가입니다.
  3. 제품 기능의 현재 동작을 설명합니다. 이것은 수정의 원하는 결과에 대한 기술적인 설명입니다.

문제 진술에서 가정을 피하십시오. 사실에 충실하십시오.

2단계: 출처 찾기

"소스"는 증상을 일으키는 문제에 가장 가까운 구성 요소 또는 코드입니다.

많은 접합부, 스플리터 및 밸브를 통해 연결된 많은 작은 물 호스를 생각해 보십시오. 물 출력 서비스 수준이 저하되었다는 경고를 받았습니다. 어떤 접합부, 스플릿, 밸브 또는 호스가 문제를 일으키는지 결정할 때까지 구성요소를 통한 물 출력에서 문제를 추적합니다. 밸브 중 하나가 단락되었음을 발견했습니다. 그 밸브가 소스입니다. 단락이 문제(직접 원인)입니다.

이것은 복잡한 기술 스택을 진단하는 것과 동일한 개념입니다. 로그인 기능이 제한되어 있으면(출력) 해당 제한을 일으키는 구성 요소를 추적하고 수정해야 합니다. API 소프트웨어(서비스 경계), 미들웨어 서비스, 데이터베이스, 리소스 제약 조건, 타사 서비스 등이 될 수 있습니다.

IT에는 Output , InputClient 의 세 가지 주요 중단점 소스가 있습니다. 이러한 범주를 측정하는 방법은 서비스 수준 관리 가이드 에서 다룹니다. 진단에 사용하는 방법을 이해하려면 계속 읽으십시오.

3단계: 변경 사항 찾기

문제의 원인에 가까우면 무엇이 변경되었는지 확인합니다. 이렇게 하면 단기간에 문제를 즉시 해결하는 방법을 신속하게 결정할 수 있습니다. 2단계 의 예에서 변경 사항은 단락을 유발하는 하드웨어 성능 저하로 인해 밸브가 더 이상 작동하지 않는다는 것이었습니다.

IT의 일반적인 변경 사항의 예는 다음과 같습니다.

  1. 처리량(트래픽)
  2. 코드(배포)
  3. 리소스(하드웨어 할당)
  4. 업스트림 또는 다운스트림 종속성 변경
  5. 데이터 볼륨

성능에 영향을 미치는 문제의 다른 일반적인 예는 아래의 문제 매트릭스 를 참조하십시오.

건강 데이터 포인트 사용

진단 여정을 시작하는 세 가지 주요 성능 범주가 있습니다. 이러한 건강 데이터 요소를 이해하면 문제의 원인이 어디에 있는지 이해하는 데 걸리는 시간을 크게 줄일 수 있습니다.

출력 성능

여기에는 다음이 필요합니다.

출력 성능은 최종 사용자에게 예상 응답(출력)을 전달하는 내부 기술 스택의 능력입니다. 이를 전통적으로 "백엔드" 서비스라고 합니다.

대부분의 시나리오에서 출력 성능은 단순히 응답 속도와 응답 품질로 측정됩니다(즉, 오류가 없음). 위에서 설명한 사용자 관점을 기억하십시오. 최종 사용자는 서비스가 느리거나 작동하지 않거나 액세스할 수 없다고 말합니다.

가장 일반적인 문제는 최종 사용자 요청에 적시 성공적인 방식으로 응답하는 능력입니다.

이는 문제가 있는 제품 기능을 지원하는 서비스의 대기 시간 이상 또는 오류 이상으로 쉽게 식별됩니다.

입력 성능

여기에는 다음이 필요합니다 . 합성

입력 성능은 단순히 클라이언트로부터 요청을 수신하는 서비스의 능력입니다. 이것은 요청을 보내는 클라이언트의 능력과는 다릅니다.

출력 성능, 백엔드 서비스가 예상 성능 수준을 초과할 수 있습니다. 그러나 클라이언트와 서비스 간의 무언가가 요청-응답 수명 주기를 깨고 있습니다. 이것은 클라이언트와 서비스 사이의 모든 것일 수 있습니다.

클라이언트 성능

이를 위해서는 브라우저 모니터링 및/또는 모바일 모니터링이 필요합니다.

클라이언트 성능은 브라우저 및/또는 모바일 애플리케이션이 요청을 하고 응답을 렌더링하는 기능입니다. 출력(백엔드)과 입력 성능(합성)이 모두 빠르게 배제되면 브라우저 및/또는 모바일이 문제의 원인으로 쉽게 식별됩니다.

출력 및 입력 성능은 상대적으로 배제(또는 배제)하기 쉽습니다. 입력 및 출력 진단의 진단 깊이로 인해 브라우저 및 모바일은 향후 고급 진단 가이드에서 다룰 예정입니다.

문제 매트릭스

문제 매트릭스는 세 가지 건강 데이터 포인트로 분류된 일반적인 문제의 치트 시트입니다.

문제의 원인은 빈도에 따라 정렬되며 가장 일반적인 것은 맨 위 행과 왼쪽에 있습니다. 자세한 분류는 아래에 나와 있습니다. 서비스 수준 관리를 잘 수행하면 이러한 데이터 요소 중 3개 중 2개를 신속하게 배제하는 데 도움이 됩니다.

이 테이블은 건강 데이터 포인트별로 정렬된 문제 매트릭스입니다.

데이터 포인트플랫폼 기능일반적인 문제 소스
산출APM, 인프라, 로그, NPM애플리케이션, 데이터 소스, 하드웨어 구성 변경, 인프라, 내부 네트워킹, 타사 공급자(AWS, GCP)
입력합성, 통나무외부 라우팅(CDN, 게이트웨이 등), 내부 라우팅, 인터넷 상의 사물(ISP 등).
고객브라우저, 모바일브라우저 또는 모바일 코드

문제는 복잡해지는 경향이 있지만 목표는 서비스 수준을 신속하게 복원하기 위해 "원인을 찾고" "변경된 사항"을 파악하는 것입니다.

예를 들어, 최근 신제품 배포로 인해 요청이 크게 증가하면 허용할 수 없는 응답 시간이 발생합니다. 로그인 미들웨어 서비스에서 소스가 발견되었습니다. 문제는 점프한 TCP 대기열 시간입니다.

이 상황을 분석하면 다음과 같습니다.

  • 카테고리 : 출력 성능
  • 출처 : 로그인 미들웨어
  • 문제 : 추가 요청 로드로 인한 TCP 대기열 시간
  • 솔루션 : 증가된 TCP 연결 제한 및 확장된 리소스
  • 근본 원인 : 로그인 미들웨어에 영향을 미치는 다운스트림 서비스에 대한 불충분한 용량 계획 및 품질 보증 테스트

다음은 상황의 또 다른 예입니다.

  • 로그인 시 게이트웨이 오류가 500개 갑자기 증가했습니다...
  • 로그인 API 응답 시간이 시간 초과가 시작된 지점까지 증가했습니다...
  • 시간 초과는 미들웨어 계층의 데이터베이스 연결로 추적되었습니다...
  • 트랜잭션 추적을 통해 로그인 요청당 데이터베이스 쿼리 수가 크게 증가한 것으로 나타났습니다...
  • 문제 직전에 발생한 배포에 대한 배포 마커가 발견되었습니다.

이 상황을 분석하면 다음과 같습니다.

  • 범주 : 입력 성능 실패로 이어지는 출력 성능 저하
  • 출처 : 미들웨어 서비스 호출 데이터베이스
  • 문제 : 코드 배포 후 데이터베이스 쿼리 10배 증가
  • 솔루션 : 배포 롤백
  • 근본 원인 : 불충분한 품질 보증 테스트

아래 표는 소스별로 정렬된 문제 매트릭스입니다.

원천

일반적인 문제

애플리케이션

  1. 최근 배포(코드)
  2. 하드웨어 리소스 제약
  3. 데이터베이스 제약 조건
  4. 구성 변경(하드웨어/라우팅/네트워킹)
  5. 타사 종속성

데이터 소스

  1. 데이터베이스 제약 조건
  2. 쿼리 로직 변경(n+1)
  3. 메시지 대기열(일반적으로 생산자 또는 소비자 성능이 저하됨)

내부 네트워킹 및 라우팅

  1. 로드 밸런서
  2. 프록시
  3. API 게이트웨이
  4. 라우터(희귀)
  5. ISP/CDN(희귀)

패턴 이상 식별

패턴 식별에 대한 훌륭한 정보와 무료 온라인 수업이 많이 있지만 진단을 위한 강력한 기술을 가능하게 하는 다소 간단한 프로세스입니다.

성능 데이터의 패턴과 이상을 식별하는 핵심은 서비스가 어떻게 수행되어야 하는지 알 필요가 없다는 것 입니다. 최근 동작이 변경되었는지만 확인하면 됩니다.

이 섹션에 제공된 예제에서는 응답 시간 또는 지연 시간을 지표로 사용하지만 오류, 처리량, 대기열 깊이와 같은 거의 모든 데이터 세트에 동일한 분석을 적용할 수 있습니다.

정상

다음은 APM의 변동성이 있어 보이는 응답 시간 차트(7일)의 예입니다. 자세히 보면 응답 시간의 동작이 반복적임을 알 수 있습니다. 즉, 7일 동안 행동에 급격한 변화가 없습니다. 스파이크는 반복적이며 나머지 타임라인과 비교하여 이상하지 않습니다.

사실, 데이터 보기를 시간 경과에 따른 평균에서 시간 경과 에 따른 백분위수 로 변경하면 응답 시간의 변경이 얼마나 "정기적"인지 훨씬 더 명확해집니다.

이상

이 차트는 최근 동작에 비해 비정상적으로 증가한 것으로 보이는 애플리케이션 응답 시간을 보여줍니다.

이는 주별 비교를 사용하여 확인할 수 있습니다.

패턴이 변경되었으며 지난주 비교에서 악화되는 것으로 보입니다.

출처 찾기

최근 행동 패턴에서 부정적인 변화를 식별하면 해당 행동을 상대적인 원인으로 추적할 수 있습니다.

여기 에서 문제 매트릭스 를 다시 참조합니다. 대부분의 경우 문제는 지연 시간의 출력 성능이나 사용자 경험에 영향을 미치는 오류입니다. 문제는 끝점 API 응용 프로그램(요청을 받는 첫 번째 응용 프로그램)이 문제를 일으키는지 또는 해당 끝점 뒤에 있는 종속성인지입니다.

최종 사용자가 경험한 지연 또는 오류를 일으키는 애플리케이션을 찾습니다. 이것은 응용 프로그램 코드가 문제라는 것을 의미하지는 않지만 응용 프로그램을 찾는 것이 우리를 소스에 가깝게 만듭니다. 그런 다음 코드, 데이터베이스, 구성, 리소스 등으로 시작하는 구성 요소를 배제할 수 있습니다.

오늘날 우리는 분산 추적을 사용할 수 있지만 먼저 소스 트랜잭션을 식별해야 합니다. 이는 하나, 일부 또는 모든 트랜잭션이 대기 시간의 영향을 받는지 식별하기 위해 APM 트랜잭션 분석을 살펴봐야 함을 의미합니다.

영향을 받는 트랜잭션이 식별되면 해당 트랜잭션의 분산 추적을 검색합니다. 이러한 분산 추적은 해당 트랜잭션 그룹 내의 종단 간 서비스에 대한 보다 완전하고 전체적인 보기를 제공합니다. 분산 추적은 대기 시간 또는 오류가 발생한 위치를 보다 빠르게 식별하는 데 도움이 됩니다.

위에서 설명한 단계를 요약하면 다음과 같습니다.

  1. APM을 사용하여 영향을 받는 기능을 지원하는 응용 프로그램을 검사합니다.
  2. 문제가 대기 시간인지 오류인지 식별합니다.
  3. 소스 애플리케이션에 대한 대기 시간 또는 오류를 추적합니다.
  4. 문제를 찾으십시오.

요약

아래 요약은 신뢰성 진단 여정을 시작하는 데 도움이 되는 모든 단계를 요약한 것입니다.

  1. 서비스 수준 관리를 사용하여 기능에 대한 제품 수준 상태 데이터 포인트를 측정합니다.
  2. 운영 핵심 성과 지표 를 사용하여 성공을 측정합니다.
  3. 성능 패턴을 사용하여 오류, 대기 시간 또는 처리량의 비정상적인 동작을 식별합니다.
  4. 명확한 문제 진술을 정의하십시오.
  5. 지연 또는 오류에 영향을 미치는 소스 애플리케이션을 찾습니다.
  6. 대기 시간 또는 오류에 영향을 미치는 변경 사항을 확인합니다. 그 변화가 "문제"라고도 하는 직접적인 원인입니다.

이제 나가서 훌륭한 SRE가 되십시오!

Copyright © 2022 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.