모니터링 및 진단 지침

Azure Monitor

클라우드에서 실행되는 분산 애플리케이션 및 서비스는 특성상, 많은 이동 부분으로 구성되는 복잡한 소프트웨어입니다. 프로덕션 환경에서는 사용자가 시스템을 사용하는 방식을 추적하고, 리소스 사용률을 추적하고, 일반적으로 시스템의 상태와 성능을 모니터링할 수 있는 것이 중요합니다. 이 정보를 진단 보조 기능으로 사용하여 문제를 검색하고 수정할 수 있으며 잠재적 문제를 발견하여 이 문제가 발생하지 않도록 할 수도 있습니다.

모니터링 및 진단 시나리오

모니터링을 사용하여 시스템이 잘 작동하는지 파악할 수 있습니다. 모니터링은 서비스 품질 대상 유지 관리의 중요한 부분입니다. 모니터링 데이터를 수집하는 일반적인 시나리오는 다음과 같습니다.

  • 시스템이 정상 상태를 유지하도록 보장합니다.
  • 시스템 및 구성 요소의 가용성을 추적합니다.
  • 작업 볼륨이 증가함에 따라 시스템의 처리량이 예기치 않게 저하되지 않도록 성능을 유지 관리합니다.
  • 시스템이 고객과 합의된 모든 SLA(서비스 수준 계약)를 충족하도록 보장합니다.
  • 개인 정보를 보호하고 시스템, 사용자 및 해당 데이터의 보안을 보장합니다.
  • 감사 또는 규제 목적으로 수행되는 작업을 추적합니다.
  • 시스템의 일상 사용량을 모니터링하고 해결하지 않을 경우 문제로 발생할 수 있는 추세를 발견합니다.
  • 초기 보고서 및 가능한 원인, 수정, 후속 소프트웨어 업데이트, 배포 등에 대한 분석에서 발생한 문제를 추적합니다.
  • 작업을 추적하고 소프트웨어 릴리스를 디버그합니다.

참고

이 목록은 포괄적이지 않습니다. 이 문서는 모니터링을 수행할 가장 일반적인 상황인 이러한 시나리오에 초점을 맞춥니다. 일반적이지 않거나 사용자 환경에 따른 다른 시나리오가 있을 수 있습니다.

다음 섹션에서는 이러한 시나리오를 자세히 설명합니다. 각 시나리오에 대한 정보는 다음과 같은 형식으로 설명합니다.

  1. 시나리오에 대한 간략한 개요
  2. 이 시나리오의 일반적인 요구 사항
  3. 시나리오를 지원하는 데 필요한 원시 계측 데이터 및 이러한 정보의 가능한 출처
  4. 이 원시 데이터를 분석 및 결합하여 유의미한 진단 정보를 생성할 수 있는 방법

상태 모니터링

시스템이 실행 중이며 요청을 처리할 수 있는 경우 시스템의 상태는 정상입니다. 상태 모니터링의 목적은 시스템의 모든 구성 요소가 예상대로 작동하는지 확인할 수 있도록 시스템의 현재 상태에 대한 스냅샷을 생성하는 것입니다.

상태 모니터링을 위한 요구 사항

시스템의 특정 부분의 상태가 정상이 아닌 것으로 간주되는 경우 신속하게(몇 초 안에) 운영자가 경고를 받아야 합니다. 운영자는 시스템에서 정상적으로 작동하고 있는 부분과 문제가 있는 분을 확인할 수 있어야 합니다. 신호등 시스템을 통해 시스템 상태를 강조 표시할 수 있습니다.

  • 비정상(시스템이 중지됨)이면 빨간색
  • 부분적으로 정상(시스템이 실행되지만 기능이 축소됨)이면 노란색
  • 완전히 정상이면 녹색

포괄적인 상태 모니터링 시스템을 통해 운영자는 시스템을 드릴다운하여 하위 시스템 및 구성 요소의 상태를 볼 수 있습니다. 예를 들어 전체 시스템이 부분적으로 정상인 것으로 표시되는 경우 운영자는 자세히 조사하여 현재 사용할 수 없는 기능을 확인할 수 있어야 합니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

상태 모니터링을 지원하는 데 필요한 원시 데이터는 다음의 결과로 생성될 수 있습니다.

  • 사용자 요청 실행 추적 이 정보를 사용하여 성공한 요청, 실패한 요청 및 각 요청에 걸리는 시간을 확인할 수 있습니다.
  • 가상 사용자 모니터링. 이 프로세스는 사용자가 수행한 단계를 시뮬레이션하고 미리 정의된 일련의 단계를 따릅니다. 각 단계의 결과를 캡처해야 합니다.
  • 예외, 장애 및 경고 기록 이 정보는 애플리케이션 코드에 포함된 추적 문의 결과로 캡처할 수 있고 시스템에서 참조하는 서비스의 이벤트 로그에서 정보를 검색하여 캡처할 수도 있습니다.
  • 시스템에서 사용하는 타사 서비스의 상태를 모니터링합니다. 이 모니터링을 위해 이러한 서비스가 제공하는 상태 데이터를 검색하고 구문 분석해야 할 수 있습니다. 이 정보는 다양한 형식을 취할 수 있습니다.
  • 엔드포인트 모니터링. 이 메커니즘에 대해서는 "가용성 모니터링" 섹션에서 자세히 설명합니다.
  • 백그라운드 CPU 사용률 또는 I/O(네트워크 포함) 활동과 같은 주변 성능 정보 수집

상태 데이터 분석

상태 모니터링의 주요 초점은 시스템이 실행 중인지 여부를 신속하게 나타내는 것입니다. 중요한 구성 요소의 상태가 비정상으로 검색되는 경우 즉시 데이터에 대한 핫 분석이 경고를 트리거할 수 있습니다. (예를 들어 연속된 일련의 ping에 응답하지 않는 경우가 있습니다.) 그러면 운영자는 적절한 정정 작업을 할 수 있습니다.

고급 시스템에는 최근 및 현재 워크로드에 대한 콜드 분석을 수행하는 예측 요소가 포함될 수 있습니다. 콜드 분석은 추세를 발견하고 시스템의 정상 상태가 유지될지 아니면 추가 리소스가 필요할지 여부를 결정합니다. 이 예측 요소는 다음과 같은 중요 성능 메트릭을 기반으로 해야 합니다.

  • 각 서비스 또는 하위 시스템으로 전달되는 요청의 비율입니다.
  • 이러한 요청의 응답 시간입니다.
  • 각 서비스에 대해 유입되거나 유출되는 데이터의 양입니다.

메트릭의 값이 정의된 임계값을 초과하는 경우 시스템에서는 운영자나 크기 자동 조정 기능(사용할 수 있는 경우)이 시스템 상태 유지에 필요한 예방 조치를 취할 수 있도록 경고를 발생시킬 수 있습니다. 이러한 조치에는 리소스를 추가하거나, 장애가 발생한 하나 이상의 서비스를 다시 시작하거나, 우선 순위가 낮은 요청에 제한을 적용하는 작업 등이 포함될 수 있습니다.

가용성 모니터링

시스템이 진정으로 정상 상태가 되려면 시스템을 구성하는 구성 요소 및 하위 시스템이 사용 가능해야 합니다. 가용성 모니터링은 상태 모니터링과 밀접하게 관련됩니다. 하지만 상태 모니터링은 시스템 현재 상태를 즉시 보여 주고 가용성 모니터링은 시스템 및 구성 요소의 가용성을 추적하여 시스템 작동 시간 관련 통계를 생성할 수 있습니다.

많은 시스템에서 예를 들어 데이터베이스와 같은 일부 구성 요소는 중복성이 기본적으로 제공되어 심각한 장애가 발생하거나 연결이 끊어지는 경우 신속한 장애 조치(failover)가 가능하도록 구성되었습니다. 사용자가 이러한 장애가 발생한 것을 인식하지 못하는 것이 가장 좋지만 가용성 모니터링 측면에서 원인을 확인하고 재발을 방지하기 위한 교정 조치를 취하기 위해 최대한 많은 장애 관련 정보를 수집해야 합니다.

가용성을 추적하는 데 필요한 데이터는 다양한 하위 수준 요소에 따라 달라질 수 있습니다. 이러한 많은 요소는 애플리케이션, 시스템 및 환경과 관련될 수 있습니다. 효과적인 모니터링 시스템은 이러한 하위 수준 요소에 해당하는 가용성 데이터를 캡처하고 집계하여 시스템의 전반적인 상태를 알려줍니다. 예를 들어 전자 상거래 시스템에서 고객이 주문할 수 있도록 하는 비즈니스 기능은 주문 세부 정보가 저장되는 리포지토리 및 주문 대금 결제를 위해 화폐 거래를 처리하는 결제 시스템에 종속될 수 있습니다. 따라서 시스템에서 주문하는 부분의 가용성은 해당 리포지토리 및 결제 하위 시스템 기능의 가용성입니다.

가용성 모니터링을 위한 요구 사항

운영자는 또한 각 시스템 및 하위 시스템의 가용성 기록을 보고 이 정보를 이용하여 하나 이상의 하위 시스템에서 주기적으로 장애가 발생하는 원인이 될 수 있는 추세를 발견할 수 있어야 합니다. 예를 들어 하루 중 처리량이 가장 많은 특정 시간대에 서비스 장애가 발생하는지 확인합니다.

모니터링 솔루션은 각 하위 시스템의 가용성 또는 비가용성에 대한 즉시 보기 및 기록 보기를 제공해야 합니다. 또한 하나 이상의 서비스가 실패하거나 사용자가 서비스에 연결할 수 없을 때 신속하게 운영자에게 경고를 보낼 수 있어야 합니다. 이렇게 되려면 각 서비스를 모니터링하는 것뿐만 아니라 서비스와 통신하려고 시도할 때 각 사용자가 수행하는 작업이 실패하는 경우 해당 작업을 검사하는 것도 포함됩니다. 어느 정도까지는, 특정 수준의 연결 장애는 정상이며 일시적인 오류가 원인일 수 있습니다. 하지만 시스템에서 특정 기간 동안 지정된 하위 시스템에 대한 연결 장애가 발생한 횟수에 대해 경고를 발생시킬 수 있게 하면 유용할 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

상태 모니터링의 경우와 마찬가지로 가용성 모니터링을 지원하는 데 필요한 원시 데이터는 가상 사용자 모니터링 및 예외, 장애, 경고 기록의 결과로 생성될 수 있습니다. 또한 엔드포인트 모니터링을 수행하여 가용성 데이터를 가져올 수도 있습니다. 애플리케이션은 각각이 시스템 내의 기능 영역에 대한 액세스를 테스트하는 상태 엔드포인트를 하나 이상 노출할 수 있습니다. 모니터링 시스템은 정의된 일정에 따라 각 엔드포인트를 ping하고 결과(성공 또는 실패)를 수집할 수 있습니다.

모든 시간 제한, 네트워크 연결 실패 및 연결 재시도가 기록되어야 합니다. 모든 데이터는 타임스탬프가 있어야 합니다.

가용성 데이터 분석

다음 유형의 분석을 지원하려면 계측 데이터를 집계하고 서로 연관지어야 합니다.

  • 시스템 및 하위 시스템의 즉각적인 가용성
  • 시스템 및 하위 시스템의 가용성 실패율. 운영자가 장애와 특정 활동을 서로 연관 짓는 것(시스템 장애 시 어떤 상황이었는지 확인하는 것)이 가장 좋습니다.
  • 지정된 기간 동안 시스템 또는 하위 시스템의 실패율 및 장애 발생 시점의 시스템 로드(예: 사용자 요청 개수) 등에 대한 기록 보기
  • 시스템 또는 하위 시스템을 사용할 수 없는 이유. 예를 들어 그 이유는 서비스가 실행되지 않거나, 연결이 끊어지거나, 연결되었지만 시간이 초과했거나, 연결되었지만 오류가 반환되었기 때문일 수 있습니다.

다음 수식을 사용하여 일정 기간에 대한 서비스 가용률을 계산할 수 있습니다.

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

이는 SLA 용도로 유용합니다. (SLA 모니터링에 대해서는 이 가이드 뒷부분에서 자세히 설명합니다.) 가동 중지 시간의 정의는 서비스에 따라 달라집니다. 예를 들어 Visual Studio Team Services 빌드 서비스는 가동 중지 시간을 정의하며 이는 빌드 서비스를 사용할 수 없는 총 누적 시간(분)입니다. 1분 내내 고객이 시작한 작업을 수행하기 위한, 빌드 서비스에 대한 모든 연속 HTTP 요청이 오류 코드를 발생시키거나 응답을 반환하지 않는 경우 해당 시간(분)을 사용할 수 없는 것으로 간주합니다.

성능 모니터링

사용자 수가 증가하여 시스템에 부하가 점점 커지면 이러한 사용자가 액세스하는 데이터 세트의 크기가 커지고 하나 이상의 구성 요소에서 장애가 발생할 가능성이 높아집니다. 대부분의 경우 구성 요소 오류가 발생하기 전에 성능이 저하됩니다. 이러한 저하를 검색할 수 있는 경우 상황을 해결하기 위한 사전 대응적인 조치를 취할 수 있습니다.

