애플리케이션 계측을 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:07 모니터링 시스템을 설계 및 구현하여 디자인 선택의 유효성을 검사하고 향후 디자인 및 비즈니스 의사 결정을 알립니다. 이 시스템은 워크로드의 인프라 및 코드에서 내보내는 운영 원격 분석, 메트릭 및 로그를 캡처하고 노출합니다.

관련 가이드: 모니터링 시스템 설계 및 만들기를 위한 권장 사항

이 가이드에서는 계측을 사용하여 애플리케이션의 가시성을 사용하도록 설정하기 위한 권장 사항을 설명합니다. 수집하여 모니터링 시스템에 통합할 수 있는 의미 있는 원격 분석을 생성합니다. 계측을 사용하면 원격 프로덕션 서버에 로그인하지 않고 정보를 수집하여 추적 또는 디버깅을 수동으로 수행할 수 있습니다. 계측 데이터에는 성능을 평가하고, 문제를 진단하고, 워크로드를 결정하는 데 사용할 수 있는 메트릭 및 로그가 포함됩니다.

주요 디자인 전략

워크로드에 대한 원격 분석을 최적화하려면 애플리케이션을 계측하여 다음 데이터를 생성합니다.

  • 로그는 개별 이벤트의 타임스탬프가 지정된 레코드입니다. 일반 텍스트, 구조적 및 이진 로그의 세 가지 형태가 있습니다.

  • 분산 추적 로그를 사용하면 다양한 서비스 및 구성 요소를 통해 이동하는 요청의 경로를 볼 수 있습니다.

  • 메트릭은 특정 시점에 시스템의 측면을 설명하는 숫자 값입니다.

참고

Application Insights, Dynatrace 및 Elastic Application Performance Monitoring과 같은 도구를 사용하여 애플리케이션을 자동으로 계측할 수 있습니다. 이러한 도구는 계측을 더 쉽게 만들지만 제한될 수도 있습니다. 자동 계측 도구를 사용하는 경우 필요에 따라 수동 계측을 통해 더 많은 기능을 추가할 수 있습니다.

로그 및 분산 추적 로그

구조적 로깅을 사용하여 로그를 모니터링 및 분석 플랫폼에 쉽게 통합할 수 있습니다. 세부 정보 수준을 변경할 수 있도록 애플리케이션을 계측합니다. 상수 자세한 정보 로깅은 스토리지 리소스를 낭비할 수 있으므로 문제 해결에 필요한 경우 켜고 끕니다.

애플리케이션이 ETW(Windows용 이벤트 추적)를 사용하는 경우 추적 로그에는 추적 이벤트에서 만든 텍스트 데이터 또는 이진 데이터가 포함됩니다. 시스템 로그는 웹 서버와 같은 인프라의 이벤트에서 추적 로그 콘텐츠를 생성합니다. 텍스트 로그 콘텐츠는 사람이 읽을 수 있도록 설계되었지만 자동화된 시스템도 구문 분석할 수 있는 형식으로 작성되었는지 확인해야 합니다.

로그를 분류하고 별도의 로그를 사용하여 시스템의 각 작동 측면에서 추적 출력을 기록합니다. 로그를 분류하는 경우 긴 단일 파일을 처리하는 대신 로그 메시지를 빠르게 필터링할 수 있습니다. 감사 정보 및 데이터 디버깅과 같은 다른 보안 요구 사항이 있는 정보를 동일한 로그에 기록하지 마세요.

참고

로그는 파일 시스템에서 파일로 구현되거나 Blob Storage의 Blob과 같은 다른 형식으로 보관될 수 있습니다. 로그 정보는 테이블의 행과 같은 구조적 스토리지에 보관될 수도 있습니다.

메트릭

메트릭 또는 샘플은 하나 이상의 연결된 태그 또는 차원을 사용하여 특정 시간에 시스템의 일부 측면 또는 리소스 수입니다. 메트릭의 단일 instance 격리에 유용하지 않으며 시간이 지남에 따라 메트릭을 캡처해야 합니다. 기록해야 하는 메트릭과 빈도를 고려합니다. 너무 자주 생성된 데이터는 시스템에 과도한 부하를 부과할 수 있지만 드물게 데이터 캡처로 인해 중요한 이벤트로 이어지는 상황을 놓칠 수 있습니다. 데이터를 캡처하는 데 적합한 빈도는 메트릭마다 다를 수 있습니다. 예를 들어 서버의 CPU 사용량은 초에서 초 단위로 크게 다를 수 있지만 높은 사용량은 몇 분 동안 일관성이 있는 경우에만 문제가 됩니다.

