다음을 통해 공유

성능 데이터 수집을 위한 권장 사항

  • 아티클

이 Azure 잘 설계된 프레임워크 성능 효율성 검사 목록 권장 사항에 적용됩니다.

PE:04 성능 데이터를 수집합니다. 워크로드 구성 요소 및 흐름은 자동, 연속 및 의미 있는 메트릭 및 로그를 제공해야 합니다. 애플리케이션, 플랫폼, 데이터 및 운영 체제 수준과 같은 다양한 워크로드 수준에서 데이터를 수집합니다.

성능 데이터 수집은 워크로드 성능에 대한 정보를 제공하는 메트릭과 로그를 수집하는 프로세스입니다. 이 데이터에는 메트릭이라고 하는 숫자 값이 포함됩니다. 메트릭은 특정 시점의 시스템 상태를 설명합니다. 레코드로 구성된 다양한 형식의 데이터를 포함하는 로그도 포함됩니다.

성능 데이터를 수집하여 워크로드 성능을 모니터링하고 분석할 수 있습니다. 이 정보를 사용하여 성능 병목 현상을 식별하고, 문제를 해결하고, 리소스 할당을 최적화하고, 데이터 기반 결정을 내려 워크로드의 전반적인 성능 효율성을 개선시킬 수 있습니다.

데이터 기반 인사이트가 없으면 기본 성능 문제 또는 최적화 기회를 인식하지 못할 수 있습니다. 잠재적인 결과에는 느린 응답 시간, 처리량 감소, 리소스 사용량 증가 및 궁극적으로 최적이 않은 사용자 환경이 포함됩니다. 또한 성능 데이터가 부족하여 적시에 문제를 진단하고 해결하기가 어려워져 가동 중지 시간이 길어지고 생산성이 저하됩니다.

정의

용어 정의
활동 로그 리소스 삭제와 같은 리소스에 대한 관리 작업을 추적하는 로그입니다.
애플리케이션 로그 애플리케이션 이벤트, 오류 및 기타 활동에 대한 정보를 추적하는 로그(예: 로그인 및 데이터베이스 연결 실패).
APM(애플리케이션 성능 모니터링) 도구 애플리케이션의 성능을 모니터링하고 보고하는 도구입니다.
코드 계측 애플리케이션 코드의 관점에서 성능 메트릭의 직접 또는 간접 캡처입니다. 캡처된 메트릭에는 흐름 메트릭, 리소스 사용 및 언어 또는 런타임과 관련된 메트릭이 포함됩니다.
분산 추적 분산 워크로드 구성 요소 간에 메트릭을 수집하고 상관 관계를 지정합니다.
메트릭 싱크 분석을 위해 시계열 데이터의 상관 관계를 지정하는 메트릭의 스토리지 대상입니다.
플랫폼 로그 리소스 로그, 활동 로그 및 감사 로그를 포함하는 진단 및 감사 데이터입니다.
플랫폼 메트릭 특정 시간에 워크로드 성능을 기록하는 숫자 값입니다.
리소스 로그 시스템에서 생성하는 데이터입니다. 시스템 상태에 대한 정보를 제공합니다.
Rx/Tx 오류 네트워크 인터페이스의 수신 오류 및 전송 오류 수입니다.
구조적 로깅 메시지를 기록하기 위한 의미 있는 형식 정의(일반적으로 키-값 쌍).

주요 디자인 전략

성능 최적화를 위해서는 데이터가 워크로드의 현재 성능을 측정하거나 성능 목표에 대한 흐름을 측정해야 합니다. 성능 대상에 대한 코드 및 인프라의 성능을 측정하려면 데이터의 적절한 양과 다양성을 수집해야 합니다. 워크로드 내의 모든 구성 요소와 흐름이 연속적이고 의미 있는 메트릭과 로그를 자동으로 생성하도록 합니다. 애플리케이션, 플랫폼, 스토리지 및 운영 체제와 같은 다양한 수준에서 이 데이터를 원본화해야 합니다. 포괄적인 성능 데이터 수집을 통해 성능에 대한 전체적인 이해를 통해 비효율성과 개선 방법을 정확하게 식별할 수 있습니다.

