[Project] 프로젝트 삽질기62 (feat sentry 잘 활용하기)

들어가며

서버에 에러가 발생했을 때, 고객이 어떤 문제를 겪는지 빠르게 파악하고 싶어서 Sentry 환경을 구축했습니다. Sentry의 기본 기능만 활용하면서 Sentry를 보다 잘 활용한다면, 에러 핸들링을 조금 더 잘할 수 있지 않을까 싶어서 Sentry 활용 방법을 바꿨는데요. Sentry를 보다 잘 사용하기 위해 삽질한 내용을 공유하고자 글을 씁니다.

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

기존 Sentry 활용

서버에서 발생하고 있는 에러를 탐지하기 위해 nest-raven 라이브러리를 활용해서 sentry를 활용했습니다.

 

import { Module } from '@nestjs/common';
import { APP_INTERCEPTOR } from '@nestjs/core';
import { RavenInterceptor } from 'nest-raven';

@Module({
  providers: [
    { provide: APP_INTERCEPTOR, useValue: new RavenInterceptor() },
  ],
})
export class SentryModule {}

 

 

위와 같이 SentryModule을 생성해서, SentryModule을 AppModule에 import 하는 식으로 Sentry 활용 환경을 구성했습니다. 그리고 서버에서 에러가 발생하면, Slack에 메시지를 전달할 수 있도록 환경을 구성함으로써 서버의 문제를 빠르게 해결할 수 있는 환경을 구축했습니다.

 

 

[Project] 프로젝트 삽질기24 (feat Sentry Slack 연동)

 

 

 

이렇게 Sentry를 설정하고 활용하면서 몇 가지 문제점을 발견할 수 있었습니다.

 

 

 

 

 

 

---

 

 

 

 

 

 

 

문제 상황

서버에서 에러가 발생하면 Sentry에서 에러를 모두 확인할 수 있었습니다. 그러다 보니 몇 가지 문제가 발생했는데요.

 

첫 번째 문제는 에러 이벤트가 너무 많이 쌓이는 문제가 있었습니다. 서버에서 발생하는 모든 에러 정보를 Sentry에 전달했기 때문에, 서버에서 예외를 발생시킨 로직들도 모두 에러 이벤트로 저장하고 있었습니다. 에러가 발생했으면 왜 에러가 발생했는지 디버깅하기 위해 Sentry를 사용했는데, 디버깅할 필요가 없는 에러 이벤트들도 Sentry에 쌓이다 보니 정말 팀에서 어떤 에러를 먼저 해결해야 하는지 파악하기 어려운 문제가 있었습니다.

 

 

두 번째 문제는 에러 이벤트를 확인했을 때, 그래서 어떤 유저가 어떤 에러를 겪었는지 정확하게 파악할 수 없는 문제가 있었습니다. 에러가 나오더라도 정확히 어떤 유저가 에러를 겪었는지를 명확하게 파악해야 디테일하게 디버깅을 할 수 있는데, 지금 상태로는 디버깅을 보다 명확하게 할 수 없다는 문제가 있었습니다. 

 

 

출처: Sentry 공식 홈페이지

 

 

세 번째 문제는 에러 이벤트를 계속 Sentry에 적재하는 과정에서 추가 비용이 발생했습니다. 사용자가 늘어나고, 트래픽이 늘어나면서 API를 많이 호출할수록 Sentry로 전달되는 이벤트도 많아졌습니다. 그래서 Sentry에 추가적으로 이벤트를 전달하려면 추가 비용이 발생되는 문제가 생겼습니다. 

 

문제 상황을 겪으며, Sentry를 어떻게 하면 더 잘 활용할 수 있을까 고민했습니다. 

 

 

 

 

 

 

 

---

 

 

 

 

 

로깅을 위한 데이터 적재

Sentry를 보다 잘 활용하기 위기 위해 예상하지 못한 외부 요인에 의해 에러가 발생하거나, 런타임에서 에러가 발생할 경우만 Sentry에 이벤트를 전달하기로 결정했습니다. 그리고 Sentry에 이벤트를 전달할 때 디버깅에 필요한 userId와 같은 추가적인 데이터가 함께 전달되도록 구성한다면 디버깅 환경을 개선할 수 있다고 판단했습니다. 이렇게 변경된다면 결과적으로 Sentry에 전처럼 많은 이벤트가 전달되지 않으면서 디버깅에 필요한 데이터를 추가할 수 있기 때문에 보다 효율적으로 디버깅을 할 수 있고, 비용적인 문제도 함께 해결할 수 있을 것이라 판단했습니다. 

 

 

 

