FortiGate SD-WAN 실전 구성하기 — SLA Monitor 기반 자동 경로 변경과 장애 대응

FortiGate SD-WAN 실전 구성하기 — SLA Monitor 기반 자동 경로 변경과 장애 대응 이미지

SD-WAN은 단순히 두 회선을 묶는 기능이 아니라, 실시간 품질 측정을 통해 트래픽이 갈 방향을 스스로 결정하는 구조입니다. 그런데 많은 엔지니어들이 “SD-WAN을 켰다”는 말만 듣고, 내부 SLA Probe가 어떤 패킷을 던지고 어떤 기준으로 경로를 바꾸는지 모른 채 운영합니다. 그러다 한쪽 회선이 미세하게 불안정해지면, 사용자는 끊김을 호소하고 엔지니어는 새벽에 전화기를 받게 되죠. 핵심은 Health Check → SLA Target → Performance SLA → SD-WAN Rule이 어떻게 연결되는지 정확히 이해하는 겁니다.

SD-WAN을 처음 도입하는 현장에서는 단순히 두 회선 사이의 로드밸런싱 정도만 기대하는 분들이 많더라고요. 그러나 진짜 가치는 회선 품질이 흔들릴 때 자동으로 우회하고, 복구되면 다시 원래 경로로 돌아오는 데 있습니다. 그 중심에 있는 SLA Monitor를 모르고 CLI 몇 줄 따라치기 수준으로 끝내면, 장애 상황에서 큰 코를 다치게 됩니다.

SD-WAN이란 무엇이며 기존 WAN과 어떻게 다른가

기존 WAN은 ISP 회선 단위로 정적 라우팅 또는 PBR(Policy-Based Routing)을 걸어두는 방식이었습니다. 회선 1이 살아있으면 회선 1로, 죽으면 관리자가 수동으로 회선 2로 라우팅 메트릭을 바꾸는 구조였죠. SD-WAN은 이걸 실시간 품질 측정 기반으로 자동화한 것이라고 보면 됩니다. FortiGate에서는 이 기능을 SD-WAN Zone + Member 구조로 추상화해서 제공합니다.

SD-WAN Zone와 Member의 의미

SD-WAN Zone는 논리적인 인터페이스 묶음이고, 그 안에 들어가는 각각의 ISP 회선이 Member입니다. Zone 기반 방화벽 정책이 가능하기 때문에, 단일 인터페이스로 구성하던 시절에 비해 정책이 훨씬 직관적으로 바뀌었습니다. underlay(물리 인터페이스)와 overlay(논리 Member)가 분리됐다는 점이 핵심입니다.

전통 라우팅과 SD-WAN의 결정적 차이

SLA Monitor의 동작 원리와 핵심 파라미터

Performance SLA는 Health Check가 보내는 Probe(기본 TCP/HTTP/PING/DNS) 패킷의 응답을 기반으로 latency, jitter, packet-loss를 계산합니다. 이 세 가지 지표가 설정한 임계값을 넘어서는 순간, 해당 SD-WAN Member는 후보에서 잠시 제외되고 트래픽은 다른 Member로 흐르게 됩니다. 이게 자동 장애조치의 전부입니다.

반드시 알아야 할 임계값 파라미터

• latency-threshold — 왕복 지연의 상한선. 일반 VoIP 회선은 80ms 이하, 일반 인터넷 회선은 200ms 권장
• jitter-threshold — 지연 편차의 상한선. 화상회의/음성 트래픽에서는 30ms 이내 권장
• packetloss-threshold — 손실률 상한선. 일반적인 트래픽은 2%, 통화 품질은 1% 이하 권장
• interval — Probe 전송 주기. 너무 짧으면 FortiGate 부하, 너무 길면 장애 감지 지연
• failtime-into-sl — 몇 회 연속 실패 시 SLA 미달로 판정할지 결정하는 카운트

