Datadog으로 모놀리스 모니터링: 방관자 효과를 피하는 방법

대규모 모놀리식 애플리케이션에서는 명확한 소유권이 없기 때문에 오류 추적 및 모니터링이 효과적이지 않은 경우가 많습니다. 이 가이드에서는 도메인 주석을 통해 책임을 할당하는 구조화된 접근 방식을 제안하여 문제를 해결합니다.

여러 팀이 있는 대규모 모놀리식에 대한 효과적인 모니터링을 설정하는 것은 어려울 수 있습니다. 명확한 소유권이 없으면 오류 추적이 일반화되고 종종 무시됩니다. 한 가지 해결책은 대기 중인 엔지니어가 모니터링 경보에 응답해야 할 팀을 식별하도록 하는 것입니다. 그러나 보다 효율적인 접근 방식은 각 로그 및 Datadog 범위에 도메인 및 팀 정보를 포함하는 것입니다.

도메인 주석 이해

애플리케이션의 다양한 부분을 담당하는 팀을 추적하기 위해 도메인 주석이라는 시스템을 사용합니다. 도메인 주석은 애플리케이션 코드의 모든 부분에 라벨을 지정하여 누가 무엇에 책임이 있는지 명확하게 나타냅니다. 이는 책임 관리에 있어 명확한 조직과 책임을 제공합니다.

도메인 주석 사용의 이점

도메인 주석은 모놀리식 애플리케이션 내에서 팀 책임을 추적하는 명확하고 체계적인 방법을 제공합니다. 도메인 주석으로 코드 일부에 태그를 지정하면 다음을 수행할 수 있습니다.

• 로그 및 추적 관리 단순화 : 팀 책임 등 특정 기준에 따라 로그 및 추적을 필터링하여 문제를 빠르게 식별하고 해결할 수 있습니다.
• 정확한 추적 유지 : 주석이 팀 이름이 아닌 도메인에 연결되므로 팀 책임의 변화에 원활하게 적응합니다.
• 책임 강화 : 각 도메인을 담당하는 팀을 명확하게 정의하여 조직 및 대상 모니터링을 개선합니다.
• 모니터링 효율성 향상 : 정확한 책임을 제공하고 전반적인 효율성을 향상하여 더 나은 모니터링 관행을 촉진합니다.

도메인 주석 처리

효율적인 모니터링 및 추적성을 보장하기 위해 각 웹 요청에는 적절한 도메인 정보가 태그로 지정됩니다. 이는 DomainProvider , DomainSpanService , DomainMdcProvider 및 DomainHandlerInterceptor 등 여러 구성 요소의 공동 작업을 통해 달성됩니다.

다음 다이어그램에 설명된 프로세스에 대한 높은 수준의 개요는 다음과 같습니다.

주요 구성 요소 설명

• DomainProvider : 특정 핸들러 메소드 또는 Bean과 연관된 도메인을 식별합니다. AOP(Aspect-Oriented 프로그래밍) 및 MVC(Model-View-Controller) 호출에서 도메인 주석을 찾는 데 도움이 됩니다.
• DomainSpanService : 추적 시스템의 작업 단위인 범위에 도메인 태그를 추가합니다. 이 서비스는 각 범위에 적절한 도메인 정보가 태그되어 있는지 확인합니다.
• DomainMdcProvider : 컨텍스트 정보로 로그 항목에 태그를 지정할 수 있는 로깅 프레임워크의 기능인 MDC(매핑된 진단 컨텍스트) 내에서 도메인 태그를 관리합니다.
• DomainHandlerInterceptor : 웹 요청을 가로채서 더 나은 모니터링 및 추적성을 위해 각 요청에 적절한 도메인 정보로 태그가 지정되도록 합니다.

이러한 구성 요소의 세부 구현은 공유 라이브러리에 캡슐화되어 대규모 모놀리식 애플리케이션에서 웹 요청에 태그를 지정하고 모니터링하기 위한 재사용 가능한 솔루션을 제공합니다.

누가 어떤 코드를 소유하는지 분류

클래스 수준에서 소유권을 정의하는 것은 도메인 주석을 사용하면 간단합니다. 기본 클래스에 최상위 주석을 적용하면 소유권이 해당 클래스 내의 모든 세부 리소스로 전파됩니다. 각 팀은 적절한 도메인 주석을 사용하여 자신이 소유한 클래스에 레이블을 지정할 수 있으므로 모든 단일 메서드를 표시할 필요 없이 명확성과 책임성을 보장할 수 있습니다.

