close
본문으로 이동

관측 가능성 (소프트웨어)

링크 편집
위키백과, 우리 모두의 백과사전.

소프트웨어 공학, 더 구체적으로는 분산 컴퓨팅에서 관측 가능성(observability)이란 프로그램의 실행, 모듈의 내부 상태, 그리고 구성 요소 간의 통신에 관한 데이터를 수집하는 능력을 의미한다.[1][2] 관측 가능성을 개선하기 위해 소프트웨어 엔지니어들은 원격 측정(telemetry) 정보를 수집하기 위한 광범위한 로깅 및 트레이싱 기술과, 이를 분석하고 활용하기 위한 도구들을 사용한다. 관측 가능성은 서비스 중단을 분류하는 첫 번째 단계이기에 사이트 신뢰성 공학의 근간이 된다. 관측 가능성의 목표 중 하나는 문제를 디버깅하는 데 필요한 사전 지식의 양을 최소화하는 것이다.

어원, 용어 및 정의

[편집]

이 용어는 제어 이론에서 차용되었는데, 제어 이론에서 시스템의 "관측 가능성"은 출력값을 통해 시스템의 상태를 얼마나 잘 결정할 수 있는지를 측정하는 척도이다. 이와 유사하게, 소프트웨어 관측 가능성은 획득한 원격 측정 데이터(메트릭, 로그, 트레이스, 프로파일링)로부터 시스템의 상태를 얼마나 잘 이해할 수 있는지를 측정한다.

관측 가능성의 정의는 벤더마다 다르다:

관측 가능성은 시스템의 내부 상태를 더 투명하게 만드는 과정이다. 시스템은 시스템이 생산하는 데이터에 의해 관측 가능해지며, 이는 결국 인프라나 애플리케이션이 건강하고 정상적으로 작동하는지 판단하는 데 도움을 준다.

— Grafana Labs[3]

새로운 코드를 배포할 필요 없이, 시스템이 처할 수 있는 모든 상태(아무리 새롭거나 기괴하더라도)를 얼마나 잘 이해하고 설명할 수 있는지에 대한 척도

— 허니콤[4]

분산 애플리케이션과 그것이 실행되는 하드웨어 및 네트워크로부터 발생하는 지속적인 성능 데이터 스트림을 집계, 상관관계 분석 및 분석하기 위한 소프트웨어 도구 및 관행

— IBM Instana[5]

관측 가능성은 분석을 시작하기 전에 모든 원시 데이터를 중앙 서비스로 전송하는 것에서 시작된다

— Edge Delta[6]

로그, 메트릭, 트레이스와 같이 시스템이 생성하는 데이터를 기반으로 시스템의 현재 상태를 측정하는 능력

— Dynatrace[7]

관측 가능성은 팀이 시스템을 능동적으로 디버깅할 수 있게 해주는 도구 또는 기술적 솔루션이다. 관측 가능성은 사전에 정의되지 않은 속성과 패턴을 탐색하는 것에 기반한다.

— Google Cloud[8]

모든 메트릭, 이벤트, 로그 및 트레이스를 선제적으로 수집, 시각화하고 지능을 적용하여 복잡한 디지털 시스템의 동작을 이해할 수 있도록 하는 것

— New Relic [9]

이 용어는 종종 숫자 줄임말인 o11y로 지칭되기도 한다(11은 단어의 첫 글자와 마지막 글자 사이에 있는 알파벳의 개수를 의미한다). 이는 i18n 및 l10n이나 k8s와 같은 다른 컴퓨터 과학 약어와 유사하다.[10]

관측 가능성 vs. 모니터링

[편집]

관측 가능성과 모니터링은 때때로 혼용되어 사용된다.[11] 도구, 상용 제품 및 관행의 복잡성이 진화함에 따라, 새로운 도구를 기존의 것과 차별화하기 위해 "모니터링"이 관측 가능성으로 재브랜딩되었다.

이 두 용어는 일반적으로 다음과 같이 대비된다. 시스템은 미리 정의된 원격 측정 세트를 사용하여 모니터링되며,[8] 모니터링되는 시스템은 관측 가능할 수 있다.[12]

채리티 메이저스(Charity Majors) 등은 모니터링 도구만 보유한 엔지니어링 팀은 전문가의 사전 지식(연차)에 의존하게 되는 반면, 관측 가능성 도구를 보유한 팀은 탐색적 분석(호기심)에 의존하게 된다고 주장한다.[4]

원격 측정 유형

[편집]

관측 가능성은 메트릭, 로그, 트레이스라는 세 가지 주요 원격 측정 데이터 유형에 의존한다.[7][8][13] 이들은 종종 "관측 가능성의 세 기둥"으로 불린다.[14]

메트릭

[편집]

메트릭은 어떤 시스템 상태를 나타내는 특정 시점의 측정값(스칼라)이다. 일반적인 메트릭의 예시는 다음과 같다:

  • 초당 HTTP 요청 수
  • 쿼리 실패 총 횟수
  • 바이트 단위의 데이터베이스 크기
  • 마지막 쓰레기 수집 이후 경과 시간(초)