저는 이 임계값을 처음엔 vendor 메뉴얼 기본값으로 두는 분들을 많이 봤는데, 그게 화를 부르는 경우가 더 많더라고요. 결국 현장의 링크 품질 데이터 한두 시간 모아서 그에 맞춰 조정해야 합니다. 너무 엄격하면 잦은 플랩, 너무 느슨하면 장애를 못 잡고, 밸런스를 잡는 게 핵심입니다.

FortiGate SD-WAN 실전 구성 7단계

아래 순서는 실제 현업에서 ISP 회선 2개(예: KT, LG U+)를 대상으로 SD-WAN을 구성하는 흐름인데, 각 단계가 모두 연결되어야 비로소 자동 장애조치가 작동합니다.

STEP 1 — ISP 인터페이스의 기본 IP와 라우트 구성

wan1, wan2 각각에 ISP에서 받은 공인 IP를 할당하고, 각 ISP의 게이트웨이를 가리키는 디폴트 라우트를 작성합니다. 이 단계에서 IP를 잘못 잡으면 이후 어떤 설정도 무의미하니까, 가장 신경 써야 할 부분입니다.

STEP 2 — SD-WAN Zone와 Member 생성

가상의 SD-WAN Zone(보통 virtual-wan-link)을 만들고, 그 안에 wan1과 wan2를 Member로 등록합니다. CLI 기준으로는 config system sdwan 안에서 config members로 정의합니다.

STEP 3 — Health Check 정의

Probe 종류(ping, http, dns, tcp), 대상 서버, interval, failtime 등을 정의합니다. 대상 서버는 회선 품질 측정에 의미 있는 곳이어야 합니다. ISP의 자체 DNS나, 사내 데이터센터 IP, SaaS endpoint IP를 추천합니다.

STEP 4 — Performance SLA 작성

Health Check를 어떤 Member들에 적용할지, 그리고 latency·jitter·packet-loss 임계값을 어떻게 잡을지 결정합니다. 여기서 너무 빡빡한 임계값을 잡으면 빈번한 플랩이 발생합니다.

STEP 5 — SD-WAN Rule(서비스 경로 규칙) 생성

어떤 애플리케이션/소스/목적지 조합이 어떤 Member를 우선으로 사용할지 결정합니다. 우선순위(preferred-member)와 가중치(weight)를 조합해서 SLA 링크와 Tie-break를 정의합니다.

STEP 6 — 방화벽 정책에서 SD-WAN Zone 활용

정책을 만들 때 incoming interface는 LAN, outgoing interface는 SD-WAN Zone을 지정합니다. 특정 Member로 강제 보내고 싶을 때만 개별 인터페이스를 선택합니다.

STEP 7 — 검증과 모니터링

diagnose sys sdwan member, diagnose sys sdwan health-check 명령으로 현재 SLA 상태와 Member 상태를 확인합니다. Configurate는 끝났다고 해도, 운영 검증 절차가 빠지면 본인의 구성인지 의심스럽습니다.

자동 경로 변경이 실제로 일어나는 시나리오

Resort 사무실에서 KT 회선을 메인으로, LG U+ 회선을 백업으로 둔 구성을 예시로 들어보겠습니다. 평상시엔 모든 트래픽이 KT로 나갑니다. 어느 날 KT 회선의 latency가 50ms에서 300ms로 뛰고, packet-loss가 5%를 넘으면 어떻게 될까요?

SLA Probe가 임계값 위반을 감지하는 순간

Health Check의 Probe는 매 interval(예: 500ms)마다 응답을 측정하고, 설정한 failtime-into-sl 횟수만큼 연속 임계 초과가 일어나면 그 Member는 SLA 미달로 표시됩니다. 이때 SD-WAN Rule이 정의한 preferred-member 후보에서 자동으로 빠지고, 살아있는 Member로 트래픽이 넘어갑니다.

회선 복구 시 Stickiness로 복귀

