브로드캐스트 도메인 분리 (VLAN 설계, PVLAN, 서브넷 최적화)

브로드캐스트 도메인 분리 네트워크 성능 저하를 막는 필수 전략

VLAN만 나누면 브로드캐스트 문제는 끝난다고 생각했습니다. 그 생각이 얼마나 안이했는지를 실제 사고로 배웠습니다. 고객사 서버 하나에서 시작된 ARP 브로드캐스트 폭풍이 같은 세그먼트에 있던 수십 대 서버를 동시에 흔들어놓는 장면을 직접 보고 나서야, 도메인 설계가 단순한 이론이 아님을 몸으로 이해했습니다.

이 경험에서 제가 뼈저리게 느낀 건, 네트워크 설계에서 "일단 되면 된 거 아닌가"라는 사고방식이 얼마나 위험한가 하는 점입니다. 평상시엔 아무 문제 없다가 사고 하나로 고객 여러 곳이 동시에 피해를 입는 구조, 그게 잘못 설계된 브로드캐스트 도메인의 민낯이었습니다.

ARP 브로드캐스트 폭풍이 터졌던 날

당시 저희 IDC는 모든 고객 서버를 동일한 /24 서브넷에 배치하고 있었습니다. /24 서브넷이란 하나의 브로드캐스트 도메인 안에 최대 254개의 호스트가 공존하는 구성으로, 한 호스트가 브로드캐스트 패킷을 날리면 나머지 253개 호스트 전원이 이를 수신해야 합니다. 지금 돌이켜보면 이 설계 자체가 문제였습니다. 멀티테넌트 환경에서 모든 고객을 하나의 브로드캐스트 도메인에 넣는 것은 한 고객의 문제가 다른 모든 고객에게 영향을 주는 구조입니다.

문제는 감염된 서버 하나가 초당 수만 건의 ARP 요청을 쏟아내기 시작했을 때였습니다. ARP(Address Resolution Protocol)란 IP 주소를 MAC 주소로 변환하기 위해 브로드캐스트를 사용하는 프로토콜인데, 정상적인 상황에서는 트래픽이 미미하지만 이것이 폭주하면 이야기가 달라집니다.

같은 브로드캐스트 도메인에 묶인 서버들은 이 패킷을 전부 처리해야 했고, CPU 인터럽트가 급증했습니다. 인터럽트란 CPU가 진행 중인 작업을 멈추고 외부 이벤트를 처리하는 메커니즘인데, 이것이 과도하게 발생하면 정작 서비스 처리에 쓰여야 할 CPU 자원이 고갈됩니다. 저는 즉각 해당 포트를 차단해 불을 껐지만, 그 짧은 시간 동안 고객사 여러 곳에서 응답 지연 민원이 들어왔습니다.

가장 뼈아팠던 건 피해를 입은 서버들이 감염된 서버와 아무 관계도 없는 다른 고객사 서버였다는 점입니다. 잘못은 한 곳에서 했는데 피해는 전체가 나눠 받는 구조였습니다. 이게 설계 실패입니다.

이 사건 이후 저희 팀이 가장 먼저 꺼낸 카드는 PVLAN(Private VLAN) 도입이었습니다. PVLAN이란 동일한 VLAN과 서브넷 안에 있더라도 호스트 간 직접 통신을 차단하는 기술로, Cisco의 기술 문서에서도 데이터센터와 호스팅 환경에서의 고객 격리 수단으로 명시하고 있습니다. PVLAN은 포트를 세 가지로 구분합니다.

Promiscuous 포트는 모든 포트와 통신 가능하며, 주로 게이트웨이나 방화벽에 할당합니다. Isolated 포트는 같은 VLAN 내 다른 호스트와 직접 통신이 불가능하며, 오직 Promiscuous 포트를 통해서만 통신합니다. Community 포트는 같은 커뮤니티 내 포트끼리는 통신 가능하나 다른 커뮤니티나 Isolated 포트와는 차단됩니다.

저희는 고객 서버 포트를 전부 Isolated로 설정했습니다. 덕분에 이후에 동일한 상황이 발생하더라도 브로드캐스트 피해가 게이트웨이 너머로는 퍼지지 않는 구조가 됐습니다.

다만 한 가지 주의할 점이 있었는데, PVLAN은 강력한 만큼 상위 라우터나 방화벽 설정과 반드시 연계해서 검토해야 합니다. 제 경험상 이 부분을 놓치면 정상적인 고객 트래픽까지 차단되는 상황이 생깁니다. 설계만 잘해서는 부족하고, 구현 후 실제 통신 검증까지 세트로 이루어져야 합니다. 저는 PVLAN 도입 후 고객사 각각의 정상 통신을 일일이 테스트했는데, 이 과정에서 방화벽 정책과 충돌하는 케이스가 두 건 나왔습니다. 검증이 필수입니다.

