Project Flash - Azure Resource Health를 사용하여 Azure Virtual Machine 가용성 모니터링

아티클
08/24/2024

Azure Resource Health는 Flash에서 제공하는 하나의 솔루션입니다. Flash는 고객이 VM(가상 머신) 상태를 모니터링할 수 있는 강력하고 안정적이며 신속한 메커니즘을 구축하는 데 전념하는 프로젝트의 내부 이름입니다.

이 문서에서는 Azure Resource Health를 사용하여 Azure Virtual Machine 가용성을 모니터링하는 방법을 설명합니다. Flash 솔루션에 대한 일반적인 개요는 Flash 개요를 참조하세요.

Flash에서 제공하는 다른 솔루션과 관련된 문서를 보려면 다음 문서 중에서 선택하세요.

Azure Resource Health

포털을 통해 개별 리소스의 상태를 즉각적이고 사용자에게 친숙한 방법으로 검사할 수 있습니다. 고객이 포털에서 리소스 상태 블레이드에 빠르게 액세스할 수 있을 뿐 아니라 30일간의 상태 검사 기록을 검토하여 쉽고 빠르게 문제 해결할 수 있는 훌륭한 도구입니다. 기존 Azure Resource Health는 Azure 리소스에 영향을 미치는 서비스 문제를 진단하고 지원을 받을 수 있는 기능입니다. 리소스의 현재 및 과거 상태를 보고하고, 각 리소스를 사용할 수 없었던 시간 범위를 표시합니다.

그러나 우리는 고객과 파트너가 기술 문제의 근본 원인을 이해하고 문제에 대한 정보를 받을 수 있는(모니터링 프로세스에 제공하고, 다른 관련자에게 문제를 설명하고, 궁극적으로 비즈니스 의사 결정을 알리기 위해) 방법을 개선하는 데 관심이 있다는 것을 알고 있습니다.

Azure Resource Health에서 VM 문제의 근본 원인

최근에 저희는 VM 오류에 대해 고객과 공유하는 정보를 향상하고 문제를 야기한 근본 원인에 대한 추가 컨텍스트를 제공하도록 리소스 상태 환경을 개선했습니다. 이제 고객은 VM의 가용성에 영향이 있을 때 빠르게 알림을 받을 수 있을 뿐 아니라 나중에 자동 RCA(근본 원인 분석) 시스템이 VM 오류로 이어진 장애 Azure 플랫폼 구성 요소를 파악하면 근본 원인이 추가될 것으로 기대할 수 있습니다. 예제를 통해 이 작업이 실제로 어떻게 진행되는지 살펴보겠습니다.

T1 시간에 네트워킹 문제로 인해 서버 랙이 오프라인 상태가 되어 랙의 VM이 연결이 끊깁니다. 네트워크 아키텍처와 관련된 최근의 안정성 개선 사항은 향후 안정성 향상 블로그 게시물을 통해 공유될 예정입니다. 이 공간을 주목하세요!

T2 시간에 Azure의 내부 모니터링 기능은 랙의 VM에 연결할 수 없다는 것을 인지하고 영향을 받는 VM을 새 랙에 다시 배포하여 문제 완화를 시작합니다. 이 시간 동안 VM이 현재 영향을 받고 있으며 사용할 수 없다고 고객에게 알리는 주석이 리소스 상태에 전송됩니다.

T3 시간에 Top-of-Rack 스위치의 플랫폼 원격 분석, 호스트 머신 및 내부 모니터링 시스템이 RCA 엔진에서 상호 연결되어 오류의 근본 원인을 찾습니다. 계산이 끝나면 고객이 향후 영향 가능성을 최소화하기 위해 구현할 수 있는 관련 아키텍처 복원력 권장 사항과 함께 RCA가 리소스 상태에 다시 게시됩니다.

초기 가동 중지 시간 알림 기능은 나온 지 몇 년 된 기능인 반면 근본 원인 설명 게시는 새로 추가된 기능입니다. 이번에는 이러한 근본 원인을 찾는 방법에 대해 자세히 알아보겠습니다.

근본 원인 분석 엔진

이전 예제를 자세히 살펴보고 RCA 엔진의 작동 방식과 바탕이 되는 기술에 대해 자세히 알아보겠습니다. VM용 RCA 엔진의 핵심은 대용량 로그 원격 분석에 최적화된 빅 데이터 서비스인 ADX(Azure Data Explorer)입니다. Azure Data Explorer를 사용하면 Azure 플랫폼을 구성하는 디바이스 및 서비스의 수테라바이트에 달하는 로그 원격 분석 데이터를 쉽게 구문 분석하고, 함께 조인하고, 상관 관계 정보 스트림을 해석하여 다양한 오류 시나리오의 근본 원인을 파악할 수 있습니다. 마지막은 다단계 데이터 엔지니어링 프로세스입니다.

1단계: 가동 중지 시간 감지

근본 원인 분석의 첫 번째 단계는 분석이 실행되는 트리거를 정의하는 것입니다. Virtual Machines의 경우 VM이 예기치 않게 다시 부팅할 때마다 근본 원인을 확인해야 하므로, 트리거는 가동 상태에서 가동 중지 상태로 전환되는 VM입니다. 대부분은 플랫폼 원격 분석 데이터에서 이러한 전환을 간단하게 식별할 수 있지만, 디바이스 오류 또는 정전으로 인해 플랫폼 원격 분석 데이터가 손실될 수 있는 종류의 인프라 오류에서는 좀 더 복잡합니다. 이러한 종류의 오류를 처리하려면 VM 가용성 전환을 암시할 수 있는 데이터 손실 추적 기능과 같은 다른 기술이 필요합니다. Azure Data Explorer는 이 시계열 분석에서 뛰어난 성능을 발휘하며, 이 프로세스과 관련된 기술에 대한 자세한 내용은 Microsoft 기술 커뮤니티: Azure Data Explorer에서 Window 함수 및 시계열 함수를 사용하여 가동 중지 시간을 계산하는 방법에서 찾을 수 있습니다.

