What? 옵저버빌리티란 무엇인가?
옵저버빌리티 (Observability)의 정의
Observability (옵저버빌리티) 단어의 뜻 : (명사) 관찰할 수 있음. 식별 가능성, 주목할 만함
옵저버빌리티는 관찰 가능성이라는 용어로 수학, 특히 제어 이론에 뿌리를 두고 있습니다. 이 이론이 최근 DevOps 및 소프트웨어 엔지니어링(SRE)에 적용되고 발전되고 있는데요. 시스템은 "초기 상태의 값이 시스템 출력에서 결정될 수 있는 경우에만 관찰 가능한" 것으로 간주된다는 이론입니다. 다시 말해 관찰 가능성은 사용 가능한 모든 출력을 실시간으로 분석하여 진화하는 복잡한 시스템의 내부 상태를 이해할 수 있는 능력입니다.
관찰 가능성을 통해 애플리케이션 성능과 비즈니스 관련 데이터를 자유롭게 조사할 수 있습니다. 이를 맥락화함으로써 비즈니스에 진정으로 영향을 미치는 문제를 신속하게 찾아 격리하고, 최종 사용자 만족도를 높이고, 혁신에 집중함으로써 시장 출시 시간을 단축할 수 있습니다.
a system is called controllable if and only if the system states can be changed by changing the system input (Kalman, 1960, 1963)
그렇다면, 기존 모니터링과 옵저버빌리티 차이점은 무엇일까요?
아래 그림이 두 관계를 잘 묘사한 것 같습니다. 모니터링은 옵저버빌리티(관찰 가능성)의 하위 집합이라고 볼 수 있습니다. 모니터링은 플랫폼 전체에서 완전히 확장된 관찰 가능성을 향한 단계입니다. 모니터링과 애플리케이션 성능 모니터링(APM)은 종종 같은 의미로 사용됩니다.
모니터링은 애플리케이션 상태 및 시스템 성능을 이해하기 위해 대시보드 및 경고와 함께 미리 구성된 원격 측정 데이터를 사용하는 프로세스입니다.
옵저버빌리티(관찰 가능성)은 사용 가능한 모든 출력을 실시간으로 분석하여 진화하는 복잡한 시스템의 내부 상태를 이해할 수 있는 능력입니다.
관찰 가능성과 모니터링의 관계
관찰 가능성과 모니터링은 모두 유사한 데이터(메트릭, 트레이스 및 로그)에 의존하지만 관찰 가능성은 사전 예방을 허용하는 반면 모니터링은 반응적입니다.
옵저버빌리티(Observability)는 원격 측정 데이터(로그, 메트릭 및 추적)를 사용하여 애플리케이션 상태를 유지하고 애플리케이션 오류의 원인을 이해합니다. 이들은 함께 애플리케이션의 외부 출력에서 신호를 사용하여 내부 상태의 상태에 대한 핵심 통찰력을 얻습니다.
관찰 가능성은 동전의 양면으로 간주될 수 있습니다. 둘 다 동일한 유형의 원격 측정 데이터를 사용하여 소프트웨어 분산 시스템에 대한 통찰력을 제공합니다. 이러한 데이터 유형(메트릭, 추적 및 로그)은 종종 관찰 가능성의 세 가지 기둥 이라고 합니다 .
- 로그(Log) : 로그는 소프트웨어에서 발생하는 이벤트를 기록합니다. 이러한 이벤트는 개발자가 오류가 발생한 위치를 이해하고 실행 가능한 통찰력을 얻는 데 도움이 됩니다. 메트릭은 일반적으로 문제의 첫 징후를 볼 수 있는 곳이지만 로그는 문제가 작업에 미치는 영향에 대한 추가 컨텍스트를 제공합니다.
- 메트릭(Metric) : 메트릭은 숫자 값을 사용하여 시스템 애플리케이션 성능 및 리소스 사용률을 나타냅니다. 이 데이터를 그래프 형식으로 입력하여 시간 경과에 따른 시스템 성능을 확인할 수 있습니다. DevOps 팀은 게이지, 델타 및 누적 지표를 사용합니다.
- 추적(Trace) : 추적은 관찰 가능성 시스템 전체에서 작업이 한 노드에서 다른 노드로 이동하는 방식을 보여줍니다. 이를 통해 특정 사용자 작업 또는 API 호출에 대한 문제 해결을 맥락화할 수 있습니다.
 모니터링은 애플리케이션의 상태와 성능을 이해하기 위해 대시보드 및 경고와 함께 미리 구성된 원격 측정 데이터를 사용하는 프로세스입니다. |
 관찰 가능성은 사용 가능한 모든 출력을 실시간으로 분석하여 진화하는 시스템의 내부 상태를 이해하는 능력입니다. |
