다음을 통해 공유

Azure에서 중요 업무용 워크로드의 상태 모델링 및 가시성

  • 아티클

상태 모델링 및 가시성은 강력하고 상황에 맞는 계측 및 모니터링에 중점을 둔 안정성을 최대화하기 위한 필수 개념입니다. 이러한 개념은 애플리케이션 상태에 대한 중요한 인사이트를 제공하여 문제의 신속한 식별 및 해결을 촉진합니다.

대부분의 중요 업무용 애플리케이션은 규모와 복잡성 측면에서 중요하므로 대량의 운영 데이터를 생성하므로 최적의 운영 작업을 평가하고 결정하기가 어렵습니다. 상태 모델링은 궁극적으로 애플리케이션 상태를 정량화하기 위한 주요 비즈니스 요구 사항으로 원시 모니터링 로그 및 메트릭을 보강하여 가시성을 최대화하기 위해 노력하고 있으며, 일관되고 신속한 작업을 달성하기 위해 상태 상태에 대한 자동화된 평가를 추진합니다.

이 디자인 영역은 운영 완성도를 달성하기 위해 가시성 및 운영 구문을 통해 정량화된 애플리케이션 상태 상태를 매핑하는 강력한 상태 모델을 정의하는 프로세스에 중점을 둡니다.

중요

이 문서는 Azure Well-Architected 중요 업무용 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드란?으로 시작하는 것이 좋습니다.

안정성을 최대화하기 위해 노력할 때 세 가지 기본 수준의 운영 완성도가 있습니다.

  1. 문제가 발생할 때 감지하고 대응합니다.
  2. 발생 중이거나 이미 발생한 문제를 진단합니다.
  3. 문제가 발생하기 전에 예측하고 방지합니다.

비디오: 중요 업무용 워크로드에 대한 상태 모델 정의

계층화된 애플리케이션 상태

상태 모델을 빌드하려면 먼저 계층화되고 측정 가능한 형식으로 '정상' 및 '비정상' 상태를 정량화하여 주요 비즈니스 요구 사항의 컨텍스트에서 애플리케이션 상태를 정의합니다. 그런 다음 각 애플리케이션 구성 요소에 대해 안정적인 실행 상태의 컨텍스트에서 정의를 구체화하고 애플리케이션 사용자 흐름에 따라 집계합니다. 성능 및 가용성에 대한 주요 비기능적 비즈니스 요구 사항을 중첩합니다. 마지막으로, 각 개별 사용자 흐름에 대한 상태 상태를 집계하여 전체 애플리케이션 상태를 적절하게 표현합니다. 일단 설정되면 이러한 계층화된 상태 정의를 사용하여 모든 시스템 구성 요소에서 중요한 모니터링 메트릭을 알리고 운영 하위 시스템 구성의 유효성을 검사해야 합니다.

중요

'비정상' 상태를 정의할 때 는 애플리케이션의 모든 수준에 대해 를 나타냅니다. 서비스 성능 저하를 사용할 수 없는 경우를 기준으로 한정하려면 일시적 오류 상태와 일시적이지 않은 오류 상태를 구분하는 것이 중요합니다.

디자인 고려 사항

  • 상태 모델링 프로세스는 모든 사용자 흐름을 정의하고 기능 및 논리 구성 요소 간에 종속성을 매핑하여 Azure 리소스 간의 종속성을 암시적으로 매핑하는 아키텍처 연습으로 시작하는 하향식 디자인 작업입니다.

  • 상태 모델은 나타내는 솔루션의 컨텍스트에 전적으로 종속되므로 '하나의 크기가 모두 맞지 않기 때문에'기본 제공'을 해결할 수 없습니다.

    • 애플리케이션은 컴퍼지션 및 종속성에서 다릅니다.
    • 또한 리소스에 대한 메트릭 및 메트릭 임계값은 정상 및 비정상 상태를 나타내는 값으로 세밀하게 조정되어야 하며, 이는 포괄 애플리케이션 기능 및 대상 비기능 요구 사항의 영향을 크게 받습니다.

  • 계층화된 상태 모델을 사용하면 애플리케이션 상태를 낮은 수준의 종속성으로 다시 추적할 수 있으므로 서비스 저하의 원인을 신속하게 파악할 수 있습니다.

  • 개별 구성 요소의 상태를 캡처하려면 프로덕션 부하를 반영하는 안정적인 상태에서 해당 구성 요소의 고유한 운영 특성을 이해해야 합니다. 따라서 성능 테스트는 애플리케이션 상태를 정의하고 지속적으로 평가하는 핵심 기능입니다.

  • 클라우드 솔루션 내의 오류는 격리된 상태로 발생하지 않을 수 있습니다. 단일 구성 요소의 중단으로 인해 여러 기능이 중단되거나 추가 구성 요소를 사용할 수 없게 될 수 있습니다.

    • 이러한 오류는 즉시 관찰할 수 없습니다.

