173. 마이크로버스트 트래픽 스파이크 탐지 (Microburst Traffic Spike Detection)

핵심 인사이트 (3줄 요약)

본질: 마이크로버스트 (Microburst)는 밀리초~수백 밀리초 동안 순간 유입률이 급증해 큐와 버퍼를 넘치게 만드는 짧은 트래픽 폭주로, 분 단위 평균 그래프에는 거의 보이지 않는다.

가치: 마이크로버스트를 따로 관측하면 "평균은 정상인데 P99 (99th Percentile) 지연과 패킷 손실이 튄다"는 간헐 장애의 원인을 설명할 수 있고, 재시도 폭풍과 선더링 허드 (Thundering Herd) 같은 상위 계층 문제까지 드러난다.

판단 포인트: 이 현상은 단순 확장보다 지터 (Jitter), 페이싱 (Pacing), 큐 분산, Explicit Congestion Notification (ECN), Active Queue Management (AQM) 같은 동시성 완화 전략으로 접근해야 효과가 크다.

Ⅰ. 개요 및 필요성

마이크로버스트는 "트래픽이 많다"는 말보다 더 좁고 더 위험한 개념이다. 지속 시간은 아주 짧지만, 그 짧은 순간에 링크가 감당할 수 있는 속도보다 훨씬 많은 패킷이 한꺼번에 몰리면서 스위치 버퍼, Network Interface Card (NIC) 큐, 소켓 버퍼를 순식간에 채운다. 평균값만 보면 멀쩡한데도 패킷 드롭과 순간 지연 급등이 반복되는 이유가 여기에 있다.

예를 들어 1Gbps 링크에 10Gbps 버스트가 100ms 동안 들어오면 초과 유입은 9Gbps × 0.1s = 0.9Gb, 즉 약 112.5MB다. 이 양은 네트워크 장비의 짧은 버퍼를 쉽게 넘길 수 있다. 그런데 같은 현상을 60초 평균으로 보면 약 16.7Mbps 수준으로 희석되어 "거의 아무 일도 없었던 것처럼" 보인다. Site Reliability Engineering (SRE) 관점에서 평균 대시보드만 보면 원인을 놓치기 쉬운 이유다.

마이크로버스트는 네트워크 장비만의 문제가 아니다. 다수 파드가 동시에 같은 데이터베이스로 쓰기 요청을 보내는 팬인 (Fan-in), 만료된 캐시를 향한 동시 요청, 지터 없는 재시도, 정각에 한꺼번에 시작되는 크론 작업도 본질적으로는 같은 패턴이다. 즉 이 주제는 링크 레벨 이슈이면서 동시에 분산 시스템 동기화 실패 문제다.

이 때문에 마이크로버스트를 별도 주제로 다뤄야 한다. 지속 스파이크는 오토스케일링으로 완화할 수 있지만, 아주 짧은 동시 폭주는 스케일아웃이 반응하기 전에 이미 버퍼를 넘쳐 버리기 때문이다. 관측 해상도와 완화 전략이 완전히 다르다.

📢 섹션 요약 비유: 좁은 문을 평소엔 한 명씩 잘 지나가다가, 쉬는 종이 울리는 순간 모두가 동시에 몰려 문 앞이 막히는 상황이 마이크로버스트다. 하루 평균 학생 수를 봐서는 이 혼잡을 절대 설명할 수 없다.

Ⅱ. 아키텍처 및 핵심 원리

마이크로버스트의 본질은 큐 이론으로 간단히 표현할 수 있다. 유입 속도 (arrival rate)가 유출 속도 (service rate)를 아주 짧게라도 크게 넘으면, 그 차이만큼 큐에 쌓인다. 그리고 초과 트래픽 = (유입률 - 유출률) × 지속 시간이 버퍼 크기를 넘는 순간 패킷 손실이나 Head-of-Line Blocking이 발생한다. 지속 시간이 짧아도 차이가 크면 충분히 장애가 된다.

┌────────────────────────────────────────────────────────────────────┐
│                    How a microburst is created                     │
├────────────────────────────────────────────────────────────────────┤
│ sender A ----\                                                     │
│ sender B -----\                                                    │
│ sender C ------> [switch / NIC queue] ---> [1 Gbps egress]        │
│ sender D -----/            │                                       │
│ sender E ----/             ├─ queue grows                         │
│                            ├─ buffer fills                        │
│                            └─ drop / ECN / latency spike          │
└────────────────────────────────────────────────────────────────────┘

관측도 같은 원리로 풀어야 한다. 평균 비트레이트만으로는 부족하고, 큐 깊이, 드롭 카운터, 순간 최대 전송률, 패킷 수, 재전송, Explicit Congestion Notification (ECN) 마크를 함께 봐야 한다. 특히 초당 또는 밀리초 단위 시계열이 없으면 마이크로버스트는 거의 보이지 않는다.

