[Chapter 05 | Observability] Observability 기초 개념

1. Observability란

 

1.1 Tracing vs Monitoring vs Observability

 

1.1.1 Tracing

프로그램의 실행 과정을 상세히 남기는 것

ex) 

- 파이썬 코딩에서 print() 하여 결과물을 확인하고 다시 수정하는 것

- 호출하는 메소드의 시작 시간과 끝 시간을 남겨서 걸린 시간을 계산할 수 있게 하는 것.

- 에러 발생시 stacktrace 

- network ping의 router trip 경로

 

오래전부터 APM(application performance monitoring)이라는 분야에서 이를 활용함

Java byte code instrumentation도 APM 분야에서 가장 많이 사용함

즉 중간과정이 있어야 성능에 대해서 자세히 분석할 수 있다는 것

 

❓ Java byte code instrumentation란?

자바 내부적으로 오류를 측정하거나 추적 정보를 쓰기 위한 기능으로 APM하는 사람들이 byte code로 바꿔치기 한다는 것

java 가 이해할수 있는 기계어로 구성된 class 파일에 transform 시켜서 내가 실행과정을 위해 만든 코드를 중간에 끼워넣는 것   

 

과거에는 하나의 머신, 또는 하나의 어플리케이션에 대한 성능 지표를 수집하고 분석하는 것이 역할

현대에는 API, micorservice 등으로 하나의 어플리케이션이나 서비스가 구동되기 위해서는

여러가지 인프라와 어플리케이션이 상호작용하기 때문에 Distributed tracing 이 중요해지고 있음 

✔️ 대표적인 distributed tracing 오픈소스 : Zipkin, Jaeger

 

Tracing 정보는 많이 남길수록 시스템 부하, 데이터 많이 사용하게되므로 무분별하게 사용하거나 남기면 X

 

 

1.1.2 Monitoring

에러, 다운타임, 비정상 상태 등을 감지하기 위해서 이벤트, 메트릭 정보들 남기고 추적하는 것

모니터링 방식은 메트릭/ 로그 모니터링으로 나눌 수 있음

 

• Metric monitoring
  • 특정 기간이나 범위의 성공/실패 상태를 모니터링
  • 목표치 대비 성능의 상태나 관계를 모니터링
  • memory use, request per second, active connections, flow, or number of errors
  • 즉 수치로 요약된 정보들을 확인하는 것 

 

• Log monitoring
  • 관심있는 이벤트 데이터를 남기고 내용을 살피는 방식
  • 이벤트 데이터를 분석
    • filter -> aggregation -> metric
    • 텍스트 검색, 필터 검색

 

 

1.1.3 Observability

최초의 시스템 내부 상태에 대해서 직접 들어가서 확인하는 것이 아니라, 쌓여있는 데이터를 연결하고 추론해서 확인할 수 있다는 개념

최근에는 IT 시스템이 복잡해지면서 여러 구성요소들간에 상호작용 하는 가운데, 각 컴포넌트 범위를 넘어서서 HW, OS, SW, Cloud infra 등의 모든 데이터를 활용해서 어플리케이션 상태부터 시스템 전체의 상태를 확인, 이상감지, 원인 추론까지 하는 것을 포괄하는 개념

 

Observability가 가능하기 위해서는 세 가지 성격의 데이터가 필요

• Trace : 데이터의 흐름에 대한 정보를 파악하기 위한 데이터
  ex) 유저의 구매행동의 정보를 확인하기 위해서 장바구니, 주문, 결제, 배송 서비스 흐름에 대한 데이터가 모두 남겨져 있어야 함
• Log : 이벤트 정보
  ex) 주문이라는 이벤트 안에 있는 내용
• Metric : 일정 기간 걸쳐 측정된 성능, 수치 데이터
  ex) 10대 남자아이가 1주일에 1만원을 쓴다, 1억을 쓴다

 

 

1.2 Observability를 위해 필요한 것

 