디자인 권장 사항

  • 측정 가능한 상태 모델을 우선 순위로 정의하여 전체 애플리케이션에 대한 명확한 운영 이해를 보장합니다.

    • 상태 모델은 애플리케이션 구조를 계층화하고 반영해야 합니다.
    • 기본 계층은 Azure 리소스와 같은 개별 애플리케이션 구성 요소를 고려해야 합니다.
    • 기본 구성 요소는 시스템 흐름의 상태에 비즈니스 컨텍스트화된 렌즈를 구축하기 위한 주요 비기능적 요구 사항과 함께 집계되어야 합니다.
    • 전체 애플리케이션 상태에 대한 의미 있는 정의를 작성하려면 시스템 흐름을 비즈니스 중요도에 따라 적절한 가중치로 집계해야 합니다. 재정적으로 중요하거나 고객 지향적인 사용자 흐름의 우선 순위를 지정해야 합니다.
    • 상태 모델의 각 계층은 '정상' 및 '비정상' 상태가 나타내는 것을 캡처해야 합니다.
    • 히스 모델이 일시적 상태와 일시적이지 않은 비정상 상태를 구분하여 서비스 성능 저하를 사용할 수 없도록 격리할 수 있는지 확인합니다.

  • 주요 비기능적 요구 사항을 계수로 고려하여 매핑된 종속 구성 요소에 대한 상태 점수를 집계하여 모든 고유 애플리케이션 구성 요소 및 모든 사용자 흐름에 대해 세분화된 상태 점수를 사용하여 상태 상태를 나타냅니다.

    • 사용자 흐름에 대한 상태 점수는 매핑된 모든 구성 요소에서 가장 낮은 점수로 표시되어야 하며, 사용자 흐름에 대한 비기능적 요구 사항에 대한 상대적 달성을 고려해야 합니다.
    • 상태 점수를 계산하는 데 사용되는 모델은 작동 상태를 일관되게 반영해야 하며, 그렇지 않은 경우 새 학습을 반영하도록 모델을 조정하고 재배포해야 합니다.
    • 상태 상태 반영하도록 상태 점수 임계값을 정의합니다.

  • 상태 점수는 기본 메트릭을 기반으로 자동으로 계산되어야 합니다. 이 메트릭은 가시성 패턴을 통해 시각화되고 자동화된 운영 절차를 통해 작동할 수 있습니다.

    • 운영 팀이 더 이상 운영 데이터를 해석하고 애플리케이션 상태에 매핑할 필요가 없도록 상태 점수가 모니터링 솔루션의 핵심이 되어야 합니다.

  • 상태 모델을 사용하여 원시 가용성 대신 가용성 SLO(서비스 수준 목표) 달성을 계산하여 서비스 성능 저하와 사용 불가 간의 구분이 별도의 SLO로 반영되도록 합니다.

  • CI/CD 파이프라인 및 테스트 주기 내에서 상태 모델을 사용하여 코드 및 구성 업데이트 후에 애플리케이션 상태가 유지 관리되는지 유효성을 검사합니다.

    • 상태 모델은 CI/CD 프로세스의 일부로 부하 테스트 및 비정상 상황 테스트 중에 상태를 관찰하고 유효성을 검사하는 데 사용해야 합니다.

  • 상태 모델을 빌드하고 유지 관리하는 것은 반복적인 프로세스이며 지속적인 개선을 추진하기 위해 엔지니어링 투자를 조정해야 합니다.

    • 모델의 정확도를 지속적으로 평가하고 미세 조정하는 프로세스를 정의하고, 모델을 추가로 학습시키기 위해 기계 학습 모델에 투자하는 것이 좋습니다.

예제 - 계층화된 상태 모델

이는 설명 목적으로 계층화된 애플리케이션 상태 모델의 간소화된 표현입니다. 포괄적인 상황별 상태 모델은 Mission-Critical 참조 구현에 제공됩니다.

상태 모델을 구현할 때는 주요 리소스 수준 메트릭의 집계 및 해석을 통해 개별 구성 요소의 상태를 정의하는 것이 중요합니다. 리소스 메트릭을 사용하는 방법의 예는 아래 이미지입니다.

중요 업무용 예제 상태 정의

이 상태 정의는 이후 InsightsMetrics(컨테이너 인사이트) 및 AzureMetrics(AKS 클러스터에 대한 진단 설정)를 집계하고 모델링된 상태 임계값과 비교(내부 조인)를 집계하는 아래 예제 쿼리에서 설명한 대로 KQL 쿼리로 나타낼 수 있습니다.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

이후 결과 테이블 출력을 상태 점수로 변환하여 상위 수준의 상태 모델에서 더 쉽게 집계할 수 있습니다.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

이러한 집계된 점수는 나중에 Grafana와 같은 시각화 도구를 사용하여 상태 모델을 설명하는 종속성 차트로 표시될 수 있습니다.

이 이미지는 Azure Mission-Critical 온라인 참조 구현의 계층화된 상태 모델 예제를 보여 줍니다. 기본 구성 요소의 상태 변경이 사용자 흐름 및 전체 애플리케이션 상태에 연속적으로 영향을 줄 수 있는 방법을 보여 줍니다(예제 값은 이전 이미지의 테이블에 해당).

중요 업무용 예제 상태 모델 시각화

데모 비디오: 모니터링 및 상태 모델링 데모

상관 관계 분석을 위한 통합 데이터 싱크

애플리케이션 구성 요소와 기본 Azure 리소스의 로그 및 메트릭을 고려하여 정의된 히스 모델을 정확하게 나타내려면 모든 시스템 구성 요소에서 많은 운영 데이터 세트를 수집해야 합니다. 이 방대한 양의 데이터는 궁극적으로 신속한 운영 작업을 용이하게 하기 위해 거의 실시간으로 해석할 수 있는 형식으로 저장되어야 합니다. 또한 효과적인 분석이 바인딩되지 않도록 하려면 모든 포괄 데이터 집합에 대한 상관 관계가 필요하므로 상태를 계층화하여 표시할 수 있습니다.

통합 데이터 싱크는 모든 운영 데이터가 신속하게 저장되고 상관 관계가 있는 분석에 사용할 수 있도록 하여 애플리케이션 상태의 '단일 창' 표현을 빌드하는 데 필요합니다. Azure는 Azure Monitor의 산하에 여러 가지 운영 기술을 제공하며 Log Analytics 작업 영역은 운영 데이터를 저장하고 분석하는 핵심 Azure 네이티브 데이터 싱크 역할을 합니다.

중요 업무용 상태 데이터 수집

디자인 고려 사항

