Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
본문으로 건너뛰기

AWS Observability 성숙도 모델

소개​

본질적으로 Observability란 시스템의 외부 출력을 분석하여 내부 상태를 이해하고 인사이트를 얻을 수 있는 능력입니다. 이 개념은 사전 정의된 메트릭이나 이벤트에 초점을 맞추던 전통적인 모니터링 접근 방식에서, 환경의 다양한 구성 요소가 생성하는 데이터의 수집, 분석, 시각화를 아우르는 보다 전체적인 접근 방식으로 발전해 왔습니다. 시스템은 관측되지 않으면 제어하거나 최적화할 수 없습니다. 효과적인 Observability 전략을 통해 팀은 문제를 신속하게 식별하고 해결하며, 리소스 사용을 최적화하고, 시스템의 전반적인 상태에 대한 인사이트를 얻을 수 있습니다. Observability는 워크로드의 전반적인 운영 가용성과 상태를 개선할 수 있는 문제를 효율적으로 탐지, 조사, 해결하는 능력을 제공합니다.

왜 Observability가 중요한가

모니터링과 Observability의 차이점은 다음과 같습니다. 모니터링은 시스템이 작동하는지 여부를 알려주는 반면, Observability는 시스템이 왜 작동하지 않는지를 알려줍니다. 모니터링은 일반적으로 사후 대응적 조치인 반면, Observability의 목표는 핵심 성과 지표(KPI)를 사전에 개선할 수 있도록 하는 것입니다. 지속적인 모니터링과 Observability는 민첩성을 높이고, 고객 경험을 개선하며, 클라우드 환경의 위험을 줄여줍니다.

Observability 성숙도 모델​

Observability 성숙도 모델은 워크로드의 Observability와 관리 프로세스를 최적화하려는 조직에게 필수적인 프레임워크입니다. 이 모델은 비즈니스가 현재 역량을 평가하고, 개선 영역을 식별하며, 최적의 Observability를 달성하기 위해 적절한 도구와 프로세스에 전략적으로 투자할 수 있는 포괄적인 로드맵을 제공합니다. 클라우드 컴퓨팅, 마이크로서비스, 일시적이고 분산된 시스템의 시대에 Observability는 디지털 서비스의 안정성과 성능을 보장하는 핵심 요소가 되었습니다. Observability를 개선하기 위한 구조화된 접근 방식을 제공함으로써, 이 모델은 조직이 시스템에 대한 더 깊은 이해와 통제력을 갖출 수 있게 하여, 더 회복력 있고, 효율적이며, 고성능의 비즈니스를 위한 길을 열어줍니다.

Observability 성숙도 모델의 단계​

조직이 워크로드를 확장함에 따라, Observability 성숙도 모델도 함께 성숙해져야 합니다. 그러나 Observability 성숙도로의 경로가 항상 워크로드와 함께 성장하는 것은 아닙니다. 이 모델의 목적은 고객이 조직 역량을 확장하고 성장시킬 때 필요한 성숙도 수준을 달성하도록 돕는 것입니다.

  1. Observability 성숙도 모델의 첫 번째 단계는 일반적으로 조직의 현재 상태에 대한 기준선을 설정하는 것입니다. 여기에는 기존 모니터링 도구와 프로세스를 평가하고, 가시성이나 기능의 격차를 식별하는 것이 포함됩니다. 이 단계에서 조직은 현재 역량을 점검하고, 엔지니어링 사이클의 초기 단계부터 개선을 위한 현실적인 목표를 설정할 수 있습니다.

  2. 다음 단계에서 조직은 고급 Observability 전략과 서비스를 채택하여 보다 정교한 접근 방식으로 이동합니다. 여기에는 사전 예방적 알림, 서로 다른 시스템 간의 상호작용에 대한 인사이트를 얻기 위한 분산 트레이싱 구현이 포함될 수 있으며, 이를 통해 조직은 가시성 향상, 인지 부하 감소, 보다 효율적인 문제 해결의 이점을 누리기 시작합니다.

  3. 비즈니스가 Observability 성숙도 모델의 세 번째 단계를 거치면서, 자동화된 복구, 이상 탐지 및 근본 원인 분석을 자동화하기 위한 인공지능 및 머신러닝 기술 같은 추가적인 기능을 활용할 수 있습니다. 이러한 고급 기능을 통해 조직은 문제를 탐지할 뿐만 아니라 최종 사용자에게 영향을 미치거나 비즈니스 운영을 방해하기 전에 수정 조치를 취할 수 있습니다. Observability 도구를 인시던트 관리 플랫폼 같은 다른 핵심 시스템과 통합함으로써, 조직은 인시던트 대응 프로세스를 간소화하고 문제 해결에 걸리는 시간을 최소화할 수 있습니다.

  4. Observability 성숙도 모델의 마지막 단계는 모니터링 및 Observability 도구가 생성하는 풍부한 데이터를 활용하여 지속적인 개선을 추진하는 것입니다. 여기에는 고급 분석을 사용하여 워크로드 성능의 패턴과 트렌드를 식별하고, 이 정보를 엔지니어링 및 운영 프로세스에 다시 반영하여 리소스 할당, 아키텍처, 배포 전략을 최적화하는 것이 포함됩니다.

