워크로드 안정성을 모니터링하기 위한 아키텍처 전략

Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

안정성 모니터링은 복원력 및 복구 가능성과 관련하여 시스템이 시간이 지남에 따라 비즈니스 요구 사항을 얼마나 잘 충족하는지 측정하는 방법입니다. 잘 설계된 모니터링 시스템은 플랫폼, 인프라 및 워크로드 계층 간에 가시성을 설정하여 시스템 동작의 실시간 보기 및 추세를 제공합니다.

이러한 신호를 구성 요소 간에 그리고 시간이 지남에 따라 상호 연결하여 모니터링을 통해 인시던트 및 중단을 빠르고 자신 있게 분석할 수 있습니다. 인사이트가 의미 있고, 경고가 올바른 작업을 유도하고, 학습이 아키텍처 및 작업에 다시 공급되도록 구조화된 접근 방식을 만듭니다.

이 문서의 주요 전략은 모니터링 시스템을 설계하기 위한 OE:07 아키텍처 전략에 설명된 관찰 가능성의 기본 운영 사례를 기반으로 합니다. 모니터링 사례 구현에 대한 지침은 모니터링 디자인 가이드에서 확인할 수 있습니다. 먼저 해당 리소스를 검토하는 것이 좋습니다.

정의

워크로드 기능 모니터링

시스템에서 실제로 제공하는 것을 모니터링합니다. 먼저 중요한 워크플로가 성공적으로 완료되었는지 여부를 추적하고 유효한 결과를 생성합니다. 시스템이 올바르지 않거나 불완전한 출력을 생성하는 동안 정상으로 나타날 수 있으므로 실행만으로는 충분하지 않습니다.

예를 들어 워크로드가 6시간마다 보고서를 생성하는 경우 모니터링은 작업이 예약된 대로 실행되고 예상 콘텐츠 및 크기가 있는 비어있지 않은 보고서와 같은 유효한 결과를 생성했음을 확인해야 합니다. 이러한 종류의 유효성 검사는 시스템이 실행 중일 뿐만 아니라 시스템이 설계한 기능을 제공하는 데에도 도움이 됩니다.

사용자 환경 모니터링

비즈니스 및 사용자 관점에서 안정성을 모니터링합니다. FMA(오류 모드 분석)의 일부로 주요 사용자 흐름을 이미 식별했어야 합니다. 각 흐름에 대해 구성 요소 또는 종속성의 실패가 사용자 환경에 미치는 영향과 예상되는 결과를 추적합니다. 예를 들어 전자 상거래 체크 아웃 흐름에서 결제 또는 인벤토리 시스템의 서비스 중단 또는 오버로드로 인해 고객이 구매를 완료하지 못할 수 있습니다.

안정성은 서비스 품질도 반영합니다. 체크 아웃 흐름에서 사용자는 중단 없이 종단 간 구매를 완료할 수 있어야 합니다. p50, p95 및 p99와 같은 백분위수 기반 대기 시간 메트릭을 사용하여 성능 문제가 가장 먼저 발생하는 비상 대기 시간에 특히 주의하여 실제 사용자 환경을 이해합니다.

가용성 대상 추적

시스템이 가용성, 처리량 및 응답 시간에 대해 정의된 대상을 얼마나 잘 충족하는지 추적합니다. 이러한 대상은 종종 SLA(서비스 수준 계약) 및 SLO(서비스 수준 목표)로 공식화되며 사용자와 함께 설정한 기대치를 반영합니다. 이에 대한 모니터링은 안정성을 실제 비즈니스 결과와 일치하게 유지합니다. 자세한 내용은 안정성 목표 및서비스 수준 계약을 참조하세요.

이러한 대상에 기여하는 주요 지표에 집중하고 시간이 지남에 따라 추적합니다. 무언가가 드리프트할 때 관련된 특정 구성 요소 또는 하위 시스템을 자세히 분석할 수 있어야 합니다. 중복 또는 장애 조치(failover)로 마스킹된 문제를 포함하여 모든 관련 신호를 캡처하고, 실제로 어떤 일이 발생했는지 이해하여 동일한 문제가 반복되지 않도록 할 수 있습니다.

실시간 인식을 기록 컨텍스트와 결합합니다. 실시간 신호는 대상이 위험에 처할 때 신속하게 대응하는 데 도움이 되며, 시간에 따른 추세는 패턴 및 되풀이 문제를 표시합니다. 또한 대상 누락의 원인을 분류하고 이러한 메트릭을 집계하면 명확한 SLA 보고를 지원하고 지속적인 개선을 안내할 수 있습니다.

