Share via

워크로드에 대한 상태 모델링

  • 아티클

클라우드 애플리케이션은 대량의 운영 데이터를 생성하므로 문제를 신속하게 파악하고 resolve 어렵습니다. 이 문제의 일반적인 이유는 워크로드의 기능에 맞게 사용자 지정된 상태 기준이 없으며 해당 기준에서 드리프트를 감지할 수 없기 때문입니다.

상태 모델링은 비즈니스 컨텍스트와 원시 모니터링 데이터를 결합하여 워크로드의 전반적인 상태를 정량화하는 가시성 연습입니다. 워크로드를 모니터링할 수 있는 기준을 설정하는 데 도움이 됩니다. 인프라 및 애플리케이션 구성 요소의 원격 분석과 같은 데이터를 고려해야 합니다. 상태 모델링은 워크로드의 품질 목표를 달성하는 데 필요한 다른 정보를 통합할 수도 있습니다.

성능 문제 또는 작동 저하로 인해 예상된 작동 상태에서 드리프트가 발생할 수 있습니다. 워크로드의 상태를 모델링하여 드리프트를 식별하고 비즈니스 영향을 고려하는 정보에 입각한 운영 결정을 내릴 수 있습니다.

건강 모델링은 부족 운영 지식과 실행 가능한 통찰력 사이의 격차를 해소합니다. 중요한 문제를 효과적으로 관리하는 데 도움이 됩니다. 이 개념은 안정성과 운영 효율성을 극대화하는 데 필수적입니다.

이 가이드에서는 워크로드 및 모든 하위 시스템의 런타임 상태를 평가하는 모델을 빌드하는 방법을 포함하여 상태 모델링에 대한 실용적인 지침을 제공합니다.

용어 정의
상태 모델링 비즈니스 컨텍스트를 사용하여 모니터링 데이터를 상태로 해석하는 가시성 연습입니다.
상태 모델 지정된 scope 대한 논리적 엔터티 및 해당 관계의 그래픽 표현입니다. 각 노드에는 모델 전체에서 모니터링 데이터를 합리화하는 상태 정의가 있습니다.
상태 엔터티 시스템의 개별 단위, 여러 관련 엔터티의 논리적 조합 또는 전체 시스템을 나타내는 논리적 구성 요소입니다.
성능 상태 엔터티의 상태에 대한 의미 있는 운영 인사이트를 제공하는 정의되고 측정 가능한 상태.
상태 신호 엔터티의 작동 동작에 대한 인사이트를 제공하는 개별 데이터 스트림입니다.
모델 모델 엔터티가 구성 요소 시스템의 고유한 상태 모델을 나타내는 집계 모델링 scope.

이 비디오를 watch 상태 모델링에 대한 높은 수준의 이해를 얻는 것이 좋습니다.

상태, 상태 모델링 및 상태 모델이란?

상태라는 용어는 엔터티 및 해당 종속성의 운영 상태 나타냅니다. 해당 엔터티는 시스템의 개별 단위, 여러 관련 엔터티의 논리적 조합 또는 전체 시스템일 수 있습니다.

다음 세 가지 상태 중 하나로 상태를 나타내는 것이 좋습니다.

  • 정상: 최적으로 작동하고 품질 기대치를 충족합니다.

  • 저하됨: 잠재적인 문제를 나타내는 건강한 행동보다 작음

  • 비정상: 위험 상태이며 즉각적인 주의가 필요합니다.

참고

상태 대신 점수를 사용하여 상태를 표시하여 더 많은 데이터 세분성을 제공할 수 있습니다.

상태 상태는 모니터링 데이터를 도메인 정보와 결합하여 파생됩니다. 각 상태는 정의되어야 하며 측정 가능해야 합니다. 상태 상태는 엔터티의 작동 동작에 대한 인사이트를 제공하는 개별 데이터 스트림인 상태 신호를 사용하여 계산됩니다. 신호에는 메트릭, 로그, 추적 또는 기타 품질 특성이 포함될 수 있습니다. 예를 들어 VM(가상 머신) 엔터티에 대한 상태 신호는 CPU 사용률 메트릭을 추적할 수 있습니다. 이 엔터티에 대한 다른 신호에는 메모리 사용량, 네트워크 대기 시간 또는 오류 비율이 포함될 수 있습니다.

