Microsoft AZ-700: 네트워크 모니터링 및 문제 해결 — 학습 가이드

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure Network Engineer AZ-700 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

관찰 가능성 도구 및 데이터 소스

Azure 네트워킹의 관찰 가능성은 Network Watcher, Azure Monitor (Log Analytics) 및 리소스의 원격 측정 데이터를 중앙 작업 영역이나 스토리지 계정으로 스트리밍하는 진단 설정을 중심으로 이루어집니다. Network Watcher는 패킷 캡처, IP 흐름 확인, 다음 홉, 연결 문제 해결 및 Connection Monitor를 제공합니다. Connection Monitor v2는 다중 엔드포인트, 다중 프로토콜 테스트를 지원하며 결과를 Log Analytics 작업 영역에 저장하여 쿼리 가능한 원격 측정 데이터를 제공합니다. NSG 흐름 로그는 Network Watcher를 통해 활성화되며 JSON 레코드를 스토리지 계정에 기록합니다. Traffic Analytics를 활성화하면(흐름 로그 + Log Analytics 작업 영역 필요) 해당 로그에 애플리케이션/지역 정보 및 시각화가 보강됩니다. Azure Firewall, Application Gateway/WAF, Front Door, 부하 분산 장치의 진단 설정은 신호를 상호 연관시키기 위해 동일한 Log Analytics 작업 영역으로 라우팅해야 합니다. 일반적인 함정으로는 스토리지 계정 방화벽 규칙이 흐름 로그 쓰기를 차단하는 경우, 오래된 테넌트에서 지역별로 Network Watcher를 활성화하는 것을 잊는 경우, 스토리지와 Log Analytics 간의 일관성 없는 보존 정책 등이 있습니다. 비용과 기능 간의 장단점은 명확합니다: 저비용 보관을 위해 원시 로그를 스토리지 계정에 쓰는 것과, 쿼리 및 경고를 위해 Log Analytics로 수집하는 것(비용은 더 높지만 진단 가치는 훨씬 큼) 사이의 선택입니다. 진단 파이프라인이 로그를 쓰고 분석가가 읽을 수 있도록 역할 기반 액세스 제어(필요한 경우 Monitor Reader 및 Storage Blob 데이터 판독기 포함)를 구성해야 합니다.

패킷 캡처, Connection Monitor 및 심층 진단

패킷 수준 문제 해결을 위해, Network Watcher 패킷 캡처(포털/CLI/PowerShell 사용)는 PCAP 파일을 스토리지 계정이나 로컬 VM 파일로 생성합니다. 과도한 스토리지 사용과 성능 영향을 피하기 위해 패킷 캡처 필터(프로토콜, 소스/대상 IP, 포트)와 크기/시간 제한을 구성하십시오. 가속 네트워킹을 사용하는 고처리량 VM의 경우, 호스트 측 패킷 가시성이 제한될 수 있습니다. 오프로드된 패킷을 놓치지 않으려면 VNet TAP을 사용하여 트래픽을 수집기 VM이나 NVA로 미러링하십시오. Connection Monitor는 능동적인 가상 테스트에 사용해야 합니다: 소스 및 대상 엔드포인트(IP, FQDN, 포트)를 정의하고, 테스트 빈도를 선택하며, 다중 세그먼트 진단을 위해 홉별 대기 시간 및 경로 캡처를 활성화하십시오. IP 흐름 확인을 사용하여 특정 5튜플이 NSG/UDR에 의해 허용되는지 또는 거부되는지 확인하고, 다음 홉을 사용하여 효과적인 라우팅을 확인하십시오. 주의할 점: Windows VM에서의 패킷 캡처는 상승된 권한이 필요할 수 있으며 OS 오프로드의 영향을 받을 수 있습니다. 패킷 캡처는 CPU/디스크 집약적일 수 있으므로 대상 필터와 시간 제한을 사용하는 것이 좋습니다. 대규모의 지속적인 패킷 검사를 위해서는 VNet TAP을 PCAP 스트림을 수집할 수 있는 패킷 분석 어플라이언스나 클라우드 SIEM과 함께 사용하십시오.

NSG 흐름 로그, Traffic Analytics 및 보안 진단

NSG 흐름 로그(버전 2)는 타임스탬프, 5튜플, 바이트/패킷 수 및 결정(허용/거부)이 포함된 흐름 레코드를 제공합니다. 페이로드, 애플리케이션 계층 세션 세부 정보 또는 복호화된 TLS는 포함하지 않습니다. Traffic Analytics는 상위 통신 주체, ASN 및 지역 매핑으로 흐름 로그를 보강하며, 이를 위해서는 Log Analytics 작업 영역이 필요합니다. Azure Firewall, Application Gateway/WAF, Azure Front Door는 자체 진단 데이터를 내보냅니다. 통합 쿼리를 위해 이들을 Log Analytics로 보내야 합니다. 중요한 설계상의 함정: NIC 수준에서 적용된 NSG 규칙이 서브넷 수준 규칙보다 우선합니다. 기본 규칙(예: AzureLoadBalancer, 인터넷 규칙)이 존재하며 제거할 수 없고, 더 높은 우선순위의 규칙으로만 재정의할 수 있습니다. 흐름 로그는 보존 및 수집 전략만큼만 유용합니다—Log Analytics에서의 장기 보존은 비용이 많이 들고, 단기 보존은 포렌식 증거를 잃을 위험이 있습니다. 측면 이동이나 데이터 반출을 탐지하려면 NSG 흐름 로그를 방화벽 진단 로그 및 Kusto 쿼리 기반 경고 규칙과 결합하십시오. 해결 조치를 계획할 때, SNAT 포트 고갈을 완화하기 위해 Azure Firewall에 전용 공용 IP를 추가하는 것을 고려하고, Log Analytics 비용이 너무 비싸다면 DiagnosticSettings를 활용하여 SIEM 통합을 위해 Event Hubs로 라우팅하는 것을 고려하십시오.