서브넷 최적화와 IGMP Snooping으로 마무리한 이유

PVLAN을 도입한 것만으로는 충분하지 않았습니다. 브로드캐스트 도메인의 크기 자체를 줄이는 작업도 병행했습니다. 기존의 /24 서브넷을 고객 그룹별로 /26으로 분할했습니다. /26 서브넷이란 하나의 브로드캐스트 도메인 안에 최대 62개의 호스트만 존재하는 구성으로, /24 대비 브로드캐스트 영향 범위가 약 1/4 수준으로 줄어듭니다. 같은 폭풍이 터지더라도 피해가 미치는 범위가 그만큼 좁아지는 셈입니다.

이 작업이 생각보다 힘들었습니다. 이미 IP가 배포된 서버들의 주소를 재편성해야 했고, 일부 고객사의 경우 서버 IP 변경이 서비스 설정 전체에 영향을 줘서 사전 조율이 필요했습니다. 처음부터 /26으로 설계했다면 겪지 않아도 될 작업이었습니다.

여기에 IGMP Snooping도 함께 활성화했습니다. IGMP Snooping이란 스위치가 멀티캐스트 그룹 가입 정보를 학습하여, 필요한 포트에만 멀티캐스트 트래픽을 전달하는 기능입니다. 이것을 켜기 전에는 멀티캐스트 패킷이 사실상 브로드캐스트처럼 모든 포트에 플러딩되고 있었는데, 활성화 이후에는 해당 그룹에 가입한 포트로만 트래픽이 제한됐습니다.

STP(Spanning Tree Protocol) 최적화도 빠뜨릴 수 없습니다. STP란 스위치 네트워크에서 루프를 방지하기 위해 특정 경로를 차단하는 프로토콜인데, 토폴로지 변경 이벤트인 TCN(Topology Change Notification)이 발생할 때마다 스위치가 MAC 테이블을 초기화하고 일시적으로 브로드캐스트 플러딩을 유발합니다.

저는 이 부분을 처음엔 간과했는데, 일반적으로 VLAN만 잘 나누면 된다고 알려져 있지만 실제로는 STP 설정이 엉망이면 VLAN을 수십 개로 쪼개도 TCN 때문에 오히려 더 심각한 플러딩이 일어날 수 있습니다. 이건 많은 교재에서 잘 강조하지 않는 부분인데, 현장에서는 굉장히 중요합니다. RSTP(Rapid Spanning Tree Protocol)로 전환하고 엣지 포트에 PortFast와 BPDUGuard를 적용해 불필요한 TCN 발생을 억제한 것이 이번 개선 작업에서 눈에 보이지 않지만 꽤 중요한 역할을 했습니다.

일련의 작업이 마무리된 후 스위치 포트별 브로드캐스트 카운터를 지속적으로 모니터링했습니다. 결과적으로 전체 브로드캐스트 트래픽이 작업 전 대비 약 60% 감소했고, 일부 고객사에서는 서버 응답속도가 눈에 띄게 개선됐다는 피드백을 직접 받았습니다. 숫자로 확인되는 순간이 솔직히 가장 보람 있었습니다.

브로드캐스트 도메인 설계는 VLAN을 나누는 것에서 시작하지만, 거기서 끝나지 않습니다. 서브넷 크기를 어떻게 잡느냐, PVLAN으로 호스트 간 격리를 어디까지 가져가느냐, STP와 IGMP Snooping까지 함께 손보느냐에 따라 실제 서비스 품질이 달라집니다. 설계와 구현, 그리고 수치 기반의 검증이 반드시 한 세트로 이루어져야 한다는 것, 저는 그걸 사고 한 번으로 배웠습니다.

처음 네트워크 설계를 맡고 있다면 /24 하나로 전부 묶는 구성부터 다시 살펴보시길 권합니다. 특히 멀티테넌트 환경이나 여러 팀이 같은 인프라를 공유하는 환경이라면, 격리 설계를 초기에 하지 않으면 나중에 바꾸는 비용이 매우 커집니다.

---

출처 및 참고 자료

• Cisco Networking Academy - VLAN 개념 및 설정: https://www.netacad.com
• Cisco - Understanding and Configuring Spanning Tree Protocol (STP): https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/5234-5.html
• RFC 1918 - Address Allocation for Private Internets (서브넷 관련): https://datatracker.ietf.org/doc/html/rfc1918
• Microsoft - DHCP Relay Agent 구성 가이드: https://docs.microsoft.com/ko-kr/windows-server/networking/technologies/dhcp/dhcp-top
• Wikipedia - Broadcast domain: https://en.wikipedia.org/wiki/Broadcast_domain
• Wikipedia - VLAN: https://en.wikipedia.org/wiki/VLAN