상태 신호를 정의할 때 워크로드에 대한 비기능 요구 사항을 고려합니다. CPU 사용률 예제에서 각 상태의 예상 임계값을 포함합니다. 사용률이 워크로드 요구 사항에 따라 허용되는 임계값을 초과하면 시스템이 정상 에서 성능 저하 또는 비정상으로 전환됩니다. 이러한 상태 변경은 적절한 경고 또는 작업을 트리거합니다.

상태 모델링을 사용하려면 엔터티에 여러 상태 신호에서 파생되고 워크로드에 대해 컨텍스트화되는 잘 정의된 상태가 있어야 합니다. 예를 들어 VM의 상태 정의는 다음과 같습니다.

  • 정상: 응답 시간, 리소스 사용률 및 전반적인 시스템 성능과 같은 주요 비기능 요구 사항 및 대상이 완전히 충족됩니다. 예를 들어 요청의 95%는 500밀리초 이내에 처리됩니다. 워크로드는 CPU, 메모리 및 스토리지와 같은 VM 리소스를 최적으로 사용하고 워크로드 요구와 사용 가능한 용량 간의 균형을 유지합니다. 사용자 환경은 예상 수준입니다.

  • 성능 저하: 리소스가 최적으로 수행되지 않지만 여전히 작동합니다. 예를 들어 스토리지 디스크에 제한 문제가 있습니다. 사용자에게 느린 응답이 발생할 수 있습니다.

  • 비정상: 성능 저하가 허용되는 제한을 초과합니다. 리소스가 더 이상 응답하거나 사용할 수 없으며 시스템이 더 이상 허용 가능한 성능 수준을 충족하지 않습니다. 사용자 환경은 심각한 영향을 받습니다.

상태 모델링의 결과는 워크로드 아키텍처에 대한 논리적 엔터티 및 해당 관계의 모델 또는 그래픽 표현입니다. 각 노드에는 상태 정의가 있습니다.

중요

상태 모델링 은 비즈니스 시나리오를 잘 이해하고 있는 경우 다양한 범위에서 구현하고 적용할 수 있는 추상 개념입니다.

상태 모델 정의를 보여 주는 다이어그램입니다.

이미지에서:

  • 엔터티는 시스템의 측면을 나타내는 워크로드의 논리적 구성 요소입니다. 서버, 데이터베이스 및 네트워크와 같은 인프라 구성 요소일 수 있습니다. 특정 애플리케이션 모듈, Pod, 서비스 또는 마이크로 서비스일 수도 있습니다. 또는 엔터티가 워크로드 내에서 사용자 상호 작용 및 시스템 흐름을 캡처할 수 있습니다.

    참고

    사용자 및 시스템 흐름은 애플리케이션 및 인프라 구성 요소를 포함하는 비즈니스 시나리오에서 비기능적 요구 사항을 요약합니다. 이 요약은 애플리케이션의 비즈니스 가치를 반영합니다.

  • 엔터티 간의 관계는 시스템 내의 종속성 체인을 미러. 예를 들어 애플리케이션 모듈은 관계를 형성하는 특정 인프라 구성 요소를 호출할 수 있습니다.

전자 상거래 워크로드가 Azure Service Bus 큐에서 실패한 메시지가 급증하여 결제가 실패하는 시나리오를 고려합니다. 이 문제는 묵시적 수익 손실로 인해 organization 매우 중요합니다. 애플리케이션 개발자는 이 메트릭 급증이 지불에 미치는 영향을 이해할 수 있지만 이 부족 지식은 운영 팀 간에 자주 공유되지 않습니다.