관측 위치	봐야 할 신호	왜 중요한가
스위치 / 로드밸런서	큐 깊이, 드롭, ECN, 포트 utilization max	버스트가 실제로 링크를 넘쳤는지 확인
호스트 NIC	ring buffer drop, packet burst, retransmit	장비 내부에서 흘려보내기 전에 놓치는 지점 확인
애플리케이션	P99 지연, timeout, retry rate, queue length	상위 계층에서 버스트가 어떻게 증폭되는지 확인
커널 / 관측 도구	eBPF (extended Berkeley Packet Filter), sFlow, high-frequency histogram	짧은 순간의 패턴을 고해상도로 포착

또 하나의 핵심은 "어떤 집계 함수가 버스트를 살려 주는가"다. avg와 긴 구간 rate()는 버스트를 평탄화한다. 반면 max, 짧은 버킷 히스토그램, per-second peak, queue depth timeline은 버스트의 실체를 드러낸다. 즉 마이크로버스트 탐지는 데이터 수집 간격과 집계 함수 선택까지 포함한 관측 설계 문제다.

📢 섹션 요약 비유: 마이크로버스트를 찾는 일은 일기예보의 하루 평균 기온이 아니라, 갑자기 내리는 소나기 순간을 보는 것과 같다. 평균 날씨만 봐서는 우산이 왜 필요한지 알 수 없다.

Ⅲ. 비교 및 연결

마이크로버스트는 일반적인 트래픽 스파이크와 닮았지만, 대응 방식은 다르다. 지속 스파이크는 수분 이상 이어져 Central Processing Unit (CPU), 메모리, 스레드 풀이 점진적으로 포화되므로 스케일아웃이나 캐시 확장으로 대응하기 쉽다. 반면 마이크로버스트는 너무 짧아 오토스케일러가 반응하기 전에 큐를 채우고 사라진다. 그래서 "짧지만 깊은" 장애로 봐야 한다.

항목	마이크로버스트	지속 스파이크
지속 시간	ms ~ 수백 ms	수초 ~ 수시간
대표 지표	큐 깊이, 드롭, 순간 max, P99	평균 utilization, 동시성, CPU
주요 피해	패킷 손실, tail latency, timeout	자원 포화, 스케일 부족
우선 대응	지터, 페이싱, 큐 평탄화	스케일아웃, 캐시, 용량 증설

또한 네트워크 마이크로버스트와 애플리케이션 버스트는 서로 영향을 준다. 예를 들어 동일한 시점에 재시도 요청이 몰리면 애플리케이션 큐가 늘고, 그 결과 네트워크 burst도 심해진다. 반대로 짧은 네트워크 지연 급등은 Circuit Breaker의 오탐을 유발하거나, 타임아웃을 증가시켜 재시도 폭풍을 다시 만든다. 즉 하위 계층의 짧은 버스트가 상위 계층의 오류율 상승으로 증폭될 수 있다.

이 연결을 이해하면 평균 중심 관측의 한계도 명확해진다. 평균은 "얼마나 많이 썼는가"에 강하지만, 마이크로버스트는 "얼마나 동시에 몰렸는가"의 문제다. 그래서 히스토그램, 최대값, 큐 길이, 동시성 이벤트가 필요한 것이며, 이것이 tail latency 분석과 직접 이어진다.

📢 섹션 요약 비유: 천천히 길게 이어지는 정체는 차선을 늘리면 도움이 되지만, 신호가 바뀌는 순간 한꺼번에 몰리는 혼잡은 출발 시간을 흩뜨리는 편이 더 잘 듣는다. 같은 교통 문제처럼 보여도 처방전이 다른 셈이다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 먼저 "어디서 버스트가 만들어지는가"를 찾아야 한다. 팬인 구조인지, 정시 배치인지, 무지터 재시도인지, 단일 핫 파티션인지에 따라 처방이 달라진다. 클라우드 환경에서는 네트워크 장비 내부 큐를 모두 볼 수 없는 경우가 많으므로, 호스트 측 eBPF, 애플리케이션 큐 길이, 고해상도 타임아웃 메트릭을 조합해 우회적으로 진단해야 한다.

┌────────────────────────────────────────────────────────────────────┐
│                    Mitigation decision flow                        │
├────────────────────────────────────────────────────────────────────┤
│ synchronized senders?                                              │
│   ├─ yes -> add jitter / stagger schedule                          │
│   └─ no                                                            │
│       │                                                            │
│       ▼                                                            │
│ single hot consumer or partition?                                  │
│   ├─ yes -> shard / queue / spread load                            │
│   └─ no                                                            │
│       │                                                            │
│       ▼                                                            │
│ network queue overflow?                                            │
│   ├─ yes -> pacing / ECN / AQM / token bucket                      │
│   └─ no  -> inspect app timeout and retry policy                   │
└────────────────────────────────────────────────────────────────────┘

실무 대응 매트릭스

원인 패턴	권장 대응	이유
정각 크론, 배치 완료 동시 전송	지터 추가, 스케줄 분산	시작 시점을 흩뜨려 버스트 원인 제거
다수 생산자 → 단일 소비자	큐잉, 샤딩, backpressure	한 지점에 몰리는 팬인 완화
무지터 재시도	exponential backoff + jitter	실패가 또 다른 burst를 만들지 않게 함
링크 레벨 혼잡	token bucket, pacing, ECN, AQM	순간 유입률 자체를 부드럽게 만듦
관측 해상도 부족	1s 이하 계측, 히스토그램, max metric	평균에 숨어 있는 피크를 드러냄