출처: Sentry를 이용한 에러 추적기, React의 선언적 에러 처리 / if(kakao)2022

 

 

Sentry를 자세히 알아보니, 이벤트를 전달할 때 Scopes, Transaction Name, Context, Issue, Level, Tags 등의 풍부한 데이터를 추가할 수 있었습니다. 이 중에서, 디버깅할 때 필요한 정보들은 무엇인지 고민했고, 추가 정보를 Sentry에 전달했습니다. 그 과정에서 어떤 작업을 추가로 진행했는지 공유드리겠습니다.

 

 

 

1. Scope 활용

Sentry에서는 전달받은 에러 이벤트 정보와 Scope라는 단위로 전달한 데이터를 병합해서 에러 이벤트를 구성합니다. Scope는 configureScope와 withScope로 나눠서 설정할 수 있었습니다. Scope 단위를 어떻게 구성할 수 있는지는 아래 링크에서 자세히 확인할 수 있습니다.

 

Sentry로 우아하게 프론트엔드 에러 추적하기 | 카카오페이 기술 블로그

 

 

개인적으론 userId는 이벤트 전송에 있어 공통적으로 사용되는 정보였기 때문에, configureScope로 구성해서 전달했습니다.

 

 Sentry.configureScope((scope: Sentry.Scope) => {
      scope.setUser({
        id: userId,
      });
    });

 

 

위처럼 이벤트를 Sentry에 전달하면 아래처럼 USERS에 어떤 유저가 문제를 겪는지 파악할 수 있고, 에러 이벤트 상세 조회를 했을 때 어떤 유저가 에러를 겪는지 확인이 가능합니다.

 

 

 

 

2. Context 활용

userId를 추가함으로써 어떤 유저가 에러를 겪고 있는지는 파악이 가능하지만, 정확히 어떤 API에서 문제가 생기는지 확인하기 위해 Context 정보를 추가했습니다. context는 이벤트에 임의의 데이터를 연결할 수 있는 기능입니다. 검색은 할 수 없지만, 이벤트가 발생한 이벤트 로그에서 추가한 데이터를 확인할 수 있습니다. 저 같은 경우엔, API 요청 객체가 어떻게 전달됐는지, API 응답값은 어떻게 전달됐는지 파악하기 위해 아래처럼 구성했습니다.

 

Sentry.setContext('API Request Detail', {
      method,
      url,
      headers,
    });

    Sentry.setContext('API Response Detail', {
      status,
      data: responseBody,
    });

 

 

위와 같이 구성하고 에러 이벤트를 Sentry에 전달하면 아래처럼 API 요청 값과 응답 값을 보다 명확히 확인할 수 있습니다. 

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

기대효과

간단하게 Scope와 Context 데이터를 Sentry에 전달함으로써 에러 디버깅을 효율적으로 처리할 수 있는 환경을 구축했습니다. 그리고 위에서는 작성하지 않았지만 예상하지 못한 외부 요인에 의해 에러가 발생하거나 런타임에서 에러가 발생할 경우는 현재 서버에서 모두 500 에러를 전달하도록 구성되어 있는데, 만약 서버에서 5xx 에러가 발생하는 경우만 Sentry에 데이터를 전달하도록 환경을 구축함으로써 Sentry로 전달되는 에러 이벤트 건수를 확 줄일 수 있었습니다. 이를 통해 사용자들의 불편함을 최소화할 수 있도록 환경을 구축할 수 있었습니다.

 

만약 Sentry를 기본 기능만 활용하고 계신다면, Sentry의 추가 기능을 활용함으로써 사용자의 불편함을 빠르게 개선하는 환경을 구축해 보시면 어떨까요? 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

마치며

Sentry를 활용하는 환경을 구축하긴 했었지만, 단순하게 활용하는 것과 이런 도구를 잘 활용하는 것은 다른 것이라는 것을 다시금 깨닫습니다. 앞으로도 기존에 사용하던 도구를 왜 사용하는지, 이 도구를 어떻게 하면 더 잘 활용할 수 있는지를 알아가기 위해 노력하려 합니다. 이 과정에서 팀에서 했던 크고 작은 문제 해결 과정을 공유해보려 합니다. 팀의 성장에 기여할 수 있는 개발자가 되겠습니다. 

 

 

 

 

 

---

 

 

 

출처

Sentry를 효과적으로 다루는 방법 | HOJUNIN

Sentry로 우아하게 프론트엔드 에러 추적하기 | 카카오페이 기술 블로그

Sentry로 사내 에러 로그 수집 시스템 구축하기