상태 모델은 운영자에게 문제와 그 효과에 대한 즉각적인 가시성을 제공할 수 있습니다. 결제 흐름은 워크로드 구성 요소 중 하나인 Service Bus에 따라 달라집니다. 시각적 표현은 Service Bus instance 성능이 저하된 상태와 결제 흐름에 미치는 영향을 보여줍니다. 운영자는 문제의 중요성을 이해하고 해당 특정 구성 요소에 수정 작업을 집중할 수 있습니다.

상태 모델링은 이전 시나리오에서 다음과 같은 방법으로 중요했습니다.

  • 더 빠른 문제 격리를 사용하도록 설정하여 TTD(감지 시간)와 TTM(완화 시간)을 개선하여 문제 및 잠재적 수정 사항을 더 빠르게 검색했습니다.

  • 운영자는 상태 상태에 따라 경고를 수신하여 불필요한 노이즈를 줄입니다. 운영자는 결제에 미치는 비즈니스 영향에 대한 특정 컨텍스트를 제공하는 알림을 받았습니다.

  • 종속성 체인을 통해 운영자는 운영 문제의 정도를 완전히 이해할 수 있습니다. 이 지식은 영향 평가를 가속화하고 우선 순위가 지정된 응답으로 이어졌습니다. 연산자는 계단식 또는 상관 관계가 있는 문제도 쉽게 식별할 수 있습니다.

  • 운영자는 상태 모델이 변칙의 근본 원인과 관련된 특정 상태 신호에 대한 인사이트를 제공했기 때문에 정확도로 인시던트 후 활동을 수행했습니다.

  • 모든 팀 구성원에게 모니터링 데이터를 의미 있게 만들었습니다. 그것은 부족 지식과 공유 통찰력 사이의 격차를 해소.

  • 이 organization AI 기반 운영에 대한 향후 투자의 기준으로 상태 모델을 사용하여 지능형 인사이트를 도출했습니다.

상태 모델 스키마

상태 모델은 가시성 사용 사례에 최적화된 고유한 데이터 스키마를 제공합니다. 이 스키마는 추상 개념에서 측정 가능한 솔루션으로 상태 모델링을 사용합니다. 특정 요구 사항, 목표 및 아키텍처 컨텍스트를 모델링하여 고유한 시나리오에 맞게 상태 데이터를 조정할 수 있습니다.

상태 정의를 보여 주는 다이어그램입니다.

상태는 상대 데이터 개념입니다. 각 모델은 동일한 엔터티 집합을 사용하는 경우에도 컨텍스트 scope 대해 고유하고 우선 순위가 지정된 상태 데이터를 나타냅니다. 특정 시나리오에서 정상 을 구성하는 것은 다른 컨텍스트에서 크게 다를 수 있습니다.

예를 들어 워크로드 내에서 동일한 유형의 Azure 리소스를 고려합니다.

  • VM A는 CPU에 민감한 애플리케이션을 실행합니다.
  • VM B는 메모리 집약적 서비스를 처리합니다.

이러한 컴퓨터에 대한 상태 정의는 다릅니다. CPU 사용률 메트릭은 VM A의 상태 상태 영향을 줄 수 있으며 VM B는 메모리 관련 메트릭의 우선 순위를 지정할 수 있습니다.

중요

상태 모델이 모든 오류를 동일하게 처리해서는 안 됩니다. 예상 또는 일시적이지만 복구 가능한 오류와 실제 재해 상태를 명확하게 구분해야 합니다.

상태 모델 빌드

상태 모델을 빌드하는 첫 번째 단계는 일반적으로 다음 섹션에 설명된 활동을 포함하는 논리적 디자인 연습입니다.

상태 모델링 활동을 보여 주는 다이어그램

워크로드 디자인 평가

워크로드 디자인의 다음 구성 요소를 평가하여 이 논리적 디자인 연습을 시작합니다.

  • 컴퓨팅 클러스터 및 데이터베이스와 같은 인프라 구성 요소

  • 컴퓨팅 및 관련 구성 요소에서 실행되는 애플리케이션 구성 요소

  • 구성 요소 간의 논리적 또는 물리적 종속성

  • 사용자 및 시스템 흐름