Azure Monitor

  • Azure Monitor는 모든 Azure 구독에 대해 기본적으로 사용하도록 설정되어 있지만 데이터 수집 및 쿼리 기능을 통합하도록 Azure Monitor 로그(Log Analytics 작업 영역) 및 Application Insights 리소스를 배포하고 구성해야 합니다.

  • Azure Monitor는 로그, 메트릭 및 분산 추적의 세 가지 유형의 가시성 데이터를 지원합니다.

    • 로그는 Azure Data Explorer 기반으로 하는 Log Analytics 작업 영역에 저장됩니다. 로그 쿼리는 구독 간에 공유할 수 있는 쿼리 팩에 저장되며 대시보드, 통합 문서 또는 기타 보고 및 시각화 도구와 같은 가시성 구성 요소를 구동하는 데 사용됩니다.
    • 메트릭은 내부 시계열 데이터베이스에 저장됩니다. 대부분의 Azure 리소스에서 메트릭은 자동으로 수집되고 93일 동안 유지됩니다 . 리소스에 대한 진단 설정을 사용하여 메트릭 데이터를 Log Analytics 작업 영역으로 보낼 수도 있습니다.

  • 모든 Azure 리소스는 로그 및 메트릭을 노출하지만 진단 데이터를 원하는 데이터 싱크로 라우팅하도록 리소스를 적절하게 구성해야 합니다.

팁

Azure는 배포된 리소스가 Log Analytics 작업 영역에 로그 및 메트릭을 보내도록 구성되도록 적용할 수 있는 다양한 기본 제공 정책을 제공합니다.

  • 규정 제어에서 운영 데이터를 원래 지역 또는 국가/지역 내에 유지하도록 요구하는 것은 드문 일이 아닙니다. 규정 요구 사항은 장기간 중요한 데이터 형식의 보존을 규정할 수 있습니다. 예를 들어 규제된 은행에서 감사 데이터는 최소 7년 동안 보존되어야 합니다.

  • 운영 데이터 형식이 다르면 보존 기간이 다를 수 있습니다. 예를 들어 보안 로그는 장기간 보존해야 할 수 있지만 성능 데이터는 AIOps 컨텍스트 외부에서 장기 보존이 필요하지 않을 수 있습니다.

  • 장기 보존 및/또는 감사 목적으로 Log Analytics 작업 영역에서 데이터를 보관 하거나 내보낼 수 있습니다.

  • 전용 클러스터는 지원되는 Azure 지역의 영역 오류로부터 가용성 영역 보호할 수 있는 배포 옵션을 제공합니다. 전용 클러스터에는 최소 일일 데이터 수집 약정이 필요합니다.

  • Log Analytics 작업 영역은 지정된 Azure 지역에 배포됩니다.

  • Log Analytics 작업 영역을 사용할 수 없도록 데이터 손실을 방지하려면 여러 진단 설정을 사용하여 리소스를 구성할 수 있습니다. 각 진단 설정은 메트릭 및 로그를 별도의 Log Analytics 작업 영역으로 보낼 수 있습니다.

    • 각 추가 Log Analytics 작업 영역으로 전송되는 데이터에는 추가 비용이 발생합니다.
    • 중복 Log Analytics 작업 영역을 동일한 Azure 지역에 배포하거나 추가 지역 중복을 위해 별도의 Azure 지역에 배포할 수 있습니다.
    • Azure 리소스에서 다른 지역의 Log Analytics 작업 영역으로 로그 및 메트릭을 보내면 지역 간 데이터 송신 비용이 발생합니다.
    • 일부 Azure 리소스에는 리소스 자체와 동일한 지역 내에 Log Analytics 작업 영역이 필요합니다.
    • Log Analytics 작업 영역에 대한 추가 가용성 옵션은 Azure Monitor 로그 모범 사례를 참조하세요.

  • Log Analytics 작업 영역 데이터를 연속, 예약 또는 일회성으로 Azure Storage 또는 Azure Event Hubs 내보낼 수 있습니다.

    • 데이터 내보내기를 사용하면 장기 데이터 보관을 허용하고 사용 불가로 인한 운영 데이터 손실 가능성을 방지할 수 있습니다.
    • 사용 가능한 내보내기 대상은 Azure Storage 또는 Azure Event Hubs. Azure Storage는 영역 또는 지역을 비롯한 다양한 중복 수준에 대해 구성할 수 있습니다. Azure Storage로의 데이터 내보내기에서는 .json 파일 내에 데이터를 저장합니다.
    • 데이터 내보내기 대상은 Log Analytics 작업 영역과 동일한 Azure 지역 내에 있어야 합니다. Log Analytics 작업 영역과 동일한 지역 내에 있는 이벤트 허브 데이터 내보내기 대상입니다. Azure Event Hubs 지역 재해 복구는 이 시나리오에 적용되지 않습니다.
    • 몇 가지 데이터 내보내기 제한 사항이 있습니다. 작업 영역의 특정 테이블만 데이터 내보내기를 지원합니다.
    • 보관을 사용하여 데이터를 내보내지 않고도 절감된 비용으로 장기 보존을 위해 Log Analytics 작업 영역에 저장할 수 있습니다.

  • Azure Monitor 로그에는 사용자 쿼리 제한 제한이 있으며, 이는 가시성 대시보드와 같은 클라이언트에 대한 가용성 감소로 나타날 수 있습니다.

    • 사용자당 5개의 동시 쿼리: 5개의 쿼리가 이미 실행 중인 경우 실행 중인 쿼리가 종료될 때까지 사용자별 동시성 큐에 추가 쿼리가 배치됩니다.
    • 동시성 큐의 시간: 쿼리가 3분 이상 동시성 큐에 있는 경우 종료되고 429 오류 코드가 반환됩니다.
    • 동시성 큐 깊이 제한: 동시성 큐는 200개의 쿼리로 제한되며 429 오류 코드로 추가 쿼리가 거부됩니다.
    • 쿼리 속도 제한: 모든 작업 영역에서 30초당 200개의 쿼리로 사용자당 제한이 있습니다.

  • 쿼리 팩은 Azure Resource Manager 리소스이며 Log Analytics 작업 영역을 사용할 수 없는 경우 로그 쿼리를 보호하고 복구하는 데 사용할 수 있습니다.

    • 쿼리 팩은 쿼리를 JSON으로 포함하며 다른 코드 기반 인프라 자산과 유사하게 Azure 외부에 저장할 수 있습니다.
      • Microsoft.Insights REST API를 통해 배포할 수 있습니다.
      • Log Analytics 작업 영역을 다시 만들어야 하는 경우 외부에 저장된 정의에서 쿼리 팩을 다시 배포할 수 있습니다.

  • Application Insights는 모든 데이터가 저장되는 Log Analytics 작업 영역에서 뒷받침되는 작업 영역 기반 배포 모델에 배포할 수 있습니다.

  • Application Insights 내에서 샘플링을 사용하도록 설정하여 전송된 원격 분석의 양을 줄이고 데이터 수집 비용을 최적화할 수 있습니다.

  • Application Insights를 포함하여 Azure Monitor에서 수집한 모든 데이터는 수집된 데이터의 양과 데이터가 보존되는 기간에 따라 요금이 청구 됩니다.

    • Log Analytics 작업 영역에 수집된 데이터는 처음 31일(Sentinel을 사용하도록 설정된 경우 90일)까지 추가 비용 없이 보존할 수 있습니다.
    • 작업 영역 기반 Application Insights에 수집된 데이터는 추가 비용 없이 처음 90일 동안 보존됩니다.

  • Log Analytics 약정 계층 가격 책정 모델은 비용 절감과 데이터 수집 요금에 대한 예측 가능한 접근 방식을 제공합니다.

    • 예약 수준 이상의 모든 사용량은 현재 계층과 동일한 가격으로 청구됩니다.

  • Log Analytics, Application Insights 및 Azure Data Explorer KQL(Kusto 쿼리 언어)을 사용합니다.

  • Log Analytics 쿼리는 Log Analytics 작업 영역(savedSearches) 내에서 함수로 저장됩니다.