시스템 성능은 다양한 요소에 따라 달라집니다. 각 요소는 일반적으로 초당 데이터베이스 트랜잭션 수 또는 지정된 시간 프레임 내에 성공적으로 처리된 네트워크 요청의 볼륨과 같은 KPI(핵심 성과 지표)를 통해 측정됩니다. 이러한 KPI 중 일부는 다른 메트릭의 조합에서 파생될 수 있지만 특정 성능 척도로 사용할 수 있습니다.

참고

성능이 낮은지 양호한지 결정하려면 시스템이 실행할 수 있어야 하는 성능의 수준을 이해해야 합니다. 이렇게 하려면 시스템이 일반적인 부하 상태에서 작동하는 동안 시스템을 관찰하고 일정 기간 동안 각 KPI에 대한 데이터를 캡처해야 합니다. 그러려면 테스트 환경의 시뮬레이트된 부하 상태에서 시스템을 실행하고 시스템을 프로덕션 환경에 배포하기 전에 적절한 데이터를 수집해야 합니다.

또한 성능을 목적으로 한 모니터링이 시스템에 부담이 되지 않도록 해야 합니다. 성능 모니터링 프로세스가 수집하는 데이터에 대한 세부 수준을 동적으로 조정할 수 있습니다.

성능 모니터링을 위한 요구 사항

시스템 성능을 검사하려면 운영자가 일반적으로 다음을 포함하는 정보를 확인할 수 있어야 합니다.

  • 사용자 요청에 대한 응답률
  • 동시 사용자 요청 수
  • 네트워크 트래픽 볼륨
  • 비즈니스 트랜잭션이 완료되는 비율
  • 요청에 대한 평균 처리 시간

운영자가 다음과 같은 상관 관계를 발견할 수 있도록 도구를 제공하면 유용할 수 있습니다.

  • 동시 사용자 수와 요청 대기 시간(사용자가 요청을 보낸 후 요청 처리가 시작될 때까지 걸리는 시간) 비교
  • 동시 사용자 수와 평균 응답 시간(요청 처리가 시작된 후 완료될 때까지 걸리는 시간) 비교
  • 요청의 양과 처리 오류 수 비교

운영자는 이러한 상위 수준 기능 정보와 함께 시스템의 각 구성 요소에 대한 세부적인 성능 보기를 구할 수 있어야 합니다. 이 데이터는 일반적으로 다음과 같은 정보를 추적하는 하위 수준 성능 카운터를 통해 제공됩니다.

  • 메모리 사용률
  • 스레드 수
  • CPU 처리 시간
  • 요청 큐 길이
  • 디스크 또는 네트워크 I/O 비율 및 오류
  • 쓰거나 읽어 들인 바이트 수
  • 미들웨어 표시기(예: 큐 길이)

모든 시각화에서 운영자는 기간을 지정할 수 있어야 합니다. 표시되는 데이터는 현재 상황 및/또는 성능 기록 보기의 스냅샷일 수 있습니다.

운영자는 지정된 시간 간격으로 지정된 값에 대한 성능 측정을 기반으로 경고를 발생시킬 수 있어야 합니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

상위 수준 성능 데이터(처리량, 동시 사용자 수, 비즈니스 트랜잭션 수, 오류 비율 등)는 사용자 요청이 도착하여 시스템에 전달되면 이에 대한 진행률을 모니터링하여 수집할 수 있습니다. 그러려면 애플리케이션 코드의 주요 요소에서 추적 문을 타이밍 정보와 통합해야 합니다. 모든 장애, 예외 및 경고는 발생시킨 요청과의 상관 관계를 설정하도록 충분한 데이터와 함께 캡처해야 합니다. IIS(인터넷 정보 서비스) 로그는 또 하나의 유용한 원본입니다.

가능하면 애플리케이션에 사용되는 외부 시스템에 대한 성능 데이터도 캡처해야 합니다. 이러한 외부 시스템은 고유한 성능 카운터나 성능 데이터를 요청하는 기타 기능을 제공할 수 있습니다. 이렇게 할 수 없는 경우에는 외부 시스템에 대해 수행된 각 요청의 시작 시간과 종료 시간과 같은 정보를 작업 상태(성공, 실패 또는 경고)와 함께 기록합니다. 예를 들어 요청의 시간을 계산하는 데 스톱워치 접근 방식을 사용할 수 있습니다. 즉, 요청이 시작되면 타이머를 시작하고 요청이 완료되면 타이머를 중지합니다.

시스템의 개별 구성 요소에 대한 하위 수준 성능 데이터는 Windows 성능 카운터, Azure Diagnostics 등과 같은 기능 및 서비스를 통해 사용할 수 있습니다.

성능 데이터 분석

분석 작업의 상당 부분은 사용자 요청 유형 및/또는 전송된 각 요청을 받는 하위 시스템이나 서비스를 기준으로 성능 데이터를 집계하는 작업으로 구성됩니다. 사용자 요청은 예를 들어 쇼핑 카트에 항목을 추가 또는 전자 상거래 시스템에서 체크 아웃 프로세스를 수행하는 것입니다.

다른 일반적인 요구 사항은 선택한 백분위수로 성능 데이터를 요약하는 것입니다. 예를 들어 운영자가 요청 중 99퍼센트, 요청 중 95퍼센트, 요청 중 70퍼센트 등에 해당하는 응답 시간을 결정할 수 있습니다. 각 백분위수에 대한 SLA 목표 또는 기타 목표를 설정할 수 있습니다. 결과는 즉각적인 문제를 검색할 수 있도록 거의 실시간으로 보고해야 합니다. 또한 통계 용도로 장기간에 걸쳐 집계하여 지속적으로 보고해야 합니다.

성능에 영향을 주는 대기 시간 문제가 있는 경우 운영자는 각 요청에서 수행하는 각 단계의 대기 시간을 검사하여 병목 상태의 원인을 신속하게 식별할 수 있어야 합니다. 따라서, 성능 데이터는 각 단계에 대한 성능 척도와 특정 요청을 연계시킬 수 있는 상관 관계를 설정하는 수단을 제공해야 합니다.

시각화 요구에 따라 원시 데이터의 뷰를 포함하는 데이터 큐브를 생성하고 저장하는 것이 유용할 수 있습니다. 이 데이터 큐브는 복잡한 임시 쿼리 및 성능 정보의 분석을 허용할 수 있습니다.

보안 모니터링

중요한 데이터가 포함된 모든 상용 시스템은 보안 구조를 구현해야 합니다. 보안 메커니즘의 복잡도는 일반적으로 데이터의 민감도의 기능입니다. 사용자가 인증되어야 하는 시스템에서 다음을 기록해야 합니다.

  • 실패 또는 성공한 모든 로그인 시도
  • 인증된 사용자가 수행한 모든 작업과 액세스한 모든 리소스에 대한 세부 정보입니다.
  • 사용자가 세션을 종료하고 로그아웃한 경우

모니터링은 시스템에 대한 공격을 검색하는 데 도움을 줄 수 있습니다. 예를 들어 실패한 로그인 시도가 많다면 이는 무차별 암호 대입 공격(brute force attack)을 나타낼 수 있습니다. DDos(배포된 서비스 거부) 공격의 결과로 요청의 수가 예기치 않게 급증한 것일 수 있습니다. 이러한 요청의 출처에 관계없이 모든 리소스에 대한 모든 요청을 모니터링할 수 있도록 준비해야 합니다. 로그인 취약성을 가진 시스템은 사용자의 실제 로그인을 요구하지 않고 실수로 리소스를 외부에 노출할 수 있습니다.

보안 모니터링을 위한 요구 사항

보안 모니터링의 가장 중요한 측면은 운영자가 신속하게 다음을 수행할 수 있게 만드는 것입니다.

  • 인증되지 않은 엔터티에 의한 침투 시도 검색
  • 액세스 권한을 부여받지 않은 엔터티에 의한 데이터 작업 수행 시도 식별
  • 시스템 또는 시스템의 일부분이 외부 또는 내부로부터 공격을 당하는지 여부 확인 (예: 인증받은 악의적인 사용자가 시스템을 중단시키려고 시도할 수 있음)

이러한 요구 사항을 지원하려면 다음과 같은 경우 운영자에게 알려야 합니다.

  • 한 계정이 지정된 기간 내에 로그인 시도에 반복적으로 실패합니다.
  • 하나의 인증된 계정이 지정된 기간 동안 금지된 리소스에 반복적으로 액세스를 시도합니다.
  • 지정된 기간 동안 많은 수의 인증되지 않았거나 승인되지 않은 요청이 발생합니다.

운영자에게 제공되는 정보에는 각 요청에 대한 출처의 호스트 주소가 포함되어야 합니다. 특정 주소 범위에서 보안 위반이 주기적으로 발생하는 경우 해당 호스트는 차단될 수 있습니다.

시스템 보안을 유지하는 데 핵심적인 부분은 일상적인 패턴에서 벗어난 작업을 신속하게 감지하는 능력입니다. 실패한/성공한 로그인 요청 횟수와 같은 정보를 시각적으로 표시하여 일상적이지 않은 시간에 활동이 급격히 증가하는지 여부를 검색하는 데 도움을 줄 수 있습니다. 예를 들어 근무일은 오전 9시에 시작되는데 사용자가 오전 3시에 로그인하여 다수의 작업을 수행한 경우 등입니다. 이 정보는 시간 기반 자동 크기 조정을 구성하는 데에도 유용하게 사용할 수 있습니다. 예를 들어 다수의 사용자가 정기적으로 특정 시간에 로그인하는 것이 관찰되는 경우 운영자는 해당 작업 볼륨을 처리하는 추가 인증 서비스를 시작한 다음 최대 사용 시간이 지나면 이 추가 서비스를 종료하도록 설정할 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

보안은 대부분의 분산 시스템의 포괄적인 측면입니다. 관련 데이터는 시스템 전체의 여러 지점에서 생성될 수 있습니다. 애플리케이션, 네트워크 장비, 서버, 방화벽, 바이러스 백신 소프트웨어 및 기타 침입 방지 요소에서 발생하는 이벤트로 인한 보안 관련 정보를 수집하기 위해 SIEM(보안 정보 및 이벤트 관리) 접근 방식을 채택해야 할 수 있습니다.

보안 모니터링은 애플리케이션의 일부로 제공되지 않는 도구에서 제공되는 데이터를 통합할 수 있습니다. 이러한 도구에는 외부 에이전시의 포트 검색 활동을 식별하는 유틸리티 또는 애플리케이션 및 데이터에 대한 인증되지 않은 액세스 시도를 검색하는 네트워크 필터가 포함될 수 있습니다.

모든 경우에 수집된 데이터는 관리자가 공격의 특성을 확인하고 적합한 대응 조치를 취할 수 있게 해야 합니다.

보안 데이터 분석

보안 모니터링의 특성은 데이터가 발생하는 원본의 다양성입니다. 다양한 형식과 세부 정보 수준으로 인해 캡처된 데이터를 일관된 정보 스레드로 묶으려면 복잡한 데이터 분석이 필요한 경우가 많습니다. 간단한 경우(예: 실패한 로그인 여러 번 검색 또는 중요한 리소스에 무단 액세스하려는 시도 반복)와 달리, 보안 데이터에 대해 복잡한 자동화 처리를 수행하는 것이 불가능할 수 있습니다. 이런 때는 대신 전문가의 수동 분석이 가능하도록 보안 리포지토리에 이 데이터를 원래 형식으로 쓰고 타임스태프를 지정하는 것이 더 습니다.

SLA 모니터링

유료 고객을 지원하는 다수의 상용 시스템은 SLA의 형태로 시스템 성능을 보증합니다. 기본적으로, SLA는 합의된 시간 프레임 내에 시스템이 중요한 정보의 손실 없이 정의된 작업 볼륨을 처리할 수 있다고 진술합니다. SLA 모니터링은 시스템이 측정 가능한 SLA를 충족할 수 있도록 보장하기 위한 것입니다.

참고

SLA 모니터링은 성능 모니터링과 밀접하게 관련되어 있습니다. 그러나 성능 모니터링은 시스템이 최적으로 작동할 수 있도록 보장하는 것과 관련 있는 반면, SLA 모니터링에는 최적으로라는 말이 실제로 의미하는 바를 정의하는 계약 의무가 적용됩니다.

SLA는 흔히 다음과 같은 조건으로 정의됩니다.

  • 전체 시스템 가용성. 예를 들어 조직이 시스템의 가용 시간을 99.9퍼센트로 보장하는 경우입니다. 이 비율은 연간 가동 중지 시간 9시간 이하 또는 주당 약 10분과 같습니다.
  • 작업 처리량. 이 측면은 종종 하나 이상의 중요 최고 수위 표시로 표현됩니다(예: 시스템이 최대 100,000개의 동시 사용자 요청을 지원하거나 10,000개의 동시 비즈니스 트랜잭션을 처리할 수 있다는 보장).
  • 작업 응답 시간. 시스템의 요청 처리 비율과 관련하여 보장할 수도 있습니다. 예를 들어 모든 비즈니스 트랜잭션의 99퍼센트를 2초 내에 완료하거나 어떠한 트랜잭션도 10초 이내에 완료되도록 보장합니다.

참고