성능 데이터 컬렉션 중앙 집중화

성능 메트릭 및 로그를 중앙 집중화하는 것은 다양한 원본에서 성능 메트릭 및 로그를 수집하여 중앙 위치에 저장하는 프로세스입니다. 중앙 메트릭 싱크와 중앙 로그 싱크를 만듭니다. 이러한 중앙 집중화를 통해 다양한 시스템과 구성 요소 전반에 걸쳐 성능 메트릭과 로그에 쉽게 액세스하고 분석하고 모니터링할 수 있습니다. 메트릭 및 로그를 중앙 집중화하여 워크로드의 성능을 파악할 수 있습니다. 워크로드 성능 메트릭 및 로그를 집계하고 저장할 수 있는 적합한 플랫폼 또는 도구를 선택합니다.

절충: 메트릭 및 로그 수집 비용을 이해합니다. 일반적으로 수집한 메트릭과 로그가 많을수록 비용이 높아질 수 있습니다.

성능 데이터 세그먼트

성능 데이터를 분할하려면 원본, 목적 또는 환경을 기준으로 메트릭과 로그를 구성하고 분류해야 합니다. 예를 들어 프로덕션 데이터를 비프로덕션 데이터와 분리하거나 성능 목표와 비즈니스 메트릭을 구분해야 합니다. 데이터를 분할하면 특정 환경을 최적화하고 문제 해결을 촉진하며 성능 모니터링의 부정확성을 제한하는 데 도움이 됩니다. 서로 다른 데이터 형식을 명확하게 구분하여 관련 메트릭을 보다 효율적으로 캡처, 분석 및 응답하고 워크로드 목표와 워크로드 상태를 더 잘 맞출 수 있습니다. 성능 데이터를 분할하려면 다음 권장 사항을 고려하세요.

  • 프로덕션 데이터와 비프로덕션 데이터를 별도로 유지합니다. 데이터를 환경별로 구분하여 각 환경의 집중적인 모니터링 및 최적화를 보장할 수 있습니다. 프로덕션 환경에서는 사용자 및 비즈니스 운영에 직접적인 영향을 주는 성능 문제를 더 잘 식별하고 해결할 수 있습니다. 비프로덕션 환경에서 데이터 분리는 프로덕션 환경에 배포하기 전에 테스트 단계에서 효과적인 문제 해결 및 미세 조정을 용이하게 합니다.

  • 각 환경 내에서 하나의 데이터 집합을 사용합니다. 성능 대상에 대해 하나의 데이터 집합과 성능 대상과 관련된 경고에 다른 데이터 집합을 사용하지 마세요. 서로 다른 데이터 집합을 사용하면 성능 모니터링의 효율성을 떨어뜨리는 부정확한 경고가 발생합니다.

  • 성능 목표와 비즈니스 메트릭을 구분합니다. 운영 및 개발 팀은 성능 목표를 사용하여 워크로드 상태를 모니터링하고 비즈니스 목표를 충족합니다. 비즈니스 메트릭은 비즈니스 목표 또는 고객 보고와 관련이 있습니다. 데이터가 직접 겹치는 경우에도 별도의 데이터 스트림에서 비즈니스 메트릭을 캡처합니다. 분리는 적절한 데이터를 캡처하고 데이터를 독립적으로 분석할 수 있는 유연성을 제공합니다.

보존 정책 정의