공급업체 및 플랫폼 서비스(Microsoft 및 기타)에서 제공하는 주요 SLA를 모니터링합니다. 다음을 수행하라.

• 잠재적 SLA 위반의 지표를 실시간으로 추적
• 위반이 발생하는 경우 SLA 클레임을 지원하는 데 필요한 증거 캡처 및 보존

복구 가능성 목표 추적

모든 테스트 및 실제 인시던트를 측정 가능한 이벤트로 처리하여 복구 가능성을 추적합니다. 모니터링 데이터를 사용하여 시스템 및 팀이 실제 조건에서 정의된 복구 목표를 충족할 수 있는지 확인합니다.

RPO(데이터 손실 노출)와 함께 RTO(감지, 응답 및 복구 시간)와 같은 키 신호를 측정합니다. 장애 조치(failover) 준비 및 용량, 장애 조치(failover) 성공률 및 실행 시간, 백업 및 복원 성공, 복제 지연, 수동 개입의 양과 같은 지표를 포함합니다.

이러한 메트릭은 또한 복구 성능에 영향을 줄 수 있는 불분명한 절차, 의사 결정 지연 또는 액세스하기 어려운 설명서와 같은 운영 격차를 강조합니다. 이러한 인사이트를 사용하여 시스템 설계 및 인시던트 대응 사례를 모두 강화합니다.

상태 모델을 사용하여 경고를 실행 가능하게 만들기

경고를 설계하여 조치할 가치가 있는 항목을 명확히 지적하고, 정상, 성능 저하, 비정상 상태와 같은 간단한 상태를 사용하여 시스템의 상태를 나타내는 건강 모델을 기반으로 합니다.

개별 구성 요소에서 전체 시스템에 이르기까지 상태 모델을 계층적으로 구성하여 문제를 해당 원본으로 신속하게 추적할 수 있습니다. SLO(서비스 수준 목표)를 사용하여 임계값을 정의하고 메트릭, 로그, 추적 및 가상 검사와 같은 신호를 결합하여 시스템 상태에 대한 신뢰할 수 있는 그림을 만듭니다. 이를 통해 운영자는 원시 데이터를 파고 들지 않고 작동되는 작업, 작동하지 않는 작업 및 작동 위치를 명확하게 볼 수 있습니다. 자세한 내용은 상태 모델링에 대한 디자인 가이드를 참조하세요.

엔드 투 엔드 환경 및 중요한 트랜잭션에 집중하여 실제 조건에 대한 경고를 조정하여 실제 사용자 영향을 반영합니다. 일시적인 변동을 고려하고 격리된 블립 또는 스파이크가 아닌 의미 있는 상태 변경을 트리거하여 노이즈를 줄입니다. 실시간 경고를 추세 인사이트와 결합하여 즉각적인 문제와 점진적인 저하를 모두 파악하여 팀이 신속하게 대응하고 집중할 수 있도록 지원합니다.

위험: 상태 모델링을 위해서는 시스템 전체에서 의미 있는 신호를 수집해야 합니다. CPU 또는 메모리와 같은 간단한 메트릭에만 의존하면 실제로 중요한 것을 놓칠 수 있습니다. 전체 보기를 얻으려면 사용자 환경 데이터 및 가상 검사를 포함합니다. "정상"을 정의하려면 맞춤이 필요하며, 제대로 조정되지 않은 임계값은 노이즈를 생성하고 효율성을 줄일 수 있습니다.

시스템의 모든 계층 모니터링

시스템, 애플리케이션, 데이터/스토리지 및 네트워크의 각 계층을 모니터링하여 안정성 신호의 전체 보기를 유지합니다.

애플리케이션 계층에서 로그, 메트릭 및 상태 프로브를 사용하여 성공, 실패 및 대기 시간을 추적합니다. 상관 관계 ID를 사용하여 서비스 전반의 요청을 따르고 문제 해결을 더 쉽게 수행할 수 있습니다. 요청 성능에 영향을 주지 않도록 로그를 비동기적으로 수집하고 명확하게 하기 위해 진단 및 감사 로그를 별도로 유지합니다. 가상 트랜잭션 및 엔드포인트 프로브를 추가하여 고객이 실제로 경험하는 것을 확인합니다.

절충. 비동기 로깅과 동기 로깅 중에서 선택하는 것은 원격 분석의 성능과 안정성 간의 균형을 맞추는 것을 포함합니다.

• 비동기 로깅은 로깅을 중요한 경로에서 벗어나게 하여 지연 시간을 줄이고 시스템 성능을 향상합니다. 그러나 특히 로그가 플러시되거나 지속되기 전에 오류가 발생하는 경우 원격 분석 손실의 위험이 발생합니다.