Observability 성숙도 모델 단계

1단계: 기반 모니터링 - 텔레메트리 데이터 수집​

최소한의 수준으로 채택되고 사일로화된 상태에서 운영되는 기본 모니터링은 조직 내 시스템 또는 워크로드 전체를 모니터링하기 위해 무엇이 필요한지에 대한 정의된 전략이 없습니다. 대부분의 경우, 애플리케이션 소유자, 네트워크 운영 센터(NOC) 또는 CloudOps/DevOps 팀 같은 서로 다른 팀이 모니터링 요구에 맞는 각기 다른 도구를 사용하므로, 이 접근 방식은 환경 전체에 걸친 디버깅이나 최적화 측면에서 거의 가치가 없습니다.

일반적으로 이 단계의 고객은 워크로드를 모니터링하기 위한 분산된 솔루션을 가지고 있습니다. 다른 팀과의 협력이 없거나 제한적이므로, 대부분의 경우 서로 다른 팀이 같은 데이터를 다른 방식으로 수집합니다. 팀은 자신이 얻은 데이터로 필요한 것을 최적화하는 경향이 있습니다. 또한 다른 팀에서 얻은 데이터는 형식이 다를 수 있어 서로의 데이터를 사용할 수 없습니다. 핵심 워크로드를 식별하고, Observability를 위한 통합 솔루션을 목표로 하며, metrics와 logs를 정의하는 계획을 수립하는 것이 이 수준의 핵심 측면입니다. 필수적인 텔레메트리를 캡처하도록 워크로드를 설계하는 것은 내부 상태와 워크로드 상태를 이해하는 데 필수적입니다.

성숙도 수준 향상을 위한 기반을 구축하려면, metrics, logs, traces 수집을 통한 워크로드 계측과 적절한 모니터링 및 Observability 도구를 사용한 의미 있는 인사이트 확보가 고객이 환경을 제어하고 최적화하는 데 도움이 됩니다. 계측이란 환경에서 워크로드의 동작과 성능을 관측하는 데 사용할 수 있는 핵심 데이터를 측정, 추적, 캡처하는 것을 의미합니다. 예를 들어, 오류, 성공/실패 트랜잭션 같은 애플리케이션 메트릭과 CPU 및 디스크 리소스 사용률 같은 인프라 메트릭이 있습니다.

2단계: 중간 모니터링 - 텔레메트리 분석 및 인사이트​

이 단계에서 고객은 온프레미스와 클라우드 같은 다양한 환경에서 신호를 수집하는 것이 조직적으로 더 명확해집니다. metrics, logs, traces를 워크로드에서 수집하는 메커니즘을 구축했으며, 이것이 Observability의 기반 구조를 형성합니다. 시각화, 알림 전략을 만들었고, 잘 정의된 기준에 따라 문제의 우선순위를 결정하는 능력도 갖추었습니다. 사후 대응적으로 추측하는 대신, 필요한 조치를 호출하는 워크플로우를 갖추었으며 관련 팀이 캡처된 정보와 과거 지식을 기반으로 분석하고 문제를 해결할 수 있습니다. 이 수준의 고객은 전통적이든 현대적이든, 고도로 확장 가능하고, 분산되며, 민첩하고 마이크로서비스 아키텍처인 환경에 대한 Observability 실천을 달성하기 위해 노력합니다.

