최근 IT 업계에서 마이크로서비스 아키텍처, 클라우드 네이티브와 같은 최신 기술 트렌드가 빠르게 채택되고 있습니다. 그러나 규모가 확장되면서 복잡해진 아키텍처에 대해 사용자들이 어려움을 겪고 있습니다.
여러분은 마이크로서비스, 클라우드 네이티브 환경을 사용하고 계시나요? 서비스 환경에서 워크플로를 인지하고 계시나요? 문제가 발생했을 때, 이를 빠르게 감지하거나 추적하는 게 가능하신가요?
요즘 IT 업계에서는 observability 개념이 주목받고 있는데요. 이는 시스템 외부 출력의 결괏값에서 시스템 내부 상태를 얼마나 잘 추론하는지 나타내는 척도입니다. observability를 지원하는 관련 솔루션도 시중에 여럿 있죠.
observability 솔루션은 조직에서 애플리케이션을 운영할 때, 위 질문에서 언급한 상황을 잘 대응하도록 지원합니다. 이 솔루션은 서비스 환경에서 워크플로를 인지하도록 돕고요. 서비스 운영 과정에서 문제가 생기면 이를 신속히 파악하고, 문제 원인을 추적하도록 지원하죠. 이 글에서는 observability 개념과 관련 도구인 Signoz를 알아보려고 합니다. 아울러 Signoz 기능을 활용한 observability 구현 방안을 살펴보겠습니다.
Observability란?
observability는 Log, Metric, Traces 등의 시스템이 생성하는 데이터 항목을 기반으로 시스템의 현재 상태를 측정하는 기능입니다. 클라우드 네이티브 환경의 마이크로서비스 구조가 확장되면서 복잡해지는 구조를 observability로 보다 쉽게 확인할 수 있습니다. 엔지니어나 운영자는 observability에서 생성된 데이터를 사용해 시스템 동작을 잘 파악하고, 문제를 빠르게 감지할 수 있습니다. 또 애플리케이션 측정 데이터를 활용해 시스템 성능을 최적화할 수 있습니다
SigNoz란?
기존 observability 솔루션에는 Data dog, New Relic 등이 있습니다. 아울러 유료 솔루션은 아니지만 오픈 소스 솔루션을 조합해 observability를 구현한 사례도 있습니다. SigNoz는 observability 솔루션 중 하나로 오픈 소스 형태입니다. 이는 자체 호스팅할 수 있는 환경을 제공하고 있습니다.
SigNoz 공식 문서에서는 이렇게 소개하고 있습니다.
SignNoz는 애플리케이션을 모니터링하고 문제를 해결하는 데
도움이 되는 오픈 소스 애플리케이션 성능 모니터링(APM) 도구입니다.
SigNoz는 분산 추적을 사용하여 소프트웨어 스택에 대한 가시성을 확보합니다.
시스템 아키텍처
- SigNoz Otel Collector : 서비스 및 애플리케이션에서 telemetry 데이터를 수집합니다.
- Clickhouse : 오픈소스 OLAP 데이터베이스 관리 시스템입니다.
- Query Service : Frontend와 Clickhouse 간의 인터페이스입니다.
- Alert Manager : 발생하는 이벤트를 Email, Slack 등으로 전달하는 시스템입니다.
- Frontend : ReactJS 및 TypeScript에 내장된 사용자 인터페이스입니다.
Why Signoz?
SigNoz가 아니라도 다른 observability 솔루션은 존재합니다. 여러 도구 중 SigNoz의 이점은 무엇일까요?
- 단일 도구
기능별 오픈 소스 도구들은 다양하게 존재합니다. 그동안 업계에서는 Grafana + Prometheus의 스택으로 수집한 메트릭을 시각화하고, 마이크로서비스 위에서 동작하는 애플리케이션의 워크플로를 확인하기 위해 Jaeger와 같은 분산 추적 솔루션을 사용하였습니다. 아울러 로그를 수집하고 시각화하기 위한 ELK(Elastic Search, Log Stash, Kibana), EFK(Elastic Search, Fluent Bit, Kibana) 등의 스택을 사용해 왔습니다.
이러한 개별 도구들의 가장 큰 문제점은 유지 관리였습니다. 이는 솔루션 별로 다른 화면으로 존재하여 유지 관리하는데 어려움이 생깁니다. SigNoz는 여러 기능을 하나로 통합해 단일 애플리케이션에서 메트릭을 확인하고, 문제를 추적하며, 로그를 확인할 수 있는 단일 창을 제공합니다. 이로써 앞서 설명드린 유지 관리의 어려움을 해소할 수 있습니다.
- Opentelemetry 및 호환성
SigNoz는 Opentelemetry 표준을 사용하여 다양한 언어 및 프레임워크를 지원합니다. OpenTelemetry를 통해 수집된 메트릭, 로그 등의 데이터를 선택된 백엔드로 export 할 수 있습니다. 아키텍처에서도 설명했듯 백엔드 기능은 SigNoz가 담당합니다. 이외에 SigNoz는 기존에 많이 사용됐던 Grafana Dashboard 데이터를 Import하여 그대로 사용할 수 있습니다. 기존에 사용하던 Grafana를 마이그레이션하기 수월하며 신규 구축 시 대시보드를 구성하는 시간을 단축할 수 있습니다.
- 자체 호스팅
SigNoz는 Datadog, New Relic과는 다르게 자체 호스팅할 수 있는 환경을 제공합니다.
Datadog과 New Relic은 솔루션 에이전트를 인프라에 설치하여 수집된 데이터를 중앙 서버에 보내는 Saas 형태의 호스팅으로 서비스를 제공합니다. 이는 로그 및 메트릭 정보를 외부로 노출할 수 없는 사용자에게는 부담스러운 환경이었습니다. 그러나 SigNoz는 자체 호스팅을 통하여 Private한 환경에서도 무료로 구축하여 사용할 수 있습니다.
SigNoz 기능
SigNoz의 기능에서 Services, Traces, Logs, DashBoards, Alerts 5가지 기능을 소개해 드리겠습니다.
Services
Services에서는 애플리케이션 메트릭 정보를 확인할 수 있습니다.
SigNoz는 기본적으로 signoz-otel-collector를 통해 각 애플리케이션의 데이터를 수집하여 제공합니다.
각 애플리케이션의 정보를 수집하기 위해 언어/프레임워크별 설정을 사전에 진행하여야 합니다.
제공하는 애플리케이션 메트릭 정보는 다음과 같습니다
- P99 latency(in ms) : 애플리케이션이 가장 빠른 99%의 요청을 각각 처리하는 데 소비하는 시간입니다. 예를 들어 대기 시간 값이
P99 760ms이면 **'요청의 99%는 760ms와 같거나 더 빠른 응답이 가능하다'**는 의미입니다. - Error Rate(% of total) : 실패한 request의 백분율, 총 요청에 대한 오류 요청의 비율입니다.
- Operations Per Second : 애플리케이션이 초당 처리하는 request 수입니다.
각 지표를 통해 시스템의 성능, 처리 능력 측정이 수월해지고 Error rate를 기반으로 오류 원인을 감지하고 해결할 수 있습니다.
실제 각 애플리케이션의 상세 페이지를 들어가 보면 다음과 같은 탭으로 구성된 대시보드를 확인할 수 있습니다.
- Application Metrics
- External Calls
- Database Calls
Traces
Traces 항목에서는 앞서 Services에서 측정된 애플리케이션의 데이터를 기반으로 분산 추적 데이터 및 일련의 Span을 구성합니다. 각각의 Span은 시스템에서 발생하는 작업 일부분을 나타내며, Span 간의 관계를 통해서 요청의 전체적인 흐름을 파악할 수 있습니다.
분산 추적의 단일 추적은 **‘범위’**라고 하는 일련의 태그가 지정된 시간 간격으로 구성됩니다. Span은 그 안에서 사용자 요청 및 트랜잭션을 완료하는 작업의 논리적 단위입니다.
하나의 요청을 선택하면 해당 Trace와 관련된 범위에 데이터를 flame graph 형태로 출력합니다.
- Trace ID: 페이지 상단에 SignNoz는 현재 선택된 추적의 ID를 표시합니다.
- Time: 선택한 Trace의 시작 시각과 기간을 표시합니다.
- Focus: 특정 Span을 Focus하여 해당 Span 정보만을 출력합니다.
- Main Content Area: 모든 Span을 트리 구조로 표시합니다. 트리의 개별 노드를 확장하거나 축소하여 하위 노드를 표시하거나 숨길 수 있습니다. SigNoz는 각 노드에 하위 노드의 수를 표시합니다.
- Span Details: 페이지 우측에 선택한 Span의 상세 정보를 출력합니다.
Logs
SigNoz는 Open Telemetry를 통해 수집된 데이터를 Clickhouse에 저장하기 위해 OTLP 형식으로 데이터를 처리하고 전송합니다. Signoz Opentelemetry-collector가 수신하는 방식은 다음과 같습니다.
- OTLP Receiver - 이 Receiver는 지정된 포트에서 OTLP 프로토콜을 통해 로그를 받습니다. OTEL SDK를 사용하는 모든 라이브러리는 이 프로토콜에 로그를 전달할 수 있습니다. 이 프로토콜은 OTEL 수집기가 다른 OTEL 수집기로 로그를 전달해야 할 때도 사용됩니다.
- Filelog Receiver - 이 Receiver는 로그가 포함된 파일을 추적하고 분석할 수 있습니다.
- Fluent Forward Receiver - 이 Receiver는 Fluent Forward Protocol을 통해 이벤트를 수락하는 TCP 서버를 실행합니다. FluentD 및 FluentBit는 이 수신기에 로그를 전달할 수 있습니다.
- TCP 수신기 - 이 Receiver는 로그를 수신할 수 있는 TCP 서버를 실행합니다.
- UDP 수신기 - 이 Receiver는 로그를 수신할 수 있는 UDP 서버를 실행합니다.
- Syslog 수신기 - 이 Receiver는 TCP 및 UDP를 통해 수신된 syslog를 구문 분석합니다.
필드
생성되는 로그들의 필드가 로그 대시보드 좌측에 출력됩니다. 이때 원하는 필드를 선택하여 추가하면, 선택한 필드의 로그들이 출력되어 나타납니다.
필터링 검색
페이지 상단 “Search Filter”를 선택하여 로그 대시보드 좌측에서 추가했던 필드를 기반으로 해당 필드에서 원하는 데이터를 검색하여 로그를 출력할 수 있습니다.
Dashboard
수집된 메트릭 정보를 바탕으로 대시보드를 생성하고 보여줍니다.
대시보드 및 패널을 설정할 수 있고 Query에 해당하는 메트릭이 존재하면 출력합니다.
현재는 Beta 버전으로 적용되었지만 v0.11.3 버전에서 Grafana의 대시보드를 Import 할 수 있는 기능이 추가되었습니다. 대시보드가 추가된 이후 PromQL에 일치하는 데이터가 있으면 이를 출력합니다.
Alert
Signoz에서는 쿼리를 작성하여 Alert를 합니다. 쿼리는 다음 3가지의 규칙으로 작성됩니다.
- Query Builder : 드롭다운에서 메트릭을 선택하여 알림을 작성하는 DIY 방식입니다. 대시보드에서 옵션을 선택하여 조건별로 필터 및 그룹화를 설정할 수도 있습니다.
- PromQL : Prometheus 쿼리 언어를 사용하여 정기적인 시간 간격으로 평가될 경고에 대한 표현식을 작성할 수 있습니다. Prometheus에서 알림을 설정했다면 이 방법이 매우 익숙할 것입니다.
- Clickhouse Queries : SigNoz 데이터 모델 및 형식을 준수하는 Clickhouse 쿼리를 작성할 수 있습니다. 쿼리 결과는 경고 임계 조건을 평가하는 데 사용됩니다. 또한 쿼리 결과를 사용하여 레이블 및 주석을 생성할 수 있습니다.
Query를 작성하기 이전에 Alert를 전송할 채널을 정의하여야 합니다.
“Settings - Alert Channels - New Alert Channel” 을 통해 신규로 추가될 Alert 채널을 정의합니다.
Slack의 경우 Incoming Hook 설정을 활성화하고, 생성된 Webhook URL을 해당 탭에 설정하면 됩니다.
정상적으로 Hook이 연결되었는지 확인하기 위해 하단 “Test” 버튼을 클릭하면 Webhook URL에 설정된 Slack 채널에서 알림을 받아볼 수 있습니다.
맺음말
지금까지 observability와 SigNoz를 알아보았습니다. SigNoz를 도입하면 시스템의 observability를 간편하게 적용할 수 있습니다. SigNoz를 도입하면 여러 관리 포인트의 콘텍스트 스위칭 부담을 줄일 수 있습니다. 이는 실제 시스템을 더 잘 파악하고 시스템을 최적화하는 데 많은 도움이 될 것입니다.
인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다.
GitLab(Omnibus/Cloud Native Hybrid) 구축 관련한 지원이 필요하시면 문의하기 로 연락 주십시오.