• 동기 로깅을 통해 처리가 계속되기 전에 로그가 기록되어 데이터 내구성과 감사 효율성이 향상됩니다. 단점은 대기 시간이 증가하고 애플리케이션 성능과 로깅 시스템 간의 결합이 더 엄격합니다.

대부분의 시나리오에서 비동기 로깅은 성능에 미치는 영향을 최소화하기 때문에 선호되는 방법입니다. 그러나 엄격하게 규제되거나 감사에 민감한 환경에서는 중요한 이벤트가 안정적으로 캡처되도록 하기 위해 동기 로깅이 필요할 수 있습니다.

데이터 및 스토리지 계층에서 가용성, 쓰기 성공률, 쿼리 대기 시간, 시간 제한, 잠금 및 리소스 압력에 초점을 맞춥니다. 시간이 지남에 따라 추세를 확인하여 증가하는 병목 상태를 식별하고 수명이 짧은 문제와 지속적인 저하를 구분합니다.

네트워크 계층에서 연결, 대기 시간, 패킷 손실, 대역폭 및 트래픽 패턴을 모니터링합니다. 흐름 로그, 엔드포인트 검사 및 가상 테스트를 결합하여 라우팅 문제, 변칙 또는 보안 관련 동작을 표시합니다. 이러한 신호를 애플리케이션 및 플랫폼 데이터에 다시 연결하여 문제가 발생하는 위치를 파악합니다.

운영 로그는 문제를 진단하고, 성능을 추적하고, 시스템 동작을 이해하는 데 도움이 됩니다. 일반적으로 더 강력한 추적성이 필요한 비즈니스 이벤트, 감사 또는 규제 보고를 위한 진실의 원천으로 사용할 수 있도록 설계되지 않았습니다.

각 계층에 대해 자세히 모니터링할 항목은 모니터링 디자인 가이드에서 다룹니다.

스탬프 용량 정의 및 모니터링

각 배포 단위 또는 스탬프에 대한 명확한 용량 제한을 정의하고 자세히 모니터링합니다. 모든 스탬프는 최대 동시 사용자, 처리량 또는 리소스 사용률 임계값에 관계없이 한정된 한도 내에서 작동합니다. 따라서 이러한 제한을 명시적으로 설정하면 의사 결정을 위한 신뢰할 수 있는 기준이 됩니다.

이 가시성은 스탬프가 안정성에 영향을 미치기 전에 채도에 가까워지는 시기를 식별하는 데 도움이 됩니다. 또한 새 스탬프 추가 또는 부하 재배포와 같은 시기 적절하게 스케일 아웃 결정을 지원하고, 디자인에 따라 트래픽이 흐르고 있는지 확인합니다.

이러한 제한을 정의하는 것이 항상 간단하지는 않습니다. 용량은 특히 크기 조정 특성이 다른 여러 기본 서비스에 따라 달라지는 경우 측정하기 어려울 수 있습니다. Microsoft Azure의 할당량 및 제한과 같은 플랫폼 지침을 시작점으로 사용해야 합니다. 실제로 용량은 정확한 선행 모델링이 아닌 부하 테스트, 관찰 및 반복 튜닝을 통해 결정되는 경우가 많습니다.

중복 인스턴스 간 부하 분산 모니터링

여러 지역 또는 영역에 인스턴스를 배포하는 경우를 포함하여 여러 중복 인스턴스에서 워크로드를 실행하는 경우 트래픽 및 리소스 사용량은 해당 인스턴스 간에 균형을 유지해야 합니다.

종종 라우팅 문제, 구성 문제 또는 종속성 제약 조건을 가리키는 불균형을 발견하려고 합니다. 또한 장애 조치(failover) 대상이 필요할 때 트래픽을 흡수할 수 있는 충분한 용량을 확보하고 안정적인 상태 작업 및 실패 시나리오 모두에서 중복 메커니즘이 예상대로 작동하는지 확인합니다.

오류 모드 검색

FMA(오류 모드 분석) 연습의 일부로 잠재적인 실패 지점을 식별해야 합니다.

안정성 모니터링 사례에서 해당 점에 대한 지속적인 감시를 유지합니다. 먼저 일시적인 오류와 같은 더 간단한 신호에 초점을 맞춥니다. 재시도 동작 및 일시적인 오류 비율을 모니터링하여 종속성 및 기본 서비스가 실제 운영 조건에서 어떻게 작동하는지 이해합니다. 이러한 신호는 새로운 불안정에 대한 초기 보기를 제공합니다. 다시 시도 패턴이 예상된 표준에서 벗어나는 경우를 인식하고, 시스템이 부하 상태에서 정상 상태를 유지하는지 여부를 파악하고, 사용자 환경에 영향을 주기 전에 종속성 또는 외부 서비스가 저하되기 시작하는 시기를 식별하는 데 도움이 됩니다.