보존 정책은 성능 데이터를 얼마나 오랫동안 보관해야 하는지를 규정합니다. 이러한 정책을 설정하면 스토리지를 효율적으로 관리하는 데 도움이 되며 분석을 위해 필요한 데이터에만 액세스할 수 있습니다. 이러한 정책은 더 나은 성능을 지원하고 규정 준수 표준을 충족합니다. 모든 환경에서 효과적인 문제 해결 및 모니터링을 사용하도록 로그 및 메트릭 데이터에 대한 보존 정책을 구성해야 합니다. 예를 들어 로그 및 메트릭은 테스트 환경보다 프로덕션 환경에서 더 오랜 시간 동안 유지되어야 할 수 있습니다. 보존 기간은 조직의 요구 사항 및 규정 준수 규정과 일치해야 합니다. 분석 및 감사 목적으로 데이터를 보존할 기간을 결정합니다. 즉각적인 분석에 필요하지 않은 데이터를 보관합니다.

애플리케이션 성능 데이터 수집

애플리케이션 데이터를 수집하려면 주로 계측 코드를 통해 수집된 처리량, 대기 시간 및 완료 시간과 같은 애플리케이션의 성능 메트릭을 모니터링하고 분석해야 합니다. 애플리케이션 성능 데이터는 애플리케이션의 상태 및 성능에 대한 중요한 인사이트를 제공합니다. 성능 데이터를 모니터링하고 분석하여 문제를 식별 및 해결하고, 애플리케이션 성능을 최적화하고, 애플리케이션에 대해 정보에 입각한 결정을 내릴 수 있습니다.

계측 코드

계측은 코드 조각을 포함하거나 도구를 애플리케이션 코드에 통합하는 프로세스를 나타냅니다. 계측의 목적은 애플리케이션이 실행되는 동안 성능 데이터를 캡처하는 것입니다. 애플리케이션의 중요한 작업을 강조하는 메트릭을 수집해야 합니다. 처리량, 대기 시간 및 완료 시간과 같은 메트릭에 집중합니다. 비즈니스 관련 운영과 그렇지 않은 작업을 구분하는 것이 중요합니다. 비즈니스 작업과 관련된 데이터의 경우 메타데이터가 고유한 추적 및 스토리지를 허용하는 방식으로 구조화되어 있는지 확인합니다. 코드 계측의 주된 이유는 애플리케이션이 워크로드를 처리하는 방법에 대한 데이터를 수집하기 위해서입니다. 가비지 수집은 다음과 같은 이점을 제공합니다.

  • 성능 병목 상태 식별: CPU 사용 및 메모리 사용과 같은 메트릭을 추적하여 병목 상태를 식별하고 그에 따라 코드를 최적화할 수 있습니다.

  • 부하에서 시스템 동작 평가: 애플리케이션이 다양한 워크로드 및 스트레스 시나리오에서 수행하는 방식을 확인할 수 있습니다. 이 데이터는 확장성, 동시성 및 리소스 사용과 관련된 문제를 식별하는 데 도움이 될 수 있습니다.

  • 애플리케이션 상태 및 가용성 추적: 주요 성능 지표가 실시간으로 모니터링되므로 애플리케이션의 성능 및 가용성에 영향을 주는 잠재적인 문제에 대한 경고를 받을 수 있습니다.

  • 사용자 환경 개선: 사용자가 애플리케이션과 상호 작용하는 방법에 대한 인사이트를 얻을 수 있습니다. 이 정보를 사용하여 사용자 환경을 최적화하고 개선할 영역을 식별합니다.

  • 용량 계획 및 리소스 할당: 계측이 수집하는 성능 데이터는 애플리케이션의 리소스 요구 사항에 대한 중요한 인사이트를 제공할 수 있습니다. 이 정보는 용량 계획 및 리소스 할당에 대한 결정을 알릴 수 있습니다.