여러 팀이 하나의 클래스에 코드를 소유하고 즉각적인 리팩토링이 적절하지 않은 경우 클래스 수준 주석보다 우선순위가 높은 다양한 도메인 주석으로 개별 메서드를 표시할 수 있습니다. 이를 통해 특정 방법을 여러 팀에 할당할 수 있어 전체 구조를 복잡하게 하지 않고도 유연성을 제공할 수 있습니다.

주석 사례에서 지원되지 않는 극복

도메인 주석은 매우 유용하지만 사용할 수 없는 경우가 드뭅니다. 예를 들어, Quartz의 AOP 논리와 도메인 주석에 사용되는 AOP 논리 간의 충돌로 인해 도메인 주석과 원활하게 작동하지 않는 Quartz 작업 생성 문제가 발생했습니다.

직접 주석을 달 수 없는 작업 및 프로세스의 경우 작업 구현에서 DomainTagsService를 직접 사용했습니다. 이 접근 방식을 통해 작업 실행 논리 내에 도메인 태그를 수동으로 추가할 수 있었습니다.

다음은 DomainTagsService를 Quartz 작업에 통합한 방법에 대한 예입니다.

 final override fun execute(context: JobExecutionContext) { domainTagsService.invoke(domain) { withLoggedExecutionDetails(context, ::doExecute) } }

인공 서비스를 통해 모니터링 및 가시성 향상

각 팀별로 별도의 서비스를 제공하는 것은 모니터링 및 소유권 측면에서 상당한 이점을 제공하지만, 모놀리스를 분할하는 데 드는 비용과 노력이 높으며 잠재적인 추가 개발 비용이 발생합니다. 모놀리스가 모듈로 분할될 때 Gradle을 사용하여 빌드 시간을 개선할 수 있는 가능성을 고려하면 모노레포를 유지하는 것이 많은 경우에 가장 효율적인 솔루션일 수 있습니다.

인공서비스 도입

Datadog에서 각 팀의 활동을 단순화하기 위해 여러 팀에 걸쳐 인공적인 서비스 이름을 할당할 수 있습니다. 이 접근 방식을 통해 모든 팀은 Datadog의 모니터링 도구에 전용 섹션을 갖게 됩니다. 관리할 서비스가 많은 경우 인위적인 서비스 이름을 사용하는 것이 혼란스러울 수 있지만 제한된 수의 백엔드 서비스를 사용하면 관리가 가능해집니다. 이러한 인공 서비스 이름에 접두사를 추가하면 Datadog 설정의 구성과 명확성을 유지하는 데 도움이 되며 다양한 팀과 해당 책임을 더 쉽게 구별할 수 있습니다.

스크린샷 대신 다이어그램을 사용하세요?? 여기서 작업자/웹앱을 사용하는 것은 의미가 없습니다.

로그에 인공 서비스를 사용하지 않는 이유는 무엇입니까?

로그에 인위적인 서비스 이름을 사용하면 동일한 로그 항목이 다른 서비스에 나타날 수 있으므로 혼란이 발생할 수 있습니다.

예를 들어 동일한 인증 서비스를 사용하는 두 개의 엔드포인트를 생각해 보세요. 이러한 엔드포인트에 다른 도메인으로 주석이 달린 경우 인증 로직은 다른 인공 서비스에서 로그를 생성합니다. 여러 서비스 이름 아래에 로그가 표시되므로 로그를 탐색할 때 혼란을 야기할 수 있습니다. 이 문제를 방지하려면 혼동을 줄이기 위해 트레이스에서 함께 집계되는 범위에만 인위적인 서비스 이름을 적용하는 것이 좋습니다.

말이 되나요? 내 생각엔 아닌 것 같아

이 문제를 시각적으로 표현하면 다음과 같습니다.

모니터링 및 대시보드에서 인공 서비스 사용

인공 서비스를 사용하면 APM 추적으로 작업할 수 있을 뿐만 아니라 장기간 저장되는 Datadog Metrics에서 서비스별로 필터링하여 장기간에 걸친 변경 사항을 추적할 수 있습니다.

