Sentry 도입으로 Spring Boot 애플리케이션 모니터링 개선하기

Improving Spring Boot Application Monitoring Using Sentry

실시간 데이터 모니터링이 요구되는 현대 개발 환경에서 Sentry는 신뢰할 수 있는 에러 추적 솔루션으로 자리매김하고 있습니다. Spring Boot 애플리케이션의 모니터링 기능을 향상시키려면 이와 같은 도구가 필수적입니다.

Sentry는 실시간으로 이슈를 이해하고, 분류하고, 해결할 수 있는 오픈소스 오류 추적 도구입니다. 이를 통해 개발자들은 오류가 발생한 이유를 더 심층적으로 이해하고 분석할 수 있습니다.

이번 포스팅에서는 Spring Boot 애플리케이션에 Sentry를 도입하여 실시간 모니터링을 어떻게 효과적으로 관리할 수 있는지 알아보겠습니다.

Prerequisite

아래와 같은 Spring Boot 환경에서 진행하였습니다:

• Java 17
• Spring Boot 3.2.2
• Gradle 8

Getting Started with Sentry

에러 추적 서비스인 Sentry를 설정하고, 이를 Spring Boot 애플리케이션에 통합하는 방법을 알아보겠습니다.

On-Premise vs Cloud-Based

Sentry는 오픈소스 도구로, 이를 호스팅하는 방법을 사용자나 기업이 자유롭게 선택 가능합니다. 이에 따라 Sentry를 구축하는 방법은 기본적으로 두 가지로 나뉩니다.

• On-Premise: 이 방법을 사용하면, 사용자는 자신의 서버에서 Sentry를 호스팅하게 됩니다. 이는 Sentry의 모든 기능을 제어할 수 있으며 민감한 정보가 유출되는 것을 예방할 수 있는 장점이 있지만, 동시에 모든 유지 보수 및 운영을 직접 관리해야 한다는 부담이 따릅니다.
• Cloud-Based: Sentry.io에서 제공하는 클라우드 기반 서비스를 사용하는 것은 아주 편리합니다. 클라우드 기반 방식은 서버를 직접 관리하는 수고를 덜어주지만, 모든 기능에 대한 제어력이나 보안적인 측면에서 상대적으로 제한적입니다.

운영 환경과 주어진 상황을 바탕으로 가장 적합한 접근법을 선정해야 합니다.

• 비용과 규모: 클라우드 서비스는 월별 요금제를 따르지만, 온프레미스 방식은 서버를 보유한 경우에 추가 비용이 발생하지 않습니다.
• 유지보수와 업데이트: 온프레미스 방식은 직접 업데이트하고 유지보수해야 한다는 단점이 있습니다. 반면에, 클라우드 서비스는 이러한 관리를 대신 해줍니다.
• 데이터 일관성과 보안 유지: 데이터 민감성이 높거나 특정 규제에 따라야 하는 경우, 온프레미스 방식으로 운영하는 것이 더 많은 제어력과 보안을 제공할 수 있습니다.

각 호스팅 방식의 장점과 단점을 고려하여 개별 비즈니스와 운영 팀의 요구 사항에 가장 적합한 결정을 내릴 수 있을 것입니다. 모든 선택은 트레이드 오프와 크고 작은 결정이 연결되어 있으므로 신중하게 고려해야 합니다.

이 글에서는 클라우드 방식을 통해 Sentry를 구축하는 방법을 살펴보도록 하겠습니다.

Enabling Sentry

클라우드 방식을 사용하려면, Sentry 계정 생성 후 Spring Boot 프로젝트를 Sentry와 연동시키면 됩니다. 먼저, Sentry 회원 가입 페이지에 접속하여 가입을 시작합니다. 이메일 주소를 이용하여 가입하거나, GitHub 또는 Google 계정을 이용하여 진행할 수 있습니다.

회원 가입을 완료하면 Sentry는 사용자를 Onboarding 화면으로 이동시킵니다. 첫 프로젝트 생성 과정을 안내하는데, 에러를 추적할 언어나 플랫폼을 선택하는 것으로 시작합니다. 여기서 Spring Boot 플랫폼을 선택합니다.

그 다음으로 SDK 적용을 위한 온보딩 화면이 나타납니다. 여기에서 Spring Boot 프로젝트에 Sentry를 적용하는 방법을 안내받게 됩니다.

위 화면에서 Sentry 인증 토큰을 발급받을 수 있고, DSN 주소도 확인할 수 있습니다. 이 정보들은 Spring Boot 프로젝트에 Sentry를 연동하는 데 필요합니다. 이제 실제 프로젝트에 Sentry SDK를 설치하고 설정을 진행해 보겠습니다.

우선  build.gradle 파일을 열어 플러그인을 설치하고 Sentry 관련 설정을 추가합니다.

plugins {
    id "io.sentry.jvm.gradle" version "4.3.0"
}

sentry {
    includeSourceContext = true

    org = "catsriding"
    projectName = "waves-server"
    authToken = System.getenv("SENTRY_AUTH_TOKEN")
}

인증 토큰이 노출되는 것을 막기 위해서 System.getenv() 함수를 이용해서 환경변수에서 토큰 값을 가져오도록 처리합니다. 발급 받은 인증 토큰을 환경변수에 등록하려면 다음과 같은 명령어를 터미널에서 실행합니다:

$ export SENTRY_AUTH_TOKEN=sntrys_eyJpYXQiOjE3***