성능 모니터링을 위해 코드를 계측할 때 다음 전략을 고려합니다.

  • APM 도구 사용: APM 도구는 메트릭, 추적 및 로그를 포함하여 성능 데이터를 수집하고 분석할 수 있습니다. APM 도구는 코드 수준 계측, 트랜잭션 추적 및 성능 프로파일링과 같은 기능을 제공합니다.

  • 로깅 및 추적 프레임워크 사용: 로깅 및 추적 프레임워크는 개발자가 로깅 및 추적을 용이하게 하기 위해 애플리케이션에 통합하는 도구 또는 라이브러리입니다. 이러한 프레임워크는 로그를 생성하고, 요청을 추적하며, 때로는 생성된 데이터의 형식을 지정하거나 전송하는 함수를 제공합니다. 로깅 및 추적 프레임워크를 코드 베이스에 통합하면 개발자는 런타임 중에 관련 데이터를 캡처할 수 있습니다. 데이터에는 실행 중인 경로, I/O 및 성능에 대한 정보가 포함될 수 있습니다.

  • 사용자 지정 계측: 개발자는 사용자 지정 코드를 추가하여 애플리케이션 및 워크로드에 고유한 성능 메트릭을 수집할 수 있습니다. 사용자 지정 계측은 런타임을 측정하거나, 리소스 사용량을 추적하거나, 특정 이벤트를 캡처할 수 있습니다. 플랫폼 메트릭이 부족한 경우에만 사용자 지정 코드 계측을 작성합니다. 경우에 따라 플랫폼 리소스는 애플리케이션의 집계 또는 세분화된 관점을 측정할 수 있습니다. 과도한 코드 절충 또는 플랫폼 기능에 대한 종속성에 대해 사용자 지정 코드를 사용하여 이러한 노력을 복제할지 여부를 결정합니다.

  • 트랜잭션 시간을 캡처합니다. 트랜잭션 시간 캡처는 성능 모니터링의 일부로 주요 기술 기능에 대한 엔드 투 엔드 시간을 측정하는 것과 관련이 있습니다. 애플리케이션 수준 메트릭에는 엔드 투 엔드 트랜잭션 시간이 포함되어야 합니다. 이러한 트랜잭션 시간은 데이터베이스 쿼리, 외부 API 호출에 대한 응답 시간 및 처리 단계의 실패율과 같은 주요 기술 기능을 포함해야 합니다.

  • 원격 분석 표준을 사용합니다. APM 도구 계측 라이브러리 및 OpenTelemetry와 같은 원격 분석 표준을 기반으로 빌드된 도구를 사용하는 것이 좋습니다.

분산 추적 사용

분산 추적은 분산 시스템을 통해 흐르는 요청을 추적하고 모니터링하는 데 사용되는 기술입니다. 이를 통해 여러 서비스 및 구성 요소를 이동할 때 요청 경로를 추적하여 워크로드의 성능과 효율성에 대한 중요한 인사이트를 제공할 수 있습니다. 분산 추적은 분산 시스템 내에서 병목 상태, 대기 시간 문제 및 최적화 영역을 식별하는 데 도움이 되므로 성능 효율성에 중요합니다. 지연 또는 비효율성이 발생하는 위치를 정확히 파악하고 요청 흐름을 시각화하여 성능을 개선하기 위해 적절한 조치를 취할 수 있습니다. 분산 추적을 사용하도록 설정하려면 다음 단계를 수행합니다.

  1. 먼저 애플리케이션 및 서비스를 계측하여 추적 데이터를 생성합니다. OpenTelemetry와 같은 분산 추적을 지원하는 라이브러리 또는 프레임워크를 사용합니다.

  2. 추적 정보가 서비스 경계를 넘어 전파되는지 확인합니다. 일반적으로 각 요청에 고유한 추적 ID 및 기타 컨텍스트 정보를 전달해야 합니다.

  3. 중앙 집중식 추적 컬렉션 시스템을 설정합니다. 이 시스템은 애플리케이션 및 서비스에서 생성된 추적 데이터를 수집하고 저장합니다.

  4. 수집된 추적 데이터를 사용하여 요청의 엔드 투 엔드 흐름을 시각화하고 분산 시스템의 성능 특성을 분석합니다.

애플리케이션 로그 수집