상용 시스템에 대한 일부 계약에는 고객 지원 관련 SLA가 포함되기도 합니다. 예를 들어 모든 헬프 데스크 요청은 5분 이내에 응답을 이끌어내고 모든 문제의 99%는 1영업일 이내에 완전히 해결됩니다. 효과적인 문제 추적 (이 섹션 뒷부분에서 설명함)이 이러한 SLA를 충족하는 데 핵심입니다.

SLA 모니터링을 위한 요구 사항

최상위 수준에서 운영자는 시스템이 합의된 SLA를 충족하는지 여부를 한눈에 확인할 수 있어야 합니다. 충족하지 않는 경우에는 운영자가 기본 요소를 드릴다운하고 검사하여 성능이 표준에 미치지 못하는 이유를 확인할 수 있어야 합니다.

시각적으로 표시할 수 있는 일반적인 상위 수준 표시기에는 다음이 포함됩니다.

  • 서비스 작동 시간 백분율
  • 애플리케이션 처리량(초당 성공한 트랜잭션 및/또는 작업 수를 기준으로 측정함)
  • 성공/실패한 애플리케이션 요청 수
  • 애플리케이션 및 시스템 장애, 예외, 경고 수

이러한 표시기는 모두 지정된 기간을 기준으로 필터링할 수 있어야 합니다.

클라우드 애플리케이션은 다수의 하위 시스템 및 구성 요소로 구성되는 경우가 있습니다. 운영자는 상위 수준 표시기를 선택하여 기본 요소의 상태에서 작성되는 방식을 확인할 수 있어야 합니다. 예를 들어 전체 시스템의 작동 시간이 허용되는 값 미만으로 떨어지는 경우 운영자는 자세히 조사하여 이 장애를 야기하는 요소를 확인할 수 있어야 합니다.

참고

시스템 작동 시간을 신중하게 정의해야 합니다. 중복성을 사용하여 최대 가용성을 보장하는 시스템에서는 요소의 개별 인스턴스에서 장애가 발생했지만 시스템은 계속 작동할 수 있습니다. 상태 모니터링에 의해 표시되는 시스템 작동 시간은 반드시 시스템이 실제로 중지되었는지 여부를 나타낼 필요 없이 각 요소의 집계 작동 시간을 나타내야 합니다. 또한 장애를 격리할 수 있습니다. 따라서 특정 시스템을 사용할 수 없는 경우에도 시스템의 나머지 부분은 기능이 감소되기는 해도 여전히 사용 가능할 수 있습니다. 예를 들어 전자 상거래 시스템에서 시스템의 장애로 인해 고객이 주문할 수 없지만 제품 카탈로그를 찾아볼 수는 있습니다.

경고를 보낼 목적으로, 시스템은 상위 수준 표시기가 지정 임계값을 초과하는 경우 이벤트를 발생시킬 수 있어야 합니다. 상위 수준 표시기를 구성하는 다양한 요소에 대한 하위 수준 세부 정보를 경고 시스템에 대한 컨텍스트 데이터로 사용할 수 있어야 합니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

SLA 모니터링을 지원하는 데 필요한 원시 데이터는 성능 모니터링과 상태 및 가용성 모니터링의 일부 측면과 함께, 성능 모니터링에 필요한 원시 데이터와 비슷합니다. (자세한 내용은 해당 섹션을 참조하세요.) 다음을 통해 이 데이터를 캡처할 수 있습니다.

  • 엔드포인트 모니터링 수행
  • 예외, 장애 및 경고 기록
  • 사용자 요청 실행 추적
  • 시스템에서 사용하는 타사 서비스의 가용성 모니터링
  • 성능 메트릭 및 카운터 사용

모든 데이터는 시간과 시간이 기록되어야 합니다.

SLA 데이터 분석

시스템의 전반적인 성능에 대한 보기를 생성할 수 있도록 계측 데이터를 집계해야 합니다. 집계된 데이터는 또한 기본 하위 시스템 성능을 검사할 수 있도록 드릴 다운을 지원해야 합니다. 예를 들어 다음을 수행할 수 있어야 합니다.

  • 지정된 기간 동안의 총 사용자 요청 수를 계산하고 이 요청의 성공 및 실패 비율을 확인합니다.
  • 사용자 요청 응답 시간을 결합하여 시스템 응답 시간 전체 보기를 생성합니다.
  • 사용자 요청 진행률을 분석하여 요청의 전체 응답 시간을 해당 요청 내의 개별 작업 항목의 응답 시간으로 나눕니다.
  • 특정 기간에 대한 시스템 전체 가용성을 작동 시간의 백분율로 결정합니다.
  • 시스템의 개별 구성 요소 및 서비스의 가용 시간 백분율을 분석합니다. 이렇게 하려면 타사 서비스에서 구문 분석 로그를 생성해야 할 수 있습니다.

다수의 상용 시스템에서는 합의된 SLA와 비교하여 지정 기간(일반적으로 월 단위)에 대한 실제 성능 수치를 보고해야 합니다. 해당 기간 동안 SLA가 충족되지 않은 경우 이 정보를 사용하여 고객에 대한 크레딧 또는 다른 형태의 상환을 계산할 수 있습니다. 가용성 데이터 분석 섹션에서 설명하는 기술을 사용하여 서비스에 대한 가용성을 계산할 수 있습니다.

내부 용도로, 조직은 서비스 장애를 야기한 인시던트의 개수와 특성을 추적할 수도 있습니다. 이러한 문제를 신속하게 해결하거나 완전히 제거하는 방법을 알아두면 가동 중지 시간을 줄이고 SLA를 충족하는 데 도움이 됩니다.

감사

애플리케이션의 특성에 따라 사용자의 작업을 감사하고 모든 데이터 액세스를 기록하는 데 요구 사항을 지정하는 법적 규정 또는 기타 법률 규정이 있을 수 있습니다. 감사는 고객과 특정 요청을 연결하는 증거를 제공할 수 있습니다. 거부 없음은 많은 e-비즈니스 시스템에서 애플리케이션 또는 서비스를 담당하는 조직과 고객 사이의 신뢰를 유지하는 데 도움을 주는 중요한 요소입니다.

감사를 위한 요구 사항

분석가는 사용자의 작업을 다시 생성할 수 있도록 사용자가 수행하는 비즈니스 작업 시퀀스를 추적할 수 있어야 합니다. 이 기능은 단순히 기록으로만 필요할 수도 있고 법정 조사의 일부로 필요할 수도 있습니다.

감사 정보는 매우 중요합니다. 감사 정보는 시스템 사용자 및 이러한 사용자가 수행 중인 작업을 식별하는 데이터가 포함될 수 있습니다. 이러한 이유로 감사 정보는 그래픽 작업의 드릴다운을 지원하는 대화형 시스템이 아니라 신뢰할 수 있는 분석가만 사용 가능한 보고서 형태가 될 가능성이 매우 높습니다. 분석가는 다양한 보고서를 생성할 수 있어야 합니다. 예를 들어 보고서는 지정된 시간 프레임에 발생하는 모든 사용자 활동을 나열하거나, 단일 사용자의 활동을 연대순으로 설명하거나, 하나 이상의 리소스에 대해 수행되는 시퀀스 작업을 나열할 수 있어야 합니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

감사 대상 정보의 기본 출처에는 다음이 포함될 수 있습니다.

  • 사용자 인증을 관리하는 보안 시스템
  • 사용자 활동을 기록하는 추적 로그
  • 식별할 수 있거나 식별할 수 없는 모든 네트워크 요청을 추적하는 보안 로그

감사 데이터의 형식과 이 데이터가 저장되는 방식은 규제 요구 사항에 의해 결정될 수 있습니다. 예를 들어 어떤 방식으로든 데이터를 지우는 것이 불가능할 수 있습니다. (원래 형식으로 기록되어야 합니다.) 변조를 방지하기 위해 데이터가 보관된 리포지토리에 대한 액세스를 보호해야 합니다.

감사 데이터 분석

분석가는 원래 형식의 원시 데이터 그 자체에 액세스할 수 있어야 합니다. 일반적인 감사 보고서를 생성하기 위한 요구 사항과 별도로, 이 데이터의 분석에 사용되는 도구는 특수화되어 시스템 외부에 보관될 가능성이 높습니다.

사용 모니터링

사용 모니터링은 애플리케이션의 기능 및 구성 요소가 사용되는 방법을 추적합니다. 운영자는 수집된 데이터를 사용할 수 있습니다.

  • 매우 많이 사용되는 기능을 확인하고 시스템의 모든 잠재적인 핫스팟을 결정합니다. 트래픽이 많은 요소의 경우 기능 분할이나 복제를 통해 보다 균등하게 부하를 분산하면 유리합니다. 또한 운영자는 이 정보를 사용하여 자주 사용되지 않는 기능, 이후 버전의 시스템에서 사용 중지하거나 대체할 후보가 될 수 있는 기능 등을 확인할 수도 있습니다.

  • 시스템에서 정상적으로 사용 중인 작업 이벤트에 대한 정보를 가져옵니다. 예를 들어 전자 상거래 사이트에서 거래 개수 및 해당 거래를 담당하는 고객 수에 대한 통계 정보를 기록할 수 있습니다. 고객 수가 증가함에 따라 용량을 계획하는 데 이 정보를 사용할 수 있습니다.

  • 시스템의 성능이나 기능에 대한 사용자의 만족도를 (간접적으로) 감지합니다. 예를 들어 전자 상거래 시스템에서 다수의 고객이 정기적으로 쇼핑 카트를 취소한다면 이는 체크 아웃 기능에 문제가 있기 때문일 수 있습니다.

  • 대금 청구 정보를 생성합니다. 상용 애플리케이션 또는 다중 테넌트 서비스는 고객이 사용하는 리소스에 대해 고객에게 청구할 수 있습니다.

  • 할당량을 적용합니다. 다중 테넌트 시스템에서 사용자가 지정 기간 동안 처리 시간 또는 리소스 사용 유료 할당량을 초과하는 경우 이 사용자의 액세스 권한이 제한되거나 처리가 제한될 수 있습니다.

사용 모니터링을 위한 요구 사항

시스템 사용량을 검사하려면 운영자가 일반적으로 다음을 포함한 정보를 확인할 수 있어야 합니다.

  • 각 하위 시스템에서 처리되어 각 리소스로 전달되는 요청의 수
  • 각 사용자가 수행 중인 작업
  • 각 사용자가 차지한 데이터 스토리지 볼륨
  • 각 사용자가 액세스 중인 리소스

운영자는 그래프도 생성할 수 있어야 합니다. 예를 들어 그래프에는 리소스가 가장 부족한 사용자, 가장 자주 액세스되는 리소스 또는 시스템 기능이 표시될 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

비교적 높은 수준에서 사용 추적을 수행할 수 있습니다. 각 요청의 시작 시간과 종료 시간 및 요청의 특성(해당 리소스에 따라 읽기, 쓰기 등)을 확인할 수 있습니다. 이러한 정보는 다음 방법을 통해 얻을 수 있습니다.

  • 사용자 활동 추적
  • 각 리소스의 사용률을 측정하는 성능 카운터 캡처
  • 각 사용자의 리소스 사용을 모니터링합니다.

측정 목적을 위해 어떤 사용자가 어떤 작업을 수행할 책임이 있고 이러한 작업에서 사용하는 리소스를 식별할 수 있어야 합니다. 청구할 수 있을 정도로 충분히 자세한 정보를 수집해야 합니다.

문제 추적

시스템에서 예기치 않은 이벤트나 동작이 발생하는 경우 고객 및 다른 사용자가 문제를 보고할 수 있습니다. 문제 추적은 이러한 문제를 관리하고, 시스템의 기본 문제를 해결하기 위한 작업을 이러한 문제와 연결하고, 가능한 해결 방법을 고객에게 알리는 기능입니다.

문제 추적을 위한 요구 사항

운영자는 사용자가 보고하는 문제의 세부 정보를 기록하고 보고할 수 있는 별도 시스템을 사용하여 문제 추적을 수행하는 경우가 많습니다. 이러한 세부 정보에는 사용자가 수행하려고 시도한 작업, 문제의 증상, 이벤트 시퀀스, 발생한 오류 또는 경고 메시지가 포함될 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

문제 추적 데이터의 초기 데이터 출처는 처음에 문제를 보고한 사용자입니다. 사용자는 다음과 같은 추가 데이터를 제공할 수 있습니다.

  • 크래시 덤프(애플리케이션에 사용자 데스크톱에서 실행되는 구성 요소가 포함되는 경우)
  • 화면 스냅샷.
  • 사용자 위치 등의 다른 환경 정보와 함께 오류가 발생한 날짜/시간

이 정보를 사용하여 디버깅 작업에 공급하고 소프트웨어 향후 릴리스에 대한 백로그를 생성하는 데 도움을 줄 수 있습니다.

문제 추적 데이터 분석

여러 사용자가 동일한 문제를 보고할 수 있습니다. 문제 추적 시스템은 공통적인 보고서를 함께 연결합니다.

각 문제 보고서에 대해 디버깅 작업의 진행 상황을 기록해야 합니다. 문제가 해결되면 고객이 이러한 해결 방법에 대해 알림을 받을 수 있습니다.