예를 들어 전자 상거래 애플리케이션의 상태 모델은 사용자 로그인, 체크 아웃 및 결제와 같은 중요한 프로세스의 현재 상태를 나타내야 합니다.

비즈니스 요구 사항을 사용하여 컨텍스트화

각 흐름이 organization 미치는 상대적 중요도와 전반적인 영향을 평가합니다. 사용자 환경, 보안 및 운영 효율성과 같은 요소를 고려합니다. 예를 들어 대부분의 시나리오에서 지불 프로세스의 실패는 보고 프로세스의 실패보다 더 중요할 수 있습니다.

각 흐름과 관련된 문제를 처리하기 위한 에스컬레이션 경로를 식별합니다. 자세한 내용은 흐름을 사용하여 워크로드 디자인 최적화를 참조하세요.

참고

비즈니스 시나리오와 컨텍스트를 통합할 때만 상태 모델링의 가치를 실현할 수 있습니다. 그런 다음 운영 문제로 인한 비즈니스 영향을 합리화할 수 있습니다.

안정성 메트릭에 매핑

애플리케이션 디자인 전체 에서 관련 안정성 메트릭 을 찾습니다.

전체 애플리케이션 및 개별 비즈니스 프로세스에 대한 SLI(서비스 수준 지표) 및 SLO(서비스 수준 목표)를 정의하는 것이 좋습니다. 이러한 SLO 및 SLO는 상태 모델에 대해 고려되는 특정 상태 신호와 일치해야 합니다. 이렇게 하면 애플리케이션에 허용되는 서비스 수준의 달성을 정확하게 반영하는 포괄적인 상태 정의를 만듭니다.

중요

SLA 및 SLO는 중요한 상태 신호입니다. 다른 품질 특성과 함께 원하는 서비스 수준을 반영하는 의미 있는 상태 정의를 만듭니다. 또한 SHO(서비스 상태 목표)를 정의하여 집계된 시간 범위에서 달성하려는 상태를 캡처할 수 있습니다.

상태 신호 식별

포괄적인 상태 모델을 빌드하려면 메트릭, 로그 및 추적을 비롯한 다양한 유형의 모니터링 데이터의 상관 관계를 지정합니다. 이렇게 하면 상태 개념이 특정 엔터티 또는 전체 워크로드의 런타임 상태를 정확하게 반영하도록 합니다.

플랫폼 메트릭 및 로그 사용

상태 모델링의 컨텍스트에서 기본 Azure 리소스에서 플랫폼 수준 메트릭 및 로그를 수집하는 것이 중요합니다. 이러한 메트릭에는 CPU 백분율, 네트워크 내 네트워크 및 네트워크 출력, 초당 디스크 작업이 포함됩니다. 상태 모델에서 이 데이터를 사용하여 신뢰할 수 있는 환경을 유지하면서 잠재적인 문제를 감지하고 예측할 수 있습니다.

또한 이 방법을 사용하면 일시적인 오류, 일시적인 중단, 비정형 오류 또는 지속적인 문제를 구분할 수 있습니다.

참고

진단 로그 및 메트릭을 선택한 로그 집계 기술로 전달하도록 모든 애플리케이션 리소스를 구성하는 것이 좋습니다. Azure Policy 사용하여 가드레일을 빌드하여 애플리케이션 전체에서 일관된 진단 설정을 보장하고 각 Azure 서비스에 대해 선택한 구성을 적용합니다.

애플리케이션 로그 추가

