fromm의 OpenTelemetry 도입 여정

안녕하세요. 노머스에서 fromm 백엔드 개발을 하고 있는 김연태입니다.

백엔드 팀에서 느낀 CloudWatch의 한계와 OpenTelemetry의 도입

fromm의 백엔드는 ECS와 Lambda에서 동작하는 nest.js 어플리케이션으로 이루어져 있습니다. 그리고 기존 백엔드 시스템의 모니터링은 AWS CloudWatch로 하고 있었습니다. CloudWatch를 통한 모니터링은 어플리케이션 배포시 메트릭과 로그를 설정의 어려움 없이 수집할 수 있다는 점, exporter 와 collector 등 추가적인 인프라 구성 및 관리부담이 없다는 점 등이 장점이라 잘 활용하고 있었습니다. 그러나 앱의 규모가 커지고 단순한 모니터링에서 observability 확보의 필요성이 생기며 다음과 같은 CloudWatch의 한계가 느껴지기 시작했습니다.

커스텀 메트릭의 부족

CloudWatch에서 제공되는 Lambda function 단위의 API Count, Latency 등의 메트릭으로 function 전체 상태를 모니터링 할 수는 있지만, API Path별로 Count, Error, Latency 등을 측정하려면 custom metric을 직접 만들어야 합니다. 이 경우 log를 기반으로 필요한 custom metric을 하나하나 설정해야 할 뿐만 아니라 추가 비용까지 부담해야 했습니다.

분산 트레이싱 미지원

앱의 규모가 커지고 여러 서비스가 추가됨에 따라 서비스간 internal call이 많아졌습니다. 하나의 요청을 따라가며 어디에서 어떤 문제가 발생했고 어느정도의 영향을 미치고 있는지 흐름을 파악할 필요성이 느껴졌습니다.

Metric Resolution의 한계

CloudWatch에서 제공되는 메트릭은 기본적으로 1분단위의 Standard Resolution을 제공하며 기간이 길어질수록 해상도는 더욱 떨어집니다. fromm의 트래픽 양상을 파악해보니 1분 Count로 잡힌 진입 트래픽의 50% 이상이 초기 5~10초 내에 발생한다는 것을 알게 되었고 따라서 1초, 5초, 10초 단위의 High Resolution이 반드시 필요했습니다.

로그의 지연

CloudWatch의 Log Insight의 경우 어플리케이션 로그가 인입되기까지 1~2분 정도의 지연이 발생합니다. Live Tail을 사용할 경우 실시간 로그를 확인할 수 있지만 ECS서비스 뿐만 아니라 Lambda의 개수가 많아 log group의 개수 또한 많아졌고 장애가 발생한 상황에서 이를 전부 Live Tail로 확인하기는 어려웠습니다. 필요한 때에 적절한 로그를 바로바로 검색할 필요가 있었습니다.

위와 같은 이유로 CloudWatch에서 벗어나 다른 방법으로 observability를 확보하고자 했습니다. 이를 위해 Datadog, Splunk, Whatap 등 다양한 상용솔루션, LGTM 스택, OpenTelemetry 등의 모니터링 툴의 사용을 검토했습니다. 여러 방법들을 검토하며 하나를 선택하기 위한 기준은 다음과 같았습니다.

1. API별 Latency, Count, Saturation 등 필요한 Metric을 고해상도로 수집할 수 있을 것.
2. 여러 서비스들에 걸친 이벤트의 분산 추적이 가능할 것.
3. 실시간에 가까운 로그의 수집과 간편한 검색이 가능할 것.
4. ECS 뿐만 아니라 Lambda에서도 동일한 모니터링이 가능할 것.
5. 운영에 과도한 시간 및 비용이 들어가지 않을 것.

Datadog 및 Splunk 의 경우 위의 조건들을 대부분 만족할 수 있는 강력한 솔루션이었지만 이를 도입하게 되면 현재 인프라 비용과 맞먹는 추가비용을 지불해야만 했습니다. Whatap의 경우 ECS, RDS에 있어선 좋은 기능을 제공하면서도 가격이 비교적 저렴했지만 Lambda의 모니터링은 불가능해 저희가 사용하기엔 어렵다는 판단이 들었고 LGTM 의 경우 DevOps 팀 없이 백엔드팀에서 직접 도입해서 사용하기엔 운영난이도가 너무 높고 스케일이 크다고 판단하였습니다. 따라서 저희는 OpenTelemetry 로 Metric, Trace, Log 를 수집하고 Self-Hosted SigNoz를 사용해 시각화하는 방법으로 저희가 생각하는 기능을 전부 만족할 수 있다고 생각했습니다.

OpenTelemetry란