관찰 가능성과 모니터링은 공생 관계에 있습니다. 효율적인 관찰 가능성이 없으면 모니터링이 이루어질 수 없기 때문입니다.
관찰 가능성이란 실제로 무엇을 의미합니까?
관찰 가능성을 마케팅 용어로 간주하는 것은 바람직하지 않습니다. 관찰 가능성은 오늘날 어떤 공급업체도 전체적으로 다루지 않는 다음과 같은 고유한 것을 의미합니다:
- 비즈니스에서 관심을 갖는 모든 작업 단위(트랜잭션, 일괄 작업 등)에 대한 코드 프로필, 메트릭, 로그, 추적 및 종속성의 포괄적인 컬렉션입니다. 따라서 애플리케이션이 1초에 5,000개의 트랜잭션을 실행하는 경우 모니터링 시스템은 각 트랜잭션을 개별적으로 이해하고 각각에 대한 코드 프로필, 메트릭, 로그, 추적 및 종속성을 개별적으로 수집합니다.
- 데이터 볼륨과 코드 프로필, 메트릭, 로그, 추적 및 종속성 맵을 구성하는 다양한 데이터 유형을 처리할 수 있는 빅 데이터 백엔드입니다. 이 요구 사항만으로도 백엔드가 Cassandra 및 Elastic과 같은 오픈 소스 데이터베이스 세트로 구성된 모든 벤더를 레거시 솔루션으로 만들 수 있습니다.
- 각 관심 작업 단위에 대한 관계 및 종속성을 자동으로 계산하는 관계 엔진입니다.
관계는 애플리케이션을 통해 해당 서비스 및 데이터베이스, 일련의 추적 및 해당 범위, VM이 특정 호스트에서 실행되는 "실행 위치" 또는 Kubernetes 노드에 대한 N 계층 트랜잭션의 흐름일 수 있습니다. 특정 포드에서 실행(및 다른 VM 또는 노드와 리소스 경쟁) 또는 단순히 멤버십(이 트랜잭션은 이 VMware 데이터 센터 또는 이 AWS 지역에서 실행됨) - AI와 인간이 추가로 분석할 가치가 있는 방대한 양의 데이터에서 자동으로 예외를 찾는 높은 카디널리티 분석 엔진입니다.
- 즉각적이고 자동화된 계측 엔진입니다. 새로운 마이크로서비스가 프로덕션 환경에 배포되면 모니터링 시스템은 그 존재를 즉시 감지하고 적절한(올바른 언어, JVM 및 프레임워크용) 계측을 자동으로 인스턴스화해야 합니다. 사후에 수동으로 코드를 계측하거나 에이전트를 설치하는 것만으로는 더 이상 충분하지 않습니다.
- 실제로 유용하고 실제로 원하는 대로 작동하는 AI 기반 근본 원인 분석 엔진입니다. Observability가 존재하기 위한 요구 사항인 포괄적이고 결정론적인 데이터는 작동하는 AI에 필요한 전제 조건입니다. 통계적 추정치에 대한 근본 원인을 찾으려고 시도하면 고전적인 "가비지 인, 가비지 아웃" 문제가 발생하기 때문입니다.
- Observability의 결정적 데이터는 모니터링에서 가장 원하는 기능인 자동화된 문제 해결을 위한 필수 전제 조건이기도 합니다. 인간은 오늘날의 매우 역동적인 시스템과 애플리케이션을 따라잡을 수 없으며 자동화가 진정한 자체 운영, 자체 조정 및 자체 치유 시스템을 만들기 위해 개입해야 할 때입니다.
< 출처 > Ranking the Observability Offerings / Bernd Harzog / CEO, APM Experts (한글 번역본)
Why? 왜 옵저버빌리티가 최근에 거론되고 있습니까?
오늘날 기업 환경은 점점 더 복잡해지고 분산되어 애플리케이션 상태를 유지하기가 더 어려워지고 있습니다. 클라우드 네이티브 마이크로서비스에는 여러 개의 동적으로 변화하기 때문에 오류가 발생하기 쉽고 문제를 감지 하기가 더 어렵습니다. 고맙게도 관찰 가능성은 사용자 경험에 영향을 미치기 전에 어떤 문제가 발생하는지에 대한 실행 가능한 통찰력을 제공합니다.
Kubernetes 클러스터에서 실행되는 환경으로 애플리케이션이 전환됨에 따라 기존 모니터링 체계에서는 문제가 모니터링되지 않거나 발견되지 않습니다. 관찰 가능성을 통해 개발자가 찾기 위해 애쓰던 "알려지지 않은 미지수(known unknowns)"를 식별할 수 있습니다.
모니터링에는 SRE 및 DevOps 전문가에게 문제가 있음을 알렸지만 오류가 발생한 이유는 설명하지 않은 "알려진 미지수(known unknowns)"가 필요합니다 . 추가된 관찰 가능성 계층은 조직의 시간을 절약하고 소프트웨어 상태를 쉽게 유지하는 데 도움이 됩니다.
기술이 발전함에 따라 AI와 자동화가 점점 더 중요해지고 있습니다. AIOps는 최신 애플리케이션에 통합되어 광범위한 인력이 필요했던 작업을 간소화하고 자동화하고 있습니다.
원격 측정 데이터를 보다 정확하게 수집하기 위해 이 기능을 활용하면 테스트, 모니터링 및 지속적 전달을 보다 쉽게 실행할 수 있습니다. 또한 전체 기술 스택에서 발생하는 상황을 더 폭넓게 이해할 수 있습니다.
What? 관찰가능성의 이점(Benefit) 은 무엇입니까?
IT, SRE, 개발자 및 운영 팀은 가시성을 애플리케이션에 구현하여 큰 이점을 얻을 수 있습니다. 클라우드 네이티브 환경에서 일반적인 문제를 해결하기 위해 원격 분석 데이터를 수집하여 최종 사용자의 경험을 개선하고 생산성을 높입니다.
관찰 가능성의 중요한 이점은 다음과 같습니다.
- 가시성 증가: 조직이 복잡한 분산 시스템에 의존함에 따라 애플리케이션의 명확한 가시성이 점점 더 어려워지고 있습니다. 관찰 가능성은 고객에게 영향을 미치기 전에 문제를 더 빨리 해결하는 데 필요한 가시성을 제공합니다. 최종 사용자 경험을 높이면 수익을 늘리고 고객 충성도를 높이며 프로세스를 최적화할 수 있습니다.
- 디버깅 향상: Observable 시스템을 통해 개발자는 상황에 맞는 데이터를 사용하여 처음부터 끝까지 요청을 추적할 수 있습니다. 사용자 여정에 따른 이 추가 정보를 통해 IT 전문가는 시스템에서 오류가 발생할 때 문제를 보다 신속하게 수정하고 디버깅할 수 있습니다.
- 사용자 경험 개선: 개발자는 Instana와 같은 관찰 플랫폼 덕분에 분산 서비스 내에서 발생하는 대기 시간을 그 어느 때보다 빠르게 포착할 수 있습니다. 그렇게 할 수 있는 능력은 사용자 경험을 개선하고 회사의 평판을 개선하고 반복 고객으로 이어질 수 있습니다.
- 업그레이드 알림: Observability는 알림을 통해 가장 관련성이 높은 성능 문제를 그 어느 때보다 빠르게 찾을 수 있도록 도와줍니다. 이러한 경고는 IT 전문가가 문제를 해결하고 불필요한 소음을 줄이며 이전보다 더 짧은 시간 내에 문제의 근본 원인을 찾는 데 도움이 됩니다.
- 비즈니스 전략 최적화: 전체 스택 분석 및 데이터를 실시간으로 분석하여 조직 계획을 개선하고 전환율을 가속화합니다. 다양한 IT 릴리스의 영향을 이해하면 비즈니스 목표를 달성하고 있는지 알 수 있는 상황별 데이터를 제공하는 데 도움이 됩니다.
애플리케이션 오류의 근본 원인을 찾는 데 소요되는 시간을 줄이고 관찰 가능성을 통해 소프트웨어 상태를 개선할 수 있습니다.
How? 시스템을 어떻게 관찰 가능하게 만들 수 있을까?
이제 관찰 가능성이 무엇이고 비즈니스에 어떻게 도움이 되는지 자세히 이해했으므로 내 시스템을 관찰 가능하게 만드는 방법이 궁금할 것입니다.
관찰 가능성을 달성하는 것은 디지털 시스템에서 원격 분석 데이터를 수집하는 것 이상입니다. 필요한 데이터를 소싱하고 추가 컨텍스트를 추가하여 오류에 대한 솔루션을 찾을 수 있는 적절한 도구가 필요합니다.
다음은 관찰 가능성을 구현하는 다섯 가지 기본 구성 요소 입니다 .
- 계측(Instrumentation) : 계측 도구는 오픈 소스 또는 공급업체별 플랫폼의 원격 분석 데이터를 사용하여 인프라에 대한 가시성을 제공합니다.
- 분산 추적(Distributed Tracing) : 분산 추적은 시스템의 내부 마이크로서비스가 어떻게 상호 연결되고 각 사용자 요청을 매핑하는지 보여주기 때문에 관찰 가능성의 필수적인 측면입니다.
- 사고 대응(Incident Response) : 관찰 가능성 플랫폼에는 문제가 발생할 때 올바른 IT 팀에 알리는 경고 관리 시스템이 있어야 합니다.
- 데이터 상관 관계(Data Correlation) : 원격 측정 데이터를 처리하고 상관 관계를 지정하면 데이터를 그래프와 차트로 변환하는 데 필요한 컨텍스트가 추가됩니다. 이러한 시각화는 팀이 수집된 데이터의 전체 그림을 보고 시계열 동안 상승 및 하강을 이해하는 데 도움이 됩니다.
- AIOps : 머신 러닝 모델은 사고 데이터 집계, 상관 관계 지정 및 우선 순위 지정과 같은 IT 운영을 자동화합니다. AIOps 도구는 궁극적으로 사고 대응을 가속화하고 평균 예방 시간(MTTR)을 개선하는 데 도움이 됩니다.
위 구성요소를 구현하기 위해 제공되는 다양한 오픈소프트웨어를 적용할 것인지 혹은 외부 벤더사에서 제공하는 전문 솔루션을 채택할 것인지는 조직내 규모와 역량을 고려하여 기술 부채 비용을 감안하여 옵저버빌리티 요소를 적용해 나가시기 바랍니다.
끝으로 왜 옵져버빌리티 역량이 우리 IT 개발 운영 담당자에게 필요한지 컨셉을 잘 정리한 3분짜리 동영상이 있어 추천 드리면 글을 마칩니다.
Let's rethink IT DevOps
위 내용은 개인이 조사하고 이해한 바탕으로 작성되었습니다. 아래 참고 사이트의 일부 내용을 한글로 인용 하였으니 참고하시기 바랍니다. 잘못된 정보가 있다면 댓글로 의견 주시면 감사하겠습니다.
< 내용 및 이미지 참고 출처 >
참고1. What is Observability? - Instana Blog
참고2 : Observability vs. Monitoring: What’s The Difference in DevOps?
'Why' 카테고리의 다른 글
| IT 운영 현대화가 필요한 이유와 대응 방안 (0) | 2023.04.06 |
|---|