디자인 권장 사항

  • Log Analytics 작업 영역을 통합 데이터 싱크로 사용하여 모든 운영 데이터 집합에 '단일 창'을 제공합니다.

    • 사용된 모든 배포 지역에서 Log Analytics 작업 영역을 분산합니다. 애플리케이션 배포가 있는 각 Azure 지역에서는 Log Analytics 작업 영역을 고려하여 해당 지역에서 시작된 모든 운영 데이터를 수집해야 합니다. 모든 전역 리소스는 기본 배포 지역 내에 배포해야 하는 별도의 전용 Log Analytics 작업 영역을 사용해야 합니다.
      • 모든 운영 데이터를 단일 Log Analytics 작업 영역으로 보내면 단일 실패 지점이 생성됩니다.
      • 데이터 보존에 대한 요구 사항은 원래 지역을 벗어나는 데이터를 금지할 수 있으며 페더레이션된 작업 영역은 기본적으로 이 요구 사항을 해결합니다.
      • 지역 간에 로그 및 메트릭 전송과 관련된 상당한 송신 비용이 있습니다.
    • 동일한 지역 내의 모든 배포 스탬프는 동일한 지역 Log Analytics 작업 영역을 사용할 수 있습니다.

  • 지역 배포 스탬프가 적은 애플리케이션에 Azure Monitor를 사용할 수 없도록 보호하기 위해 다양한 Log Analytics 작업 영역을 가리키는 여러 진단 설정을 사용하여 리소스를 구성하는 것이 좋습니다.

  • Application Insights를 모든 애플리케이션 구성 요소에서 일관된 APM(애플리케이션 성능 모니터링) 도구로 사용하여 애플리케이션 로그, 메트릭 및 추적을 수집합니다.

    • 작업 영역 기반 구성에 Application Insights를 배포하여 각 지역 Log Analytics 작업 영역에 애플리케이션 구성 요소와 기본 Azure 리소스의 로그와 메트릭이 모두 포함되도록 합니다.

  • 작업 영역 간 쿼리를 사용하여 여러 작업 영역에서 통합된 '단일 창'을 유지 관리합니다.

  • 쿼리 팩을 사용하여 작업 영역을 사용할 수 없는 경우 로그 쿼리를 보호합니다.

    • 애플리케이션 git 리포지토리 내에 쿼리 팩을 코드로서의 인프라 자산으로 저장합니다.

  • 모든 Log Analytics 작업 영역은 지역 배포 스탬프 내의 애플리케이션 리소스와 수명 주기가 다른 장기 실행 리소스로 처리되어야 합니다.

  • 장기 보존 및 분석을 위해 Log Analytics 작업 영역에서 중요한 운영 데이터를 내보내 AIOps 및 고급 분석을 용이하게 하여 기본 상태 모델을 구체화하고 예측 작업을 알릴 수 있습니다.

  • 장기 보존에 사용해야 하는 데이터 저장소를 신중하게 평가합니다. 모든 데이터를 핫 및 쿼리 가능한 데이터 저장소에 저장해야 하는 것은 아닙니다.

    • 장기 운영 데이터 스토리지를 위해 GRS 구성에서 Azure Storage를 사용하는 것이 좋습니다.
      • Log Analytics 작업 영역 내보내기 기능을 사용하여 사용 가능한 모든 데이터 원본을 Azure Storage로 내보냅니다.

  • 로그 분석 내의 운영 데이터 형식에 적절한 보존 기간을 선택하여 '핫' 가시성 요구 사항이 있는 작업 영역 내에서 더 긴 보존 기간을 구성합니다.

  • Azure Policy 사용하여 모든 지역 리소스가 운영 데이터를 올바른 Log Analytics 작업 영역으로 라우팅하도록 합니다.

참고