Observability 기둥

대부분의 경우 모니터링이 잘 작동하는 것처럼 보이지만, 조직은 문제 디버깅에 더 많은 시간을 소비하는 경향이 있으며, 결과적으로 전반적인 평균 해결 시간(MTTR)이 일정하지 않거나 시간이 지남에 따라 의미 있게 개선되지 않습니다. 또한 문제 디버깅에 예상보다 더 높은 인지적 시간과 노력이 필요하여 인시던트 대응이 길어집니다. 운영을 압도하는 데이터 과부하 상황도 발생하는 경향이 있습니다. 대부분의 기업이 다음으로 나아갈 수 있는 곳을 인식하지 못한 채 이 단계에 머무는 것을 발견합니다. 조직을 다음 수준으로 이동시키기 위해 취할 수 있는 구체적인 조치는 다음과 같습니다: 1) 정기적인 간격으로 시스템 아키텍처 설계를 검토하고 영향과 다운타임을 줄이는 정책과 관행을 배포하여 알림을 줄입니다. 2) 실행 가능한 KPI를 정의하고, 알림 결과에 가치 있는 컨텍스트를 추가하며, 심각도/긴급도별로 분류하고, 엔지니어가 문제를 더 빠르게 해결할 수 있도록 다른 도구와 팀에 전송하여 알림 피로를 방지합니다.

이러한 알림을 정기적으로 분석하고 반복되는 일반적인 알림에 대해 자동 복구를 구현합니다. 운영 및 프로세스 개선에 대한 피드백을 제공하기 위해 관련 팀과 알림 결과를 공유하고 소통합니다.

다양한 엔티티를 상호 연관시키고 시스템의 서로 다른 부분 간의 종속성을 이해하는 데 도움이 되는 지식 그래프를 점진적으로 구축하는 계획을 수립합니다. 이를 통해 고객은 시스템 변경의 영향을 시각화하고, 잠재적 문제를 예측하고 완화할 수 있습니다.

3단계: 고급 Observability - 상관관계 분석 및 이상 탐지​

이 단계에서 조직은 문제 해결에 많은 시간을 소비하지 않고도 문제의 근본 원인을 명확하게 이해할 수 있습니다. 문제가 발생하면, 알림이 네트워크 운영 센터(NOC) 또는 CloudOps/DevOps 팀 같은 관련 팀에 충분한 컨텍스트 정보를 제공합니다. 모니터링 팀은 알림을 보고 metrics, logs, traces 같은 신호의 상관관계를 통해 즉시 문제의 근본 원인을 파악할 수 있습니다. Traces는 요청에 대해 애플리케이션에서 수집된 데이터로, 도구를 사용하여 문제와 최적화 기회를 식별하고 확인, 필터링, 인사이트를 얻을 수 있습니다. 애플리케이션의 추적된 요청은 요청과 응답뿐만 아니라, 애플리케이션이 다운스트림 AWS 리소스, 마이크로서비스, 데이터베이스, 웹 API에 대해 수행하는 호출에 대한 상세 정보도 제공합니다. traces가 캡처됨에 따라 해당하는 로그 이벤트를 찾고, 인프라와 애플리케이션의 metrics를 살펴보며 상황에 대한 360도 뷰를 확보할 수 있습니다.

적절한 팀은 문제를 해결하는 수정 사항을 제공하여 즉시 조치를 취할 수 있습니다. 이 시나리오에서 MTTR은 매우 짧고, 서비스 수준 목표(SLO)는 정상이며, 오류 예산 소진율은 허용 가능한 수준입니다. 일반적으로 이 수준의 고객은 현대적이고 민첩하며, 고도로 확장 가능한 마이크로서비스 환경에 대한 Observability 실천을 달성했습니다.