데이터 상관 관계를 설정하기 위한 정보

개별 및 시스템 수준 성능 카운터를 쉽게 모니터링하고, 리소스에 대한 메트릭을 캡처하고, 다양한 로그 파일에서 애플리케이션 추적 정보를 가져올 수 있습니다. 일부 모니터링에는 모니터링 파이프라인의 분석 및 진단 단계에서 데이터 상관 관계가 필요합니다. 이 데이터는 여러 가지 형태를 취할 수 있으며 분석 프로세스는 이러한 다양한 양식을 매핑할 수 있는 충분한 계측 데이터를 제공해야 합니다. 예를 들어 애플리케이션 프레임워크 수준에서 스레드 ID는 작업을 식별할 수 있습니다. 애플리케이션 내에서 동일한 작업이 해당 작업을 완료하는 사용자의 사용자 ID와 연결될 수 있습니다.

비동기 작업이 둘 이상의 사용자에 대해 동일한 스레드를 다시 사용할 수 있으므로 스레드와 사용자 요청 간에 1:1 맵이 될 가능성은 낮습니다. 문제를 더욱 복잡하게 만들기 위해 단일 요청은 시스템을 통해 흐르는 스레드와 둘 이상의 상관 관계를 지정할 수 있습니다. 가능하면 요청 컨텍스트의 일부로 시스템을 통해 전파되어 있는 고유한 작업 ID와 각 요청을 연결하는 것이 좋습니다. 활동 ID를 생성하여 추적 정보에 포함하는 기법은 추적 데이터를 캡처하는 데 사용되는 기술에 따라 달라집니다.

모든 모니터링 데이터에 같은 방식으로 타임스탬프를 지정해야 합니다. 일관성을 위해 모든 날짜와 시간은 협정 세계시를 사용하여 기록합니다.

참고

다른 표준 시간대 및 네트워크에서 작동하는 컴퓨터는 동기화되지 않을 수 있습니다. 여러 머신에 걸쳐 있는 계측 데이터의 상관 관계를 지정하는 데 타임스탬프만 단독으로 사용하지 마세요.

계측 데이터에 포함할 정보

수집해야 하는 계측 데이터를 결정할 때 다음 사항을 고려합니다.

사람이 읽을 수 있는 데이터

추적 이벤트에 의해 캡처된 정보가 컴퓨터와 사람이 읽을 수 있는지 확인합니다. 이 정보에 대해 잘 정의된 스키마를 채택하여 시스템 전체에서 로그 데이터의 자동화된 처리를 구현하고 로그를 읽는 운영 및 엔지니어링 직원에게 일관성을 제공합니다.

데이터에 다음 환경 정보를 포함합니다.

  • 배포 환경
  • 처리 컴퓨터
  • 프로세스의 세부 정보
  • 호출 스택

추적 가능성 및 상관 관계에 투자

개발자 또는 관리자가 각 요청의 원본을 확인할 수 있도록 요청의 특정 instance 연결된 활동 ID와 같은 충분한 컨텍스트를 제공합니다.

데이터 컨텍스트에는 작업과 수행된 계산 작업 및 사용된 리소스의 상관 관계를 지정하는 데 사용되는 정보가 포함될 수도 있습니다. 이 작업은 프로세스와 머신의 경계를 넘을 수 있습니다.

계량의 경우 컨텍스트는 요청을 발생시킨 고객에 대한 참조를 직접 또는 간접적으로 포함해야 합니다. 이 컨텍스트는 모니터링 데이터를 캡처한 시점의 애플리케이션 상태에 대한 귀중한 정보를 제공합니다.

모든 관련 데이터 캡처