모니터링 도구는 일반적으로 특정 메트릭 값이 설정된 임계값을 초과할 때 경고를 보내도록 구성된다. 임계값은 정상적인 운영 조건에 대한 지식과 경험을 바탕으로 설정된다.

메트릭은 일반적으로 그룹화와 검색 용이성을 위해 태그가 지정된다.

애플리케이션 개발자는 소프트웨어가 출시되기 전에 어떤 종류의 메트릭을 구현할지 선택한다. 그 결과, 이전에 알려지지 않은 문제가 발생했을 때 새로운 코드를 배포하지 않고는 새로운 메트릭을 추가할 수 없다. 또한, 메트릭의 카디널리티는 원격 측정 데이터의 저장 크기를 감당하기 힘들 정도로 비싸게 만들 수 있다. 메트릭은 카디널리티가 제한되어 있기 때문에 종종 집계된 값(예: 평균 페이지 로드 시간 또는 5초 평균 요청률)을 나타내는 데 사용된다. 외부 컨텍스트 없이는 이벤트(예: 사용자 요청)와 개별 메트릭 값 사이의 상관관계를 파악하는 것이 불가능하다.

로그

[편집]

로그 또는 로그 라인은 일반적으로 사람이 읽을 수 있도록 의도된 자유 형식의 비정형 텍스트 덩어리이다. 현대의 로깅은 기계가 파싱할 수 있도록 구조화되어 있다.[4] 메트릭과 마찬가지로, 애플리케이션 개발자는 사전에 애플리케이션에 로깅을 구현해야 하며, 다른 로그 정보가 필요한 경우 새로운 코드를 배포해야 한다.

로그에는 일반적으로 타임스탬프와 심각도 수준이 포함된다. 하나의 이벤트(예: 사용자 요청)가 여러 로그 라인에 걸쳐 파편화될 수 있으며, 동시적인 이벤트의 로그들과 섞일 수 있다.

트레이스

[편집]

분산 트레이싱

[편집]

클라우드 네이티브 애플리케이션은 일반적으로 하나의 요청을 함께 수행하는 분산된 서비스들로 구성된다. 분산 트레이스는 단일 사용자 요청의 진행 과정을 추적하는 상호 연관된 일련의 개별 이벤트(스팬이라고도 함)이다.[4] 트레이스는 요청을 처리하기 위해 상호 작용하는 서비스들 간의 인과 및 시간 관계를 보여준다.

애플리케이션에 트레이싱을 구현한다는 것은 스팬 정보를 트레이싱 백엔드로 보내는 것을 의미한다. 트레이싱 백엔드는 수신된 스팬들의 상관관계를 분석하여 시각화된 트레이스를 생성한다. 요청이 여러 서비스를 거쳐가는 과정을 따라갈 수 있도록, 스팬에는 스팬 간의 부모-자식 관계를 구축할 수 있는 고유 식별자가 레이블로 지정된다. 스팬 정보는 일반적으로 외부 요청의 HTTP 헤더를 통해 공유된다.[4][15][16]

지속적 프로파일링

[편집]

지속적 프로파일링은 애플리케이션이 자원을 어떻게 소비하는지 정확하게 결정하기 위해 사용되는 또 다른 원격 측정 유형이다.[17]

인스트루먼테이션 (Instrumentation)

[편집]

애플리케이션을 관측할 수 있으려면 애플리케이션의 동작에 대한 원격 측정 데이터를 수집하거나 내보내야 한다. 인스트루먼테이션은 애플리케이션의 정상적인 작동과 병행하여 원격 측정 데이터를 생성하는 것을 의미한다.[4] 이렇게 생성된 데이터는 나중에 분석하기 위해 독립적인 백엔드에 의해 수집된다.

빠르게 변화하는 시스템에서 인스트루먼테이션 그 자체는 종종 최선의 문서가 된다. 왜냐하면 그것은 의도(엔지니어가 이름을 붙이고 수집하기로 결정한 차원들이 무엇인가?)와 프로덕션 환경의 실시간 라이브 상태 정보를 결합하기 때문이다.[4]

인스트루먼테이션은 자동이거나 커스텀일 수 있다. 자동 인스트루먼테이션은 포괄적인 범위와 즉각적인 가치를 제공하며, 커스텀 인스트루먼테이션은 더 높은 가치를 제공하지만 대상 애플리케이션에 대한 더 깊은 개입이 필요하다.

인스트루먼테이션은 코드 내에서 수행되는 방식(네이티브 - 대상 애플리케이션의 코드 수정)과 코드 외부에서 수행되는 방식(예: 사이드카, eBPF)이 있다.

커스텀 인스트루먼테이션과 함께 새로운 기능을 프로덕션에 배포하여 이를 검증하는 관행을 "관측 가능성 기반 개발"(observability-driven development)이라고 부른다.[4]