많은 조직이 Observability 환경에서 이 수준의 정교함과 성숙도를 달성했습니다. 이 단계는 이미 조직에게 복잡한 인프라를 지원하고, 높은 가용성으로 시스템을 운영하며, 애플리케이션에 더 높은 서비스 수준 가용성(SLA)을 제공하고, 안정적인 인프라를 제공함으로써 비즈니스 혁신을 달성할 수 있는 능력을 부여합니다. 고객은 또한 일반적인 패턴과 일치하지 않는 이상 및 아웃라이어를 모니터링하는 이상 탐지기를 사용하며, 거의 실시간으로 알림 메커니즘을 갖추고 있습니다.

그러나 이러한 조직의 팀은 항상 가능한 것 이상을 추구합니다. 팀은 반복적인 문제를 이해하고, 향후 발생할 수 있는 문제를 예측하기 위해 시나리오에 대한 모델링에 활용할 수 있는 지식 베이스를 구축하고자 합니다. 이것이 고객이 성숙도 모델의 다음 단계로 이동하여 미지의 것에 대한 인사이트를 얻는 때입니다. 이를 달성하려면 새로운 도구가 필요하며, 데이터를 저장하고 활용하기 위한 새로운 기술과 기법을 식별해야 합니다. IT 운영을 위한 인공지능(AIOps)을 활용하여 과거 수집된 데이터로 훈련된 모델을 기반으로 신호를 자동으로 상관시키고, 근본 원인을 식별하며, 해결 계획을 생성하는 시스템을 만들 수 있습니다.

AIOps를 활용한 Observability

4단계: 사전 예방적 Observability - 자동화된 사전 근본 원인 식별​

여기서 Observability 데이터는 문제가 발생한 "후"에만 사용되는 것이 아니라, 문제가 발생하기 "전"에 실시간으로 데이터를 활용합니다. 잘 훈련된 모델을 사용하여 문제 식별이 사전에 이루어지며, 해결이 더 쉽고 간단하게 달성됩니다. 수집된 신호를 분석하여 모니터링 시스템이 자동으로 문제에 대한 인사이트를 제공하고, 문제를 해결하기 위한 해결 옵션도 제시할 수 있습니다.

Observability 소프트웨어 벤더들은 이 영역으로 역량을 지속적으로 확장하고 있으며, 생성형 AI의 대중화와 함께 이러한 성숙도 수준을 달성하려는 조직이 더 쉽게 목표를 달성할 수 있도록 가속화되었습니다. 이 단계가 성숙되고 형태를 갖추면, 고객은 Observability 서비스가 자동으로 동적 대시보드를 생성할 수 있는 상황을 경험합니다. 대시보드에는 당면한 문제와 관련된 정보만 포함될 수 있습니다. 이는 실제로 중요하지 않은 데이터를 조회하고 시각화하는 시간과 비용을 절약합니다. 생성형 AI(GenAI)와 머신러닝을 수행하기 위한 컴퓨팅이 날로 민주화되면서, 사전 예방적 모니터링 역량이 현재보다 미래에 더 일반화될 것으로 예상됩니다.

다양한 AWS 네이티브 및 오픈소스 솔루션으로 데이터 수집, 데이터 처리, 데이터 인사이트 및 분석을 포함하는 전체적인 그림을 제공하는 Observability 포트폴리오 개요로서, 고객이 엔드투엔드 Observability 요구에 맞는 적절한 솔루션을 선택할 수 있습니다.

AWS Observability 스택

Observability를 위한 AWS Well-Architected 및 Cloud Adoption Framework​

조직은 AWS Well-Architected와 Cloud Adoption Framework를 활용하여 Observability 역량을 강화하고 클라우드 환경을 효과적으로 모니터링하고 문제를 해결할 수 있습니다.

Observability를 위한 AWS Well-Architected 및 Cloud Adoption Framework는 워크로드의 설계, 배포, 운영을 위한 구조화된 접근 방식을 제공하여 모범 사례가 준수되도록 합니다. 이는 가용성, 시스템 성능, 확장성, 안정성의 향상으로 이어집니다. 이러한 프레임워크는 또한 표준화된 실천 방법과 규범적 가이드를 제공하여, 조직 전체에서 협업하고, 지식을 공유하며, 일관된 솔루션을 더 쉽게 구현할 수 있게 합니다.