OpenTelemetry는 코드를 계측하고 telemetry data를 observability backend로 내보내는 표준이 없는 문제를 해결하기 위해 OpenTracing과 OpenCensus라는 프로젝트가 합쳐져 만들어진 CNCF 프로젝트입니다. 따라서 OpenTelemetry를 통해 계측되는 traces, metrics, logs 등 telemetry data 는 표준화된 data 프로토콜인 OTLP로 export 되며 벤더의 종속성을 가지지 않습니다. Observability backend로 Prometheus, Grafana, Jaeger, Datadog, SigNoz 등 다양한 솔루션을 선택할 수 있으므로 추후 필요성이 좀더 커지게 되었을때 SigNoz만 교체해 다른 백엔드를 사용할 수 있다는 것도 저희에겐 큰 매력으로 다가왔습니다.

OpenTelemetry는 Agent, API, SDK 등의 형태로 WAS의 telemetry data를 생성하고 이 데이터를 Collector로 전송해 Collector가 데이터 프로세싱 후 외부 백엔드로 전송하는 아키텍쳐를 가지고 있습니다.

이때 OpenTelemetry Collector를 좀더 상세히 살펴보면 Receivers, Processors, Exporters 로 구성되어 있습니다. 각각의 구성요소들은 다음과 같은 역할을 합니다.

Receivers

• OTLP, Jaeger, Zipkin 등 push-based protocol 지원해 application이 collector로 데이터 전송
  • 이때 OTLP는 HTTP, gRPC 모두 사용가능
• Prometheus 등 pull-based protocol 지원해 collector가 직접 데이터 스크래핑 가능

Processors

• Batch : 효율적인 전송을 위해 데이터를 묶음
• Filter : 관련 없는 데이터 제거
• Normalization : 데이터 형식 변환, 표준화
• Attributes : 메타데이터 주석 처리
• Sampling : 데이터 샘플링을 통한 양 조절
• Memory Limiter : 리소스 사용 제한 및 과부하 방지

Exporters

• 백엔드 시스템으로 데이터 전송
• 전송 실패 시 재시도 로직 제공
• 여러 백엔드간 로드밸런싱

뿐만 아니라 Collector의 헬스체크, 인증 및 권한관리 등 기능을 확장할 수 있는 extension도 제공됩니다.

Collector의 receivers, processors, exporters 설정은 다음과 같은 OpenTelemetry Collector YAML 을 통해 구성할 수 있습니다.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:

exporters:
  otlp:
    endpoint: otelcol:4317

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

nest.js에서 OpenTelemetry client 사용

저희가 선택한 SigNoz에서는 telemetry data를 시각화할 수 있는 frontend, 저장하는 time series database인 ClickHouse, OpenTelemetry collector 까지 ZooKeeper로 관리해줘 백엔드에 신경을 많이 쓰지 않고도 OpenTelemetry client 설정만으로 초기 도입을 쉽게 할 수 있었습니다. 여기에서 nest.js application에서 OpenTelemetry client를 어떻게 설정하고 사용할 수 있는지 알아보겠습니다.

Automatic Instrumentation을 통한 OpenTelemetry 설정

먼저 OpenTelemetry에서 제공하는 auto instrumentation을 통해 최소한의 코드로 기본적인 metrics, traces, logs 를 수집해보도록 하겠습니다.

1. OpenTelemetry packages 설치

npm install --save @OpenTelemetry/api 
npm install --save @OpenTelemetry/sdk-node
npm install --save @OpenTelemetry/auto-instrumentations-node
npm install --save @OpenTelemetry/exporter-trace-otlp-http

2. tracer.ts 파일 설정

import { getNodeAutoInstrumentations } from '@OpenTelemetry/auto-instrumentations-node';
import { Resource } from '@OpenTelemetry/resources';
import * as OpenTelemetry from '@OpenTelemetry/sdk-node';
import { SemanticResourceAttributes } from '@OpenTelemetry/semantic-conventions';
import dotenv from 'dotenv';

dotenv.config();

// For Debug
// import { diag, DiagConsoleLogger, DiagLogLevel } from '@OpenTelemetry/api';
// diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.ALL);

const exporterOptions = { 
    url: 'OTEL Collector URL', 
    };

const traceExporter = new OTLPTraceExporter(exporterOptions);

const sdk = new OpenTelemetry.NodeSDK({
    traceExporter,
    instrumentations: [
        getNodeAutoInstrumentations({
            '@OpenTelemetry/instrumentation-fs': {
                enabled: false
            }
        })
    ],
    resource: new Resource({
        [SemanticResourceAttributes.SERVICE_NAME]: 'Service Name'
        [SemanticResourceAttributes.DEPLOYMENT_ENVIRONMENT]: process.env.stage
    })
});

process.on('SIGTERM', () => {
    sdk.shutdown()
        .then(() => console.log('Tracing terminated'))
        .catch(error => console.log('Error terminating tracing', error))
        .finally(() => process.exit(0));
});

export default sdk;