사용자가 문제 추적 시스템에 알려진 해결 방법이 있는 문제를 보고하는 경우 운영자는 해당 사용자에게 해결 방법을 즉시 알릴 수 있어야 합니다.

작업 추적 및 소프트웨어 릴리스 디버그

사용자가 문제를 보고할 때 사용자는 종종 작업에 미치는 즉각적인 영향만 인식합니다. 사용자는 시스템을 유지 관리하는 운영자에게 사용자 자신의 경험에서 나온 결과만 보고할 수 있습니다. 이러한 경험은 일반적으로 하나 이상의 근본적인 문제의 가시적 증상일 뿐입니다. 많은 경우 분석가가 기본 작업을 연대순으로 심도 있게 분석하여 문제의 근본 원인을 파악해야 합니다. 이 프로세스를 근본 원인 분석이라고 합니다.

참고

근본 원인 분석 결과, 애플리케이션의 설계에서 비효율성이 발견될 수 있습니다. 이런 경우에는 영향을 받은 요소를 다시 작업해서 후속 릴리스의 일부로 배포할 수 있습니다. 이 프로세스는 세심하게 제어해야 하며, 업데이트된 구성 요소를 면밀하게 모니터링해야 합니다.

추적 및 디버깅을 위한 요구 사항

예기치 않은 이벤트 및 기타 문제를 추적하려면 분석가가 이 문제의 근원을 추적하고 발생한 이벤트 시퀀스를 다시 생성할 수 있도록 모니터링 데이터가 세부 정보를 포함하여 충분한 정보를 제공하는 것이 매우 중요합니다. 이 정보는 분석가가 모든 문제의 근본 원인을 진단할 수 있도록 충분해야 합니다. 개발자는 문제 재발을 방지하기 위해 필요한 사항을 수정할 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

문제 해결에는 고객이 특정 요청을 하는 경우 시스템 내에서 이루어지는 논리 흐름을 설명하는 트리를 작성하는 작업 도중에 호출되는 모든 메서드 및 해당 매개 변수를 추적하는 작업이 필요할 수 있습니다. 이 흐름의 결과로 시스템에서 생성하는 예외 및 경고는 캡처하고 기록해야 합니다.

디버깅을 지원하기 위해 시스템은 운영자가 시스템의 중요 지점에서 상태 정보를 캡처할 수 있게 하는 후크를 제공할 수 있습니다. 또는 선택한 작업을 진행하는 자세한 단계별 정보를 제공할 수 있습니다. 이 세부 수준으로 데이터를 캡처하는 작업은 시스템에 부하를 더할 수 있으며 임시 프로세스여야 합니다. 운영자는 아주 특수한 일련의 이벤트가 발생할 때나 시스템에 하나 이상의 요소를 새로 릴리스하면서 이 요소가 예상대로 작동하는지 확인하기 위해 세심하게 모니터링해야 할 때 주로 이 프로세스를 사용합니다.

모니터링 및 진단 파이프라인

대규모 분산 시스템을 모니터링하는 것은 상당한 과제입니다. 이전 섹션에서 설명한 각 시나리오를 별개로 고려해서는 안 됩니다. 각 상황에 필요한 모니터링 데이터와 진단 데이터는 처리 및 표시 방식이 서로 다를 수는 있지만 상당히 중복될 가능성이 있습니다. 이러한 이유로, 모니터링 및 진단에 대한 전체적인 뷰를 확인해야 합니다.

전체 모니터링 및 진단 프로세스를 그림 1에 나오는 단계를 구성하는 파이프라인으로 그려 볼 수 있습니다.

모니터링 및 진단 파이프라인의 단계

그림 1 - 모니터링 및 진단 파이프라인의 단계

그림 1에서는 모니터링 및 진단을 위한 데이터를 다양한 데이터 소스에서 가져올 수 있는 방법을 보여 줍니다. 계측 및 수집 단계는 데이터를 캡처할 원본을 식별하고, 캡처할 데이터, 데이터 캡처 방법, 쉽게 검사할 수 있도록 이 데이터의 형식을 지정하는 방법 등을 결정하는 작업과 관련이 있습니다. 분석/진단 단계에서는 원시 데이터를 가져와 이 데이터를 사용하여 운영자가 시스템 상태를 확인하는 데 사용 가능한 유의미한 정보를 생성합니다. 운영자는 이 정보를 사용하여 취할 수 있는 조치에 대한 의사 결정을 내릴 수 있으며 결과를 다시 계측 및 수집 단계로 공급할 수 있습니다. 시각화/경고 단계에서는 시스템 상태에 대한 사용 가능한 뷰를 표시합니다. 이 뷰는 일련의 대시보드를 사용해 실시간에 가깝게 정보를 표시할 수 있으며 장기적인 추세를 식별하는 데 유용할 수 있는 데이터 기록 보기를 제공하는 보고서, 그래프 및 차트를 생성할 수 있습니다. 이 정보가 KPI가 허용 범위를 초과할 수 있음을 나타내는 경우 이 단계에서도 운영자에게 경고를 트리거할 수 있습니다. 일부 경우, 자동 크기 조정과 같은 정정 작업을 시도하는 자동화된 프로세스를 트리거하는 데 경고를 사용할 수도 있습니다.

이러한 단계는 병렬로 단계가 수행되는 연속 흐름 프로세스를 구성합니다. 모든 단계를 동적으로 구성할 수 있으면 가장 좋습니다. 일부 경우, 특히 시스템을 새로 배포했거나 시스템에서 문제가 발생할 때 더 자주 확장 데이터를 수집해야 할 수 있습니다. 다른 경우에는 기본 수준의 필수 정보 캡처로 되돌아가 시스템이 제대로 작동하고 있는지 확인할 수 있어야 합니다.

또한 전체 모니터링 프로세스를 피드백의 결과에 따라 미세하게 조정하고 개선하는 지속적인 라이브 솔루션으로 고려해야 합니다. 예를 들어 처음 시작할 때는 시스템 상태를 확인하기 위해 많은 요소를 측정했습니다. 시간이 지남에 따라 분석을 거쳐 관련성 없는 측정값을 취소하면서 조정하게 되며 이에 따라 백그라운드 노이즈를 최소화하며 필요한 데이터에 더 정확히 초점을 맞출 수 있게 됩니다.

모니터링 및 진단 데이터의 소스

모니터링 프로세스에서 사용하는 정보는 그림 1에 나온 것처럼 여러 원본에서 올 수 있습니다. 애플리케이션 수준에서 이 정보는 시스템의 코드에 통합된 추적 로그에서 가져옵니다. 개발자는 코드 전체의 제어 흐름을 추적하기 위한 표준 접근 방식을 따라야 합니다. 예를 들어 메서드로 들어갈 때 메서드 이름, 현재 시간, 각 매개 변수의 값, 기타 영구 정보 등을 지정하는 추적 메시지를 내보낼 수 있습니다. 진입 시간과 종료 시간을 기록하는 것도 유용합니다.

모든 예외 및 경고를 기록해야 하며 모든 중첩된 예외 및 경고에 대한 전체 추적 내용을 보존해야 합니다. 코드를 실행하는 사용자를 식별하는 정보도 작업 상관 관계 정보와 함께 캡처(시스템 전체적으로 전달되는 과정에서 요청을 추적하기 위해)하고 메시지 큐, 데이터베이스, 파일 및 다른 종속 서비스와 같은 모든 리소스에 대한 액세스 시도를 기록하는 것이 가장 좋습니다. 이 정보는 계량 및 감사 용도로 사용할 수 있습니다.

많은 애플리케이션이 네트워크를 통해 데이터 저장소에 액세스하는 등의 일반적인 작업을 수행하는 데 라이브러리 및 프레임워크를 활용합니다. 이 프레임워크는 고유한 추적 메시지뿐만 아니라 트랜잭션 속도와 데이터 전송 성공 및 실패와 같은 원시 진단 정보도 제공하도록 구성될 수 있습니다.

참고

많은 최신 프레임워크에서 성능 및 추적 이벤트를 자동으로 게시합니다. 이 정보를 캡처하도록 하려면 정보를 검색하여 처리 및 분석할 수 있는 위치에 저장할 수 있는 수단을 제공하기만 하면 됩니다.

애플리케이션이 실행되는 운영 체제는 I/O 비율, 메모리 사용률, CPU 사용량과 같은 시스템 전체의 하위 수준 정보의 출처가 될 수 있습니다. 예를 들어 파일을 올바르게 열지 못하는 경우와 같은 운영 체제 오류도 보고할 수 있습니다.

또한 시스템을 실행하는 기본 인프라 및 구성 요소도 고려해야 합니다. 가상 머신, 가상 네트워크 및 스토리지 서비스는 모두 인프라 수준의 중요 성능 카운터 및 다른 진단 데이터의 소스가 될 수 있습니다.

애플리케이션에서 웹 서버나 데이터베이스 관리 시스템 같은 다른 외부 서비스를 사용하는 경우 이러한 서비스가 고유한 추적 정보, 로그 및 성능 카운터를 게시할 수 있습니다. SQL Server 데이터베이스에 대해 수행되는 작업을 추적하는 SQL Server 동적 관리 뷰, 웹 서버에 대한 요청을 기록하는 IIS 추적 로그 등을 예로 들 수 있습니다.

시스템의 구성 요소가 수정되고 새로운 버전이 배포됨에 따라 문제, 이벤트, 메트릭 등이 어느 버전에서 비롯된 것인지 식별할 수 있어야 합니다. 특정 버전의 구성 요소에서 발생한 문제를 신속하게 추적하고 수정할 수 있도록 이 정보를 다시 릴리스 파이프라인에 연계해야 합니다.

보안 문제는 시스템의 어느 지점에서나 발생할 수 있습니다. 예를 들어 사용자가 잘못된 사용자 ID나 암호로 로그인하려고 시도할 수 있습니다. 인증된 사용자가 리소스를 무단으로 액세스하려고 시도할 수 있습니다. 또는 사용자가 암호화된 정보에 액세스하기 위해 잘못되었거나 오래된 키를 제공할 수 있습니다. 성공한 요청 및 실패한 요청에 대한 보안 관련 정보는 항상 로그에 기록해야 합니다.

애플리케이션 계측 섹션에 캡처해야 하는 정보에 대한 추가 지침이 포함되어 있습니다. 그러나 이 정보를 수집하는 데 다양한 전략을 사용할 수 있습니다.

  • 애플리케이션/시스템 모니터링. 이 전략은 애플리케이션, 애플리케이션 프레임워크, 운영 체제 및 인프라 내에 있는 내부 원본을 사용합니다. 애플리케이션 코드가 클라이언트 요청 수명 주기 동안 중요 지점에서 고유한 모니터링 데이터를 생성할 수 있습니다. 애플리케이션에 상황에 따라 선택적으로 사용 또는 사용 안 함으로 설정될 수 있는 추적 문을 포함할 수 있습니다. 진단 프레임워크를 사용하여 진단을 동적으로 삽입하는 것도 가능합니다. 이러한 프레임워크에는 일반적으로 코드 내의 다양한 계측 지점에 연결하여 이 지점에서 추적 데이터를 캡처할 수 있는 플러그 인이 있습니다.

    또한 코드 및/또는 기본 인프라가 중요 지점에서 이벤트를 발생시킬 수도 있습니다. 이러한 이벤트를 수신 대기하도록 구성된 모니터링 에이전트가 이벤트 정보를 기록할 수 있습니다.

  • 실제 사용자 모니터링. 이 접근 방식은 사용자와 애플리케이션 사이의 상호 작용을 기록하고 각 요청과 응답의 흐름을 관찰합니다. 이 정보에는 두 가지 목적이 있을 수 있습니다. 첫째, 이 정보를 사용하여 각 사용자의 사용 현황을 계량할 수 있습니다. 둘째, 이 정보를 사용하여 사용자가 적절한 서비스 품질(예: 빠른 응답 시간, 짧은 대기 시간, 최소한의 오류)을 받고 있는지 여부를 확인할 수 있습니다. 캡처된 데이터를 사용하여 가장 자주 장애가 발생하는 영역을 식별할 수 있습니다. 또한 데이터를 사용하여 애플리케이션의 핫스팟이나 다른 형태의 병목 상태로 인한 시스템 속도 저하가 일어나는 요소를 식별할 수 있습니다. 이 접근 방식을 주의 깊게 구현한다면 디버깅 및 테스트 용도로 애플리케이션에서 사용자의 흐름을 다시 생성할 수 있습니다.

    중요

    실제 사용자를 모니터링하여 캡처되는 데이터는 기밀 자료가 포함될 수 있기 때문에 매우 중요한 데이터로 간주해야 합니다. 캡처된 데이터를 저장하는 경우 안전하게 저장합니다. 이 데이터를 성능 모니터링이나 디버깅 목적으로 사용하는 경우에는 먼저 개인 식별이 가능한 모든 정보를 제거해야 합니다.

  • 가상 사용자 모니터링. 이 접근 방식에서는 사용자를 시뮬레이트하는 고유한 테스트 클라이언트를 작성하고 구성 가능하면서도 일반적인 일련의 작업을 수행합니다. 테스트 클라이언트의 성능을 추적하여 시스템 상태를 확인할 수 있습니다. 부하 테스트 작업의 일환으로 테스트 클라이언트 인스턴스를 여러 개 사용하여 부하가 높은 조건에서 시스템이 응답하는 방식뿐만 아니라 이런 조건에서 생성되는 모니터링 출력의 종류도 설정할 수 있습니다.

    참고

    메서드 호출 및 애플리케이션의 다른 중요 부분의 실행을 추적하고 실행 시간을 지정하는 코드를 포함하여 실제 사용자 모니터링 및 가상 사용자 모니터링을 구현할 수 있습니다.

  • 프로파일링. 이 접근 방식은 애플리케이션 성능을 모니터링하고 개선하는 것을 주요 목표로 합니다. 실제 사용자 모니터링 및 가상 사용자 모니터링의 기능 수준에서 작업하는 것보다 애플리케이션이 실행될 때 하위 수준 정보를 캡처합니다. 프로파일링은 애플리케이션의 실행 상태를 주기적으로 샘플링(지정된 시점에 애플리케이션이 실행 중인 코드 조각 확인)하여 구현할 수 있습니다. 또한 코드의 중요 지점(예: 메서드 호출 시작 및 종료)에 프로브를 삽입하고 호출된 메서드, 호출된 시간, 각 호출에 걸린 시간 등을 기록하는 계측을 사용할 수 있습니다. 그런 다음, 이 데이터를 분석하여 애플리케이션의 어느 부분이 성능 문제를 발생시킬 수 있는지 확인할 수 있습니다.

  • 엔드포인트 모니터링. 이 기술은 특히 모니터링을 사용할 수 있도록 애플리케이션에서 노출하는 하나 이상의 진단 엔드포인트를 사용합니다. 엔드포인트는 애플리케이션 코드에 대한 경로를 제공하며 시스템 상태에 대한 정보를 반환할 수 있습니다. 여러 엔드포인트가 이 기능의 다양한 측면에 집중할 수 있습니다. 이러한 엔드포인트에 정기적으로 요청을 보내고 응답을 시뮬레이션하는 고유한 진단 클라이언트를 작성할 수 있습니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴을 참조하세요.