효과적으로 활용하려면, 조직은 AWS Well-Architected 프레임워크의 핵심 구성 요소인 기둥(운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화, 지속 가능성)을 이해해야 하며, 이는 클라우드 환경 설계 및 운영을 위한 전체적인 접근 방식을 제공합니다. 한편, Cloud Adoption Framework는 비즈니스, 인력, 거버넌스, 플랫폼과 같은 영역에 초점을 맞춘 클라우드 도입을 위한 구조화된 접근 방식을 제공합니다. 이러한 구성 요소를 Observability 요구사항과 일치시킴으로써, 조직은 강력하고 확장 가능한 워크로드를 구축할 수 있습니다.

Observability를 위한 AWS Well-Architected 및 Cloud Adoption Framework 구현에는 몇 가지 단계가 포함됩니다. 첫째, 조직은 현재 상태를 평가하고 개선 영역을 식별해야 합니다. 이는 이러한 프레임워크에 대해 워크로드를 평가하는 Observability 성숙도 모델 평가를 수행하여 달성할 수 있습니다. 검토 결과를 바탕으로 조직은 Observability 이니셔티브의 우선순위를 정하고 계획할 수 있습니다. 여기에는 모니터링 및 로깅 요구사항 정의, 적절한 AWS 서비스 선택, 필요한 인프라와 도구 구현이 포함됩니다. 마지막으로, 조직은 지속적인 효과를 보장하기 위해 Observability 솔루션을 지속적으로 모니터링하고 최적화해야 합니다.

또한 고객은 AWS Well-Architected Framework의 모범 사례를 사용하여 워크로드를 문서화하고 측정할 수 있는 AWS 내 서비스인 AWS Well-Architected Tool을 활용할 수 있습니다. 이 도구는 AWS Well-Architected Framework의 기둥을 통해 워크로드를 측정하기 위한 일관된 프로세스를 제공하며, 결정 사항을 문서화하고, 워크로드 개선을 위한 권장 사항을 제공하고, 워크로드를 더 안정적이고, 안전하며, 효율적이고, 비용 효과적으로 만들도록 안내합니다.

평가​

Observability 성숙도 모델 평가는 현재 Observability 상태를 파악하고 개선 영역을 식별하는 데 사용할 수 있습니다. 각 단계의 평가에는 여러 팀에 걸친 기존 모니터링 및 관리 관행을 평가하고, 격차와 개선 영역을 식별하며, 다음 단계에 대한 전반적인 준비 상태를 결정하는 것이 필수적입니다. 성숙도 평가는 비즈니스 프로세스 개요, 워크로드 인벤토리 및 도구 발견, 현재 과제 식별, 조직 우선순위 및 목표 이해에서 시작됩니다.

평가는 기존 구성의 추가 개발 및 최적화를 위한 기반을 마련하는 대상 지표와 KPI를 식별하는 데 도움이 됩니다. Observability 성숙도 모델 평가는 비즈니스가 현대 시스템의 복잡하고 동적인 특성을 처리할 준비가 되어 있는지 확인하는 데 중요한 역할을 합니다. 시스템 장애나 성능 문제로 이어질 수 있는 사각지대와 취약점을 식별하는 데 도움이 됩니다.

또한 정기적인 평가는 비즈니스가 민첩하고 적응력 있게 유지되도록 합니다. 진화하는 기술과 방법론에 보조를 맞출 수 있게 하여, 시스템이 항상 최고의 효율성과 안정성을 유지하도록 보장합니다.

이 평가는 AWS 모범 사례에 대한 Observability 전략의 상태를 검토하고, 개선 기회를 식별하며, 시간에 따른 진행 상황을 추적하는 데 도움이 되도록 설계되었습니다. 아래 질문은 현재 Observability 성숙도 수준을 평가하는 데 도움이 됩니다. 무료로 "AWS Observability 성숙도 모델 평가" 도구를 사용한 평가를 받으려면 AWS 어카운트 팀에 문의하세요.