Azure 랜딩 존에 배포할 때 운영 데이터의 중앙 집중식 스토리지에 대한 요구 사항이 있는 경우 인스턴스화 시 데이터를 포크 하여 중앙 집중식 도구 및 애플리케이션 전용 Log Analytics 작업 영역으로 수집할 수 있습니다. 또는 중앙 팀이 애플리케이션 데이터를 쿼리할 수 있도록 애플리케이션 Log Analytics 작업 영역에 대한 액세스를 노출합니다. 궁극적으로 솔루션에서 시작된 운영 데이터는 애플리케이션 전용 Log Analytics 작업 영역 내에서 사용할 수 있는 것이 중요합니다.

SIEM 통합이 필요한 경우 원시 로그 항목을 보내지 않고 대신 중요한 경고를 보냅니다.

  • 성능을 최적화해야 하거나 샘플링하지 않으면 비용이 많이 드는 경우에만 Application Insights 내에서 샘플링을 구성합니다.

    • 과도한 샘플링은 누락되거나 부정확한 작동 신호로 이어질 수 있습니다.

  • 모든 추적 이벤트 및 로그 메시지에 상관 관계 ID를 사용하여 지정된 요청에 연결합니다.

    • 실패한 요청뿐만 아니라 모든 호출에 대한 호출자에게 상관 관계 ID를 반환합니다.

  • 애플리케이션 코드가 적절한 계측 및 로깅을 통합하여 상태 모델을 알리고 필요한 경우 후속 문제 해결 또는 근본 원인 분석을 용이하게 합니다.

    • 애플리케이션 코드는 오류 발생 시 상관 관계 ID를 포함하는 포괄적인 오류 메시지를 호출자에게 제공하여 Application Insights를 사용하여 분산 추적을 용이하게 해야 합니다.

  • 모든 로그 메시지에 구조적 로깅 을 사용합니다.

  • 모든 애플리케이션 구성 요소에 의미 있는 상태 프로브를 추가합니다.

    • AKS를 사용하는 경우 Kubernetes가 Pod가 정상인지 비정상인지를 올바르게 확인할 수 있도록 각 배포(Pod)에 대한 상태 엔드포인트를 구성합니다.
    • Azure App Service 사용하는 경우 스케일 아웃 작업으로 인해 아직 준비되지 않은 인스턴스로 트래픽을 보내고 비정상 인스턴스가 신속하게 재활용되도록 하여 오류가 발생하지 않도록 상태 검사를 구성합니다.

애플리케이션이 Microsoft Mission-Critical 지원을 구독하는 경우 Microsoft 지원 애플리케이션 상태를 보다 정확하게 모델링할 수 있도록 주요 상태 프로브를 Microsoft 지원 노출하는 것이 좋습니다.

  • 분석 모델링에 대한 추가 인사이트를 제공하기 때문에 애플리케이션 성능의 컨텍스트에서 증가된 데이터 볼륨을 허용할 수 없는 한 성공적인 상태 검사 요청을 기록합니다.

  • 운영 데이터의 일일 수집을 제한하는 일일 한도를 적용하도록 프로덕션 Log Analytics 작업 영역을 구성하지 마세요. 이로 인해 중요한 운영 데이터가 손실 될 수 있기 때문에.

    • 개발 및 테스트와 같은 하위 환경에서는 일일 한도를 선택적 비용 절감 메커니즘으로 간주할 수 있습니다.

  • 운영 데이터 수집 볼륨이 최소 계층 임계값을 충족하는 경우 약정 계층 기반 가격 책정을 사용하여 '종량제' 가격 책정 모델을 기준으로 비용 효율성을 높이기 위해 Log Analytics 작업 영역을 구성합니다.

  • 소스 제어를 사용하여 Log Analytics 쿼리를 저장하고 CI/CD 자동화를 사용하여 관련 Log Analytics 작업 영역 인스턴스에 배포하는 것이 좋습니다.

시각화

효과적인 운영을 달성하고 안정성을 극대화하려면 중요한 운영 데이터로 상태 모델을 시각적으로 나타내는 것이 필수적입니다. 궁극적으로 대시보드를 활용하여 DevOps 팀의 애플리케이션 상태에 대한 거의 실시간 인사이트를 제공하여 안정적인 상태에서 편차를 신속하게 진단할 수 있어야 합니다.

Microsoft는 Azure 대시보드, Power BI 및 Azure Managed Grafana(현재 미리 보기 상태)를 비롯한 여러 데이터 시각화 기술을 제공합니다. Azure 대시보드는 Azure Monitor 내에서 운영 데이터에 대해 긴밀하게 통합된 기본 시각화 솔루션을 제공하기 위해 배치됩니다. 따라서 중요 업무용 워크로드에 대한 운영 데이터 및 애플리케이션 상태의 시각적 표현에서 중요한 역할을 합니다. 그러나 Azure 대시보드를 전체적인 가시성 플랫폼으로 배치하는 데는 몇 가지 제한 사항이 있으며, 따라서 Azure 내에서 관리되는 솔루션으로도 제공되는 Grafana와 같은 시장 최고의 가시성 솔루션의 추가 사용에 대한 고려 사항을 고려해야 합니다.

이 섹션에서는 Azure 대시보드 및 Grafana를 사용하여 애플리케이션 상태에 기술 및 비즈니스 렌즈를 제공하고 DevOps 팀과 효과적인 운영을 가능하게 할 수 있는 강력한 대시보드 환경을 구축하는 데 중점을 둡니다. 강력한 대시보드는 이미 발생한 문제를 진단하고 발생한 문제를 검색하고 대응하는 운영 팀을 지원하는 데 필수적입니다.