모든 요청과 요청이 만들어진 위치 또는 지역을 기록합니다. 이 정보를 사용하여 위치별 핫스팟을 식별할 수 있습니다. 이 정보는 애플리케이션 또는 애플리케이션에서 사용하는 데이터를 다시 분할할지를 결정하는 데에도 유용한 역할을 할 수 있습니다.

예외의 세부 정보를 주의 깊게 기록하고 캡처합니다. 예외 처리가 좋지 않아 중요한 디버그 정보가 손실되는 경우가 많습니다. 가능한 경우 내부 예외 또는 호출 스택과 같은 기타 컨텍스트 정보를 포함하여 애플리케이션이 throw하는 모든 예외 세부 정보를 캡처합니다.

데이터 일관성을 위해 노력

일관된 데이터는 이벤트를 분석하고 사용자 요청과 상호 연결하는 데 도움이 될 수 있습니다. 포괄적이고 구성 가능한 로깅 패키지를 사용하여 정보를 수집하는 것이 좋습니다. 로깅 패키지는 개발자가 시스템의 여러 부분을 구현할 때 접근 방식을 채택하는 데 의존하지 않도록 하는 데 도움이 될 수 있습니다.

입력/출력 볼륨, 요청 수, 메모리, 네트워크 및 CPU 사용량과 같은 데이터를 주요 성능 카운터에서 수집합니다. 일부 인프라 서비스는 다음과 같은 자체 성능 카운터를 제공합니다.

  • 데이터베이스에 대한 연결 수.
  • 트랜잭션 속도입니다.
  • 성공하거나 실패한 트랜잭션 수.

애플리케이션은 자체 성능 카운터를 정의할 수도 있습니다.

외부 종속성 고려

모든 외부 서비스 호출을 기록합니다. 외부 호출은 다음을 수행할 수 있습니다.

  • 데이터베이스 시스템.
  • 웹 서비스.
  • 인프라의 일부인 기타 시스템 수준 서비스입니다.

각 호출 기간 및 호출의 성공 또는 실패에 대한 정보를 기록합니다. 가능하면 발생하는 일시적 오류와 관련해 모든 재시도 및 실패에 대한 정보를 캡처합니다.

원격 분석 시스템 호환성 확인

많은 경우에 계측 정보는 일련의 이벤트로 생성되고 처리와 분석을 위해 별도의 원격 분석 시스템에 전달됩니다. 원격 분석 시스템은 일반적으로 특정 애플리케이션 또는 기술과 독립적입니다.

원격 분석 시스템은 정의된 스키마를 사용하여 정보를 구문 분석합니다. 스키마는 원격 분석 시스템에서 수집할 수 있는 데이터 필드 및 형식을 정의하는 계약을 지정합니다. 다양한 플랫폼 및 디바이스에서 데이터가 도착할 수 있도록 스키마를 일반화합니다. 공통 스키마에는 다음과 같은 모든 계측 이벤트와 관련된 필드가 포함되어야 합니다.

  • 이벤트 이름입니다.
  • 이벤트 시간입니다.
  • 보낸 사람의 IP 주소입니다.
  • 다음을 포함하여 이벤트 상관 관계에 필요한 세부 정보:
    • 사용자 ID
    • 디바이스 ID
    • 응용 프로그램 ID

많은 디바이스가 동일한 애플리케이션에 대한 이벤트를 발생할 수 있으므로 스키마가 디바이스 유형에 의존해서는 안 됩니다. 애플리케이션은 로밍 또는 디바이스 간 배포를 지원해야 합니다. 스키마에는 다음과 같은 애플리케이션에서 공통적인 특정 시나리오에 대한 관련 도메인 필드도 포함될 수 있습니다.

  • 예외에 대한 정보입니다.
  • 애플리케이션 시작 및 종료 이벤트.
  • 웹 서비스 API 호출의 성공 또는 실패.

동일한 이벤트 집합을 생성하는 도메인 필드를 설정하여 애플리케이션 전체에서 공통 보고서 및 분석 집합을 빌드합니다. 애플리케이션별 이벤트의 세부 정보를 캡처하기 위한 사용자 지정 필드를 포함하도록 스키마를 구성해야 할 수 있습니다.