1.2.1 운영 데이터의 중요성

많은 개발자들이 단순히 코드를 어떻게 작성하고, 어떻게 배포하는지에만 관심이 있음 

하지만, 모든 시스템은 어떤 기능이나 서비스를 하기 위해 동작하기에, 그 목적을 달성하는지 지속적으로 관찰해야 함

물론 대중적으로 안정적인 기술스택과 인프라를 선택하고, 규모가 적다면 상태를 확인하지 않아도 알아서 잘 돌아간다고 생각할 것임

하지만 그것은 데이터를 확인하지 않았기 때문에 그렇게 판단하는 것

실제로 서버가 죽었거나 배포버전이 다른데도 며칠동안 모르고 운영되는 시스템들이 많음

따라서 코드를 개발하는 것 만큼 운영하면서 데이터로 확인하는 것도 중요하다는 마인드가 있어야 함

 

1.2.2 데이터를 남겨라 

Tracing, Monitoring, Observability 무엇이든 그것을 하려면 데이터가 남아야 함 

데이터가 남아야 상태 확인을 위한 공수가 덜 듦

즉, 데이터가 있어야 분석할 수 있고 자동화를 할 수 있음  

작은 시스템이라도 그 시스템의 개발자가 운영하면서 어떤 데이터가 필요할 지를 고민하고, 그것을 어떤 도구를 통해서든 남기도록 개발이 되어야한다. 

이미 데이터를 수집하는 통합된 환경이 있다면, 그것을 수집할 수 있는 채널(port, path, agent설치 등)을 열어둘 수 있도록 최소한의 설정이 필요함

 

1.2.3 지속적인 데이터 Observability 경험

분명히 이상이 있는데 데이터로 확인이 안 되는 경우가 있기 때문에 데이터를 남겼으면 지속적으로 확인해야 함 

이런 경우 어떤 데이터가 필요한 지 정의하고 추가로 데이터를 남길 수 있도록 개발해야 함

지속적으로 데이터를 남기고 확인하다보면, IT 시스템 전체에 대한 이해가 높아질 뿐만 아니라 문제 해결 과정 또한 빨라짐

한 번 만들어진 통합된 모니터링, 대시보드 등의 환경은 복리적 효과를 가짐

함께 일하는 동료들의 개발, 디버깅 리소스 또한 줄여주기 때문 

 

1.2.4 시스템에 대한 이해

"단순히 observability 합니다." 선언하고 몇 가지 도구만 설치하면 될까?

Observability의 좋은 경험을 위해서는 필요한 데이터가 조회하기 적절한 형태여야 함 

그렇게 위해서는 구축되어있는 IT 시스템, 각 어플리케이션의 내부 구조, 로직, 사용 목적이나 용도에 따라서 데이터를 남겨야 함

결국 그 시스템이 어떻게 구성되어있는지, 어떤 과정으로 기능하는 지를 알아야 어떤 데이터를 확인할 수 있는지 알게 됨

따라서 제대로 된 모니터링, observability를 하려면 사용하는 시스템에 대한 깊은 이해, 데이터에 대한 사용이 같이 이루어져야 함

이것이 어렵다면, 각 시스템마다 모니터링까지 갖추어진 관리형 도구를 비싼 비용을 내면서 쓸 수 밖에 없음

 

 

1.3. 대표적인 Observability 도구들

Observability 도구가 갖춰져야 Observability가 가능하다고 할 수는 없음 

이미 제각기 남기고 있는 데이터로 본능적으로 Observability 활동을 하고있을 수도 있음

여기서 소개하는 도구는 Tracing, Log, Metric 데이터를 남기거나 수집할 수 있는 도구를 갖추고, 통합된 분석 환경을 제공하는 것 기준임

 

1.3.1 Opentelemetry

오픈소스로 만들어지는 통합 Observability 스택

Tracing, Metric, Logs 수집해서 통합된 모니터링, 분석환경을 제공