문제 해결 패턴, 라우팅 함정 및 설계 트레이드오프

연결 문제를 해결할 때는 계층적 접근 방식을 따르십시오. 리소스 수준의 NSG/UDR을 확인하고, 유효 경로와 다음 홉을 점검하고, IP Flow Verify와 Connection Troubleshoot을 사용한 후, 필요한 경우 패킷 캡처 또는 VNet TAP으로 에스컬레이션합니다. 라우팅 함정은 강제 터널링, 중첩된 CIDR 또는 적절한 반환 경로 없이 트래픽을 AzureFirewallSubnet으로 보내는 잘못 구성된 UDR에서 자주 발생합니다. 부하 분산 및 확장을 위해서는 L4와 L7 요구 사항, 그리고 글로벌 트래픽 관리와 지역 트래픽 관리 중 무엇이 필요한지에 따라 Azure Standard Load Balancer, Application Gateway WAF, Front Door 중에서 선택하십시오. 다음 SKU 트레이드오프를 고려하십시오.

Azure Firewall Standard vs Premium: Premium은 더 높은 비용으로 TLS 검사, IDPS 및 URL 필터링을 추가합니다. 심층적인 트래픽 검사와 규제 제어가 필요할 때 Premium을 선택하십시오.
Azure Front Door Standard vs Premium: Premium은 고급 WAF 기능과 프라이빗 링크 통합을 지원합니다. Standard는 일반적인 글로벌 CDN + 라우팅에 대해 더 저렴합니다.
VNet TAP vs packet capture: TAP은 비용이 더 높지만, 대규모 무손실 캡처 및 가속 네트워킹이 패킷을 오프로드할 때 필요합니다. 트레이드오프는 성능, 비용, 복원력을 중심으로 이루어집니다. NVA는 Firewall Premium보다 저렴하거나 기능이 더 풍부할 수 있지만, HA로 설계되지 않으면 관리 오버헤드와 단일 장애 지점(SPOF) 위험이 추가됩니다. SNAT 용량을 계획하고, 여분의 공용 IP를 예약하고, 진단 파이프라인을 단계적으로 구축하여 관찰 가능성 요구 사항과 수집 비용 간의 균형을 맞추십시오.

실제 문제: 사용 사례 시나리오

시나리오: Contoso Electronics는 두 개의 Azure 리전(EastUS, WestEurope)에서 허브-스포크 VNet, 허브의 Azure Firewall Standard, 여러 스포크의 Application Gateway WAF, 그리고 모니터링을 위한 중앙 Log Analytics 작업 영역을 운영하고 있습니다. 최근에 스포크에 배포한 프로덕션 VM 세트에서 ExpressRoute 회선을 통해 온프레미스 SQL 클러스터에 도달하는 데 간헐적인 장애가 보고되고 있습니다.

과제: 명확한 패킷 수준의 증거 없이 온프레미스 리소스에 대한 간헐적인 연결 및 높은 지연 시간 발생. 기존 NSG 흐름 로그는 활성화되어 있지만 허용된 흐름만 표시하고 지연 시간 메트릭은 없음.

권장 접근 방식:

대표 VM에서 온프레미스 SQL FQDN 및 IP로 TCP 포트 1433을 사용하여 Connection Monitor v2를 배포하고, 30초마다 테스트를 설정하고, 결과를 중앙 Log Analytics 작업 영역으로 보내 홉별 지연 시간과 연결 가능성을 캡처합니다.
영향을 받는 VM에서 SQL 클러스터의 소스/대상 IP 및 포트 1433에 대한 필터를 사용하여 Network Watcher 패킷 캡처를 활성화하고, 수명 주기 정책이 있는 스토리지 계정에 PCAP을 저장합니다. 동시에 가속 네트워킹이 있는 경우 스포크 서브넷에서 VNet TAP을 활성화하여 트래픽을 전용 수집기 VM으로 미러링합니다.
Azure Firewall (Standard)의 진단 설정을 구성하여 애플리케이션 및 네트워크 로그를 동일한 Log Analytics 작업 영역으로 보내고, Connection Monitor 결과, 방화벽 로그, NSG 흐름 로그를 조인하는 상관 관계 쿼리를 실행하여 방화벽 SNAT 고갈 또는 정책에 의한 드롭을 탐지합니다.
장애 발생 중 실패하는 5-튜플에 대해 IP Flow Verify 및 Next Hop을 사용합니다. SNAT 또는 비대칭 라우팅이 의심되는 경우, Azure Firewall에 추가 공용 IP를 추가하거나 스포크에 NAT Gateway를 배포하여 예측 가능한 이그레스(egress)를 확보하고 허브를 통해 라우팅하도록 UDR을 업데이트합니다.

근거: Connection Monitor는 합성된 타임스탬프가 있는 연결 가능성 및 홉별 지연 시간을 제공합니다. 패킷 캡처와 VNet TAP은 OS 오프로드가 트래픽을 불분명하게 만들 때 무손실 포렌식 데이터를 제공합니다. Log Analytics에서 방화벽 및 NSG 로그를 상호 연관시키면 정책, SNAT 또는 비대칭 라우팅 문제를 식별할 수 있습니다. 공용 IP 또는 NAT Gateway를 추가하면 포트 고갈을 완화하고 이그레스(egress) 동작을 안정화시킵니다.

← 부하 분산 및 트래픽 관리 · 모든 도메인 · Azure Virtual WAN 및 Hub-Spoke →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →