새 콘텐츠·이펙트·동기화 항목이 패킷 크기와 빈도를 늘리면, 잘되던 서버가 패치 뒤부터 MTU·대역폭·패킷 수 한도에 걸립니다.
왜 패치로 새 스킬 이펙트·동기화 항목·아이템 정보가 늘어 패킷이 커지거나 잦아짐 → 그러면 큰 패킷은 MTU를 넘어 단편화되고 늘어난 양은 대역폭·클라우드 PPS 한도·송신 버퍼에 걸림 → 화면에서는 패치 직후부터 붐비는 곳에서 순간이동·스킬 씹힘·입력 지연. 인프라는 바꾼 것이 없는데 손실이 늘어남
패킷을 1,200바이트 이하로 직접 나누기, 새 동기화 항목은 변경분만 보내고 거리·중요도에 따라 빈도 낮추기, 배포 전 테스트 서버에서 유저당 초당 패킷·바이트와 가장 큰 패킷 크기를 이전 빌드와 비교, 트래픽 지표에 빌드 버전 남기기.
인프라팀 할 일
서버 장비·OS: 배포 시각을 그래프에 표시하고 유저당 초당 패킷·바이트와 평균 패킷 크기를 배포 전후로 비교, 인스턴스 한도 초과 카운터 경보, 필요하면 더 큰 인스턴스. 네트워크: 방화벽·로드밸런서·DDoS 방어 장비의 처리 한도와 프래그먼트 차단 여부 점검.
수치 감각
UDP 패킷은 1,200바이트 이하가 안전하고 인터넷 경로 MTU는 보통 1,500바이트, 터널을 지나면 더 작습니다(GRE 터널이면 1,476바이트). 경로 MTU를 넘은 패킷은 단편화되거나 버려지고 단편화된 패킷은 프래그먼트 하나만 잃어도 전체를 잃습니다. 유저당 초당 패킷이 20% 늘면 서버 전체도 20% 늘어, 한도 가까이 쓰던 인스턴스는 바로 넘칩니다.
그래프에서는
어느 순간부터 계단처럼 올라감 · 유저당 초당 패킷·바이트, 평균 패킷 크기
확인할 곳
배포 시각 앞뒤로 서버 NIC의 초당 패킷·바이트(sar -n DEV의 rxpck/s·txpck/s·rxkB/s·txkB/s, EC2는 NetworkPacketsOut·NetworkOut)를 동시 접속 수로 나눠 비교. 평균 패킷 크기는 바이트 ÷ 패킷, 크기 분포는 패킷 캡처를 Wireshark의 Packet Lengths 통계로
이러면 맞음
배포 직후부터 유저당 패킷·바이트나 평균 패킷 크기가 한 단계 올라 머물고, 같은 시각부터 서버가 만든 프래그먼트 수(sar -n IP의 fragcrt/s)나 인스턴스 한도 초과 카운터(AWS ENA의 pps_allowance_exceeded·bw_out_allowance_exceeded)가 늘어남
이러면 아님
트래픽 패턴은 배포 전후가 같은데 지연·손실만 늘었으면 같은 시각의 인프라 변경(설정, 경로, 장비, OS·커널 업데이트)을 봄
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
“패치 전에는 잘됐다”는 제보가 오면 인프라 변경과 함께 먼저 확인할 게임 쪽 원인입니다. 패치 노트에 네트워크 변경이 없어도, 새 이펙트나 동기화 항목 하나가 붐비는 곳에서는 수백 명분으로 곱해집니다. 늘어난 트래픽이 실제로 걸리는 곳은 “UDP 패킷의 IP 단편화”, “클라우드 PPS 한도 초과”, “NIC 대역폭 포화”, “커널 소켓 버퍼 부족”, “중간 장비 처리 한도 초과 (방화벽·IPS·DDoS 방어)” 항목에서 다룹니다. 이 항목은 그 한도에 닿게 만든 출발점이 게임 패치인 경우라서, 한도를 늘리기 전에 패치로 늘어난 트래픽부터 줄입니다. 같은 시각에 OS·커널도 업데이트했다면, 유저당 트래픽이 달라졌는지로 “OS·커널·드라이버·펌웨어 업데이트 뒤 성능 변화”와 가립니다.
출처
RFC 8085: UDP Usage GuidelinesIETF UDP 앱은 경로 MTU를 넘는 데이터그램을 보내지 말아야 함(SHOULD NOT), 프래그먼트 하나를 잃으면 단편화된 패킷 전체를 잃고 일부 NAT·방화벽은 프래그먼트를 모두 버림