Azure의 Observability 기능을 사용하기 위한 서비스들에 대해 간략히 설명합니다.

• Azure Monitor: Azure에서 제공하는 핵심 통합 모니터링 플랫폼입니다. 클라우드 및 온프레미스 환경에서 실행되는 애플리케이션, 인프라, 네트워크 리소스의 성능과 상태를 수집, 분석, 시각화, 응답할 수 있도록 지원합니다.

• : Azure Monitor의 하위 서비스 중 하나로, 특히 애플리케이션 수준의 Observability에 초점을 맞춘 도구입니다. 주로 웹 애플리케이션, API 서버, 클라이언트 앱의 성능과 사용 현황을 실시간으로 분석할 수 있게 도와줍니다. application insight는 리소스 생성시 반드시 1개의 Log Analytics Workspace와 연동이 필요합니다.

• Log Analytics Workspace: Azure Monitor의 핵심 기능 중 하나로, 다양한 소스에서 수집한 로그 데이터를 저장하고 질의(Query)를 통해 분석할 수 있도록 해줍니다.

• Container Insights: Kubernetes 클러스터 및 컨테이너 기반 워크로드의 상태와 성능을 모니터링하며, CPU/메모리 사용량, 컨테이너 재시작, 노드 상태 등의 정보를 시각화해 줍니다.

장단점

Azure의 모니터링 서비스는 리소스나 데이터 단위로 Pay-as-you-go 방식으로 과금되지만, 다른 Azure 서비스 와의 연결성이 아주 좋아 손쉽게 구축할 수 있으며, 인프라 관점에서 관리 포인트가 적어 운영 효율성을 높이는 데 유리합니다.

Azure Observability 관련 서비스들은 아래와 같이 정리 할 수 있습니다.

Azure VS OpenSource

Azure는 통합된 SaaS 기반 솔루션을 통해 손쉽고 빠르게 Observability 환경을 구축할 수 있는 반면, OpenSource는 벤더 종속을 최소화하면서도 유연하고 확장성 높은 관측 체계를 설계할 수 있습니다. 각각의 접근 방식은 구축 목적, 시스템 복잡도, 운영 조직의 역량에 따라 장단점이 분명히 구분됩니다.

구축, 운영시 유의점

Application Insights는 데이터 저장소로 Log Analytics Workspace를 사용합니다. Log Analytics Workspace의 비용 정책은 Pay-as-you-go 방식이기 때문에, 대규모 서비스의 경우 샘플링 기능을 활성화하는 것이 비용 효율성을 높일 수 있습니다. 예를 들어, error 발생 시 100%, info 발생 시 10%의 비율로 데이터를 저장하도록 서비스 내의 Agent에서 샘플링 비율을 조정하는것이 효율적일 것입니다.

Log Analytics Workspace

각 리소스별 진단 설정을 했을 때 리소스를 사용량이 많은경우 Pay-as-you-go 정책에 따라 과금량이 급증 할 수 있습니다. 진단 설정의 경우 샘플링 기능이 없기 때문에 리소스의 로그 생성이 많은 리소스인 경우 진단 설정을 제외하거나, 만약 제외 할 수 없는 경우라면 해당 리소스가 생성하는 log가 저장되는 table의 retention 기간, archive 기간을 조절하는것이 필요합니다.

Observability 구축

현재 AI 플랫폼에서는 여러 프로젝트들이 Azure 서비스를 기반으로 Observability가 구축되어 있습니다.

샘플 프로젝트에서 를 이용한 기본적인 Observability 구축 방법과 AI 플랫폼의 하나의 프로젝트를 예시로 Observability에 대해 설명하고자 합니다.

샘플 프로젝트

샘플 프로젝트에서는 API Management Service, Container Apps, SQLite를 사용하여 특정 서비스를 구축한다고 했을 때 Observability를 구축하는 방법에 대해 설명하겠습니다.

Application Insights 사용

Azure Observability 서비스들 중에서 Application insights를 사용하여 MSA 아키텍처에서의 API 요청 Metric, Trace, Log 확인을 예제로 보여드리겠습니다.

다음은 예제로 구성한 데모 아키텍처의 호출 시퀀스 다이어그램입니다. 사용자 요청은 Azure API Management를 통해 Spring Boot 기반의 Container App으로 전달되고, 해당 애플리케이션은 내부적으로 요청받은 사용자 정보를 SQLite에 저장한 후 응답을 반환합니다.

Java Agent 설정

application insights로 metric, trace, log 데이터를 전송하기 위해 agent 설정이 필요합니다.

Agent jar 파일 다운로드

아래 링크에서 용 OpenTelemetry Java Agent를 다운로드합니다:

Releases · microsoft/ApplicationInsights-Java

application insights 연결시 connection string으로 인증을 하게 됩니다.

java application 시작시 환경변수로 connection string을 읽을 수 있도록 connection string을 환경변수로 설정하거나 image를 build하는 경우 Dockerfile의 환경변수에 추가합니다.

어플리케이션 실행시 -javaagent 옵션을 추가해야 합니다.

agent가 정상 동작한다면 아래와 같이 어플리케이션 실행 시 console log에서 c.m.applicationinsights.agent 패키지에서 생성되는 log를 확인 할 수 있습니다.

2025-06-02 16:08:02.813+09:00 INFO  c.m.applicationinsights.agent -  Java Agent 3.7.1 started successfully (PID 20150, JVM running for 6.13 s)
2025-06-02 16:08:02.814+09:00 INFO  c.m.applicationinsights.agent - Java version: 21.0.6, vendor: Microsoft, home: /Library/Java/JavaVirtualMachines/microsoft-21.jdk/Contents/Home
  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v3.4.2)