관측 시 주의점

Prometheus가 15초 간격으로만 스크랩되면 10ms 버스트는 보이지 않는다.
max_over_time()과 짧은 구간 레이트를 함께 써야 평균 희석을 줄일 수 있다.
클라우드 관리형 네트워크에서는 장비 큐 대신 재전송, 드롭, tail latency를 우선 본다.
Service Level Objective (SLO) 위반이 간헐적이라면 평균보다 P99, timeout burst, retry burst를 먼저 의심한다.

안티패턴

마이크로버스트를 지속 트래픽 증가로 오인해 무조건 오토스케일링만 늘리는 것
지터 없는 재시도 정책으로 순간 동시성을 더 키우는 것
평균 utilization이 낮다는 이유로 네트워크 병목 가능성을 배제하는 것
짧은 버스트를 볼 수 없는 계측 간격으로 "문제 없음"을 결론내리는 것

기술사 답안에서는 짧은 시간 스케일, 큐/버퍼 관점, 원인 패턴, 완화 기법을 함께 제시해야 한다. 단순 정의보다 "왜 평균에 안 잡히는가"와 "왜 지터와 페이싱이 중요한가"를 써야 실무적 답안이 된다.

📢 섹션 요약 비유: 쉬는 시간 화장실 줄 문제를 해결한다고 화장실 건물만 무조건 늘리는 건 비효율적일 수 있다. 반별로 나가는 시간을 조금만 달리해도 훨씬 큰 효과가 나는 것과 같다.

Ⅴ. 기대효과 및 결론

마이크로버스트를 정확히 관측하면 "가끔만 느리다", "평균은 정상인데 타임아웃이 난다", "패킷 손실이 랜덤하게 보인다" 같은 애매한 증상을 구조적으로 설명할 수 있다. 이는 단순한 원인 찾기를 넘어서, 재시도 정책, 배치 스케줄링, 큐 설계, 네트워크 혼잡 제어까지 함께 개선하는 출발점이 된다. 즉 버스트를 보게 되면 평균 중심 운영에서 tail 중심 운영으로 시야가 넓어진다.

물론 한계도 있다. 밀리초 단위 계측은 데이터 양과 비용이 크고, 클라우드 환경에서는 네트워크 장비 내부 큐를 직접 보기 어렵다. 따라서 모든 환경에서 완벽한 가시성을 기대하기보다, 보이는 신호를 조합해 상관관계를 잡는 접근이 현실적이다. 미래에는 In-Band Network Telemetry (INT), eBPF, 스마트 Network Interface Card (NIC) 같은 기술이 이 간극을 더 줄여 줄 가능성이 크다.

결국 이 주제는 "짧은 네트워크 피크"가 아니라, 순간 동시성이 큐를 무너뜨리는 현상으로 기억해야 한다. 마이크로버스트를 다룬다는 것은 더 빠른 링크만 사는 일이 아니라, 시스템이 한꺼번에 몰리지 않도록 설계하는 일이다.

📢 섹션 요약 비유: 큰 사고는 늘 도로가 하루 종일 막혀서 생기지 않는다. 때로는 아주 짧은 순간 모두가 동시에 핸들을 꺾는 일이 더 위험하듯, 시스템도 순간 동시성이 더 치명적일 수 있다.

📌 관련 개념 맵

개념	연결 포인트
Queue Depth	마이크로버스트가 가장 먼저 드러나는 현장 지표
Tail Latency	짧은 버스트가 P99를 크게 악화시키는 결과
Fan-in	다수 생산자가 한 소비자에 몰리며 burst를 만드는 구조
Thundering Herd	동시 기동·동시 재시도가 burst를 증폭하는 패턴
ECN / AQM	드롭 전에 혼잡을 알리거나 큐를 제어하는 네트워크 기법
eBPF	호스트 수준에서 짧은 패킷 burst를 관측하는 수단
Backpressure	소비자 처리 속도에 맞춰 생산 속도를 늦추는 제어 방식

📈 관련 키워드 및 발전 흐름도

Average utilization monitoring
    │
    ▼
Need for burst-aware visibility
    ├─ queue depth
    ├─ max throughput
    └─ retransmit / drop / timeout burst
    │
    ▼
Root-cause analysis
    ├─ fan-in
    ├─ thundering herd
    └─ retry synchronization
    │
    ▼
Jitter + pacing + queueing + congestion signaling

이 흐름은 네트워크 운영이 평균 사용률 중심 관측에서, 짧은 동시 폭주를 따로 식별하고 제어하는 방향으로 고도화되는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

마이크로버스트는 평소에는 조용한 복도에 쉬는 종이 울리는 순간 모두가 한꺼번에 뛰어나오는 것과 같아요.
복도의 하루 평균 사람 수는 적어 보여도, 그 짧은 순간에는 서로 부딪히고 넘어질 수 있어요.
그래서 사람들을 조금씩 나가게 하거나 줄을 나눠 서게 하면 훨씬 안전해져요.