코드를 계측할 때 기본 출력 중 하나는 애플리케이션 로그여야 합니다. 로깅은 다양한 환경에서 애플리케이션이 실행되는 방식을 이해하는 데 도움이 됩니다. 애플리케이션 로그는 애플리케이션 이벤트를 생성하는 조건을 기록합니다. 모든 애플리케이션 환경에서 애플리케이션 로그를 수집합니다. 애플리케이션 전체의 해당 로그 항목은 각 트랜잭션에 대한 상관 관계 ID를 캡처해야 합니다. 상관 관계 ID는 사용자 로그인과 같은 중요한 애플리케이션 흐름 간에 애플리케이션 로그 이벤트의 상관 관계를 지정해야 합니다. 이 상관 관계를 사용하여 대상 및 비기능 요구 사항의 컨텍스트에서 주요 시나리오의 상태를 평가합니다.

구조적 로깅을 사용해야 합니다. 구조적 로깅은 로그 구문 분석 및 분석 속도를 향상합니다. 이렇게 하면 복잡성 없이 로그를 더 쉽게 인덱싱, 쿼리 및 보고할 수 있습니다. 애플리케이션 코드에서 구조화된 로깅 라이브러리를 추가하고 사용합니다. 경우에 따라 로그 항목은 다른 수단으로 상관 관계를 지정할 수 없는 데이터의 상관 관계를 지정하는 데 도움이 될 수 있습니다.

리소스 성능 데이터 수집

리소스 성능 데이터를 수집하여 워크로드의 상태 및 동작에 대한 인사이트를 얻을 수 있습니다. 리소스 성능 데이터는 용량 계획의 핵심인 리소스 사용에 대한 정보를 제공합니다. 또한 이 데이터는 워크로드의 상태에 대한 인사이트를 제공하며 문제를 감지하고 문제를 해결하는 데 도움이 될 수 있습니다. 다음 권장 사항을 살펴 보십시오.

  • 모든 리소스에 대한 메트릭 및 로그를 수집합니다. 각 Azure 서비스에는 리소스의 기능에 고유한 메트릭 집합이 있습니다. 이러한 메트릭은 리소스의 상태와 성능을 이해하는 데 도움이 됩니다. 각 리소스에 대한 진단 설정을 추가하여 워크로드 팀이 경고 및 대시보드를 빌드할 때 액세스할 수 있는 위치에 메트릭을 보냅니다. 메트릭 데이터는 단기 액세스에 사용할 수 있습니다. 장기 액세스 또는 Azure Monitor 외부의 시스템에서 액세스하려면 메트릭 데이터를 통합 싱크로 액세스 위치로 보냅니다.

  • 플랫폼 도구를 사용합니다. Azure Monitor Insights와 같은 기본 제공 및 통합 모니터링 솔루션에서 영감을 얻습니다. 이 도구는 성능 작업을 간소화합니다. 플랫폼을 선택하고 사용자 지정 도구 또는 보고에 투자할 때 플랫폼 도구를 고려합니다.

  • 네트워크 트래픽을 모니터링합니다. 네트워크 트래픽 모니터링은 네트워크 경로 간에 이동할 때 데이터의 흐름과 패턴을 추적하고 분석하는 것을 의미합니다. 트래픽 분석을 수집하고 서브넷 경계를 트래버스하는 트래픽을 모니터링합니다. 사용자의 목표는 네트워크 성능을 분석하고 최적화하는 것입니다.

데이터베이스 및 스토리지 데이터 수집