최대한 검사할 수 있도록 이러한 기술을 조합하여 사용해야 합니다.

애플리케이션 계측

계측은 모니터링 프로세스의 중요한 부분입니다. 애초에 결정을 뒷받침할 수 있는 데이터를 캡처하는 경우에만 시스템 성능 및 상태에 대해 유의미한 결정을 내릴 수 있습니다. 계측을 사용하여 수집하는 정보는 추적(및 디버깅)을 수동으로 수행하기 위해 원격 프로덕션 서버에 로그인하지 않고도 성능을 평가하고 문제를 진단하고 결정을 내릴 수 있을 정도로 충분해야 합니다. 계측 데이터는 일반적으로 추적 로그에 기록된 정보와 메트릭으로 구성됩니다.

추적 로그의 내용은 애플리케이션이 작성하는 텍스트 데이터의 결과이거나, 추적 이벤트의 결과로 생성되는 이진 데이터(애플리케이션에서 ETW(Windows용 이벤트 추적)를 사용중인 경우)일 수 있습니다. 웹 서버와 같은 인프라 일부에서 발생하는 이벤트를 기록하는 시스템 로그에서 생성될 수도 있습니다. 텍스트 로그 메시지는 사용자가 읽을 수 있도록 설계되는 경우가 많지만 자동화된 시스템에서 쉽게 구문 분석할 수 있는 형식으로도 작성해야 합니다.

또한 로그를 분류해야 합니다. 모든 추적 데이터를 단일 로그에 쓰지 말고, 개별 로그를 사용하여 시스템의 다양한 운영 측면에서 나온 추적 출력을 기록해야 합니다. 이렇게 하면 길이가 긴 단일 파일을 처리할 필요 없이 적절한 로그에서 읽어 로그 메시지를 신속하게 필터링할 수 있습니다. 예를 들어 감사 정보와 디버깅 데이터의 경우처럼 보안 요구 사항이 서로 다른 정보를 동일한 로그에 쓰면 안 됩니다.

참고

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

일반적으로 메트릭은 특정 시점에 시스템의 일부 측면이나 리소스를 측정한 값 또는 개수로, 관련 태그나 차원을 하나 이상 가집니다(샘플이라고 하는 경우도 있음). 메트릭의 단일 인스턴스는 일반적으로 별개로는 유용하지 않습니다. 대신 시간이 지남에 따라 여러 메트릭을 캡처해야 합니다. 기록해야 할 메트릭이 어느 것이며 얼마나 자주 기록해야 하는지를 중요한 문제로 고려해야 합니다. 메트릭용으로 데이터를 생성할 때 많은 경우 시스템에 상당한 부하를 더할 수 있습니다. 반면, 메트릭을 드물게 캡처하면 중요한 이벤트를 발생시키는 상황을 놓칠 수 있습니다. 고려 사항은 메트릭마다 다릅니다. 예를 들어 서버의 CPU 사용률은 초마다 크게 다를 수 있지만 높은 사용률은 몇 분에 걸쳐 오래 지속되는 경우에만 문제가 됩니다.

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

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

또한 비동기 작업에서 여러 명의 사용자를 위한 작업을 수행하는 데 동일 스레드를 다시 사용할 수 있기 때문에 스레드와 사용자 요청 사이에 1:1 매핑이 되지 않을 수도 있습니다. 문제를 더 복잡하게 만드는 것은, 실행이 시스템 전체에서 진행되는 동안 단일 요청이 여러 스레드에 의해 처리될 수도 있다는 점입니다. 가능하면 요청 컨텍스트의 일부로 시스템을 통해 전파되어 있는 고유한 작업 ID와 각 요청을 연결하는 것이 좋습니다. (작업 ID를 생성하여 추적 정보에 포함시키는 기술은 추적 데이터를 캡처하는 데 사용되는 기술에 따라 달라집니다.)

모든 모니터링 데이터에 같은 방식으로 타임스탬프를 지정해야 합니다. 일관성을 위해 모든 날짜와 시간은 협정 세계시를 사용하여 기록합니다. 이렇게 하면 이벤트의 시퀀스를 보다 쉽게 추적할 수 있습니다.

참고

다른 표준 시간대 및 네트워크에서 작동 중인 컴퓨터는 동기화될 수 없습니다. 여러 컴퓨터에 걸쳐 있는 계측 데이터의 상관 관계를 지정하기 위해 타임스탬프만 사용하는 데 의존하지 마세요.

계측 데이터에 포함할 정보

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

  • 추적 이벤트에 의해 캡처되는 정보는 컴퓨터 및 사용자가 읽을 수 있어야 합니다. 이 정보가 여러 시스템의 로그 데이터에 대한 자동화된 처리를 용이하게 하고 로그를 읽는 운영 및 엔지니어링 직원에게 일관성을 제공하기 위해서는 잘 정의된 스키마를 채택합니다. 배포 환경, 프로세스를 실행하는 컴퓨터, 프로세스에 대한 세부 정보, 호출 스택과 같은 환경 정보를 포함합니다.

  • 프로파일링은 시스템에 상당한 오버헤드를 줄 수 있으므로 필요한 경우에만 사용하도록 설정해야 합니다. 계측을 사용한 프로파일링은 이벤트(예: 메서드 호출)가 발생할 때마다 이벤트를 기록하지만 샘플링은 선택한 이벤트만 기록합니다. 선택은 시간 기반(n초마다 한 번) 또는 빈도 기반(n회 요청마다 한 번)으로 이루어질 수 있습니다. 이벤트가 매우 자주 발생하는 경우에는 계측에 의한 프로파일링은 너무 많은 부담을 야기하고 전체 성능에 영향을 미칠 수 있습니다. 이 경우에는 샘플링 접근 방식이 더 좋을 수 있습니다. 그러나 이벤트의 빈도가 낮을 때는 샘플링이 이벤트를 놓칠 수 있습니다. 이 경우에는 계측이 더 나은 접근 방식일 수 있습니다.

  • 개발자나 관리자가 각 요청의 원본을 확인할 수 있도록 충분한 컨텍스트를 제공합니다. 여기에는 특정 요청 인스턴스를 식별하는 일부 형태의 작업 ID가 포함될 수 있습니다. 또한 이 작업과 수행된 계산 작업 및 사용된 리소스 사이의 상관 관계를 설정하는 데 사용할 수 있는 정보도 포함될 수 있습니다. 이 작업은 프로세스 및 컴퓨터의 경계를 넘을 수 있습니다. 계량을 위해 컨텍스트에는 요청을 발생시킨 고객에 대한 참조가 포함되어야 합니다(직접적으로 또는 다른 상호 관련 정보를 통해 간접적으로). 이 컨텍스트는 모니터링 데이터를 캡처한 시점의 애플리케이션 상태에 대한 귀중한 정보를 제공합니다.

  • 모든 요청 및 이러한 요청이 발생한 위치나 지역을 기록합니다. 이 정보는 위치별 핫스팟이 있는지 여부를 결정하는 데 도움을 줄 수 있습니다. 이 정보는 애플리케이션 또는 애플리케이션에서 사용하는 데이터를 다시 분할할지 여부를 결정하는 데에도 유용한 역할을 할 수 있습니다.

  • 예외의 세부 정보를 주의 깊게 기록하고 캡처합니다. 예외 처리가 제대로 이루어지지 않아 중요한 디버그 정보가 손실되는 경우가 많습니다. 내부 예외 및 기타 컨텍스트 정보를 비롯하여 애플리케이션에서 발생한 예외의 전체 세부 정보를 캡처합니다. 가능한 경우 호출 스택을 포함합니다.

  • 애플리케이션의 다양한 요소에 의해 캡처되는 데이터는 이벤트를 분석하고 이벤트와 사용자 요청 사이의 상관 관계를 설정하는 데 도움이 될 수 있으므로 이 데이터의 일관성을 유지합니다. 시스템의 다양한 부분을 구현하는 개발자들이 모두 동일한 접근 방식을 채택하도록 하지 말고, 포괄적이고 구성 가능한 로깅 패키지를 사용하여 정보를 수집하는 것이 좋습니다. 수행되는 I/O의 볼륨, 네트워크 이용률, 요청 수, 메모리 사용, CPU 사용률과 같은 주요 성능 카운터에서 데이터를 수집합니다. 일부 인프라 서비스는 데이터베이스 연결 수, 트랜잭션이 수행되는 속도, 성공/실패한 트랜잭션 수 같은 고유한 특정 성능 카운터를 제공할 수 있습니다. 애플리케이션도 고유한 특정 성능 카운터를 정의할 수 있습니다.

  • 데이터베이스 시스템, 웹 서비스 또는 인프라의 일부인 기타 시스템 수준 서비스와 같은 외부 서비스에 대해 수행된 모든 호출을 기록합니다. 각 호출을 수행하는 데 걸린 시간 및 호출 성공 또는 실패에 대한 정보를 기록합니다. 가능하면 발생하는 일시적 오류와 관련해 모든 재시도 및 실패에 대한 정보를 캡처합니다.

원격 분석 시스템 호환성 보장

많은 경우에 계측에서 나오는 정보는 일련의 이벤트로 생성되고 처리와 분석을 위해 별도의 원격 분석 시스템으로 전달됩니다. 원격 분석 시스템은 일반적으로 특정 애플리케이션이나 기술에 대해 독립적이지만 정보는 대개 스키마에 정의된 특정 형식을 따라야 합니다. 스키마는 원격 분석 시스템이 수집할 수 있는 데이터 필드와 유형을 정의하는 계약을 효과적으로 지정합니다. 스키마는 다양한 플랫폼 및 디바이스에서 도달하는 데이터를 허용할 수 있도록 일반화해야 합니다.

공통 스키마는 모든 계측 이벤트에 공통인 필드(예: 이벤트 이름, 이벤트 시간, 보낸 사람의 IP 주소) 및 다른 이벤트와 상관 관계를 설정하는 데 필요한 세부 정보(사용자 ID, 디바이스 ID, 애플리케이션 ID)를 포함해야 합니다. 이벤트를 발생시킬 수 있는 디바이스 수에는 제한이 없으므로 스키마는 디바이스 유형에 종속되어서는 안 됩니다. 또한 동일한 애플리케이션에 대한 이벤트가 여러 개의 다양한 디바이스에서 발생할 수 있으며, 애플리케이션이 로밍 또는 다른 형태의 디바이스 간 배포를 지원할 수도 있습니다.

스키마는 여러 애플리케이션 사이에 공통되는 특정 시나리오와 관련된 도메인 필드를 포함할 수도 있습니다. 이는 예외, 애플리케이션 시작/종료 이벤트, 웹 서비스 API 호출의 성공 및/또는 실패에 대한 정보일 수 있습니다. 동일한 도메인 필드 집합을 사용하는 모든 애플리케이션이 동일한 이벤트 집합을 내보내서 일련의 일반 보고서 및 분석을 작성할 수 있게 해야 합니다.