OpenTelemetry 는 API, SDK 및 기타 도구의 공급업체 중립적 컬렉션입니다. OpenTelemetry를 사용하여 애플리케이션을 계측하고 언어 간에 의미 있는 원격 분석을 일관되게 생성할 수 있습니다. OpenTelemetry는 도구에 구애받지 않으므로 오픈 소스 및 상업용 제품을 비롯한 많은 가시성 플랫폼과 호환됩니다. Microsoft는 계측을 위한 표준 도구로 OpenTelemetry를 채택하고 있습니다.

애플리케이션 계측 모범 사례

다음은 클라우드에서 실행되는 분산 애플리케이션을 계측하기 위한 모범 사례를 요약한 목록입니다.

  • 로그를 쉽게 읽고 구문 분석할 수 있도록 만듭니다. 가능한 경우 구조화된 로깅을 사용합니다.

  • 간결하고 설명적인 로그 메시지를 사용합니다.

  • 로그의 원본을 식별합니다.

  • 각 로그 레코드가 기록되면 타임스탬프 정보를 추가합니다.

  • 모든 타임스탬프에 동일한 표준 시간대와 형식을 사용합니다.

  • 로그를 분류하고 적절한 위치에 메시지를 씁니다.

  • 시스템에 대한 중요한 정보 또는 사용자에 대한 개인 정보를 공개하지 마세요. 기록하기 전에 이 정보를 스크러빙하지만 관련 세부 정보를 유지합니다.

  • 모든 중요한 예외를 기록하지만 관리자는 더 적은 예외 및 경고에 대해 필요에 따라 로깅을 켜고 끌 수 있습니다.

  • 모든 재시도 논리 정보를 캡처하고 로그합니다. 이 데이터는 시스템의 일시적인 상태를 모니터링하는 데 유용합니다.

  • 외부 웹 서비스 또는 데이터베이스에 대한 요청과 같은 프로세스 호출을 추적합니다.

  • 보안 요구 사항이 서로 다른 메시지를 동일한 로그 파일에 혼합하지 마세요.

  • 모든 로깅 호출이 비즈니스 운영 진행을 차단하지 않는 방화 및 잊어버리 기 작업인지 확인합니다. 감사 이벤트는 비즈니스에 중요하므로 이 규칙에서 제외합니다.

  • 로깅이 확장 가능하고 구체적인 대상에 대한 직접적인 종속성이 없는지 확인합니다.

  • 모든 로깅이 실패로부터 안전하며 연속 오류를 트리거하지 않는지 확인합니다.

  • 계측을 지속적인 반복 프로세스로 처리하고 로그를 정기적으로 검토합니다.

고려 사항

  • 시스템에 상당한 오버헤드를 부과할 수 있으므로 필요한 경우에만 프로파일링을 구현합니다. 프로파일링은 계측을 사용하여 발생할 때마다 메서드 호출과 같은 이벤트를 기록합니다. 그러나 샘플링은 선택한 이벤트만 기록합니다.

  • 프로파일링 선택은 시간 기반(예: n 초마다 한 번) 또는 빈도 기반(예: n 개 요청마다 한 번)일 수 있습니다. 이벤트가 자주 발생하는 경우 프로파일링으로 인해 시스템에 너무 많은 부담이 발생하고 전반적인 성능에 영향을 줄 수 있습니다. 이 경우 샘플링 방법이 바람직합니다. 그러나 이벤트의 빈도가 낮을 때는 샘플링이 이벤트를 놓칠 수 있습니다. 이 경우 프로파일링이 더 나은 방법일 수 있습니다.

Azure 촉진

자동 침입 은 Application Insights로 모니터링되는 다양한 유형의 Azure 및 온-프레미스 애플리케이션에 사용할 수 있습니다. 자동 침입 함수는 Application Insights에 풍부한 원격 분석을 제공하도록 애플리케이션을 자동으로 구성하고 애플리케이션 dashboard 및 애플리케이션 맵과 같은 환경에 쉽게 액세스할 수 있도록 합니다. 지원되는 호스팅 플랫폼 및 개발 언어는 지원되는 환경, 언어 및 리소스 공급자를 참조하세요.

운영 우수성 검사 목록

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

운영 우수성 검사 목록