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

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

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

전제 조건

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

• New Relic 관측 가능성 적용 범위:

  • Required : 분산 추적 기능이 있는 APM, 컨텍스트에 따른 APM 로그, 인프라 에이전트
  • 권장 사항: 로그 및 네트워크 모니터링 (NPM)

• Required: 서비스 수준 관리

• 권장 사항: 뻐끔왕 APM, 횡 추적, NRQL 쿼리 및 로그 관리UI사용 경험

• 권장 사항: 다음 가이드를 읽었습니다.

  • 경보 품질 관리
  • 서비스 수준 관리

개요

이 안내서를 사용하기 전에 학습할 내용을 이해하는 데 도움이 됩니다. 이 가이드는 다음을 이해하는 데 도움이 됩니다.

• 진단 기술 향상이 비즈니스에 미치는 영향.

• 성공을 측정하는 데 사용되는 운영 핵심 성과 지표.

• 최종 사용자가 다양한 유형의 안정성 문제를 인식하는 방법.

• 문제의 직접적인 원인 과 근본 원인 사이의 차이.

• 문제를 찾고 해결하기 위한 기본 진단 단계에는 다음이 포함됩니다.

  • 문제 정의 - 문제 진술 만들기
  • 문제의 원인 찾기
  • 문제의 직접적인 원인 찾기

• 일부 성능 문제 범주(출력 성능, 입력 성능, 클라이언트 성능)와 이러한 문제를 진단하는 데 사용되는 뉴웰릭 기능(APM, 신세틱스, 브라우저 모니터링및 모바일 모니터링)

• 일반적인 문제와 가능한 원인을 이해하기 위한 치트 시트인 문제 매트릭스를 사용하는 방법.

마지막으로 이러한 개념을 더 잘 이해하는 데 도움이 되는 몇 가지 성능 문제의 예를 검토할 것입니다.

원하는 결과

요약

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

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

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

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

사업성과

2014년 Gartner는 IT 다운타임의 평균 비용이 분당 $5,600인 것으로 추정 했습니다. 비즈니스에 영향을 미치는 인시던트의 누적 비용은 파악 시간, 빈도, 복구 시간, 수익 영향 및 인시던트를 분류하고 해결하는 엔지니어 수와 같은 요인에 따라 결정됩니다. 간단히 말해 비즈니스에 영향을 미치는 인시던트가 적고, 인시던트 기간이 짧으며, 진단이 빨라지고 성능 영향을 해결하는 데 필요한 인력이 더 적습니다.

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

Downtime minutes x Cost per minute = Downtime cost

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

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

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

운영 결과

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

이 시리즈의 다른 가이드에서는 time to know 개선에 중점을 둡니다. 공지 품질 관리 가이드 에서는 알 시간을 향상하는 reactive 방법에 중점을 두고 있으며, 서비스 수준 관리 가이드 에서는 proactive 방법에 중점을 두고 있습니다.

지금 읽고 있는 가이드에서는 time to understand 및 time to resolve 개선에 중점을 두고 있습니다.

핵심 성과 지표 - 운영

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

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

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

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

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

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

근본 원인 vs 직접 원인

문제의 근본 원인은 해당 문제의 직접적인 원인과 동일 하지 않습니다 . 마찬가지로 직접적인 원인(단기적)을 해결했다고 해서 문제의 근본 원인(장기적)이 해결되었다는 의미는 아닙니다. It's very important to make this distinction.

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

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

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

진단 단계(개요)

1단계: 문제 정의

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

1. 최종 사용자가 경험하는 것을 설명하십시오. 최종 사용자가 겪고 있는 문제는 무엇입니까?
2. 제품 기능의 예상 동작을 설명합니다. 최종 사용자가 경험해야 하는 것은 무엇입니까?
3. 제품 기능의 현재 동작을 설명합니다. 사용자가 경험하는 것에 대한 기술적 평가는 무엇입니까?

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

2단계: 출처 찾기

"소스"는 문제의 직접적인 원인에 가장 가까운 구성 요소 또는 코드입니다.