많은 데이터베이스 및 스토리지 시스템은 자체 모니터링 도구를 제공합니다. 이러한 도구는 해당 시스템과 관련된 성능 데이터를 수집합니다. 데이터베이스 및 스토리지 시스템은 성능 관련 이벤트 및 표시기를 포함하는 로그를 생성하는 경우가 많습니다. 데이터베이스 데이터와 스토리지 성능 데이터를 수집하여 병목 현상을 식별하고, 문제를 진단하고, 합리적 결정을 내려 워크로드의 전반적인 성능과 안정성을 개선시킬 수 있습니다. 다음과 같은 유형의 성능 데이터를 수집하는 것이 좋습니다.

  • 처리량: 처리량은 일정 기간 동안 스토리지 시스템에서 읽거나 스토리지 시스템에 쓴 데이터의 양을 측정합니다. 처리량 데이터는 데이터 전송 기능을 나타냅니다.

  • 대기 시간: 대기 시간은 스토리지 작업이 지속되는 기간을 측정합니다. 대기 시간 데이터는 스토리지 시스템의 응답성을 나타냅니다.

  • IOPS(초당 I/O 작업): 스토리지 시스템에서 초당 수행할 수 있는 읽기 작업 또는 쓰기 작업 수에 대한 데이터입니다. IOPS 데이터는 스토리지 시스템의 처리량 및 응답성을 나타냅니다.

  • 용량 사용: 용량 사용량은 사용된 스토리지 용량의 양과 사용 가능한 양입니다. 용량 사용 데이터는 조직이 향후 스토리지 요구 사항을 계획하는 데 도움이 됩니다.

데이터베이스의 경우 데이터베이스별 메트릭도 수집해야 합니다.

  • 쿼리 성능: 데이터베이스 쿼리의 실행 시간, 리소스 사용량 및 효율성에 대한 데이터입니다. 느리거나 비효율적인 데이터베이스 쿼리로 인해 워크로드 속도가 크게 느려질 수 있습니다. 느리고 자주 실행되는 쿼리를 찾습니다.

  • 트랜잭션 성능: 트랜잭션 기간, 동시성 및 잠금 경합과 같은 데이터베이스 트랜잭션의 성능에 대한 데이터입니다.

  • 인덱스 성능: 인덱스 조각화, 사용 통계 및 쿼리 최적화와 같은 데이터베이스 인덱스의 성능에 대한 데이터입니다.

  • 리소스 사용: CPU, 메모리, 디스크 공간, I/O 및 네트워크 대역폭을 포함하는 데이터입니다.

  • 연결 메트릭: 활성, 중단됨 및 실패한 연결 수를 추적하는 메트릭입니다. 높은 실패율은 네트워크 문제를 나타내거나 데이터베이스가 최대 연결 수에 도달했음을 나타낼 수 있습니다.

  • 트랜잭션 속도: 데이터베이스가 초당 실행되는 트랜잭션 수입니다. 트랜잭션 속도의 변경은 성능 문제를 나타낼 수 있습니다.

  • 오류율: 데이터베이스 성능을 나타내는 데이터입니다. 높은 오류 비율은 성능 문제를 나타낼 수 있습니다. 데이터베이스 오류를 수집하고 분석합니다.

운영 체제 데이터 수집

PaaS(Platform as a Service) 솔루션을 사용하면 운영 체제 성능 데이터를 수집할 필요가 없습니다. 그러나 워크로드가 가상 머신(서비스로서의 인프라)에서 실행되는 경우 운영 체제에 대한 성능 데이터를 수집해야 합니다. 운영 체제 및 가상 머신에 대한 수요를 이해해야 합니다. 운영 체제 성능 카운터를 자주 샘플링합니다. 예를 들어 1분마다 성능 카운터를 샘플링할 수 있습니다.

최소한 다음 성능 영역에 대한 데이터를 수집합니다.

성능 영역 프로세스 또는 함수
CPU - CPU 사용량(사용자 모드 또는 권한 있는 모드)
- CPU 큐 길이(CPU 시간을 기다리는 프로세스 수)
Process - 프로세스 스레드 수
- 프로세스 핸들 수
메모리 - 커밋된 메모리
- 사용 가능한 메모리
- 초당 페이지 수
- 공간 사용량 교환
디스크 - 디스크 읽기
- 디스크 쓰기
- 디스크 처리량
- 디스크 공간 사용량
네트워크 - 네트워크 인터페이스 처리량
- 네트워크 인터페이스 Rx/Tx 오류

데이터 유효성 검사 및 분석