하지만 이렇게만 설정하는 경우 시스템을 재부팅하면 매번 다시 설정해야 합니다. 이는 매우 비효율적이므로, 시스템 환경변수에 추가하는 것이 편리합니다.

쉘 설정 파일을 수정해야 하는데, 이는 사용하고 있는 쉘에 따라 달라집니다. 여기서는 zsh 쉘을 기반으로 󱆃 .zshrc 파일에 작업을 진행하였습니다.

터미널을 열고 아래의 명령어를 입력합니다:

$ vim ~/.zshrc

그럼 편집창이 열리는데, 이 화면의 맨 아래에 다음 코드를 추가하고 저장합니다:

# Sentry
export SENTRY_AUTH_TOKEN=sntrys_eyJpYXQiOjE3***

이제 변경 사항을 적용합니다.

$ source ~/.zshrc

마지막으로 SDK 온보딩 페이지에서 발급받은 DSN URL을 󰖷 application.yml에 추가하여 설정을 마무리합니다:

sentry:
  dsn: https://[public:secret]@sentry.io/[project]
  traces-sample-rate: 1.0
  environment: development

• sentry.dsn:
  • DSN(Data Source Name)은 Sentry로 오류 및 이벤트를 보내기 위한 연결 설정 정보를 포함하고 있습니다. 이는 프로젝트의 고유한 식별자로 작동하며, Sentry SDK는 이 DSN을 사용하여 오류와 이벤트를 정확한 Sentry 프로젝트로 보내는 데 사용합니다.
  • DSN은 API 키, Sentry 서버의 주소, 프로젝트의 ID로 구성되어 있습니다.
• sentry.traces-sample-rate:
  • Sentry에서 수집하는 트랜잭션 데이터의 비율을 설정하는데 사용됩니다. 애플리케이션의 트랜잭션 데이터 중 얼마만큼을 Sentry가 수집하여 분석할 것인지를 결정할 수 있습니다. 이 설정은 성능 모니터링과 관련하여 자원 사용을 최적화하는데 도움이 됩니다.
  • 예를 들어, traces-sample-rate가 1.0 으로 설정되어 있다면, 이는 Sentry가 발생하는 모든 트랜잭션 데이터를 수집하도록 설정된 것입니다. 이는 샘플링 비율이 100%라는 것을 의미합니다. 반대로 traces-sample-rate를 0.1 로 설정하면, Sentry는 발생하는 트랜잭션 데이터 중 약 10%만 수집하게 됩니다.

이렇게 설정을 완료하면, Spring Boot 애플리케이션과 Sentry가 성공적으로 통합되었습니다. 이제 Sentry를 통해 애플리케이션의 오류 추적과 성능 모니터링이 가능합니다.

위 설정 이외에도, Sentry의 공식 문서에서 다양한 추가 옵션을 확인할 수 있습니다. 이를 활용하여 애플리케이션의 오류 추적 및 성능 모니터링을 프로젝트의 요구 사항에 따라 더욱 세밀하게 조절할 수 있을 것입니다.

Playgrounds

테스트를 진행하여 기능이 예상대로 작동하는지 확인해 보겠습니다. 이를 통해 예외 발생 시 Sentry로 에러 로그 전송이 잘 이루어지는지 살펴봅니다.

사용자로부터 HTTP GET 요청을 받았을 때 RuntimeException을 발생시키는 간단한 REST API를 구현합니다.

@Slf4j
@RestController
@RequestMapping(value = "/sentry")
public class SentryController {

    @GetMapping
    public ResponseEntity<?> sentry() {
        throw new RuntimeException("Sent exception to Sentry.io");
    }
}

RuntimeException이 발생함에 따라 이를 Sentry에 전달해주는 SentryControllerAdvice 역시 추가하였습니다. 이 클래스의 기능은 RuntimeException을 캐치하고 해당 예외를 Sentry에 전송하는 것입니다.

@Slf4j
@RestControllerAdvice
public class SentryControllerAdvice {

    @ExceptionHandler(RuntimeException.class)
    protected ResponseEntity<?> handle(RuntimeException e) {
        Sentry.captureException(e);
        return ResponseEntity
                .badRequest()
                .body(e.getMessage());
    }
}

이제 curl 명령을 이용해 테스트를 진행해봅니다. 아래의 명령을 입력하면, SentryController의 sentry() 메서드가 호출될 것이고, 이 메서드에서는 RuntimeException이 발생하며 SentryControllerAdvice의 handle() 메서드에서 예외를 Sentry로 전송할 것입니다.

$ curl -X GET http://localhost:8080/sentry
Sent exception to Sentry.io

Sentry 사이트에 접속해보면, 이전에 보이지 않았던 새로운 에러 이슈가 생성된 것을 확인할 수 있습니다. 이 이슈를 클릭하면, 이슈에 대한 자세한 정보를 얻을 수 있습니다. 이 정보는 GitHub에 이슈를 생성하거나 다른 연계된 작업을 진행하는 데 매우 유용하게 사용될 수 있습니다.

명시적인 예외 발생 상황 외에도, 실제 사용자가 서비스를 이용하는 중에 발생하는 다양한 예외 상황들에 대해서도 Sentry로 쉽게 전송하여 관리할 수 있습니다.

이렇게 Sentry를 활용함으로써 빠르게 이슈를 파악하고 대응할 수 있어, 서비스 품질 향상에 크게 기여할 수 있을 것 같습니다. 😎