많은 접합부, 스플리터 및 밸브를 통해 연결된 많은 수도관을 생각해 보십시오. 용수 출력 서비스 수준이 저하되었다는 경고를 받습니다. 어떤 접합부, 분할, 밸브 또는 파이프가 문제를 일으키는지 확인할 때까지 파이프를 통한 물 출력에서 문제를 추적합니다. 전기 밸브 중 하나가 단락된 것을 발견했습니다. 그 밸브가 문제의 원인입니다. 짧은 것은 문제의 직접적인 원인입니다. 값을 교체하여 직접적인 원인을 쉽게 해결할 수 있습니다. 근본 원인은 기상 조건, 수중 화학 물질 또는 제조와 같이 더 복잡한 것일 수 있음을 명심하십시오.

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

IT에는 응답 시간을 개선하기 위한 세 가지 주요 중단점 범주가 있습니다.

1. Output

2. Input

3. Client

서비스 수준 이라고도 하는 이러한 범주 내에서 성능 지표를 정의하면 문제의 원인이 어디인지 판단할 때 응답 시간이 크게 향상됩니다. 이러한 범주 측정은 서비스 수준 관리 가이드 에서 다룹니다. 진단에 사용하는 방법을 이해하려면 계속 읽으십시오.

3단계: 직접적인 원인 찾기

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

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

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

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

건강 데이터 포인트 사용

앞서 언급한 바와 같이 진단 여정을 빠르게 시작하는 세 가지 기본 성능 범주가 있습니다. 이러한 건강 데이터 포인트를 이해하면 문제의 원인을 이해하는 데 걸리는 시간을 크게 줄일 수 있습니다.

문제 매트릭스

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

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

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

| 데이터 포인트 | 뉴렐릭 능력 | 일반적인 문제 원인 | | ---------- | -------- | ------------------------------------- ------------------------------------- ------ | | 출력 | APM, 인프라, 로그인, NPM | 도면, 데이터 소스, 하드웨어 구성 변경, 도면, 내부 네트워킹, 타사 공급자(AWS, GCP) | | 입력 | 신세틱스, 로그인 | 외부 라우팅(CDN, 게이트웨이 등), 내부 라우팅, 인터넷상의 사물(ISP 등) | | 클라이언트 | 브라우저, 모바일 | 브라우저 또는 모바일 코드 |

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

예제 문제

예제 문제를 살펴보겠습니다. 회사에서 새 제품을 배포하고 요청이 크게 증가하여 허용할 수 없는 응답 시간이 발생했다고 가정해 보겠습니다. 소스는 로그인 미들웨어 서비스에서 검색됩니다. 문제는 TCP 대기열 시간의 점프입니다.

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

• Category: 출력 성능
• Source: 로그인 미들웨어
• Direct cause: 추가 요청 로드로 인한 TCP 큐 시간
• Solution: TCP 연결 제한 증가 및 리소스 확장
• Root-cause: 로그인 미들웨어에 영향을 미치는 다운스트림 서비스에 대한 용량 계획 및 품질 보증 테스트가 부족합니다.

또 다른 예시 문제

다음은 또 다른 예제 문제입니다.

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

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

• Category: 출력 성능 저하로 인한 입력 성능 저하
• Source: 미들웨어 서비스 호출 데이터베이스
• Direct cause: 코드 배포 후 데이터베이스 쿼리가 10배 증가했습니다.
• Solution: 배포 롤백
• Root-cause: 품질 보증 테스트가 부족함

소스별 문제 매트릭스

다음은 소스별로 정렬된 문제 행렬이 있는 표입니다.

성능 패턴 이상 식별

패턴 이상을 식별하면 문제의 직접적인 원인이 무엇이고 어디에 있는지 식별하는 능력이 향상됩니다.

패턴 식별에 대한 많은 훌륭한 정보와 무료 온라인 수업이 있지만 일반적인 개념은 다소 단순하며 강력한 진단 능력을 발휘할 수 있습니다.

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

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

정상

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

실제로 데이터 보기를 average over time 에서 percentiles over time 로 변경하면 응답 시간의 변경이 얼마나 "규칙적인"지 더욱 분명해집니다.

이상

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

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

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