여러 언어별로 intrument sdk를 제공하고, 여러 인프라 환경(또는 제품)별로 collector 또한 개발되어 있음

전용 OpenTelemetry protocol(OTLP) 프로토콜을 정의해 놓았기 떄문에 이 프로토콜에 맞춰 직접 agent, collector 등을 구현할 수 있음

opentelemetry를 중심으로 통합된 수집, observability 환경을 구성할 수 있음

중견기업 이상의 회사가 Observability 전문 팀으로 전사적인 통합 observability 환경을 구축하고자 할 때 선택하기 가장 좋은 대안

 

1.3.2 Datadog 

cloud에서 운영되는 Observability 제품

AWS, Azure, GCP 등에 쉽게 intergration할 수 있음 

각 언어나 플랫폼 별로 데이터 수집을 위한 agent들도 제공하고 설치가 쉬움

웹, 앱부터 백엔드까지 통합해서 모니터링하고 병목이나 장애지점을 진단할 수 있는 것이 가장 큰 장점

 

1.3.3 Dynatrace

오래전 APM분야부터 시작한 회사

Java Tracing 도구들의 기능이 더 상세하고 성능이 좋은 편

Datadog와 마찬가지로 Full stack observability 를 제공하려 하고 있음

cloud 뿐만 아니라 On-premise 도 부분적으로 제공

 

 

2. 데이터 엔지니어가 모니터링 해야할 대상

 

2.1 host machine

모든 프로그램은 컴퓨터에서 돌아감 

기본적으로 해당 컴퓨터의 상태를 모니터링 할 수 있어야 함

아래 내용은 physical machine, virtual machine, container 환경에 모두 적용됨

• Running 여부
• cpu usage
• memory usage
• disk usage 
• network I/O (IOPS)

 

2.2 OS 상태

개발자가 개발한 프로세스는 자원을 운영체제로부터 할당받아서 사용

운영체제가 가용한 자원이 없다면 내 프로세스가 영향을 받게 됨

반대로 내 프로세스가 운영체제의 자원을 너무 많이 사용하면 다른 프로세스에 영향을 미침

데이터 엔지니어는 분산시스템을 많이 사용하고, 대용량 처리를 위해서 리소스 매니저 등을 사용하기 때문에

OS 상태지표에 대한 관심이 필요

 

지표

• FD(File Descriptor) count
• socket status and count 
• cpu, memory, disk per cgroup (해당 컨테이너당 사용량)

 

2.3 Process/Application 상태

자신이 개발한 프로세스의 상태를 확인할 수 있어야함 

여기에는 이벤트 로그, 메트릭, 트레이스 모두 포함 

아래는 공통적으로 확인할만한 사항

 

지표

• cpu, memory, disk usage of process
• open FD count in process
• 사용하는 프레임워크 레벨에서 진단이 필요한 정보
• 내 어플리케이션 로직이나 상태를 확인하기 위한 정보

 

2.4 인프라 환경 정보

분산 리소스 매니저를 쓴다면, 내 어플리케이션은 해당 인프라에 종속되어있기 때문에 해당 인프라의 환경을 확인할 수 있어야 함 

예를 들어, 내 어플리케이션이 시작되지 못하는 이유가 리소스가 부족해서 일 수 있음 

또는 해당 시스템이 운영체제나 machine과 버전이 안맞거나 crash가 나는 것으로 내 process가 영향 받을 수 있음 

대표적으로 Yarn, kubernetes등이 있음 

이것은 해당 시스템의 아키텍처나 구성요소에 따라서 남아야할 정보가 다름

기본적으로 해당 시스템이 내 프로그램에 할당한 id 정보는 필수로 같이 남아야 함

 

 

해당 포스터는 패스트캠퍼스 <한 번에 끝내는 데이터 엔지니어링 초격자 패키지 Online 강의>를 기반으로 작성되었습니다.