대다수의 인프라 엔지니어링은 트래픽 폭증을 방어하는 데 집중되어 있습니다. 대규모 할인 행사나 스포츠 결승전처럼 수십만 명의 사용자가 일시에 몰려드는 순간 서버가 뻗지 않도록 수평 확장(Scale-out)을 구성하고 대역폭을 확보합니다. 트래픽이 치솟는 상황은 위험하지만, 최소한 그 위험의 방향성은 예측 가능합니다.
하지만 반대의 상황은 어떨까요. 수많은 사용자가 예고도 없이 동시에 스크린을 끄고 접속을 끊었다가, 정확히 수 분 뒤 한꺼번에 원래 자리로 돌아와 새로고침을 누르는 상황입니다. 우리는 흔히 트래픽이 줄어드는 구간을 안전한 휴식기로 착각하지만, 분산 시스템 관점에서 통제되지 않은 급격한 트래픽 급락과 즉각적인 반등은 인프라의 가장 취약한 연결고리를 강타하는 치명적인 파동이 됩니다.
자연 현상이 만들어낸 이 극단적인 트래픽 패턴은 현대 클라우드 아키텍처가 맹신해 온 자동 확장 정책과 캐시 관리 전략의 맹점을 고스란히 드러냅니다. 수치 기반의 오토스케일링이 실제 사용자 행동의 비선형성을 어떻게 오판하는지, 그리고 왜 빠른 축소가 오히려 가용성을 파괴하는지 면밀히 살펴볼 필요가 있습니다.
태양의 가려짐과 완벽히 동기화된 인터넷 트래픽의 침묵
Cloudflare Blog에 따르면 8월 12일 유럽 대륙을 관통한 개기일식 동안 아이슬란드, 스페인, 포르투갈을 중심으로 유례없는 네트워크 트래픽 급락 현상이 기록되었습니다. 20년 만에 유럽 본토를 지나간 개기일식을 보기 위해 수백만 명의 시민들이 야외로 쏟아져 나왔고, 그 순간 지상 네트워크의 HTTP 요청량은 비정상적인 골짜기를 형성했습니다.
Cloudflare Radar가 해당 지역의 HTTP 요청량을 5분 단위 버킷으로 나누어 평상시 기준선과 비교 분석한 데이터는 놀라울 정도로 정밀했습니다. 태양과 달의 겉보기 시직경 및 천구상 거리를 계산해 5분마다 도출한 식의 차폐율(Obscuration) 그래프와 국가별 트래픽 감소 곡선이 완벽하게 겹쳐졌습니다. 개기일식의 중심 경로에 위치했던 지역들은 평소 대비 트래픽이 15%에서 30%가량 급감했으며, 지역에 따라서는 최저 -46.7%에 달하는 극단적인 하락 폭을 기록했습니다. 반면 차폐율이 낮았던 스웨덴, 덴마크, 폴란드 등에서는 트래픽 변화가 거의 나타나지 않았습니다.
더욱 주목할 점은 복귀 속도였습니다. 달이 태양을 최대로 가리는 식의 정점(Maximum Eclipse)을 지나 태양이 다시 모습을 드러내자마자, 불과 수 분 만에 트래픽은 가파른 수직 상승 곡선을 그리며 평소 수준으로 반등했습니다. 사람들은 일식이 끝나자마자 일제히 스마트폰을 켜고 현장 사진을 업로드하거나 메신저로 대화를 재개했습니다. 자연의 시계가 인간의 스크린 타임에 전례 없는 동기화 파동을 일으킨 셈입니다.
급격한 트래픽 축소가 촉발하는 인프라 스케일 인의 위험
이러한 급락 후 급반등 패턴은 쿠버네티스의 HPA(Horizontal Pod Autoscaler)나 클라우드 공급자의 오토스케일링 그룹이 가장 취약하게 반응하는 구간입니다. 대부분의 팀은 인프라 비용 최적화를 위해 CPU 사용률이나 초당 요청 수(RPS)가 떨어지면 지체 없이 파드나 가상머신을 줄이도록 스케일 인(Scale-in) 정책을 설정해 둡니다.
트래픽이 30%에서 40% 이상 빠져나가는 10~15분 동안, 오토스케일러는 유휴 자원이 발생했다고 판단하여 활성 노드와 컨테이너를 공격적으로 제거합니다. 문제는 바로 그 직후입니다. 트래픽이 완만하게 회복되는 것이 아니라 전원이 동시에 켜지듯 수 분 만에 급반등하면, 축소된 인프라는 순식간에 임계치를 초과하는 요청 폭격을 맞게 됩니다.
yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: core-api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: core-api
minReplicas: 10
maxReplicas: 100
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
behavior:
scaleDown:
stabilizationWindowSeconds: 600
policies:
- type: Percent
value: 10
periodSeconds: 60
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Percent
value: 100
periodSeconds: 15
이 과정에서 시스템은 연쇄 장애의 늪에 빠집니다. 급증한 요청에 대응해 스케일 아웃이 트리거되더라도, 컨테이너 이미지를 풀링하고 런타임을 구동하며 헬스 체크를 통과하는 데는 물리적인 부팅 시간(Cold Start)이 소요됩니다. 신규 노드가 준비되지 않은 상태에서 살아남은 소수의 파드에 트래픽이 집중되고, 이 파드들이 OOM(Out of Memory)이나 CPU 스로틀링으로 연쇄 다운되면 유입 트래픽 전체가 500 에러로 터져 나가는 참사가 벌어집니다.
동시에 백엔드 데이터베이스 연결 풀(Connection Pool)의 고갈 현상이 발생합니다. 파드가 급격히 종료되면서 커넥션이 정리되는 과정에서 커넥션 리크가 발생하거나, 갑자기 수십 개의 파드가 동시 기동하면서 데이터베이스로 수천 개의 신규 연결 핸드셰이크를 요청하는 순간 DB의 CPU 사용률은 천장을 치게 됩니다.
반등 파동을 방어하는 스케일링 지연과 캐시 계층의 재설계
이처럼 트래픽의 급격한 골짜기와 급반등이 예상되는 환경에서는 스케일링 정책의 기본 철학을 비대칭적으로 재설계해야 합니다. 비용 절감을 위한 공격적인 스케일 인보다, 가용성 보존을 위한 보수적인 안정화 기간(Stabilization Window) 확보가 선행되어야 합니다.
쿠버네티스 HPA의 behavior.scaleDown.stabilizationWindowSeconds 설정을 최소 600초(10분) 이상으로 길게 유지하여, 일시적인 트래픽 하락을 즉각적인 인프라 축소로 연결하지 않는 완충 지대를 두어야 합니다. 또한 한 번에 축소할 수 있는 파드의 최대 비율을 10% 미만으로 제한하여 단계적인 스케일 인을 유도해야 급작스러운 부하 복귀 시에도 최소한의 완충 인스턴스가 요청을 받아낼 수 있습니다.
캐시 계층의 스탬피드(Cache Stampede) 현상 방어도 필수적입니다. 수십 분간 트래픽이 빠진 사이 엣지 CDN과 인메모리 캐시의 주요 키들이 TTL(Time-to-Live) 만료로 증발할 수 있습니다. 캐시가 비어 있는 상태에서 사용자들이 동시에 복귀하면 모든 요청이 캐시를 뚫고 오리진 백엔드 서버로 직격합니다.
이를 막기 위해서는 엣지 계층에서 Stale-While-Revalidate 전략을 적극적으로 적용해야 합니다. 캐시가 만료되었더라도 백엔드에서 새 데이터를 가져오는 동안 클라이언트에게는 만료된 데이터를 즉시 응답하고, 백그라운드에서 비동기로 캐시를 갱신하여 오리진으로 향하는 스파이크를 원천 차단해야 합니다.
엣지 워커를 활용해 급격한 트래픽 유입 구간에서 유입률을 초 단위로 모니터링하고, 백엔드의 수용 한계를 넘어서는 순간 정적 대기열이나 서킷 브레이커를 즉시 작동시키는 엣지 레이트 리미팅(Edge Rate Limiting) 역시 강력한 방어선이 됩니다.
비정형 사용자 행동을 견디는 아키텍처의 설계 기준
모든 인프라 엔지니어링에는 비용과 안정성 사이의 트레이드오프가 존재합니다. 트래픽 급락 시 인프라를 줄이지 않고 유지하는 것은 단기적으로 클라우드 비용의 낭비처럼 보일 수 있습니다. 핀옵스(FinOps) 관점에서는 유휴 자원을 1분 1초라도 빨리 회수하는 것이 미덕으로 여겨지기 쉽습니다.
하지만 인스턴스 몇 개를 일찍 내려서 아끼는 몇 달러의 비용보다, 트래픽 반등 시 발생하는 수 분간의 전면 서비스 장애가 비즈니스에 미치는 손실이 비교할 수 없을 만큼 큽니다. 특히 런타임 초기화 비용이 크거나 데이터베이스 쓰기 부하가 높은 모놀리스 및 무거운 마이크로서비스 아키텍처라면, 스케일 인 정책은 지나칠 정도로 둔감하게 설정하는 것이 기술적으로 안전한 선택입니다.
자연 현상이든 사회적 이벤트든, 인간의 행동은 수학적으로 완벽한 선형 그래프를 그리지 않습니다. 트래픽이 언제든 절벽처럼 떨어졌다가 파도처럼 들이닥칠 수 있다는 사실을 아키텍처 레벨에서 인정해야 합니다.
당장 운영 중인 프로덕션 클러스터의 오토스케일링 매니페스트를 열어보시길 권합니다. 축소 지연 시간이 지나치게 짧게 잡혀 있지는 않은지, 엣지 캐시가 만료된 순간을 버텨낼 완충력이 충분한지 점검하는 것만으로도 시스템의 회복 탄력성은 한 단계 높아집니다.
IT & Mind Trends
댓글 0