성능 데이터는 성능 목표와 일치해야 합니다. 데이터는 성능 목표와 관련하여 워크로드 또는 흐름 성능을 완전하고 정확하게 나타내야 합니다. 예를 들어 웹 서비스의 응답 시간은 성능 목표인 500ms입니다. 자주 평가하면 성능 문제를 조기에 감지하고 완화할 수 있으므로 데이터를 분석하는 루틴으로 만듭니다.

  • 경고 만들기 실행 가능한 경고를 사용하면 성능 문제를 신속하게 식별하고 수정할 수 있습니다. 이러한 경고는 위반된 성능 임계값, 잠재적 비즈니스 효과 및 관련 구성 요소를 명확하게 나타내야 합니다. 일반 및 권장 경고를 설정하여 시작합니다. 시간이 지남에 따라 특정 요구 사항에 따라 이러한 조건을 수정할 수 있습니다. 이러한 경고의 주요 목표는 중요한 문제로 확대되기 전에 잠재적인 성능 저하를 예측하는 것입니다. 외부 종속성에 대한 경고를 설정할 수 없는 경우 종속성 호출 기간과 같은 간접 측정값을 수집하는 방법을 고안하는 것이 좋습니다.

  • 데이터 수집 제한을 설정합니다. 수집한 데이터의 양과 보존 기간에 대한 논리적 제한을 결정하고 설정합니다. 원격 분석은 때때로 엄청난 양의 데이터를 생성할 수 있습니다. 가장 중요한 성능 지표만 캡처하는 데 집중하거나 성능 데이터에서 의미 있는 인사이트를 추출할 수 있는 효율적인 시스템을 갖추어야 합니다.

Azure 촉진

성능 데이터 중앙 집중화, 분할 및 유지: Azure Monitor 는 여러 Azure 및 비 Azure 구독 및 테넌트에 걸쳐 워크로드의 모든 계층 및 구성 요소에서 데이터를 수집하고 집계합니다. Azure Monitor는 공통 데이터 플랫폼에 데이터를 저장하여 상호 연결, 분석, 시각화, 응답할 수 있는 공통 도구 집합에서 사용할 수 있도록 합니다.

Azure Monitor 로그를 사용하도록 설정하려면 하나 이상의 Log Analytics 작업 영역 이 필요합니다. 모든 데이터 컬렉션에 대해 단일 작업 영역을 사용할 수 있습니다. 성능 데이터를 분할하기 위한 요구 사항에 따라 여러 작업 영역을 만들 수도 있습니다. 또한 보존 정책을 정의할 수 있습니다.

애플리케이션 성능 데이터 수집: Application Insights 는 애플리케이션의 성능 및 가용성을 모니터링하는 데 도움이 되는 Azure Monitor의 기능입니다. 요청 속도, 응답 시간 및 예외 세부 정보와 같은 원격 분석 데이터를 수집하여 애플리케이션 수준 인사이트를 제공합니다. 애플리케이션에 대해 Application Insights를 사용하도록 설정하고 필요한 성능 데이터를 수집하도록 구성할 수 있습니다. Application Insights는 분산 추적도 지원합니다. 모든 흐름에 대해 분산 추적을 구성합니다. 엔드 투 엔드 트랜잭션 흐름을 빌드하려면 다른 애플리케이션 구성 요소 또는 계층에서 오는 이벤트와 상관 관계를 지정합니다.

성능 카운터는 애플리케이션의 성능을 모니터링하는 강력한 방법입니다. Azure는 CPU 사용량, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등에 대한 데이터를 수집하는 데 사용할 수 있는 다양한 성능 카운터를 제공합니다. 성능 카운터 데이터를 내보내도록 애플리케이션을 구성하는 경우 Azure Monitor는 분석을 위해 데이터를 수집하고 저장합니다.

리소스 성능 데이터 수집: 대부분의 Azure 서비스는 진단 및 감사 정보를 제공하는 플랫폼 로그 및 메트릭을 생성합니다. 진단 설정을 사용하도록 설정하면 수집 및 저장할 플랫폼 로그 및 메트릭을 지정할 수 있습니다. 상관 관계를 위해 지원되는 모든 서비스에 대해 진단을 사용하도록 설정한 다음 애플리케이션 로그와 동일한 대상으로 로그를 보냅니다.

