Observability
Tracing
프로그램의 실행 과정을 상세히 남기는 것
- 호출하는 메소드의 시작 시간과 끝 시간을 남겨서 걸린 시간을 계산할 수 있게 하는 것.
- 에러 발생시 Stacktrace
- Network ping의 Router trip 경로 (거치는 라우터들의 순서)
오래전부터 APM(Application Performance Monitoring)이라는 분야에서 Tracing을 활용했고 여러 기술과 제품들이 있다. Java byte code instrumentation 도 APM 분야에서 가장 많이 사용한다.
과거에는 하나의 머신, 또는 하나의 어플리케이션에 대한 선능 지표를 수집하고 분석하는 것이 역할이었다. 현대에는 API, Microservice 등으로 하나의 어플리케이션이나 서비스가 구동되기 위해서는 여러가지 인프라와 어플리케이션이 상호작용하기 때문에 Distributed Tracing이 중요해지고 있다.
- 대표적인 Distribuite Tracing 오픈소스로는 Zipkin 과 Jaeger가 있다.
Tracing 정보는 상세히 남길수록 어플리케이션이나 시스템에 부하를 주거나, 데이터를 많이 사용하게 되므로 무분별하게 남기면 안된다.
Monitoring
에러, 다운타임, 비정상 상태등을 감지하기 위해서 이벤트, 메트릭 정보들을 남기고 추적하는 것을 말한다. 모니터링 방식은 크게 메트릭 모니터링과 로그 모니터링으로 나눌 수 있다.
Metric Monitoring
- 특정 기간이나 범위의 성공/실패 상태를 모니터링
- 목표치 대비 성능의 상태나 관계를 모니터링
- Memory Use, Request per Second, Active Connections, Flow, Or Number of Errors(지표들)
Log Monitoring
- 관심 있는 이벤트 데이터를 남기고 내용을 살피는 방식.
- 이벤트 데이터를 분석
- filter -> aggregation -> metric
- 텍스트 검색, 필터 검색
Observability
최초에는 시스템의 내부 상태에 대해서 직접 들어가서 확인하는 것이 아니라, 쌓여있는 데이터를 연결하고 추론해서 확인할 수 있게 한다는 개념으로 쓰였다. 최근에는 IT시스템이 복잡해지면서 여러 구성요소들간에 상호작용 하는 가운데, 각 컴포넌트의 범위를 넘어서서 HW, OS, SW, Cloud infra 등의 모든 데이터를 활용하여 어플리케이션의 상태부터 시스템 전체의 상태를 확인, 이상감지, 원인 추론까지 하는 것을 포괄하는 개념으로 쓰이고 있다.
- Trace: 데이터의 흐름에 대한 정보를 파악하기 위한 데이터
- Log: 이벤트 정보
- Metric: 일정 기간 걸쳐 측정된 성능, 수치 데이터
Observability를 위해 필요한 것
1. 운영 데이터의 중요성
많은 개발자들이 단순히 코드를 어떻게 작성하고, 어떻게 배포하는 지에만 관심이 있다. 하지만, 모든 시스템은 어떤 기능이나 서비스를 하기 위해서 동작하고, 그렇다면 그 목적을 달성하는 지를 지속적으로 관찰할 필요가 있다.
물론 대중적으로 안정적인 기술스택과 인프라를 선택하고, 규모가 적다면 상태를 확인하지 않아도 어느정도는 알아서 잘 돌아간다고 생각할 것이다. 하지만, 그것은 데이터를 확인하지 않아서 모르기 때문에 그렇게 생각하는 경우가 많다. 실제로는 서버가 죽었는데도, 아니면 배포버전이 다른데도 며칠 동안 모르고 운영되는 시스템들이 많다.
코드를 개발하는 것 만큼이나 운영하면서 데이터로 확인하는 것도 중요하다는 마인드가 있어야 한다.
2. 데이터를 남겨라
Tracing, Monitoring, Observability 무엇이든 그것을 하려면 데이터가 남아야 확인할 수 있다. 데이터가 남아야 상태 확인을 위한 공수가 덜 든다. 데이터가 있어야 분석할 수 있고, 데이터가 남아야 자동화를 할 수 있다.
작은 시스템이라도 그 시스템의 개발자가 운영하면서 어떤 데이터가 필요할지를 고민하고, 그것을 어떤 도구를 통해서든 남기도록 개발이 되어야 한다.
이미 데이터를 수집하는 통합된 시스템이 있다면, 그것에서 수집할 수 있는 채널(port, path, agent 설치 등)을 열어 둘 수 있도록 최소한의 설정이 필요하다.
3. 지속적인 데이터 Observability 경험
데이터를 남겼으면 지속적으로 확인해야한다. 분명히 이상이 있는데 데이터로 확인이 안되는 경우가 있다. 이런 경우에 어떤 데이터가 필요한지 정의하고 추가로 데이터를 남길 수 있도록 개발해야 한다. 지속적으로 데이터를 남기고 확인하다 보면, IT 시스템 전체에 대한 이해가 높아질 뿐만 아니라 문제 해결과정 또한 빨라진다.
한 번 만들어진 통합된 모니터링, 대시보드 등의 환경은 복리적인 효과를 갖는다. 함께 일하는 동료들의 개발, 디버깅 리소스 또한 줄여주기 때문이다. Observability에 대한 좋은 경험을 가진 개발자는 지속적으로 좋은 시스템을 만들 수 밖에 없다. Observability를 등한시한 개발자는 언제 생길지 모르는 에러나 장애에 매일 불안에 떨며 잠을 자게 된다.
4. 시스템에 대한 이해
단순히 Observability 합니다. 선언하고 몇가지 도구만 설치하면 될까?
Observability의 좋은 경험을 위해서는 필요한 데이터가, 조회하기 적절한 형태로 남아야 한다. 그렇기 위해서는 구축되어있는 IT 시스템, 각 어플리케이션의 내부 구조, 로직, 사용 목적이나 용도에 따라서 데이터를 남겨야 한다. 결국 그 시스템이 어떻게 구성되어있는지 어떤 과정으로 기능하는 지를 알아야 어떤 데이터를 확인할 수 있는 지 알게 된다.
따라서 제대로 된 모니터링, Observability를 하려면 사용하는 시스템에 대한 조금 더 높은 이해, 데이터에 대한 사용이 같이 이루어 질 수 밖에 없다.
이것이 어렵다면, 각 시스템마다 모니터링까지 갖추어진 관리형 도구를 비싼 비용을 내면서 쓸 수 밖에 없다.
대표적인 Observability 도구들
1. Opentelemetry
오픈 소스로 만들어지는 통합 Observability 스택이다.
Tracing, Metric, Logs 수집해서 통합된 모니터링, 분석 환경을 제공한다. 여러 언어별로 Instrument SDK를 제공하고, 여러 인프라 환경(또는 제품)별로 Collector 또한 개발되어 있다.
전용 OpenTelemetry Protocol(OTLP) 프로토콜을 정의해 놓았다. 이 프로토콜에 맞추어 직접 agent, collector등을 구현할 수 있다. Opentelemetry 를 중심으로 통합된 수집, Observability 환경을 구성할 수 있다. 중견기업 이상의 회사가 Observability 전문 팀으로 전사적인 통합 Observability 환경을 구축하고자 할 때 선택하기 가장 좋은 대안이다.
2. Datadog
Cloud에서 운영되는 툴이다. AWS, Azure, GCP 등에 쉽게 Integration 할 수 있다. 각 언어나 플랫폼 별로 데이터 수집을 위한 agent들도 제공하고 설치도 쉽다. 웹, 앱부터 백엔드까지 통합해서 모니터링 하고 병목이나 장애지점을 진단할 수 있는 것이 큰 장점이다.
3. Dynatrace
오래전 APM 분야부터 시작한 회사이다. Java Tracing 도구들의 기능이 더 상세하고 성능이 좋은 편이다. Datadog와 마찬가지로 Full Stack Observability를 제공하거나 제공하려고 하고 있다. Cloud 뿐만 아니라 On-premise도 부분적으로 제공한다.
데이터 엔지니어가 모니터링 해야할 대상
Host Machine
모든 프로그램은 컴퓨터에서 돌아간다. 기본적으로 해당 컴퓨터의 상태를 모니터링 할 수 있어야 한다. 아래 내용은 Physical Machine, Virtual Machine, Container 환경에 모두 적용 된다.
- running 여부
- CPU Usage
- Memory Usage
- Disk Usage
- Network I/O (IOPS)
OS Status
개발자가 개발한 프로세스는 자원을 운영체제로 부터 할당받아서 사용한다. 운영체제가 가용한 자원이 없다면 내 프로세스가 영향을 받는다. 반대로 내 프로세스가 운영체제의 자원을 너무 많이 사용하면, 다른 프로세스에 영향을 미친다.
데이터 엔지니어는 분산시스템을 많이 사용하고, 대용량 처리를 위해서 리소스 매니저 등을 사용하기 때문에 OS 상태지표에 대한 관심이 필요하다.
Metric
- FD Count (File Discriptor Count)
- Socket Status and Count
- CPU, Memory, Disk per cgroup(container group (Docker, Kubernetes ...))
Process/Application 상태
자신이 개발한 프로세스의 상태를 확인할 수 있어야 한다. 여기에는 이벤트 로그, 메트릭, 트레이스 모두 포함된다. 아래는 공통적으로 확인할만한 사항
Metric
- CPU, Memory, Disk Usage of Process
- Open FD Count in Process
- 사용하는 프레임워크 레벨에서 진단이 필요한 정보
- 내 어플리케이션의 로직이나 상태를 확인하기 위한 정보
인프라 환경 정보
분산 리소스 매니저를 쓴다면, 내 어플리케이션은 해당 인프라에 종속되어있기 때문에 해당 인프라의 환경을 확인할 수 있어야 한다.
예를 들어, 내 어플리케이션이 시작되지 못하는 이유가 리소스가 부족해서 일 수 있다. 또는 해당 시스템이 운영체제나 machine과 버전이 안맞거나 Crash가 나는 것으로 내 Process가 영향 받을 수도 있다.
대표적으로 Yarn, Kubernetes 등이 있다. 이것은 해당 시스템의 아키텍처나 구성요소에 따라서 남아야 할 정보가 다르다.
기본적으로는 해당 시스템이 내 프로그램에 할당한 ID 정보는 필수로 같이 남아야 한다.
