클라우드 모니터링 및 대응

  • 아티클

이 문서는 클라우드 모니터링 가이드의 시리즈의 일부입니다.

대응은 모니터링의 데이터 기반 결정에 따라 서비스 소비자가 다음을 수행하도록 하는 하나 이상의 조치를 정의한 결과입니다.

  • 실행 가능하도록 설정: 잘 조정된 모니터링 구성을 사용하여 실행 가능한 신호를 만듭니다.
  • 지속적인 모니터링: 문제 진단에 도움이 되도록 인시던트 및 문제 해결 활동 전반에 걸쳐 모니터링을 적용합니다.
  • 자동화: 식별된 신호에 따라 자동 조사, 진단, 해결, 복구 및 수정을 구성합니다.

중요 원칙 은 여기에 적용됩니다. 이를 통해 경고, 알림 및 보고서 다이제스트를 조정하고 최적화하는 작업을 위한 프로세스 흐름 또는 정책에 도움이 됩니다. 클라우드 모니터링은 잘못된 것을 인간에게 알리는 것 이상입니다. 또한 시스템 및 서비스에 대응하는 신호를 제공하는 것에 대해서도 설명합니다.

모니터링은 다양한 시나리오에서 중요한 역할을 합니다.

  • 동적 서비스 동작 사용: 모니터링 데이터를 기반으로 대응하고 인시던트가 자동으로 제거되도록 시스템 및 서비스를 동적으로 제어합니다.
  • 지속적으로 신호 평가: 동적 프로세스, 규정 준수, 자동 크기 조정 및 시각화에 대한 원격 분석을 지속적으로 알리고 제공합니다.
  • 조직 작업: IT 조직이 변경 작업을 수행하고 관리할 수 있도록 지원합니다.

경고

자동화는 최신 클라우드 환경에서 더 많은 비용이 드는 서비스 관리 프로세스를 대체하여 더 많은 인시던트가 제거됩니다. 경고는 인식에 중요한 역할을 하지만 경고 피로 또는 노이즈를 방지하기 위해 실행 가능해야 합니다.

경고를 정의하면 서비스 및 시스템이 정상적이고 응답성이 뛰어나며 안정적이며 안전하게 기본 수 있도록 사전에 확인할 수 있습니다. 성능 보장, SLO(서비스 수준 목표 ), 가용성 및 개인 정보 보호 유지에는 적절한 경고 전략이 필요합니다. 경고 에스컬레이션은 관찰 가능성에 중요하지 않으며, 오늘날에는 첫 번째 방어선으로 간주해서는 안 됩니다. 대신 자동화는 여기서 중요한 역할을 해야 합니다.

전통적으로 모니터링은 누군가가 행동할 수 있다는 경고를 발생시키는 것을 의미하여 완전히 반응적인 프로세스를 의미했습니다. 이 방법은 최신 서비스 관리 또는 클라우드 운영 사례에 따라 수정해야 합니다. 이 접근 방식은 민첩성, 최소 비용, 최적화 등을 통해 클라우드 효율성의 목표와 일치하지 않는 기존의 ITIL 인시던트 관리 경로를 밀접하게 따릅니다.

최신 접근 방식에는 훨씬 더 유익하고 자동화된 감지된 조건의 빈도가 있을 수 있습니다. 예를 들면 다음과 같습니다.