3. main.ts 에서 tracer 시작

// eslint-disable-next-line import/order
import tracer from './tracer';

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
    // tracer를 가장 먼저 시작
    await tracer.start();
    
    const app = await NestFactory.create(AppModule);
    
    // nest.js app config
    // ...
    
    await app.listen(3000);
}

bootstrap();

이때 tracer는 반드시 application의 메인 파일 (ex. main.ts)의 최상단에 import 시켜야 합니다. 따라서 lint의 영향을 받지 않도록 import/order를 해당라인은 무시하도록 eslint-disable-next-line import/order 를 사용합니다.

Custom Metrics 수집

다음으로는 OpenTelemetry를 통해 Custom Metrics를 수집하는 방법을 알아보도록 하겠습니다.

1. MetricsService 생성

import { Injectable } from '@nestjs/common';
import { metrics, Meter } from '@OpenTelemetry/api';

@Injectable()
export class MetricsService {
    private meter: Meter;
    private requestCounter;
    private requestDurationHistogram;
    private activeUsersGauge;

    constructor() {
        this.meter = metrics.getMeter('nestjs-application');

        // Counter Metric 예시
        this.requestCounter = this.meter.createCounter('app.request.count', {
            description: 'API Count'
        });

        // Histogram Metric 예시
        this.requestDurationHistogram = this.meter.createHistogram('app.request.duration', {
            description: 'latency (ms)',
            unit: 'ms'
        });

        // Gague Metric 예시
        this.activeUsersGauge = this.meter.createObservableGauge('app.active_users', {
            description: 'Active Users Gauge'
        });

        // active user 메트릭 등록
        let activeUsers = 0;
        this.meter.createObservableGauge('app.active_users', {
            description: 'Active Users Gauge',
            callback: observableResult => {
                observableResult.observe(activeUsers);
            }
        });

        // active user 업데이트
        this.updateActiveUsers = (count: number) => {
            activeUsers = count;
        };
    }

    // API Count 증가
    incrementRequestCount(endpoint: string, method: string, statusCode: number) {
        this.requestCounter.add(1, {
            endpoint,
            method,
            statusCode: statusCode.toString()
        });
    }

    // API Latency 기록
    recordRequestDuration(endpoint: string, method: string, durationMs: number) {
        this.requestDurationHistogram.record(durationMs, {
            endpoint,
            method
        });
    }

    // 활성 사용자 수 업데이트
    updateActiveUsers: (count: number) => void;
}

2. MetricsMiddleware 생성

import { MetricsService } from './metrics.service';

export class MetricsMiddleware {
    constructor(private metricsService: MetricsService) {}

    use(req, res, next) {
        const startTime = Date.now();
        const endpoint = req.path;
        const method = req.method;

        // 기존 응답 end 메서드 저장
        const originalEnd = res.end;

        // 응답 end 메서드 오버라이드
        res.end = function (...args) {
            const duration = Date.now() - startTime;
            const statusCode = res.statusCode;

            // 메트릭 기록
            this.metricsService.incrementRequestCount(endpoint, method, statusCode);
            this.metricsService.recordRequestDuration(endpoint, method, duration);

            // 원래 end 메서드 호출
            return originalEnd.apply(res, args);
        }.bind({ metricsService: this.metricsService });

        next();
    }
}

3. app.module에 service 및 middleware 등록

import { Module } from '@nestjs/common';
import { MetricsService } from './metrics.service';
import { MetricsMiddleware } from './metrics.middleware'
import { AppController } from './app.controller';

@Module({
    imports: [],
    controllers: [AppController],
    providers: [MetricsService],
})

export class AppModule implements NestModule {
    configure(consumer: MiddlewareConsumer) { consumer.apply(MetricsMiddleware).forRoutes('*'); }
}

위와 같은 방법으로 모든 API call에 대해 API Count, API Latency, Active User Count 를 측정할 수 있습니다. 뿐만 아니라 MetricsService 에 따로 측정할 custom metric을 추가하고 controller 혹은 service 레벨에서 해당 metric을 증가시키는 방법으로 특정 API에만 따로 metric을 수집할 수 있습니다.

마치며

이번 글에서는 fromm 백엔드 팀에서 observability 확보를 위해 CloudWatch를 벗어나 OpenTelemetry를 도입하기까지의 여정을 함께 살펴보았습니다. 다음 글에서는 ECS, K8S 환경 등 일반적인 container 환경과는 조금 다른 설정을 해주어야 하는 Lambda에서 OpenTelemetry를 도입하는 방법에 대해 알아보도록 하겠습니다.

끝까지 읽어주신 모든분께 감사드립니다🙇‍♂️

참고자료

• OpenTelemetry Docs
• SigNoz Docs
• OpenTelemetry Architecture - Understanding the design concepts
• GCP - Collect OpenTelemetry Protocol (OTLP) metrics and traces