출처 찾기

다음으로 New Relic에서 소스를 찾는 방법을 살펴보겠습니다. 이 워크플로우는 분산 추적에 의존합니다.

먼저 최종 사용자가 경험하는 대기 시간 또는 오류와 관련된 애플리케이션을 찾습니다. 이것은 응용 프로그램이나 코드가 문제라는 것을 의미하지는 않지만 흐름 내에서 응용 프로그램을 찾으면( 첫 번째 ) 소스에 더 빨리 접근할 수 있습니다. 이 응용 프로그램이 발견되면 코드, 호스트, 데이터베이스, 구성 및 네트워크와 같은 구성 요소를 빠르게 배제할 수 있습니다.

애플리케이션이 식별되면 문제는 해당 애플리케이션 내의 어떤 트랜잭션이 문제의 일부인지입니다. 성능 문제가 발생한 것으로 확인한 애플리케이션을 사용하고 영향을 받는 트랜잭션을 식별합니다. 여기에서 Identif performance pattern anomalies 에서 위에서 설명한 성능 패턴 이상 기술을 반복할 수 있지만 이번에는 트랜잭션 자체에 대해 수행합니다.

다음 문서는 New Relic을 사용하여 문제 트랜잭션을 식별하는 데 도움이 됩니다.

1. 거래 페이지: 특정 성능 문제 찾기
2. 서비스 요약 페이지의 느린 트랜잭션

문제가 있는 트랜잭션이 식별되면 분산 추적을 사용하여 해당 트랜잭션을 지원하는 종단 간 구성 요소를 검토할 수 있습니다. 분산 추적은 하나의 보기 내에서 전체 스택에서 대기 시간이 있는 위치 및/또는 오류가 발생하는 위치를 신속하게 식별하는 데 도움이 됩니다.

다음 리소스는 분산 추적을 사용하여 소스 문제 구성 요소를 식별하는 방법을 배우는 데 도움이 됩니다.

1. 분산 추적 소개
2. 분산 추적 UI를 사용하는 방법
3. 분산 추적에 대한 무료 온라인 웨비나
4. 직접적인 원인 분석을 위한 분산 추적 사용에 대한 비디오

소스 찾기 단계에 대한 간략한 요약은 다음과 같습니다.

1. 영향을 받는 성능과 관련된 애플리케이션을 검사합니다.
2. 문제의 원인이 되는 트랜잭션을 식별합니다.
3. 분산 추적을 사용하여 종단 간 흐름 내에서 문제 구성 요소를 식별합니다.

이제 직접적인 원인을 식별하는 마지막 단계로 넘어갈 수 있습니다.

직접적인 원인 찾기

소스 구성 요소가 발견되면 직접적인 원인을 결정할 수 있습니다.

이전 단계의 지식을 사용하면 문제가 대기 시간, 성공 또는 둘 다인지 알 수 있습니다.

대기 시간 문제는 트랜잭션 추적 및/또는 분산 추적 내의 "진행 중인 범위"를 사용하여 찾을 수 있습니다.

성공 문제 오류 메시지는 추적에서도 볼 수 있지만 성공 문제에 대한 최상의 세부 정보는 일반적으로 애플리케이션 로그에서 찾을 수 있습니다.

어느 쪽이든 1계층 사고 대응자 또는 SRE인 경우 직접적인 원인을 찾는 것은 일반적으로 발견된 소스 구성 요소를 담당하는 개발자 및 엔지니어인 주제 전문가(SME)에게 맡겨질 것입니다.

소스 구성 요소를 발견한 후 가장 효과적인 다음 단계는 해당 구성 요소에 대해 주제 전문가에게 문의하는 것입니다. 문제 해결을 시작하기 위해 완료한 분류 및 진단에서 발견한 데이터를 그들에게 보여주십시오.

이제 New Relic과 함께 최고의 사이트 신뢰성 엔지니어가 되어보세요!

다음 단계

아직 읽지 않았다면 다음을 포함하여 관련 관측 가능성 성숙도 가이드 를 읽어볼 수 있습니다.

• 경보 품질 관리
• 서비스 수준 관리