애플리케이션 로그는 상태 모델에 대한 진단 데이터의 중요한 원본입니다. 다음은 애플리케이션 로깅에 대한 몇 가지 모범 사례입니다.

  • 의미 체계 또는 구조화된 로깅을 사용합니다. 구조적 로그는 대규모 로그 데이터의 자동화된 사용 및 분석을 용이하게 합니다.

    스토리지 계정 대신 Azure Monitor 로그 작업 영역에 Azure 리소스 메트릭 및 진단 데이터를 저장하는 것이 좋습니다. 이 방법을 사용하면 효율적인 평가를 위해 Kusto 쿼리를 사용하여 상태 신호를 만들 수 있습니다.

  • 프로덕션 환경에서 데이터를 기록합니다. 애플리케이션이 프로덕션 환경에서 작동하는 동안 포괄적인 데이터를 캡처합니다. 상태 평가 및 감지된 프로덕션 문제를 진단하려면 충분한 정보가 필요합니다.

  • 서비스 경계에서 이벤트를 기록합니다. 서비스 경계를 통과하는 상관 관계 ID를 포함합니다. 트랜잭션에 여러 서비스가 포함되고 그 중 하나가 실패하는 경우 상관 관계 ID를 사용하면 애플리케이션 전체에서 요청을 추적하고 실패 원인을 파악할 수 있습니다.

  • 비동기 로깅을 사용합니다. 애플리케이션 코드를 차단할 수 있는 동기 로깅 작업을 방지합니다. 비동기 로깅은 로그 쓰기 중에 요청 백로그를 방지하여 가용성을 보장합니다.

  • 감사에서 애플리케이션 로깅을 분리합니다. 진단 로그와 별도로 감사 로그를 유지 관리합니다. 감사 레코드는 규정 준수 또는 규정 요구 사항을 제공하지만 고유하게 유지하면 트랜잭션 삭제를 방지할 수 있습니다.

분산 추적 구현

중요한 시스템 흐름 간에 원격 분석의 상관 관계를 지정하여 분산 추적을 구현합니다. 상호 연결된 원격 분석은 엔드 투 엔드 트랜잭션에 대한 인사이트를 제공하며 오류가 발생할 때 효과적인 RCA(근본 원인 분석)에 필수적입니다.

상태 프로브 사용

애플리케이션 외부에서 상태 프로브를 구현하고 실행하여 애플리케이션의 상태 및 응답성을 명시적으로 검사. 프로브 응답을 상태 모델 내에서 신호로 사용합니다.

애플리케이션 전체 또는 개별 구성 요소에서 응답 시간을 측정하여 상태 프로브를 구현할 수 있습니다. 프로브는 프로세스를 실행하여 대기 시간을 측정하고 가용성을 검사 애플리케이션에서 정보를 추출할 수 있습니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴을 참조하세요.

대부분의 부하 분산 장치는 구성된 간격으로 애플리케이션 엔드포인트를 ping하는 상태 프로브 실행을 지원합니다. 또는 외부 Watchdog 서비스를 사용할 수 있습니다. Watchdog 서비스는 워크로드의 여러 구성 요소에서 상태 검사를 집계합니다. Watchdog은 알려진 상태 상태에 대한 즉각적인 수정을 수행하는 코드를 호스트할 수도 있습니다.

구조적 및 기능적 모니터링 기술 채택

구조적 모니터링에는 애플리케이션에 의미 체계 로그 및 메트릭이 포함됩니다. 애플리케이션은 현재 메모리 사용량, 요청 대기 시간 및 기타 관련 애플리케이션 수준 데이터를 포함하는 이러한 메트릭을 직접 수집합니다.

기능 모니터링을 사용하여 모니터링 프로세스를 강화합니다. 이 방법은 플랫폼 서비스 측정과 전반적인 사용자 환경에 미치는 영향에 중점을 둡니다. 구조적 모니터링과 달리 기능 모니터링에는 시스템에 대한 자세한 지식이 필요하지 않습니다. 애플리케이션의 외부에서 볼 수 있는 동작을 테스트합니다. 이 방법은 SLO 및 SLA를 평가하는 데 유용합니다.

디자인 모델링

식별된 애플리케이션 디자인을 엔터티 및 관계로 나타냅니다. 상태 신호를 특정 구성 요소에 매핑하여 엔터티 수준에서 상태 상태를 정량화합니다. 구성 요소의 중요도를 고려하여 상태 상태가 모델을 통해 전파되는 방법을 결정합니다. 예를 들어 보고 구성 요소는 다른 구성 요소만큼 중요하지 않을 수 있으므로 전체 워크로드 상태에 다른 영향을 줍니다.