데이터베이스 및 스토리지 성능 데이터 수집: Azure Monitor를 사용하면 Azure에서 데이터베이스에 대한 성능 데이터를 수집할 수 있습니다. Azure SQL Database, Azure Database for MySQL, Azure Database for PostgreSQL 및 기타 데이터베이스 서비스에 대한 모니터링을 사용하도록 설정할 수 있습니다. Azure Monitor는 CPU 사용, 메모리 사용 및 쿼리 성능을 포함하여 데이터베이스 성능을 모니터링하기 위한 메트릭 및 로그를 제공합니다. 문제에 대한 알림을 받도록 성능 임계값에 따라 경고를 설정할 수 있습니다.

Azure는 Azure Virtual Machines의 SQL Server와 같은 데이터베이스에 대한 성능 권장 사항을 제공합니다. 이러한 권장 사항은 데이터베이스 워크로드의 성능을 최적화하는 데 도움이 됩니다. 여기에는 성능 카운터 수집, 대기 통계 캡처 및 사용량이 많은 시간 동안 성능 데이터 수집을 위한 제안이 포함됩니다.

Azure 스토리지 분석 사용하면 Blob Storage, Table Storage 및 Queue Storage와 같은 Azure Storage 서비스에 대한 성능 데이터를 수집할 수 있습니다. 스토리지 계정에 대한 로깅 및 메트릭을 사용하도록 설정하여 읽기/쓰기 작업 수, 처리량 및 대기 시간과 같은 주요 성능 지표를 모니터링할 수 있습니다.

운영 체제 성능 데이터 수집: Azure Diagnostics 확장을 사용하면 CPU, 메모리, 디스크 I/O 및 네트워크 트래픽을 포함하여 VM(가상 머신)에서 자세한 성능 데이터를 수집할 수 있습니다. 이 데이터는 분석 및 경고를 위해 Azure Monitor 또는 다른 스토리지 서비스로 보낼 수 있습니다.

성능 데이터 유효성 검사 및 분석: Azure Monitor 내에서 Azure Monitor 로그를 사용하여 애플리케이션 및 시스템에서 로그 데이터를 수집, 분석 및 시각화할 수 있습니다. 애플리케이션 수준 로그 및 인프라 로그를 포함하여 애플리케이션에서 로그를 수집하도록 Azure Monitor 로그를 구성할 수 있습니다. 로그를 집계하여 이벤트를 교차 쿼리하고 애플리케이션의 성능에 대한 인사이트를 얻을 수 있습니다. 자세한 내용은 Azure Monitor 로그 비용 계산 및 옵션 및 Azure Monitor 가격 책정을 참조하세요.

Azure Monitor에서 경고 규칙을 정의하여 특정 성능 메트릭을 모니터링하고 미리 정의된 조건에 따라 경고를 트리거할 수 있습니다. 예를 들어 CPU 사용량이 특정 임계값을 초과하거나 응답 시간이 지정된 제한을 초과할 때 알리는 경고 규칙을 만들 수 있습니다. 원하는 받는 사람에게 알림을 보내도록 경고 규칙을 구성합니다.

경고 규칙을 만들 때 경고를 트리거해야 하는 시기를 결정하는 조건을 정의할 수 있습니다. 임계값, 집계 방법, 시간 기간 및 평가 빈도를 설정할 수 있습니다. 성능 모니터링 요구 사항에 따라 조건을 정의합니다. 알림을 보내는 것 외에도 경고가 트리거될 때 수행할 작업을 지정할 수 있습니다. 작업에는 이메일 보내기, 웹후크 호출 또는 Azure 함수 실행이 포함될 수 있습니다. 특정 경고 시나리오에 응답할 적절한 작업을 선택합니다.

예제

성능 효율성 검사 목록

전체 권장 사항 집합을 참조하세요.

성능 효율성 검사 목록