FortiGate SD-WAN 장애 원인 분석용 SLA 헬스체크, 성능 로그, 진단 도구의 평면 배치
글 요약
FortiGate SD-WAN 장애 분석은 단순한 ping 확인이 아니라 SLA Health Check, Performance SLA 로그, 인터페이스 통계를 동시에 교차 검증해야 정확합니다. 이 글에서는 실무에서 자주 발생하는 장애 패턴과 진단 절차, 그리고 다른 모니터링 도구와의 차이점을 정리합니다.
“SD-WAN 회선은 살아 있는데 서비스가 끊겨요”
SLA Health Check와 Performance Log를 제대로 읽지 못하면 원인 없는 downtime이 반복되더라고요. 이 글에서 FortiGate가 제공하는 진단 체계의 핵심을 단계별로 짚어드립니다.
SD-WAN은 두 개 이상의 회선을 동시에 사용하면서 트래픽을 분산시키는 구조라, “회선이 살아 있는데 트래픽이 느린” 상황이 빈번하게 발생합니다. 일반적인 ping 모니터링만으로는 실제 서비스 품질을 파악할 수 없거든요. 특히 VoIP나 영상회의 같은 실시간 트래픽은 패킷 손실률 1%만 있어도 체감 품질이 급격히 떨어지더라고요. FortiGate는 이런 상황을 위해 SLA Health Check와 Performance SLA라는 이중 진단 체계를 제공합니다.
📌 이 글의 핵심 정리
- SD-WAN 장애의 본질은 회선 up/down이 아니라 품질 저하를 감지하는 데 있습니다.
- FortiGate의 Health Check는 link 상태, Performance SLA는 품질 지표를 각각 담당합니다.
- 장애 진단은 인터페이스 통계 → SLA 이력 → 패킷 캡처 순서로 좁혀가는 게 효율적입니다.
- latency, jitter, packet loss 세 지표는 반드시 함께 해석해야 오진을 피할 수 있습니다.
- 외부 NMS와 FortiGate 내장 진단은 상호 보완적이며, 단독 사용은 한계가 있습니다.
SD-WAN 장애, 왜 진단이 어려운가
SD-WAN 구조의 복잡성
일반적인 라우팅은 단일 경로로 트래픽을 보내기 때문에 문제가 생기면 인터페이스 down 여부만 확인하면 됐습니다. 그런데 SD-WAN은 여러 회선이 동시에 active 상태일 수 있고, 정책에 따라 일부 트래픽은 회선 A로, 다른 트래픽은 회선 B로 분산됩니다. 이 때문에 같은 회선이라도 서비스별로 체감 품질이 다르게 나타나더라고요.
특히 SD-WAN 정책 라우팅이 적용된 트래픽의 경우, 사용자는 “인터넷이 안 된다”고 표현하지만 실제로는 특정 destination에 대한 경로만 문제가 있는 경우가 많습니다. 이런 상황에서는 단순한 traceroute 결과만으로는 어디서 손실이 발생하는지 알 수 없거든요.
일반적인 모니터링의 한계
ping이 성공한다고 회선이 정상이라고 단정하면 안 됩니다. ICMP는 우선순위가 낮아 운영 트래픽에 영향을 주지 않으면서도 회선 품질 저하를 놓치는 경우가 많거든요. 실제로 jitter나 packet loss가 증가해도 ping RTT는 정상으로 보이는 케이스를 여러 번 접했습니다. VoIP 품질은 MOS 점수 3.5 이하로 떨어져도 ping은 멀쩡하게 응답하던 사례가 대표적이더라고요.
SLA Health Check 설정과 동작 원리
FortiGate SD-WAN 장애 분석용 방화벽 LED와 케이블 측면 클로즈업
Health Check 프로토콜 종류
FortiGate가 지원하는 Health Check 방식은 크게 ping, TCP echo, UDP echo, HTTP 세 가지입니다. 단순 가용성만 확인하려면 ping으로 충분하지만, 실제 서비스 품질까지 보려면 TCP/HTTP 기반 probe가 효과적입니다. HTTP probe의 경우 응답 코드까지 검증할 수 있어 backend 서비스의 이상까지 감지할 수 있거든요.
- ping: 가장 가벼움. ICMP 차단 환경에서는 사용 불가.
- TCP echo: TCP/80, TCP/443 등 실제 서비스 포트까지 검증.
- HTTP: 응답 코드(200, 302 등)와 본문 문자열까지 매칭 가능.
SLA Targets 핵심 파라미터
SLA 설정에서 가장 자주 놓치는 부분이 interval과 faildetect threshold입니다. interval을 너무 길게 잡으면 장애 감지가 늦어지고, 너무 짧게 잡으면 일시적 네트워크 변동에 과민하게 반응합니다. 실무에서는 보통 500~1000ms 간격에 faildetect 5회 정도로 설정하는 게 안정적이더라고요.
⚠️ SLA 설정 주의
- probe-target을 사내 서버 IP로 지정하면 해당 서버 장애와 회선 장애가 섞여 보입니다. ISP 게이트웨이나 공개 DNS 같은 외부 안정 IP를 함께 사용하세요.
- interval을 5초 이상으로 두면 failover가 사용자 체감 후 30초 이상 늦어질 수 있습니다.
Performance SLA 로그 읽는 법
핵심 CLI 명령어
장애가 발생했을 때 가장 먼저 실행하는 명령은 diagnose sys sdwan health-check입니다. 이 명령은 현재 모든 SD-WAN 멤버의 SLA 상태, latency, jitter, packet loss를 한 화면에 보여줍니다. 실시간 진단이므로 자동화 스크립트에 넣어서 주기적으로 모니터링하는 것도 가능하거든요.
실무에서 자주 사용하는 명령어 모음
- diagnose sys sdwan health-check: 현재 SLA 상태 실시간 확인.
- diagnose sys sdwan member: SD-WAN 멤버별 우선순위 및 상태.
- diagnose sys sdwan service: 서비스별 라우팅 상태와 세션 카운트.
- diagnose sys sdwan log: SLA 변경 이벤트 이력 추적.
로그 항목별 의미
Performance SLA 로그에서 가장 중요한 세 가지 지표는 latency, jitter, packet loss입니다. latency는 왕복 지연, jitter는 지연 변동폭, packet loss는 손실 비율을 의미합니다. 이 중 어느 하나만 봐서는 원인 규명이 어렵고, 세 지표를 동시에 비교해야 ISP 회선 문제인지 서버 응답 문제인지 구분할 수 있거든요.
실제 장애 사례 분석 — VoIP 끊김 사건
사례: 매일 오후 3시에만 VoIP가 끊기는 현상
실제로 겪었던 사례입니다.某 고객사는 두 회선(A, B)을 SD-WAN으로 묶어 사용하고 있었는데, 매일 오후 3시쯤 VoIP 품질만 급격히 떨어졌습니다. ping 모니터링은 정상이었고, ISP에 문의해도 “회선에는 문제 없다”는 답변만 돌아왔습니다. 결국 한참을 헤맨 끝에 원인을 찾았는데, 바로 SLA Health Check의 interval이 5000ms로 설정되어 있어 품질 저하를 30초 이상 늦게 감지하고 있었던 것이었습니다. failover가 동작하기까지 30~40초가 소요되면서 그 사이 VoIP 패킷이 손실된 거였죠.
노하우: 근본 원인 규명 절차
이 사례를 통해 배운 교훈은, Health Check 결과만 믿지 말고 Performance SLA의 latency/jitter 추이를 시간대별로 그래프로 그려봐야 한다는 점이었습니다. 시간대별 그래프를 그려보니 오후 3시쯤 회선 A의 jitter만 200ms 이상으로 치솟는 패턴이 명확히 보였습니다. 결국 interval을 500ms로 줄이고 faildetect threshold를 5로 조정한 뒤, 동시에 jitter 임계값을 SLA에 추가해 능동적으로 회선을 회피하도록 구성하니 문제가 사라졌더라고요.
💡 SD-WAN 장애 분석 노하우
- 장애가 특정 시간대에만 발생한다면 시간대별 latency/jitter 그래프를 반드시 작성하세요. 단일 snapshot만으로는 패턴을 놓칠 수 있습니다.
- Health Check와 Performance SLA의 두 가지를 동시에 확인하세요. link down은 Health Check로, 품질 저하는 Performance SLA로 분리해서 봅니다.
FortiGate 내장 진단 vs 외부 모니터링 도구 비교
FortiGate 내장 도구의 강점
FortiGate의 SD-WAN 진단은 장비 내부에서 동작하므로 외부 NMS처럼 별도 collector를 두지 않아도 됩니다. CLI 한 줄로 회선별 latency, jitter, packet loss를 즉시 확인할 수 있고, FortiAnalyzer와 연동하면 장기 이력도 그래프로 분석할 수 있거든요. 무엇보다 SD-WAN 정책과 직접 연동되어 자동으로 failover를 트리거한다는 점이 결정적인 장점입니다.
외부 NMS(예: PRTG, SolarWinds)와의 차이
외부 NMS는 다양한 벤더 장비를 통합 모니터링할 수 있다는 강점이 있지만, SD-WAN 정책과 직접 연동되지 않아 자동 failover는 어렵습니다. 또한 collector가 외부에 있으면 collector 자체의 회선 품질에 영향을 받는다는 함정이 있죠. 결국 두 가지를 병행 사용하는 게 가장 효과적이더라고요. FortiGate 내장 진단으로 1차 스크리닝하고, 외부 NMS로 장기 트렌드를 검증하는 식입니다.
| 항목 | FortiGate 내장 진단 | 외부 NMS (PRTG/SolarWinds) | Cisco Viptela vManage |
|---|---|---|---|
| 자동 failover 연동 | 지원 | 미지원 (별도 액션 필요) | 지원 |
| 실시간 CLI 조회 | 가능 (1~2초) | 불가 | 제한적 |
| 장기 트렌드 분석 | FortiAnalyzer 필요 | 기본 제공 | 기본 제공 |
| 타 벤더 장비 통합 | 제한적 | 강점 | 불가 |
| 초기 구성 난이도 | 낮음 (GUI 제공) | 중간 | 높음 |
체계적인 트러블슈팅 절차 한눈에 보기
1단계: 링크 상태 확인
가장 먼저 get system interface physical로 각 WAN 포트의 link 상태를 확인합니다. 여기서 down으로 표시되는 포트가 있으면 SD-WAN 이전 단계의 물리적 문제이므로 케이블, 광모듈, ISP 측 장비부터 점검해야 합니다.
2단계: SLA 이력 분석
diagnose sys sdwan log로 최근 멤버 전환 이벤트를 확인합니다. 특정 시간대에 멤버가 active→standby로 바뀌었다면 그 시점의 latency spike나 packet loss가 원인입니다. log timestamp와 사용자 신고 시각을 매칭하면 패턴이 보이기 시작하거든요.
3단계: 패킷 캡처 및 라우팅 검증
위 단계로도 원인이 명확하지 않다면 diagnose sniffer packet로 실제 패킷을 캡처해 어느 인터페이스로 나가는지 확인합니다. 정책 라우팅이 의도와 다르게 동작하는 경우가 종종 있는데, 이 단계에서 대부분 명확해지더라고요.
자주 묻는 질문
Q. FortiGate SD-WAN에서 Health Check가 no-data로 표시될 때는 어떻게 하나요?
A. probe-target이 응답하지 않는 경우입니다. 먼저 execute ping로 대상 서버가 실제로 응답하는지 확인하고, 방화벽 정책에서 health-check 트래픽이 허용되는지 검토하세요.
Q. latency와 jitter는 어떻게 다른가요?
A. latency는 패킷 왕복 지연의 절대값이고, jitter는 그 latency가 얼마나 들쭉날쭉한지를 나타냅니다. latency가 낮아도 jitter가 크다면 실시간 서비스 품질은 떨어질 수 있습니다.
Q. SD-WAN 멤버가 inactive로 표시되는 원인은 무엇인가요?
A. 대부분 SLA fail이 지속되어 standby로 전환된 경우입니다. 또한 방화벽 정책이 해당 인터페이스에서 트래픽을 차단하면 세션이 생성되지 않아 inactive로 보일 수도 있습니다.
Q. FortiAnalyzer 없이도 Performance SLA 이력을 분석할 수 있나요?
A. CLI의 diagnose sys sdwan log 명령으로 최근 이벤트 이력은 확인할 수 있지만, 장기 트렌드 분석에는 한계가 있습니다. 장기 모니터링이 필요하다면 FortiAnalyzer 도입을 권장합니다.
SD-WAN 장애 진단에서 가장 중요한 건 회선이 살아 있다는 사실만으로 정상이라고 판단하지 않는 마인드셋입니다. Health Check와 Performance SLA, 인터페이스 통계를 함께 보는 습관이 결국 downtime을 줄이는 핵심이더라고요. 오늘 정리한 절차를 팀 내 runbook으로 만들어두시면 장애 대응 속도가 한층 빨라질 겁니다.
면책조항: 본 글의 내용은 정보 제공 및 교육 목적으로 작성되었으며, 특정 환경에서의 동작을 보장하지 않습니다. FortiGate 펌웨어 버전, 네트워크 토폴로지, ISP 회선 품질에 따라 실제 결과는 달라질 수 있습니다. 프로덕션 환경에 적용하기 전에는 반드시 테스트 환경에서 검증하시길 권장드립니다.