실행 가능한 경고 설정

평가된 상태 를 사용하여 경고 및 자동화된 작업을 트리거합니다. 상태를 핵심 가시성 데이터 테넷으로 기존 운영 Runbook 내에 통합해야 합니다.

일반적으로 모니터링 데이터와 경고 규칙 간에 일대일 매핑이 있으므로 경고 폭풍 및 주변 경고 노이즈와 같은 바람직하지 않은 결과가 발생할 수 있습니다. 예를 들어 컴퓨팅 클러스터에서 CPU 사용률 및 오류 수에 따라 대량의 VM 수준 경고가 실패하는 동안 연산자를 압도하고 해결이 지연될 수 있습니다. 마찬가지로 구성된 경고 수가 많을 때 주변 경고 노이즈는 종종 간과되거나 무시되는 경고를 발생합니다.

상태 모델은 모니터링 데이터와 경고 규칙 간에 분리를 도입합니다. 상태 정의는 많은 신호를 단일 상태 상태로 집계하여 운영자가 organization 중요한 고가치 경고에만 집중할 수 있도록 경고 수를 줄입니다. 전자 상거래 시나리오를 고려합니다. Service Bus 큐와 같은 기본 리소스의 변경 내용 대신 프로세스 지불 흐름 상태의 변경 내용에 대한 알림을 보내도록 경고를 설정할 수 있습니다.

참고

상태 모델의 모든 계층에서 경고하는 기능은 다양한 워크로드 가상 사용자에 대한 유연성을 제공합니다. 애플리케이션 소유자 및 제품 관리자는 주요 비즈니스 시나리오 또는 전체 워크로드의 상태 변경에 대해 경고할 수 있습니다. 운영자는 인프라 또는 애플리케이션 구성 요소의 상태에 따라 경고를 받을 수 있습니다.

모델 시각화

테이블 또는 그래프와 같은 시각적 표현을 만들어 상태 모델의 현재 상태와 기록을 효과적으로 전달합니다. 시각화가 비즈니스 컨텍스트와 일치하고 실행 가능한 인사이트를 제공하는지 확인합니다.

상태 모델을 시각화할 때 종속성 체인에서 상태 상태를 즉시 인사이트를 얻을 수 있도록 신호등 접근 방식을 채택하는 것이 좋습니다.

정상의 경우 녹색, 성능이 저하된 경우 황색, 비정상 상태의 경우 빨간색을 할당합니다. 색으로 구분된 상태를 빠르게 식별하면 애플리케이션 저하의 근본 원인을 효율적으로 찾을 수 있습니다.

이 다이어그램은 신호등 접근 방식을 사용하는 상태 모델을 보여 줍니다.

참고

건강 모델에 대한 dashboard 만들 때 시각 장애가 있는 사용자를 위한 접근성 요구 사항을 고려하는 것이 좋습니다. 다이어그램 모범 사례는 아키텍처 디자인 다이어그램을 참조하세요.

상태 모델 채택

상태 모델을 빌드한 후 다음 사용 사례를 고려하여 오류 또는 운영 문제에 대한 검색 및 해석을 추진합니다.

다양한 역할에 적용 가능성

상태 모델링은 작업 함수 또는 워크로드의 동일한 컨텍스트 내의 역할에 관련된 정보를 제공할 수 있습니다. 예를 들어 DevOps 역할에는 운영 상태 정보가 필요할 수 있습니다. 보안 책임자는 침입 신호 및 보안 노출에 대해 더 우려할 수 있습니다. 데이터베이스 관리자는 데이터베이스 리소스를 통해 애플리케이션 모델의 하위 집합에만 관심이 있습니다.

다양한 관련자를 위한 상태 인사이트를 조정합니다. 겹치는 데이터 집합에서 별도의 모델을 만드는 것이 좋습니다.

지속적인 유효성 검사