또한 전체 Azure 지역을 오프라인으로 전환할 수 있는 인프라, 서비스 중단 또는 지역 중단의 하위 집합에 영향을 주는 가용성 영역 중단과 같은 더 큰 영향 오류도 포함됩니다. DDoS 또는 기타 악의적인 활동, 구성 요소 구성 오류 및 성능 문제와 같은 보안 시나리오도 각 시나리오가 솔루션의 전반적인 안정성에 영향을 줄 수 있으므로 주의해야 합니다.

FMA에 대한 자세한 내용은 실패 모드 분석을 위한 아키텍처 전략을 참조하세요.

플랫폼 안정성 상태에 대한 정보 제공

안정성을 효과적으로 관리하려면 플랫폼 상태에 대한 명확한 인사이트가 필요합니다. 이러한 인식을 통해 워크로드 또는 기본 클라우드 플랫폼에서 문제가 발생하는지 여부를 신속하게 확인할 수 있습니다.

Azure Service Health는 Azure 상태에 대한 가시성을 제공합니다. 플랫폼 조건이 변경될 때 알림을 받을 수 있도록 Service Health에서 경고를 구성합니다. 리소스에 영향을 주는 활성 중단, 중단을 발생시킬 수 있는 계획된 유지 관리 이벤트 및 지역 또는 서비스별 성능 저하에 대한 업데이트를 받습니다.

Azure 지원

• 다음을 포함하여 클라우드 플랫폼 모니터링 및 경고 서비스를 통합합니다.

  • Azure Service Health와 같은 플랫폼 수준 상태입니다.

  • Azure Resource Health와 같은 리소스 수준 상태입니다.

• Azure Monitor 는 클라우드 및 온-프레미스 환경에서 모니터링 데이터를 수집, 분석 및 응답하는 데 사용되는 포괄적인 모니터링 솔루션입니다.

• Log Analytics는 Log Analytics 작업 영역의 데이터에 대한 로그 쿼리를 편집하고 실행하는 데 사용되는 Azure Portal의 도구입니다.

• Application Insights 는 Azure Monitor의 확장입니다. APM(애플리케이션 성능 모니터링) 기능을 제공합니다.

• Azure Monitor 인사이트는 가상 머신, 애플리케이션 서비스 및 컨테이너와 같은 Azure 서비스를 모니터링하는 데 도움이 되는 고급 분석 도구입니다. 인사이트는 Azure Monitor 및 Log Analytics를 기반으로 합니다.

• SAP 솔루션을 위한 Azure Monitor는 Azure에서 실행되는 SAP 환경을 위한 Azure 네이티브 모니터링 제품입니다.

• 연결 모니터 는 Azure 리소스에서 네트워크 연결 및 성능을 지속적으로 추적하기 위한 도구입니다. 가상 테스트를 실행하고 실시간 경고 및 진단을 제공하여 오류를 조기에 검색합니다. 사용자 지정 통합 문서를 빌드하여 연결 상태 및 집계된 성능 메트릭을 시각화할 수 있습니다.

• 네트워크 트래픽을 모니터링하기 위해 워크로드에서 가상 네트워크 흐름 로그를 사용하도록 설정할 수 있습니다. 트래픽 분석을 사용하여 이러한 흐름 로그를 분석하고 보강하여 차단된 트래픽, 악의적인 흐름 및 인터넷에 노출된 활성 포트와 같은 인사이트를 표시할 수 있습니다. 통합 문서를 만들면 팀이 라이브 트래픽 동작을 모니터링하고 경고를 받을 수 있습니다. 타임라인 보기 및 토폴로지 시각화를 사용하여 성능 저하 또는 보안 위협을 나타낼 수 있는 트래픽 패턴을 쉽게 모니터링할 수 있습니다.

• 여러 작업 영역 모범 사례는 Log Analytics 작업 영역 아키텍처 디자인을 참조 하세요.

Example

실제 모니터링 솔루션의 예는 Azure의 웹 애플리케이션 모니터링 및 Azure Kubernetes Service 클러스터에 대한 기준 아키텍처를 참조하세요.

커뮤니티 링크

• AMBA(Azure Monitor 기준 경고) 는 고객과 파트너가 Azure Monitor 채택을 통해 관찰 환경을 개선하는 데 사용할 수 있는 경고 정의의 중앙 리포지토리입니다.

안정성 검사 목록

전체 권장 사항 세트를 참조하세요.