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

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

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

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

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

### 관측 가능성 vs. 모니터링

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

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

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

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

### 메트릭

메트릭은 어떤 시스템 상태를 나타내는 특정 시점의 측정값(스칼라)이다. 일반적인 메트릭의 예시는 다음과 같다:
* 초당 HTTP 요청 수
* 쿼리 실패 총 횟수
* 바이트 단위의 데이터베이스 크기
* 마지막 쓰레기 수집 이후 경과 시간(초)

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

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

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

### 로그

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

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

### 트레이스

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

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

### 지속적 프로파일링

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

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

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

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

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

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

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

## 같이 보기
* 애플리케이션 성능 관리 (APM)
* 데브옵스
* 사이트 신뢰성 공학 (SRE)

## 외부 링크
* CNCF Observability Technical Advisory Group (TAG)

## 각주

## 참고 문헌
* 
* 
* 
* 

분류:소프트웨어 공학
분류:분산 컴퓨팅