AZ-305 시험에서 모니터링·로깅 아키텍처는 설계자 역량을 직접 검증하는 영역입니다. 서비스 이름보다 언제 어느 구성을 선택해야 하는지를 판단하는 문제가 주를 이룹니다. Azure Monitor, Log Analytics, Application Insights, 진단 설정, 경고 규칙의 연결 관계를 이해하면 이 영역 문제의 대부분을 풀 수 있습니다. 이 글은 실제 시험 문제 25개를 바탕으로 핵심 개념과 선택 기준을 정리했습니다.
---
Azure Monitor의 데이터 흐름
Azure Monitor는 클라우드 환경 전체를 감시하는 통합 모니터링 플랫폼입니다. 데이터는 크게 네 가지 유형으로 수집됩니다.
메트릭은 CPU 사용률, 메모리, 네트워크 처리량 같은 숫자형 시계열 데이터입니다. 대부분의 Azure 리소스에서 자동으로 수집되며, 기본 보존 기간은 93일입니다.
로그는 "누가 언제 무엇을 했는가"를 기록하는 구조화된 이벤트 데이터입니다. 로그는 기본적으로 리소스 내부에 머물러 있으며, 분석하려면 진단 설정(Diagnostic Settings)을 통해 Log Analytics 작업 영역으로 전송해야 합니다.
Activity Log는 Azure Resource Manager를 통한 모든 관리 작업을 자동 기록하는 플랫폼 로그입니다. 리소스 배포, 삭제, 구성 변경 같은 제어 플레인 이벤트가 기록되며, 에이전트 설치도 진단 설정도 필요 없이 즉시 조회 가능하고 기본 90일 보존됩니다.
진단 로그는 리소스 내부의 운영 데이터입니다. Azure SQL Database의 SQLInsights, App Service 로그, Key Vault 접근 로그 등이 여기에 해당하며, 반드시 진단 설정을 통해 대상(Log Analytics, Storage Account, Event Hub)을 지정해야 수집됩니다.
시험 함정: "에이전트 없이, 설정 없이 즉시 관리 작업 이력 조회" → Activity Log. 리소스 내부 운영 로그 분석 → 진단 설정이 선행입니다.
---
Log Analytics 작업 영역 설계
Log Analytics 작업 영역은 Azure Monitor의 핵심 로그 저장소입니다. 시험에서는 작업 영역 수와 비용 최적화를 묻는 문제가 자주 출제됩니다.
단일 vs 다중 작업 영역
Network Insights, Application Insights(작업 영역 기반), Microsoft Sentinel, VM Insights는 모두 단일 Log Analytics 작업 영역에 통합할 수 있습니다. 서비스 수 = 작업 영역 수가 아닙니다. 중앙화·상관 분석이 목적이면 1개로 충분하고, 팀별 완전 분리·데이터 주권이 필요할 때만 다중 작업 영역을 검토합니다. 하나의 리소스에 최대 5개의 진단 설정을 만들 수 있으므로, 두 팀이 각각 독립된 작업 영역을 원하면 진단 설정 2개를 만들어 각각 다른 작업 영역을 지정합니다.
데이터 수집 에이전트: AMA와 DCR
Azure Monitor Agent(AMA)는 구형 MMA를 대체하는 현세대 에이전트이며, Data Collection Rule(DCR)과 함께 사용합니다. DCR은 무엇을 수집하여 어디로 보낼지 정의하는 정책 리소스입니다.
DCR 수를 계산할 때 기준은 VM의 수가 아닌 운영체제와 데이터 소스 유형의 차이입니다. Windows VM 20대(보안 이벤트 로그)와 Linux VM 15대(Syslog)처럼 OS가 다르면 최소 2개의 DCR이 필요합니다.
Data Collection Endpoint(DCE)는 네트워크 격리 환경에서만 필요합니다. 공용 엔드포인트로 접근 가능하고 격리 요구사항이 없다면 DCE는 0개입니다. Private Link 또는 인터넷 차단 키워드가 없으면 DCE 불필요로 판단하세요.
데이터 보존과 비용 최적화
Log Analytics 작업 영역의 기본 보존 기간은 30일입니다. 최대 인터랙티브 보존은 730일(2년), 아카이브 계층을 포함하면 최대 4,383일(약 12년)까지 보존할 수 있습니다. 인터랙티브 계층은 KQL 쿼리가 가능하지만 비용이 높고, 아카이브 계층은 쿼리가 제한되지만 비용이 낮습니다.
신규 수집 비용을 줄이려면 약정 가격 계층(Commitment Tier)으로 전환하세요. 종량제 대비 최대 30% 이상 할인을 받을 수 있으며, 기존 경고 규칙과 자동화 런북에 영향을 주지 않습니다. Storage Account 진단 설정의 retention days는 Blob 자동 삭제 주기이며, Log Analytics 쿼리 가능 기간과 다릅니다.
---
Application Insights와 분산 추적
Application Insights는 애플리케이션 성능 모니터링(APM) 전용 서비스로, 인프라 지표 중심의 Azure Monitor와 달리 트랜잭션 단위 분석과 사용자 행동 분석에 특화되어 있습니다.
핵심 기능 세 가지
Application Map은 마이크로서비스 간의 호출 관계와 의존성을 그래프로 시각화합니다. 오류율이 높은 서비스와 응답 지연 구간을 한눈에 파악할 수 있습니다.
분산 추적(Distributed Tracing)은 단일 요청이 여러 마이크로서비스를 거치는 전 과정을 엔드투엔드 타임라인으로 추적합니다.
사용자 분석은 Users, Sessions, Funnels, Retention, User Flows 등 6가지 분석 기능을 단일 서비스 안에서 제공합니다.
코드리스 연결과 가용성 테스트
코드리스 연결(Codeless Attach)은 Azure App Service에서 코드나 SDK 변경 없이 Azure Portal 설정만으로 자동 계측을 활성화합니다. 코드 변경 없이 트랜잭션 수준 응답 시간과 의존성 호출을 분석해야 한다는 조건이 나오면 이 기능이 정답입니다.
가용성 테스트는 실제 사용자 없이 사용자 흐름을 주기적으로 시뮬레이션하는 합성 트랜잭션 모니터링입니다. URL Ping 테스트, 표준 테스트, 다단계 웹 테스트 세 가지 유형을 지원하며, 전 세계 Azure 위치에서 에이전트 없이 실행됩니다. 추가 인프라 없이 합성 모니터링이 필요하다는 조건이 나오면 Application Insights 가용성 테스트를 선택하세요.
---
경고와 자동 대응 설계
경고 시스템은 경고 규칙(Alert Rule), 작업 그룹(Action Group), 경고 처리 규칙(Alert Processing Rule) 세 요소로 구성됩니다.
경고 규칙과 작업 그룹
메트릭 경고는 CPU 사용률·HTTP 5xx 같은 수치 임계값 기반, 1분 단위 평가가 가능합니다. 로그 쿼리 기반 경고는 KQL 결과를 기반으로 발생시킵니다. Action Group은 하나를 여러 경고 규칙에서 공유할 수 있습니다. VM 재시작·할당 해제·전원 꺼짐 세 이벤트에 동일 수신자로 알림을 보낸다면 단일 Action Group + 세 개의 Activity Log 경고 규칙 조합이 최적입니다. 수신자 변경 시 Action Group만 수정하면 됩니다. 경고 처리 규칙은 유지보수 기간에 알림을 억제할 때 사용합니다.
인터넷 경유 없이 프라이빗 경로로만 로그를 수집해야 한다면 Azure Monitor Private Link Scope(AMPLS)를 사용합니다. AMPLS는 Log Analytics 작업 영역과 Application Insights를 VNet 내부 Private Endpoint로 연결합니다.
---
서비스 비교표
아래 표는 Azure Monitor 플랫폼에서 수집되는 주요 데이터 유형과 각 서비스의 특성을 정리한 것입니다.
| 데이터 유형 | 대표 서비스 | 저장소 | 자동 수집 여부 | 주요 용도 | |-----------|-----------|--------|-------------|----------| | 메트릭 | Azure Monitor Metrics | 메트릭 DB (93일) | 대부분 자동 | 실시간 성능 모니터링, 임계값 경고 | | 로그 | Log Analytics 작업 영역 | Log Analytics (기본 30일) | 진단 설정 필요 | KQL 쿼리, 상관 분석, 장기 감사 | | 트레이스 | Application Insights | Log Analytics 연동 (기본 90일) | SDK 또는 코드리스 연결 | 분산 추적, 트랜잭션 분석 | | Activity Log | Azure Activity Log | 플랫폼 자동 (기본 90일) | 완전 자동 | 관리 작업 감사, 배포 이력 추적 |
테이블 관점: Windows VM 보안 이벤트 로그 → SecurityEvent, Linux syslog → Syslog, Azure 관리 작업 → AzureActivity, 리소스 진단 로그 → AzureDiagnostics. SecurityEvent와 Syslog는 운영체제 기준으로 구분됩니다.
---
시험에서 자주 헷갈리는 선택 기준
시나리오 1: 관리 작업 감사
"에이전트 없이, 추가 설정 없이 리소스 배포 이력을 즉시 조회" — Azure Activity Log입니다. 기본 90일 자동 보존되며, 여러 구독의 Activity Log를 월간 보고서로 집계하려면 Log Analytics로 연동해 KQL 쿼리를 사용합니다.
시나리오 2: 코드 변경 없는 성능 분석
"코드 변경 없이 트랜잭션 수준 응답 시간과 의존성 호출 분석" — Application Insights 코드리스 연결이 정답입니다. Azure Monitor 메트릭 경고는 집계 수준 경고에 특화되어 트랜잭션 단위 세부 추적에는 적합하지 않습니다.
시나리오 3: 진단 설정 다중 대상
"실시간 모니터링(Log Analytics)과 장기 아카이브(Storage Account)를 동시에" — 단일 진단 설정에서 두 대상을 동시 지정합니다. 두 팀이 각각 독립된 작업 영역을 원한다면 진단 설정 두 개를 별도로 만들어 각각 다른 작업 영역을 지정합니다.
시나리오 4: AD 동기화 전용 모니터링
"Entra ID 동기화 오류를 전용으로 모니터링" — Microsoft Entra Connect Health가 정답입니다. Azure Monitor는 범용 플랫폼으로 AD Connect 동기화에 특화된 심층 가시성을 제공하지 않습니다. Entra Connect Health는 Entra ID P1/P2 라이선스가 필요하며, 에이전트 설치만으로 동기화 오류·지연·개체 불일치를 자동 감지합니다.
시나리오 5: 마이크로서비스 맵과 사용자 분석
"서비스 간 의존성 맵, 분산 추적, 사용자 분석을 단일 서비스에서" — Application Insights입니다. Azure Monitor는 인프라 메트릭·로그 중심, Application Insights는 애플리케이션 성능과 사용자 행동 분석 중심입니다.