마지막으로 스키마는 애플리케이션별 이벤트의 세부 정보를 캡처하기 위한 사용자 지정 필드를 포함할 수 있습니다.

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

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

  • 로그를 쉽게 읽고 구문 분석할 수 있도록 만듭니다. 가능한 경우 구조화된 로깅을 사용합니다. 간결하고 설명적인 로그 메시지를 사용합니다.

  • 모든 로그에서 원본을 식별하고 각 로그 레코드가 작성될 때 컨텍스트와 타이밍 정보를 제공합니다.

  • 모든 타임스탬프에 동일한 표준 시간대와 형식을 사용합니다. 이렇게 하면 다양한 지리적인 지역에서 실행되는 하드웨어 및 서비스의 작업에 대한 이벤트의 상관 관계를 설정하는 데 도움이 됩니다.

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

  • 시스템에 대한 중요 정보나 사용자에 대한 개인 정보를 공개하지 않습니다. 로그에 기록되기 전에 이 정보를 삭제하지만, 관련 세부 정보는 보존해야 합니다. 예를 들어 데이터베이스 연결 문자열에서 ID와 암호를 제거하지만, 분석가가 시스템이 올바른 데이터베이스에 액세스하는지 확인할 수 있도록 나머지 정보는 로그에 씁니다. 모든 심각한 예외를 로그에 기록하지만, 하위 수준의 예외 및 경고에 대해서는 관리자가 로깅을 설정 및 해제할 수 있도록 합니다. 또한 모든 재시도 논리 정보를 캡처하고 로그에 기록합니다. 이 데이터는 시스템의 일시적인 상태를 모니터링하는 데 유용할 수 있습니다.

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

  • 보안 요구 사항이 서로 다른 메시지를 동일한 로그 파일에 혼합하지 마세요. 예를 들어 디버그 정보와 감사 정보를 동일한 로그에 쓰지 않습니다.

  • 감사 이벤트를 제외하고, 모든 로깅 호출은 자체 유도(fire-and-forget) 작업이어야 하며 비즈니스 작업의 진행을 차단해서는 안 됩니다. 감사 이벤트는 비즈니스에 매우 중요하고 비즈니스 작업의 기본적인 부분으로 분류될 수 있기 때문에 예외입니다.

  • 로깅은 확장 가능해야 하며 구체적인 대상에 대한 직접적인 종속성이 없어야 합니다. 예를 들어 System.Diagnostics.Trace를 사용하여 정보를 쓰는 대신, 로깅 메서드를 노출하며 적절한 수단을 통해 구현할 수 있는 추상 인터페이스(예: ILogger)를 정의합니다.

  • 모든 로깅은 유사 시 대기이며 연속 오류를 트리거하지 않아야 합니다. 로깅은 예외를 발생시켜서는 안 됩니다.

  • 계측을 지속적으로 반복 프로세스로 취급하고 문제가 있을 때뿐만 아니라 정기적으로 로그를 검토합니다.

데이터 수집 및 저장

모니터링 프로세스의 수집 단계는 계측에서 생성된 정보를 검색하고, 이 데이터를 분석/진단 단계에서 더 쉽게 사용할 수 있도록 형식을 지정하여 변환된 데이터를 안정적인 스토리지에 저장하는 과정입니다. 분산 시스템의 여러 부분에서 수집하는 계측 데이터는 다양한 형식을 사용해 다양한 위치에 보관할 수 있습니다. 예를 들어 애플리케이션 코드가 추적 로그 파일을 생성하고 애플리케이션 이벤트 로그 데이터를 생성할 수 있으며, 애플리케이션이 사용하는 인프라의 주요 측면을 모니터링하는 성능 카운터는 다른 기술을 통해 캡처할 수 있습니다. 애플리케이션에 사용되는 타사 구성 요소 및 서비스는 별도의 추적 파일, Blob Storage 또는 사용자 지정 데이터 스토리지를 사용하여 다양한 형식으로 계측 정보를 제공할 수 있습니다.

데이터 수집은 계측 데이터를 생성하는 애플리케이션에서 자율적으로 실행할 수 있는 수집 서비스를 통해 수행되는 경우가 많습니다. 그림 2에서는 이 아키텍처의 예를 보여 주며 여기서는 계측 데이터 수집 하위 시스템이 강조 표시되어 있습니다.

계측 데이터 수집의 예제

그림 2 - 계측 데이터 수집

이 그림은 간략한 뷰입니다. 수집 서비스는 반드시 단일 프로세스는 아니며 다음 섹션의 설명대로 다양한 컴퓨터에서 실행 중인 많은 구성 부분으로 이루어질 수 있습니다. 또한 일부 원격 분석 데이터를 신속하게 분석해야 하는 경우 수집 서비스 외부에서 작동하는 로컬 구성 요소가 즉시 분석 작업을 수행할 수 있습니다. 참고로, 신속한 분석을 핫 분석이라고 하며 이 문서 뒷부분에 나오는 핫, 웜, 콜드 분석 지원 섹션에서 자세히 설명합니다. 그림 2에서는 선택한 이벤트에 대해 이러한 상황을 보여 줍니다. 분석 처리 후 결과는 시각화 및 경고 하위 시스템에 직접 보낼 수 있습니다. 웜 또는 콜드 분석 대상 데이터는 처리를 대기하는 동안 스토리지에 보관됩니다.

Azure 애플리케이션 및 서비스의 경우 Azure Diagnostics를 사용하면 데이터를 캡처할 수 있습니다. Azure 진단은 각 컴퓨팅 노드에 대한 다음 소스에서 데이터를 수집하고 이를 집계한 다음, Azure Storage에 업로드합니다.

  • IIS 로그
  • IIS 실패한 요청 로그
  • Windows 이벤트 로그
  • 성능 카운터
  • 크래시 덤프
  • Azure Diagnostics 인프라 로그
  • 사용자 지정 오류 로그
  • .NET EventSource
  • 매니페스트 기반 ETW

자세한 내용은 Azure: 원격 분석 기본 사항 및 문제 해결문서를 참조하세요.

계측 데이터 수집 전략

클라우드의 탄력적인 특성을 고려하고 시스템의 모든 노드에서 원격 분석 데이터를 수동 검색할 필요가 없도록 하기 위해 데이터를 하나의 중앙 위치로 전송하여 통합해야 합니다. 여러 데이터 센터에 걸쳐 있는 시스템에서는 먼저 데이터를 수집 및 통합하여 지역별로 저장한 다음 지역별 데이터를 단일 중앙 시스템에 집계하는 것이 유용할 수 있습니다.

대역폭 사용을 최적화하려면 덜 긴급한 데이터를 청크 단위로 일괄 작업으로 전송할 수 있습니다. 그러나 데이터를 무기한 지연해서는 안 되며, 특히 시간이 중요한 정보가 포함된 경우는 더욱 그렇습니다.

계측 데이터 끌어오기 밀어넣기

계측 데이터 수집 하위 시스템은 다양한 로그 및 각 애플리케이션 인스턴스에 대한 다른 원본으로부터 능동적으로 계측 데이터를 수신( 끌어오기 모델)할 수 있습니다. 또는 각 애플리케이션 인스턴스를 구성하는 구성 요소로부터 전송되는 데이터를 대기하는 수동적 수신기의 역할( 밀어넣기 모델)을 할 수 있습니다.

끌어오기 모델을 구현하는 한 가지 접근 방식은 각 애플리케이션 인스턴스와 함께 로컬에서 실행되는 모니터링 에이전트를 사용하는 것입니다. 모니터링 에이전트는 로컬 노드에서 수집된 원격 분석 데이터를 주기적으로 검색(끌어오기)한 후 애플리케이션의 모든 인스턴스가 공유하는 중앙 스토리지에 이 정보를 직접 쓰는 별도의 프로세스입니다. Azure Diagnostics를 구현하는 메커니즘입니다. Azure 웹 또는 작업자 역할의 각 인스턴스는 로컬에 저장된 진단 정보 및 다른 추적 정보를 캡처하도록 구성할 수 있습니다. 나란히 함께 실행되는 모니터링 에이전트는 지정 데이터의 각 인스턴스를 Azure Storage에 복사합니다. Azure Cloud Services 및 Virtual Machines에서 진단 사용 문서에서 이 프로세스에 대한 자세한 내용을 제공합니다. IIS 로그, 크래시 덤프 및 사용자 지정 오류 로그와 같은 일부 요소는 Blob Storage에 기록됩니다. Windows 이벤트 로그, ETW 이벤트 및 성능 카운터의 데이터는 Table Storage에 기록됩니다. 그림 3에서는 이 메커니즘을 보여 줍니다.

모니터링 에이전트를 사용하여 정보 끌어오기 및 공유 스토리지에 쓰기의 예시

그림 3 - 모니터링 에이전트를 사용하여 정보 끌어오기 및 공유 스토리지에 쓰기

참고

모니터링 에이전트를 사용하는 것은 자연스럽게 데이터 원본에서 끌어온 계측 데이터를 캡처하는 데 가장 적합합니다. 예를 들어 SQL Server 동적 관리 뷰에서 가져온 정보 또는 Azure Service Bus 큐 길이 정보입니다.

단일 위치에서 제한된 수의 노드에서 실행되는 소규모 애플리케이션에 대한 원격 분석 데이터는 방금 설명한 접근 방식을 사용하여 최적으로 저장할 수 있습니다. 그러나 복잡하고 확장성이 뛰어난 전역 클라우드 애플리케이션은 수백 개의 웹 및 작업자 역할, 분할된 데이터베이스 및 기타 서비스에서 대량의 데이터를 생성할 수 있습니다. 이렇게 대량의 데이터가 쏟아지면 단일 중앙 위치에서 사용할 수 있는 I/O 대역폭이 쉽게 압도될 수 있습니다. 따라서 원격 분석 솔루션은 시스템 확장에 따른 병목 상태를 유발하지 않도록 확장할 수 있어야 합니다. 시스템 일부에서 장애가 발생하는 경우 중요한 모니터링 정보(예: 감사 및 청구 데이터)가 손실되는 위험을 줄이기 위해 일정 수준의 중복성을 포함하는 것이 좋습니다.

이러한 문제를 해결하기 위해 그림 4와 같이 큐를 구현할 수 있습니다. 이 아키텍처에서는 로컬 모니터링 에이전트(적절하게 구성할 수 있는 경우) 또는 사용자 지정 데이터 수집 서비스(구성할 수 없는 경우)가 큐에 데이터를 게시합니다. 비동기식으로 실행되는 별도의 프로세스(그림 4의 스토리지 쓰기 서비스)가 이 큐의 데이터를 사용하여 공유 스토리지에 씁니다. 메시지 큐는 게시되고 나면 큐에 대기 중인 데이터가 손실되지 않도록 하는 의미 체계를 "한 번 이상" 제공하므로 이 시나리오에 적합합니다. 스토리지 쓰기 서비스는 별도의 작업자 역할을 사용하여 구현할 수 있습니다.

큐를 사용하여 계측 데이터 버퍼링의 예시

그림 4 - 큐를 사용하여 계측 데이터 버퍼링

로컬 데이터 수집 서비스는 데이터가 수신되는 즉시 큐에 데이터를 추가할 수 있습니다. 큐가 버퍼 역할을 하며 스토리지 쓰기 서비스가 고유한 속도로 데이터를 검색하고 쓸 수 있습니다. 기본적으로 큐는 선입선출 방식으로 작동합니다. 더 빨리 처리해야 하는 데이터가 포함된 메시지의 경우 우선 순위를 지정하여 해당 메시지의 큐 대기 시간을 단축할 수 있습니다. 자세한 내용은 우선 순위 큐 패턴을 참조하세요. 또는 필요한 분석 처리의 형식에 따라, 다른 채널(예: Service Bus 토픽)을 사용하여 데이터를 다른 대상에 전달할 수도 있습니다.

확장성을 위해 스토리지 쓰기 서비스 인스턴스를 여러 개 실행할 수 있습니다. 고용량의 이벤트가 있는 경우 이벤트 허브를 사용하여 처리 및 스토리지을 위해 데이터를 다양한 컴퓨팅 리소스로 디스패치할 수 있습니다.

계측 데이터 통합

애플리케이션의 단일 인스턴스에서 데이터 수집 서비스가 검색한 계측 데이터는 해당 인스턴스의 상태와 성능을 국지적으로 확인할 수 있는 뷰를 제공합니다. 시스템의 전반적인 상태를 평가하기 위해서는 데이터의 일부 측면을 로컬 뷰에 통합해야 합니다. 이를 수행하려면 먼저 데이터를 저장해야 하지만 일부 경우에는 데이터를 수집과 함께 통합될 수도 있습니다. 계측 데이터를 공유 스토리지에 직접 기록하는 대신, 데이터를 결합하고 필터 및 정리 프로세스의 역할을 하는 별도의 데이터 통합 서비스에 계측 데이터를 전달할 수 있습니다. 예를 들어 작업 ID와 같은 동일한 상관 관계 정보를 포함하는 계측 데이터를 통합할 수 있습니다. (사용자가 하나의 노드에서 비즈니스 작업 수행을 시작한 후에 노드 장애 발생 시 또는 부하 분산 구성 방식에 따라 다른 노드로 전송하는 것이 가능합니다.) 이 프로세스는 중복된 데이터를 감지하고 제거할 수도 있습니다(원격 분석 서비스가 스토리지에서 계측 데이터를 밀어내는 데 메시지 큐를 사용하는 경우 항상 가능함). 그림 5에서는 이 구조의 예를 보여 줍니다.