"관측 가능성의 기둥"

[편집]

메트릭, 로그, 트레이스는 관측 가능성의 기둥으로 가장 흔히 언급된다.[14] 채리티 메이저스 등은 관측 가능성의 기둥이 고카디널리티(high cardinality), 고차원성(high-dimensionality), 그리고 탐색 가능성(explorability)이라고 제안하며, "현대 시스템은 정확히 똑같은 방식으로 두 번 실패하는 경우가 거의 없기 때문에" 런북과 대시보드는 가치가 거의 없다고 주장한다.[4]

자기 모니터링 (Self monitoring)

[편집]

자기 모니터링은 눈에 띄지 않는 장애의 위험을 줄이기 위해 관측 가능성 스택이 서로를 모니터링하는 관행이다. 연관된 실패를 더욱 방지하기 위해 고가용성 및 중복성 외에도 자기 모니터링을 구축할 수 있다.

같이 보기

[편집]

외부 링크

[편집]

각주

[편집]
  1. ↑ Fellows, Geoff (1998). 《High-Performance Client/Server: A Guide to Building and Managing Robust Distributed Systems》. 《Internet Research》 8. doi:10.1108/intr.1998.17208eaf.007. ISSN 1066-2243.
  2. ↑ Cantrill, Bryan (2006). 《Hidden in Plain Sight: Improvements in the observability of software can help you diagnose your most crippling performance problems.》 (영어). 《ACM Queue》 4. 26–36쪽. doi:10.1145/1117389.1117401. ISSN 1542-7730. S2CID 14505819.
  3. ↑ “What is observability?”. 《Grafana Labs》. 2025년 12월 8일에 확인함.
  4. 1 2 3 4 5 6 7 8 9 Majors, Charity; Fong-Jones, Liz; Miranda, George (2022). 《Observability engineering : achieving production excellence》 1판. Sebastopol, CA: O'Reilly Media, Inc. ISBN 9781492076445. OCLC 1315555871.
  5. ↑ “What is observability”. 《IBM》. 2021년 10월 15일. 2023년 3월 9일에 확인함.
  6. ↑ “How to Begin Observability at the Data Source”. 《Cisco》. 2023년 10월 26일. 2023년 10월 26일에 확인함.
  7. 1 2 Livens, Jay (October 2021). “What is observability?”. 《Dynatrace》. 2023년 3월 9일에 확인함.
  8. 1 2 3 “DevOps measurement: Monitoring and observability”. 《Google Cloud》. 2023년 3월 9일에 확인함.
  9. ↑ Reinholds, Amy (2021년 11월 30일). “What is observability?”. 《New Relic》. 2023년 3월 9일에 확인함.
  10. ↑ “How Are Structured Logs Different from Events?”. 2018년 6월 26일.
  11. ↑ Hadfield, Ally (2022년 6월 29일). “Observability vs. Monitoring: What's The Difference in DevOps?”. 《Instana》. 2023년 3월 15일에 확인함.
  12. ↑ Kidd, Chrissy. “Monitoring, Observability & Telemetry: Everything You Need To Know for Observable Work”. 2023년 3월 15일에 확인함.
  13. ↑ “What is Observability? A Beginner's Guide”. 《Splunk》. 2023년 3월 9일에 확인함.
  14. 1 2 Sridharan, Cindy (2018). 〈Chapter 4. The Three Pillars of Observability〉 1판. 《Distributed systems observability : a guide to building robust systems》. Sebastopol, CA: O'Reilly Media, Inc. ISBN 978-1-4920-3342-4. OCLC 1044741317.
  15. ↑ “Trace Context”. W3C. 2021년 11월 23일. 2023년 9월 27일에 확인함.
  16. ↑ “b3-propagation”. openzipkin. 2023년 9월 27일에 확인함.
  17. ↑ “What is continuous profiling?”. 《Cloud Native Computing Foundation》. 2022년 5월 31일. 2023년 3월 9일에 확인함.

참고 문헌

[편집]
  • Boten, Alex; Majors, Charity (2022). 《Cloud-Native Observability with OpenTelemetry》. Packt Publishing. ISBN 978-1-80107-190-1. OCLC 1314053525. 
  • Majors, Charity; Fong-Jones, Liz; Miranda, George (2022). 《Observability engineering : achieving production excellence》 1판. Sebastopol, CA: O'Reilly Media, Inc. ISBN 9781492076445. OCLC 1315555871. 
  • Sridharan, Cindy (2018). 《Distributed systems observability : a guide to building robust systems》 1판. Sebastopol, CA: O'Reilly Media, Inc. ISBN 978-1-4920-3342-4. OCLC 1044741317. 
  • Hausenblas, Michael (2023). 《Cloud Observability in Action》. Manning. ISBN 9781633439597. OCLC 1359045370. 
원본 주소 "https://ko.wikipedia.org/w/index.php?title=관측_가능성_(소프트웨어)&oldid=41226157"