KT 회선이 복구되었을 때, 설정한 recovery-time(예: 5분) 동안 SLA가 안정적으로 충족되면 다시 preferred-member로 복귀합니다. 이 복귀 과정에서 Stickiness가 작동해서 기존 세션이 끊기지 않도록 합니다. 이게 단순 라우팅 failover와 SD-WAN의 결정적 차이입니다.

실무에서 자주 발생하는 실패 사례와 회복 전략

실제 현장에서 제가 본 가장 흔한 사고는 SLA 임계값을 너무 빡빡하게 잡아둔 경우

“30분마다 회선이 바뀌는데 왜 그래요?”라는 고객 컴플레인에서 시작됐습니다.

어느 회사에서 SD-WAN을 처음 도입하면서 latency-threshold를 50ms, packet-loss-threshold를 0.5%로 잡아뒀습니다. 평일 낮 시간엔 문제없이 잘 동작했지만, 출퇴근 시간 ISP 회선 품질이 미세하게 떨어질 때마다 SLA 미달 판정이 떨어졌습니다. 회선이 살아있는데도 자동 우회가 일어나니, 통화 중이던 VoIP 세션이 끊기고, 화상회의가 30분마다 한 번씩 짜증나게 다시 연결됐죠.

문제의 근본 원인은 무엇인가

• latency-threshold 50ms는 일반적인 국내 ISP 회선 기준 너무 엄격한 수치였습니다. 실제 peak 시간엔 60~80ms가 흔한데, 그러면 SLA가 거의 매시간 위반 상태로 들어갑니다.
• failtime-into-sl을 3회로 짧게 잡아둬서, 1.5초 일시 지연에도 SLA 미달로 판정되었습니다.
• interval은 500ms로 짧았고, 동시에 여러 Health Check를 정의해서 FortiGate CPU에도 부담이 갔습니다.

이 문제를 해결한 단계별 접근

첫째, 한 주간 평일/주말/peak/off-peak 시간대의 latency/jitter/loss 데이터를 수집했습니다. 둘째, 그 데이터를 기반으로 latency-threshold를 200ms, packet-loss-threshold를 2%로 완화했습니다. 셋째, interval을 1000ms로 늘리고 failtime-into-sl을 5회로 조정했습니다. 결과: 경로 플랩이 사라지고, 실제 회선 장애 시에만 우회가 동작했습니다. 핵심은 벤더 권장값이 아니라 그 회선의 실제 품질 데이터를 보고 결정하는 것입니다.

FortiGate SD-WAN vs 다른 솔루션 비교

SD-WAN 시장에서 자주 비교되는 솔루션들과 FortiGate의 차이를 정리하면, 어떤 환경에 어떤 제품이 어울리는지 판단이 쉬워집니다.

솔루션별 핵심 비교

FortiGate SD-WAN만의 차별화 포인트

FortiGate SD-WAN의 진짜 강점은 보안 기능과 SD-WAN이 한 박스에서 동작한다는 점입니다. 다른 솔루션들은 보안과 SD-WAN을 별도 구매·연동해야 하지만, FortiGate는 SD-WAN Rule과 방화벽 정책이 같은 인터페이스에서 작성되고, IPS·안티바이러스·URL 필터링이 자동으로 SD-WAN 트래픽에 적용됩니다. 지사/소규모 본사 단일장비 환경에서는 도입 비용과 운영 복잡도 모두 낮출 수 있습니다.

자주 묻는 질문

FortiGate SD-WAN은 단순한 회선 다중화가 아니라, 사용자가 체감하는 품질을 실시간으로 보면서 트래픽이 갈 길을 스스로 결정하는 시스템입니다. SLA Monitor의 임계값을 회선 데이터 기반으로 조정하고, Health Check 대상을 의미 있는 곳으로 두고, Stickiness 설정을 이해하는 것. 이 세 가지가 갖춰지면, 새벽에 장애 전화가 줄어드는 진짜 운영 효율을 경험하게 됩니다. 한 번에 모든 걸 완벽하게 가져가려 하지 말고, 작은 지사부터 file럿 구성하면서 팀의 노하우로 녹여보시길 권합니다.