서비스를 사용하여 계측 데이터를 통합하는 예제

그림 5 - 별도 서비스를 사용하여 계측 데이터 통합 및 정리

계측 데이터 저장

앞에서는 계측 데이터가 저장되는 방식을 보여 주는 다소 간략한 뷰에 대해 설명했습니다. 실제로는 각 정보 유형이 사용될 방식에 가장 적합한 기술을 사용하여 다양한 유형의 정보를 저장하는 것이 좋습니다.

예를 들어 Azure Blob 및 Table Storage는 액세스하는 방식에 있어 몇 가지 유사점이 있습니다. 하지만 이들 저장소를 사용하여 수행할 수 있는 작업에 제한이 있으며 저장하는 데이터의 세분성은 상당히 다릅니다. 자세한 분석 작업을 수행해야 하거나 데이터에 대한 전체 텍스트 검색 기능이 필요한 경우에는 특정 유형의 쿼리 및 데이터 액세스에 최적화된 기능을 제공하는 데이터 스토리지를 사용하는 것이 더 적합할 수 있습니다. 예를 들면 다음과 같습니다.

  • 성능 카운터 데이터는 SQL 데이터베이스에 저장하여 임시 분석을 가능하도록 만들 수 있습니다.
  • 추적 로그는 Azure Cosmos DB에 저장하는 것이 더 효율적일 수 있습니다.
  • 보안 정보는 HDFS에 쓸 수 있습니다.
  • 전체 텍스트 검색이 필요한 정보는 탄력적 검색(다양한 인덱싱을 사용하여 검색 속도를 높일 수도 있음)을 사용하여 저장할 수 있습니다.

주기적으로 공유 스토리지, 파티션에서 데이터를 검색하고 목적에 따라 데이터를 필터링한 다음 그림 6에 나온 것처럼 적절한 데이터 스토리지 집합에 이 데이터를 쓰는 추가 서비스를 구현할 수 있습니다. 이 접근 방식 대신, 이 기능을 통합 및 정리 프로세스에 포함하고 데이터를 중간 공유 스토리지 영역에 저장하지 않고 검색되면 바로 이 스토리지에 쓰는 방법을 택할 수도 있습니다. 각 접근 방식은 모두 장점과 단점이 있습니다. 별도의 분할 서비스를 구현하면 통합 및 정리 서비스에 주는 부하를 줄이고 필요한 경우(공유 스토리지에 보존되는 데이터의 양에 따라) 분할된 데이터 중 적어도 일부를 다시 생성하도록 만듭니다. 그러나 추가 리소스가 사용됩니다. 또한 계측 데이터가 각 애플리케이션 인스턴스에서 검색되는 시점과 이 데이터가 조치 가능한 정보로 변환되는 시점 사이에 지연이 발생할 수 있습니다.

데이터 분할 및 스토리지

그림 6 - 분석 및 스토리지 요구 사항에 따라 데이터 분할

동일한 계측 데이터가 두 가지 이상의 목적을 위해 필요할 수 있습니다. 예를 들어 성능 카운터를 사용하여 시간 경과에 따른 시스템 기록 보기를 제공할 수 있습니다. 이 정보를 다른 사용량 현황 데이터와 결합하여 고객의 청구 정보를 생성할 수 있습니다. 이런 경우 청구 정보를 보관하는 장기 저장소 역할을 할 수 있는 문서 데이터베이스, 복잡한 성능 분석을 처리하기 위한 다차원 저장소 등과 같은 두 개 이상의 대상에 동일 데이터를 전송할 수 있습니다.

또한 데이터가 어느 정도로 긴급하게 필요한지에 대해서도 고려해야 합니다. 경고용 정보를 제공하는 데이터는 신속하게 액세스할 수 있어야 하므로 빠른 데이터 스토리지에 보관하고 경고 시스템이 수행하는 쿼리를 최적화할 수 있게 인덱싱하거나 구조화해야 합니다. 일부 경우에 각 노드의 데이터를 수집하는 원격 분석 서비스가 데이터 형식을 지정해 로컬에서 데이터를 저장함으로써 경고 시스템의 로컬 인스턴스가 문제를 신속하게 알릴 수 있게 만드는 것이 필요할 수도 있습니다. 다른 목적을 위해 필요한 경우 동일한 데이터를 이전 다이어그램에 표시된 스토리지 쓰기 서비스로 디스패치하고 중앙에서 저장할 수도 있습니다.

보다 심도 있는 분석, 보고, 장기 추세 포착 등을 위해 사용되는 정보는 덜 긴급하므로 데이터 마이닝과 임시 쿼리를 지원하는 방식으로 저장할 수 있습니다. 자세한 내용은 이 문서 뒷부분에 나오는 핫, 웜, 콜드 분석 지원 을 섹션을 참조하세요.

로그 회전 및 데이터 보존

계측에서는 상당한 양의 데이터가 생성될 수 있습니다. 이러한 데이터는 원시 로그 파일, 추적 파일, 각 노드에서 캡처되는 기타 정보뿐만 아니라 공유 스토리지에 보관되는 이 데이터의 통합, 정리, 분할된 뷰에 이르기까지 다양한 장소에 보관될 수 있습니다. 일부 경우, 데이터가 처리 및 전송된 후에 원시 원본 데이터를 각 노드에서 제거할 수 있습니다. 다른 경우에는 원시 정보를 저장해야 하거나 저장해 두면 유용할 수 있습니다. 예를 들어 디버깅 용도로 생성된 데이터는 원시 형태로 사용할 수 있도록 두면 가장 좋을 수도 있지만 버그 수정 후에 빨리 삭제될 수 있습니다.

성능 데이터는 비교적 수명이 길게 유지되므로 성능 추세를 발견하고 용량을 계획하는 데 사용될 수 있습니다. 이 데이터에 대한 통합 보기는 일반적으로 빠른 액세스가 가능하도록 온라인에서 일정 기간 동안 유지됩니다. 그 이후에 보관되거나 삭제됩니다. 계량 및 고객 대금 청구용으로 수집되는 데이터는 무기한 저장해야 할 수 있습니다. 또한 감사 및 보안 목적으로 수집되는 정보도 규제 요구 사항에 따라 보관 및 저장해야 할 수 있습니다. 이 데이터도 중요한 데이터이므로 암호화하거나 변조할 수 없도록 보호해야 할 수 있습니다. 사용자 암호 또는 ID 사기에 사용될 수 있는 기타 정보는 절대로 기록해서는 안 됩니다. 이러한 세부 정보는 저장 전에 데이터에서 삭제해야 합니다.

저해상도로 처리

장기 추세를 파악할 수 있도록 기록 데이터를 저장하면 유용한 경우가 많습니다. 이전 데이터 전체를 저장하지 않고 데이터를 저해상도로 처리하여 해상도를 줄이고 스토리지 비용을 절약할 수 있습니다. 예를 들어 분 단위 성능 지표를 저장하지 않고 1개월이 넘은 데이터를 통합하여 시간 단위 보기를 만들 수 있습니다.

로깅 정보 수집 및 저장 모범 사례

다음은 로깅 정보를 캡처하고 저장하기 위한 모범 사례를 요약한 목록입니다.

  • 모니터링 에이전트나 데이터 수집 서비스는 Out of Process 서비스로 실행해야 하며 간단하게 배포할 수 있어야 합니다.

  • 모니터링 에이전트나 데이터 수집 서비스에서 나오는 모든 출력은 컴퓨터, 운영 체제 또는 네트워크 프로토콜과 관계없는 독립적인 형식이어야 합니다. 예를 들어 ETL/ETW 대신 JSON, MessagePack 또는 Protobuf와 같은 자체 설명적 형식으로 정보를 내보냅니다. 표준 형식을 사용하면 시스템에서 처리 파이프라인을 생성할 수 있으며 합의된 형식으로 데이터를 읽고 변환하고 전송하는 구성 요소를 쉽게 통합할 수 있습니다.

  • 모니터링 및 데이터 수집 프로세스는 장애 발생 시 안전해야 하며 연속 오류 조건을 트리거해서는 안 됩니다.

  • 정보를 데이터 싱크로 보내는 데 일시적인 장애가 발생하는 경우 모니터링 에이전트나 데이터 수집 서비스는 최신 정보가 먼저 전송되도록 원격 분석 데이터 순서를 변경할 준비가 되어 있어야 합니다. (모니터링 에이전트/데이터 수집 서비스는 자체 판단에 따라 오래된 데이터를 삭제하거나 로컬에 저장했다가 나중에 확인을 위해 전송하도록 선택할 수 있습니다.)

데이터 분석 및 문제 진단

모니터링 및 진단 프로세스의 중요한 한 부분은 수집된 데이터를 분석하여 시스템의 전반적인 상태를 파악하는 것입니다. 고유한 KPI 및 성능 메트릭을 정의해 둬야 하며, 분석 요구 사항에 부합하려면 수집된 데이터를 어떻게 구조화할 수 있는지 이해해야 합니다. 다양한 메트릭과 로그 파일에서 캡처한 데이터는 이벤트 시퀀스를 추적하는 데 있어서 키가 될 수 있고 발생하는 문제를 진단하는 데에도 유용하므로 이 데이터의 상관 관계를 설정하는 방법을 이해하는 것도 중요합니다.

계측 데이터 통합섹션에 설명된 대로 시스템의 각 부분에 대한 데이터는 대체로 로컬로 캡처되지만 일반적으로 시스템에 속한 다른 사이트에서 생성된 데이터와 결합해야 합니다. 이 정보는 세심하게 상관 관계를 설정해야 데이터가 정확히 결합될 수 있습니다. 예를 들어 작업에 대한 사용량 현황 데이터가 사용자가 연결하는 웹 사이트를 호스트하는 노드, 이 작업 도중에 액세스되는 별도의 서비스를 실행하는 노드 및 추가 노드에 보관되는 데이터 스토리지 등에 걸쳐 있을 수 있습니다. 이 정보를 함께 연결하여 작업에 대한 리소스 및 처리 사용량 전체 보기를 제공해야 합니다. 데이터가 캡처된 노드에서 일부 데이터 사전 처리 및 필터링이 발생할 수 있으며, 중앙 노드에서는 집계 및 형식 지정이 발생할 가능성이 높습니다.

핫, 웜, 콜드 분석 지원

시각화, 보고 및 경고의 용도로 데이터를 분석하고 데이터 형식을 다시 지정하는 것은 고유한 일련의 리소스를 사용하는 복잡한 프로세스일 수 있습니다. 일부 형태의 모니터링은 시간이 매우 중요하여 즉각적인 데이터 분석이 적용되어야 합니다. 이것을 핫(hot) 분석이라고 합니다. 경고를 위해 필요한 분석, 보안 모니터링의 일부 측면(예: 시스템 공격 검색) 등을 예로 들 수 있습니다. 이러한 목적으로 필요한 데이터는 빨리 사용할 수 있고 효율적인 처리가 가능하도록 구조화되어야 합니다. 일부 경우 데이터가 보관되어 있는 개별 노드로 분석 처리를 이동해야 할 수도 있습니다.

시간의 중요성이 비교적 낮은 다른 형태의 분석이 있으며, 여기서는 원시 데이터를 수신한 후에 일부 계산 및 집계가 필요할 수 있습니다. 이를 웜 분석이라고 합니다. 성능 분석이 이 범주에 속하는 경우가 많습니다. 이 분석의 경우, 격리된 단일 성능 이벤트는 통계적 중요성이 낮습니다. (급격한 변동이나 결함으로 인해 발생할 수 있습니다.) 일련의 이벤트에서 나온 데이터는 시스템 성능에 대해 신뢰성 높은 보기를 제공해야 합니다.

웜(warm) 분석은 상태 문제를 진단하는 데에도 사용할 수 있습니다. 상태 이벤트는 일반적으로 핫 분석을 통하여 처리되며 즉시 경고를 발생시킬 수 있습니다. 운영자는 웜 경로의 데이터를 검사하여 상태 이벤트의 원인을 자세히 살펴볼 수 있어야 합니다. 이 데이터에는 상태 이벤트를 발생시킨 문제를 야기한 이벤트에 대한 정보가 있어야 합니다.

일부 유형의 모니터링은 더 많은 장기 데이터를 생성합니다. 나중에 미리 정의된 일정에 따라 이 분석을 수행할 수 있습니다. 일부 경우에는 분석에서 일정 기간 동안 캡처된 대용량 데이터에 대해 복잡한 필터링을 수행해야 할 수도 있습니다. 이를 콜드 분석이라고 합니다. 주요 요구 사항은 캡처된 데이터를 안전하게 저장하는 것입니다. 예를 들어 사용 모니터링 및 감사에는 정기적인 시점의 시스템 상태를 정확히 파악할 수 있는 보기가 필요합니다. 그러나 이러한 상태 정보는 수집된 후에 즉시 제공되어야 할 필요는 없습니다.

또한 운영자는 콜드 분석을 사용하여 예측 상태 분석용으로 데이터를 제공할 수 있습니다. 운영자는 지정된 기간에 걸쳐 기록 정보를 수집하고 사용하여 현재 상태 데이터(핫 경로에서 검색)와 함께 사용하여 곧 상태 문제를 일으킬 수 있는 추세를 발견할 수 있습니다. 이러한 경우에 정정 작업을 수행할 수 있도록 경고를 발생시켜야 할 수 있습니다.