디자인 고려 사항

  • 로그 쿼리를 사용하여 상태 모델을 시각화할 때는 후속 쿼리가 큐에 대기되고 제한되는 전체 쿼리 속도뿐만 아니라 동시 및 큐에 대기 중인 쿼리에 대한 Log Analytics 제한이 있습니다.

  • 상태 점수를 계산하고 나타내는 데 사용되는 운영 데이터를 검색하는 쿼리는 Log Analytics 또는 Azure Data Explorer 작성 및 실행할 수 있습니다.

  • Log Analytics는 운영 대시보드를 디자인할 때 설계해야 하는 몇 가지 쿼리 제한을 적용합니다.

  • CPU 사용률 또는 네트워크 처리량과 같은 원시 리소스 메트릭을 시각화하려면 운영 팀이 상태 상태 영향을 확인하기 위해 수동으로 평가해야 하며, 이는 활성 인시던트 중에 어려울 수 있습니다.

  • 여러 사용자가 Grafana와 같은 도구 내에서 대시보드를 사용하는 경우 Log Analytics로 전송된 쿼리 수가 빠르게 곱됩니다.

    • Log Analytics에서 동시 쿼리 제한에 도달하면 후속 쿼리가 큐에 추가되어 dashboard 환경이 '느림'으로 느껴집니다.

디자인 권장 구성

  • 모든 지역 Log Analytics 작업 영역 및 전역 Log Analytics 작업 영역에서 쿼리된 출력을 수집하고 표시하여 애플리케이션 상태에 대한 통합 보기를 빌드합니다.

참고

Azure 랜딩 존에 배포하는 경우 온-프레미스 통신을 위한 ExpressRoute와 같은 플랫폼 리소스에 대한 주요 종속성이 있는 경우 중앙 플랫폼 Log Analytics 작업 영역을 쿼리하는 것이 좋습니다.

  • '신호등' 모델은 '정상' 및 '비정상' 상태를 시각적으로 나타내는 데 사용해야 하며, 녹색은 주요 비기능적 요구 사항이 완전히 충족되고 리소스가 최적으로 활용되는 경우를 설명하는 데 사용됩니다. "녹색", "주황색" 및 "빨강"을 사용하여 "정상", "저하됨" 및 "사용할 수 없음" 상태를 나타냅니다.

  • Azure 대시보드를 사용하여 Azure Front Door에 대한 요청 수, Azure Cosmos DB의 서버 쪽 대기 시간, Event Hubs의 수신/발신 메시지, AKS의 CPU 사용률 또는 배포 상태와 같은 주요 메트릭을 나타내는 글로벌 리소스 및 지역 배포 스탬프에 대한 운영 렌즈를 만듭니다. 대시보드는 DevOps 팀이 주요 메트릭에 대한 직접적인 가시성을 갖도록 오류 시나리오에서 학습을 주입하여 운영 효율성을 높이기 위해 조정되어야 합니다.

  • Azure 대시보드를 사용하여 상태 모델을 정확하게 나타내고 비즈니스 요구 사항을 충족할 수 없는 경우 Grafana를 대체 시각화 솔루션으로 간주하여 시장을 선도하는 기능과 광범위한 오픈 소스 플러그 인 에코시스템을 제공하는 것이 좋습니다. Grafana 인프라 관리의 운영 복잡성을 방지하려면 관리되는 Grafana 미리 보기 제품을 평가합니다.

  • 자체 호스팅 Grafana를 배포할 때 고가용성 및 지리적으로 분산된 디자인을 사용하여 중요한 운영 대시보드가 지역 플랫폼 오류 및 연속 오류 시나리오에 복원력을 유지할 수 있도록 합니다.

    • Grafana 애플리케이션 노드가 상태 비저장 상태로 유지되도록 구성 상태를 Azure Database for Postgres 또는 MySQL과 같은 외부 데이터 저장소로 분리합니다.

      • 배포 지역에서 데이터베이스 복제를 구성합니다.

    • 컨테이너 기반 배포를 사용하여 지역 내의 고가용성 구성으로 Grafana 노드를 App Services에 배포합니다.

      • 고려된 배포 지역에 App Service 인스턴스를 배포합니다.

      App Services는 운영 대시보드와 같은 저규격 시나리오에 이상적인 저마찰 컨테이너 플랫폼을 제공하며, AKS에서 Grafana를 격리하면 기본 애플리케이션 플랫폼과 해당 플랫폼에 대한 운영 표현 간의 명확한 분리를 제공합니다. 추가 구성 권장 사항은 Application Platform deign 영역을 참조하세요.

    • GRS 구성에서 Azure Storage를 사용하여 사용자 지정 시각적 개체 및 플러그 인을 호스트하고 관리합니다.

    • 앱 서비스 및 데이터베이스 읽기 복제본(replica) Grafana 구성 요소를 최소 두 개의 배포 지역에 배포하고 Grafana가 고려된 모든 배포 지역에 배포되는 모델을 사용하는 것이 좋습니다.

= 99.99% SLO를 대상으로 하는 >시나리오의 경우 주요 운영 대시보드의 전반적인 안정성을 최대화하려면 최소 3개의 배포 지역 내에 Grafana를 배포해야 합니다.

  • KQL 'union' 연산자를 사용하는 등 쿼리를 단일 또는 적은 수의 쿼리로 집계하고 dashboard 적절한 새로 고침 속도를 설정하여 Log Analytics 쿼리 제한을 완화합니다.

    • 적절한 최대 새로 고침 속도는 dashboard 쿼리의 수와 복잡성에 따라 달라집니다. 구현된 쿼리를 분석해야 합니다.

  • Log Analytics의 동시 쿼리 제한에 도달하는 경우 dashboard 필요한 데이터를 Azure SQL 같은 고성능 데이터 저장소에 저장하여(일시적으로) 검색 패턴을 최적화하는 것이 좋습니다.

자동화된 인시던트 대응

애플리케이션 상태의 시각적 표현은 문제 검색 및 진단을 지원하는 귀중한 운영 및 비즈니스 인사이트를 제공하지만 운영 팀의 준비 및 해석과 후속 사람이 트리거한 응답의 효과에 의존합니다. 따라서 안정성을 최대화하려면 사전에 감지하고 거의 실시간으로 문제에 대응하기 위해 광범위한 경고를 구현해야 합니다.