Logs

  1. logs를 어떻게 수집하나요?
  2. logs를 어떻게 활용하나요?
  3. logs에 어떻게 접근하나요?
  4. 보안 및 규정 준수를 위한 로그 보존 정책은 무엇인가요?
  5. 현재 ML/AI 기능을 사용하고 있나요?

Metrics

  1. 어떤 유형의 metrics를 수집하나요?
  2. metrics를 어떻게 활용하나요?
  3. metrics에 어떻게 접근하나요?

Traces

  1. traces를 어떻게 수집하나요?
  2. traces를 어떻게 활용하나요?

대시보드 및 알림

  1. 알람을 어떻게 활용하나요?
  2. 대시보드를 어떻게 활용하나요?

조직

  1. 엔터프라이즈 Observability 전략이 있나요?
  2. SLO를 어떻게 활용하나요?

Observability 전략 수립​

조직이 자신의 Observability 단계를 식별한 후에는 현재 프로세스와 도구를 최적화하고 성숙도를 향해 노력하는 전략을 수립해야 합니다. 조직은 고객이 훌륭한 고객 경험을 가지도록 하고자 하므로, 그러한 고객 요구사항에서 시작하여 거기서부터 역방향으로 작업합니다. 그런 다음 이러한 요구사항을 잘 이해하는 이해관계자와 협력합니다. Observability 전략을 목표로 하여, 조직은 먼저 전반적인 비즈니스 목표와 일치하는 Observability 목표를 정의하고, 전략을 통해 달성하고자 하는 바를 명확하게 표현하여 Observability 계획을 수립하고 구현하기 위한 로드맵을 제공해야 합니다.

다음으로, 조직은 시스템 성능에 대한 인사이트를 제공할 핵심 지표(KPI)를 식별해야 합니다. 여기에는 지연 시간과 오류율부터 리소스 사용률과 트랜잭션 볼륨까지 다양할 수 있습니다. 지표의 선택은 비즈니스의 특성과 구체적인 요구에 크게 의존한다는 점에 유의하는 것이 중요합니다.

핵심 지표가 식별되면, 조직은 데이터 수집에 필요한 도구와 기술을 결정할 수 있습니다. 도구 선택은 조직의 목표와의 일치, 기존 시스템과의 통합 용이성, 비용 최적화, 확장성 달성, 고객 요구 충족, 전반적인 고객 경험 개선을 기반으로 해야 합니다.

마지막으로, 조직은 Observability를 중시하는 문화를 장려해야 합니다. 여기에는 팀원들에게 Observability의 중요성을 교육하고, 시스템 성능을 사전에 모니터링하도록 장려하며, 지속적인 학습과 개선의 문화를 조성하는 것이 포함됩니다. 이 전략은 최상의 고객 경험을 위한 수집, 조치, 개선의 지속적인 프로세스라는 선순환을 만들어냅니다.

Observability 선순환

요약하면, Observability 전략을 수립하기 위해 세 가지 주요 측면을 고려해야 합니다: 1) 무엇을 수집해야 하는지 2) 관측해야 하는 모든 시스템과 워크로드는 무엇인지 3) 문제가 발생했을 때 어떻게 대응하며, 이를 해결하기 위한 어떤 메커니즘이 마련되어야 하는지.

결론​

Observability 성숙도 모델은 워크로드와 인프라의 동작을 이해, 분석, 대응하는 능력을 개선하기 위한 현재 상태를 평가하고 방법을 모색하는 조직을 위한 로드맵입니다. 현재 역량을 평가하고, 고급 모니터링 기법을 채택하며, 데이터 기반 인사이트를 활용하는 구조화된 접근 방식을 따름으로써, 비즈니스는 더 높은 수준의 Observability를 달성하고 워크로드와 인프라에 대해 더 정보에 기반한 결정을 내릴 수 있습니다. 이 모델은 다양한 성숙도 수준을 거쳐 발전하기 위해 조직이 개발해야 하는 핵심 역량과 관행을 설명하며, 궁극적으로 사전 예방적 Observability의 이점을 완전히 활용할 수 있는 상태에 도달하는 것을 목표로 합니다.

유용한 리소스​