데이터 상관 관계 설정

계측에서 캡처된 데이터는 시스템 상태에 대한 스냅샷을 제공할 수 있지만, 분석의 목적은 이 데이터를 조치 가능한 데이터로 만드는 것입니다. 예를 들면 다음과 같습니다.

  • 특정 시간에 시스템 수준에서 집중적인 I/O 부하가 발생한 원인은 무엇인가요?
  • 데이터베이스 작업의 수가 많아서일까요?
  • 이 결과가 데이터베이스 응답 시간, 초당 트랜잭션 수, 동일한 지점의 애플리케이션 응답 시간 등에 반영되나요?

만약 그렇다면 이 부하를 줄일 수 있는 한 가지 수정 조치는 더 많은 서버에 데이터를 분할하는 것입니다. 또한 시스템 어느 수준에서나 장애로 인해 예외가 발생할 수 있습니다. 한 수준의 예외는 위 수준에서 다른 장애를 트리거하는 경우가 많습니다.

이러한 이유로 인해 각 수준에서 다양한 유형의 모니터링 데이터의 상관 관계를 설정하여 시스템 및 시스템에서 실행되는 애플리케이션의 상태에 대한 전체 보기를 제공할 수 있어야 합니다. 그러면 이 정보를 사용하여 시스템이 양호하게 작동하는지 여부에 대해 결정하고 시스템 품질 향상을 위해 할 수 있는 일을 확인할 수 있습니다.

데이터 상관 관계를 설정하기 위한 정보섹션에 설명된 대로, 원시 계측 데이터에 이벤트 상관 관계 설정에 필요한 집계를 지원할 수 있도록 충분한 컨텍스트 및 작업 ID 정보를 포함해야 합니다. 또한 이 데이터는 다양한 형식으로 보관할 수 있으며 분석을 위해 표준화된 형식으로 변환하려면 이 정보를 구문 분석해야 할 수도 있습니다.

문제 해결 및 문제 진단

진단을 위해서는 장애나 예기치 않은 동작(근본 원인 분석 수행 포함)의 원인을 확인할 수 있는 기능이 필요합니다. 필요한 정보에는 일반적으로 다음이 포함됩니다.

  • 지정된 기간 동안 전체 시스템 또는 지정된 하위 시스템에 대한 이벤트 로그 및 추적에서 가져온 자세한 정보
  • 지정된 기간 동안 시스템 또는 지정된 하위 시스템 내부에서 발생하는 특정 수준의 예외 및 장애에서 발생한 전체 스택 추적
  • 지정된 기간 동안 시스템 내의 임의의 위치 또는 지정된 하위 시스템에 대해 실패한 프로세스의 크래시 덤프
  • 지정된 기간 동안 모든 사용자가 수행하거나 일부 선택된 사용자를 위해 수행되는 작업을 기록하는 활동 로그

문제 해결을 목적으로 데이터를 분석하는 데는 종종 시스템 아키텍처 및 솔루션을 구성하는 다양한 구성 요소와 관련된 기술에 대한 심도 있는 이해가 필요합니다. 결과적으로 데이터를 해석하고 문제 원인을 파악하며 문제를 해결하기 위한 적절한 전략을 제안하기 위해 상당 수준의 수동 작업이 필요할 때가 많습니다. 이 정보의 복사본을 원래 형식으로 저장해서 전문가의 콜드 분석을 위해 제공하는 것이 적절할 수도 있습니다.

데이터 시각화 및 경고 발생

모든 모니터링 시스템에서 중요한 측면은 운영자가 추세나 문제를 신속하게 발견할 수 있는 방식으로 데이터를 표시하는 기능입니다. 또한 주의를 요하는 중대한 이벤트가 발생한 경우 이를 신속하게 운영자에게 알리는 기능도 중요합니다.

데이터는 대시보드, 경고 및 보고를 사용한 시각화를 포함하여 여러 형태로 표시할 수 있습니다.

대시보드를 사용한 시각화

데이터를 시각화하는 가장 일반적인 방법은 정보를 일련의 차트, 그래프 또는 일부 다른 일러스트레이션으로 표시할 수 있는 대시보드를 사용하는 것입니다. 이러한 항목을 매개 변수화할 수 있으며 분석가는 특정 상황에 대해 중요한 매개 변수(예: 기간)를 선택할 수 있어야 합니다.

대시보드는 계층적으로 구성될 수 있습니다. 최상위 대시보드가 시스템의 각 측면에 대한 전체 보기를 제공할 수 있지만 운영자의 세부 정보 드릴 다운을 지원하는 기능을 포함합니다. 예를 들어 시스템에 대한 전체적인 디스크 I/O를 설명하는 대시보드에서 분석가는 각 개별 디스크의 I/O 비율을 보고 하나 이상의 특정 디바이스가 불균형한 트래픽 볼륨의 원인인지 여부를 확인할 수 있어야 합니다. 대시보드에 이 I/O를 생성하는 각 요청의 출처(사용자 또는 작업)와 같은 관련 정보도 표시되는 것이 가장 좋습니다. 그러면 이 정보를 사용하여 여러 디바이스에서 부하를 더 균등하게 분산할지 여부(및 방법)와 디바이스가 추가되면 시스템 성능이 향상될지 여부를 결정할 수 있습니다.

대시보드는 색 구분 또는 다른 시각 신호를 사용하여 비정상으로 보이거나 예상 범위를 벗어난 값을 나타낼 수도 있습니다. 이전 예제에서는 다음과 같이 사용되었습니다.

  • 장기간에 걸쳐 I/O 비율이 최대 용량에 근접하는 디스크(핫 디스크)를 빨간색으로 강조 표시할 수 있습니다.
  • 짧은 기간에 주기적으로 I/O 비율이 최대 한도에서 실행되는 디스크(웜 디스크)는 노란색으로 강조 표시할 수 있습니다.
  • 정상적인 사용 현황을 보이는 디스크는 녹색으로 표시할 수 있습니다.

대시보드 시스템이 효율적으로 작동하려면 작업에 사용할 원시 데이터가 있어야 합니다. 고유한 대시보드 시스템을 작성하거나 다른 조직에서 개발한 대시보드를 사용하려는 경우에는 수집해야 할 계측 데이터, 세분성의 정도, 대시보드에서 사용할 수 있도록 데이터의 형식을 지정하는 방식 등을 이해해야 합니다.

좋은 대시보드는 정보를 표시하는 것에만 그치지 않고 분석가가 해당 정보에 대한 임시 질문도 할 수 있습니다. 일부 시스템에서는 운영자가 이러한 작업을 수행하고 기본 데이터를 탐색하는 데 사용할 수 있는 관리 도구를 제공합니다. 또는 이 정보를 보관하는 데 사용되는 리포지토리에 따라 이 데이터를 직접 쿼리할 수도 있고 아니면 추가 분석 및 보고를 위해 이 데이터를 Microsoft Excel과 같은 도구로 가져올 수도 있습니다.

참고

이 정보는 상업적으로 중요할 수 있으므로 권한 있는 직원만 대시보드에 액세스할 수 있게 해야 합니다. 또한 대시보드에 대한 기본 데이터를 사용자가 변경하지 못하도록 보호해야 합니다.

경고 발생

경고는 계측 데이터를 분석 및 모니터링하고 중대한 이벤트가 감지되는 경우 알림을 생성하는 프로세스입니다.

경고는 시스템의 정상 상태, 응답성, 보안을 유지하는데 도움이 됩니다. 경고는 모든 시스템에서 성능, 가용성, 개인 정보 보호를 보장하는 중요한 부분이며 해당 데이터에 대해 즉시 조치를 취해야 할 수 있습니다. 운영자는 경고를 트리거한 이벤트에 대한 알림을 받아야 할 수 있습니다. 경고는 자동 크기 조정과 같은 시스템 기능을 호출하는 데에도 사용될 수 있습니다.

경고는 일반적으로 다음 계측 데이터에 종속됩니다.

  • 보안 이벤트. 이벤트 로그에 인증 및/또는 권한 부여 실패가 반복적으로 발생하는 것으로 나타난다면 시스템이 공격을 받고 있을 수 있으며 이 경우 운영자는 알림을 받아야 합니다.
  • 성능 메트릭. 특정 성능 메트릭이 지정된 임계값을 초과하는 경우 시스템이 신속하게 응답해야 합니다.
  • 가용성 정보. 장애가 검색되면 신속하게 하나 이상의 하위 시스템을 다시 시작하거나 백업 리소스로 장애 조치(failover)를 수행해야 할 수 있습니다. 하위 시스템에서 발생하는 반복적인 장애는 보다 심각한 문제를 나타낼 수 있습니다.

운영자는 메일, 호출기 디바이스 또는 SMS 문자 메시지와 같은 다양한 배달 채널을 사용하여 경고 정보를 받을 수 있습니다. 경고에는 상황이 어느 정도 심각한지에 대한 표시도 포함될 수 있습니다. 많은 경고 시스템이 구독자 그룹을 지원하며 동일 그룹의 구성원인 모든 운영자가 동일한 경고 집합을 받을 수 있습니다.

경고 시스템을 사용자 지정할 수 있어야 하며 기본 계측 데이터의 적절한 값을 매개 변수로 제공할 수 있습니다. 이렇게 하면 운영자가 데이터를 필터링하여 관심 있는 임계값이나 값 조합에 초점을 맞출 수 있습니다. 경우에 따라 원시 계측 데이터를 경고 시스템에 제공할 수 있습니다. 일부 상황에서는 집계된 데이터를 제공하는 것이 더 적절할 수 있습니다. 예를 들어 노드에 대한 CPU 사용률이 최근 10분 동안 90퍼센트를 초과한 경우 경고를 트리거할 수 있습니다. 경고 시스템에 제공되는 세부 정보는 적절한 요약 및 컨텍스트 정보도 포함해야 합니다. 이러한 데이터는 가양성 이벤트로 인해 경고가 발생하는 가능성을 줄입니다.

보고

보고는 시스템 전체 보기를 생성하기 위해 사용됩니다. 현재 정보 외에도 기록 데이터를 통합할 수 있습니다. 보고 요구 사항은 운영 보고와 보안 보고 등 광범위한 두 가지 범주로 구분됩니다.

운영 보고에는 일반적으로 다음 측면이 포함됩니다.

  • 지정된 시간 범위 동안 전체 시스템 또는 지정된 하위 시스템의 리소스 사용률을 이해하도록 사용할 수 있는 통계 집계.
  • 지정된 기간 동안 전체 시스템 또는 지정된 하위 시스템에 대한 리소스 사용 추세 파악.
  • 지정된 기간 동안 시스템 전체 또는 지정된 하위 시스템에서 발생한 예외 모니터링.
  • 배포된 리소스를 기준으로 애플리케이션의 효율성을 결정하고 성능에 불필요한 영향을 미치지 않고도 리소스 볼륨(및 관련 비용)을 줄일 수 있는지 여부 파악.

보안 보고는 고객의 시스템 사용을 추적합니다. 다음을 포함할 수 있습니다.

  • 사용자 작업 감사. 이렇게 하려면 각 사용자가 수행하는 개별 요청을 날짜 및 시간과 함께 기록해야 합니다. 데이터는 관리자가 사용자가 지정 기간 동안 수행한 작업 시퀀스를 신속하게 다시 생성할 수 있도록 구성되어야 합니다.
  • 사용자에 의한 리소스 사용 추적. 이렇게 하려면 사용자의 각 요청이 시스템을 구성하는 다양한 리소스에 액세스하는 방법 및 액세스 기간을 기록해야 합니다. 관리자는 이 데이터를 사용하여 (예: 청구 목적으로) 지정된 기간 동안 사용자에 대한 사용률 보고서를 생성할 수 있어야 합니다.

대부분의 경우 정의된 일정에 따라 일괄 처리 프로세스에서 보고서를 생성할 수 있습니다. (대기 시간은 일반적으로 문제가 아닙니다.) 하지만 필요한 경우 임시로 생성할 수도 있어야 합니다. 예를 들어 Azure SQL Database와 같은 관계형 데이터베이스에 데이터를 저장하는 경우 SQL Server Reporting Services와 같은 도구를 통해 데이터를 추출하여 형식을 지정하고 이를 일련의 보고서로 제공할 수 있습니다.

다음 단계

  • 자동 크기 조정 지침 에서는 운영자가 지속적으로 시스템 성능을 모니터링하고 리소스 추가 또는 제거에 대한 결정을 내려야 하는 필요성을 줄여 관리 오버헤드를 낮추는 방법을 설명합니다.
  • 상태 엔드포인트 모니터링 패턴에서는 외부 도구가 노출된 엔드포인트를 통해 정기적인 간격으로 액세스할 수 있는 기능 검사를 애플리케이션 내부에 구현하는 방법을 설명합니다.
  • 우선 순위 큐 패턴에서는 긴급한 요청을 수신하여 덜 긴급한 메시지보다 먼저 처리할 수 있도록 큐에 대기 중인 메시지의 우선 순위를 지정하는 방법을 보여줍니다.