Azure Monitor 는 작업 그룹을 통해 운영 신호를 검색, 분류 및 응답하는 광범위한 경고 프레임워크를 제공합니다. 따라서 이 섹션에서는 Azure Monitor 경고를 사용하여 정상 애플리케이션 상태의 현재 또는 잠재적 편차에 대응하여 자동화된 작업을 구동하는 데 중점을 줍니다.

중요

경고 및 자동화된 작업은 더 큰 부정적인 영향이 발생하기 전에 발생하는 문제를 효과적으로 감지하고 신속하게 대응하는 데 중요합니다. 경고는 들어오는 신호를 해석하고 문제가 발생하기 전에 이를 방지하기 위해 응답하는 메커니즘도 제공합니다.

디자인 고려 사항

  • 경고 규칙은 들어오는 신호에 대해 조건부 조건이 충족되면 발생하도록 정의됩니다. 여기에는 메트릭, 로그 쿼리 또는 가용성 테스트와 같은 다양한 데이터 원본이 포함될 수 있습니다.

  • 경고는 특정 리소스의 Log Analytics 또는 Azure Monitor 내에서 정의할 수 있습니다.

  • Log Analytics 내에서 모든 진단 데이터 요소를 사용할 수 있는 것은 아니므로 일부 메트릭은 Azure Monitor 내에서만 심문할 수 있습니다.

  • Azure Monitor 경고 API를 사용하여 활성 및 기록 경고를 검색할 수 있습니다.

  • 다음을 위해 설계해야 하는 경고 및 작업 그룹과 관련된 구독 제한이 있습니다.

    • 구성 가능한 경고 규칙 수에 대한 제한이 있습니다.
    • 경고 API에는 극단적인 사용 시나리오에 대해 고려해야 하는 제한 제한이 있습니다.
    • 작업 그룹에는 구성 가능한 응답 수에 대한 몇 가지 하드 제한이 있으며, 이를 위해 설계해야 합니다.
      • 각 응답 유형에는 1,000개의 작업으로 제한되는 전자 메일을 제외한 10개의 작업으로 제한됩니다.

  • 경고는 모델의 '루트' 채점 함수에서 저장된 로그 검색 쿼리에 대한 경고 규칙을 만들어 계층화된 상태 모델 내에 통합할 수 있습니다. 예를 들어 'WebsiteHealthScore'를 사용하고 '비정상' 상태를 나타내는 숫자 값에 대해 경고합니다.

디자인 권장 사항

  • 리소스 중심 경고의 경우 Azure Monitor 내에서 경고 규칙을 만들어 모든 진단 데이터를 경고 규칙 조건에 사용할 수 있는지 확인합니다.

  • DevOps 접근 방식을 지원하기 위해 서비스 팀과 정렬된 최소 수의 작업 그룹 내에서 자동화된 작업을 통합합니다.

  • 가능한 경우 Azure 네이티브 자동 크기 조정 기능을 사용하여 자동화된 크기 조정 작업을 통해 과도한 리소스 사용률 신호에 응답합니다. 기본 제공 자동 크기 조정 기능을 적용할 수 없는 경우 구성 요소 상태 점수를 사용하여 신호를 모델링하고 자동화된 크기 조정 작업으로 응답할 시기를 결정합니다. 크기 조정 응답은 다른 구성 요소와 관련하여 스케일링해야 하는 구성 요소를 포함하도록 구성 요소 간의 크기 조정 관계를 정량화하는 용량 모델에 따라 자동화된 크기 조정 작업이 정의되었는지 확인합니다.

  • 비즈니스 영향에 따라 결정되어야 하는 우선 순위가 지정된 순서를 수용하기 위한 작업을 모델링합니다.

  • Azure Monitor 경고 API를 사용하여 기록 경고를 수집하여 고급 분석을 위한 '콜드' 운영 스토리지 내에 통합합니다.

  • 자동화된 응답을 충족할 수 없는 중요한 오류 시나리오의 경우 수동 해석 및 로그아웃이 제공된 후 신속하고 일관된 작업을 추진하기 위해 운영 'Runbook Automation'이 제자리에 있는지 확인합니다. 경고 알림을 사용하여 수동 해석이 필요한 문제를 신속하게 식별

  • 이전에 고려되지 않은 새로운 실패 시나리오가 새로운 자동화된 작업 내에서 완전히 수용될 수 있도록 경고의 증분 개선을 추진하기 위해 엔지니어링 스프린트 내에서 허용량을 만듭니다.

  • CI/CD 프로세스의 일부로 운영 준비 테스트를 수행하여 배포 업데이트에 대한 주요 경고 규칙의 유효성을 검사합니다.

AIOps(예측 작업 및 AI 작업)

기계 학습 모델을 적용하여 운영 데이터의 상관 관계를 지정하고 우선 순위를 지정할 수 있으므로 과도한 경고 '노이즈'를 필터링하고 영향을 받기 전에 문제를 예측하는 것과 관련된 중요한 인사이트를 수집하고 인시던트 대응을 가속화할 수 있습니다.

특히 AIOps 방법론은 시스템, 사용자 및 DevOps 프로세스의 동작에 대한 중요한 인사이트에 적용할 수 있습니다. 이러한 인사이트에는 지금 발생하는 문제 식별(감지), 문제가 발생하는 이유 정량화(진단) 또는 향후 발생할 일 신호(예측)가 포함될 수 있습니다. 이러한 인사이트를 사용하여 주요 비즈니스 메트릭, 시스템 품질 메트릭 및 DevOps 생산성 메트릭을 사용하여 활성 또는 잠재적인 문제를 완화하기 위해 애플리케이션을 조정하고 최적화하는 작업을 추진하여 비즈니스 영향에 따라 우선 순위를 지정할 수 있습니다. 수행된 작업은 기본 모델을 추가로 학습하여 추가 효율성을 높이는 피드백 루프를 통해 시스템에 주입될 수 있습니다.