모니터의 예

다음은 쿼리에서 인공 서비스 이름 konsus-assets 사용하는 Datadog의 모니터 스크린샷입니다.

대시보드의 예

다음은 필터에서 인공 서비스 이름 konsus-assets 사용하는 Datadog의 대시보드 스크린샷입니다.

모니터링 전략에 가짜 서비스를 활용하면 모놀리식 애플리케이션 내에서 각 팀 활동의 가시성과 책임성을 강화할 수 있습니다. 이 접근 방식은 팀별 모니터와 대시보드를 생성하고 유지 관리하는 프로세스를 단순화하여 Datadog에서 보다 효과적이고 체계적인 모니터링을 제공합니다.

마무리

도메인 주석은 Datadog의 모놀리식 애플리케이션 모니터링을 단순화하는 간단한 접근 방식을 제공합니다. 이 전략을 구현하면 로그, 범위 및 측정항목의 관리 효율성을 향상하여 모니터링 설정을 특정 팀에 맞는 도구로 변환할 수 있습니다. 이를 통해 책임성과 조직성이 향상되고 애플리케이션 전반에 걸쳐 보다 효과적이고 효율적인 문제 해결 및 성능 분석이 용이해집니다.

주요 시사점

1. 향상된 소유권 및 책임 : 코드의 일부에 도메인 주석을 추가하면 각 도메인을 담당하는 팀을 명확하게 정의할 수 있습니다. 이를 통해 더 나은 구성과 대상 모니터링이 용이해집니다.
2. 향상된 로그 및 추적 관리 : 도메인 주석을 사용하면 팀 책임과 같은 특정 기준에 따라 로그와 추적을 모두 필터링하여 문제를 빠르게 식별하고 해결할 수 있습니다.
3. 인공 서비스의 유연성 : 범위(로그 아님)에 인공 서비스 이름을 사용하면 로그가 명확하게 유지되고 실제 출처를 추적할 수 있어 혼동을 피할 수 있습니다.
4. 통합 문제 극복 : Quartz와 같은 특정 작업 실행 프레임워크와 같이 주석을 직접 적용할 수 없는 경우 작업 구현에서 직접 DomainTagsService 와 같은 서비스를 사용하면 도메인별 모니터링을 계속 유지할 수 있습니다.

도메인 주석 사용에 대한 단계별 접근 방식:

1. 도메인 및 팀 정의

   그것은 lib로 바뀔 것입니다 !!!

   애플리케이션에서 다양한 도메인과 팀을 나타내는 열거형을 만듭니다.

   • @Domain 클래스나 함수에 적용할 수 있는 주석으로, 특정 도메인 값으로 표시합니다.
   • DomainValue 각각 팀과 연결된 다양한 도메인을 나타내는 열거형입니다.
   • Team 애플리케이션을 작업하는 다양한 팀을 나타내는 열거형입니다.

    @Retention(AnnotationRetention.RUNTIME) @Target(AnnotationTarget.CLASS, AnnotationTarget.FUNCTION) annotation class Domain(val value: DomainValue) enum class DomainValue(val team: Team) { USER_MANAGEMENT(Team.TEAM_A), PAYMENT_PROCESSING(Team.TEAM_B), NOTIFICATIONS(Team.TEAM_C) } enum class Team { TEAM_A, TEAM_B, TEAM_C }

2. 클래스(및 필요한 경우 메서드)에 주석을 답니다.

    @Domain(DomainValue.USER_MANAGEMENT) class UserService { @Domain(DomainValue.PAYMENT_PROCESSING) fun processPayment() { ... } }

3. 지원되지 않는 사례 처리

   직접 주석을 달 수 없는 경우에는 DomainTagsService 직접 사용하여 로직을 래핑하세요.

    fun executeNotSupportedByAnnotationsLogic() { domainTagsService.invoke(domain) { executeLogic() } }

4. Datadog으로 모니터링

   모니터, 대시보드 및 APM 추적 필터링에 인공 서비스 필터 사용

이러한 단계를 수행하면 모놀리식 애플리케이션에서 도메인 주석을 효과적으로 구현하여 향상된 모니터링, 책임 및 전반적인 효율성을 보장할 수 있습니다.

게시물을 읽어주셔서 감사합니다!