Incident Library

IL-0568 DeNA · 2026-04-14 (게시일)networking

DeNA의 한 사업장에서 L2 스위치 루프가 생겨 사업장 전체의 단말이 서버에 접속하지 못하거나 통신이 느려졌다

DeNA 네트워크 그룹은 사업장마다 손으로 설정해 온 장비 설정을 모든 사업장에서 통일하고 구성 관리하는 프로젝트를 진행하고 있었다. 엔지니어는 평일 19시쯤 원격으로 한 사업장의 L2 스위치 Cisco Catalyst 2960L 15대에 description 수정, VLAN 정의 추가, Trunk 포트의 허용 VLAN 추가 같은 작업을 시작했다. 엔지니어는 가벼운 작업으로 여겨 시간대도 고려하지 않았고 작업 공지도 하지 않았다. 이 사업장은 DeNA가 운영하는 20곳이 넘는 사업장 가운데 특히 큰 곳이었고 오피스가 아니어서 그 시간에도 영업 중이었다. 작업을 시작하고 몇 분 뒤, SW1-SW2-SW3 순서로 이어진 구성에서 가장 아래에 있는 SW3의 LAG를 이루는 물리 포트 Gi0/15 하나에만 no switchport trunk allowed vlan 이 들어갔다.

20시쯤 현장에서 단말이 서버에 접속하지 못한다는 연락이 왔지만 모니터링 알림은 없었다. 대상 포트에는 처음부터 인터페이스 모니터링이 설정돼 있지 않았고, LACP 모니터링은 직전에 다른 모니터링 설정을 고치다 낸 실수로 꺼져 있었다. 스위치 CPU는 10% 정도만 올라 알림이 울리지 않았다. 21시쯤 엔지니어가 원인을 모른 채 설정을 되돌리다가 장비 한 대의 인터페이스 설정을 되돌리자 통신이 복구됐다. 여러 대를 한꺼번에 바꾼 데다 되돌리는 절차를 만들어 두지 않아 시간이 걸렸다. 22시쯤 원인 지점을 확인하고 다른 영향이 없음을 확인해 1차 대응을 마쳤다.

MACFLAP이 대량으로 나와 루프가 난 것은 분명했지만, Prometheus에서 Gi0/15는 장애 중 ifOperStatus=2 로 down이었고 STP도 켜져 있었다. 실제 장비로 검증해 보니 2960C끼리 연결하거나 2960S가 낀 조합에서는 LAG가 정상적으로 suspend돼 루프가 나지 않았다. 장애 때와 같이 SW2를 2960C, SW3를 2960L로 두고 한 포트의 allowed vlan을 지우자 루프가 재현됐다. 이때 포트는 Status: up, Protocol: down 이면서 down 상태의 포트로 프레임이 지나갔다. STP가 보기에는 이 포트가 down이어서 관리 대상이 아니었고, 정상 링크와 함께 링크 두 개가 열린 상태가 됐다. 2960L은 EoL 제품이고 버그 보고도 찾지 못했으며 장애 당시 버전은 최신이었다. DeNA는 문제가 장비가 아니라 운영에 있었다고 결론 내리고 장비를 교체하지 않았다.

심각도
–
영향 범위
The network of one of DeNA's largest sites; terminals of a customer-facing system could not reach their servers or were very slow, affecting the business of the whole site
영향 사용자
–
지역
–
감지까지
1h
복구까지
2h

증상

평일 20시쯤 사업장 현장에서 고객 업무에 쓰는 특정 시스템의 단말이 통신하지 못해 영업에 문제가 생겼다는 연락이 왔다. 네트워크 그룹의 모니터링에서는 알림이 하나도 울리지 않았다.

현장 연락은 단말 쪽 문제일 수도 있지만 네트워크를 확인해 달라는 내용이었다. 장비 알림이 없었기 때문에 담당 엔지니어는 첫 연락을 받았을 때 자기 작업의 영향일 가능성을 크게 보지 않았다.

조사해 보니 연락을 받기 30분 전부터 사업장 안에서 장애 보고가 나오기 시작했고, 시각은 작업 시작과 맞았다. 일부 단말은 곧 풀렸지만 다른 곳에서는 계속됐고, 특정할 수 없는 여러 단말에서 문제가 났다. 장애가 난 시스템의 단말은 서버에 접속하지 못하거나 접속해도 통신이 매우 느렸다.

사업장 메인 스위치의 CPU 사용률이 알림 기준에는 못 미치지만 올라가 있었고, 사업장에서 MACFLAP 로그가 대량으로 나왔다. 원인은 끝내 특정하지 못했다. 그러나 그 시간에 작업한 사람이 담당 엔지니어뿐이어서, 엔지니어는 자기 작업을 원인으로 보고 되돌리기 시작했다.

증상 간헐적 연결 실패지연 시간 증가

원인

원인 운영 실수

구성 요소 네트워크 스위치
기여 요인 모니터링 사각지대단계적 배포 부재런북 부재피크 시간 변경
촉발
Cisco Catalyst 2960L 15대의 설정을 맞추는 작업에서, SW2와 SW3 사이 LACP LAG를 이루는 물리 포트 두 개 중 SW3 쪽 한 포트에만 no switchport trunk allowed vlan 을 넣어 허용 VLAN 지정을 지웠다.

감지

모니터링 알림은 울리지 않았고, 20시쯤 사업장 현장에서 단말이 통신하지 못한다는 연락을 받고 알았다. 대상 포트의 인터페이스 모니터링은 처음부터 없었고, LACP 모니터링은 꺼져 있었으며, CPU 상승은 10% 정도라 리소스 알림에 걸리지 않았다.

조치

후속 조치

교훈

말단 장비 한 대라도 사업장 전체에 영향을 줄 수 있다. 작업 실수, 예상 못 한 상황, 버그 같은 이유로 작업 중에는 언제든 장애가 날 수 있으므로, 미리 일정을 맞춰 유지보수 시간을 확보해야 한다. 여러 대를 한꺼번에 바꾸면 원인 장비를 찾고 되돌리는 데 시간이 걸린다. 만일에 대비해 미리 준비하고, 사람이 아니라 구조로 막을 수 있는 부분은 막아야 한다. 지금이라면 로그를 AI에게 보여 주고 원인을 바로 찾을 수 있었을 것이다. 이번 같은 장애에는 AI의 사전 리뷰와 장애 상황 분석이 효과가 있었을 것이다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 네트워크 스위치. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.