중요 업무용 AIOps 방법론

AZURE 내에는 AIOps에 대한 분석 모델을 빌드하고 학습하는 데 사용할 수 있는 Azure Synapse 및 Azure Databricks와 같은 여러 분석 기술이 있습니다. 따라서 이 섹션에서는 AIOps를 수용하고 예측 작업을 추진하기 위해 애플리케이션 디자인 내에서 이러한 기술을 배치하는 방법에 중점을 두고 강력한 새로운 기능과 함께 Azure 데이터 서비스의 최고를 결합하여 마찰을 줄이는 Azure Synapse 집중합니다.

AIOps는 문제가 발생하기 전에 더 잘 대응하고 방지하기 위해 지속적인 기간 동안 관찰된 복잡한 운영 신호를 해석하고 상관 관계를 지정하는 예측 작업을 구동하는 데 사용됩니다.

디자인 고려 사항

  • Azure Synapse Analytics는 여러 ML(Machine Learning) 기능을 제공합니다.

    • ML 모델은 MLLib, SparkML 및 MMLSpark를 비롯한 라이브러리와 Scikit Learn과 같은 인기 있는 오픈 소스 라이브러리가 있는 Synapse Spark 풀에서 학습 및 실행할 수 있습니다.
    • ML 모델은 PySpark/Python, Scala 또는 .NET과 같은 일반적인 데이터 과학 도구를 사용하여 학습할 수 있습니다.

  • Synapse Analytics는 Azure Synapse Notebooks를 통해 Azure ML과 통합되어 자동화된 ML을 사용하여 Azure ML 작업 영역에서 ML 모델을 학습할 수 있습니다.

  • 또한 Synapse Analytics를 사용하면 Azure Cognitive Services 를 사용하여 변칙 검색과 같은 다양한 도메인의 일반적인 문제를 해결하는 ML 기능을 사용할 수 있습니다. Cognitive Services는 Azure Synapse, Azure Databricks 및 클라이언트 애플리케이션의 SDK 및 REST API를 통해 사용할 수 있습니다.

  • Azure Synapse 기본적으로 ETL(추출, 변환 및 로드) 또는 오케스트레이션 파이프라인 내에서 데이터를 수집하는 Azure Data Factory 도구와 통합됩니다.

  • Azure Synapse Azure Blob Storage 또는 Azure Data Lake Storage 저장된 데이터에 외부 데이터 세트를 등록할 수 있습니다.

    • 등록된 데이터 세트는 Synapse Spark 풀 데이터 분석 작업에서 사용할 수 있습니다.

  • 추가 Spark 기능을 위해 Azure Databricks를 Azure Synapse Analytics 파이프라인에 통합할 수 있습니다.

    • Synapse는 데이터를 읽고 Databricks 클러스터로 보내도록 오케스트레이션하며, 여기서 ML 모델 학습을 위해 변환하고 준비할 수 있습니다.

  • 원본 데이터는 일반적으로 분석 및 ML에 대해 준비해야 합니다.

    • Synapse는 T-SQL 및 기본 제공 시각화를 사용하는 Apache Spark, Synapse Notebook 및 서버리스 SQL 풀을 포함하여 데이터 준비를 지원하는 다양한 도구를 제공합니다.

  • 학습, 운영 및 배포된 ML 모델은 Synapse에서 일괄 채 점에 사용할 수 있습니다.

    • CI/CD 파이프라인에서 회귀 또는 저하 예측 실행과 같은 AIOps 시나리오에는 실시간 채점이 필요할 수 있습니다.

  • AIOps 방법론의 컨텍스트에서 완전히 이해되어야 하는 Azure Synapse 대한 구독 제한이 있습니다.

  • AIOps를 완전히 통합하려면 근 실시간 가시성 데이터를 지속적으로 실시간 ML 유추 모델에 공급해야 합니다.

    • 변칙 검색과 같은 기능은 가시성 데이터 스트림 내에서 평가되어야 합니다.

디자인 권장 사항

  • AIOps 모델 학습에 완전한 운영 데이터 세트를 사용할 수 있도록 모든 Azure 리소스 및 애플리케이션 구성 요소가 완전히 계측되었는지 확인합니다.

  • 분석을 위해 전역 및 지역 Azure Storage 계정에서 Azure Synapse Log Analytics 운영 데이터를 수집합니다.

  • Azure Monitor 경고 API를 사용하여 기록 경고를 검색하고 이후 ML 모델 내에서 작동 데이터를 사용할 수 있도록 콜드 스토리지 내에 저장합니다. Log Analytics 데이터 내보내기를 사용하는 경우 내보낸 Log Analytics 데이터와 동일한 Azure Storage 계정에 기록 경고 데이터를 저장합니다.

  • 수집된 데이터가 ML 학습을 위해 준비되면 Synapse 데이터 준비 컴퓨팅 리소스를 실행할 필요 없이 ML 모델 학습에 사용할 수 있도록 Azure Storage에 다시 기록합니다.

  • ML 모델 운영화가 일괄 처리 및 실시간 채점을 모두 지원하는지 확인합니다.

  • AIOps 모델이 만들어지면 MLOps를 구현하고 DevOps 사례를 적용하여 학습, 운영화, 점수 매기기 및 지속적인 개선을 위한 ML 수명 주기를 자동화 합니다. AIOps ML 모델에 대한 반복 CI/CD 프로세스를 만듭니다.

  • 관리 및 통합 오버헤드가 낮기 때문에 특정 예측 시나리오에 대해 Azure Cognitive Services 를 평가합니다. 변칙 검색을 고려하여 가시성 데이터 스트림의 예기치 않은 분산에 빠르게 플래그를 지정합니다.

다음 단계

배포 및 테스트 고려 사항을 검토합니다.

배포 및 테스트