2025-06-02T16:08:03.238+09:00  INFO 20150 --- [order-service] [           main] c.k.o.o.OrderServiceApplication          : Starting OrderServiceApplication v0.0.1-SNAPSHOT using Java 21.0.6 with PID 20150 (/Projects/opentelemetry-demo/order-service/build/libs/order-service-0.0.1-SNAPSHOT.jar started by chpark in /Projects/opentelemetry-demo/order-service)
2025-06-02T16:08:03.245+09:00  INFO 20150 --- [order-service] [           main] c.k.o.o.OrderServiceApplication          : The following 1 profile is active: "dev"
2025-06-02T16:08:03.635+09:00  INFO 20150 --- [order-service] [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.
2025-06-02T16:08:03.714+09:00  INFO 20150 --- [order-service] [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 74 ms. Found 1 JPA repository interface.
2025-06-02T16:08:04.017+09:00  INFO 20150 --- [order-service] [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port 8080 (http)
1
2
3
4
5
6
7
8
9
10
11
12
13
14

확인 결과

POST /api/v1/users 경로로 api 요청을 했을 때 application insights에서 전체 transaction 요청을 추적 할 수 있는 기능을 제공합니다.

아래에서 보이듯이 apim → container apps → sqlite 순으로 요청되는 Trace를 볼 수 있고 각 구간별 소요 시간 및 상세 정보 또한 확인 할 수 있습니다.

그림 3.2 end-to-end transaction 조회

에서는 Log Analytics workspace를 이용하여 log, metric, trace를 테이블 형태로 저장합니다.

데이터가 저장되는 각 테이블은 다음과 같이 확인할 수 있습니다:

• traces: 애플리케이션에서 출력한 로그 메시지를 저장합니다 (console log, 커스텀 log 등).

• requests: 수신된 HTTP 요청의 메타데이터와 상태 정보를 저장합니다.

• dependencies: 외부 서비스나 데이터베이스에 대한 호출 정보를 저장합니다.

• exceptions: 애플리케이션에서 발생한 예외 정보를 저장합니다.

• pageViews: 웹 애플리케이션의 페이지 뷰 정보를 저장합니다.

• customEvents: 사용자가 정의한 이벤트 데이터를 저장합니다.

• availabilityResults: 가용성 테스트의 결과를 저장합니다.

• performanceCounters: 서버의 성능 지표(CPU, 메모리 등)를 저장합니다.

• metrics: 사용자 정의 또는 자동 수집된 메트릭 데이터를 저장합니다.

이 문서에서는 traces, requests 테이블에 대해서만 설명하겠습니다. 자세한 내용은 참조된 Azure 공식 문서에서 확인할 수 있습니다.

Application Insights telemetry data model - Azure Monitor 

traces 테이블을 통해 애플리케이션 내부에서 출력된 콘솔 로그나 커스텀 로그를 실시간으로 확인할 수 있습니다. 위 그림에서는 사용자 생성 API(/api/v1/users)가 호출될 때 HelloController에서 기록한 로그를 확인할 수 있습니다. 로그에는 요청한 유저의 정보와 함께 요청을 처리한 스레드 정보, 로거 이름 등 다양한 customDimensions 데이터도 함께 기록되어 있어서 문제 분석 시 매우 유용합니다.

requests 테이블은 외부에서 들어온 HTTP 요청의 이력을 기록합니다. 요청의 URL, 메서드, 성공 여부, 응답 코드를 포함하여 API 호출의 전반적인 흐름을 확인 할 수 있습니다. 위 그림에서는 API Management와 Azure Container Apps 두 곳에서 /api/v1/users API가 호출되었고, 모두 성공적으로 응답되었음을 확인할 수 있습니다.

Observability In Project

아래와 같이 AI Platform 내에 하나의 프로젝트에서는 Azure의 AKS, API Management Service, Postgres등 여러 리소스를 사용하고 있습니다.

위 서비스들의 호출 상관 관계, api별 평균 호출 시간등 의 기능을 이용하여 확인 할 수 있습니다.

아래 처럼 서비스 개발자는 application map을 이용해 전체 모듈간의 호출 상관 관계를 다이어그램으로 손쉽게 확인 합니다. 또한 transaction search를 이용해 개별 api transaction을 확인 하고 있습니다.

정리하며

Observability는 단순한 모니터링을 넘어, 시스템의 내부 동작을 깊이 있게 이해하고 예기치 못한 문제를 조기에 탐지하는 데 필수적인 요소입니다. 특히 MSA 아키텍처처럼 복잡도가 높은 환경에서는 로그, 지표, 트레이스를 통합적으로 분석할 수 있는 관찰 체계가 반드시 필요합니다.

Azure는 와 같은 도구를 통해 개발자와 운영자가 애플리케이션의 상태를 직관적으로 파악하고, 문제의 원인을 빠르게 분석할 수 있도록 강력한 Observability 기능을 제공합니다. Azure 뿐만 아니라 OpenTelemetry 기반으로 Observability를 도입해 본다면, 운영 효율성과 장애 대응력이 크게 향상될 것입니다.

참고자료

Application Insights에서 OpenTelemetry 사용 - Azure Monitor

구성 옵션 - Java용 Azure Monitor Application Insights - Azure Monitor

TraceContext 표준 문서 Trace Context

Log Analytics cost optimization Log Analytics 작업 영역에서 데이터 보존 관리 - Azure Monitor

Azure Monitor cost optimization Azure Monitor의 비용 최적화 - Azure Monitor