감지된 조건 기본 조치 최신 조치
  • 성능 메트릭 - 높은 메모리 사용률.
  • 보안 위협 - 의심스러운 네트워크 활동이 감지되었습니다.
  • 가용성 오류 - Azure Blob Storage 요청이 실패합니다.
    		•  경고 및 알림, 웹후크, 푸시 알림, 플레이북, 자동 크기 조정 로그를 쿼리하여 잘못된 구성 요소를 식별하고 자동화를 트리거하여 잘못된 구성 요소의 문제를 해결합니다.

    Azure의 경고 및 자동화 기능에 대한 관련 리소스 목록은 다음과 같습니다.

    최신 클라우드 모니터링

    과거에 제공되었던 모니터링 플랫폼 및 관련 도구와 클라우드 컴퓨팅 제품을 비교하면 다음과 같습니다.

    • 훨씬 더 유연하게 대응 옵션을 고안할 수 있습니다.
    • 자동화된 대응을 더 쉽게 개발하고 사용하도록 설정할 수 있습니다.
    • 클라우드 프로토콜 또는 API 메서드가 DevOps를 비롯한 작업 관리 시스템과 보다 쉽게 통합됩니다.

    조사, 보강, 라우팅, 할당, 수정, 복구 또는 해결을 위한 자동 작업 범위에 대해 다음 모드를 고려합니다.

    오케스트레이션 방법 설명
    완전 자동화됨 조치가 자동으로 수행됩니다. 전체 자동화는 유용성이 단기적이지 않고 안전한 곳에서 안정적이고 효율적이며 내구성이 입증되어야 합니다. 전체 자동화를 통해 리소스를 확보하여 전략적 이니셔티브에 더 집중할 수 있습니다.
    반자동화 모든 수정 조치에 대한 승인이 필요합니다.
    수동 운영자가 큐레이팅된 라이브러리에서 자동화 예제 또는 플레이북을 선택합니다.

    경고는 보안 이벤트, 성능 메트릭, 가용성 정보 및 로그를 기반으로 계측된 데이터에 따라 달라집니다. 데이터 기반 작업은 영향과 수행할 대응 작업을 결정하기 위해 다양한 수집된 데이터 형식을 집계하고 처리하여 모니터링되는 각 리소스의 전체적인 엔드투엔드 관점을 분석한 결과입니다.

    메트릭 경고 및 보안 이벤트를 기반으로 자동화에 대해 자세히 알아보려면 다음 리소스를 사용하여 읽기를 확장합니다.

    비용 효율성

    다른 가시성 원칙과 마찬가지로, 팀은 비용 영향뿐 아니라 최신 인시던트 관리를 지원하기 위해 정의된 대응 유형이 비용을 제어하는 데 어떤 도움이 되는지 이해하고 인식해야 합니다. 가장 중요한 목표는 문제에 신속하게 대응하고 해결하여 MTTR(평균 복구 시간)을 줄이는 것이지만, IT 또는 비즈니스 수익원에 대한 잠재적 비용과 영향을 지속적으로 평가해야 합니다.

    보고된 모든 인시던트에는 비용이 발생합니다. 조직이 대응을 자동화하기 위해 오케스트레이션에 투자한다고 가정합니다. 이 경우 자동화를 사용하도록 설정하는 서비스 또는 기능을 이용하려면 클라우드 서비스에서 소비를 늘려 비용의 이점과 비용의 영향을 평가해야 합니다.

    자동화

    클라우드 자동화는 보안 및 상태 모니터링에 상당한 이점을 제공합니다. 속도, 유연성 및 정밀도는 클라우드 자동화가 대응 작업에 제공하는 세 가지 원형입니다. 이를 오케스트레이션이라고도 하며, Microsoft 클라우드는 여러 서비스를 제공합니다.

    예시:

    1. 하나 이상의 로그에서 ID 기반 위협이 감지되어 경고가 발생합니다.
    2. 자동화는 즉시 트리거되어 더 많은 정보를 수집하고 더 많은 로그의 상관 관계를 지정하여 경고를 보강합니다.
    3. 운영자가 라이브러리에서 올바른 자동화를 선택하여 사용자 계정을 사용하지 않도록 설정하는 등의 조치를 취합니다.

    예제 또는 사용 사례는 완전히 자동화할 수 있습니다.

    그런 다음, 자동화 역할은 비용을 절감하고 시간을 절약하는 일종의 플레이북을 제공합니다.

    • 보안 인시던트는 장기간의 조사, 진단, 해결 및 복구 과정을 거칠 필요가 없었습니다.
    • 검색-수정 주기는 시간 단위가 아닌 초 또는 분 단위일 수 있습니다.

    다음으로, 팀은 공용 웹 사이트의 원료에서 또는 내부적으로 큐레이팅되고 소스 제어 리포지토리에 저장되는 등 유연하게 사용할 수 있는 자동화 예제의 목록 또는 라이브러리를 빌드해야 합니다.

    ID 또는 보안 이벤트를 기반으로 더 많은 자동화를 위해 제안된 읽기 목록은 다음과 같습니다.

    성공적인 경고 전략

    잘못된 부분을 모른다면 고치려고 할 수조차 없습니다.

    중요한 사항에 대한 경고는 필수적입니다. 이는 올바른 지표와 로그를 수집하고 측정함으로써 뒷받침됩니다. 또한 조건이 충족되면 저장, 집계, 시각화, 분석 및 자동화된 응답을 시작할 수 있는 모니터링 도구가 필요합니다. 서비스 및 애플리케이션의 구성을 완전히 이해하는 경우에만 서비스 및 애플리케이션의 가시성을 개선할 수 있습니다. 모니터링 플랫폼에서 적용할 세부 모니터링 구성에 해당 구성을 매핑합니다. 이 구성에는 경고해야 하는 예측 가능한 오류 상태(오류의 원인이 아닌 증상)가 포함됩니다.

    정보 경고

    특정 상황에서 일부 경고는 정보가 될 수 있습니다. 이를 사용하여 시스템이 어떻게 작동하는지 알아볼 수 있습니다. 예를 들어 다음과 같은 정보 경고를 가져올 수 있습니다.

    • VM이 종료되었습니다. VM이 자동으로 종료되어 폐기물을 최소화하고 일정 또는 낮은 사용률 검색에 따라 비용을 제어합니다.

      이 예제에서 오케스트레이션은 네이티브 예약 기능 및 사용률 조건을 검색하는 모니터링 플랫폼에 의해 사용되었습니다. 경고가 알리거나 에스컬레이션하는 데 유일한 조치로 사용되는 대신, 수행된 조치 및 이유를 알려줍니다.

    • 유휴 리소스: IaaS 또는 PaaS 리소스는 장기간 유휴 상태이거나 Azure Advisor 권장 사항에 따라 프로비전되지 않습니다.

      이 예제에서는 오케스트레이션을 사용하여 비즈니스 논리 또는 ITSM 프로세스 워크플로를 기반으로 인프라 관련 활동을 관리할 수 있습니다. 오늘날 훨씬 더 빠른 응답과 조치가 필요합니다. 클라우드 를 사용하는 경우 자동화된 값 스트림의 일부로 자동화된 응답 또는 지속적인 오케스트레이션보다 인간에 대한 경고 가 적습니다.

    경고 전략 고려 사항

    학습이 핵심이며, 올바르게 설계된 경우 정보 경고는 클라우드 에코시스템 및 상태에 대한 많은 인사이트를 제공할 수 있습니다.

    증상이 경고에 적합한지 여부를 결정하기 위해 다음 원칙을 고려합니다.

    • 실행 가능: 문제가 중요합니까? 애플리케이션의 상태에 실제 문제가 반영됩니까? 예를 들어 리소스에 대한 지속적인 기간 동안 CPU 사용률이 너무 높거나 SQL 쿼리가 지속적으로 성능 문제를 일으키는 경우 경고를 보낼 수 있지만 짧은 기간 동안 CPU가 급증할 때 경고를 보내지 않을 수 있습니다. 가양성 을 줄이고 경고 피로를 피하기 위해 조치를 취할 수 있도록 합니다.

    • 긴급: 이 문제에 긴급한 주의가 필요한가요? 그러한 경우 담당 팀에 즉시 알려야 합니다.

    • 고객 영향: 서비스 또는 애플리케이션의 사용자가 문제의 영향을 받나요?

    • 종속 시스템에 미치는 영향: 상호 관련된 종속성에서 발생하는 경고가 서로 다른 팀에게 동일한 문제에 대해 모두 알리지 않도록 상관 관계를 지정할 수 있나요?

    이러한 초기 고려 사항을 사용하여 모니터링 구성 개발을 시작할 수 있습니다. 환경 전체에서 가정을 테스트하고 유효성을 검사할 수 있습니다. 예를 들어 프로덕션 환경뿐만 아니라 비프로덕션 환경에서도 이러한 고려 사항 및 질문을 지속적으로 평가합니다. 지속적인 개선은 신호 모니터링에 대한 성공적인 응답의 핵심입니다.

    작동 중인 작업을 지속적으로 평가할 때 모니터링 응답 효율성에 대한 인식을 높이는 데 도움이 되도록 다음과 같은 질문을 스스로에게 물어보는 것이 좋습니다.

    • 경고 볼륨: 경고 볼륨이 높나요? 피할 수 있었던 실행 불가능한 경고가 많이 있나요?
    • 눈에 띄지 않는 문제: 모니터링 구성에 의해 catch되지 않은 문제가 발생한 사용자로부터 보고서 또는 티켓을 받나요?
    • 가양성: 잘못 플래그가 지정된 경고 또는 신호를 받나요?
    • 경고 또는 이벤트: 실제로 경고를 보내야 합니까, 아니면 발생한 경고 중 일부는 시스템에 플래그가 지정된 이벤트일 수 있나요? 경고 전송과 달리 쿼리할 때 신호가 표시되는 경우 경고 피로 및 실행 불가능한 알림을 방지하는 데 충분할까요?

    Microsoft 모니터링 솔루션 전반의 기능에 대한 자세한 내용은 이 문서 시리즈의 모니터링 플랫폼 개요를 참조하세요.

    다음 단계

    클라우드 모니터링을 위한 기술 준비