상태 모델을 사용하여 부하 테스트 및 비정상 상황 테스트와 같은 테스트 및 유효성 검사 프로세스를 최적화합니다. 테스트 중에 런타임 작동 상태를 확인하고 성능 모델을 엔지니어링 수명 주기에 통합하여 규모 및 실패 시나리오에서 모델의 효과를 평가할 수 있습니다.

조직 상태

상태 모델링은 일반적으로 개별 애플리케이션에 대한 상태 정량화와 관련이 있지만 해당 적용 가능성은 해당 scope 넘어 확장됩니다.

개별 워크로드 수준에서 상태 모델은 애플리케이션 가시성 및 운영 인사이트를 위한 토대를 제공합니다. 각 애플리케이션에는 컨텍스트 내에서 각 상태의 의미를 캡처하는 자체 상태 모델이 있을 수 있습니다.

모델 모델을 빌드하여 여러 상태 모델을 상위 수준 구문으로 결합할 수 있습니다. 예를 들어 더 큰 모델 내에서 상태 모델을 구성 요소로 사용하여 사업부 또는 전체 클라우드 자산의 가시성 공간을 구축할 수 있습니다. 상태 모델은 최상위 그래프 내의 노드로 자산 내의 워크로드를 나타냅니다. 이 모델의 관계를 사용하여 데이터 흐름, 서비스 상호 작용 및 공유 인프라를 비롯한 애플리케이션 간 종속성을 캡처합니다.

전자 상거래, 결제 및 주문 처리에 대한 다양한 애플리케이션이 있는 소매 회사를 고려합니다. 이러한 각 애플리케이션을 독립적인 상태 모델로 정의하여 해당 워크로드에 대한 상태의 의미를 정량화할 수 있습니다. 그런 다음 부모 모델을 사용하여 이러한 모든 구성 요소 상태 모델을 엔터티로 매핑하고 종속성 체인을 통해 애플리케이션 간 운영 영향을 캡처할 수 있습니다. 예를 들어 전자 상거래 애플리케이션이 비정상 상태가 되면 결제 애플리케이션에 연속적인 영향을 줍니다.

상태 모델링은 특정 비즈니스 컨텍스트에 맞게 조정된 정량화된 운영 기준을 제공합니다. AIOps(IT 운영용 AI)는 운영 효율성을 향상시키는 데 널리 사용되는 방법입니다. 상태 데이터는 기계 학습 모델이 상태 추세를 분석하기 위한 기본 입력입니다. 예를 들어 기계 학습 모델은 다음을 수행할 수 있습니다.

  • 상태 변경 내용에서 더 많은 인사이트를 추출하고 작업을 권장합니다.

  • 시간 경과에 따른 상태 추세를 분석하여 문제 예측 및 모델 구체화를 추진합니다.

상태 모델 유지 관리

히스 모델을 유지 관리하는 것은 애플리케이션의 개발 및 운영에 부합하는 지속적인 엔지니어링 작업입니다. 애플리케이션이 발전함에 따라 상태 모델이 병렬로 진화하는지 확인합니다.

또한 개발 수명 주기에 통합해야 하는 워크로드 아티팩트 같은 상태 모델을 처리합니다. 상태 모델의 일관된 버전 제어 관리를 위해 IaC(Infrastructure as Code)를 채택합니다. 워크로드에서 인프라 및 애플리케이션 구성 요소를 추가하거나 제거할 때 모델이 최신 상태로 유지되도록 자동화를 사용합니다.

상태 데이터는 시간이 지남에 따라 점차 가치가 감소합니다. 운영 효율성을 최적화하고 비용을 최소화하려면 30일 이상 상태 데이터를 유지하지 않도록 합니다. 필요한 경우 감사 요구 사항을 충족하거나 IT 운영용 AI의 장기 패턴 분석을 포함하는 시나리오에서 데이터를 보관할 수 있습니다.

참고

상태 데이터를 보관할 때 모델의 구성 상태와 결합해야 합니다. 이 컨텍스트가 없으면 상태 변경 내용을 해석하는 것이 어려울 수 있습니다.

다음 단계

신뢰할 수 있는 모니터링 및 경고 전략을 설계하기 위한 권장 사항