2단계: 상관 관계 분석

트리거 이벤트(이 문서에서는 VM이 비정상 상태로 전환)를 정의한 후에는 상관 관계를 분석해야 합니다. 이 단계에서는 트리거 이벤트의 존재를 사용하여 다음과 같이 Azure 플랫폼의 여러 지점에서 원격 분석의 상관 관계를 지정합니다.

Azure 호스트: VM을 호스팅하는 실제 블레이드입니다.
TOR: Top-of-Rack 네트워크 스위치입니다.
Azure Storage: Azure Virtual Machines용 Virtual Disks를 호스트하는 서비스입니다.

각 시스템에는 자체적인 원격 분석 피드가 있으며 이러한 피드를 구문 분석하고 VM 가동 중지 시간 트리거 이벤트와 상관 관계를 지정해야 합니다. 이 프로세스는 VM의 종속성 그래프와 VM 오류를 일으킬 수 있는 기본 시스템을 이해한 다음, 이 모든 종속 시스템의 상태 원격 분석 데이터를 조인하고 VM이 전환된 시간과 가까운 시간에 발생한 이벤트를 필터링하는 방식으로 수행됩니다. Azure Data Explorer의 직관적이고 강력한 쿼리 언어는 임시 원격 분석 스트림의 상관 관계를 지정하는 시간 범위 조인과 같이 문서화된 패턴을 제공하여 도움을 줍니다. 이 상관 관계 프로세스가 끝나면 VM 오류의 원인일 수 있는 또는 원인을 파악하는 데 유용한 정보를 제공할 수 있는 모든 종속 시스템의 상관 관계가 지정된 플랫폼 원격 분석 데이터를 사용하여 VM 가동 중지 시간 전환을 나타내는 데이터 세트를 얻게 됩니다.

3단계: 근본 원인 분류

이 프로세스의 다음 단계는 분류입니다. 모든 관련 데이터를 단일 데이터 세트에 수집했으므로, 이제 분석 규칙을 적용하여 정보를 해석하고 고객 입장의 근본 원인 설명으로 변환합니다. 이 문서에서 예로 든 TOR 오류 예제로 돌아가서, 상관 관계 분석이 끝나면 해석이 필요한 흥미로운 정보가 많이 발견됩니다. 예를 들어 Azure 호스트를 모니터링하는 시스템의 로그에 이 시간 동안 호스트 연결이 끊어졌다는 정보가 있을 수 있습니다. 가상 디스크 연결 문제가 있다는 신호나 TOR 디바이스의 명시적 오류 신호가 있을 수도 있습니다. 이제 이 모든 정보가 검사되고, 명시적 TOR 오류 신호는 오류의 근본 원인으로써 다른 신호보다 높은 우선 순위가 지정됩니다. 이 우선 순위 지정 프로세스와 이 프로세스의 기반이 되는 규칙은 도메인 전문가를 통해 수립되며, Azure 플랫폼이 발전하면 그에 맞게 수정됩니다. 기계 학습 및 이상 탐지 메커니즘은 이처럼 분류된 근본 원인을 기반으로 하며, 이러한 분류 규칙을 개선하고 이러한 오류 비율의 패턴 변화를 감지하여 다시 안전한 배포 파이프라인에 제공할 수 있는 기회를 식별합니다.

4단계: RCA 게시

마지막 단계는 고객이 볼 수 있는 Azure Resource Health에 근본 원인을 게시하는 것입니다. 게시는 Azure Data Explorer에서 처리된 근본 원인 데이터를 주기적으로 쿼리하여 결과를 리소스 상태 백 엔드로 내보내는 간단한 Azure Functions 애플리케이션을 통해 수행됩니다. 정보 스트림이 들어올 때 다양한 데이터가 지연될 수 있으므로, 이 프로세스에서는 원래 게시된 근본 원인보다 구체적인 근본 원인으로 연결되는 더 좋은 정보 소스가 있으면 이를 반영하도록 RCA가 업데이트될 수 있습니다.

앞으로 이동

문제의 근본 원인을 파악하고 고객과 파트너에게 전달하는 것은 단지 시작일 뿐입니다. 고객이 이러한 RCA를 받아서 그들의 고객 및 동료와 공유해야 할 수도 있습니다. 리소스 RCA를 보다 쉽게 식별, 추적 및 공유할 수 있도록 기능을 더욱 강화하려고 합니다. 그러기 위해 사용자에게 표시할 수 있는 고유한 리소스별 및 가동 중지 시간별 추적 ID를 생성하도록 백 엔드 변경 작업을 진행하고 있습니다. 이 작업이 완료되면 가동 중지 시간을 해당 RCA와 쉽게 매칭할 수 있습니다. 또한 RCA를 이메일로 더 쉽게 보내고 결국에는 VM에 대한 RCA를 구독할 수 있도록 새 기능을 개발하고 있습니다. 이 기능이 개발되면 사용 불가 이벤트가 발생한 후 받은 편지함에서 직접 RCA에 등록할 수 있으며 고객 측에서 추가 작업을 할 필요가 없습니다.

다음 단계

제공되는 솔루션에 대해 자세히 알아보려면 해당 솔루션 문서를 계속 진행합니다.

Azure Virtual Machines를 모니터링하는 방법에 대한 일반적인 개요는 Azure 가상 머신 모니터링 및 Azure 가상 머신 모니터링 참조를 확인하세요.

다음을 통해 공유