게임 렉 백서 텍스트 판: 온라인 게임 렉 원인 228가지

온라인 게임에서 화면이 끊기거나 순간이동하거나 접속이 끊기는 원인 228가지를 내 화면부터 서버 데이터베이스까지 층별로 정리한 텍스트 판. 원인마다 증상, 담당 팀(게임개발팀·인프라팀), 수치, 공신력 있는 출처.

그림과 직접 조작하는 실험이 있는 원본은 게임 렉 백서입니다. 이 판은 같은 원인·용어·출처를 자바스크립트 없이 한 페이지에서 읽을 수 있게 모았습니다. 원인마다 따로 된 페이지(c/ID.html)도 있습니다. 마크다운 한 파일로는 llms-full.txt에 있습니다.

증상별로 찾기

렉은 네 가지 요인에서 시작합니다: 지연(거리, 대기열, 처리 시간 때문에 모든 패킷이 일정하게 늦게 도착합니다.) 지터(평균은 괜찮지만 어떤 패킷은 빨리, 어떤 패킷은 늦게 옵니다. 와이파이, 혼잡한 회선, 바쁜 CPU가 만듭니다.) 손실(넘친 대기열, 전파 간섭, 불량 장비가 패킷을 버립니다. 잠깐 회선이 끊기는 것도 연속 손실입니다.) 정체(서버 틱이 늦거나 멈추고(GC, 락, 동기 호출, 과부하), 내 PC의 프레임이 멈춥니다. 회선은 멀쩡해도 생깁니다.)

담당 팀과 담당 코드

L1 클라이언트 게임 프로세스

코드	팀	담당	범위
`cli`	게임개발팀	클라이언트 개발	게임 클라이언트 코드: 프레임·GC·로딩, 보간·외삽·예측, 클라이언트의 네트워크 처리(하트비트 보내기·자동 재접속 포함)
`srv`	게임개발팀	서버 개발	게임 서버 코드: 틱·스레드·락, 동기화 설계, 접속 처리(accept 루프·listen 인자), 하트비트 응답·끊긴 연결 정리, 소켓 옵션, 쿼리·트랜잭션 설계
`net`	인프라팀	네트워크 인프라	회선과 IDC 네트워크 장비(스위치·라우터·방화벽·로드밸런서·DDoS 방어), 클라우드 네트워크 ACL·VPC 라우팅·로드밸런서, 통신사·피어링
`sys`	인프라팀	서버 인프라	서버 장비·클라우드 인스턴스(보안 그룹·연결 추적 포함), OS·커널 설정, NIC, 배포·모니터링 환경
`dba`	인프라팀	DB 인프라	DB 서버·스토리지, DB 설정·복제·백업, 캐시 서버
`ext`	외부	외부	유저 PC·집 네트워크, 통신사 구간(우리 계약 밖), 클라우드 사업자. 직접 고칠 수 없어 안내·요청·우회로 대응

프레임 타임 스파이크 Frame hitch

ID cg-hitch · 주 담당 게임개발팀·클라이언트 개발

한 프레임 계산이 평소보다 몇 배 오래 걸려 화면이 잠깐 멈춥니다.

왜 스킬 이펙트 폭증, 대량 스폰, UI 전체 갱신이 한 프레임에 몰림 → 그러면 16.7ms 안에 못 끝내고 50~300ms가 걸림 → 화면에서는 화면이 멈칫했다가 다음 프레임에 모두가 한 번에 이동

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 나만
언제: 사람이 몰릴 때, 특정 행동을 할 때, 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 무거운 일을 여러 프레임에 나누기, 프로파일러로 튀는 프레임 찾기, 이펙트 개수 상한.
수치 감각: 60FPS의 한 프레임은 16.7ms. 50ms를 넘는 프레임 하나만 있어도 “끊겼다”고 느끼기 쉽습니다.
그래프에서는: 가끔 무작위로 튐 · 프레임 시간
확인할 곳: PresentMon으로 게임 중 프레임 시간(FrameTime)과 CPU·GPU가 그 프레임에 쓴 시간(CPUBusy·GPUBusy)을 녹화. 모바일은 안드로이드 vitals의 느린 세션·느린 렌더링 지표
이러면 맞음: 평소 16.7ms 근처인 프레임 시간이 50ms를 넘게 솟는 순간이 스킬 연출·대량 스폰·UI 전체 갱신과 겹치고, 그 순간 핑은 그대로임
이러면 아님: 프레임 시간은 고른데 다른 캐릭터만 멈칫하면 “보간 버퍼가 없거나 짧음” 같은 네트워크 쪽. 튀는 간격이 규칙적이면 “클라이언트 가비지 컬렉션”을 먼저 봄
확인 수단: 유저 쪽 환경에서 확인

출처 3건

Slow rendering Android (Google)
60FPS를 내려면 한 프레임을 16ms 안에 그려야 하고 늦으면 프레임을 건너뛰어 끊김(jank)으로 보임
Slow Sessions (games only) Android (Google)
안드로이드 vitals는 게임 프레임이 50ms(20FPS)·34ms(30FPS)를 넘으면 느린 프레임으로 봄
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime(프레임 사이 CPU 시간), CPUBusy·GPUBusy(그 프레임을 만드는 데 CPU·GPU가 쓴 시간)

클라이언트 가비지 컬렉션 Client GC (Unity C#, Unreal, Lua)

ID cg-gc · 주 담당 게임개발팀·클라이언트 개발

쓰고 버린 메모리(가비지)를 회수하는 동안 게임 전체가 멈춥니다. 규칙적인 간격으로 뚝뚝 끊기는 것이 특징입니다.

왜 매 프레임 임시 문자열·배열·리스트를 만들고 버림 → 그러면 가비지가 쌓이면 GC가 메인 스레드를 멈추고 회수 → 화면에서는 몇 초~몇십 초마다 규칙적으로 뚝뚝 끊김

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 나만
언제: 일정한 주기로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 할당 줄이기(문자열 합치기·LINQ·람다 캡처 피하기), 오브젝트 풀, 점진적 GC 켜 두기(유니티 2020 이후 기본값), 로딩 화면처럼 멈춰도 괜찮은 때에 미리 GC 돌리기.
수치 감각: 보통 한 번에 수 ms~100ms, 저사양 폰이나 메모리를 많이 쓰는 게임은 그 이상(실험은 약 150~170ms). 유니티의 GC는 돌 때마다 힙 전체를 검사해서 게임이 쓰고 있는 메모리가 많을수록 길어집니다.
그래프에서는: 일정 주기로 튐 · 프레임 시간, GC 실행 시각
확인할 곳: 개발 빌드에서 유니티 프로파일러의 GC.Collect·GC.Alloc 마커를 봄. 언리얼은 stat GC와 stat Hitches(t.HitchFrameTimeThreshold로 정한 시간을 넘는 프레임을 로그로 남김)
이러면 맞음: 튄 프레임마다 GC.Collect 구간이 있고 그 길이가 튄 길이와 비슷하며, 간격이 몇 초~몇십 초로 규칙적임. 사람 많은 곳에서 프레임당 GC.Alloc이 늘어남
이러면 아님: 튄 프레임에 GC 구간이 없으면 “메인 스레드 동기 로딩·셰이더 컴파일”이나 “대규모 인원 렌더링 부하”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 유니티처럼 C#을 쓰는 클라이언트에서 흔합니다. 전투 로그 문자열, 데미지 숫자, UI 텍스트를 매 프레임 새로 만드는 코드가 가장 흔한 원인입니다. 사람 많은 곳에서만 끊긴다면 인원에 비례해 가비지가 늘어나는 코드가 원인입니다. 점진적 GC는 한 프레임에 조금씩(유니티 기본 3ms) 나눠 수집하지만 수집하는 속도보다 가비지를 빨리 만들면 결국 한 번에 멈춥니다. 언리얼 엔진에도 안 쓰는 게임 오브젝트를 정리하는 자체 GC가 있고 엔진 버전·설정에 따라 다르지만 기본 설정으로 약 1분마다 돌아 1분 간격의 멈칫을 만들기도 합니다. 게임 규칙을 Lua 같은 스크립트로 짠 클라이언트는 그 스크립트의 GC도 따로 돕니다.

출처 5건

Garbage collection modes Unity
점진적 GC가 기본값이고 여러 프레임에 나눠 수집, 끄면 힙 전체를 검사하는 동안 메인 스레드가 멈추며 수백 ms까지 갈 수 있음
Scripting.GarbageCollector.CollectIncremental Unity
점진적 GC가 한 번에 쓰는 시간(타임 슬라이스)의 기본 목표는 3ms(incrementalTimeSliceNanoseconds)
Garbage Collection Settings in the Unreal Engine Project Settings Epic Games
언리얼 GC가 정해진 간격(Time Between Purging Pending Kill Objects, 초 단위)으로 돈다는 설정. 기본값 숫자는 이 문서에 없음
Profiler markers reference Unity
GC.Collect: 가비지 컬렉션 동안 프로그램 코드가 멈춘 구간(1ms 미만~수백 ms), GC.Alloc: 관리 힙 할당
Stat Commands in Unreal Engine Epic Games
stat GC(가비지 컬렉션 통계), stat Hitches(t.HitchFrameTimeThreshold를 넘는 프레임을 로그에 기록)

메인 스레드 동기 로딩·셰이더 컴파일 Synchronous asset load, shader compile

ID cg-sync-load · 주 담당 게임개발팀·클라이언트 개발

처음 보는 지역·몬스터·이펙트를 그리기 직전에 파일을 읽고 셰이더를 만드느라 멈춥니다.

왜 새 지역 진입, 처음 보는 스킬·장비·몬스터 등장 → 그러면 메인 스레드가 파일 읽기와 셰이더 컴파일을 기다림 → 화면에서는 처음 한 번만 0.1~1초 멈춤, 두 번째부터는 괜찮음

증상: 멈춤, 뚝뚝 끊김
요인: 정체
누가 겪나: 나만
언제: 이동 중·지역 전환 때, 특정 행동을 할 때
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 비동기 로딩, 미리 불러두기(프리워밍), 셰이더를 로딩 화면이나 첫 실행 때 미리 컴파일, 로딩 화면 활용.
수치 감각: 셰이더 하나 컴파일에 수십 ms, 길면 100ms 이상. 텍스처 로딩은 저장장치 속도에 따라 수십~수백 ms.
그래프에서는: 접속·점검 직후 폭증 · 프레임 스파이크 수(패치·드라이버 업데이트 직후)
확인할 곳: PresentMon으로 같은 경로를 두 번 녹화해 첫 방문과 두 번째를 비교. 개발 빌드는 언리얼에서 r.PSOPrecache.Validation을 켜고 stat PSOPrecache와 로그의 “PSO PRECACHING MISS”를, 유니티는 프로파일러 Timeline에서 튄 프레임의 로딩·셰이더 구간을 봄
이러면 맞음: 처음 가는 곳·처음 쓰는 스킬에서만 0.1~1초 튀고 두 번째에는 사라짐. 패치나 그래픽 드라이버 업데이트 직후 제보가 몰렸다가 줄어듦
이러면 아님: 같은 곳에서 매번 튀면 셰이더 캐시 문제가 아님. 저장장치가 느린 PC에서만 이동할 때마다 반복되면 “저장장치가 느려 에셋 스트리밍이 밀림”, 전용 GPU 메모리가 꽉 찼으면 “그래픽 메모리(VRAM) 부족”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: PC에서 한 번 만든 셰이더는 그래픽 드라이버가 셰이더 캐시에 저장해 두었다가 다시 씁니다. 그래픽 드라이버를 업데이트하거나 게임 패치가 나온 직후에는 이 캐시가 무효화되어, 괜찮던 사람도 한동안 다시 끊깁니다. “패치 후 처음 가는 곳마다 멈칫”이라는 제보가 전형입니다.

출처 5건

Shader loading Unity
셰이더 변형을 처음 쓸 때 그래픽 드라이버가 GPU용으로 만드느라 눈에 띄게 멈출 수 있고, 한 번 만든 것은 캐시해 다시 멈추지 않음
Optimizing Rendering With PSO Caches in Unreal Engine Epic Games
파이프라인 상태(PSO)를 필요한 순간에 만들면 100ms 이상 걸릴 수 있어 미리 만들어 둬야 함
Direct3D 12 Return Codes Microsoft
D3D12_ERROR_DRIVER_VERSION_MISMATCH: 다른 드라이버 버전에서 만든 PSO 캐시는 다시 쓸 수 없음(드라이버 업데이트 후 재컴파일)
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime(프레임 사이 CPU 시간)으로 프레임별 시간을 녹화
PSO Precaching for Unreal Engine Epic Games
r.PSOPrecache.Validation을 켜면 stat PSOPrecache로 놓친 PSO 통계를 보고 로그에 “PSO PRECACHING MISS”를 남김, 런타임 PSO 생성이 기본 20ms를 넘으면 히치로 셈

저장장치가 느려 에셋 스트리밍이 밀림 Slow storage stalls asset streaming

ID cg-asset-stream · 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부

HDD처럼 느린 저장장치에서는 오픈월드의 텍스처·모델을 읽는 속도가 이동을 따라가지 못해, 개체가 늦게 뜨거나 게임이 읽기를 기다리며 끊깁니다.

왜 탈것·텔레포트로 빠르게 이동하거나 사람 많은 곳에 들어가 새 텍스처·모델이 한꺼번에 필요해짐 → 그러면 HDD 같은 느린 저장장치가 필요한 속도로 읽지 못해 읽기 요청이 쌓이고 일부 로딩은 메인 스레드가 끝날 때까지 기다림 → 화면에서는 텍스처가 한동안 흐릿하고 건물·캐릭터가 늦게 나타나며 읽기를 기다리는 순간 뚝뚝 끊김·멈춤

증상: 안 보임·유령 개체, 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 나만
언제: 이동 중·지역 전환 때, 사람이 몰릴 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부
게임개발팀 할 일: 읽기를 메인 스레드에서 기다리지 않는 비동기 스트리밍, 이동 방향·속도를 보고 미리 읽기, 낮은 해상도(밉맵)·간단한 모델을 먼저 보여 주고 나중에 바꾸기, 빠른 이동 중 스트리밍이 밀리면 잠깐 이동 속도를 제한하거나 로딩 화면 쓰기, 최소·권장 사양에 SSD 필요 여부 명시.
외부 할 일: 유저에게 게임을 SSD에 설치하도록 안내, 같은 디스크에서 다운로드·백신 검사가 도는지 확인하도록 안내.
수치 감각: 마이크로소프트에 따르면 예전 하드디스크는 1초에 수십 MB, NVMe SSD는 1초에 수 GB를 읽고 이전 세대 게임은 스트리밍에 1초에 50MB 안팎을 썼습니다. SSD 속도를 전제로 이보다 훨씬 많이 읽는 게임을 HDD에서 돌리면 읽기가 이동을 따라가지 못하기 쉽습니다.
그래프에서는: 일부만 높음 · 프레임 스파이크 수(저장장치 종류별), 디스크 읽기 지연
확인할 곳: 윈도우 성능 모니터의 PhysicalDisk\Avg. Disk sec/Read(읽기 한 번의 평균 시간)·Current Disk Queue Length와 PresentMon 프레임 시간을 빠르게 이동하면서 함께 기록. 개발 빌드는 언리얼 stat Streaming·stat AsyncLoad, 유니티 프로파일러의 AssetBundle.asset/allAssets 경고(로딩이 끝나기 전에 결과를 요청해 메인 스레드가 기다림)를 봄
이러면 맞음: 빠르게 이동할 때 디스크 읽기 지연과 대기열이 치솟고 같은 시각 프레임이 튀거나 텍스처·개체가 늦게 뜸. 같은 장면을 SSD에서 돌리면 사라짐
이러면 아님: 디스크는 한가한데 텍스처가 흐릿하면 “그래픽 메모리(VRAM) 부족”, 같은 곳 두 번째 방문부터 멀쩡하면 “메인 스레드 동기 로딩·셰이더 컴파일”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 처음 한 번만 멈추고 다음부터 괜찮다면 “메인 스레드 동기 로딩·셰이더 컴파일”에 가깝고 저장장치가 느린 PC에서만 이동할 때마다 반복되면 이 원인입니다. 그래픽 메모리가 모자라 텍스처를 내렸다 올리는 “그래픽 메모리(VRAM) 부족”도 흐릿한 텍스처를 만드니, 디스크 읽기 대기와 그래픽 메모리 사용량을 함께 봅니다. 백신의 실시간 검사가 게임 파일을 열 때마다 끼어들어 읽기가 더 늦어지기도 합니다.

출처 8건

DirectStorage is coming to PC Microsoft
예전 하드디스크는 초당 수십 MB, NVMe SSD는 초당 수 GB, 이전 세대 게임의 에셋 스트리밍 예산은 초당 50MB 안팎, 오픈월드 게임은 이동하며 먼 풍경을 실시간으로 읽고 버림
Texture and mesh loading Unity
동기 업로드는 메인 스레드에서 한 프레임에 읽고 올려 눈에 띄는 멈춤을 만들고, 비동기 업로드는 여러 프레임에 걸쳐 스트리밍함
Texture Streaming Overview for Unreal Engine Epic Games
스트리머가 시점에 맞춰 텍스처 해상도(밉)를 올리고 내리며 계산 대부분은 비동기 작업 스레드에서 하고 화면에 보이는 밉부터 불러옴
Profiler markers reference Unity
AssetBundle.asset/allAssets 경고: 로딩이 끝나기 전에 결과를 요청해 메인 스레드가 멈춰 기다림
Stat Commands in Unreal Engine Epic Games
stat Streaming(스트리밍 텍스처의 메모리·개수), stat AsyncLoad(비동기 로딩 통계)
Windows Performance Monitor Disk Counters Explained Microsoft
Avg. Disk sec/Read는 읽기 한 번이 끝나는 데 걸린 평균 시간(I/O 지연), Current Disk Queue Length는 측정 순간의 디스크 대기열 길이
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime(프레임 사이 CPU 시간)으로 프레임별 시간을 녹화
About regular quick and full scans with Microsoft Defender Antivirus Microsoft
실시간 보호는 파일을 열고 닫을 때마다 검사

대규모 인원 렌더링 부하 Render/animation cost of crowds

ID cg-crowd · 주 담당 게임개발팀·클라이언트 개발

공성전·월드 보스처럼 수백 명이 한 화면에 들어오면 그리는 비용 자체가 감당이 안 됩니다.

왜 한 화면에 수백 명과 이펙트가 겹침 → 그러면 애니메이션·그림자·이름표·이펙트 비용이 인원에 비례해 증가 → 화면에서는 FPS가 60 → 15로 떨어져 모든 움직임이 뚝뚝 끊기고 입력도 늦음

증상: 뚝뚝 끊김, 입력 지연
요인: 정체
누가 겪나: 특정 장소·채널, 나만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 거리별 간소화(LOD), 표시 인원 상한, 이펙트 간소화 옵션, 애니메이션 갱신 주기 낮추기.
수치 감각: 캐릭터 1명당 0.02~0.1ms라도 300명이면 6~30ms. 60FPS의 프레임 예산이 16.7ms이므로 이것만으로 예산의 3분의 1 넘게 쓰고 많으면 예산을 넘깁니다.
그래프에서는: 인원·부하를 따라 오름 · 프레임 시간, 화면 안 캐릭터 수
확인할 곳: PresentMon의 프레임 시간과 CPUBusy·GPUBusy를 공성전·월드 보스 전후로 비교. 개발 빌드는 언리얼 stat Unit(게임 스레드·렌더링 스레드·GPU 시간)
이러면 맞음: 화면 안 인원이 늘수록 프레임 시간이 함께 오르고 표시 인원 제한이나 이펙트 간소화 옵션을 켜면 바로 나아짐
이러면 아님: 인원과 상관없이 튀면 “프레임 타임 스파이크”나 “클라이언트 가비지 컬렉션”. FPS는 멀쩡한데 다른 사람 움직임만 밀리면 “메인 스레드 패킷 처리 병목”
확인 수단: 유저 쪽 환경에서 확인

출처 4건

Introduction to level of detail Unity
LOD가 없으면 화면에 작게 보이는 물체도 같은 복잡도로 그림, LOD로 그리기 부담을 줄임
Animation Budget Allocator in Unreal Engine Epic Games
스켈레탈 메시의 애니메이션 갱신(틱)을 동적으로 줄여 애니메이션에 쓰는 시간을 예산 안으로 제한
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime·CPUBusy·GPUBusy로 CPU와 GPU 중 어느 쪽이 프레임을 늦추는지 구분
Stat Commands in Unreal Engine Epic Games
stat Unit: 전체 프레임 시간과 게임 스레드·렌더링 스레드·GPU 시간

메인 스레드 패킷 처리 병목 Network processing on the main thread

ID cg-net-mainthread · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

받은 패킷을 프레임마다 정해진 만큼만 처리하면, 몰려온 패킷이 다음 프레임으로 계속 밀립니다.

왜 사람 많은 곳에서 초당 수천 개의 업데이트가 도착 → 그러면 메인 스레드가 프레임당 처리량 제한에 걸려 다 못 읽음 → 화면에서는 다른 사람 움직임이 점점 늦게, 몰아서 반영

증상: 몰아치기, 입력 지연
요인: 정체, 지연
누가 겪나: 특정 장소·채널, 나만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 수신·해석은 별도 스레드, 같은 대상의 오래된 위치 업데이트는 합쳐서 최신만 적용. 서버: 사람 많은 곳에서는 먼 캐릭터의 업데이트를 덜 자주 보내 전송량 줄이기.
수치 감각: 처리 못 한 패킷이 쌓이면 1초 분량이 밀리는 데 몇 초면 충분합니다.
그래프에서는: 인원·부하를 따라 오름 · 처리 못 한 수신 패킷 수, 수신~적용 지연
확인할 곳: 클라이언트가 프레임마다 처리하지 못하고 남긴 패킷 수와, 패킷이 도착한 시각부터 게임에 적용한 시각까지의 지연을 로그로 남겨 주변 인원과 함께 봄
이러면 맞음: 사람 많은 곳에서 남은 패킷 수와 적용 지연이 계속 늘고 같은 시각 핑과 서버의 송신 간격은 정상임
이러면 아님: 적용 지연은 없는데 패킷 자체가 늦게 도착하면 네트워크 구간. 프레임 시간이 크게 오르면 “대규모 인원 렌더링 부하”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Actor Priority in Unreal Engine Epic Games
대역폭이 모자라면 모든 액터를 매번 복제하지 않고 보는 사람과의 거리·마지막 복제 후 시간으로 우선순위를 매김
Replication Graph in Unreal Engine Epic Games
접속자·복제 대상이 많은 게임(MMORPG 등)은 위치별로 묶어 필요한 대상만 보내야 서버 CPU 병목을 피함

보간 버퍼가 없거나 짧음 Missing/short interpolation buffer

ID cg-no-buffer · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

서버 패킷을 받자마자 그리면 지터(도착 간격의 흔들림)가 그대로 화면에 드러납니다.

왜 받은 위치를 바로 그리거나 버퍼가 지터보다 짧음 → 그러면 늦게 온 패킷만큼 멈추고 몰려온 패킷만큼 튐 → 화면에서는 다른 캐릭터가 멈칫멈칫 움직임

증상: 뚝뚝 끊김
요인: 지터
누가 겪나: 나만
언제: 항상
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 보간 버퍼 두기, 회선 상태에 따라 버퍼 길이를 자동 조절. 서버: 버퍼만큼 과거 모습을 보고 쏴도 판정이 맞도록 지연 보상(되감기 판정) 적용.
수치 감각: 보통 서버가 패킷을 보내는 간격의 2배 정도(1초에 20번 받으면 100ms)를 버퍼로 둡니다.
그래프에서는: 처음부터 늘 높음 · 패킷 도착 간격, 보간 버퍼가 빈 횟수
확인할 곳: 클라이언트에서 서버 패킷의 도착 간격 분포와, 보간할 다음 스냅숏이 없어 멈추거나 외삽으로 넘어간 프레임 수를 기록
이러면 맞음: 도착 간격의 흔들림이 보간 버퍼 길이보다 자주 커지고 그때마다 버퍼가 비어 다른 캐릭터가 멈칫함. 버퍼를 늘리면 줄어듦
이러면 아님: 버퍼가 충분한데도 멈칫하면 서버가 보내는 간격 자체가 불규칙한지(틱 지연) 확인
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 버퍼를 늘리면 매끄러워지지만 그만큼 상대를 과거 모습으로 봅니다. 그래서 공격 판정은 서버가 “그 사람이 보던 과거”로 되감아 확인하는 지연 보상을 함께 씁니다.

출처 3건

Interpolation and extrapolation (Netcode for Entities 6.5) Unity
늦게 온 패킷을 기다리려고 일부러 늦춰 그리는 버퍼 보간, 버퍼가 클수록 정확하지만 그만큼 지연이 늘어남
Struct ClientTickRate (Netcode for Entities 6.5) Unity
보간 버퍼 기본값 InterpolationTimeNetTicks = 2(서버 전송 2번 분량)
Physics (Netcode for Entities 6.5) Unity
지연 보상: 서버가 클라이언트가 그 틱에 보던 충돌 세계를 찾아 명중 여부를 판정

과도한 외삽(데드 레커닝) Over-extrapolation / dead reckoning

ID cg-extrap · 주 담당 게임개발팀·클라이언트 개발

패킷이 오지 않는 동안 마지막 속도로 계속 움직여 보여 주다가, 틀린 걸 알고 되돌립니다.

왜 패킷 수신이 끊겨 마지막 방향·속도로 계속 이동시킴 → 그러면 실제로는 상대가 멈추거나 방향을 바꿨음 → 화면에서는 상대 캐릭터가 한참 가다가 진짜 위치로 휙 옮겨지거나 벽을 뚫고 지나감. 패킷 도착 간격이 들쭉날쭉하면 앞서 나갔다 당겨지기를 반복해 떨리듯 움직임

증상: 순간이동, 뚝뚝 끊김
요인: 손실, 지터
누가 겪나: 나만
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 외삽 시간 상한(예: 200~250ms), 틀렸을 때 부드럽게 수렴.
수치 감각: 속도 6m/s라면 300ms만 틀려도 1.8m 어긋납니다.
그래프에서는: 가끔 무작위로 튐 · 외삽 시간, 위치 보정 거리
확인할 곳: 다른 캐릭터를 외삽으로 그린 시간과, 새 패킷이 온 뒤 위치를 바로잡은 거리를 기록
이러면 맞음: 패킷이 끊긴 구간마다 외삽 시간이 상한 없이 길어지고 그 뒤 보정 거리가 수 m로 커짐
이러면 아님: 외삽이 짧게 끊기는데도 순간이동하면 패킷 손실·지연 자체가 커서 회선·경로 쪽을 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Interpolation and extrapolation (Netcode for Entities 6.5) Unity
다음 스냅샷이 제때 안 오면 같은 방향·속도로 계속 움직이는 외삽은 자주 틀리므로 상한을 둠(유니티 기본 20틱, 60Hz에서 약 1/3초)
Peeking into VALORANT's Netcode Riot Games
늦거나 빠진 데이터를 추측으로 메우다 틀리면 서버와 어긋나 캐릭터가 튀거나 미끄러지듯 보정됨

클라이언트 예측 불일치 Prediction mismatch / reconciliation

ID cg-predict · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

내 클라이언트가 먼저 움직여 보여 줬는데 서버가 다르게 계산하면 내 캐릭터가 끌려갑니다.

왜 클라이언트가 서버 확인 전에 먼저 움직임(예측) → 그러면 서버는 충돌·이동 속도·버프를 다르게 계산하거나 명령을 못 받음 → 화면에서는 확인이 올 때 내 캐릭터가 뒤로 끌려감

증상: 고무줄
요인: 손실, 지연
누가 겪나: 나만
언제: 이동 중·지역 전환 때, 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 서버와 같은 이동 코드 사용, 입력 중복 전송, 보정은 부드럽게. 서버: 클라이언트와 같은 이동 코드 사용, 중복으로 온 입력은 입력 번호로 걸러 한 번만 처리.
수치 감각: 끌려가는 거리는 “어긋난 시간 × 이동 속도”. 명령 몇 개만 사라져도 1~3m.
그래프에서는: 가끔 무작위로 튐 · 서버 보정(예측 실패) 횟수
확인할 곳: 서버가 보낸 위치 보정 횟수와 보정 거리를 기록. 언리얼은 서버의 ClientAdjustPosition 보정, 유니티 Netcode for Entities는 예측 실패로 되돌려 다시 계산한 횟수를 셈
이러면 맞음: 고무줄 제보 시각에 보정이 몰리고 특정 버프·지형·이동기에서 보정 거리가 반복해서 큼
이러면 아님: 보정이 손실이 큰 때에만 몰리면 입력 패킷 손실(회선) 쪽. 보정 없이 다른 캐릭터만 끌려가 보이면 “과도한 외삽(데드 레커닝)”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Introduction to prediction (Netcode for Entities 6.5) Unity
클라이언트와 서버가 같은 시뮬레이션 코드로 예측, 서버 상태와 다르면(예측 실패) 되돌려 다시 계산하며 보정이 보임
Use the command stream to handle user inputs (Netcode for Entities 6.5) Unity
패킷 손실에 대비해 최신 입력과 함께 이전 몇 틱의 입력을 중복으로 보냄
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
클라이언트가 먼저 움직이고 서버가 같은 이동을 재현, 위치가 다르면 ClientAdjustPosition으로 보정하고 저장한 이동을 다시 적용

고정 타임스텝 따라잡기 폭주 Fixed-timestep catch-up / spiral of death

ID cg-fixed-step · 주 담당 게임개발팀·클라이언트 개발

한 번 멈춘 뒤 밀린 계산을 몰아서 하다가, 그 계산 때문에 또 밀립니다.

왜 게임 시뮬레이션을 고정 간격으로 돌리는데 한 번 멈춤 → 그러면 밀린 스텝을 한 프레임에 몰아서 계산 → 화면에서는 긴 프레임이 줄줄이 이어지며 튀거나, 상한에 걸려 세계가 느려짐

증상: 뚝뚝 끊김, 몰아치기, 슬로우모션
요인: 정체
누가 겪나: 나만
언제: 가끔 무작위로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 프레임당 따라잡기 상한, 남는 시간은 보간으로 처리.
그래프에서는: 가끔 무작위로 튐 · 프레임 시간, 프레임당 고정 스텝 수
확인할 곳: 개발 빌드 프로파일러에서 한 프레임에 고정 스텝이 몇 번 돌았는지(유니티는 FixedBehaviourUpdate 등 FixedUpdate 단계 마커 수)와 프레임 시간을 함께 봄
이러면 맞음: 긴 프레임 하나 뒤에 스텝을 여러 번 도는 긴 프레임이 줄줄이 이어지고 상한(유니티 Maximum Allowed Timestep)에 닿으면 게임 시간이 실제보다 늦게 흐름
이러면 아님: 긴 프레임이 한 번으로 끝나면 “프레임 타임 스파이크”나 “클라이언트 가비지 컬렉션”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 유니티의 물리 계산(FixedUpdate)이 대표적인 고정 스텝입니다(기본 0.02초, 1초에 50번). Time 설정의 Maximum Allowed Timestep(한 프레임에 따라잡을 최대 시간, 기본 약 0.33초)이 따라잡기 상한입니다. 한 프레임이 이보다 길면 넘친 시간은 버려져, 그만큼 게임 시계가 실제보다 늦어집니다.

출처 3건

Set fixed timestep to optimize physics simulation frequency Unity
Fixed Timestep 기본값 0.02초(1초에 50번), 프레임이 길면 한 프레임에 물리 스텝을 여러 번 돌려 부담이 커짐
Handling variation in time Unity
Maximum Allowed Timestep 기본값 1/3초(0.3333333), 1초가 멈춰도 게임 시간은 0.333초만 흐름, 따라잡기 스텝이 또 느려지는 악순환을 막는 상한
Profiler markers reference Unity
FixedBehaviourUpdate: MonoBehaviour.FixedUpdate 실행 구간, 물리 마커는 FixedUpdate 단계에서 호출됨

시계 동기화 오차 Clock sync error

ID cg-clock · 주 담당 게임개발팀·클라이언트 개발

클라이언트가 추정한 서버 시각이 틀리면 보간 시점과 쿨타임 판정이 어긋납니다.

왜 접속할 때 한 번만 서버 시간을 맞추고 핑이 변해도 그대로 둠 → 그러면 보간할 시점·쿨타임 끝나는 시각이 서버와 어긋남 → 화면에서는 상대가 가끔 멈칫, 쿨타임이 끝났는데 스킬이 거절됨

증상: 뚝뚝 끊김, 씹힘·롤백
요인: 지연
누가 겪나: 나만
언제: 오래 켜 둘수록, 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 주기적으로 시간 동기화(왕복 시간 측정 후 보정), 급하게 바꾸지 말고 서서히 맞추기, 경과 시간은 PC 시각 대신 단조 시계(monotonic clock)로 재기.
그래프에서는: 서서히 오름 · 추정 서버 시각의 오차
확인할 곳: 클라이언트가 추정한 서버 시각과 서버가 패킷에 담아 보낸 서버 시각(틱 번호)의 차이를 주기적으로 기록
이러면 맞음: 오차가 접속 뒤 시간이 지날수록 커지거나 PC 시계가 맞춰지는 순간 한 번에 튀고, 그 무렵 스킬 거절·멈칫 제보가 늘어남
이러면 아님: 오차가 작게 유지되는데 스킬이 거절되면 서버 판정·지연 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 경과 시간을 PC의 날짜·시각(wall clock)으로 재면, 윈도우가 인터넷 시간에 맞춰 시계를 고치거나 사용자가 시계를 바꾸는 순간 게임 시각이 튑니다. 경과 시간은 되돌아가지 않는 단조 시계(monotonic clock, Stopwatch 등)로 재야 합니다.

출처 3건

RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification IETF
요청·응답의 네 시각으로 왕복 지연과 시계 오차를 계산하는 방식
Acquiring high-resolution time stamps Microsoft
QueryPerformanceCounter(Stopwatch가 사용)는 외부 시각과 동기화되지 않는 경과 시간용 시계, UTC 시각이 필요할 때만 시스템 시각 사용
Time synchronization (Netcode for Entities 6.5) Unity
왕복 시간으로 서버 시각을 추정하고 시각을 크게 바꾸지 않고 진행 속도를 조금씩 조정해 맞춤

float 시간 정밀도 손실 Float time precision loss on long sessions

ID cg-float-time · 주 담당 게임개발팀·클라이언트 개발

게임 시각을 정밀도가 낮은 소수 형식(float)으로 들고 있으면, 켜 둔 시간이 길수록 시간 해상도(구별할 수 있는 가장 작은 시간 차이)가 떨어져 움직임과 이펙트가 떨립니다.

왜 게임을 켠 뒤 흐른 시간을 float로 쌓거나 그대로 셰이더에 넘김 → 그러면 켜 둔 시간이 길수록 float가 나타낼 수 있는 가장 작은 차이가 커짐 → 화면에서는 며칠 켜 둔 클라이언트만 캐릭터·애니메이션·흐르는 이펙트가 덜덜 떨리고 다시 켜면 멀쩡함

증상: 뚝뚝 끊김
요인: 지터
누가 겪나: 나만
언제: 오래 켜 둘수록
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 흐른 시간은 double(64비트)이나 정수로 보관, 셰이더에 넘기는 시간은 일정 주기로 되감기, 며칠짜리 장시간 자동 테스트.
수치 감각: 32비트 float는 유효 숫자가 7자리 남짓입니다. 켜 둔 지 하루(약 86,400초)면 시간 해상도가 약 8ms로 60FPS 한 프레임(16.7ms)의 절반쯤이 되고, 일주일이면 약 60ms로 한 프레임보다 커집니다.
그래프에서는: 서서히 오름 · 켜 둔 시간별 떨림 제보
확인할 곳: 떨림 제보에 클라이언트를 켜 둔 시간을 함께 받고 재시작 전후를 비교. 개발 쪽은 게임 시작 시각 값을 며칠 지난 값으로 두고 돌려 보는 테스트
이러면 맞음: 며칠 켜 둔 클라이언트에서만 떨리고 재시작하면 사라지며 켜 둔 시간이 길수록 심해짐
이러면 아님: 켜자마자 떨리면 “보간 버퍼가 없거나 짧음”이나 “타이머 해상도”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 자동 사냥을 켜 두고 며칠씩 끄지 않는 모바일 MMO에서 특히 나옵니다. 유니티의 Time.time도 float라서, 유니티는 double로 된 Time.timeAsDouble을 따로 두고 이쪽을 권합니다.

출처 2건

Time.timeAsDouble Unity
Time.time의 double 버전, 오래 켜 둘수록 float보다 정밀해 대부분 이쪽을 권장
Floating-point numeric types (C# reference) Microsoft
float 정밀도 약 6~9자리, double 약 15~17자리

V-Sync와 렌더 대기열 V-Sync, render queue

ID cg-vsync · 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부

GPU가 그린 프레임을 몇 장 대기열에 쌓아 두었다가 모니터 주기에 맞춰 내보내는 동안 입력이 늦어집니다.

왜 그래픽 드라이버가 프레임을 1~3장 미리 대기열에 쌓음 → 그러면 입력이 화면에 반영되기까지 그만큼 더 걸림 → 화면에서는 핑은 낮은데 조작이 묵직하고 굼뜸

증상: 입력 지연, 뚝뚝 끊김
요인: 지연
누가 겪나: 나만
언제: 항상
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부
게임개발팀 할 일: 저지연 모드 지원, 프레임 대기열 줄이기, 주사율보다 조금 낮게 거는 프레임 상한 옵션 제공, 폰은 프레임 페이싱 기능 켜기.
외부 할 일: 유저에게 가변 주사율 모니터와 함께 주사율보다 조금 낮은 프레임 상한 걸기, 그래픽 드라이버의 저지연 모드 켜기 안내.
수치 감각: 60Hz에서 한 장당 16.7ms. CPU가 GPU나 화면 주기보다 빨라 대기열 세 장(DirectX 11 기본값)이 꽉 차면 50ms가 더해집니다. 이중 버퍼 V-Sync에서는 17ms 걸린 프레임이 다음 화면 갱신 시점(33.3ms)까지 기다리고, 그동안 이전 프레임이 한 번 더 보입니다.
그래프에서는: 처음부터 늘 높음 · 입력~화면 지연
확인할 곳: PresentMon의 MsClickToPhotonLatency·MsAllInputToPhotonLatency(마우스·키보드 입력부터 화면으로 내보내기까지)와 DisplayLatency를 V-Sync·저지연 모드·프레임 상한을 바꿔 가며 비교. MsPCLatency(PC가 입력을 받은 뒤 화면으로 보내기까지)는 게임이 PC Latency 이벤트를 내보낼 때만 기록됨
이러면 맞음: V-Sync를 켜거나 프레임 상한이 없을 때 이 지연이 한두 프레임(수십 ms) 늘고, 저지연 모드나 주사율보다 조금 낮은 프레임 상한에서 줄어듦. 핑은 그대로임
이러면 아님: PC 안의 지연은 낮은데도 조작이 늦으면 “디스플레이·입력 장치·프레임 생성 지연”, 핑이 높으면 네트워크 쪽
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: V-Sync(수직 동기화)는 모니터가 화면을 바꾸는 순간에만 새 프레임을 내보내는 설정입니다. 화면 찢어짐은 사라지지만 그 순간을 기다리는 만큼 입력이 늦고 FPS가 60 아래로 내려가면 60과 30 사이를 오가며 뚝뚝 끊깁니다. 가변 주사율 모니터는 모니터가 프레임이 준비되는 때에 맞춰 화면을 바꿔 이 기다림을 줄입니다. 폰에서도 같은 일이 생깁니다. 30FPS 게임이 60Hz 화면에 프레임을 고르게 맞춰 내보내지 못하면, 평균은 30FPS인데 한 장이 49·16·33ms처럼 들쭉날쭉 머물러 뚝뚝 끊깁니다(안드로이드 개발 문서의 예). 안드로이드의 프레임 페이싱(프레임 출력 간격 고르기) 라이브러리나 엔진의 같은 옵션으로 줄입니다.

출처 5건

IDXGIDevice1::SetMaximumFrameLatency Microsoft
드라이버가 대기열에 쌓을 수 있는 프레임 수 기본값 3(1~16)
Reduce latency with DXGI 1.3 swap chains Microsoft
Present가 대기열이 빌 때까지 막혀 그린 뒤 표시까지 거의 한 프레임을 더 기다리게 됨, 대기 가능한 스왑 체인으로 줄임
Frame Pacing library Android (Google)
60Hz 화면에서 새 프레임이 없으면 이전 프레임을 다시 보여 줌, 30FPS 게임의 프레임 시간이 49·16·33ms처럼 들쭉날쭉해지는 예
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsPCLatency(PC가 입력을 받아 화면으로 보내기까지), MsClickToPhotonLatency(마우스 클릭~화면), MsAllInputToPhotonLatency(키보드·마우스 입력~화면), DisplayLatency(프레임 제출~모니터로 내보내기)
PresentMon Console Application (README-ConsoleApplication.md) Intel
MsPCLatency는 앱이 PC Latency 이벤트를 내보내야 기록됨(--track_pc_latency), MsAllInputToPhotonLatency는 키보드·마우스 입력 기준

클라이언트 메모리 누수 Client memory leak

ID cg-leak · 주 담당 게임개발팀·클라이언트 개발

오래 켜 둘수록 메모리가 늘어 점점 느려지다가 결국 게임이 강제로 꺼집니다.

왜 지역을 오갈 때 텍스처·UI·이펙트가 해제되지 않음 → 그러면 GC가 잦아지고 OS 메모리가 부족해 스왑 발생 → 화면에서는 몇 시간 플레이 뒤 점점 뚝뚝 끊기다가 강제 종료(플레이어에게는 접속 끊김처럼 보임)

증상: 뚝뚝 끊김, 접속 끊김
요인: 정체
누가 겪나: 나만
언제: 오래 켜 둘수록
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 지역 전환 때 메모리 사용량 측정, 해제되지 않는 텍스처·UI·이펙트 찾아 고치기, 장시간 자동 테스트(소크 테스트).
그래프에서는: 서서히 오름 · 게임 프로세스 메모리
확인할 곳: 성능 모니터로 Process(게임)\Private Bytes를 몇 시간 기록. 모바일은 안드로이드 ApplicationExitInfo의 종료 사유(REASON_LOW_MEMORY)와 iOS jetsam 보고서
이러면 맞음: 지역을 오갈 때마다 메모리가 올라가고 내려오지 않으며 켜 둔 시간이 길수록 뚝뚝 끊김·강제 종료가 늘어남
이러면 아님: 메모리는 일정한데 오래 켜 둘수록 떨리기만 하면 “float 시간 정밀도 손실”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 폰은 주로 메모리를 압축해 버팁니다. 그래도 메모리가 모자라면 OS가 게임을 바로 꺼 버립니다(튕김). 램이 작은 기기일수록 먼저 꺼집니다.

출처 4건

Memory allocation among processes Android (Google)
안드로이드는 메모리를 zRAM에 압축해 버티고 모자라면 저메모리 킬러가 프로세스를 종료, 앞에 띄운 앱이 종료되면 크래시처럼 보임
Identifying high-memory use with jetsam event reports Apple
iOS는 메모리 압박이 풀리지 않으면 앱을 강제 종료(jetsam)하고 앱마다 메모리 한도를 넘으면 종료 대상이 됨
Find user-mode memory leaks with Performance Monitor (PerfMon) Microsoft
Process > Private Bytes(프로세스가 할당한 전용 메모리)·Virtual Bytes를 오래 기록해 늘기만 하면 누수
ApplicationExitInfo Android (Google)
REASON_LOW_MEMORY: 시스템의 저메모리 킬러가 앱 프로세스를 종료함(지원하지 않는 기기는 REASON_SIGNALED·SIGKILL로 보고)

클라이언트 크래시 Client crash

ID cg-crash · 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부

처리하지 못한 오류로 게임이 꺼집니다. 플레이어에게는 접속 끊김처럼 보이지만 서버는 정상입니다.

왜 널 참조, 메모리 부족, 그래픽 드라이버 오류 → 그러면 게임 프로세스가 강제 종료 → 화면에서는 “튕겼다”는 제보. 같은 시각 다른 사람은 멀쩡

증상: 접속 끊김
요인: 정체
누가 겪나: 나만
언제: 특정 행동을 할 때, 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부
게임개발팀 할 일: 크래시 리포트 수집, 기기·드라이버별 통계, 많이 몰리는 오류부터 수정.
외부 할 일: 특정 그래픽 드라이버 버전에서 몰리면 유저에게 드라이버 업데이트 안내.
그래프에서는: 일부만 높음 · 크래시 수(기기·그래픽 드라이버·빌드별)
확인할 곳: 크래시 리포트와 안드로이드 vitals의 크래시율을 기기·드라이버·빌드별로 봄. 유저 PC는 이벤트 뷰어 응용 프로그램 로그의 이벤트 ID 1000(오류가 난 모듈 이름)과 “Display driver stopped responding and has recovered” 기록
이러면 맞음: 끊김 제보 시각에 크래시 기록이 있고 같은 시각 같은 서버의 다른 유저는 정상. 특정 기기·드라이버 버전·모듈에 몰림
이러면 아님: 크래시 기록 없이 접속만 끊겼으면 “NAT 매핑 만료”나 회선 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Crashes Android (Google)
처리하지 않은 예외나 시그널(SIGSEGV 등)로 앱이 예기치 않게 종료되는 것이 크래시, Play Console의 Android vitals로 집계
WDDM Support for Timeout Detection and Recovery (TDR) Microsoft
GPU가 기본 2초 안에 작업을 못 끝내면 윈도우가 그래픽 드라이버와 GPU를 재설정
The application or service crashing behavior troubleshooting guidance Microsoft
응용 프로그램 로그의 이벤트 ID 1000이 실제 크래시 기록이며 오류 응용 프로그램·오류 모듈 이름(Faulting module name)을 담음

게임 보안 모듈(안티치트) 검사 Anti-cheat scan and heartbeat

ID cg-anticheat · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

해킹을 막으려고 게임과 함께 도는 보안 모듈이 주기적으로 검사합니다. 검사가 무겁거나 보안 서버와 주고받는 하트비트(주기적인 생존 확인 신호)가 늦으면 뚝뚝 끊기거나 접속이 끊깁니다.

왜 보안 모듈이 주기적으로 게임 메모리·실행 중인 프로그램·드라이버를 검사 → 그러면 검사하는 동안 게임 스레드가 멈추거나, 하트비트가 제때 못 감 → 화면에서는 일정한 간격으로 멈칫, 심하면 보안 오류 안내와 함께 접속 끊김

증상: 뚝뚝 끊김, 멈춤, 접속 끊김
요인: 정체
누가 겪나: 나만
언제: 일정한 주기로, 접속·점검 직후, 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 무거운 검사는 게임 스레드 밖에서 조금씩 나눠 돌리기, 보안 모듈 버전별 뚝뚝 끊김·튕김 통계 비교(업데이트 직후 몰리면 보안 모듈 업체에 전달). 서버: 하트비트가 한두 번 늦는 것은 허용하기.
수치 감각: 가벼운 검사는 보통 1ms도 안 걸리지만 게임 스레드에서 도는 무거운 검사는 구현에 따라 한 번에 수십~수백 ms를 차지하기도 합니다.
그래프에서는: 일정 주기로 튐 · 프레임 시간, 안티치트 강퇴 수
확인할 곳: PresentMon 프레임 시간에서 튀는 간격을 재고 서버가 받은 안티치트 강퇴 사유(EOS는 ClientActionReason의 AuthenticationFailed / Authentication Timed Out 등)를 보안 모듈 버전·사양별로 집계
이러면 맞음: 게임 상황과 무관하게 일정한 간격의 짧은 멈춤이 반복되고 보안 모듈 업데이트 직후 특정 사양에서 뚝뚝 끊김·인증 시간 초과 강퇴가 늘어남
이러면 아님: 보안 모듈 버전과 무관하게 모든 사양에서 같은 간격이면 “클라이언트 가비지 컬렉션”이나 “백그라운드 프로세스의 CPU 점유”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 보안 모듈은 OS 깊숙이 드라이버로 들어가 있어 백신·오버레이·다른 게임의 보안 모듈과 충돌하기도 합니다. 보안 모듈 업데이트 직후 특정 사양에서만 뚝뚝 끊김·튕김 제보가 몰리면 먼저 의심합니다.

출처 2건

Using the Anti-Cheat Interfaces Epic Games
서버가 정해진 시간(RegisterTimeout) 안에 클라이언트의 안티치트 메시지를 못 받으면 인증 시간 초과로 내보냄(로딩으로 멈춘 클라이언트가 흔한 원인), 최근 모듈 업데이트가 문제면 이전 모듈로 되돌림
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime(프레임 사이 CPU 시간)으로 프레임별 시간을 녹화

L2 클라이언트 OS·기기

백그라운드 프로세스의 CPU 점유 Background CPU contention

ID co-background · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

백신 검사, 윈도우 업데이트, 방송 프로그램, 브라우저 영상이 코어를 차지하면 게임 스레드가 CPU를 배정받지 못하고 기다립니다.

왜 다른 프로그램이 CPU 코어를 오래 차지 → 그러면 게임 스레드가 스케줄링 대기 → 화면에서는 프레임이 늦고 받은 패킷 처리도 늦어짐

증상: 뚝뚝 끊김, 몰아치기
요인: 정체
누가 겪나: 나만
언제: 가끔 무작위로, 일정한 주기로
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 게임 스레드 우선순위 조정, 뚝뚝 끊김이 생긴 때의 로그에 PC 전체 CPU 사용률을 함께 남겨 다른 프로그램 탓인지 구분.
외부 할 일: 유저에게 윈도우 게임 모드 켜기, 게임 중 불필요한 프로그램(백신 검사·윈도우 업데이트·방송 프로그램·브라우저 영상) 종료 안내.
수치 감각: 윈도우는 보통 한 번에 수 ms~수십 ms씩 코어를 넘겨줍니다. 스케줄링에서 한 번만 밀려도 한 프레임이 사라집니다.
그래프에서는: 가끔 무작위로 튐 · PC 전체 CPU 사용률, 프레임 시간
확인할 곳: 작업 관리자 프로세스 탭의 CPU 열과 성능 모니터의 Processor Information(_Total)\% Processor Time을 PresentMon 프레임 시간과 함께 기록. 백신이 의심되면 New-MpPerformanceRecording으로 녹화해 Get-MpPerformanceReport로 검사 시간이 긴 파일·프로세스를 봄
이러면 맞음: 끊긴 시각에 다른 프로그램(백신 검사·업데이트·방송 프로그램)의 CPU 사용이 솟거나, 게임 폴더의 파일이 검사 시간 상위에 올라옴. 그 프로그램을 끄거나 예외로 두면 사라짐
이러면 아님: CPU 사용률이 낮은데도 화면 전체가 멈칫하고 소리가 지직거리면 “NIC 절전·드라이버 문제”(DPC 지연)
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 윈도우는 앞에 띄운 창(포그라운드)의 프로그램에 우선순위를 조금 더 주지만, 코어보다 바쁜 일이 많으면 게임도 기다립니다. 백신은 CPU를 쓰는 것보다 “실시간 감시”로 더 자주 끼어듭니다. 게임이 파일을 열 때마다 검사해서 에셋을 읽는 순간의 멈춤이 길어집니다.

출처 6건

Multitasking Microsoft
윈도우는 스레드마다 타임 슬라이스를 주고 다 쓰면 다음 스레드로 넘김, 타임 슬라이스는 약 20ms(OS·CPU에 따라 다름)
Priority Boosts Microsoft
앞에 띄운 창(포그라운드)의 프로세스는 우선순위를 백그라운드 프로세스 이상으로 올려 줌
About regular quick and full scans with Microsoft Defender Antivirus Microsoft
실시간 보호는 파일을 열고 닫을 때마다, 폴더를 열 때마다 검사
Network-Related Performance Counters Microsoft
Processor Information: % Processor Time 카운터
Performance analyzer for Microsoft Defender Antivirus Microsoft
New-MpPerformanceRecording으로 녹화하고 Get-MpPerformanceReport로 검사 시간에 영향을 준 상위 파일·경로·프로세스를 봄
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime(프레임 사이 CPU 시간)으로 프레임별 시간을 녹화

절전 모드·발열 스로틀링 Power saving, thermal throttling

ID co-power · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

노트북 배터리 모드, 폰 절전 모드, 기기 발열 때문에 CPU·GPU 속도가 떨어집니다. 발열은 처음엔 괜찮다가 한참 뒤부터 느려지는 게 특징입니다.

왜 배터리·절전 모드이거나 기기가 뜨거워짐 → 그러면 CPU·GPU 클럭을 기기에 따라 30~50% 낮춤 → 화면에서는 절전 모드는 켜자마자, 발열은 몇 분~20분쯤 플레이한 뒤부터 FPS가 떨어지고 뚝뚝 끊김

증상: 뚝뚝 끊김, 입력 지연
요인: 정체
누가 겪나: 나만
언제: 오래 켜 둘수록, 항상
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 그래픽 옵션 자동 조절, 프레임 상한으로 발열 관리, OS가 알려 주는 발열 단계(iOS의 thermalState, 안드로이드의 발열 상태 API)를 보고 미리 옵션 낮추기, 그래픽 칩이 두 개인 노트북에서 외장 그래픽을 쓰도록 실행 파일에 표시(NvOptimusEnablement·AmdPowerXpressRequestHighPerformance 내보내기).
외부 할 일: 유저에게 절전 모드 끄기, 노트북은 전원 연결 권장 안내, “좋은 노트북인데 FPS가 낮다”는 제보면 게임이 어느 그래픽 칩에서 도는지 확인하고 윈도우 그래픽 설정에서 게임을 고성능 GPU로 지정하도록 안내.
그래프에서는: 서서히 오름 · FPS, CPU·GPU 클럭
확인할 곳: PresentMon의 CPUFrequency·GPUFrequency·CPUTemperature·GPUTemperature를 프레임 시간과 함께 20~30분 기록하고, 작업 관리자 프로세스 탭의 GPU 엔진 열로 게임이 어느 그래픽 칩에서 도는지 확인. 모바일은 안드로이드 발열 API(getThermalHeadroom, 발열 상태)와 iOS thermalState를 FPS와 함께 기록
이러면 맞음: 온도가 오른 뒤 클럭이 떨어지는 시점부터 FPS가 내려가거나, 배터리·절전 모드에서만 클럭이 낮음. 또는 게임이 내장 그래픽에서 돌고 있음
이러면 아님: 클럭·온도가 그대로인데 FPS가 떨어지면 “백그라운드 프로세스의 CPU 점유”나 “클라이언트 메모리 누수”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 그래픽 칩이 두 개인 노트북은 전기를 아끼려고 게임을 느린 내장 그래픽으로 돌리기도 합니다. “좋은 노트북인데 FPS가 낮다”는 제보라면 게임이 어느 그래픽 칩에서 도는지 먼저 확인합니다.

출처 5건

Thermal API Android (Google)
기기는 높은 성능을 제한된 시간만 유지하고 그 뒤 발열로 스로틀링됨, 발열 상태를 보고 미리 부하를 낮추도록 권장
thermalState Apple
iOS가 알려 주는 현재 발열 단계, 단계가 높아지면 앱이 자원 사용을 줄여야 함
Selecting the Best Graphics Device to Run a 3D Intensive Application AMD
그래픽 칩이 두 개인 노트북에서 내장 그래픽으로 돌면 60FPS 게임이 30FPS가 되기도 함, AmdPowerXpressRequestHighPerformance 내보내기로 외장 그래픽 선택
PresentMon Capture Application (README-CaptureApplication.md) Intel
CPUFrequency·GPUFrequency(클럭), CPUTemperature·GPUTemperature(온도)를 프레임별로 기록
GPUs in the task manager Microsoft
작업 관리자는 프로세스별 GPU 사용률과 그 값이 어느 GPU·엔진의 것인지 보여 주는 열을 둠

타이머 해상도 Timer resolution (Windows 15.6ms)

ID co-timer · 주 담당 게임개발팀·클라이언트 개발

윈도우의 기본 타이머는 15.6ms 단위라 “1ms만 쉬기”가 실제로는 다음 타이머 주기까지, 길게는 15.6ms로 늘어납니다.

왜 프레임 제한·패킷 전송을 Sleep(잠깐 대기) 방식으로 구현 → 그러면 OS가 15.6ms 단위로만 깨워 줌 → 화면에서는 프레임 간격과 입력 전송 간격이 들쭉날쭉

증상: 뚝뚝 끊김
요인: 지터
누가 겪나: 나만
언제: 항상
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 고해상도 타이머 사용, 대기 대신 이벤트·V-Sync 기반 페이싱.
수치 감각: 15.6ms 단위로는 16.7ms 간격을 맞출 수 없어, 프레임 간격이 15.6ms와 31.2ms 사이를 오갑니다.
그래프에서는: 처음부터 늘 높음 · 프레임 간격 분포
확인할 곳: PresentMon의 MsBetweenPresents(프레임 간격) 분포와, powercfg /energy 보고서의 “Platform Timer Resolution” 항목(타이머 해상도를 바꾼 프로세스)을 봄
이러면 맞음: 프레임 간격이 15.6ms와 31.2ms처럼 15.6ms의 배수에 몰려 있고, 게임이 더 높은 타이머 해상도를 요청하지 않음
이러면 아님: 간격이 고르게 흩어져 있으면 타이머 탓보다 “백그라운드 프로세스의 CPU 점유”나 프레임 부하 쪽
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 예전 윈도우는 한 프로그램이 타이머를 1ms로 바꾸면 모든 프로그램에 적용됐습니다. 그래서 “브라우저를 켜 두면 게임이 부드러워진다”는 말도 있었습니다. 윈도우 10 2004 버전부터는 요청한 프로그램에만 적용되고 윈도우 11은 최소화되거나 완전히 가려져 소리도 내지 않는 창의 요청을 적용하지 않을 수 있습니다.

출처 6건

_WDF_TIMER_CONFIG (wdftimer.h) Microsoft
일반 타이머의 정확도는 시스템 클록 틱 간격인 기본 15.6ms, 고해상도 타이머는 1ms
timeBeginPeriod function (timeapi.h) Microsoft
윈도우 10 2004 이전에는 전역 설정, 이후에는 요청한 프로세스에만 적용, 윈도우 11은 가려지거나 최소화된 창의 프로세스에 높은 해상도를 보장하지 않음
CreateWaitableTimerExW function (synchapi.h) Microsoft
고해상도 대기 타이머 플래그 CREATE_WAITABLE_TIMER_HIGH_RESOLUTION
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsBetweenPresents: 이번 Present() 호출과 이전 호출 사이 시간(ms)
Results for the Idle Energy Efficiency Assessment Microsoft
기본 시스템 타이머 해상도 15.6ms, 에너지 보고서의 “Platform Timer Resolution” 항목에서 타이머 해상도를 바꾼 프로세스를 찾음
Powercfg command-line options Microsoft
powercfg /energy: 시스템을 분석해 에너지 보고서(HTML)를 만듦

모바일 앱 백그라운드 전환 App suspended in background

ID co-mobile-bg · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

알림을 보려고 앱을 잠깐 내리면 OS가 몇 초 뒤 앱을 일시 정지(suspend)하고, 그동안 서버는 나를 끊습니다.

왜 메시지 확인·전화로 게임을 내림 → 그러면 게임 엔진이 게임 진행을 멈추고 OS도 곧 앱과 네트워크를 정지시킴 → 화면에서는 돌아오면 이미 접속 끊김, 재접속

증상: 접속 끊김
요인: 정체, 손실
누가 겪나: 나만
언제: 가만히 있다가, 특정 행동을 할 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 돌아오면 끊긴 연결을 기다리지 말고 세션 토큰으로 바로 자동 재접속(재로그인 없이 이어 붙이기), 최신 상태를 한 번에 받아 맞추기. 서버: 하트비트가 끊기면 연결은 정리하되 캐릭터 세션은 짧은 유예 시간 동안 유지(바로 내보내지 않기), 그 안에 재접속하면 세션 토큰으로 이어 받기.
수치 감각: 게임 엔진은 보통 내리는 순간 멈춥니다. iOS는 몇 초, 추가 시간을 받아도 대개 수십 초 안에 앱을 일시 정지하고 안드로이드 14 이상은 화면에서 내려간 앱을 10초쯤 뒤 동결(freeze)합니다.
그래프에서는: 연결이 한꺼번에 끊김 · 끊김 수(하트비트 타임아웃), 앱 일시 정지 기록
확인할 곳: 클라이언트 로그의 앱 일시 정지·복귀 시각(유니티는 OnApplicationPause)과 서버의 끊김 사유·시각을 세션 ID로 맞춰 봄. 안드로이드는 ApplicationExitInfo에 남은 프로세스 종료 사유(REASON_LOW_MEMORY 등)도 함께 봄
이러면 맞음: 서버의 하트비트 타임아웃 끊김 직전에 클라이언트가 일시 정지로 들어갔고 복귀 직후 재접속함
이러면 아님: 앱을 앞에 띄워 둔 동안 끊겼다면 “NAT 매핑 만료”, “통신사 공유 IP (CGNAT)”, “와이파이 ↔ LTE·5G 전환”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 폰은 메모리가 모자라면 내려 둔 게임을 아예 종료하기도 합니다. 카메라나 결제·인증 앱을 다녀오면 게임이 처음부터 다시 켜지는 것도 이 때문입니다. 저사양 기기일수록 흔합니다.

출처 5건

Extending your app’s background execution time Apple
백그라운드로 가면 applicationDidEnterBackground에 5초가 주어지고 곧 일시 정지, 더 필요하면 beginBackgroundTask로 시간을 요청(남은 시간은 backgroundTimeRemaining)
Cached apps freezer Android (Google)
안드로이드 14 이상은 캐시 상태가 된 앱 프로세스를 10초 뒤 동결, 동결되면 모든 스레드가 멈춤
Application.runInBackground Unity
기본값 false로 백그라운드에서 멈춤, 안드로이드는 백그라운드면 설정과 관계없이 멈추고 iOS는 이 설정을 무시
MonoBehaviour.OnApplicationPause(bool) Unity
앱이 일시 정지되거나 다시 실행될 때 모든 MonoBehaviour에 OnApplicationPause(true/false)를 보냄
ApplicationExitInfo Android (Google)
REASON_LOW_MEMORY: 시스템의 저메모리 킬러가 앱 프로세스를 종료함(지원하지 않는 기기는 REASON_SIGNALED·SIGKILL로 보고)

와이파이 ↔ LTE·5G 전환 Network switch changes IP

ID co-netswitch · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·네트워크 인프라

집 밖으로 나가며 와이파이가 끊기고 LTE·5G로 바뀌면 내 IP 주소가 바뀌어 기존 연결이 무효가 됩니다.

왜 와이파이 신호가 약해져 모바일망으로 전환 → 그러면 내 IP 주소가 바뀌어 옛 주소로 맺은 연결로는 더 주고받을 수 없음 → 화면에서는 잠깐 멈춘 뒤 접속 끊김 또는 재접속

증상: 멈춤, 접속 끊김
요인: 손실
누가 겪나: 나만
언제: 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·네트워크 인프라
게임개발팀 할 일: 서버: 세션 토큰으로 주소가 바뀌어도 같은 플레이어로 이어 받고 옛 주소의 연결은 바로 정리, 주소가 바뀌어도 이어지는 프로토콜(QUIC의 연결 마이그레이션 등) 검토. 클라이언트: 네트워크 전환을 감지하면 하트비트 타임아웃을 기다리지 말고 세션 토큰으로 바로 재접속.
인프라팀 할 일: QUIC 연결 마이그레이션을 쓰면 로드밸런서가 주소·포트 대신 연결 ID로 서버를 고르도록 설정(주소·포트로 고르면 주소가 바뀐 패킷이 다른 서버로 감).
그래프에서는: 연결이 한꺼번에 끊김 · 끊김·재접속 수, 재접속 때 바뀐 IP
확인할 곳: 서버 접속 로그에서 같은 세션 토큰이 다른 IP로 재접속한 기록을 찾고 클라이언트의 기본 네트워크 변경 콜백(registerDefaultNetworkCallback) 시각과 맞춰 봄
이러면 맞음: 끊김 직후 재접속한 IP가 와이파이(집 회선) 대역에서 모바일 통신사 대역으로, 또는 그 반대로 바뀌고 그 직전에 망 전환 콜백이 옴
이러면 아님: IP가 그대로인데 끊겼다면 “기지국 핸드오버 (이동 중)”나 “모바일 신호 약함·음영 지역”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Read network state Android (Google)
기본 네트워크가 바뀌면 새 연결은 새 네트워크로 가고 이전 네트워크의 연결은 결국 강제로 끊김, registerDefaultNetworkCallback으로 전환 감지
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport IETF
연결 ID로 IP 주소·포트가 바뀌어도 연결 유지(9장), 주소·포트로만 분산하는 로드밸런서는 주소가 바뀐 패킷을 다른 서버로 보낼 수 있음(5.2.3절)
RFC 9293: Transmission Control Protocol (TCP) IETF
TCP 연결은 양 끝의 소켓(주소·포트) 쌍으로 식별됨

보안 프로그램의 패킷 검사 Antivirus / firewall inspection

ID co-security · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

백신·방화벽이 모든 패킷을 검사하면 지연이 늘고 과하면 게임을 공격으로 오인해 막습니다.

왜 보안 프로그램이 송수신 패킷을 하나하나 검사 → 그러면 패킷마다 지연이 붙고 검사가 밀리면 버려짐 → 화면에서는 핑이 불규칙하게 튀거나 접속이 막힘

증상: 뚝뚝 끊김, 접속 불가·무한 로딩
요인: 지터, 손실
누가 겪나: 나만
언제: 항상, 접속·점검 직후
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 보안 프로그램 호환성 목록 관리, 설치할 때 윈도우 방화벽에 게임 예외 등록.
외부 할 일: 유저에게 보안 프로그램에서 게임을 예외로 등록하도록 안내, 게임을 공격으로 오인하면 보안 프로그램 업체에 오탐 수정 요청.
수치 감각: 정상일 때 패킷 검사에 드는 시간은 보통 1ms도 안 됩니다. 지연과 차단은 검사 모듈이 밀리거나 버그가 있을 때, 게임 통신을 공격으로 오인할 때 생깁니다.
그래프에서는: 일부만 높음 · RTT·접속 실패(유저별)
확인할 곳: 보안 프로그램을 잠깐 끄거나 게임을 예외로 등록한 뒤 비교. 윈도우는 감사 정책의 Audit Filtering Platform Connection·Audit Filtering Platform Packet Drop을 켜면 보안 로그에 5157(연결 차단)·5152(패킷 차단)가 남고, 성능 모니터 WFPv4\Packets Discarded/sec로 버린 패킷 수를 봄
이러면 맞음: 게임 서버 주소로 가는 연결·패킷의 차단 기록이 남거나, 보안 프로그램을 끄면 핑 튐·접속 불가가 사라짐
이러면 아님: 보안 프로그램과 무관하게 같은 집의 다른 기기도 똑같으면 공유기·회선 쪽
확인 수단: 유저 쪽 환경에서 확인

출처 6건

About Windows Filtering Platform Microsoft
윈도우 네트워크 스택의 후크와 필터 엔진으로 패킷을 허용·차단하는 구조, 외부 보안 업체가 자기 필터 모듈(콜아웃)을 끼워 넣을 수 있음
Windows Firewall Rules Microsoft
기본은 들어오는 연결 차단이라 앱에 예외 규칙이 필요하고 흔히 앱 설치 프로그램이 규칙을 만듦
Address false positives/negatives in Microsoft Defender for Endpoint Microsoft
정상 프로그램을 위협으로 오인(오탐)했을 때 예외 설정과 마이크로소프트에 분석 제출하는 절차
5157(F): The Windows Filtering Platform has blocked a connection. Microsoft
이벤트 5157: Windows Filtering Platform이 연결을 차단함(Audit Filtering Platform Connection)
Audit Filtering Platform Packet Drop Microsoft
이벤트 5152: Windows Filtering Platform이 패킷을 차단함
Network-Related Performance Counters Microsoft
WFPv4·WFPv6: Packets Discarded/sec 카운터

수신 버퍼 넘침 Socket receive buffer overflow

ID co-rcvbuf · 주 담당 게임개발팀·클라이언트 개발

게임이 바빠서 소켓(OS가 제공하는 네트워크 송수신 인터페이스)에서 패킷을 늦게 꺼내면 OS 버퍼가 넘칩니다.

왜 프레임이 밀려 게임이 소켓을 늦게 읽음 → 그러면 OS 수신 버퍼가 가득 차 UDP는 버리고 TCP는 수신 윈도우를 줄여 송신을 멈추게 함 → 화면에서는 순간이동(UDP) 또는 몰아치기(TCP)

증상: 순간이동, 몰아치기
요인: 손실, 정체
누가 겪나: 나만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 수신 전용 스레드, 버퍼 크기 조정(SO_RCVBUF).
수치 감각: 기본 수신 버퍼는 OS·설정에 따라 수십~수백 KB. 사람 많은 곳의 업데이트는 1초에 수백 KB가 되기도 합니다.
그래프에서는: 인원·부하를 따라 오름 · UDP 수신 버퍼 폐기 수, 프레임 시간
확인할 곳: 윈도우 성능 모니터의 Microsoft Winsock BSP\Dropped Datagrams(소켓 수신 버퍼가 모자라 버린 UDP 수)와 UDPv4\Datagrams Received Errors를 프레임 시간과 함께 기록하고, 게임은 받은 패킷 순번의 빈 곳을 셈
이러면 맞음: 사람 많은 곳이나 긴 프레임 직후 Dropped Datagrams가 늘고 같은 순간 게임 순번에 빈 곳이 생김. 같은 시각 회선 쪽 손실은 없음
이러면 아님: Dropped Datagrams는 그대로인데 순번만 빠지면 경로상의 손실
확인 수단: 유저 쪽 환경에서 확인

출처 5건

socket(7) — Linux manual page Linux man-pages
SO_RCVBUF는 소켓 수신 버퍼 최대 크기, 기본값은 rmem_default, 최대값은 rmem_max로 정해짐(안드로이드도 리눅스 커널)
SOL_SOCKET Socket Options (Winsock2.h) Microsoft
윈도우 SO_RCVBUF: 소켓마다 수신용으로 잡아 두는 버퍼 공간
RFC 9293: Transmission Control Protocol (TCP) IETF
TCP 윈도우 필드는 수신 측이 더 받을 수 있는 바이트 수, 0이면 송신 측은 제로 윈도우 프로브만 보내며 기다림
Low Latency Workloads Management and Operations Microsoft
Microsoft Winsock BSP 카운터 세트의 Dropped Datagrams·Dropped Datagrams/sec: 앱이 처리하는 속도보다 UDP가 빨리 오거나 수신 소켓 버퍼가 모자라 버린 수
Network-Related Performance Counters Microsoft
UDPv4·UDPv6: Datagrams Received Errors, Microsoft Winsock BSP: Dropped Datagrams 카운터

클라이언트 메모리 부족·스왑 Paging / swap on client

ID co-swap · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

브라우저 탭 수십 개와 게임을 함께 켜 두면 OS가 게임 메모리 일부를 디스크로 내보냅니다.

왜 전체 램이 부족해짐 → 그러면 OS가 당장 안 쓰는 게임 메모리를 디스크로 옮김 → 화면에서는 그 부분을 다시 쓰는 순간 저장장치에 따라 수십~수백 ms 멈춤

증상: 멈춤, 뚝뚝 끊김
요인: 정체
누가 겪나: 나만
언제: 이동 중·지역 전환 때, 가끔 무작위로
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 메모리 사용량 줄이기, 남은 메모리가 적으면 경고 표시.
외부 할 일: 유저에게 최소 사양 안내, 게임 중 다른 프로그램(브라우저 탭 등) 종료 안내.
그래프에서는: 가끔 무작위로 튐 · 하드 페이지 폴트, 메모리 사용량
확인할 곳: 성능 모니터의 Memory\Pages Input/sec(하드 페이지 폴트를 해결하려고 디스크에서 읽은 페이지 수)와 작업 관리자 성능 탭의 메모리 사용량·커밋을 프레임 시간과 함께 기록
이러면 맞음: 멈춘 순간 Pages Input/sec가 솟고 메모리가 거의 꽉 차 있음. 브라우저 등 다른 프로그램을 닫으면 사라짐
이러면 아님: 메모리에 여유가 있고 Pages Input/sec가 조용하면 “메인 스레드 동기 로딩·셰이더 컴파일”이나 “저장장치가 느려 에셋 스트리밍이 밀림”
확인 수단: 유저 쪽 환경에서 확인

출처 3건

Introduction to the page file Microsoft
페이지 파일은 디스크에 있는 파일로, 자주 안 쓰는 수정된 메모리 페이지를 램에서 내보내는 데 씀
Working Set Microsoft
램에 없는 페이지를 건드리면 페이지 폴트, 하드 폴트는 페이지 파일 등 디스크에서 읽어 와야 해결됨
Chapter 12 - Detecting Memory Bottlenecks Microsoft
Memory\Pages Input/sec: 페이지 폴트를 해결하려고 디스크에서 읽은 페이지 수(하드 페이지 폴트)

그래픽 메모리(VRAM) 부족 VRAM over-commit

ID co-vram · 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부

그래픽 옵션이 요구하는 메모리가 그래픽카드 메모리보다 크면, OS가 텍스처를 PC 메모리로 내보냈다가 다시 가져오느라 뚝뚝 끊깁니다.

왜 높은 텍스처 옵션, 사람 많은 곳의 온갖 장비·이펙트로 그래픽카드 메모리가 가득 참 → 그러면 OS가 당장 안 쓰는 텍스처를 PC 메모리로 옮겼다가, 필요할 때 느린 PCIe 버스로 다시 가져옴 → 화면에서는 새 장면이나 새 캐릭터가 보일 때마다 멈칫, 텍스처가 한동안 흐릿함

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 나만
언제: 사람이 몰릴 때, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부
게임개발팀 할 일: 그래픽카드 메모리 크기에 맞춘 옵션 기본값, 메모리 예산을 넘으면 텍스처 품질 자동 낮추기, 사람 많은 곳은 캐릭터 텍스처 간소화.
외부 할 일: 유저에게 텍스처 옵션 낮추기 안내, 클라이언트를 두 개 띄우면 옵션을 더 낮추도록 안내.
수치 감각: 그래픽카드 메모리는 1초에 수백 GB를 읽지만 PC 메모리와 오가는 PCIe 버스는 세대에 따라 1초에 16~64GB 안팎이라 열 배 넘게 느립니다.
그래프에서는: 한도에 닿아 평평해짐 · 전용 GPU 메모리, 공유 GPU 메모리
확인할 곳: 작업 관리자 성능 탭 GPU 항목의 전용 GPU 메모리·공유 GPU 메모리 그래프(세부 정보 탭에 프로세스별 열도 추가 가능)를 PresentMon 프레임 시간과 함께 봄
이러면 맞음: 전용 GPU 메모리가 한도에 붙어 평평해지고 공유 GPU 메모리가 늘어나는 동안 멈칫이 잦고, 텍스처 옵션을 낮추면 사라짐
이러면 아님: 전용 메모리에 여유가 있으면 “저장장치가 느려 에셋 스트리밍이 밀림”이나 “메인 스레드 동기 로딩·셰이더 컴파일”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 윈도우 작업 관리자의 GPU 항목에서 “전용 GPU 메모리”가 꽉 차고 “공유 GPU 메모리”가 늘어나면 이 상태입니다. 같은 PC에 클라이언트를 두 개 띄우면 더 빨리 찹니다(“메모리·VRAM 부족으로 스트리밍 실패” 항목).

출처 4건

Residency Microsoft
프로세스가 쓸 수 있는 그래픽 메모리 예산이 있고 넘치면 커널이 외장 GPU의 힙 일부를 PC 메모리로 옮김(최후의 수단이라 예산 관리 권장)
GPUs in the task manager Microsoft
작업 관리자의 전용 GPU 메모리는 그래픽카드의 VRAM, 공유 GPU 메모리는 GPU와 CPU가 함께 쓰는 PC 메모리
CUDA C++ Best Practices Guide NVIDIA
그래픽 메모리 대역폭(V100 898GB/s)이 PCIe x16 3세대(16GB/s)보다 훨씬 커서 PC 메모리와 오가는 전송을 줄이라고 권장
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime(프레임 사이 CPU 시간)으로 프레임별 시간을 녹화

와이파이 백그라운드 스캔 Periodic Wi-Fi background scan

ID co-wifi-scan · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

OS가 주변 와이파이를 찾으려고 주기적으로 채널을 옮겨 다니는 동안 통신이 잠깐 멈춥니다.

왜 OS·드라이버가 일정 주기로 주변 와이파이를 검색 → 그러면 검색하는 동안 송수신이 잠깐 멈춤 → 화면에서는 정확히 일정한 간격(예: 60초마다)으로 핑이 튐

증상: 뚝뚝 끊김, 순간이동
요인: 지터
누가 겪나: 나만
언제: 일정한 주기로
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 게임 중 무선 검색을 줄이는 모드 요청(안드로이드는 저지연 와이파이 모드 WIFI_MODE_FULL_LOW_LATENCY, 윈도우는 WlanSetInterface의 미디어 스트리밍 모드. 기기·드라이버에 따라 효과가 없기도 함).
외부 할 일: 유저에게 유선 연결, 위치 서비스·와이파이 자동 검색 설정 조정, 무선 드라이버 업데이트 안내.
수치 감각: 보통 한 번에 수십~수백 ms. 너무 규칙적이면 이 원인을 먼저 의심합니다.
그래프에서는: 일정 주기로 튐 · 공유기까지 RTT
확인할 곳: 게임 중 ping /t로 공유기 주소(ipconfig의 기본 게이트웨이)를 몇 분 동안 재고 튀는 간격을 잼. 유선으로 바꿔 같은 측정
이러면 맞음: 공유기까지의 핑이 정확히 일정한 간격(예: 60초)으로 수십~수백 ms 튀고 유선에서는 사라짐
이러면 아님: 튀는 간격이 불규칙하면 “와이파이 간섭·신호 약화”. 공유기까지는 멀쩡하고 그 너머만 튀면 회선·통신사 구간
확인 수단: 유저 쪽 환경에서 확인

출처 5건

WDI low latency connection quality Microsoft
검색·로밍은 무선 칩을 연결된 채널 밖으로 옮기므로, 저지연 모드에서는 채널을 벗어나는 시간과 검색을 제한
WlanSetInterface function (wlanapi.h) Microsoft
윈도우에서 백그라운드 검색(wlan_intf_opcode_background_scan_enabled)과 미디어 스트리밍 모드를 켜고 끄는 API
Wi-Fi low-latency mode Android (Google)
저지연 모드에서는 와이파이 절전을 끄고 검색·로밍 설정 최적화는 기기 제조사 구현에 따라 다름
ping Microsoft
/t: 멈출 때까지 계속 에코 요청을 보냄
ipconfig Microsoft
매개변수 없이 실행하면 어댑터별 IPv4·IPv6 주소와 기본 게이트웨이를 보여 줌

NIC 절전·드라이버 문제 NIC power saving, driver bugs

ID co-driver · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

랜카드·와이파이 칩이 패킷 사이에 절전 상태로 들어가면 다시 활성화되는 데 시간이 걸립니다.

왜 네트워크 장치 절전 기능이 켜져 있거나 드라이버가 오래됨 → 그러면 절전 해제(wake-up) 지연, 가끔 장치 재시작 → 화면에서는 불규칙한 지연, 드물게 수 초 멈춤

증상: 뚝뚝 끊김, 멈춤
요인: 지터, 손실
누가 겪나: 나만
언제: 가만히 있다가, 가끔 무작위로
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 안드로이드 클라이언트는 게임 중 저지연 와이파이 모드(WIFI_MODE_FULL_LOW_LATENCY)를 요청해 와이파이 절전 끄기.
외부 할 일: 유저에게 네트워크 드라이버 업데이트, 장치 관리자에서 네트워크 장치 절전 해제 안내, 화면 전체가 멈칫하고 소리가 지직거리면 LatencyMon으로 원인 드라이버를 찾도록 안내.
그래프에서는: 가끔 무작위로 튐 · DPC·ISR 시간, 공유기까지 RTT
확인할 곳: 윈도우 성능 레코더(WPR)로 녹화해 윈도우 성능 분석기(WPA)의 DPC/ISR 그래프에서 오래 도는 드라이버(Module 열)를 찾고, 장치 관리자에서 네트워크 어댑터의 전원 관리(절전) 설정을 확인
이러면 맞음: 멈칫한 시각에 네트워크 드라이버의 DPC·ISR이 몇 ms씩 이어지거나, 절전을 끄면 불규칙한 지연이 사라짐
이러면 아님: DPC가 짧고 절전을 꺼도 같으면 “와이파이 간섭·신호 약화”나 “와이파이 백그라운드 스캔”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 드라이버가 인터럽트를 처리하느라 CPU를 오래 점유하면(윈도우에서는 DPC 지연이라고 부릅니다) 그동안 게임 스레드도 코어를 못 씁니다. 이때는 CPU 사용률이 낮은데도 화면 전체가 멈칫하고 소리도 지직거립니다. LatencyMon 같은 도구로 어느 드라이버인지 찾을 수 있고 와이파이·랜 드라이버가 흔한 원인입니다.

출처 4건

Introduction to NDIS Selective Suspend Microsoft
윈도우는 쉬고 있는 네트워크 어댑터를 저전력 상태로 보낼 수 있음(선택적 절전)
Guidelines for Writing DPC Routines Microsoft
DPC가 도는 동안 그 코어의 모든 스레드가 멈추므로 한 번에 100µs를 넘기지 않도록 권고
Wi-Fi low-latency mode Android (Google)
안드로이드 저지연 와이파이 모드는 프레임워크가 와이파이 절전을 명시적으로 끔
CPU Analysis Microsoft
WPA의 DPC/ISR 그래프: DPC·ISR이 끊김 없이 돈 구간별 시간과 그 함수가 들어 있는 모듈(Module)

같은 기기의 다른 앱이 대역폭 점유 Other apps saturating the link

ID co-other-apps · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

클라우드 동기화, 대용량 다운로드, 게임 패치가 같은 PC에서 돌면 게임 패킷이 대기열에서 기다립니다.

왜 다른 앱이 업로드·다운로드를 최대로 사용 → 그러면 PC와 공유기의 대기열에 게임 패킷이 쌓임 → 화면에서는 핑 폭등, 입력 지연, 몰아치기

증상: 입력 지연, 몰아치기
요인: 지연, 지터
누가 겪나: 나만, 같은 집
언제: 가끔 무작위로
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 우리 런처·패처는 게임 중 백그라운드 다운로드를 멈추거나 속도 제한.
외부 할 일: 유저에게 다운로드 속도 제한, 게임 중 자동 업데이트 끄기 안내.
그래프에서는: 인원·부하를 따라 오름 · RTT, PC 송수신량
확인할 곳: 성능 모니터의 Network Interface\Bytes Sent/sec·Bytes Received/sec와 핑을 함께 기록. 핑을 켜 둔 채 일부러 대용량 전송을 걸어 보는 버퍼블로트 테스트와 같은 방식
이러면 맞음: 다운로드·업로드가 회선 속도 가까이 차는 동안 핑이 수십~수백 ms 오르고, 전송을 멈추면 바로 돌아옴
이러면 아님: PC 송수신량이 낮은데 핑이 오르면 같은 집 다른 기기의 “버퍼블로트 (공유기 대기열)”나 통신사 구간
확인 수단: 유저 쪽 환경에서 확인

출처 4건

Introduction Bufferbloat.net
공유기 등 네트워크 장비가 데이터를 너무 많이 쌓아 두면 지연이 크게 튐(버퍼블로트)
Delivery Optimization reference Microsoft
윈도우 업데이트 다운로드(배달 최적화)는 기본값이 사용 가능한 대역폭에 맞춰 동적으로 조절되고, 백그라운드·포그라운드 다운로드 대역폭 상한을 설정할 수 있음
Network-Related Performance Counters Microsoft
Network Interface: Bytes Received/sec·Bytes Sent/sec 카운터
Tests for Bufferbloat Bufferbloat.net
핑을 켜 둔 채 속도 측정으로 회선을 채워 핑이 오르면 버퍼블로트

창 최소화·비활성 시 처리 제한 Minimized / unfocused window throttling

ID co-unfocused · 주 담당 게임개발팀·클라이언트 개발

다른 창을 보거나 게임을 최소화하면 게임과 윈도우가 전기를 아끼려고 게임을 느리게 돌립니다. 돌아오면 밀린 패킷이 몰려오거나, 이미 접속이 끊겨 있습니다.

왜 Alt+Tab으로 다른 창을 보거나 게임을 최소화 → 그러면 게임이 보이지 않는 동안 FPS를 크게 낮추거나 멈추고 윈도우도 보이지 않는 프로그램의 우선순위를 낮춤 → 화면에서는 돌아오는 순간 몰아치기, 오래 내려 두었다면 접속 끊김

증상: 몰아치기, 뚝뚝 끊김, 접속 끊김
요인: 정체
누가 겪나: 나만
언제: 특정 행동을 할 때, 가만히 있다가
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 창이 안 보여도 패킷 수신과 하트비트는 별도 스레드에서 계속, 엔진의 “백그라운드에서 실행” 설정 확인, 복귀할 때 최신 상태로 한 번에 맞추기.
수치 감각: 창이 안 보일 때 FPS를 5~10으로 낮추면 프레임 하나가 100~200ms. 패킷을 프레임마다 처리하는 게임은 그만큼 패킷을 늦게 읽습니다.
그래프에서는: 끊겼다가 몰아서 · 프레임 간격(창 전환 전후), 처리한 패킷 수
확인할 곳: PresentMon을 켠 채로 Alt+Tab·최소화를 해 보고 창이 안 보일 때의 프레임 간격을 봄. 게임 로그에 창 포커스가 바뀐 시각을 남겨 끊김 사유와 맞춰 봄
이러면 맞음: 창이 안 보이는 동안 프레임 간격이 100ms 이상으로 늘거나 기록이 끊기고, 돌아온 순간 밀린 패킷을 한꺼번에 처리하며 몰아치기. 오래 내려 두면 하트비트 타임아웃으로 끊김
이러면 아님: 창을 띄워 둔 채로도 같으면 “백그라운드 프로세스의 CPU 점유”나 네트워크 쪽
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 윈도우 11은 최소화되거나 완전히 가려져 소리도 내지 않는 창의 프로그램에 1ms 타이머를 보장하지 않습니다. 배터리로 도는 노트북에서는 그런 프로그램을 전기를 가장 적게 쓰는 속도로 낮추고, 코어 종류가 섞인 CPU라면 느린 효율 코어로 돌리기도 합니다. 같은 PC의 두 클라이언트 중 백그라운드 쪽만 이상하다면 “백그라운드 창의 처리 제한” 항목을 함께 보세요.

출처 4건

Quality of Service Microsoft
보이지도 들리지도 않는 창의 프로그램은 Low QoS, 배터리일 때 가장 효율적인 CPU 속도와 효율 코어로 스케줄링
timeBeginPeriod function (timeapi.h) Microsoft
윈도우 11은 가려지거나 최소화된 창의 프로세스에 기본보다 높은 타이머 해상도를 보장하지 않음
Application.runInBackground Unity
유니티 기본값은 false라 창이 백그라운드로 가면 게임 루프가 멈춤
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsBetweenPresents: 이번 Present() 호출과 이전 호출 사이 시간(ms)

오버레이 프로그램 간섭 Overlays and screen hooks

ID co-overlay · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

메신저·런처·녹화·FPS 표시 프로그램이 게임 화면 위에 자기 UI를 덧그리려고 게임의 렌더링 과정에 끼어듭니다(후킹). 프레임마다 작업이 늘고 가끔 게임과 부딪혀 멈칫하거나 게임이 강제로 꺼집니다.

왜 메신저·게임 런처·그래픽카드 도구·녹화 프로그램의 오버레이가 켜져 있음 → 그러면 프레임을 화면에 내보낼 때마다 오버레이가 끼어들어 자기 UI를 덧그림 → 화면에서는 프레임이 조금씩 늦고 알림이 뜨는 순간 멈칫하거나 그래픽 오류·강제 종료(플레이어에게는 접속 끊김처럼 보임)

증상: 뚝뚝 끊김, 멈춤, 접속 끊김
요인: 정체
누가 겪나: 나만
언제: 항상, 가끔 무작위로
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 크래시 리포트와 뚝뚝 끊김 로그에 실행 중인 오버레이 목록을 함께 모으기.
외부 할 일: 제보가 오면 유저에게 오버레이를 모두 끄고 다시 시험하도록 안내.
그래프에서는: 일부만 높음 · 프레임 시간·크래시 수(오버레이를 켠 유저)
확인할 곳: 오버레이를 모두 끄고 같은 장면의 PresentMon 프레임 시간을 비교하고, 크래시가 있으면 이벤트 뷰어 이벤트 ID 1000의 오류 모듈 이름(Faulting module name)을 봄
이러면 맞음: 오버레이를 끄면 멈칫·그래픽 오류가 사라지거나, 크래시의 오류 모듈이 오버레이 프로그램의 DLL임
이러면 아님: 오버레이를 모두 꺼도 같으면 그래픽 드라이버나 “클라이언트 크래시”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 특정 사람만 뚝뚝 끊기거나 게임이 꺼지고 사양으로는 설명이 안 될 때, 오버레이와 게임 보안 모듈의 충돌을 먼저 의심합니다.

출처 3건

Steam Overlay (Steamworks Documentation) Valve
스팀 오버레이는 스팀으로 실행한 게임에 자동으로 후킹해 끼어들고 그 방식 때문에 게임의 렌더링 API 사용상 메모리 오류를 드러내 크래시가 나기도 함
PresentMon Capture Application (README-CaptureApplication.md) Intel
FrameTime(프레임 사이 CPU 시간)으로 프레임별 시간을 녹화
The application or service crashing behavior troubleshooting guidance Microsoft
응용 프로그램 로그의 이벤트 ID 1000은 오류 모듈 이름(Faulting module name)을 담고, 다른 모듈의 손상 때문에 윈도우 모듈이 오류 모듈로 찍히기도 함

디스플레이·입력 장치·프레임 생성 지연 Display, input device and frame generation latency

ID co-display-input · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

핑은 정상인데 조작이 묵직하다면, TV의 영상 처리나 무선 컨트롤러, 프레임 생성 기능이 입력과 화면 사이에 지연을 더했을 수 있습니다.

왜 TV 게임 모드가 꺼져 있거나, 블루투스·무선 컨트롤러를 쓰거나, 프레임 생성(DLSS·FSR 프레임 생성)을 켬 → 그러면 TV는 화질 처리를 하는 동안 프레임을 늦게 내보내고 무선 입력은 전송 주기와 간섭만큼 늦게 도착하며 프레임 생성은 다음 프레임을 기다렸다가 사이 프레임을 만듦 → 화면에서는 핑과 FPS 숫자는 좋은데 누른 뒤 화면에 반영되기까지 늦어 입력 지연

증상: 입력 지연
요인: 지연
누가 겪나: 나만
언제: 항상
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 프레임 생성은 선택 옵션으로 두고 켜면 입력 지연이 늘 수 있다고 안내, 프레임 생성을 쓸 때는 그래픽 제조사의 저지연 기능(NVIDIA Reflex, AMD Anti-Lag 2)을 함께 연동, 게임 안에서 PC 쪽 입력~화면 지연을 보여 주는 표시, 안드로이드 TV·셋톱 빌드는 Window.setPreferMinimalPostProcessing(true)로 TV에 저지연 모드(ALLM) 요청.
외부 할 일: 유저에게 TV·모니터의 게임 모드(ALLM) 켜기, 경쟁 콘텐츠에서는 유선 컨트롤러와 프레임 생성 끄기, 블루투스 기기는 가까이 두고 와이파이는 5GHz 쓰기 안내.
수치 감각: 60Hz 화면은 프레임 하나를 보내는 데만 16.7ms, 120Hz면 8.3ms가 걸립니다. 예전 Xbox 컨트롤러는 입력을 8ms마다 읽어 보냈습니다. TV 영상 처리가 더하는 지연은 기기마다 달라 한 숫자로 말하기 어렵고 게임 모드는 이 처리를 줄이는 설정입니다. 프레임 생성은 AMD가 생성 전 프레임률 60FPS 이상에서 쓰도록 권장합니다.
그래프에서는: 처음부터 늘 높음 · 입력~화면 지연
확인할 곳: PresentMon의 MsAllInputToPhotonLatency(키보드·마우스 입력부터 화면으로 내보내기까지)를 프레임 생성을 켜고 끄며 비교하고, FrameType(드라이버·SDK가 알려 줄 때만 기록됨)으로 생성된 사이 프레임이 섞였는지 봄. 이 값에는 컨트롤러 무선 구간과 TV 안의 처리가 들어가지 않으므로, 그 부분은 TV 게임 모드·유선 컨트롤러로 바꿔 가며 비교
이러면 맞음: 핑은 정상인데 프레임 생성을 끄면 입력~화면 지연이 줄거나, TV 게임 모드·유선 컨트롤러로 바꾸면 체감 지연이 사라짐
이러면 아님: 이 설정들을 모두 바꿔도 같고 핑이 높거나 튀면 네트워크 쪽. PC 쪽 지연이 V-Sync·프레임 대기열 때문에 높으면 “V-Sync와 렌더 대기열”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 네트워크 지연은 핑으로 보이지만 이 지연은 핑에 잡히지 않습니다. “핑은 낮은데 렉”이라는 제보라면 이 지연을 먼저 확인합니다. 프레임 생성은 화면의 FPS 숫자를 두 배쯤 올리지만 사이 프레임을 만들려면 다음 진짜 프레임을 기다려야 해서 입력이 화면에 반영되기까지의 시간은 늘어납니다(AMD는 설계상 지연이 늘어난다고 밝힘). 블루투스 기기는 와이파이와 같은 2.4GHz 대역을 써서, 간섭을 받으면 입력이 끊기거나 튈 수 있습니다. PC 안의 지연을 키우는 V-Sync·렌더 대기열은 “V-Sync와 렌더 대기열” 항목을 보세요.

출처 9건

Auto Low Latency Mode (ALLM) HDMI Licensing Administrator
ALLM은 기기가 디스플레이를 저지연 모드(흔히 게임 모드)로 자동 전환하게 함, 저지연 모드에서는 지연을 줄이려고 TV의 일부 영상 처리를 멈춤
Xbox Series X: What’s the Deal with Latency? Microsoft
입력 지연은 컨트롤러→콘솔→HDMI→TV로 이어지는 경로의 합, 예전 컨트롤러는 입력을 8ms마다 읽어 보냄, HDMI로 프레임 하나를 보내는 시간 60Hz 16.6ms·120Hz 8.3ms, ALLM으로 TV 게임 모드 자동 전환
AMD FSR 3 game integrations out now + more details for developers AMD
프레임 보간은 설계상 지연을 늘림, 보간 전 프레임률 60 이상에서 쓰도록 권장, 60FPS 입력으로 최대 120FPS 출력
AMD FSR Frame Generation AMD
프레임 생성은 보간 전 60FPS 이상 권장(30FPS 미만은 피해야 함), AMD Radeon Anti-Lag 2가 CPU·GPU 작업을 맞춰 시스템 지연을 줄임
NVIDIA DLSS NVIDIA
DLSS 프레임 생성은 NVIDIA Reflex(저지연 기능)와 함께 응답성을 유지하도록 설계됨
Resolve Wi-Fi and Bluetooth issues caused by wireless interference Apple
무선 간섭은 와이파이·블루투스 기기의 끊김과 성능 저하를 만들고 블루투스와 와이파이는 같은 2.4GHz 대역을 씀
PresentMon Capture Application (README-CaptureApplication.md) Intel
MsAllInputToPhotonLatency(입력~화면 지연), DisplayLatency(프레임 제출~모니터로 내보내기), FrameType(앱이 그린 프레임과 드라이버·SDK가 보간한 프레임 구분)
PresentMon Console Application (README-ConsoleApplication.md) Intel
MsAllInputToPhotonLatency는 키보드·마우스 입력 기준, FrameType은 앱·드라이버가 Intel-PresentMon 이벤트를 내보내야 기록됨(--track_frame_type)
Window.setPreferMinimalPostProcessing Android (Google)
게임처럼 지연이 중요한 창은 디스플레이에 최소 영상 처리를 요청, HDMI 연결이면 ALLM·Game Content Type 신호를 보내 TV를 저지연 모드로 바꿈

L3 집 네트워크

와이파이 간섭·신호 약화 Wi-Fi interference, weak signal

ID hn-wifi · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

신호가 약하거나 간섭이 생기면 무선 구간에서 몇 번씩 다시 보내느라 도착이 들쭉날쭉해집니다.

왜 벽·거리·전자레인지·블루투스·이웃 공유기로 전파 품질 저하 → 그러면 무선 구간에서 전송 실패 → 몇 번씩 재전송 → 화면에서는 패킷 도착이 들쭉날쭉(지터)해 캐릭터가 멈칫멈칫, 심하면 손실로 순간이동

증상: 뚝뚝 끊김, 순간이동, 고무줄
요인: 지터, 손실
누가 겪나: 나만, 같은 집
언제: 가끔 무작위로, 항상
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 회선 상태에 따라 보간 버퍼 길이 자동 조절, 지터·손실이 크면 화면에 네트워크 상태 표시.
외부 할 일: 유저에게 유선 연결, 5GHz·6GHz 사용, 공유기 위치 옮기기 안내.
수치 감각: 재전송 한 번에 1~4ms쯤 더 걸립니다. 신호가 약하면 느린 속도로 여러 번 다시 보내고 채널이 빌 때까지 대기도 해서, 50~200ms씩 튀기도 합니다. 평균 핑은 멀쩡해 보여서 놓치기 쉽습니다.
그래프에서는: 가끔 무작위로 튐 · 공유기까지 RTT
확인할 곳: ping /t로 공유기 주소(ipconfig의 기본 게이트웨이)까지 몇 분 재고, netsh wlan show networks mode=bssid로 내 공유기의 신호 세기·채널을 봄. 같은 자리에서 유선으로 바꿔 비교
이러면 맞음: 공유기까지의 핑부터 불규칙하게 수십~수백 ms 튀고 가끔 손실이 나며 신호 세기가 낮음. 유선이나 공유기 가까이에서는 사라짐
이러면 아님: 공유기까지는 고른데 그 너머만 튀면 회선·통신사 구간. 같은 간격으로만 튀면 “와이파이 백그라운드 스캔”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 메시 와이파이에서 공유기(노드)끼리 무선으로 이어져 있으면(무선 백홀), 중계하는 노드는 받는 동안 보낼 수 없고 같은 채널을 쓰는 앞뒤 구간과 전송 기회를 나눠 씁니다. 이 때문에 붐빌 때 처리량이 줄고 지연이 더해질 수 있습니다. 백홀 전용 무선 대역이 있는 제품은 덜할 수 있고 노드끼리 유선(이더넷)으로 이으면 이 구간이 무선에서 빠집니다. 전력선 어댑터(PLC)도 와이파이처럼 매체가 비었는지 확인하고 보내는 방식(CSMA/CA)을 씁니다. 가전제품이 내는 잡음과 가전제품을 켜고 끄는 일에 따라 품질이 수시로 바뀌어 재전송과 지터가 생길 수 있습니다.
실제 사례: Square Enix 2021: FINAL FANTASY XIV 확장팩 출시 혼잡과 로그인 대기열 오류

출처 8건

Resolve Wi-Fi and Bluetooth issues caused by wireless interference Apple
전자레인지·무선 전화기 같은 간섭원, 와이파이와 블루투스가 같은 2.4GHz 대역을 씀, 5GHz로 옮기기와 간섭이 적은 채널 고르기 권장
RFC 8325: Mapping Diffserv to IEEE 802.11 IETF
802.11의 CSMA/CA: 채널이 비어 있을 때만 보내고 바쁘면 빌 때까지 미룬 뒤 무작위 백오프만큼 더 기다림
Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017) USENIX
부하가 걸린 와이파이의 기본 대기열은 수백 ms 지연, 느린 속도로 붙은(신호 약한) 기기는 FQ-CoDel을 써도 중앙값 200ms 넘음
ping Microsoft
/t: 멈출 때까지 계속 에코 요청을 보냄
ipconfig Microsoft
매개변수 없이 실행하면 어댑터별 IPv4·IPv6 주소와 기본 게이트웨이를 보여 줌
Wireless network connectivity issues troubleshooting Microsoft
netsh wlan show networks mode=bssid: 보이는 와이파이마다 BSSID·신호 세기·채널·무선 방식을 보여 줌
Capacity of Ad Hoc Wireless Networks (MobiCom 2001) ACM
802.11 무선으로 여러 번 중계하면 노드가 받는 동안 보낼 수 없고 앞뒤 구간이 서로 간섭해, 한 줄로 중계하는 경로의 처리량이 이론상 3분의 1(모의실험에서는 약 7분의 1)까지 떨어짐
Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015) ACM
전력선 통신(IEEE 1901·HomePlug AV) 상용 장비는 와이파이와 비슷한 CSMA/CA로 보내며 짧은 시간의 불공평으로 지터가 커질 수 있고, 채널 품질이 가전제품이 내는 잡음과 가전제품을 켜고 끄는 일(몇 분~몇 시간 단위)에 따라 변함

와이파이 채널 혼잡 Crowded Wi-Fi channel

ID hn-channel · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

아파트처럼 공유기가 수십 개 있는 곳은 같은 채널을 나눠 쓰느라 전송 기회를 기다립니다.

왜 수십 개 공유기가 같은 2.4GHz 채널을 사용 → 그러면 전송하려면 다른 기기의 전송이 끝나 채널이 빌 때까지 대기 → 화면에서는 사람들이 집에 오는 저녁 시간에 지터(도착 간격의 흔들림)가 늘어 뚝뚝 끊김

증상: 뚝뚝 끊김, 입력 지연
요인: 지터, 지연
누가 겪나: 같은 집
언제: 저녁 피크 시간
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 지터가 늘면 보간 버퍼 길이를 자동으로 늘리기.
외부 할 일: 유저에게 5GHz·6GHz, 덜 붐비는 채널, 유선 연결 안내.
그래프에서는: 특정 시간대에만 높음 · 공유기까지 RTT·지터
확인할 곳: netsh wlan show networks mode=bssid로 주변 와이파이의 채널과 신호 세기를 보고, 저녁과 낮에 공유기까지 핑을 재어 비교
이러면 맞음: 2.4GHz 같은 채널에 주변 공유기가 많이 잡히고 공유기까지의 지터가 저녁 시간에만 커짐. 5GHz·6GHz나 덜 붐비는 채널로 옮기면 줄어듦
이러면 아님: 시간대와 상관없이 튀면 “와이파이 간섭·신호 약화”. 공유기까지는 괜찮고 저녁에 그 너머만 나쁘면 “피크 시간 피어링 구간 혼잡”
확인 수단: 유저 쪽 환경에서 확인

출처 4건

Recommended settings for Wi-Fi routers and access points Apple
같은 채널을 쓰는 다른 공유기·기기가 간섭원, 2.4GHz는 20MHz 폭 권장, 5GHz·6GHz는 간섭 걱정이 덜함
RFC 8325: Mapping Diffserv to IEEE 802.11 IETF
802.11은 채널이 바쁘면 빌 때까지 전송을 미루고 무작위 백오프 뒤에 보냄(CSMA/CA)
Wireless network connectivity issues troubleshooting Microsoft
netsh wlan show networks mode=bssid: 보이는 와이파이마다 BSSID·신호 세기·채널·무선 방식을 보여 줌
ping Microsoft
/t: 멈출 때까지 계속 에코 요청을 보냄

버퍼블로트 (공유기 대기열) Bufferbloat

ID hn-bufferbloat · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

가족 누군가 영상을 올리거나 큰 파일을 받으면 공유기 대기열에 수백 ms 분량의 패킷이 쌓이고, 게임 패킷도 그 뒤에서 기다립니다.

왜 가족의 영상 업로드·클라우드 백업, 내 방송 송출, 대용량 다운로드로 회선이 꽉 참 → 그러면 공유기나 모뎀이 넘치는 패킷을 큰 대기열에 쌓아 둠 → 화면에서는 게임 패킷도 대기열 뒤에서 기다려 핑이 수백 ms로 폭등

증상: 입력 지연, 몰아치기, 순간이동
요인: 지연, 지터
누가 겪나: 같은 집, 나만
언제: 가끔 무작위로, 저녁 피크 시간
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 핑이 갑자기 수백 ms로 오르면 화면에 네트워크 상태 표시(같은 회선의 대용량 전송 가능성 안내).
외부 할 일: 유저에게 SQM(fq_codel, CAKE)이나 QoS가 있는 공유기 사용, SQM 속도는 회선 속도의 90~95%로 맞추기(그래야 대기열이 공유기 안에 생겨 효과가 남), 업로드 속도 제한 안내.
수치 감각: 업로드 10Mbps 회선에 1MB 버퍼면 대기열이 800ms 분량까지 길어집니다.
그래프에서는: 인원·부하를 따라 오름 · RTT, 회선 업로드·다운로드 사용량
확인할 곳: 핑을 켜 둔 채 속도 측정으로 회선을 가득 채워 보거나, 부하 중 지연을 재는 웹 테스트를 씀(Bufferbloat.net 안내). 공유기 화면의 업로드·다운로드 사용량과 함께 봄
이러면 맞음: 업로드나 다운로드가 회선을 채우는 동안 핑이 수백 ms로 오르고 전송이 끝나면 돌아옴(부하 중 지연이 50ms를 넘으면 의심). SQM을 켜면 사라짐
이러면 아님: 회선이 한가한데도 핑이 튀면 “와이파이 간섭·신호 약화”나 “회선 품질 불량”
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 업로드 쪽이 특히 잘 막힙니다. 케이블·모바일 회선은 업로드가 다운로드보다 훨씬 좁은 경우가 많기 때문입니다. 광랜이 넉넉한 집에서는 와이파이 구간이 병목이 되어, 공유기의 무선 대기열에서 같은 일이 생깁니다. 게임 패킷은 작아서 대역폭은 거의 안 쓰지만 대기열에서는 똑같이 기다려야 합니다. 업로드 방향만 막히면 내 입력만 늦고 남의 움직임은 멀쩡합니다. 폰에서는 같은 폰의 사진 백업·앱 업데이트가 폰 모뎀과 기지국의 대기열을 채워 같은 일이 생깁니다.

출처 4건

Setting up SQM for CeroWrt 3.10 Bufferbloat.net
SQM 속도를 실측 속도의 95%(광고 속도 기준이면 85%)로 낮춰 병목을 통신사 장비에서 공유기 안으로 가져와야 효과가 남
SQM (Smart Queue Management) OpenWrt
다운로드·업로드 속도를 실측의 90%로 입력, 대기열 방식은 cake 권장(CPU가 약하면 fq_codel)
Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017) USENIX
와이파이 구간이 꽉 차면 공유기 무선 대기열에서 수백 ms 지연이 생김, 무선 대기열을 고치면 부하 중 지연이 약 10분의 1로 줄어듦
Tests for Bufferbloat Bufferbloat.net
핑을 켜 둔 채 속도 측정으로 회선을 채워 핑이 오르면 버퍼블로트, 부하 중 지연 50ms 초과(또는 B 등급 미만)면 대책 권장

NAT 매핑 만료 NAT mapping timeout

ID hn-nat · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

공유기는 한동안 패킷이 오가지 않은 유휴 연결을 NAT 테이블에서 지웁니다. 가만히 있다가 움직이는 순간 접속이 끊기는 흔한 원인입니다.

왜 공유기가 “안쪽 기기 ↔ 바깥 서버” 연결을 NAT 테이블(주소 변환표)에 기록 → 그러면 패킷이 한동안 없으면 테이블에서 삭제(UDP는 흔히 30~120초) → 화면에서는 서버 패킷이 집 안으로 못 들어와 접속 끊김

증상: 접속 끊김
요인: 손실
누가 겪나: 나만, 같은 집
언제: 가만히 있다가
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 가장 짧은 유휴 타임아웃의 절반 이하 간격으로 하트비트 보내기(UDP 매핑은 집 안에서 나가는 패킷으로만 확실히 갱신되므로 클라이언트가 보냄), 끊기면 자동 재접속. 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리, 매핑이 지워져 바깥 주소·포트가 바뀌어도 세션 토큰(접속할 때 받은 확인 번호)으로 같은 플레이어임을 확인해 이어 받기.
그래프에서는: 연결이 한꺼번에 끊김 · 끊김 수(하트비트 타임아웃), 끊기기 전 유휴 시간
확인할 곳: 서버의 끊김 사유와, 끊기기 전 그 연결로 마지막 패킷이 오간 뒤 흐른 시간(유휴 시간)을 모아 분포로 봄. 시험으로는 UDP 패킷 간격을 30초·60초·120초로 늘려 가며 응답이 끊기는 간격을 잼
이러면 맞음: 가만히 있던 연결만 끊기고 유휴 시간이 30~120초 같은 특정 값 바로 뒤에 몰림. 하트비트 간격을 그보다 짧게 하면 사라짐
이러면 아님: 움직이는 중에도 끊기면 회선·경로 쪽. 특정 모바일 통신사에서만 짧은 값에 몰리면 “통신사 공유 IP (CGNAT)”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP IETF
UDP 매핑 타이머는 2분 전에 끝나면 안 되고 기본 5분 이상 권장, 안에서 나가는 패킷으로 갱신은 필수·바깥에서 들어오는 패킷으로 갱신은 선택
An Experimental Study of Home Gateway Characteristics (IMC 2010) ACM
가정용 공유기 34종 측정: UDP 매핑 유지 30~691초·중앙값 90초로 절반 넘게 2분 미만, TCP는 중앙값 약 60분
RFC 9308: Applicability of the QUIC Transport Protocol IETF
경로에 NAT가 있는 인터넷에서는 약 30초 간격의 keep-alive가 적당, 그보다 잦으면 트래픽·전력 낭비

공유기 성능 부족·과열 Router CPU / session table exhaustion

ID hn-router · 주 담당 외부·외부

값싼 공유기에 기기 수십 대, 연결 수천 개가 몰리면 공유기 자체가 처리를 못 합니다.

왜 기기 수십 대, P2P·토렌트가 연결 수천 개를 엶 → 그러면 공유기 CPU와 세션 테이블이 포화 → 화면에서는 패킷 처리 지연·손실, 새 연결 실패

증상: 뚝뚝 끊김, 접속 불가·무한 로딩, 접속 끊김
요인: 손실, 지터
누가 겪나: 같은 집
언제: 오래 켜 둘수록, 가끔 무작위로
담당: 주 담당 외부·외부
외부 할 일: 유저에게 공유기 재부팅(임시), 공유기 교체, 연결을 많이 여는 프로그램(P2P·토렌트) 정리 안내.
그래프에서는: 한도에 닿아 평평해짐 · 공유기 CPU·연결 수, 공유기까지 RTT
확인할 곳: 공유기 관리 화면에서 CPU 사용률·연결(세션) 수·붙은 기기 수를 보고(지원하는 공유기라면), 공유기 자신까지의 핑을 재부팅 전후로 비교
이러면 맞음: 연결 수가 많을 때 공유기까지의 핑부터 튀거나 손실이 나고 새 접속이 실패함. 재부팅하면 한동안 괜찮다가 다시 나빠짐
이러면 아님: 공유기까지는 멀쩡하고 그 너머만 나쁘면 회선·통신사 구간
확인 수단: 유저 쪽 환경에서 확인

출처 2건

An Experimental Study of Home Gateway Characteristics (IMC 2010) ACM
가정용 공유기가 한 서버 포트로 허용하는 TCP 연결 수는 16~약 1,024개(중앙값 135), 저가 장비는 처리량이 수 Mbps 수준에 그치기도 함
Netfilter Conntrack Sysfs variables Linux kernel
리눅스 연결 추적 표의 최대 항목 수(nf_conntrack_max)와 상태별 유지 시간 기본값

기지국 핸드오버 (이동 중) Cellular handover

ID hn-handover · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발

버스·지하철로 이동하면 기지국이 바뀌는 동안 통신이 끊깁니다.

왜 이동하며 접속하는 기지국이 바뀜 → 그러면 보통은 수십 ms 공백이지만 신호가 나빠 전환에 실패하면 수백 ms~수 초 끊기기도 함 → 화면에서는 멈췄다가 순간이동, 길면 접속 끊김

증상: 멈춤, 순간이동, 접속 끊김
요인: 손실
누가 겪나: 나만
언제: 이동 중·지역 전환 때
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 짧은 끊김을 견디는 타임아웃, 빠른 재접속. 서버: 몇 초 끊겨도 바로 내보내지 않는 타임아웃, 재접속하면 같은 세션으로 이어 주기.
외부 할 일: 이동 중(버스·지하철) 끊김은 기지국 전환 때문임을 유저에게 안내.
그래프에서는: 끊겼다가 몰아서 · 받은 패킷 수, RTT
확인할 곳: 끊김 제보가 이동 중(버스·지하철)이었는지 확인하고 클라이언트 로그의 수신 공백 시각과 망 종류·신호 변화를 봄
이러면 맞음: 이동 중에만 수신이 수백 ms~수 초 비었다가 몰려오고 멈춰 있을 때는 재현되지 않음
이러면 아님: 멈춰 있어도 같으면 “모바일 신호 약함·음영 지역”이나 “5G↔LTE 잦은 전환 (5G 경계 지역)”
확인 수단: 유저 쪽 환경에서 확인

출처 2건

Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s) ITU
핸드오버 중 데이터를 못 주고받는 시간의 요구치: 같은 주파수 27.5ms, 다른 주파수 40~60ms
Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020) ACM
상용망 실측 핸드오버 지연: 4G↔4G 평균 30ms, 5G(NSA) 셀 사이 평균 108ms

RRC 상태 전환 지연 (모바일 무선 절전) Radio state promotion (RRC)

ID hn-rrc · 주 담당 게임개발팀·클라이언트 개발

폰은 한동안 통신이 없으면 무선 연결을 저전력 상태로 내리고 다음 패킷 때 다시 올리느라 늦어집니다.

왜 잠시 통신이 없으면 폰이 무선 연결을 절전 상태로 전환 → 그러면 다음 패킷을 보내려면 연결을 다시 올려야 함 → 화면에서는 가만히 있다 한 첫 행동만 유독 늦음

증상: 입력 지연
요인: 지연
누가 겪나: 나만
언제: 가만히 있다가
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 가벼운 주기 전송으로 활성 유지(배터리와 맞바꿈).
수치 감각: LTE는 보통 10초 안팎 통신이 없으면 절전으로 내려가고 다시 올리는 데 수십~수백 ms가 걸립니다(실측 예: 약 0.3~0.6초). 3G는 1초 이상.
그래프에서는: 일부만 높음 · 유휴 뒤 첫 요청의 RTT(모바일)
확인할 곳: 게임 안 RTT를 직전 통신과의 간격별로 나눠 봄. 모바일에서 10초 넘게 쉬었다가 보낸 첫 패킷과 연달아 보낸 패킷의 RTT를 비교
이러면 맞음: 모바일망에서 쉬었다가 보낸 첫 패킷만 수백 ms 늦고 바로 이어 보낸 패킷은 정상. 와이파이에서는 차이가 없음
이러면 아님: 연달아 보내도 늦으면 신호·회선·경로 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013) ACM
측정한 LTE망의 절전 전환 타이머(tail) 10초, 절전에서 다시 올리는 지연 중앙값 435ms(25~75%: 319~558ms), 3G는 약 1.5~2초
Optimize network access Android (Google)
무선 상태 전환 지연과 tail 시간은 무선 기술(3G·LTE·5G)과 통신사 설정에 따라 다름, 3G 예: 저전력→최대 전력 약 1.5초, 대기→최대 전력 2초 이상
Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s) ITU
대기 상태에서 활성 상태로 올라가는 제어 평면 지연 요구치 100ms 미만(호출·유선 구간 제외)

모바일 신호 약함·음영 지역 Weak cellular signal

ID hn-weak-cell · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

엘리베이터·지하·건물 안쪽에서는 재전송이 늘고 속도가 떨어지며 결국 접속이 끊깁니다.

왜 신호가 약한 곳으로 이동 → 그러면 무선 재전송 증가, 속도 저하, 순간 단절 → 화면에서는 지터·손실로 뚝뚝 끊김·순간이동, 결국 접속 끊김

증상: 뚝뚝 끊김, 순간이동, 접속 끊김
요인: 지터, 손실
누가 겪나: 나만
언제: 이동 중·지역 전환 때
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 재접속 흐름 다듬기, 네트워크 품질 표시.
외부 할 일: 신호가 약한 곳(엘리베이터·지하·건물 안쪽)에서 생기는 문제임을 유저에게 안내.
그래프에서는: 일부만 높음 · RTT·손실(모바일 유저별)
확인할 곳: 끊김 제보 때의 장소(엘리베이터·지하·건물 안)와 폰의 신호 표시를 확인하고, 신호가 좋은 곳에서 같은 행동을 반복해 비교
이러면 맞음: 신호가 약한 곳에서만 RTT·손실이 늘고 끊기며 신호가 좋은 곳으로 옮기면 사라짐
이러면 아님: 신호가 좋은데도 같으면 통신사 구간이나 서버 쪽
확인 수단: 유저 쪽 환경에서 확인

출처 1건

An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013) ACM
LTE는 무선 구간 손실을 물리·MAC 계층 재전송으로 감춤, 가용 대역폭은 신호 세기 등에 따라 초 단위로 크게 변함

5G↔LTE 잦은 전환 (5G 경계 지역) 5G NSA / LTE switching

ID hn-5g-flip · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

5G 신호가 약한 건물 안이나 5G 경계 지역에서는 폰이 5G와 LTE를 자주 오가고, 바뀔 때마다 핑이 튀거나 통신이 잠깐 끊깁니다.

왜 5G 신호가 들쭉날쭉한 곳(건물 안, 5G 경계)에 있음 → 그러면 폰이 5G와 LTE 사이를 수시로 전환하며 그때마다 짧은 공백이 생김 → 화면에서는 가만히 있어도 규칙 없이 핑이 튀고 가끔 멈춤·순간이동

증상: 뚝뚝 끊김, 순간이동, 멈춤
요인: 지터, 손실
누가 겪나: 나만
언제: 가끔 무작위로, 이동 중·지역 전환 때
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 지터가 늘면 보간 버퍼 길이를 자동으로 늘리기, 렉이 생긴 때의 로그에 망 종류(5G·LTE) 변화를 함께 남겨 원인 구분.
외부 할 일: 유저에게 설정에서 LTE 우선 모드로 바꿔 비교해 보도록 안내, 와이파이 사용 권장.
수치 감각: 전환 한 번에 수십~수백 ms. 국내 5G는 대부분 LTE와 함께 묶어 쓰는 방식(NSA)이라 5G 쪽만 붙었다 떨어졌다 하기 쉽습니다.
그래프에서는: 가끔 무작위로 튐 · RTT, 망 종류(5G·LTE) 변화
확인할 곳: 폰 설정을 LTE 우선으로 바꿔 같은 자리에서 비교. 클라이언트가 안드로이드 TelephonyDisplayInfo의 망 표시(OVERRIDE_NETWORK_TYPE_NR_NSA 등) 변화를 RTT와 함께 기록하면 더 확실함
이러면 맞음: RTT가 튄 시각과 5G↔LTE 표시가 바뀐 시각이 겹치고 LTE 우선 모드에서는 튐이 사라짐
이러면 아님: 망 표시가 바뀌지 않는데도 튀면 “모바일 신호 약함·음영 지역”이나 회선 쪽
확인 수단: 유저 쪽 환경에서 확인

출처 3건

Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020) ACM
NSA 5G는 제어를 LTE에 맡겨 5G 셀을 바꿀 때 5G를 놓고 LTE를 거쳐 다시 붙음: 평균 108ms(4G→5G 80ms), 5G가 낀 전환 직후 TCP 처리량 73~83% 감소
5G 통신서비스 품질평가 결과 발표 과학기술정보통신부
2020년 발표 기준 국내 5G는 NSA 방식으로 제공 중이고 SA 전환은 예정 단계
TelephonyDisplayInfo Android (Google)
OVERRIDE_NETWORK_TYPE_NR_NSA: LTE에 붙어 있으면서 5G(NR)와 이중 연결(EN-DC)할 수 있거나 붙어 있을 때의 망 표시

공용 와이파이·회사망 제한 Captive portal, restrictive network

ID hn-captive · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발

카페 와이파이 로그인 페이지나 회사 방화벽이 게임 연결을 막습니다.

왜 로그인 페이지 인증 전이거나 방화벽이 게임 포트·UDP를 차단 → 그러면 접속 시도 자체가 막히거나 일부만 통과 → 화면에서는 접속 불가, 로그인은 되는데 게임 입장 실패

증상: 접속 불가·무한 로딩
요인: 손실
누가 겪나: 나만
언제: 접속·점검 직후
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 막혔을 때 이유를 알려 주는 안내(로그인 페이지 인증 전, UDP 차단 등), UDP가 막히면 대체 경로로 자동 전환. 서버: TCP 443 같은 대체 경로 제공.
외부 할 일: 유저에게 공용 와이파이는 로그인 페이지 인증을 먼저 하고 회사망처럼 막힌 곳에서는 다른 네트워크를 쓰도록 안내.
그래프에서는: 일부만 높음 · 접속 실패 수(네트워크별)
확인할 곳: 실패한 유저에게 모바일 데이터 등 다른 네트워크로 바꿔 접속해 보게 하고 서버 접속 로그에서 UDP 첫 패킷이 도착했는지와 TCP 443 대체 경로로는 붙는지를 봄
이러면 맞음: 특정 와이파이(카페·회사)에서만 실패하고 다른 망에서는 바로 붙음. 로그인 페이지 인증 전이거나 UDP만 서버에 도착하지 않음
이러면 아님: 어느 망에서도 실패하면 계정·서버·“DNS 장애·지연” 쪽. 특정 국가·통신사 전체에서 실패하면 “국가·통신사 단위 UDP 제한·패킷 검사”
확인 수단: 유저 쪽 환경에서 확인

출처 2건

RFC 8952: Captive Portal Architecture IETF
캡티브 포털: 약관 동의·인증 같은 요구 조건을 채울 때까지 접속이 제한되는 네트워크
RFC 9308: Applicability of the QUIC Transport Protocol IETF
측정 연구상 네트워크의 3~5%는 UDP를 모두 막으므로, UDP 기반 앱은 TCP(TLS) 대체 경로를 준비해야 함

L4 인터넷 회선

전파 지연 (물리적 거리) Propagation delay

ID isp-distance · 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·네트워크 인프라, 게임개발팀·서버 개발

빛도 광케이블에서 1초에 약 20만 km밖에 못 갑니다. 먼 서버는 아무리 좋아도 늦습니다.

왜 서버가 멀리 있음 (해외 서버, 다른 대륙) → 그러면 거리만큼 왕복 시간이 늘어남(1,000km당 최소 10ms) → 화면에서는 모든 행동에 일정한 입력 지연, 판정에서 불리

증상: 입력 지연
요인: 지연
누가 겪나: 특정 지역·통신사
언제: 항상
담당: 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·네트워크 인프라, 게임개발팀·서버 개발
게임개발팀 할 일: 물리 법칙은 코드로 못 고치므로 완화만 가능, 가까운 지역 서버를 고르게 하는 지역 선택, 지연 보상(되감기)으로 판정 불리 줄이기.
인프라팀 할 일: 서버 장비·OS: 이용자가 많은 지역에 지역별 서버 두기. 네트워크: 가까운 곳에 접속 거점(엣지) 두기, 우회가 적은 회선·경로 고르기.
수치 감각: 서울–도쿄 약 30ms, 서울–싱가포르 약 75ms, 서울–미국 서부 약 140ms, 서울–유럽 약 230~270ms (왕복, 실제 경로 기준). 유럽은 직선 위로 큰 케이블이 거의 없어 동남아·수에즈나 미국을 돌아가므로 거리보다 훨씬 깁니다.
그래프에서는: 처음부터 늘 높음 · RTT(국가·지역별)
확인할 곳: 접속 IP에 국가를 붙여 국가별 RTT 분포를 보고 그 지역의 클라우드 리전 VM이나 RIPE Atlas 프로브(국가·ASN으로 고름)에서 서버까지 ping·traceroute로 잼
이러면 맞음: 먼 국가의 RTT가 시간대와 무관하게 늘 높고 그 값이 거리로 계산한 최소 지연(1,000km당 왕복 10ms)과 공개 지연 통계에 가까움
이러면 아님: 거리로 설명되는 값보다 훨씬 높으면 “우회 라우팅”, 저녁에만 오르면 “피크 시간 피어링 구간 혼잡”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: Riot Games 2015: 멀리 돌아가던 League of Legends 트래픽과 Riot Direct

출처 4건

ITU-T G.114: One-way transmission time ITU
광케이블 전파 지연 계획값 5µs/km(초속 약 20만 km, 1,000km 왕복 10ms)
Azure network round-trip latency statistics Microsoft Azure
서울(Korea Central) 기준 실측 왕복 중앙값: 도쿄 30ms, 싱가포르 68ms, 미국 서부 124~136ms, 유럽 234~244ms
AAE-1 & SMW5 cable cuts impact millions of users across multiple countries Cloudflare
유럽–아시아 사이 트래픽은 대개 이집트(수에즈)를 지나는 해저 케이블로 감
Probe Selection (RIPE Atlas REST API) RIPE NCC
RIPE Atlas 측정의 프로브를 국가·지역·ASN·주소 대역으로 골라 ping·traceroute를 실행

위성 인터넷 (저궤도·정지궤도) Satellite internet (LEO, GEO)

ID isp-satellite · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발

위성 인터넷은 전파가 우주를 오가야 해서, 정지궤도 위성은 왕복만 0.5초가 넘고 Starlink 같은 저궤도 위성은 평소엔 빠르지만 경로를 다시 배정하는 순간 지연이 흔들리고 잠깐 끊기기도 합니다.

왜 집·배·비행기에서 정지궤도 위성이나 저궤도 위성 인터넷, 위성을 쓰는 기내 와이파이로 접속 → 그러면 정지궤도는 고도가 약 36,000km라 오가는 거리 자체가 길고 저궤도는 단말·위성·지상국 경로를 짧은 주기로 다시 배정하며 그 순간 지연·손실이 잠깐 생김 → 화면에서는 정지궤도는 모든 행동에 큰 입력 지연, 저궤도는 평소 괜찮다가 일정한 간격으로 뚝뚝 끊김·순간이동

증상: 입력 지연, 뚝뚝 끊김, 순간이동
요인: 지연, 지터, 손실
누가 겪나: 나만, 같은 집, 특정 지역·통신사
언제: 항상, 일정한 주기로
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 지터에 맞춰 보간 버퍼 길이를 자동으로 늘리기, 짧은 손실을 견디게 입력 중복 전송, 연결 품질 표시. 서버: 판정 구간·지연 보상 한도를 정할 때 위성 회선의 지연을 고려, 1초 안팎의 공백으로 바로 내보내지 않는 타임아웃.
외부 할 일: 유저에게 위성 인터넷은 지연이 크거나 주기적으로 튈 수 있음을 안내, 경쟁 콘텐츠는 가능하면 지상 유선망을 쓰도록 안내.
수치 감각: 정지궤도(고도 36,000km)는 전파가 우주를 지나는 데만 한 방향 260ms라 왕복 520ms가 넘습니다(ITU-T G.114). 저궤도 Starlink는 공식 자료(15초 평균값) 기준 미국 피크 시간 중앙값 33ms, 가장 나쁜 1%(p99)도 65ms 미만입니다(2024년). 측정 연구에서는 15초마다 경로를 다시 배정하는 순간 지연이 바뀌고 1초 미만의 짧은 끊김이 생겼습니다. 2018년 기내 인터넷 측정에서 위성 방식의 왕복 지연은 평균 750ms였습니다.
그래프에서는: 일부만 높음 · RTT·지터(위성 인터넷 사업자 ASN별)
확인할 곳: 접속 IP의 ASN이 위성 인터넷 사업자인지 보고 그 사업자 유저의 RTT 분포와 시계열을 따로 그림. 그 ASN의 RIPE Atlas 프로브에서 서버까지 ping을 몇 분 이어서 재거나, 유저에게 ping을 켜 두고 튀는 간격을 재게 함
이러면 맞음: 정지궤도 사업자는 RTT가 늘 500ms를 넘고 저궤도 사업자는 평소 수십 ms이다가 약 15초 간격으로 RTT가 바뀌거나 짧게 끊김
이러면 아님: 위성 사업자가 아닌데 RTT가 늘 높으면 “전파 지연 (물리적 거리)”이나 “우회 라우팅”, 불규칙하게 튀면 와이파이·모바일 신호 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 저궤도 위성은 위성까지의 거리가 짧아(Starlink 한 구간 1.8~3.6ms) 평소 지연이 지상 회선과 비슷할 수 있습니다. 대신 지상국에서 인터넷으로 나가는 지점(PoP)이 게임 서버와 멀면 그만큼 경로가 길어지고, 위성 사이 레이저 링크로 돌아가면 지연이 더 붙습니다. 측정 연구는 15초 주기의 흔들림이 위성 간 전환과는 무관하게 전 세계에서 같은 시각에 일어나는 경로 재배정 때문이라고 봅니다. 기내 와이파이는 방식(위성, 지상 기지국)에 따라 지연이 크게 다르고 정지궤도 위성을 쓰는 방식이면 위와 같은 긴 왕복이 생깁니다.

출처 5건

ITU-T G.114: One-way transmission time ITU
위성 구간의 한 방향 전파 지연 계획값: 고도 400km 12ms, 14,000km 110ms, 36,000km(정지궤도) 260ms
Improving Starlink’s Latency Starlink
미국 피크 시간 중앙값 48.5ms→33ms, 가장 느린 1%(p99) 150ms 초과→65ms 미만(2024년), 위성 한 구간 전파 1.8~3.6ms, 레이저 링크로 돌면 지연이 더해지고 지상국에서 인터넷 접속 지점(PoP)까지의 거리도 지연 요인
A Multifaceted Look at Starlink Performance (WWW 2024) ACM
Starlink는 15초마다 전 세계에서 같은 시각에 경로를 다시 배정하며 그 경계에서 지연·처리량이 흔들리고 1초 미만의 짧은 끊김이 생김(위성 간 전환 때문은 아님), 단말↔위성↔지상국 구간 지연 약 40ms
Mile High WiFi: A First Look at In-Flight Internet Connectivity (WWW 2018) ACM
기내 인터넷 45시간 측정: 왕복 지연 평균 지상 기지국 방식 200ms, 위성 방식 750ms, 위성 방식의 손실률 중앙값 7%
Probe Selection (RIPE Atlas REST API) RIPE NCC
RIPE Atlas 측정의 프로브를 국가·지역·ASN·주소 대역으로 골라 ping·traceroute를 실행

우회 라우팅 Suboptimal routing

ID isp-routing · 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부

통신사끼리의 연결 계약 때문에 가까운 서버도 먼 곳을 돌아서 갑니다.

왜 내 통신사와 서버 쪽 통신사가 직접 연결되어 있지 않음 → 그러면 다른 나라나 다른 도시를 경유해 거리와 장비가 늘어남 → 화면에서는 특정 통신사 사용자만 핑이 유독 높음

증상: 입력 지연
요인: 지연
누가 겪나: 특정 지역·통신사
언제: 항상
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부
인프라팀 할 일: 여러 통신사와 연결(멀티홈), 통신사별 핑을 모니터링해 우회하는 통신사 찾기, 통신사와 경로 조정 협의.
외부 할 일: 해당 통신사에 경로 조정 요청.
수치 감각: 같은 나라 안인데도 경로에 따라 핑이 두세 배 차이 나기도 합니다.
그래프에서는: 처음부터 늘 높음 · RTT(통신사·ASN별)
확인할 곳: 통신사(ASN)별 RTT를 비교하고 느린 통신사의 RIPE Atlas 프로브나 유저에게서 받은 traceroute·mtr로 경로가 어느 나라·도시를 거치는지 봄. IPv4와 IPv6를 따로 잼(mtr -4, -6)
이러면 맞음: 같은 지역인데 특정 통신사만 늘 높고 경로에 다른 나라나 먼 도시를 거치는 구간이 있음. 또는 한쪽 주소 체계(IPv4나 IPv6)만 높음
이러면 아님: 모든 통신사가 비슷하게 높으면 “전파 지연 (물리적 거리)”, 저녁에만 높으면 “피크 시간 피어링 구간 혼잡”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: IPv4와 IPv6는 경로가 따로 정해져서, 같은 서버라도 한쪽만 멀리 돌아가 느릴 수 있습니다(2016년 APNIC 측정: 한 통신사 안에서 IPv6가 IPv4보다 15·25·75ms 느린 사용자 집단이 따로 나타남). IPv6와 IPv4 중 먼저 연결되는 쪽을 쓰는 Happy Eyeballs(RFC 8305) 방식의 앱은 IPv6를 먼저 시도하고, IPv6가 권장값 250ms 안에 연결되면 IPv4는 시도하지 않습니다. 그래서 IPv6 쪽이 조금 느려도 그 경로로 붙기 쉽습니다. 특정 통신사에서만 핑이 높다면 IPv4와 IPv6를 나눠 재 봅니다.
실제 사례: Riot Games 2015: 멀리 돌아가던 League of Legends 트래픽과 Riot Direct

출처 6건

Quantifying the Causes of Path Inflation (SIGCOMM 2003) ACM
65개 ISP 분석: ISP 사이 피어링 정책과 도메인 간 라우팅이 경로를 크게 늘림
The Internet at the Speed of Light (HotNets 2014) ACM
실제 라우터 경로는 광케이블 직선 대비 중앙값 약 1.5배, 가까운 두 지점 사이 패킷이 지구 반대편을 돌아가는 사례(헤어피닝)도 있음
Probe Selection (RIPE Atlas REST API) RIPE NCC
RIPE Atlas 측정의 프로브를 국가·지역·ASN·주소 대역으로 골라 ping·traceroute를 실행
mtr(8) manual page source mtr
-4·-6으로 IPv4·IPv6만 써서 경로를 잼
RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency IETF
주소나 주소 체계(IPv4·IPv6)는 망에 따라 막히거나 고장 나거나 느릴 수 있음, IPv6를 먼저 시도하고 다음 연결 시도까지 권장 250ms 기다림
IPv6 Performance – Revisited APNIC
같은 이중 스택 사용자의 IPv6·IPv4 왕복 시간 비교: 접속망에 따라 IPv6 패킷을 전혀 다르게 처리하기도 해, 한 통신사 안에서 IPv6가 15·25·75ms 느린 무리가 나타남

피크 시간 피어링 구간 혼잡 Peak-hour congestion at peering

ID isp-peak · 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부

저녁 9~11시 무렵에는 영상 트래픽이 폭증해 통신사 간 연결 구간(피어링)이 붐비기 쉽습니다.

왜 저녁 시간 스트리밍·다운로드가 몰림 → 그러면 피어링 구간에 대기열과 손실 발생 → 화면에서는 저녁에만 특정 통신사 사용자가 뚝뚝 끊김·순간이동

증상: 뚝뚝 끊김, 순간이동, 고무줄
요인: 지터, 손실, 지연
누가 겪나: 특정 지역·통신사
언제: 저녁 피크 시간
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부
인프라팀 할 일: 해당 통신사와 직접 연결 늘리기, 혼잡 경로 우회, 통신사별 저녁 시간 손실·핑 모니터링.
외부 할 일: 해당 통신사에 피어링 구간 증설 요청.
그래프에서는: 특정 시간대에만 높음 · RTT·손실(통신사별)
확인할 곳: 통신사(ASN)별 RTT·손실을 시간대별로 그리고, 그 통신사의 RIPE Atlas 프로브나 유저에게서 저녁과 낮에 각각 mtr을 받아 손실이 시작되는 구간을 봄
이러면 맞음: 특정 통신사만 매일 저녁 9~11시 무렵 RTT·손실이 오르고 mtr에서 통신사 간 연결 구간부터 목적지까지 손실·지연이 이어짐
이러면 아님: 모든 통신사가 같이 오르면 우리 회선·서버 쪽. 같은 집만 저녁에 나쁘면 “와이파이 채널 혼잡”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 2건

Inferring Persistent Interdomain Congestion (SIGCOMM 2018) ACM
통신사 간 연결 구간 일부에서 매일 피크 시간마다 지연이 오르는 반복 혼잡, 혼잡 시간대에 손실률도 상승
Probe Selection (RIPE Atlas REST API) RIPE NCC
RIPE Atlas 측정의 프로브를 국가·지역·ASN·주소 대역으로 골라 ping·traceroute를 실행

해저 케이블·국제 회선 장애 Submarine cable fault

ID isp-cable · 주 담당 외부·외부 · 함께 인프라팀·네트워크 인프라

해저 케이블이 끊기면 수리될 때까지 몇 주(길면 몇 달) 동안 먼 우회 경로로 돌아가고, 남은 회선은 붐빕니다.

왜 케이블 절단·장비 고장 → 그러면 트래픽이 먼 우회 경로와 남은 회선으로 몰림 → 화면에서는 해외 접속자 핑 급등과 손실이 며칠~몇 주 지속

증상: 입력 지연, 순간이동
요인: 지연, 손실
누가 겪나: 특정 지역·통신사
언제: 항상
담당: 주 담당 외부·외부 · 함께 인프라팀·네트워크 인프라
인프라팀 할 일: 다른 경로의 회선 확보, 장애 때 트래픽을 그 경로로 옮기기.
외부 할 일: 해외 접속자에게 원인과 복구 예상 시점 공지, 회선 사업자에 복구 일정 확인 요청.
그래프에서는: 어느 순간부터 계단처럼 올라감 · RTT(해외 국가별)
확인할 곳: 국가별 RTT·손실 그래프에서 오른 시각을 찾아 Cloudflare Radar의 인터넷 장애 요약과 해저 케이블 사업자 공지와 맞춰 보고, traceroute로 경로가 다른 대륙을 도는지 확인
이러면 맞음: 어느 순간부터 특정 해외 지역의 RTT가 한 단계 올라 며칠~몇 주 머물고, 같은 시기 케이블 장애 보고가 있음. 경로가 평소와 다른 먼 우회로로 바뀜
이러면 아님: 며칠 안에 원래대로 돌아오고 장애 보고가 없으면 “BGP 경로 변경·수렴”이나 통신사 구간
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

AAE-1 & SMW5 cable cuts impact millions of users across multiple countries Cloudflare
해저 케이블 수리는 수리선을 보내야 해 보통 며칠~몇 주(통가 사례 38일), 절단 때 유럽–아시아 구간 지연·손실 증가
Q2 2024 Internet disruption summary Cloudflare
2024년 2월 손상된 홍해 케이블은 7월에도 수리 중(분쟁 지역), 5월의 EASSy·Seacom 절단은 19일 만에 복구
Q1 2024 Internet disruption summary Cloudflare
서아프리카 케이블 절단(3월 14일)은 3~6주 뒤 복구, 그동안 다른 케이블로 트래픽을 옮김

BGP 경로 변경·수렴 Route change / BGP convergence

ID isp-bgp · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부

인터넷의 경로 정보가 바뀌어 다시 수렴하는 몇 초~몇십 초(드물게 몇 분) 동안 패킷이 유실됩니다.

왜 어느 통신사 구간의 경로 정보가 바뀜 → 그러면 몇 초~몇십 초 동안 패킷이 사라지거나 새 경로로 전환 → 화면에서는 갑자기 몇 초 멈춘 뒤 핑 수치가 달라짐(예: 40 → 70ms)

증상: 멈춤, 순간이동
요인: 손실, 지연
누가 겪나: 특정 지역·통신사
언제: 가끔 무작위로
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부
게임개발팀 할 일: 짧은 끊김을 견디는 타임아웃(몇 초 멈춘 연결을 바로 끊지 않기).
인프라팀 할 일: 경로 모니터링(우리 IP 대역의 경로·핑 변화 감시), 우리 회선 장애는 BFD로 1초 안에 감지해 전환(BGP 기본 홀드 타임은 90~180초), 먼 경로로 바뀐 채 돌아오지 않으면 다른 회선으로 트래픽 옮기기.
외부 할 일: 경로가 자주 바뀌는 통신사 구간은 해당 통신사에 원인 확인 요청.
그래프에서는: 어느 순간부터 계단처럼 올라감 · RTT, traceroute 경로
확인할 곳: RTT가 바뀐 시각 전후의 traceroute·mtr 경로를 비교하고 RIPEstat BGPlay로 우리 주소 대역(prefix)의 BGP 경로 변경 기록을 봄
이러면 맞음: 몇 초 멈춤과 함께 RTT가 다른 값으로 옮겨 가고 같은 시각 BGP 업데이트와 AS 경로 변경이 있음
이러면 아님: 경로 변경 기록이 없는데 저녁에만 오르면 “피크 시간 피어링 구간 혼잡”, 일부 연결만 나쁘면 “ECMP 경로 하나의 불량”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: Cloudflare 2020: Cloudflare 백본 설정 오류로 일부 도시의 트래픽 손실
Meta 2021: Facebook 백본 명령 하나로 DNS까지 사라진 장애
Cloudflare 2025: Cloudflare 공용 DNS 1.1.1.1 장애

출처 4건

RFC 4271: A Border Gateway Protocol 4 (BGP-4) IETF
BGP 홀드 타임 권장 기본값 90초(이 시간 동안 상대 메시지가 없으면 세션을 끊음)
BGP updates in 2024 APNIC
불안정해진 경로가 다시 안정되기까지 하루 평균 25~35초(IPv4), 40~50초(IPv6)
Delayed Internet Routing Convergence (SIGCOMM 2000) ACM
경로 장애 뒤 수렴에 수 분까지 걸리고 그동안 손실·지연이 늘어남(2000년 당시 측정)
BGPlay (RIPEstat Data API) RIPE NCC
주소 대역(prefix)의 시작 시점 BGP 경로와 그 기간에 관측된 BGP 업데이트, 경로에 있는 AS 정보를 보여 줌

ECMP 경로 하나의 불량 ECMP / link bundle member fault

ID isp-ecmp · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부

통신사와 데이터센터는 같은 목적지로 가는 경로를 여러 개 두고 연결마다 경로 하나를 정해 보냅니다. 경로 하나만 고장 나면 그 경로에 배정된 사람만 계속 렉을 겪습니다.

왜 여러 회선을 묶은 구간에서 한 회선이나 장비 하나가 불량이거나 붐빔 → 그러면 주소·포트 조합(해시)으로 경로가 정해져, 그 경로에 배정된 연결만 손실·지연 → 화면에서는 같은 지역·같은 통신사인데 일부만 꾸준히 순간이동. 재접속하면 멀쩡해지기도 함

증상: 순간이동, 고무줄, 뚝뚝 끊김
요인: 손실, 지터
누가 겪나: 나만, 특정 지역·통신사
언제: 항상
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부
게임개발팀 할 일: 연결별 손실·재전송 통계를 남겨 겪는 사람의 IP·포트와 시각을 뽑을 수 있게 하기(TCP는 TCP_INFO의 재전송 수, UDP는 빠진 패킷 순번으로 계산).
인프라팀 할 일: 겪는 사람의 IP·포트와 시각을 모아 통신사·데이터센터에 전달, 경로별 손실 모니터링, 경로 측정은 게임과 같은 프로토콜·포트로(mtr --tcp·--udp와 --port), 우리 장비의 경로면 불량 회선·장비를 묶음에서 빼기.
외부 할 일: 통신사에 불량 경로 확인·교체 요청, 유저에게 재접속으로 임시로 피하도록 안내(재접속으로 포트가 바뀌는 경우).
수치 감각: 경로가 4개면 사용자의 약 4분의 1만 겪습니다. 핑 측정은 게임과 다른 경로로 가서 멀쩡하게 나오기도 합니다.
그래프에서는: 일부만 높음 · 연결별 손실·재전송(IP·포트별)
확인할 곳: 연결별 손실·재전송을 출발 IP·포트로 나눠 보고 mtr을 UDP(-u)로 게임 포트(-P)에 보내며 출발 포트(-L)를 정해 재고, 출발 포트를 바꿔 여러 번 되풀이함. -L 없이 -P만 주면 요청마다 출발 포트가 바뀌어 여러 경로가 섞임
이러면 맞음: 같은 지역·통신사 안에서 특정 출발 포트(또는 주소) 조합만 꾸준히 손실이 나고, 재접속해 포트가 바뀌면 멀쩡해짐
이러면 아님: 포트를 바꿔도 모두 나쁘면 한 구간 전체의 혼잡·장애
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 한 연결의 패킷 순서가 뒤섞이지 않게, 장비는 주소와 포트(장비 설정에 따라 주소만)로 계산한 값에 따라 연결마다 경로를 고정합니다(ECMP, LAG). 주소만 쓰는 곳에서는 재접속해도 같은 경로라 나아지지 않습니다. “핑은 멀쩡한데 게임만 렉”, “재접속하니 나아짐” 같은 제보가 함께 들어오면 이 원인을 의심합니다.

출처 3건

RFC 7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks IETF
LAG·ECMP는 헤더 필드의 해시로 흐름마다 링크 하나를 정해 패킷 순서를 지킴(흐름→링크 다대일 대응)
RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
흐름 구분 기준은 구현마다 다름(목적지 주소만, 주소 쌍, 포트까지), 다중 경로에서는 ping·traceroute 결과를 믿기 어려움
mtr(8) manual page source mtr
-u(UDP), -P(목적지 포트), -L(UDP 출발 포트) 옵션, -P만 주면 출발 포트에 요청 순번을 넣어 요청마다 바뀜

통신사 속도 제한·트래픽 관리 Traffic shaping, data caps

ID isp-shaping · 주 담당 외부·외부 · 함께 게임개발팀·서버 개발, 인프라팀·네트워크 인프라

데이터 사용량을 넘기거나 특정 트래픽을 관리하는 요금제에서는 패킷이 늦춰지거나 버려집니다.

왜 요금제 데이터 소진 후 속도 제한, 또는 특정 트래픽 제한 → 그러면 패킷이 대기하거나 버려짐 → 화면에서는 일정 사용량 이후 렉, 특히 모바일

증상: 입력 지연, 순간이동
요인: 지연, 손실
누가 겪나: 나만, 특정 지역·통신사
언제: 항상, 저녁 피크 시간
담당: 주 담당 외부·외부 · 함께 게임개발팀·서버 개발, 인프라팀·네트워크 인프라
게임개발팀 할 일: 게임 트래픽 줄이기(압축, 필요한 것만 전송).
인프라팀 할 일: 특정 통신사에서만 게임 트래픽이 늦춰지거나 버려지면 자료를 모아 통신사에 에스컬레이션.
외부 할 일: 유저에게 요금제 데이터 소진·속도 제한 여부와 같은 폰의 다른 앱 사용 확인 안내, 통신사에 게임 트래픽 제한 여부 확인 요청.
수치 감각: 국내 모바일 요금제는 데이터를 다 쓰면 보통 1~5Mbps, 싼 요금제는 수백 kbps로 제한됩니다. 게임은 가벼워도 같은 폰의 다른 앱이 쓰면 속도 제한 장비 앞에 대기열이 생깁니다.
그래프에서는: 한도에 닿아 평평해짐 · 처리량, RTT
확인할 곳: 유저에게 통신사 앱에서 남은 데이터와 속도 제한 여부를 확인하게 하고 속도 측정으로 최대 속도를 봄. 서버 쪽은 통신사별 손실·RTT를 비교
이러면 맞음: 처리량이 1~5Mbps나 수백 kbps 같은 한 값에서 더 오르지 않고 그때부터 같은 폰의 다른 앱이 쓰면 RTT·손실이 늘어남. 데이터를 충전하거나 와이파이로 바꾸면 사라짐
이러면 아님: 속도 제한이 없는데 특정 통신사만 나쁘면 “피크 시간 피어링 구간 혼잡”이나 “우회 라우팅”
확인 수단: 유저 쪽 환경에서 확인

출처 2건

SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시 SK텔레콤
5G 요금제의 기본 데이터 소진 뒤 속도 제어 예: 최대 400kbps, 1Mbps, 3Mbps
SKT, 요금제 개편 SK텔레콤
기본 제공 데이터를 다 쓴 뒤에도 최대 400kbps로 계속 이용(전 국민 안심 데이터)

국가·통신사 단위 UDP 제한·패킷 검사 UDP blocking, throttling and inspection by networks

ID isp-udp-block · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발, 인프라팀·네트워크 인프라

일부 망은 특정 UDP 주소·포트를 막거나 UDP 속도를 제한하고 패킷 검사 장비가 알아보지 못하는 프로토콜을 걸러 냅니다. UDP로 통신하는 게임은 그 망에서 접속이 안 되거나 자주 끊깁니다.

왜 UDP 속도를 제한하는 일부 통신사망이나, 국가·통신사 단위의 트래픽 검사(검열) 장비가 있는 망에서 접속 → 그러면 특정 UDP 주소·포트를 막거나, 붐비는 시간에 UDP 속도를 제한하거나, 허용 목록에 없는 포트·프로토콜을 걸러 내거나, 처음 몇 패킷만 통과시킨 뒤 막음 → 화면에서는 특정 국가·통신사 유저만 접속 불가·무한 로딩, 접속했다가 곧 접속 끊김, 붐비는 시간에 손실로 순간이동

증상: 접속 불가·무한 로딩, 접속 끊김, 순간이동
요인: 손실
누가 겪나: 특정 지역·통신사
언제: 접속·점검 직후, 항상, 저녁 피크 시간
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발, 인프라팀·네트워크 인프라
게임개발팀 할 일: 클라이언트: UDP가 몇 초 안에 연결되지 않으면 TCP·TLS 443 대체 경로로 자동 전환, 처음엔 붙었다가 곧 끊기는 경우도 감지해 대체 경로로 다시 시도, 어느 경로로 붙었는지 로그에 남기기. 서버: 같은 게임 프로토콜을 TCP 443(TLS)으로도 받기, 대체 경로는 지연이 늘 수 있으니 타임아웃 조정.
인프라팀 할 일: 해외 국가를 추가하기 전에 현지 통신사망에서 UDP 도달 여부와 피크 시간 손실을 측정, TCP 443 대체 경로를 받는 릴레이·게이트웨이를 현지 가까이에 두기, 국가·ASN별 UDP·TCP 접속 성공률 감시, UDP 속도 제한이 확인된 통신사는 자료를 모아 에스컬레이션.
외부 할 일: 해당 통신사·기관에 UDP 제한 기준과 완화를 문의, 유저에게 다른 네트워크에서 접속해 비교해 보도록 안내.
수치 감각: IETF 문서가 인용한 측정으로는 네트워크의 3~5%가 UDP를 모두 막습니다. 구글이 2016년 QUIC(UDP 기반) 사용 결과를 보니 클라이언트의 4.4%는 UDP·QUIC이 막혔거나 경로 MTU가 작아 쓰지 못했습니다. 대부분 기업 방화벽 뒤였고 통신사 전체가 막은 경우는 보지 못했습니다. 0.3%는 피크 시간에 손실이 크게 늘어 UDP 속도를 제한하는 것으로 보이는 망에 있었고, 통신사에 요청해 2015년 1%에서 줄였습니다.
그래프에서는: 일부만 높음 · UDP 접속 성공률(국가·ASN별)
확인할 곳: 국가·ASN별로 UDP 접속 성공률과 TCP 443 대체 경로 성공률을 나눠 봄. 해당 통신사망의 클라우드 VM이나 유저 PC에서 게임 UDP 포트와 TCP 443으로 각각 접속 시험을 하고, mtr -u -P(게임 포트)와 mtr -T -P 443으로 어느 구간부터 응답이 사라지는지 비교
이러면 맞음: 특정 국가·ASN에서만 UDP 첫 응답이 없거나 몇 초 만에 끊기고 같은 곳에서 TCP 443은 정상. 속도 제한이면 피크 시간에만 UDP 손실이 뚜렷이 늘고 TCP는 덜 영향받음
이러면 아님: TCP도 함께 실패하면 경로 장애·IP 차단·“DNS 장애·지연” 쪽. 모든 국가에서 같으면 우리 서버·방화벽 설정, UDP·TCP 가리지 않고 순간 전송량이 많을 때만 손실이 나면 “폴리서의 초과분 폐기”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 패킷 검사 장비는 주소·포트·프로토콜로 UDP 흐름을 골라 막거나, 허용한 프로토콜 외에는 모두 막는 방식(허용 목록)을 쓰기도 합니다(IRTF 조사 문서). 장비가 패킷의 일부 필드만 보고 판단하면 프로토콜을 조금 바꾼 것만으로 막히기도 합니다. QUIC 초기에 한 방화벽은 헤더의 1비트가 바뀐 뒤 처음 몇 패킷은 통과시키고 그 뒤 패킷을 막아, 클라이언트가 TCP로 바꿔 붙는 로직이 작동하지 못했습니다. 해외 국가를 추가할 때 “국내는 괜찮은데 그 나라 일부 통신사만 접속이 안 된다”는 제보로 드러날 수 있습니다. 카페·회사처럼 한 장소의 망에서만 막히면 “공용 와이파이·회사망 제한” 항목을 보세요.

출처 4건

RFC 9308: Applicability of the QUIC Transport Protocol IETF
측정 연구상 네트워크의 3~5%가 UDP를 모두 막아 UDP 기반 앱은 연결 실패를 받아들이거나 TCP(TLS) 대체 경로를 둬야 함, 등록 서비스와 연결되지 않는 포트는 방화벽이 막을 수 있음
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017) ACM
2016년: 클라이언트 4.4%가 QUIC(UDP)을 못 씀(UDP·QUIC 차단 또는 작은 경로 MTU, 주로 기업 방화벽 뒤, 통신사 전체 차단은 관측되지 않음), 0.3%는 UDP 속도 제한으로 보이는 망(피크 시간 손실 증가, 통신사에 요청해 2015년 1%에서 감소), 헤더 1비트 변경 뒤 처음 몇 패킷만 통과시키고 이후를 막은 방화벽이 TCP 대체 로직을 무력화한 사례
RFC 9505: A Survey of Worldwide Censorship Techniques IRTF
망의 검사 장비가 주소·포트·프로토콜로 TCP·UDP 흐름을 골라 막을 수 있고(QUIC에서 UDP 엔드포인트 차단이 관측됨), 허용한 프로토콜 외에는 막는 방식은 과잉 차단을 부르며 특정 트래픽의 속도를 제한하는 방식도 쓰임
mtr(8) manual page source mtr
-u로 UDP, -T로 TCP SYN을 보내고 -P로 목적지 포트를 정해 게임과 같은 프로토콜·포트로 경로를 잼

회선 품질 불량 Faulty last-mile line / modem

ID isp-line · 주 담당 외부·외부

단자 접촉 불량이나 낡은 선, 모뎀 이상은 꾸준한 손실과 주기적인 회선 끊김을 만듭니다.

왜 케이블 손상, 접촉 불량, 모뎀·광단말 이상 → 그러면 비트 오류로 패킷 폐기, 가끔 회선이 다시 연결되느라 수 초~1분쯤 단절되기도 함 → 화면에서는 꾸준한 소량 손실, 가끔 수 초 멈춤이나 접속 끊김

증상: 순간이동, 멈춤, 접속 끊김
요인: 손실
누가 겪나: 같은 집
언제: 가끔 무작위로
담당: 주 담당 외부·외부
외부 할 일: 유저에게 다른 게임·영상 통화도 끊기는지 확인하고 그렇다면 통신사에 점검을 요청하도록 안내.
그래프에서는: 가끔 무작위로 튐 · 손실률, 회선 재연결 기록
확인할 곳: pathping(또는 mtr)으로 통신사 첫 구간까지의 손실을 몇 분 재고, 공유기 화면의 인터넷(WAN) 연결 기록에서 재연결 시각을 봄
이러면 맞음: 회선이 한가할 때도 통신사 첫 구간부터 꾸준히 손실이 나고 공유기 기록의 회선 재연결 시각이 멈춤·끊김 시각과 겹침. 다른 게임·영상 통화도 같이 끊김
이러면 아님: 손실이 공유기까지의 무선 구간에서 시작되면 “와이파이 간섭·신호 약화”, 통신사 먼 구간에서 시작되면 통신사 경로
확인 수단: 유저 쪽 환경에서 확인

출처 3건

RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
프레임 검사(FCS)를 통과하지 못한 프레임은 FCS 오류(dot3StatsFCSErrors)로 세고 입력 오류(ifInErrors)에 합산
Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017) ACM
패킷 깨짐의 주원인은 불량 광모듈·손상된 광섬유·더러운 커넥터·잘못된 설치, 깨짐 손실률은 사용량과 무관하게 꾸준함
pathping Microsoft
구간마다 일정 시간 핑을 보내 라우터·링크별 손실률을 계산해 어느 구간에서 손실이 생기는지 보여 줌

DNS 장애·지연 DNS failure / slowness

ID isp-dns · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

서버 이름을 주소로 바꿔 주는 DNS가 느리거나 실패하면 로그인·패치 서버를 찾지 못합니다.

왜 통신사 DNS 장애 또는 설정 오류 → 그러면 로그인·패치 서버 주소를 못 찾음 → 화면에서는 접속 버튼 뒤 한참 대기 또는 접속 불가. 이미 접속한 사람은 멀쩡

증상: 접속 불가·무한 로딩
요인: 지연, 손실
누가 겪나: 특정 지역·통신사, 나만
언제: 접속·점검 직후
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 주소 캐시(마지막으로 접속에 성공한 서버 주소 기억), 여러 DNS 준비(한 곳이 실패하면 다른 DNS로 다시 조회).
외부 할 일: 유저에게 DNS를 공용 DNS 등 다른 곳으로 바꿔 보도록 안내.
그래프에서는: 일부만 높음 · 로그인 실패 수(통신사별), DNS 조회 시간
확인할 곳: Resolve-DnsName -Server(또는 nslookup)로 로그인 서버 이름을 통신사 DNS와 공용 DNS에 각각 물어 응답 시간과 결과를 비교
이러면 맞음: 통신사 DNS에서만 응답이 없거나 오래 걸리고 공용 DNS로 바꾸면 바로 접속됨. 이미 접속한 유저는 멀쩡함
이러면 아님: 어느 DNS로도 주소는 바로 나오는데 접속이 안 되면 경로·방화벽·서버 쪽
확인 수단: 유저 쪽 환경에서 확인
실제 사례: Meta 2021: Facebook 백본 명령 하나로 DNS까지 사라진 장애
Cloudflare 2025: Cloudflare 공용 DNS 1.1.1.1 장애
AWS 2025: AWS us-east-1 DynamoDB DNS 장애와 긴 복구

출처 4건

Cloudflare 1.1.1.1 Incident on July 14, 2025 Cloudflare
공용 DNS 리졸버가 62분 동안 멈추자, 이름을 못 찾게 된 사용자에게는 사실상 모든 인터넷 서비스가 불가
RFC 8767: Serving Stale Data to Improve DNS Resiliency IETF
권한 서버에 닿지 못할 때 만료된 캐시 기록을 계속 써서 장애를 버티는 방식(serve-stale)
Resolve-DnsName Microsoft
-Server로 물어볼 DNS 서버를 정해 이름을 조회
nslookup Microsoft
DNS 서버에 이름을 직접 조회하는 명령

DDoS로 인한 공유 회선 포화 DDoS saturating shared links

ID isp-ddos-path · 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부

게임사나 같은 망의 다른 곳을 향한 대량 공격이 공유 회선을 가득 채웁니다.

왜 대량의 공격 트래픽이 발생 → 그러면 같은 회선을 쓰는 정상 트래픽까지 밀리고 버려짐 → 화면에서는 많은 사람이 동시에 순간이동·접속 끊김·접속 불가

증상: 순간이동, 접속 끊김, 접속 불가·무한 로딩
요인: 손실, 지연
누가 겪나: 서버 전체, 특정 지역·통신사
언제: 가끔 무작위로, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부
인프라팀 할 일: DDoS 방어 서비스, 공격 때 트래픽 우회, 서버 주소 숨기기(방어 장비 뒤에 두고 실제 주소 노출 막기).
외부 할 일: 같은 망의 다른 곳을 향한 공격이면 통신사에 상위 구간 차단 요청.
그래프에서는: 한도에 닿아 평평해짐 · 회선 수신량(bps·pps), 인터페이스 드롭
확인할 곳: 우리 회선·장비의 인터페이스 수신량과 버린 패킷 수, DDoS 방어 서비스의 공격 탐지 기록을 끊김이 몰린 시각과 함께 봄
이러면 맞음: 회선 수신량이 회선 용량에 붙어 평평해지고 드롭이 늘며 같은 시각 여러 지역·통신사 유저가 한꺼번에 순간이동·접속 끊김
이러면 아님: 회선에 여유가 있는데 일부 통신사만 나쁘면 통신사 구간의 혼잡·경로 문제
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Infrastructure layer attacks AWS
UDP 반사·SYN 플러드 같은 대량 공격은 네트워크 용량을 넘치게 하거나 방화벽·로드밸런서 자원을 묶어 둠
Obfuscating AWS resources (BP1, BP4, BP5) AWS
원본 서버 앞에 CloudFront·로드밸런서 같은 엣지 서비스를 두어 직접 노출을 줄이기
RFC 7999: BLACKHOLE Community IETF
특정 주소로 가는 트래픽을 인접 통신사가 버려 달라고 BGP로 알리는 BLACKHOLE 커뮤니티

통신사 공유 IP (CGNAT) Carrier-grade NAT

ID isp-cgnat · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발, 인프라팀·네트워크 인프라

모바일망과 일부 통신사는 여러 가입자가 IP 하나를 나눠 쓰며 유휴 연결의 매핑을 짧은 시간 안에 지웁니다.

왜 통신사 장비가 수많은 가입자의 세션 테이블을 관리 → 그러면 세션 테이블 한도, 짧은 유휴 타임아웃 → 화면에서는 가만히 있다 접속 끊김, 같은 IP를 쓰는 사람들이 한꺼번에 차단되는 오탐

증상: 접속 끊김, 접속 불가·무한 로딩
요인: 손실
누가 겪나: 특정 지역·통신사
언제: 가만히 있다가
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발, 인프라팀·네트워크 인프라
게임개발팀 할 일: 클라이언트: 가장 짧은 유휴 타임아웃(모바일망은 30초 안팎인 경우도 있음)의 절반 이하 간격으로 하트비트 보내기(통신사 CGNAT 매핑은 안에서 나가는 패킷으로만 확실히 갱신되므로 클라이언트가 보냄), 끊기면 자동 재접속. 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리, 매핑이 바뀌어 주소·포트가 달라져도 세션 토큰으로 같은 플레이어로 이어 받기, IP 하나를 여러 사람이 나눠 쓸 수 있으니 IP 기준 차단 정책은 신중히(계정·기기 기준과 함께 판단).
인프라팀 할 일: 방화벽·DDoS 방어 장비의 IP당 연결 수·초당 새 연결 수 제한을 통신사 공유 IP에 맞게 조정(모바일 통신사 대역은 기준을 높이거나 예외로).
수치 감각: 모바일망 UDP 유휴 타임아웃은 30초 안팎인 경우도 있습니다.
그래프에서는: 연결이 한꺼번에 끊김 · 끊김 수(하트비트 타임아웃), 끊기기 전 유휴 시간(통신사별)
확인할 곳: 접속 로그에서 한 IP에 동시에 붙은 계정 수와 통신사(ASN)를 보고 유휴 뒤 끊긴 연결의 유휴 시간을 통신사별로 모음. 유저 쪽은 공유기 화면의 인터넷(WAN) 주소를 확인
이러면 맞음: 모바일 통신사 대역에서 한 IP에 여러 계정이 붙고 끊기기 전 유휴 시간이 30~60초 안팎으로 짧게 몰림. 공유기의 WAN 주소가 100.64.0.0/10(통신사 NAT용 공유 주소)이거나 서버가 보는 주소와 다름
이러면 아님: 통신사와 상관없이 집 공유기 사용자에게 몰리면 “NAT 매핑 만료”
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 4건

A Multi-perspective Analysis of Carrier-Grade NAT Deployment (IMC 2016) ACM
측정된 NAT의 UDP 매핑 유지 시간 10~200초, 74%가 1분 이하, CGN 중앙값은 모바일망 65초·유선망 35초
RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) IETF
CGN은 가입자당 외부 포트 수 제한과 새 매핑 생성 속도 제한을 지원해야 함
RFC 6269: Issues with IP Address Sharing IETF
주소를 여럿이 나눠 쓰면 IP 기준 차단(penalty box)이 같은 주소의 다른 가입자까지 막음
RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space IETF
100.64.0.0/10은 통신사 NAT(CGN) 장비와 가입자 공유기 사이에 쓰는 공유 주소 대역

VPN·게임 가속기 경유 VPN / game accelerator detour

ID isp-vpn · 주 담당 외부·외부 · 함께 인프라팀·네트워크 인프라, 게임개발팀·서버 개발

VPN이나 게임 가속기를 켜면 패킷이 그 회사의 중계 서버를 거쳐 갑니다. 중계 서버가 멀거나 붐비면 오히려 느려집니다.

왜 VPN·가속기가 게임 패킷을 모두 중계 서버로 돌려 보냄 → 그러면 중계 서버까지의 거리와 혼잡이 더해지고 터널 헤더 때문에 MTU(한 번에 보낼 수 있는 패킷 크기)도 줄어듦 → 화면에서는 핑 상승과 손실, 같은 중계 주소를 쓰는 사람과 함께 차단되어 접속 불가

증상: 입력 지연, 순간이동, 접속 불가·무한 로딩
요인: 지연, 손실
누가 겪나: 나만
언제: 항상, 접속·점검 직후
담당: 주 담당 외부·외부 · 함께 인프라팀·네트워크 인프라, 게임개발팀·서버 개발
게임개발팀 할 일: UDP 패킷은 1,200바이트 이하로 유지(터널 헤더로 MTU가 줄어도 단편화되지 않게), IP 기준 차단은 VPN·가속기의 공용 중계 주소를 고려해 계정·기기 기준과 함께 판단.
인프라팀 할 일: 해외 이용자가 많으면 가까운 접속 거점을 직접 두기, “가속기를 켜니 좋아졌다”는 제보가 몰리는 통신사는 경로 점검.
외부 할 일: 유저에게 VPN·가속기를 끄고 비교해 보도록 안내.
수치 감각: 가까운 중계 서버면 수 ms, 다른 나라를 돌아가면 수십~100ms 넘게 더해집니다.
그래프에서는: 일부만 높음 · RTT(유저별), 접속 IP의 사업자
확인할 곳: 접속 IP의 ASN이 VPN·가속기·호스팅 사업자인지 보고 유저에게 VPN·가속기를 끄고 핑과 traceroute를 비교하게 함
이러면 맞음: VPN·가속기를 켰을 때만 RTT·손실이 늘거나 접속이 막히고 traceroute에 중계 서버를 거치는 구간이 보임
이러면 아님: 끄고 켜도 같으면 회선·통신사 구간. 켰을 때 더 좋아지면 원래 통신사 경로(“우회 라우팅”, “피크 시간 피어링 구간 혼잡”) 문제
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 반대로 통신사 경로가 나쁠 때는 가속기가 더 좋은 경로로 돌아가 핑이 줄기도 합니다. “가속기를 켜니 좋아졌다”는 제보는 우회 라우팅이나 저녁 혼잡 같은 통신사 경로 문제의 단서입니다.

출처 3건

RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling IETF
망 중간 터널의 캡슐화 헤더 때문에 보낼 수 있는 크기가 줄어 생기는 단편화·경로 MTU 문제
RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports IETF
UDP 같은 데이터그램 전송의 기본 안전 크기(BASE_PLPMTU)로 1,200바이트 권장
Azure network round-trip latency statistics Microsoft Azure
다른 나라 거점을 거칠 때 더해지는 왕복 지연 규모: 서울–도쿄 30ms, 서울–홍콩 39ms, 서울–싱가포르 68ms

L5 데이터센터 네트워크 장비

방화벽 세션 테이블 포화 Firewall session table exhaustion

ID dc-firewall · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발

방화벽은 통과시킨 모든 연결을 세션 테이블에 기록해 추적합니다. 테이블이 다 차면 새 연결을 받을 수 없습니다.

왜 접속 폭주나 공격으로 세션 수가 한도에 도달 → 그러면 새 연결을 기록할 빈 항목이 없어 거부 → 화면에서는 새로 들어오려는 사람은 접속 불가·무한 로딩, 일부 기존 연결도 접속 끊김

증상: 접속 불가·무한 로딩, 접속 끊김
요인: 손실
누가 겪나: 서버 전체
언제: 접속·점검 직후, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 로그인 대기열 시스템으로 한꺼번에 몰리는 접속 조절, 짧은 연결을 반복하지 않게 연결 재사용, 하트비트가 끊긴 연결은 먼저 정리(죽은 연결이 세션 테이블을 오래 차지하지 않게). 클라이언트: 가장 짧은 유휴 타임아웃의 절반 이하 간격으로 하트비트 보내기, 끊기면 자동 재접속하되 재시도 간격을 늘려 가며 무작위로 분산(한꺼번에 다시 몰리지 않게).
인프라팀 할 일: 세션 테이블 크기 늘리기, 짧게 끝난 연결 빨리 정리(종료된 세션의 타임아웃 단축), 유휴 세션 타임아웃을 줄일 때는 그 값을 게임팀에 알려 하트비트 간격 맞추기, 공격 차단, 세션 수 사용률 경보.
그래프에서는: 한도에 닿아 평평해짐 · 방화벽 세션 수, 새 연결 실패 수
확인할 곳: 방화벽 장비의 동시 세션 수를 세션 한도와 함께 그래프로 보고 장비 로그에서 세션을 만들지 못해 버린 기록을 찾음. 리눅스 방화벽이면 nf_conntrack_count를 nf_conntrack_max와 비교하고 dmesg의 “nf_conntrack: table full, dropping packet”을, AWS 인스턴스면 ethtool -S의 conntrack_allowance_exceeded를 봄
이러면 맞음: 세션 수가 한도에서 평평해진 시각부터 새 연결 실패가 늘고 세션 생성 실패 기록이나 폐기 카운터가 함께 늘어남
이러면 아님: 세션 수가 한도에 한참 못 미치는데 접속이 안 되면 “접속 대기열(backlog) 넘침”이나 로그인 서버 쪽. 유휴 연결만 끊기면 “클라우드 보안 그룹의 연결 추적 만료”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

Netfilter Conntrack Sysfs variables Linux kernel
연결 추적 테이블의 최대 항목 수(nf_conntrack_max), 종료 중인 연결의 유지 시간(TIME_WAIT·FIN_WAIT 기본 120초), 성립된 TCP 기본 5일, 현재 항목 수(nf_conntrack_count)
Amazon EC2 security group connection tracking AWS
인스턴스당 추적할 수 있는 연결 수를 넘으면 새 연결의 패킷을 버림, 유휴 연결이 추적 테이블을 고갈시킬 수 있음
Infrastructure layer attacks AWS
SYN 플러드 같은 공격은 서버·방화벽·로드밸런서의 자원을 묶어 둠
net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
연결 추적 테이블이 가득 차면 “nf_conntrack: table full, dropping packet”을 남기고 새 연결의 패킷을 버림
Monitor network performance for ENA settings on your EC2 instance AWS
conntrack_allowance_exceeded: 인스턴스의 연결 추적 한도를 넘어 버린 패킷 수, ethtool -S로 확인

DDoS 방어 경유·오탐 DDoS scrubbing latency, false positives

ID dc-ddos · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발

공격을 막으려고 트래픽을 스크러빙 센터로 돌리면 경로가 길어지고 정상 사용자를 공격으로 오인해 막기도 합니다.

왜 공격 감지 후(또는 상시) 들어오는 트래픽을 스크러빙 센터로 우회 → 그러면 경로가 길어지고 일부 정상 패킷을 공격으로 판정 → 화면에서는 전체 핑 상승, 특정 지역·통신사만 접속 불가

증상: 입력 지연, 접속 불가·무한 로딩, 순간이동
요인: 지연, 손실
누가 겪나: 서버 전체, 특정 지역·통신사
언제: 사람이 몰릴 때, 가끔 무작위로
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 게임 트래픽 패턴(포트, 패킷 크기, 초당 패킷 수)을 정리해 인프라팀에 공유, UDP 패킷은 1,200바이트 이하로 유지.
인프라팀 할 일: 게임 트래픽 패턴에 맞춘 방어 규칙, 지역별 스크러빙 거점, 터널 구간에서 TCP 패킷 크기 줄이기(MSS 조정), 지역·통신사별 접속 실패율로 오탐 확인.
수치 감각: 스크러빙 거점이 같은 나라에 있으면 수 ms, 다른 나라 거점을 거치면 30~100ms 넘게 더해집니다. 보통 들어오는 쪽만 돌아가고 서버의 응답은 곧바로 나갑니다. 걸러진 트래픽을 터널로 되돌려 받으면 한 번에 보낼 수 있는 크기(MTU)도 줄어 큰 패킷만 사라지기도 합니다.
그래프에서는: 어느 순간부터 계단처럼 올라감 · RTT(핑), 지역·통신사별 접속 실패율
확인할 곳: 방어 장비·서비스의 우회(스크러빙) 시작·종료 기록과 차단 로그를 RTT 그래프, 지역·통신사별 접속 실패율과 같은 시간축에 놓고 봄. 문제 지역에서 mtr·traceroute로 경로에 스크러빙 거점이 끼었는지 확인
이러면 맞음: 우회가 켜진 시각에 RTT가 한 단계 올라 머물다가 꺼지면 돌아옴. 또는 차단 로그에 정상 유저 주소가 있고 그 지역·통신사만 접속 실패율이 오름
이러면 아님: 우회·차단 기록이 없는 시각에 RTT가 오르면 “우회 라우팅”이나 “BGP 경로 변경·수렴”. 큰 패킷만 사라지면 “MTU 불일치 (큰 패킷만 사라짐)”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 2건

Maximum transmission unit and maximum segment size Cloudflare
들어오는 트래픽은 걸러진 뒤 GRE 터널(MTU 1,476)로 전달, 나가는 응답은 인터넷으로 바로(DSR), TCP MSS 1,436 이하로 제한 권장, 안 맞추면 큰 패킷이 버려지거나 단편화됨
Azure network round-trip latency statistics Microsoft Azure
거점 위치별 왕복 지연 규모: 서울–부산 지역 8ms, 서울–도쿄 30ms, 서울–싱가포르 68ms

로드밸런서 유휴 타임아웃 Load balancer idle timeout

ID dc-lb-idle · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발

로드밸런서는 유휴 연결을 일정 시간 뒤 지웁니다. 게임은 연결이 유지된다고 여기다가 접속이 끊깁니다.

왜 플레이어가 한동안 아무 패킷도 안 보냄(대화창, 자리 비움) → 그러면 로드밸런서가 유휴 연결을 정리(흔한 기본값 60~350초) → 화면에서는 다시 움직이는 순간 접속 끊김

증상: 접속 끊김
요인: 손실
누가 겪나: 나만, 서버 전체
언제: 가만히 있다가
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 가장 짧은 유휴 타임아웃의 절반 이하 간격으로 하트비트 보내기(ALB 60초 뒤라면 30초 이하), 끊기면 자동 재접속. 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리, 세션 토큰으로 이어 받기.
인프라팀 할 일: 경로에 있는 로드밸런서의 유휴 타임아웃 값을 확인해 게임팀에 공유하고 필요하면 늘리기.
수치 감각: AWS ALB는 60초, NLB는 TCP 350초·UDP 120초, Azure Load Balancer는 TCP 4분이 기본값입니다. ALB와 NLB의 TCP 값은 바꿀 수 있지만 NLB의 UDP 120초는 바꿀 수 없습니다. ALB는 시간이 되면 서버 쪽 연결도 닫지만 NLB는 조용히 지워 서버가 모르는 채로 남기 쉽습니다.
그래프에서는: 연결이 한꺼번에 끊김 · 끊김 수, 끊기기 전 유휴 시간
확인할 곳: 경로에 있는 로드밸런서의 유휴 타임아웃 설정값을 확인하고 끊긴 연결마다 마지막 패킷 뒤 끊기기까지 걸린 시간을 모아 봄. AWS NLB면 CloudWatch의 TCP_ELB_Reset_Count(로드밸런서가 보낸 RST 수)도 봄
이러면 맞음: 끊긴 연결의 유휴 시간이 설정값(ALB 60초, NLB TCP 350초 등) 바로 뒤에 몰리고 그 시간보다 오래 가만히 있다 움직이면 재현됨. NLB는 그 시각에 TCP_ELB_Reset_Count가 늘어남
이러면 아님: 유휴 시간과 상관없이 끊기면 이 원인이 아님. 로드밸런서 없이 바로 붙는 서버에서 350초 근처로 몰리면 “클라우드 보안 그룹의 연결 추적 만료”, 유저 집 공유기 쪽이면 “NAT 매핑 만료”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

Edit attributes for your Application Load Balancer AWS
ALB 유휴 타임아웃 기본 60초(1~4,000초), 클라이언트·대상 연결이 이 시간 동안 조용하면 로드밸런서가 연결을 닫음
Network Load Balancers AWS
NLB TCP 유휴 기본 350초(60~6,000초), 지나면 추적만 멈추고 그 뒤 데이터가 오면 RST, UDP 흐름 120초는 변경 불가
Configure load balancer TCP reset and idle timeout Microsoft Azure
Azure Load Balancer 유휴 타임아웃 기본 4분(4~100분), 넘으면 세션 유지 보장 없음, TCP 리셋은 선택 설정
CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count: 로드밸런서가 만들어 보낸 RST 패킷 수

클라우드 보안 그룹의 연결 추적 만료 Cloud security group connection tracking timeout

ID dc-cloud-conntrack · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발

클라우드 서버에 붙은 방화벽(보안 그룹)도 연결을 추적하고 유휴 연결의 추적 항목은 정해진 시간 뒤 만료됩니다. 로드밸런서 없이 바로 붙는 서버에서도 가만히 있던 플레이어의 접속이 끊길 수 있습니다.

왜 보안 그룹이 게임 연결을 추적하는 설정(특정 주소만 허용, 나가는 규칙 제한, NLB 경유 등) → 그러면 한동안 유휴 상태인 연결의 추적 항목이 만료되고 그 뒤 오는 패킷을 보안 그룹이 조용히 버림 → 화면에서는 자리 비움 뒤 다시 움직이면 반응이 없다가 접속 끊김. 서버 프로그램은 한참 모름

증상: 접속 끊김
요인: 손실
누가 겪나: 나만, 서버 전체
언제: 가만히 있다가
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·클라이언트 개발, 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 가장 짧은 유휴 타임아웃의 절반 이하 간격으로 하트비트 보내기(TCP 350초라면 175초 이하, UDP 스트림 180초라면 90초 이하), 끊기면 자동 재접속. 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리, 세션 토큰으로 이어 받기.
인프라팀 할 일: 인스턴스의 연결 추적 시간(TcpEstablishedTimeout) 확인·필요하면 늘리기(UDP는 180초가 최대라 못 늘림), 추적이 생기지 않는 보안 그룹 구성 검토(게임 포트는 모든 주소 허용, 나가는 규칙은 전체 허용. NLB를 거치는 연결은 그래도 추적됨), 새 세대 인스턴스로 옮길 때 유휴 시험.
수치 감각: AWS 기준 Nitro v6 인스턴스 유형은 유휴 TCP 연결의 추적 항목을 기본 350초 뒤 지웁니다(그 밖의 유형은 5일). UDP는 요청과 응답이 여러 번 오간 흐름(스트림) 180초, 한 방향으로만 갔거나 요청·응답이 한 번뿐인 흐름 30초가 기본입니다.
그래프에서는: 연결이 한꺼번에 끊김 · 끊김 수, 끊기기 전 유휴 시간
확인할 곳: 인스턴스의 연결 추적 시간 설정과 보안 그룹 규칙(추적이 생기는 구성인지)을 확인하고, 끊긴 연결의 유휴 시간을 모아 봄. 끊긴 직후 서버에서 ss -tnoi로 그 연결이 ESTABLISHED로 남아 재전송 타이머(timer:(on,…))가 돌고 backoff가 커지는지 봄
이러면 맞음: 끊긴 연결의 유휴 시간이 TCP 350초, UDP 스트림 180초, UDP 한 방향 30초 바로 뒤에 몰리고 서버 쪽 소켓은 끊김을 감지하지 못한 채 ESTABLISHED로 남음(서버가 보낼 데이터가 있으면 재전송만 반복)
이러면 아님: 보안 그룹이 추적하지 않는 구성(게임 포트를 모든 주소에 허용, 나가는 규칙 전체 허용, NLB를 거치지 않음)이면 이 원인이 아님. NLB를 거치면 “로드밸런서 유휴 타임아웃”과 값을 비교
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Amazon EC2 security group connection tracking AWS
TCP 유휴 추적 기본 350초(Nitro v6, 그 외 43만 2,000초=5일), UDP 한 방향 30초·스트림 180초(최대 180), 모든 주소 허용 규칙이면 추적 안 함, NLB 경유 연결은 항상 추적
Update the TCP idle timeout for your Network Load Balancer listener AWS
NLB 유휴 타임아웃이 대상 인스턴스의 연결 추적 시간보다 길면 인스턴스 쪽이 먼저 조용히 연결 상태를 버림
ss(8) — Linux manual page iproute2
-o의 timer:(on,…)은 재전송 타이머, -i의 backoff는 재전송 대기를 두 배씩 늘린 횟수

클라우드 NAT 게이트웨이 연결·포트 한도 Cloud NAT gateway connection / port limits

ID dc-nat-gateway · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발

사설 서브넷의 서버가 외부(플랫폼 인증·결제·외부 API)로 나가는 연결은 NAT 게이트웨이가 주소와 포트를 바꿔 내보냅니다. 같은 목적지로 가는 동시 연결이 게이트웨이의 포트 한도를 넘으면 새 연결이 실패합니다.

왜 서버들이 플랫폼 인증·결제처럼 같은 외부 주소로 짧은 연결을 많이 열거나 연결을 오래 열어 둠 → 그러면 NAT 게이트웨이가 그 목적지에 쓸 원본 포트를 더 할당하지 못해 새 연결이 실패함 → 화면에서는 게임 안은 멀쩡한데 로그인·결제·보상 지급처럼 외부를 부르는 기능만 실패하거나 늦어짐(접속 불가·무한 로딩, 씹힘·롤백)

증상: 접속 불가·무한 로딩, 씹힘·롤백
요인: 손실, 지연
누가 겪나: 특정 기능만, 서버 전체
언제: 접속·점검 직후, 저녁 피크 시간, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 외부 API는 연결을 재사용(HTTP keep-alive, 커넥션 풀)하고 요청마다 새 연결을 열지 않기, 풀에 남겨 둔 유휴 연결은 NAT 유휴 타임아웃(AWS 350초)보다 짧은 간격으로 keepalive를 보내거나 먼저 닫기, 실패하면 재시도 간격을 늘려 가며 무작위로 분산, 외부 호출별 실패율·지연 기록.
인프라팀 할 일: NAT 게이트웨이에 IP 주소 추가(AWS 공인 NAT 게이트웨이는 탄력적 IP를 기본 2개까지만 붙일 수 있어 그 이상은 할당량 상향 요청), 가용 영역·서브넷별로 게이트웨이 나누기, 포트 할당 실패 지표(AWS ErrorPortAllocation, Azure SNAT Connection Count의 Failed, Google Cloud dropped_sent_packets_count의 OUT_OF_RESOURCES) 경보, Google Cloud NAT는 VM당 최소 포트 수를 늘리거나 동적 포트 할당 사용.
수치 감각: AWS NAT 게이트웨이는 IP 주소 하나로 같은 목적지(IP·포트·프로토콜)에 동시 연결 5만 5천 개까지 열 수 있고, IP를 8개까지 붙여 늘립니다. 350초 동안 조용한 연결은 지우고 그 뒤 이 연결로 보내는 패킷에는 RST를 돌려줍니다. Azure NAT Gateway는 공인 IP 하나당 SNAT 포트 64,512개(IP 최대 16개)입니다. Google Cloud NAT는 NAT IP 하나당 64,512포트를 VM마다 나눠 줍니다. VM당 최소 포트 기본값이 64개(정적 할당)라서 기본 설정이면 VM 하나가 같은 목적지로 동시에 열 수 있는 연결이 대개 64개로 묶입니다.
그래프에서는: 한도에 닿아 평평해짐 · NAT 게이트웨이 동시 연결 수, 포트 할당 실패 수
확인할 곳: AWS는 CloudWatch의 NAT 게이트웨이 지표 ErrorPortAllocation·ActiveConnectionCount·PacketsDropCount(Azure는 SNAT Connection Count를 Failed 상태로 거른 값과 Dropped Packets, Google Cloud는 dropped_sent_packets_count의 reason OUT_OF_RESOURCES)를 게임 서버의 외부 호출 실패 시각과 나란히 봄
이러면 맞음: 외부 호출이 실패한 시각에 ErrorPortAllocation(Azure는 Failed 상태의 SNAT Connection Count, Google Cloud는 OUT_OF_RESOURCES 폐기)이 0보다 커지고, 실패가 인증·결제 서버처럼 연결이 많이 몰리는 한두 목적지로 가는 호출에 모임
이러면 아님: 포트 할당 실패가 0인데 게임 서버의 connect가 EADDRNOTAVAIL로 실패하고 TIME_WAIT가 임시 포트 범위에 가까우면 “서버 간 연결의 임시 포트 고갈”. 연결은 되는데 응답만 느리면 “외부 서비스 의존”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 서버 한 대의 임시 포트가 바닥나는 “서버 간 연결의 임시 포트 고갈”과 달리, 이 한도는 NAT 게이트웨이에 걸리고 게이트웨이 뒤의 서버들이 함께 씁니다(Google Cloud NAT는 VM마다 나눠 줌). 서버 쪽 TIME_WAIT와 임시 포트 범위는 여유가 있는데도 외부 호출만 실패하면 이쪽입니다. 닫힌 연결의 포트도 곧바로 같은 목적지에 다시 쓰이지 않아(Azure는 쿨다운, Google Cloud는 TIME_WAIT 동안 사용 불가) 짧은 연결을 반복할수록 한도에 빨리 닿습니다.

출처 7건

NAT gateway basics AWS
IPv4 주소 하나당 같은 목적지(목적지 IP·포트·프로토콜)로 동시 연결 5만 5천 개, IP를 8개까지 붙여 늘림(공인 NAT 게이트웨이의 탄력적 IP는 기본 2개, 할당량 상향 요청으로 늘림), 대역폭은 5Gbps에서 100Gbps까지, 처리량은 초당 100만에서 1,000만 패킷까지 자동으로 늘고 그 한도를 넘으면 패킷을 버림
NAT gateway metrics and dimensions AWS
ErrorPortAllocation: 원본 포트를 할당하지 못한 횟수(0보다 크면 동시 연결 과다), ActiveConnectionCount, IdleTimeoutCount(350초 유휴로 정리된 연결), PacketsDropCount
Troubleshoot NAT gateways AWS
350초 유휴면 연결이 만료되고 이어서 보내면 RST를 돌려줌, 350초보다 짧은 keepalive 권장, 연결 한도에 닿으면 가용 영역별 게이트웨이·IP 추가·연결 수 줄이기
Source Network Address Translation (SNAT) with Azure NAT Gateway Microsoft Azure
공인 IP 하나당 SNAT 포트 64,512개(IP 최대 16개), 같은 목적지로 가는 연결마다 다른 포트가 필요, 닫힌 포트는 같은 목적지에 다시 쓰기 전 쿨다운
Metrics and alerts for Azure NAT Gateway Microsoft Azure
SNAT Connection Count를 Failed 상태로 거른 값이 0보다 크면 SNAT 포트 고갈 가능성, Dropped Packets
IP addresses and ports Google Cloud
NAT IP 하나당 TCP·UDP 각각 64,512포트, VM당 최소 포트 기본 64(정적 할당)·32(동적 할당), VM에 예약된 포트 수가 같은 목적지로 가는 동시 연결 수를 제한, 닫힌 연결은 TIME_WAIT 동안 못 씀
Logs and metrics Google Cloud
dropped_sent_packets_count의 reason OUT_OF_RESOURCES: NAT IP나 포트가 모자라 버린 패킷

로드밸런서 쏠림·헬스체크 오판 LB imbalance, bad health checks

ID dc-lb-imbalance · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발

로드밸런서가 한 서버에만 연결을 몰아주거나, 이미 죽은 서버로 계속 사람을 보냅니다.

왜 분배 규칙이 맞지 않거나 헬스체크가 실제 상태를 못 봄 → 그러면 한 서버만 과부하, 또는 죽은 서버로 접속 시도 → 화면에서는 일부 채널·일부 사람만 슬로우모션, 접속 불가·무한 로딩

증상: 슬로우모션, 접속 불가·무한 로딩
요인: 정체, 손실
누가 겪나: 특정 장소·채널
언제: 접속·점검 직후, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 로드밸런서의 확인 요청에 실제 게임 상태(틱 진행, DB 연결)를 보고 답하는 헬스체크 구현, 서버 부하 값을 함께 알려 주기.
인프라팀 할 일: 헬스체크를 실제 게임 응답을 확인하는 방식으로 바꾸기, 서버 부하 기반 분배, 서버별 연결 수 차이 모니터링.
그래프에서는: 일부만 높음 · 서버별 연결 수·CPU 사용률
확인할 곳: 로드밸런서 뒤 서버마다 연결 수(ss -s)와 CPU 사용률을 한 그래프에 겹쳐 보고, 로드밸런서의 대상 헬스 상태(AWS는 CloudWatch의 HealthyHostCount·UnHealthyHostCount)를 게임 서버의 실제 상태와 비교
이러면 맞음: 서버 한두 대만 연결 수·CPU가 다른 서버보다 크게 높거나, 틱이 멈춘 서버가 헬스 상태 “정상”으로 남아 새 접속을 계속 받음
이러면 아님: 서버별 연결 수가 고른데 한 채널만 느리면 그 채널 안의 부하(“단일 스레드 지역 과부하(핫스팟)”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: AWS 2025: AWS us-east-1 DynamoDB DNS 장애와 긴 복구

출처 3건

Load Balancing in the Datacenter Google
단순 라운드 로빈은 작업 간 CPU 사용량이 최대 2배까지 벌어짐, 백엔드가 응답·헬스체크에 부하를 실어 보내는 가중 분배, 요청을 그만 받겠다는 lame duck 상태
Health checks for Network Load Balancer target groups AWS
헬스체크 기본 30초 간격·2회 실패로 제외, UDP 서비스는 TCP·HTTP 헬스체크로 확인하므로 실제 서비스 상태를 반영하도록 구성 권장
CloudWatch metrics for your Network Load Balancer AWS
HealthyHostCount·UnHealthyHostCount: 정상·비정상으로 판정된 대상 수

스위치 마이크로버스트 Switch microburst drops

ID dc-microburst · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라, 인프라팀·서버 인프라

여러 서버가 같은 순간 수천 명에게 패킷을 한꺼번에 보내면, 그 트래픽이 모이는 스위치 포트의 작은 버퍼가 1ms도 안 돼 넘칩니다.

왜 월드 보스 등장·대규모 스킬, 또는 여러 서버의 틱이 같은 순간에 맞물려 한꺼번에 발송 → 그러면 여러 포트가 한 포트로 모이거나 빠른 포트에서 느린 포트로 넘어가는 곳의 버퍼(포트당 수백 KB~수 MB)가 순간적으로 가득 → 화면에서는 일부 패킷 폐기, 많은 사람이 동시에 순간이동·스킬 씹힘

증상: 순간이동, 씹힘·롤백
요인: 손실
누가 겪나: 특정 장소·채널
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라, 인프라팀·서버 인프라
게임개발팀 할 일: 전송을 틱 안에 고르게 나누기(페이싱), 서버마다 틱 시작 시점을 조금씩 어긋나게.
인프라팀 할 일: 네트워크: 버퍼 큰 스위치, 트래픽 분산(서버를 여러 스위치·포트에 나눠 배치), 스위치 포트별 폐기 카운터 감시. 서버 장비·OS: 서버 전체 송신 속도 상한(리눅스 tc 셰이퍼).
수치 감각: 10Gbps 포트로 1ms 동안 내보낼 수 있는 양은 약 1.25MB. 두 포트의 트래픽이 한 포트로 동시에 몰리면 1ms마다 1.25MB씩 쌓입니다. 1초 평균 사용률이 10%여도 1ms 단위로는 넘칠 수 있습니다.
그래프에서는: 인원·부하를 따라 오름 · 스위치 포트 출력 폐기 수
확인할 곳: 서버가 붙은 스위치 포트와 그 트래픽이 모이는 포트의 출력 폐기 카운터(ifOutDiscards, 장비에 따라 output drops)를 가능한 짧은 간격으로 모아 보스 등장·대규모 전투 시각과 맞춰 봄. 1초·1분 평균 사용률 그래프만으로는 보이지 않음
이러면 맞음: 평균 사용률은 낮은데 사람이 한곳에 몰리는 순간마다 출력 폐기가 늘고 그때 여러 유저가 동시에 순간이동·스킬 씹힘을 제보함
이러면 아님: 폐기가 평균 사용률이 높은 시간대에 꾸준히 늘면 “데이터센터 회선 포화”. 입력 오류(CRC)가 늘면 “불량 케이블·포트 오류”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

High-Resolution Measurement of Data Center Microbursts (IMC 2017) ACM
데이터센터 버스트의 70% 이상이 수십 µs 안에 끝남, 평균 사용률이 약 9%인 포트에서도 버스트로 패킷 폐기
Data Center TCP (DCTCP) (SIGCOMM 2010) ACM
범용 스위치는 버퍼가 얕음(48포트가 4MB 공유, 한 포트가 약 700KB까지 사용), 여러 흐름이 짧은 순간 한 포트로 몰리면 손실
RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards: 오류가 없는데도 버퍼 공간 확보 등의 이유로 내보내지 못하고 버린 패킷 수

데이터센터 회선 포화 Uplink saturation

ID dc-uplink · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라

패치 배포·로그 전송·백업이 게임과 같은 회선을 쓰면 회선이 꽉 찹니다.

왜 대용량 전송이 같은 회선을 점유 → 그러면 회선 대기열과 손실 증가 → 화면에서는 서버 전체 핑 상승과 순간이동

증상: 입력 지연, 순간이동
요인: 지연, 손실
누가 겪나: 서버 전체
언제: 일정한 주기로, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라
인프라팀 할 일: 네트워크: 게임 트래픽 우선 처리(QoS), 대용량 전송 회선 분리, 회선 사용률 경보. 서버 장비·OS: 백업·로그 전송·배포에 속도 제한을 걸고 한산한 시간에 실행.
그래프에서는: 한도에 닿아 평평해짐 · 회선 사용률, RTT(핑)
확인할 곳: 데이터센터 회선(업링크) 인터페이스의 사용률(SNMP ifHCInOctets·ifHCOutOctets로 계산)과 출력 폐기(ifOutDiscards)를 백업·배포·로그 전송 일정과 같은 시간축에 놓고 봄
이러면 맞음: 회선 사용률이 대역폭 한도에 붙어 평평해진 시각에 서버 전체 RTT와 폐기가 오르고, 그 시각이 대용량 전송 작업과 겹침
이러면 아님: 분 단위 사용률이 한도에 한참 못 미치는데 폐기가 있으면 “스위치 마이크로버스트”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

RFC 4594: Configuration Guidelines for DiffServ Service Classes IETF
게임 같은 실시간 대화형 트래픽과 백업 같은 대용량 전송을 서로 다른 서비스 등급으로 나눠 처리
RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
장비로 들어오는 양이 내보내는 속도를 넘으면 대기열이 쌓이고 과도한 대기열이 지연의 주요 원인
RFC 2863: The Interfaces Group MIB IETF
ifHCInOctets·ifHCOutOctets: 인터페이스로 받고 보낸 바이트 수(64비트), ifOutDiscards: 내보내지 못하고 버린 패킷 수

네트워크 장비 장애 전환(페일오버) Network device failover

ID dc-failover · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발

라우터·방화벽 한 대가 고장 나 예비 장비로 전환(페일오버)되는 몇 초 동안 모두가 멈춥니다.

왜 장비 고장 또는 점검으로 예비 장비로 전환 → 그러면 전환에 수 초, 세션 정보가 동기화되지 않으면 연결 초기화 → 화면에서는 서버의 모든 유저가 동시에 멈춤, 대량 접속 끊김

증상: 멈춤, 접속 끊김
요인: 손실
누가 겪나: 서버 전체
언제: 가끔 무작위로
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 짧은 끊김(수 초)을 견디는 타임아웃, 끊겨도 재접속하면 세션 토큰으로 세션을 이어 받게. 클라이언트: 끊기면 자동 재접속(한꺼번에 몰리지 않게 재시도 간격을 무작위로 분산).
인프라팀 할 일: 연결 상태를 공유하는 이중화, BFD로 고장을 1초 안에 감지, 전환 시험을 정기적으로.
수치 감각: 장비가 고장을 바로 감지하면 1~3초 안팎. 빠른 고장 감지(BFD) 없이 BGP 기본 타이머에만 맡기면 인접 장비가 감지하기까지 90~180초 동안 경로가 끊길 수 있습니다.
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 서버 전체 송수신량
확인할 곳: 라우터·방화벽의 이벤트 로그(VRRP 역할 변경, BFD·BGP 세션 다운, 장애 전환 기록)와 같은 시각의 서버 전체 접속 수·송수신량을 봄
이러면 맞음: 장비 로그의 전환 시각에 그 장비 뒤 모든 서버의 트래픽이 몇 초간 0이 되거나 접속 수가 동시에 떨어짐
이러면 아님: 한 서버의 접속만 떨어지면 “서버 크래시”나 “NIC 드라이버·펌웨어 문제”. 장비 로그가 깨끗하고 멈춘 서버가 클라우드 가상 머신 한 대면 “클라우드 호스트 점검·라이브 마이그레이션”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

RFC 5880: Bidirectional Forwarding Detection (BFD) IETF
라우팅 프로토콜의 Hello 방식은 고장 감지에 1초 이상 걸려, 더 짧은 시간에 감지하려고 만든 BFD
RFC 7938: Use of BGP for Routing in Large-Scale Data Centers IETF
BGP keepalive에만 기대면 수렴이 느리고 링크 다운을 바로 받아 세션을 끊으면 ms 단위로 감지해 재수렴
RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 IETF
VRRP 광고 기본 1초, 예비 장비는 광고가 약 3배 간격 넘게 끊기면 역할을 넘겨받음(기본 설정으로 3초 남짓)

불량 케이블·포트 오류 Bad cable / optics (CRC errors)

ID dc-bad-cable · 주 담당 인프라팀·네트워크 인프라

광모듈이나 케이블이 불량이면 그 경로를 지나는 패킷이 일정 비율로 깨집니다.

왜 광모듈·케이블 불량으로 비트 오류 → 그러면 깨진 패킷은 장비가 조용히 폐기 → 화면에서는 그 경로를 쓰는 일부 서버·사용자만 꾸준한 손실로 순간이동·고무줄

증상: 순간이동, 고무줄
요인: 손실
누가 겪나: 특정 장소·채널
언제: 항상
담당: 주 담당 인프라팀·네트워크 인프라
인프라팀 할 일: 포트 오류(CRC) 카운터 모니터링·경보, 광모듈·케이블 등 부품 교체, 교체 전까지 문제 링크를 빼서 우회.
그래프에서는: 일부만 높음 · 포트별 CRC 오류 수, 서버·경로별 손실률
확인할 곳: 링크 양쪽의 CRC 카운터를 봄. 스위치는 포트의 FCS 오류(dot3StatsFCSErrors)·입력 오류(ifInErrors), 서버는 ip -s -s link의 RX errors 중 crc(커널 통계 rx_crc_errors)
이러면 맞음: 한 포트의 CRC 오류가 트래픽 양·시간대와 상관없이 꾸준히 늘고 그 포트를 지나는 서버·유저만 손실이 있음
이러면 아님: CRC 오류가 없고 출력 폐기만 늘면 혼잡(“스위치 마이크로버스트”, “데이터센터 회선 포화”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017) ACM
데이터센터 35만 링크 분석: 깨짐 원인은 불량 광모듈·손상된 광섬유·더러운 커넥터, 깨짐률은 사용량과 무관하게 꾸준, 경로 수를 지키며 문제 링크를 빼고 수리
RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
프레임 검사(FCS) 실패 카운터(dot3StatsFCSErrors), 이 오류는 입력 오류(ifInErrors)로 합산
Interface statistics Linux kernel
rx_crc_errors: CRC 오류로 받은 패킷 수, ip -s -s link로 오류 종류별 확인

MTU 불일치 (큰 패킷만 사라짐) MTU black hole

ID dc-mtu · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발

중간 구간의 MTU(한 번에 보낼 수 있는 크기)가 줄었는데 크기 초과 알림이 막히면, 큰 패킷만 계속 사라집니다.

왜 터널·VPN 구간에서 MTU가 줄어듦 → 그러면 크기 초과 알림(ICMP)이 방화벽에 막혀 보내는 쪽이 모름 → 화면에서는 인벤토리·캐릭터 목록처럼 큰 화면을 열 때만 멈췄다가 접속 끊김

증상: 멈춤, 접속 끊김, 접속 불가·무한 로딩
요인: 손실
누가 겪나: 특정 지역·통신사, 나만
언제: 특정 행동을 할 때, 접속·점검 직후
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발
게임개발팀 할 일: 서버 쪽에서 직접 낮추려면 소켓의 최대 세그먼트 크기(TCP_MAXSEG) 설정(게임 코드에서 메시지를 잘게 쪼개는 것만으로는 안 막힘), UDP 패킷은 1,200바이트 이하로 유지.
인프라팀 할 일: 네트워크: 터널 구간에서 TCP 패킷 크기 줄이기(MSS 조정), 방화벽·클라우드 네트워크 ACL에서 크기 초과 알림(ICMP) 허용. 서버 장비·OS: 서버 방화벽·클라우드 보안 그룹에서도 크기 초과 알림(ICMP) 허용, 서버 커널의 MTU 탐색(tcp_mtu_probing=1) 켜기(몇 초 멈춘 뒤에야 작동하는 마지막 안전망).
수치 감각: 보통 1,500바이트, 터널을 지나면 1,400 안팎으로 줄어듭니다.
그래프에서는: 일부만 높음 · 지역·통신사별 접속 끊김, 큰 응답 실패
확인할 곳: 문제 유저 PC에서 서버로 쪼개지 말라는 표시(DF)를 켠 핑을 크기를 바꿔 가며 보냄. 윈도우는 ping /f /l 1472 SERVER_IP, 리눅스는 ping -M do -s 1472 SERVER_IP(1,472는 MTU 1,500에서 IP 헤더 20바이트와 ICMP 헤더 8바이트를 뺀 값). 크기를 줄여 가며 통과하는 최대 크기를 찾고 서버 쪽 보안 그룹·방화벽이 ICMP 크기 초과 알림(Fragmentation Needed)을 허용하는지 확인
이러면 맞음: 작은 핑은 가는데 1,472바이트 DF 핑은 실패하고(응답 없음 또는 단편화가 필요하다는 오류), 통과하는 최대 크기가 1,400 안팎으로 작음. 같은 지역 유저들이 큰 화면을 열 때만 멈춤
이러면 아님: 1,472바이트 DF 핑도 잘 가면 경로 MTU 문제가 아님. 작은 핑도 안 가면 ICMP 자체가 막힌 것이라 이 방법으로는 판단할 수 없음
확인 수단: 유저 쪽 환경에서 확인

출처 5건

RFC 2923: TCP Problems with Path MTU Discovery IETF
방화벽이 ICMP(Fragmentation Needed)를 막으면 경로 MTU 탐색이 실패해 큰 패킷만 계속 사라짐(블랙홀), 핑·작은 통신은 되어 진단이 어려움
Maximum transmission unit and maximum segment size Cloudflare
인터넷 경로 MTU 1,500, GRE 터널을 지나면 1,476, TCP MSS는 1,436 이하로 제한 권장
IP Sysctl Linux kernel
tcp_mtu_probing=1은 평소 꺼져 있다가 ICMP 블랙홀을 감지했을 때 TCP 경로 MTU 탐색을 켬
ping(8) — Linux manual page iputils
-M do는 DF 표시를 켜고 경로 MTU보다 큰 패킷을 거부, -s로 데이터 크기 지정(기본 56바이트에 ICMP 헤더 8바이트)
ping Microsoft
/f는 DF 표시를 켜서 경로 MTU 문제를 찾는 데 쓰고 /l로 데이터 크기 지정

L6 서버 네트워크 카드

NIC 인터럽트 단일 코어 집중 Single-queue NIC / no RSS

ID nic-irq · 주 담당 인프라팀·서버 인프라

NIC가 패킷 도착 인터럽트를 CPU 코어 하나에만 보내면 그 코어가 병목이 됩니다.

왜 수신 큐가 하나이거나 여러 코어로 분산하는 RSS가 꺼져 있음 → 그러면 코어 하나가 100%가 되어 패킷을 제때 못 꺼냄 → 화면에서는 사람이 몰릴 때 서버 전체에서 손실과 지연(순간이동·입력 지연)

증상: 순간이동, 고무줄, 입력 지연
요인: 손실, 지연
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: RSS(NIC가 분산)·RPS(커널이 분산) 설정, 인터럽트를 여러 코어에 분산, UDP는 포트까지 보고 큐를 나누게 설정(ethtool -N의 rx-flow-hash udp4 sdfn), 인터럽트 처리 코어와 게임 틱 스레드 코어 분리, 코어별 %soft 감시.
수치 감각: 코어 하나가 커널을 거쳐 처리할 수 있는 양은 패킷 크기와 설정에 따라 대략 초당 수십만 패킷. 코어별 사용률에서 수신 처리 비중(mpstat의 %soft)이 한 코어에만 몰려 있으면 이 경우입니다.
그래프에서는: 한도에 닿아 평평해짐 · 코어별 %soft, 초당 수신 패킷 수
확인할 곳: mpstat -P ALL 1로 코어별 %soft(소프트웨어 인터럽트 처리 비율)를 보고, /proc/interrupts로 NIC 큐별 인터럽트가 어느 코어로 가는지, ethtool -l로 큐 수, ethtool -S로 큐별 패킷 수(이름은 드라이버마다 다름)를 확인
이러면 맞음: 한 코어만 %soft가 100% 가까이에 붙어 있고 나머지는 한가하며 인터럽트와 패킷이 큐 하나에 몰림. 그때부터 초당 수신 패킷 수가 더 오르지 못함
이러면 아님: %soft가 여러 코어에 고르게 퍼져 있으면 이 원인이 아님. CPU는 한가한데 손실이 있으면 “클라우드 PPS 한도 초과”나 “링 버퍼 부족”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 큐가 여러 개여도 게이트웨이·프록시처럼 몇 안 되는 주소에서 트래픽이 대부분 오면 한 큐로 몰립니다. UDP는 NIC 기본 설정이 주소만 보고 큐를 나누는 경우가 있어, 포트까지 보도록 바꿔야 고르게 퍼집니다.

출처 4건

Scaling in the Linux Networking Stack Linux kernel
RSS(NIC가 여러 수신 큐로 분산)·RPS(커널이 분산), 큐마다 인터럽트를 따로 두고 여러 코어에 나누는 설정, 수신 인터럽트 처리가 병목이면 RSS 권장
How to receive a million packets per second Cloudflare
수신 큐 하나가 코어 하나로만 가면 그 코어가 초당 약 35만~43만 패킷에서 막힌 측정, NIC가 UDP를 IP 주소로만 해시해 한 큐로 몰린 사례
ethtool(8) — Linux manual page ethtool
ethtool -N rx-flow-hash udp4로 UDP 해시에 포트(f·n)까지 넣는 옵션
mpstat(1) — Linux manual page sysstat
%soft: CPU가 소프트웨어 인터럽트 처리에 쓴 시간 비율, -P ALL로 코어별

링 버퍼 부족 RX ring buffer overflow

ID nic-ring · 주 담당 인프라팀·서버 인프라

NIC가 패킷을 잠시 담아 두는 링 버퍼가 작으면, 순간적으로 몰릴 때 버퍼가 넘쳐 패킷이 버려집니다.

왜 링 버퍼가 기본값(드라이버마다 슬롯 256~2,048개)으로 작음 → 그러면 버스트 때 CPU가 꺼내기 전에 버퍼가 넘침 → 화면에서는 버스트 순간에만 손실(순간이동·스킬 씹힘). 게임 서버 로그에는 흔적이 없음

증상: 순간이동, 씹힘·롤백
요인: 손실
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: 링 버퍼 크게(ethtool -G), 폐기(drop) 카운터 감시(ethtool -S의 rx_missed_errors 등, 이름은 드라이버마다 다름).
수치 감각: 초당 100만 패킷이 몰리면 슬롯 1,024개는 약 1ms 만에 찹니다. 그 사이 CPU가 한 번만 늦게 와도 넘칩니다. 대부분의 NIC는 수천 개까지 늘릴 수 있습니다.
그래프에서는: 가끔 무작위로 튐 · NIC 수신 폐기 카운터
확인할 곳: ethtool -S의 수신 폐기 카운터(rx_missed_errors, rx_fifo_errors 등, 이름은 드라이버마다 다름)와 ip -s -s link의 missed를 짧은 간격으로 모으고, ethtool -g로 현재 링 크기와 최대값을 확인
이러면 맞음: 버스트 순간에 폐기 카운터가 늘고 현재 링 크기가 최대값보다 한참 작음. 링을 키우면 폐기가 줄어듦
이러면 아님: 폐기 카운터가 그대로인데 손실이 있으면 커널 다음 단계(“커널 소켓 버퍼 부족”)나 네트워크 구간. 한 코어의 %soft가 100%면 “NIC 인터럽트 단일 코어 집중”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

Linux Base Driver for Intel(R) Ethernet Network Connection (e1000) Linux kernel
e1000 수신 디스크립터(링 슬롯) 기본 256개, 4,096개까지 늘릴 수 있음
drivers/net/ethernet/intel/ice/ice.h (Linux v6.12) Linux kernel
ice 드라이버 수신 디스크립터 기본 2,048개, 최대 8,160개
Interface statistics Linux kernel
버퍼가 모자라 장치가 버린 패킷은 rx_missed_errors로 집계, 드라이버별 통계는 ethtool -S로 확인
ethtool(8) — Linux manual page ethtool
-g로 링 크기(현재값·최대값) 확인, -G로 변경, -S로 드라이버별 통계

인터럽트 병합 과다 Interrupt coalescing

ID nic-coalesce · 주 담당 인프라팀·서버 인프라

CPU 부담을 줄이려고 패킷을 모았다 한 번에 알리면, 모으는 시간만큼 늦어집니다.

왜 NIC가 일정 시간·개수만큼 모았다가 알림 → 그러면 모으는 동안 패킷이 대기 → 화면에서는 미세한 지연 증가. 보통은 작지만 과하면 ms 단위

증상: 입력 지연
요인: 지연
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: 적응형 병합, 게임 서버에 맞는 값으로 조정(ethtool -C).
수치 감각: 보통 수십~수백 µs. 게임에는 대개 무시할 수준이지만 설정이 과하면 ms로 커집니다.
그래프에서는: 처음부터 늘 높음 · 같은 데이터센터 안 왕복 시간
확인할 곳: ethtool -c로 현재 병합 설정(adaptive-rx, rx-usecs, rx-frames)을 보고 같은 데이터센터의 다른 서버와 ping 왕복 시간을 설정을 바꾸기 전후로 비교
이러면 맞음: rx-usecs가 수백 µs 이상으로 크게 잡혀 있고 값을 줄이면 같은 데이터센터 안 왕복 시간이 그만큼 줄어듦
이러면 아님: 줄여도 왕복 시간이 그대로면 이 원인이 아님
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Linux Driver for Intel(R) Ethernet Network Connection (e1000e) Linux kernel
기본은 적응형 인터럽트 조절로 초당 4,000~20,000번(간격 50~250µs), 인터럽트를 줄이면 CPU는 아끼지만 지연이 늘어남
Linux Base Driver for Intel(R) Ethernet Network Connection (e1000) Linux kernel
RxIntDelay로 수신 인터럽트를 1.024µs 단위로 최대 65,535까지(약 67ms) 늦출 수 있고, 값을 키우면 수신 지연이 늘어남
ethtool(8) — Linux manual page ethtool
ethtool -C의 adaptive-rx·rx-usecs·rx-frames 설정

클라우드 PPS 한도 초과 Cloud PPS / bandwidth allowance

ID nic-cloud-pps · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 외부·외부

클라우드 서버는 종류마다 초당 패킷 수·대역폭 한도가 있고 넘으면 조용히 버립니다.

왜 동접이 늘어 초당 패킷 수가 인스턴스 한도를 넘음 → 그러면 클라우드 네트워크가 초과분을 폐기 → 화면에서는 원인을 알 수 없는 손실로 순간이동·스킬 씹힘. 서버 CPU는 여유

증상: 순간이동, 씹힘·롤백
요인: 손실
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 외부·외부
게임개발팀 할 일: 패킷 합치기(한 틱의 메시지를 한 패킷에), 아주 작은 패킷을 자주 보내지 않게.
인프라팀 할 일: 한도 초과 카운터 확인(AWS는 pps_allowance_exceeded, conntrack_allowance_exceeded 등)·경보, 더 큰 인스턴스, 연결 추적 한도는 추적이 생기지 않는 보안 그룹 구성으로 피하기.
외부 할 일: 클라우드 사업자에 인스턴스 종류별 초당 패킷 수·연결 추적 한도 문의.
수치 감각: 한도는 인스턴스 크기마다 다르고 초당 패킷 수 한도는 공개하지 않는 경우가 많습니다. 작은 인스턴스의 “최대 10Gbps”는 크레딧이 남아 있는 동안(보통 5~60분)만 쓸 수 있는 버스트 속도이고, 평소 기본 속도는 훨씬 낮습니다.
그래프에서는: 한도에 닿아 평평해짐 · 초당 패킷 수, allowance 초과 카운터
확인할 곳: ethtool -S의 ENA 카운터 pps_allowance_exceeded·bw_in_allowance_exceeded·bw_out_allowance_exceeded·conntrack_allowance_exceeded를 짧은 간격으로 모아 초당 패킷 수와 함께 봄. CloudWatch 에이전트로 이 카운터를 올려 경보를 걸 수도 있음
이러면 맞음: 손실이 난 시각에 allowance 초과 카운터가 늘고 초당 패킷 수가 일정한 값에서 더 오르지 못함. 서버 CPU는 여유
이러면 아님: 초과 카운터가 그대로면 이 원인이 아님. 한 코어의 %soft가 100%면 “NIC 인터럽트 단일 코어 집중”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: conntrack_allowance_exceeded는 연결 추적 테이블이 가득 차 새 연결을 버린 경우입니다. 테이블은 여유가 있는데 유휴 연결만 추적이 만료되어 끊긴다면 “클라우드 보안 그룹의 연결 추적 만료” 항목을 보세요.

출처 2건

Monitor network performance for ENA settings on your EC2 instance AWS
인스턴스마다 대역폭·PPS·연결 추적 한도가 있고 넘치면 큐에 쌓았다가 버림, pps_allowance_exceeded·conntrack_allowance_exceeded 카운터
Amazon EC2 instance network bandwidth AWS
16 vCPU 이하 인스턴스의 “최대 N Gbps”는 네트워크 I/O 크레딧으로 쓰는 버스트(보통 5~60분), 크레딧이 떨어지면 기준 대역폭으로 돌아감

NIC 대역폭 포화 NIC bandwidth saturation

ID nic-saturate · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

1Gbps·10Gbps 카드의 한계까지 쓰면 송신 대기열이 길어지고 넘친 패킷은 버려집니다.

왜 브로드캐스트 증가로 전송량이 카드 한계에 도달 → 그러면 송신 대기열이 길어지고 넘치면 폐기 → 화면에서는 서버 전체 지연·손실(입력 지연·순간이동)

증상: 입력 지연, 순간이동
요인: 지연, 손실
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 전송량 줄이기(관심 영역, 압축, 변경분만).
인프라팀 할 일: 카드 증설(더 빠른 NIC, 클라우드는 더 큰 인스턴스), NIC 사용률 경보.
그래프에서는: 한도에 닿아 평평해짐 · NIC 송신량, 송신 폐기
확인할 곳: sar -n DEV 1의 txkB/s와 %ifutil(인터페이스 속도 대비 사용률)을 NIC 속도·인스턴스 대역폭과 비교하고, ip -s link의 TX dropped를 함께 봄
이러면 맞음: 송신량이 NIC·인스턴스 대역폭 근처에서 평평해지고 그때부터 송신 폐기와 서버 전체 지연이 늘어남
이러면 아님: 대역폭에 여유가 있으면 이 원인이 아님. 작은 패킷이 많은데 손실이 있으면 “클라우드 PPS 한도 초과”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Interface statistics Linux kernel
tx_dropped: 자원이 모자라 송신 도중 버린 패킷 수
Amazon EC2 instance network bandwidth AWS
인스턴스가 쓸 수 있는 대역폭은 vCPU 수(인스턴스 크기)에 따라 정해짐
sar(1) — Linux manual page sysstat
-n DEV의 rxkB/s·txkB/s와 %ifutil(인터페이스 속도 대비 사용률)

가상화 오버헤드·노이지 네이버 Noisy neighbors in virtualization

ID nic-noisy · 주 담당 인프라팀·서버 인프라 · 함께 외부·외부

같은 물리 서버의 다른 가상 머신이 네트워크·CPU를 많이 쓰면 내 서버의 처리가 불규칙하게 밀립니다.

왜 같은 물리 서버의 다른 가상 머신이 자원을 많이 씀 → 그러면 내 가상 머신의 패킷 처리가 불규칙하게 지연 → 화면에서는 뚜렷한 원인 없이 가끔 지터(도착 간격의 흔들림)가 생겨 뚝뚝 끊김

증상: 뚝뚝 끊김
요인: 지터
누가 겪나: 서버 전체
언제: 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라 · 함께 외부·외부
인프라팀 할 일: 전용 호스트, 성능 보장 인스턴스, 지터가 계속되는 인스턴스는 중지 후 다시 시작해 다른 호스트로 옮기기.
외부 할 일: 클라우드 사업자에 문제 호스트 신고.
그래프에서는: 가끔 무작위로 튐 · 같은 데이터센터 안 왕복 시간 지터, %steal
확인할 곳: 같은 데이터센터의 다른 서버로 계속 ping을 보내 왕복 시간의 지터를 기록하고, mpstat의 %steal과 함께 같은 구성의 다른 인스턴스와 비교
이러면 맞음: 이 인스턴스만 왕복 시간 지터나 %steal이 불규칙하게 튀고 같은 구성의 다른 인스턴스는 조용함. 중지 후 다시 시작해 다른 호스트로 옮기면 사라짐
이러면 아님: 같은 구성의 인스턴스가 모두 똑같이 튀면 호스트 문제가 아님. 게임 서버 쪽 부하나 네트워크 구간을 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 2건

How EC2 instance stop and start works AWS
인스턴스를 중지했다 시작하면 대부분 새 호스트로 옮겨짐(전용 호스트 제외)
mpstat(1) — Linux manual page sysstat
%steal: 하이퍼바이저가 다른 가상 CPU를 돌리는 동안 이 가상 CPU가 어쩔 수 없이 기다린 시간 비율

클라우드 호스트 점검·라이브 마이그레이션 Cloud host maintenance / live migration

ID nic-host-maintenance · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 외부·외부

클라우드 사업자가 물리 서버(호스트)를 점검할 때 가상 머신을 다른 호스트로 옮기거나(라이브 마이그레이션) 잠시 멈춥니다. 그동안 서버 전체가 멈추고 멈춘 시간이 길면 연결이 끊깁니다.

왜 사업자가 호스트 점검이나 고장 예측으로 가상 머신을 다른 호스트로 옮기거나 잠시 일시 정지 → 그러면 옮기는 동안 CPU·메모리·네트워크가 느려지고 마지막에 가상 머신이 잠깐 완전히 멈춤(사업자와 방식에 따라 1초 미만에서 30초 안팎) → 화면에서는 서버의 모두가 동시에 멈췄다가 몰아치기·순간이동, 멈춤이 타임아웃보다 길면 대량 접속 끊김

증상: 멈춤, 몰아치기, 순간이동, 접속 끊김
요인: 정체, 손실
누가 겪나: 서버 전체
언제: 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 외부·외부
게임개발팀 할 일: 수 초 멈춤을 견디는 타임아웃, 멈춘 뒤 따라잡는 틱 수에 상한 두기, 경과 시간은 단조 시계(monotonic clock)로 계산, 점검 알림을 받으면 진행 상황을 저장하고 유저를 다른 서버로 옮기는 절차.
인프라팀 할 일: 점검 알림 구독과 경보(Google Cloud maintenance-event, AWS 예약 이벤트·AWS Health, Azure Scheduled Events), 알림을 받으면 유저가 적은 시간에 미리 서버 교체, 사업자가 허용하면 점검 시각 조정(Azure Maintenance Configuration, 종류에 따라 AWS 예약 이벤트), 점검 기록과 장애 기록 대조.
외부 할 일: 클라우드 사업자에 점검 일정과 영향 범위 확인, 같은 인스턴스에서 멈춤이 반복되면 신고.
수치 감각: Google Compute Engine은 라이브 마이그레이션의 멈춤이 보통 1초보다 훨씬 짧다고 하고, 멈추는 동안 시스템 시계가 최대 5초 앞으로 뛸 수 있습니다. 메타데이터의 maintenance-event 값은 옮기기 60초 전에 바뀝니다(그 전에 이 값을 한 번 이상 조회해 둔 경우). Azure는 재부팅이 필요 없는 점검이면 거의 항상 10초 미만, 드물게(일반 크기는 18개월에 한 번 이하) 약 30초 멈추고 라이브 마이그레이션은 보통 5초를 넘지 않습니다. Azure Scheduled Events는 이런 멈춤(Freeze)을 최소 15분 전에 알립니다. 다만 호스트 하드웨어가 갑자기 고장 나면 알림 없이 바로 복구를 시작합니다.
그래프에서는: 끊겼다가 몰아서 · 서버 송수신 패킷 수, 틱 간격
확인할 곳: 멈춘 시각을 사업자 기록과 대조함. Google Cloud는 감사 로그의 compute.instances.migrateOnHostMaintenance, AWS는 describe-instance-status·AWS Health의 예약 이벤트, Azure는 활동 로그(Activity Log)의 Microsoft.Compute/virtualMachines/liveMigration/action과 VM 가용성 지표(VmAvailabilityMetric)가 0으로 떨어진 시각. 서버 안에서는 멈춘 동안 지표·로그가 비었는지, 직후 시계가 뛰었는지(시간 동기화 로그) 봄
이러면 맞음: 서버 전체가 멈춘 시각이 사업자가 기록한 점검·마이그레이션 시각과 겹치고 그 몇 초 동안 서버 안의 지표·로그가 모두 빔
이러면 아님: 사업자 기록에 없고 짧은 멈춤이 자주 되풀이되면 “CPU 스틸 (가상 머신)”. 커널 로그에 NIC 재설정 기록이 있으면 “NIC 드라이버·펌웨어 문제”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: AWS는 예약 이벤트로 알립니다. system-reboot는 재부팅하며 새 호스트로 옮기는 이벤트이고 system-maintenance는 네트워크·전원 점검으로 잠시 영향을 줄 수 있는 이벤트입니다. 멈춘 시간이 몇 초여도 그동안 서버에 보낸 패킷의 ACK를 받지 못한 클라이언트는 재전송 대기를 두 배씩 늘려 가므로, 풀린 뒤에도 TCP 연결은 더 오래 멈춰 있을 수 있습니다(“TCP RTO와 지수 백오프”). 멈췄다 깨어나면 “시스템 시계 점프 (NTP 스텝)”처럼 시계가 뛰기도 하고 로드밸런서 헬스체크가 실패해 그 서버를 잠시 빼기도 합니다. 옮길 수 없는 인스턴스(Google Cloud의 베어메탈 인스턴스 등)는 점검 때 중지되거나 다시 시작됩니다.

출처 6건

Live migration process during maintenance events Google Cloud
라이브 마이그레이션의 멈춤은 보통 1초보다 훨씬 짧음, 멈추는 동안 시스템 시계가 최대 5초 앞으로 뜀, 옮기는 동안 디스크·CPU·메모리·네트워크 성능이 잠시 떨어짐, 라이브 마이그레이션하지 않는 VM은 점검 때 종료(베어메탈 인스턴스는 지원 안 함)
Query metadata server for maintenance event notices Google Cloud
maintenance-event 메타데이터 값이 라이브 마이그레이션 60초 전에 바뀜(라이브 마이그레이션 설정이고 지난 점검 뒤 이 값을 한 번 이상 조회한 경우)
Monitor and plan for a host maintenance event Google Cloud
점검 때 감사 로그에 compute.instances.migrateOnHostMaintenance 시스템 이벤트가 남음
Scheduled events for Amazon EC2 instances AWS
예약 이벤트 종류(system-reboot는 재부팅하며 새 호스트로 이동, system-maintenance는 네트워크·전원 점검으로 잠시 영향), 메일·AWS Health로 알림, describe-instance-status로 확인, 종류에 따라 시각 조정 가능
Maintenance and updates Microsoft Azure
재부팅 없는 점검은 거의 항상 10초 미만 멈춤, 드물게(일반 크기는 18개월에 한 번 이하) 약 30초, 라이브 마이그레이션은 보통 5초 이하, 멈춘 뒤 시계 자동 동기화, 긴 TCP 연결이 끊기거나 상대가 멈춘 VM에 보낸 데이터를 지수 백오프로 재전송해 복구가 더 늦어질 수 있음, 로드밸런서 헬스체크가 약 10초 안에 비정상으로 판정, 활동 로그의 Microsoft.Compute/virtualMachines/liveMigration/action과 멈추는 동안 0이 되는 VmAvailabilityMetric으로 확인, Maintenance Configuration으로 적용 시각 선택
Scheduled Events for Linux VMs in Azure Microsoft Azure
Freeze(몇 초 멈춤, CPU·네트워크가 멈출 수 있음)는 최소 15분 전에 알림, 호스트 하드웨어 고장 때는 알림 기간 없이 바로 복구 시작

NIC 드라이버·펌웨어 문제 NIC hang / reset

ID nic-reset · 주 담당 인프라팀·서버 인프라

드라이버 버그나 기능 오동작으로 카드가 멈춰 재시작되는 동안 모든 송수신이 끊깁니다.

왜 드라이버 버그, 오프로드 기능 오동작 → 그러면 NIC가 멈추고 재시작(수 초) → 화면에서는 그 서버의 모두가 함께 멈췄다가 순간이동하거나 접속 끊김

증상: 멈춤, 접속 끊김
요인: 손실
누가 겪나: 서버 전체
언제: 가끔 무작위로, 오래 켜 둘수록
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: 커널 로그의 “transmit queue … timed out”, “Link is Down” 기록 확인·경보, 드라이버·펌웨어 업데이트, 문제 기능(오프로드 등) 끄기.
그래프에서는: 끊겼다가 몰아서 · 서버 송수신 패킷 수
확인할 곳: dmesg로 커널 로그에서 “NETDEV WATCHDOG … transmit queue N timed out”, 드라이버의 재설정, “Link is Down”·“Link is Up” 기록을 찾고 그 시각의 서버 송수신 패킷 수를 봄
이러면 맞음: 멈춘 시각에 커널 로그에 송신 큐 타임아웃이나 링크 다운·업 기록이 있고 그 몇 초 동안 송수신 패킷 수가 0
이러면 아님: 커널 로그가 깨끗하고 스위치 쪽 포트도 멀쩡하면 게임 서버 프로세스의 멈춤(“서버 GC 전체 멈춤”, “데드락”)이나 “네트워크 장비 장애 전환(페일오버)”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

net/sched/sch_generic.c (Linux v6.12) Linux kernel
송신 큐가 멈추면 커널 워치독이 “NETDEV WATCHDOG … transmit queue N timed out”을 남기고 드라이버의 재설정 함수를 부름
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c (Linux v6.12) Linux kernel
ixgbe 드라이버가 송신 멈춤 때 어댑터를 재설정하고 링크가 끊기면 “NIC Link is Down”을 기록
ethtool(8) — Linux manual page ethtool
ethtool -K로 오프로드 기능을 하나씩 끄는 옵션

GRO/LRO 병합 대기 지연 GRO/LRO batching

ID nic-offload · 주 담당 인프라팀·서버 인프라

여러 패킷을 하나로 묶어 CPU 부담을 줄이는 기능입니다. 설정에 따라 작은 게임 패킷이 함께 묶을 다음 패킷을 잠깐 기다리기도 합니다.

왜 NIC·커널이 도착한 패킷을 묶어서 처리 → 그러면 하드웨어 병합(LRO)이나 병합 대기 시간 설정이 켜져 있으면 다음 패킷을 기다리며 잠깐 대기 → 화면에서는 미세한 지연 증가(대개 수십 µs 이하)

증상: 입력 지연
요인: 지연
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: 게임 트래픽에 맞게 조정(LRO 끄기, 병합 대기 시간 설정 확인), 효과는 대개 작으니 다른 원인보다 뒤에 확인.
그래프에서는: 처음부터 늘 높음 · 같은 데이터센터 안 왕복 시간
확인할 곳: ethtool -k로 lro·gro 상태를, 장치의 sysfs 설정 gro_flush_timeout 값을 확인하고 바꾸기 전후 같은 데이터센터 안 작은 패킷의 왕복 시간을 비교
이러면 맞음: LRO가 켜져 있거나 gro_flush_timeout이 0보다 크고 끄거나 0으로 두면 작은 패킷의 왕복 시간이 줄어듦
이러면 아님: 바꿔도 차이가 수 µs 안쪽이면 이 원인이 아님
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

NAPI Linux kernel
gro_flush_timeout을 크게 잡으면 묶어 처리하는 대신 부하가 낮을 때 지연이 생김
Linux Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Adapters (ixgbe) Linux kernel
GRO는 수신 트래픽을 큰 덩어리로 합쳐 CPU를 아끼는 기능이고 LRO를 발전시킨 것
ethtool(8) — Linux manual page ethtool
ethtool -K의 gro·lro on|off 설정

L7 서버 OS (커널)

접속 대기열(backlog) 넘침 Listen backlog / SYN queue overflow

ID so-backlog · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발

점검 직후 수만 명이 동시에 접속하면, 커널의 접속 대기열(backlog)이 넘쳐 접속 시도가 버려집니다.

왜 점검 종료와 동시에 게임 서버가 accept로 접속을 처리하는 속도보다 빨리 몰림 → 그러면 커널의 접속 대기열(backlog. 서버 코드가 listen에 준 값과 커널 상한 중 작은 쪽)이 가득 → 화면에서는 접속 시도가 버려지고 재시도가 반복되어 접속 불가·무한 로딩

증상: 접속 불가·무한 로딩
요인: 손실
누가 겪나: 서버 전체
언제: 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 코드에서 주는 listen 값 늘리기, 접속을 받는 스레드가 다른 일로 멈추지 않게, 로그인 대기열 시스템. 클라이언트: 재시도 간격 늘리기(무작위로 분산).
인프라팀 할 일: 커널 somaxconn 늘리기(서버 코드의 listen 값과 둘 다 올려야 효과), SYN 쿠키 켜 두기, 넘침 횟수 감시(nstat의 TcpExtListenOverflows).
수치 감각: 리눅스 커널 상한(somaxconn)은 5.4부터 기본 4,096(그 전 128)이지만, 서버 코드가 listen에 더 작은 값을 주면 그 값이 한도입니다. 리눅스는 대기열이 차면 접속 요청을 오류 없이 조용히 버립니다. 클라이언트 OS가 1초 뒤부터 몇 차례 다시 보내므로, 플레이어에게는 “연결 실패”보다 긴 로딩으로 보입니다. 윈도우 서버는 거절 응답을 돌려보내 클라이언트가 곧바로 “연결 실패”를 봅니다.
그래프에서는: 접속·점검 직후 폭증 · 접속 대기열 넘침 수(ListenOverflows), 접속 시도 수
확인할 곳: nstat -az의 TcpExtListenOverflows·TcpExtListenDrops 증가량을 보고, ss -ltn으로 리슨 소켓의 Recv-Q(accept를 기다리는 접속 수)와 Send-Q(backlog 한도)를 비교
이러면 맞음: 접속이 몰린 시각에 ListenOverflows가 늘고 리슨 소켓의 Recv-Q가 Send-Q 값에 붙어 있음
이러면 아님: ListenOverflows가 그대로면 이 원인이 아님. 연결은 맺어졌는데 로딩이 안 끝나면 “로그인 폭주와 N+1 쿼리”, 정확히 일정 인원에서 막히면 “파일 디스크립터 한도”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

listen(2) — Linux manual page Linux man-pages
listen의 backlog는 somaxconn을 넘으면 조용히 잘림, somaxconn 기본 4,096(5.4부터, 전에는 128), 대기열이 차면 요청을 무시해 클라이언트 재시도에 맡길 수 있음
IP Sysctl Linux kernel
tcp_syn_retries: 접속 요청(SYN)을 첫 재전송 대기 1초로 여러 번 다시 보냄, tcp_abort_on_overflow 기본 꺼짐(넘쳐도 거절 응답 없음), tcp_syncookies 기본 켜짐
listen function (winsock2.h) Microsoft
윈도우는 대기열이 가득 차면 클라이언트가 WSAECONNREFUSED 오류를 받음
SNMP counter Linux kernel
TcpExtListenOverflows: accept 대기열이 가득 차 접속 요청(SYN)을 버린 횟수, 이때 TcpExtListenDrops도 함께 증가
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트

파일 디스크립터 한도 File descriptor limit (ulimit)

ID so-fd · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

연결 하나마다 파일 디스크립터(fd, OS가 열린 파일·소켓에 붙이는 번호)가 필요한데, 한 프로세스가 열 수 있는 fd 수가 제한되어 있습니다.

왜 동접이 프로세스의 파일 디스크립터 한도에 도달 → 그러면 서버가 새 연결을 받지 못함(Too many open files). 로그·DB 연결 열기도 함께 실패 → 화면에서는 정확히 일정 인원부터 아무도 못 들어오는 접속 불가·무한 로딩

증상: 접속 불가·무한 로딩
요인: 손실
누가 겪나: 서버 전체
언제: 접속·점검 직후, 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 연결을 끝낼 때 소켓을 확실히 닫기(fd 누수 방지), accept가 EMFILE(fd 부족)로 실패하면 잠시 접속 받기를 멈추거나 미리 남겨 둔 예비 fd로 받아 바로 닫기(같은 접속 알림만 반복 처리하며 CPU를 낭비하지 않게).
인프라팀 할 일: ulimit·서비스 설정(systemd의 LimitNOFILE) 확인, 한도 근접 경보.
수치 감각: 리눅스는 서비스 설정을 따로 하지 않으면 한도가 1,024인 경우가 아직 많습니다. 게임 서버는 보통 수만~수십만으로 올립니다. 윈도우에는 이렇게 낮은 기본 한도가 없습니다.
그래프에서는: 한도에 닿아 평평해짐 · 프로세스의 열린 fd 수, 동시 접속 수
확인할 곳: pidstat -v로 게임 서버 프로세스의 fd-nr(열린 파일 디스크립터 수)를, /proc/PID/limits로 열린 파일 수 한도를 보고 서버 로그에서 accept 실패(EMFILE, Too many open files)를 찾음
이러면 맞음: fd 수가 한도 값에서 평평해지고 그 시각부터 accept가 EMFILE로 실패함
이러면 아님: fd 수가 한도에 한참 못 미치면 이 원인이 아님. 접속 요청이 커널에서 버려지면 “접속 대기열(backlog) 넘침”, 연결 추적 쪽이면 “서버 conntrack 테이블 포화”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 받지 못한 접속은 커널 접속 대기열(backlog)에 그대로 남아 있어, 서버 코드에 따라 “새 접속 있음” 알림을 계속 받으며 CPU를 낭비하기도 합니다.

출처 5건

systemd-system.conf(5) — Linux manual page systemd
서비스의 DefaultLimitNOFILE 기본값은 1024:524288(소프트 한도 1,024)
accept(2) — Linux manual page Linux man-pages
프로세스의 fd 한도에 닿으면 accept가 EMFILE로 실패
Maximum Number of Sockets Supported Microsoft
윈도우 Winsock은 소켓 수를 사용 가능한 메모리로만 제한
pidstat(1) — Linux manual page sysstat
-v의 fd-nr: 프로세스가 연 파일 디스크립터 수
proc_pid_limits(5) — Linux manual page Linux man-pages
/proc/PID/limits에 프로세스별 자원 한도의 소프트·하드 값

커널 소켓 버퍼 부족 Small socket buffers

ID so-sockbuf · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

송수신 버퍼가 작으면 버스트 트래픽이 몰릴 때 UDP로 받은 패킷은 버려지고, TCP 송신은 버퍼에 여유가 없어 막힙니다.

왜 SO_SNDBUF·SO_RCVBUF가 기본값이거나 너무 작음 → 그러면 버스트나 받는 스레드가 잠깐 멈춘 사이 UDP 수신 버퍼가 넘쳐 폐기, TCP는 송신 버퍼에 여유가 없어 대기 → 화면에서는 순간이동(UDP 손실) 또는 몰아치기(TCP 대기)

증상: 순간이동, 몰아치기
요인: 손실, 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 트래픽에 맞춘 버퍼 크기(SO_SNDBUF·SO_RCVBUF)를 코드에서 설정, TCP는 크기를 직접 정하면 리눅스의 자동 크기 조절이 꺼지니 주의, 너무 크게 잡으면 오래된 데이터가 버퍼에 쌓여 지연이 늘어나니 적당히, 받는 스레드가 멈추지 않게.
인프라팀 할 일: 커널 상한(rmem_max·wmem_max. 코드에서 정한 버퍼 크기도 이 값을 넘지 못함)과 기본값(rmem_default) 조정, 버퍼 넘침 카운터(RcvbufErrors) 감시.
수치 감각: 리눅스 UDP 수신 버퍼 기본값은 약 208KB입니다. 작은 패킷도 한 개가 커널 메모리를 실제 크기보다 훨씬 많이 차지해 수십~수백 개면 찹니다. 초당 10만 개를 받는 서버라면 받는 스레드가 몇 ms만 멈춰도 넘칩니다.
그래프에서는: 가끔 무작위로 튐 · UDP 수신 버퍼 넘침(UdpRcvbufErrors)
확인할 곳: nstat -az의 UdpRcvbufErrors 증가량과 ss -uamn의 skmem(rb는 수신 버퍼 크기, d는 소켓에 넣지 못하고 버린 패킷 수)을 보고 TCP는 ss -tm의 skmem에서 송신 대기 메모리(w)가 송신 버퍼 크기(tb)에 닿았는지 봄
이러면 맞음: 버스트나 받는 스레드가 멈춘 시각에 UdpRcvbufErrors(또는 소켓의 d)가 늘고, rb가 기본값(약 208KB) 근처. TCP는 w가 tb에 붙은 채 send가 막힘
이러면 아님: 카운터가 그대로인데 손실이 있으면 NIC 단계(“링 버퍼 부족”)나 네트워크 구간
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 6건

socket(7) — Linux manual page Linux man-pages
SO_RCVBUF·SO_SNDBUF 기본값은 rmem_default·wmem_default, 상한은 rmem_max·wmem_max, 설정값은 커널이 두 배로 잡음
include/net/sock.h (Linux v6.18) Linux kernel
기본 소켓 버퍼를 sk_buff 오버헤드를 포함한 256바이트 패킷 256개분(SKB_TRUESIZE(256)×256)으로 정의, 작은 프레임도 sk_buff+MTU만큼 계산됨(약 208KB는 x86-64 기준 계산값)
IP Sysctl Linux kernel
tcp_rmem·tcp_wmem: SO_RCVBUF·SO_SNDBUF를 직접 정하면 그 소켓의 자동 크기 조절이 꺼짐
net/ipv4/udp.c (Linux v6.12) Linux kernel
UDP 수신 대기열이 소켓 버퍼 크기를 넘으면 곧바로 버리고 RcvbufErrors를 올림
net/ipv4/proc.c (Linux v6.12) Linux kernel
nstat이 보여 주는 카운터 이름: Udp 그룹의 RcvbufErrors·SndbufErrors
ss(8) — Linux manual page iproute2
-m의 skmem: rb 수신 버퍼 크기, tb 송신 버퍼 크기, w 송신 대기 메모리, d 소켓에 넣기 전 버린 패킷 수

스레드 과다와 컨텍스트 스위칭 Thread oversubscription, context switching

ID so-context · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

코어보다 훨씬 많은 스레드를 돌리면 OS가 번갈아 실행시키는 데만 CPU를 씁니다.

왜 연결마다 스레드를 만드는 등 스레드가 수백~수천 개 → 그러면 컨텍스트 스위칭(실행 스레드 교체) 비용과 캐시 미스 증가 → 화면에서는 CPU는 바쁜데 처리량은 낮고 틱이 들쭉날쭉해 뚝뚝 끊김·슬로우모션

증상: 뚝뚝 끊김, 슬로우모션
요인: 정체, 지터
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 코어 수에 맞춘 스레드, 비동기 I/O(epoll·IOCP).
인프라팀 할 일: 컨텍스트 스위칭 횟수와 실행 대기 스레드 수(vmstat의 cs·r) 모니터링.
수치 감각: 컨텍스트 스위칭 한 번에 수 µs, 그 뒤 캐시 미스 비용까지 합치면 더 큽니다.
그래프에서는: 인원·부하를 따라 오름 · 초당 컨텍스트 스위칭 수, 실행 대기 스레드 수
확인할 곳: vmstat 1의 cs(초당 컨텍스트 스위칭)·r(실행 중이거나 CPU를 기다리는 수)을 코어 수와 비교하고, pidstat -w -t로 게임 서버 스레드별 자발적(cswch/s)·비자발적(nvcswch/s) 컨텍스트 스위칭을 봄
이러면 맞음: 동접이 늘 때 r이 코어 수보다 훨씬 크게 오르고 cs도 따라 치솟으며 비자발적 컨텍스트 스위칭이 많은 스레드가 수백 개
이러면 아님: r이 코어 수 이하로 머물면 이 원인이 아님. 자발적 스위칭만 많으면 스레드가 락·I/O를 기다리는 것(“락 경합”, “블로킹 I/O 구조”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

Quantifying The Cost of Context Switch (ExpCS 2007) ACM
컨텍스트 스위칭 직접 비용 약 3.8µs, 캐시 영향까지 합친 간접 비용은 수 µs~1,000µs 이상(측정 환경 기준)
vmstat(8) — Linux manual page procps-ng
cs(초당 컨텍스트 스위칭 수)와 r(실행 중이거나 실행을 기다리는 프로세스 수) 항목
I/O Completion Ports Microsoft
미리 만든 스레드 풀과 IOCP로 많은 비동기 I/O를 처리하고 동시에 도는 스레드 수를 CPU 동시성에 맞춤
pidstat(1) — Linux manual page sysstat
-w의 cswch/s는 자원을 기다리며 스스로 멈춘 자발적 컨텍스트 스위칭, nvcswch/s는 타임 슬라이스를 다 써서 강제로 바뀐 비자발적 컨텍스트 스위칭, -t로 스레드별

CPU 스틸 (가상 머신) CPU steal time

ID so-steal · 주 담당 인프라팀·서버 인프라 · 함께 외부·외부

물리 서버(하이퍼바이저)가 가상 머신의 CPU 시간을 잠시 다른 가상 머신에 넘기는 동안(CPU 스틸) 게임 서버가 멈춥니다.

왜 같은 호스트의 다른 가상 머신이 CPU를 많이 씀 → 그러면 내 가상 머신이 수 ms~수십 ms씩 실행 기회를 잃음 → 화면에서는 원인 모를 틱 시간 급증으로 뚝뚝 끊김·멈춤

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 서버 전체
언제: 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라 · 함께 외부·외부
인프라팀 할 일: steal 지표(top·vmstat의 st) 모니터링, 전용 코어·호스트, CPU 크레딧이 바닥나면 느려지는 버스트형 인스턴스 피하기, steal이 계속 높은 인스턴스는 중지 후 다시 시작해 다른 호스트로 옮기기.
외부 할 일: 클라우드 사업자에 steal이 계속 높은 호스트 신고.
그래프에서는: 가끔 무작위로 튐 · %steal, 서버 틱 시간
확인할 곳: mpstat -P ALL 1의 %steal을 서버 틱 시간과 같은 시간축에 놓고 봄
이러면 맞음: 틱이 튄 시각에 %steal이 함께 튀고 중지 후 다시 시작해 다른 호스트로 옮기면 줄어듦
이러면 아님: %steal이 0에 가까운데 틱이 튀면 게임 서버 안쪽 원인(“서버 GC 전체 멈춤”, “락 경합”). 컨테이너면 “컨테이너 CPU 스로틀링 (CFS 쿼터)”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

proc_stat(5) — Linux manual page Linux man-pages
steal: 가상화 환경에서 다른 운영체제가 실행되느라 빼앗긴 시간
Standard mode for burstable performance instances AWS
버스트형 인스턴스는 크레딧을 써서 기준 성능을 넘고 크레딧이 떨어지면 CPU 사용률이 기준 수준으로 낮아짐
How EC2 instance stop and start works AWS
인스턴스를 중지했다 시작하면 대부분 새 호스트로 옮겨짐
mpstat(1) — Linux manual page sysstat
%steal: 하이퍼바이저가 다른 가상 CPU를 돌리는 동안 이 가상 CPU가 어쩔 수 없이 기다린 시간 비율

컨테이너 CPU 스로틀링 (CFS 쿼터) Container CPU throttling (CFS quota)

ID so-cpu-quota · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

컨테이너에 CPU 한도를 걸면, 정해진 주기(보통 100ms) 안에 할당량을 다 쓴 순간 남은 시간 동안 강제로 멈춥니다(스로틀링).

왜 쿠버네티스 등에서 게임 서버 컨테이너에 CPU 한도(limit)를 걸어 둠 → 그러면 틱 계산이 몰린 순간 할당량을 다 써서 다음 주기까지 수십 ms 정지 → 화면에서는 평균 CPU는 낮은데 틱이 주기적으로 튀어 뚝뚝 끊김·슬로우모션

증상: 뚝뚝 끊김, 슬로우모션
요인: 정체, 지터
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 워커 스레드 수를 CPU 한도에 맞추기(런타임이 호스트 전체 코어 수만큼 스레드를 만들지 않게).
인프라팀 할 일: CPU 한도를 넉넉히 두거나 빼고 전용 코어 배정, 스로틀링된 횟수(nr_throttled) 감시.
수치 감각: 한도 2코어인 서버에서 스레드 8개가 동시에 일하면, 100ms 주기의 할당량을 25ms 만에 다 쓰고 75ms를 멈춥니다.
그래프에서는: 인원·부하를 따라 오름 · 스로틀링 횟수(nr_throttled), 서버 틱 시간
확인할 곳: 컨테이너 cgroup의 cpu.stat에서 nr_throttled·throttled_usec(cgroup v1은 nr_throttled·throttled_time) 증가량을 서버 틱 시간과 함께 봄
이러면 맞음: 평균 CPU 사용률은 한도보다 낮은데 nr_throttled·throttled_usec가 계속 늘고, 틱이 튄 시각과 겹침
이러면 아님: nr_throttled가 늘지 않으면 이 원인이 아님. 가상 머신 자체가 밀리면 “CPU 스틸 (가상 머신)”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

CFS Bandwidth Control Linux kernel
주기마다 받은 할당량을 다 쓰면 다음 주기까지 스레드가 멈춤(스로틀링), 기본 주기 100ms, nr_throttled 통계
Control Group v2 Linux kernel
cpu.max는 “$MAX $PERIOD”(할당량, 주기) 형식이고 기본값은 “max 100000”(100ms 주기)
Resource Management for Pods and Containers Kubernetes
컨테이너의 CPU limit은 커널이 CPU 스로틀링으로 강제하는 하드 한도

서버 전원 관리(C-state·주파수 조절)로 지연 튐 CPU power management latency (C-states, frequency scaling)

ID so-cstate · 주 담당 인프라팀·서버 인프라

쉬는 CPU 코어는 전기를 아끼려고 깊은 절전 상태(C-state)로 들어가고 주파수도 낮춥니다. 패킷이나 타이머가 오면 깨어나고 주파수를 올리는 데 시간이 걸려, 작은 패킷 처리에 지연이 더해집니다.

왜 OS의 주파수 조절 정책(governor)이나 BIOS 전원 설정이 깊은 C-state와 낮은 주파수를 허용 → 그러면 쉬던 코어가 깊은 절전 상태에서 깨어날 때마다 최대 수백 µs 늦고 주파수가 낮게 묶여 있으면 틱 계산 자체가 느려짐 → 화면에서는 대개 체감하기 어렵지만 서버 간 호출이 많으면 쌓여 한산할 때 오히려 응답이 늦는 입력 지연. 주파수가 낮게 묶이면 사람이 몰릴 때 틱이 밀려 슬로우모션

증상: 입력 지연, 슬로우모션
요인: 지연, 지터, 정체
누가 겪나: 서버 전체
언제: 항상, 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: BIOS 전원 설정을 성능 쪽으로, OS governor를 performance로(cpufreq의 scaling_governor), 지연에 민감한 서버는 깊은 C-state 제한(tuned latency-performance 프로필, PM QoS의 /dev/cpu_dma_latency, 커널 파라미터 intel_idle.max_cstate), 바꾼 뒤 같은 데이터센터 안 왕복 시간·틱 시간 지터와 전력 사용을 함께 비교.
수치 감각: 리눅스 6.12의 intel_idle 드라이버 표 기준으로 인텔 서버 CPU의 얕은 C1은 깨어나는 데 1~2µs, 깊은 C6는 133µs(Skylake-SP)~290µs(Sapphire Rapids)입니다. 한 번은 작지만 요청 하나가 서버 여러 대를 거치면 그만큼 쌓입니다. 커널은 예상 유휴 시간이 길수록 깊은 상태를 고르므로 패킷이 드문드문 오는 한산한 서버에서 더 자주 나타납니다. 범용 cpufreq의 powersave governor는 허용 범위의 가장 낮은 주파수로 고정합니다(intel_pstate의 같은 이름 알고리즘은 부하에 따라 조절).
그래프에서는: 처음부터 늘 높음 · 같은 데이터센터 안 왕복 시간, 코어 주파수
확인할 곳: cpupower monitor로 코어별 C-state에 머문 비율과 실제 주파수를 보고, /sys/devices/system/cpu/cpu0/cpuidle/ 아래 state마다 name·latency(깨어나는 데 걸리는 µs)·usage, cpufreq의 scaling_governor, tuned-adm active로 현재 프로필을 확인
이러면 맞음: 코어가 한산할 때 가장 깊은 C-state에 오래 머물거나 주파수가 최저 근처에 묶여 있고, performance governor·얕은 C-state로 바꾸면 작은 요청의 왕복 시간과 지터가 줄어듦
이러면 아님: 바꿔도 차이가 수십 µs 안쪽이면 이 원인은 무시해도 됨. ms 단위로 튀면 “CPU 스틸 (가상 머신)”이나 다른 층
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 베어메탈 IDC 서버는 BIOS(펌웨어)의 전원 설정과 OS 설정을 함께 봅니다. 클라우드에서는 일부 인스턴스 종류만 OS가 C-state·주파수를 바꿀 수 있고, AWS는 기본 설정이 최대 성능 쪽이라 대부분 그대로 두어도 됩니다. Red Hat 계열의 tuned latency-performance 프로필은 governor를 performance로 두고 PM QoS로 얕은 C-state만 쓰게 합니다. 절전을 끄면 전력 소비가 늘어나니 지연에 민감한 서버에만 적용합니다.

출처 7건

CPU Idle Time Management Linux kernel
절전 상태마다 깨어나는 시간(exit latency)과 최소 머무름 시간(target residency)이 있고, 예상 유휴 시간에 맞춰 깊은 상태를 고름, sysfs의 state별 latency·usage·time, PM QoS(/dev/cpu_dma_latency)와 intel_idle.max_cstate로 깊은 상태 제한
drivers/idle/intel_idle.c (Linux v6.12) Linux kernel
인텔 서버 CPU의 C-state별 깨어나는 시간: Skylake-SP C1 2µs·C1E 10µs·C6 133µs, Ice Lake C6 170µs, Sapphire Rapids C1 1µs·C6 290µs
CPU Performance Scaling Linux kernel
scaling_governor로 governor 확인·변경, performance는 허용 범위의 가장 높은 주파수, powersave는 가장 낮은 주파수를 요청
intel_pstate CPU Performance Scaling Driver Linux kernel
intel_pstate의 powersave 알고리즘은 범용 powersave governor와 다르게 부하에 따라 조절(schedutil·ondemand와 비슷)
Chapter 2. Getting started with TuneD Red Hat
latency-performance 프로필은 절전 기능을 끄고 governor를 performance로, PM QoS로 얕은 C-state만 쓰게 함, tuned-adm active로 현재 프로필 확인
tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel
cpupower monitor: 코어별 주파수와 절전 상태 통계
Processor state control for Amazon EC2 Linux instances AWS
일부 인스턴스 종류만 OS가 C-state·P-state를 제어할 수 있고 지연을 줄이려고 바꿀 수 있음, 기본 설정은 최대 성능이라 대부분의 작업에 알맞음, Graviton은 고정 주파수라 OS가 제어하지 않음

OOM 킬러 Out-of-memory killer

ID so-oom · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

리눅스는 메모리가 바닥나면 메모리를 가장 많이 쓰는 프로세스를 골라 강제로 죽입니다. 대개 게임 서버입니다.

왜 누수나 폭증으로 메모리 고갈, 또는 컨테이너 메모리 한도 도달 → 그러면 커널이 게임 서버 프로세스를 강제 종료 → 화면에서는 그 서버의 모두가 동시에 접속 끊김, 최근 진행 롤백 가능

증상: 접속 끊김, 씹힘·롤백
요인: 정체
누가 겪나: 서버 전체
언제: 오래 켜 둘수록, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 누수 수정, 메모리 사용 상한을 두고 가까워지면 저장 후 정상 종료하는 절차.
인프라팀 할 일: 메모리 경보, 컨테이너 메모리 한도를 실제 사용량에 맞게 설정, 먼저 죽일 순서 조정(oom_score_adj).
수치 감각: 커널 로그(dmesg)에 “Out of memory: Killed process”가 남고 쿠버네티스에서는 OOMKilled로 표시됩니다. 윈도우에는 OOM 킬러가 없고 메모리 할당이 실패하면서 서버가 오류로 죽는 경우가 많습니다.
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 메모리 사용량
확인할 곳: dmesg의 “Out of memory: Killed process” 기록, 쿠버네티스면 파드 상태의 OOMKilled, cgroup v2면 memory.events의 oom_kill 증가를 접속이 끊긴 시각과 맞춰 봄
이러면 맞음: 접속이 한꺼번에 끊긴 시각에 게임 서버 프로세스를 죽인 기록이 있고 그 직전까지 메모리 사용량이 한도로 올라감
이러면 아님: OOM 기록이 없는데 프로세스가 죽었으면 “서버 크래시”의 크래시 로그·코어 덤프를 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

mm/oom_kill.c (Linux v6.12) Linux kernel
메모리를 가장 많이 쓰는 프로세스가 가장 높은 점수를 받도록 계산(oom_score_adj 반영), 종료할 때 “Out of memory: Killed process …” 기록
Assign Memory Resources to Containers and Pods Kubernetes
컨테이너가 메모리 limit을 넘어 계속 쓰면 종료되고 상태가 OOMKilled로 표시됨
Pushing the Limits of Windows: Virtual Memory Microsoft
윈도우는 커밋 한도에 닿으면 메모리를 확정하는 할당이 실패하고 앱 오류나 시스템 장애로 이어질 수 있음
Control Group v2 Linux kernel
memory.events의 oom_kill: 이 cgroup에서 OOM 킬러가 죽인 프로세스 수

메모리 회수·컴팩션으로 인한 멈춤 Memory compaction / reclaim stalls (THP)

ID so-reclaim · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

OS가 큰 페이지(huge page)를 만들려고 메모리를 컴팩션하거나 여유 메모리를 회수하는 동안 프로세스가 멈춥니다.

왜 여유 메모리가 줄거나 큰 페이지 기능(THP)이 메모리 컴팩션 실행 → 그러면 메모리를 요청한 스레드가 회수·컴팩션이 끝날 때까지 대기 → 화면에서는 불규칙한 서버 멈춤(수 ms~수백 ms)

증상: 멈춤, 뚝뚝 끊김
요인: 정체
누가 겪나: 서버 전체
언제: 오래 켜 둘수록, 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 실행 중 큰 메모리 할당 줄이기(시작할 때 미리 확보해 재사용).
인프라팀 할 일: 큰 페이지(THP)는 필요한 곳에만 쓰게(madvise) 설정, 여유 메모리 기준 높이기(vm.min_free_kbytes 등).
그래프에서는: 가끔 무작위로 튐 · 서버 틱 시간, 메모리 PSI
확인할 곳: /proc/pressure/memory의 some·full(메모리를 기다리며 멈춘 시간 비율)과 /proc/vmstat의 compact_stall 증가량을 서버 틱 시간과 함께 보고, /sys/kernel/mm/transparent_hugepage/defrag 설정을 확인
이러면 맞음: 틱이 튄 시각에 메모리 PSI가 오르고 compact_stall이 늘어남. defrag가 always
이러면 아님: PSI와 compact_stall이 그대로면 이 원인이 아님. 스왑 사용이 늘면 “스왑”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Transparent Hugepage Support Linux kernel
defrag=always면 THP 할당에 실패할 때 그 자리에서 메모리 회수·컴팩션을 하며 멈춤, madvise는 요청한 영역만 그렇게 함
Documentation for /proc/sys/vm/ Linux kernel
min_free_kbytes: 커널이 남겨 둘 최소 여유 메모리(워터마크) 기준
PSI - Pressure Stall Information Linux kernel
/proc/pressure/memory의 some(일부 작업이 메모리를 기다리며 멈춘 시간 비율)·full(모든 작업이 멈춘 시간 비율)

시스템 시계 점프 (NTP 스텝) Wall-clock jump (NTP step)

ID so-timejump · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

서버 시계가 한 번에 몇 초 앞뒤로 조정되면 시스템 시계에 의존하는 타이머가 한꺼번에 발동하거나 멈춥니다.

왜 시간 동기화가 시계를 한 번에 크게 조정 → 그러면 타이머가 몰아서 발동하거나 멈추고 타임아웃이 잘못 판정됨 → 화면에서는 버프·쿨타임 이상, 일제히 접속 끊김, 몰아치기

증상: 몰아치기, 접속 끊김, 씹힘·롤백
요인: 정체
누가 겪나: 서버 전체
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 경과 시간·타임아웃·쿨타임은 뛰거나 되돌아가지 않는 단조 시계(monotonic clock)로 계산, wall clock은 표시·기록용으로만.
인프라팀 할 일: 시계는 서서히 조정(chrony의 makestep은 켜진 직후에만), 시간 동기화 상태(시계 차이) 모니터링.
수치 감각: ntpd는 차이가 0.128초를 넘으면 한 번에 맞추고 그보다 작으면 1초 차이를 없애는 데 30분 남짓 걸리는 속도로 서서히 맞춥니다. 요즘 많이 쓰는 chrony는 권장 설정(makestep)에서 켜진 직후 몇 번만 한 번에 맞추고, 그 뒤에는 서서히 맞춥니다. 가상 머신이 잠깐 멈췄다 깨어날 때도 시계가 뜁니다.
그래프에서는: 가끔 무작위로 튐 · 타이머 발동 수·끊김 수, 시계 조정 기록
확인할 곳: 시간 동기화 서비스의 로그에서 시계를 한 번에 크게 조정한 기록을 찾아 이상이 난 시각과 맞춰 봄. chrony는 logchange에 정한 값(기본 1초)보다 크게 조정하면 syslog에 남김
이러면 맞음: 버프·쿨타임 이상, 일제히 접속 끊김, 몰아치기가 난 시각에 시계 조정 기록이 있고 조정 폭이 이상의 크기와 비슷함
이러면 아님: 시계 조정 기록이 없으면 이 원인이 아님. 가상 머신이면 멈췄다 깨어난 경우(“클라우드 호스트 점검·라이브 마이그레이션”)도 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

ntpd - Network Time Protocol (NTP) daemon Network Time Foundation
차이가 스텝 임계값 128ms를 넘으면 한 번에 맞추고 작으면 서서히 맞춤, 초당 0.5ms씩이라 1초를 맞추는 데 2,000초(약 33분) 걸림
chrony – Frequently Asked Questions chrony
makestep 1 3처럼 시작 직후 몇 번만 스텝을 허용하는 것이 권장, 멈췄다 재개한 가상 머신은 시각이 틀어진 채 깨어날 수 있음
clock_gettime(2) — Linux manual page Linux man-pages
CLOCK_MONOTONIC은 시스템 시계의 불연속 점프에 영향받지 않고 뒤로 가지 않음
chrony.conf(5) chrony
logchange: 이 값(기본 1초)보다 크게 시계를 조정하면 syslog에 기록

예약 작업 Cron jobs (log rotation, backup, scans)

ID so-cron · 주 담당 인프라팀·서버 인프라

매일 같은 시각에 도는 로그 압축·백업·보안 검사가 CPU와 디스크를 차지합니다.

왜 정해진 시각에 OS 작업이 실행 → 그러면 CPU·디스크를 게임 서버와 나눠 씀 → 화면에서는 매일 새벽 4시처럼 정해진 시각에 뚝뚝 끊김·슬로우모션

증상: 뚝뚝 끊김, 슬로우모션
요인: 정체
누가 겪나: 서버 전체
언제: 일정한 주기로
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: 작업 시각 분산, 우선순위 낮추기(nice, ionice), 게임 서버와 분리(별도 서버에서 실행).
그래프에서는: 일정 주기로 튐 · CPU 사용률, 디스크 대기열, 서버 틱 시간
확인할 곳: crontab과 systemctl list-timers로 예약 작업의 실행 시각을 모으고, 틱이 튄 시각에 pidstat -u -d로 어떤 프로세스가 CPU·디스크를 쓰는지 봄
이러면 맞음: 틱이 매일(또는 매시) 같은 시각에 튀고 그 시각에 예약 작업 프로세스가 CPU·디스크를 차지함
이러면 아님: 튀는 시각이 매일 같은 시각과 맞지 않으면 이 원인이 아님. 몇 초·몇 분 간격으로 튀면 “서버 GC 전체 멈춤”, “타이머 동시 발동 몰림”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

ionice(1) — Linux manual page util-linux
idle 클래스 작업은 다른 프로그램이 디스크를 쓰지 않을 때만 I/O를 받음
systemd.timer(5) — Linux manual page systemd
RandomizedDelaySec로 예약 작업 시각을 무작위로 늦춰 부하 몰림을 줄임
systemctl(1) — Linux manual page systemd
list-timers: 타이머 유닛을 다음 실행 시각 순으로 보여 줌
pidstat(1) — Linux manual page sysstat
-u는 CPU, -d는 디스크 I/O를 프로세스별로 보여 줌

OS·커널·드라이버·펌웨어 업데이트 뒤 성능 변화 Performance regression after OS / kernel / driver / firmware update

ID so-os-update · 주 담당 인프라팀·서버 인프라

게임 코드는 그대로인데 서버 OS·커널·드라이버·펌웨어를 업데이트한 뒤부터 서버가 느려집니다. 업데이트로 기본값, 스케줄러, CPU 취약점 완화(mitigations), 드라이버 동작이 바뀌기도 합니다.

왜 정기 보안 패치나 새 서버 이미지로 커널·드라이버·펌웨어가 바뀜 → 그러면 기본값·스케줄러가 바뀌거나 새 취약점 완화가 켜져, 같은 일에 CPU 시간이 더 들고 스레드가 CPU를 배정받는 순서가 달라짐 → 화면에서는 잘되던 서버가 업데이트한 날부터 늘 조금씩 느려져 입력 지연, 사람이 몰리면 뚝뚝 끊김·슬로우모션

증상: 입력 지연, 뚝뚝 끊김, 슬로우모션
요인: 지연, 정체, 지터
누가 겪나: 서버 전체
언제: 항상, 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: 업데이트는 일부 서버에 먼저 적용하고 틱 시간·지연·CPU 사용률을 이전 버전과 비교한 뒤 넓히기, 게임 패치와 다른 날 배포, 업데이트 전후 커널·드라이버·펌웨어 버전과 주요 sysctl 값 기록, 문제가 생기면 이전 커널로 부팅해 확인, 완화를 끄는 설정(mitigations=off)은 보안 위험을 따져 결정.
수치 감각: 커널 버전이 바뀌면 기본 동작도 바뀝니다. 예를 들어 리눅스는 6.6부터 스케줄러를 CFS에서 EEVDF로 옮겨 가기 시작했고, 접속 대기열 상한(somaxconn) 기본값도 5.4부터 128에서 4,096으로 바뀌었습니다. CPU 취약점 완화는 커널에서 프로그램으로 돌아갈 때(시스템 콜을 마칠 때마다), 컨텍스트 스위칭·가상 머신 전환 때 CPU 내부 버퍼를 비우는 등 일을 더합니다. 패킷마다 시스템 콜을 부르는 네트워크 서버일수록 영향을 더 받습니다. 일부 취약점은 완전히 막으려면 SMT(코어 하나를 스레드 두 개처럼 쓰는 기능)를 꺼야 하고, SMT를 끄면 작업에 따라 성능이 크게 떨어집니다. 커널 파라미터 mitigations=off는 이 완화를 모두 꺼 성능을 되찾지만 취약점에 노출됩니다.
그래프에서는: 어느 순간부터 계단처럼 올라감 · 서버 틱 시간, CPU 사용률, 같은 부하의 지연
확인할 곳: 패키지 관리자의 업데이트 기록과 재부팅 시각, uname -r로 본 커널 버전, ethtool -i로 본 NIC 드라이버 정보를 지연이 오른 시각과 맞춰 봄. 업데이트한 서버와 안 한 서버를 같은 부하에서 mpstat·pidstat로 비교하고, /sys/devices/system/cpu/vulnerabilities/의 완화 상태도 비교
이러면 맞음: 지연·CPU 사용률이 업데이트 뒤 재부팅한 시각부터 한 단계 올라 그대로 머물고, 같은 부하에서 업데이트한 서버만 높음. 이전 커널·드라이버로 부팅하면 돌아옴
이러면 아님: 업데이트한 서버와 안 한 서버가 같은 부하에서 똑같이 느리면 이 원인이 아님. 같은 날 게임 패치도 배포했고 유저당 패킷 수·크기가 달라졌으면 “패치로 트래픽 패턴이 바뀜”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 완화 상태는 /sys/devices/system/cpu/vulnerabilities/ 아래 파일에서 확인합니다. 기본값(mitigations=auto)은 SMT를 켜 둔 채 완화하지만 auto,nosmt로 두면 취약한 CPU에서 SMT를 꺼서 커널을 올린 뒤 논리 코어 수가 절반으로 줄 수 있습니다. 게임 패치와 같은 날 OS를 업데이트하면 원인을 가리기 어려우니 따로 배포합니다.

출처 6건

The kernel’s command-line parameters Linux kernel
mitigations=: off는 CPU 취약점 완화를 모두 꺼 성능을 높이지만 취약점에 노출, 기본 auto는 SMT를 켠 채 완화, auto,nosmt는 필요하면 SMT를 끔
MDS - Microarchitectural Data Sampling Linux kernel
완화는 커널에서 사용자 공간으로 돌아갈 때와 가상 머신에 들어갈 때 CPU 버퍼를 비움, /sys/devices/system/cpu/vulnerabilities/ 아래 파일로 취약점·완화 상태 확인, 완전히 막으려면 SMT를 꺼야 하는 CPU가 많고 SMT를 끄면 작업에 따라 성능 영향이 큼
Spectre Side Channels Linux kernel
완화하려고 컨텍스트 스위칭·가상 머신 전환 때 분기 예측 버퍼를 비우고 강한 완화는 모든 프로그램에 오버헤드를 더함
EEVDF Scheduler Linux kernel
리눅스는 6.6부터 CFS에서 EEVDF 스케줄러로 옮겨 가기 시작
listen(2) — Linux manual page Linux man-pages
somaxconn 기본값이 리눅스 5.4부터 128에서 4,096으로 바뀜
ethtool(8) — Linux manual page ethtool
ethtool -i로 네트워크 장치의 드라이버 정보 조회

서버 conntrack 테이블 포화 conntrack table full

ID so-conntrack · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발

리눅스 방화벽이 모든 연결을 기록하는 연결 추적(conntrack) 테이블이 한도에 닿으면 새 패킷을 버립니다.

왜 접속 폭주, 짧은 연결 반복으로 연결 기록 증가 → 그러면 테이블이 가득 차 새 연결과 일부 패킷 폐기 → 화면에서는 접속 불가, 원인 모를 손실로 순간이동

증상: 접속 불가·무한 로딩, 순간이동
요인: 손실
누가 겪나: 서버 전체
언제: 접속·점검 직후, 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 짧은 연결 줄이기(서버 간 호출은 연결 재사용). 클라이언트: 접속이 실패하거나 끊기면 재시도 간격을 늘려 가며 무작위로 분산.
인프라팀 할 일: 테이블 크기(nf_conntrack_max) 늘리기, 게임 포트는 추적 제외(raw 테이블의 NOTRACK), 사용량 경보.
수치 감각: 기본 한도는 서버 메모리에 따라 약 6만~26만 개입니다. 넘치면 커널 로그에 “nf_conntrack: table full, dropping packet”이 찍힙니다.
그래프에서는: 한도에 닿아 평평해짐 · conntrack 항목 수(nf_conntrack_count)
확인할 곳: sysctl의 net.netfilter.nf_conntrack_count(현재 항목 수)를 nf_conntrack_max와 같은 그래프에 놓고, dmesg에서 “nf_conntrack: table full, dropping packet”을 찾음
이러면 맞음: nf_conntrack_count가 max에서 평평해지고 그 시각부터 커널 로그에 table full이 찍힘
이러면 아님: 항목 수가 max에 한참 못 미치면 이 원인이 아님. AWS 인스턴스 자체의 연결 추적 한도는 “클라우드 PPS 한도 초과”의 conntrack_allowance_exceeded로 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Netfilter Conntrack Sysfs variables Linux kernel
nf_conntrack_max 기본값은 해시 버킷 수(nf_conntrack_buckets)와 같고, 버킷 수는 메모리 크기로 정해짐
net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
기본 크기는 메모리 1GB 초과면 65,536, 4GB 초과(64비트)면 262,144, 가득 차면 “nf_conntrack: table full, dropping packet”을 남기고 버림
iptables-extensions(8) — Linux manual page netfilter
raw 테이블의 CT --notrack으로 연결 추적 제외

서버 간 연결의 임시 포트 고갈 Ephemeral port exhaustion (TIME_WAIT)

ID so-ports · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

게임 서버가 DB나 다른 서버에 연결을 짧게 자주 맺고 끊으면, 끊긴 연결이 한동안 포트를 점유해 새 연결을 못 엽니다.

왜 요청마다 새 연결을 열고 닫음 → 그러면 먼저 닫은 쪽이 약 60초(리눅스) 동안 포트를 점유해(TIME_WAIT) 쓸 포트가 바닥 → 화면에서는 내부 요청 실패로 저장 실패·기능 오류

증상: 씹힘·롤백, 접속 불가·무한 로딩
요인: 손실
누가 겪나: 서버 전체, 특정 기능만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 연결 재사용(커넥션 풀), 요청마다 연결을 새로 열고 닫지 않게.
인프라팀 할 일: 포트 범위 확장(ip_local_port_range), 나가는 연결의 TIME_WAIT 재사용(리눅스 tcp_tw_reuse) 검토, TIME_WAIT 수 감시.
수치 감각: 리눅스 기본 포트 범위(32768~60999)는 약 2만 8천 개. 같은 상대 주소로 1초에 470번 넘게 새로 연결하면 바닥납니다. 윈도우는 기본 포트가 약 1만 6천 개(49152~65535)이고 TIME_WAIT도 더 길어 더 빨리 바닥납니다.
그래프에서는: 한도에 닿아 평평해짐 · TIME_WAIT 소켓 수, 내부 연결 실패 수
확인할 곳: ss -tan state time-wait로 TIME_WAIT 소켓을 상대 주소별로 세고, 게임 서버 로그에서 connect 실패(EADDRNOTAVAIL)를 찾음
이러면 맞음: 같은 상대(DB 등)로 가는 TIME_WAIT가 임시 포트 범위(기본 약 2만 8천 개) 근처에서 평평해지고, connect가 EADDRNOTAVAIL로 실패함
이러면 아님: TIME_WAIT가 적은데 외부로 나가는 연결만 실패하면 “클라우드 NAT 게이트웨이 연결·포트 한도”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 리눅스의 TIME_WAIT 60초는 커널에 고정된 값입니다. 이름이 비슷한 tcp_fin_timeout을 줄여도 TIME_WAIT는 짧아지지 않습니다.

출처 5건

IP Sysctl Linux kernel
ip_local_port_range 기본 32768~60999, tcp_tw_reuse, tcp_fin_timeout은 FIN_WAIT_2 상태 유지 시간
include/net/tcp.h (Linux v6.12) Linux kernel
TCP_TIMEWAIT_LEN(60*HZ): TIME_WAIT 약 60초는 커널 상수
TCP/IP port exhaustion troubleshooting Microsoft
윈도우 동적 포트 기본 49152~65535, 닫힌 연결은 기본 4분 동안 TIME_WAIT로 포트를 잡고 있음
ss(8) — Linux manual page iproute2
상태 필터 state time-wait로 TIME_WAIT 소켓만 골라 봄
connect(2) — Linux manual page Linux man-pages
EADDRNOTAVAIL: 임시 포트 범위의 포트가 모두 쓰이는 중이라 연결을 열지 못함

L8 소켓과 프로토콜

TCP HOL 블로킹 Head-of-line blocking

ID sk-hol · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

TCP는 순서를 지키려고 잃어버린 패킷 하나를 다시 받을 때까지 뒤에 도착한 패킷을 게임에 넘기지 않습니다.

왜 패킷 하나가 사라짐 → 그러면 뒤 패킷들은 도착했지만 수신 버퍼에서 대기 → 화면에서는 멈췄다가 한꺼번에 풀리며 몰아치기

증상: 멈춤, 몰아치기
요인: 손실, 정체
누가 겪나: 나만
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 실시간 위치는 UDP, 꼭 필요한 것만 신뢰성 전송, 스트림 여러 개로 나누기. 클라이언트: 서버와 같은 방식(UDP, 채널 분리)으로 네트워크 처리 변경.
수치 감각: 패킷 하나를 잃으면 최소 왕복 시간 + α, 재전송까지 잃으면 수백 ms~수 초 멈춥니다.
그래프에서는: 끊겼다가 몰아서 · 연결별 수신량, 재전송 수
확인할 곳: 서버 쪽 패킷 캡처(tcpdump·Wireshark)로 그 유저 연결에서 재전송 패킷과 그 앞뒤의 공백을 보고, 서버 전체는 nstat -az의 TcpRetransSegs 증가량을 봄
이러면 맞음: 멈춘 구간이 패킷 하나의 재전송으로 시작하고 재전송 패킷이 도착한 직후 밀린 데이터가 한꺼번에 처리됨(수신량이 0이다가 몰림)
이러면 아님: UDP로 통신하는 게임이면 해당 없음. 재전송이 없는데 멈추면 서버 틱 쪽(“틱 예산 초과”)을 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

RFC 9293: Transmission Control Protocol (TCP) IETF
TCP는 신뢰성 있는, 순서를 지키는 바이트 스트림 서비스
RFC 5681: TCP Congestion Control IETF
중복 ACK 3개로 손실을 감지해 빠른 재전송, 그렇지 않으면 재전송 타이머를 기다림
RFC 6298: Computing TCP's Retransmission Timer IETF
재전송 타이머가 만료될 때마다 두 배로 늘리는 백오프
net/ipv4/proc.c (Linux v6.12) Linux kernel
nstat이 보여 주는 카운터 이름: Tcp 그룹의 RetransSegs(재전송한 세그먼트 수)

TCP RTO와 지수 백오프 RTO and exponential backoff

ID sk-rto · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

재전송이 또 실패할 때마다 기다리는 시간이 두 배로 늘어, 짧은 회선 끊김이 긴 멈춤이 됩니다.

왜 회선이 잠깐 끊겨 재전송도 연달아 실패 → 그러면 다음 시도까지 0.3 → 0.6 → 1.2 → 2.4초처럼 두 배씩 늘어남(핑 100ms 기준) → 화면에서는 회선은 1초 끊겼는데 게임은 2초 넘게 멈춤. 더 길게 끊기면 결국 접속 끊김

증상: 멈춤, 접속 끊김
요인: 손실, 정체
누가 겪나: 나만
언제: 가끔 무작위로, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리(TCP_USER_TIMEOUT으로 포기 시점 줄이기), 세션 토큰으로 이어 받기, 신뢰성 UDP. 클라이언트: 짧은 간격으로 하트비트를 보내고 응답이 끊기면 TCP 재전송을 기다리지 말고 빨리 재접속.
수치 감각: 리눅스 RTO(재전송 대기 시간)는 “핑 + 200ms”가 최소이고 연결을 맺을 때는 1초부터 시작합니다. 기본 설정(tcp_retries2=15)이면 재전송이 계속 실패해도 약 15분 뒤에야 연결을 포기합니다.
그래프에서는: 끊겼다가 몰아서 · 연결별 RTO·backoff, RTO 만료 수
확인할 곳: 멈춘 연결을 ss -ti로 보고 rto(재전송 대기 ms)와 backoff(연속 만료 횟수)를, 서버 전체는 nstat -az의 TcpExtTCPTimeouts(재전송 타이머 만료 횟수) 증가량을 봄
이러면 맞음: 멈춘 연결의 backoff가 1 이상이고 rto가 초 단위로 커져 있으며 그 시각 TCPTimeouts가 늘어남
이러면 아님: 재전송이 빠른 재전송으로 끝나고 RTO 만료가 없으면 멈춤이 짧음. 그때는 “TCP HOL 블로킹”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 6건

RFC 6298: Computing TCP's Retransmission Timer IETF
첫 RTO 1초, 타이머가 만료될 때마다 RTO를 두 배로(지수 백오프)
net/ipv4/tcp_input.c (Linux v6.12) Linux kernel
리눅스 RTO = 평활 RTT + RTT 변동값이고 변동값의 하한이 tcp_rto_min(200ms)이라 RTO는 RTT+200ms 이상
IP Sysctl Linux kernel
tcp_rto_min_us 기본 200ms, 접속 요청의 첫 RTO 1초, tcp_retries2=15면 포기까지 최소 924.6초(약 15분)
ss(8) — Linux manual page iproute2
-i의 rto(재전송 타이머, ms)와 backoff(지수 백오프 횟수)
net/ipv4/proc.c (Linux v6.12) Linux kernel
nstat이 보여 주는 카운터 이름: TcpExt 그룹의 TCPTimeouts
net/ipv4/tcp_timer.c (Linux v6.12) Linux kernel
재전송 타이머가 만료될 때마다 TCPTimeouts를 올리고 backoff를 하나 늘리며 RTO를 두 배로(최대값까지) 늘림

Nagle 알고리즘 + 지연 ACK Nagle + delayed ACK (TCP_NODELAY off)

ID sk-nagle · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

작은 패킷을 모아 보내는 Nagle 알고리즘과 ACK를 늦게 보내는 지연 ACK가 맞물려, 메시지를 나눠 쓸 때마다 40~200ms씩 지연됩니다.

왜 TCP_NODELAY를 켜지 않은 채 작은 메시지를 나눠 씀 → 그러면 보내는 쪽은 ACK를 기다리고 받는 쪽은 ACK를 늦게 보냄 → 화면에서는 회선 핑은 낮은데 모든 행동이 일정하게 굼뜬 입력 지연

증상: 입력 지연
요인: 지연
누가 겪나: 서버 전체, 나만
언제: 항상, 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: TCP_NODELAY 켜기, 한 틱 동안의 메시지를 모아 한 번에 쓰기, 받는 쪽 지연 ACK를 끄는 방법(리눅스 TCP_QUICKACK은 잠깐만 유지, 윈도우는 PC마다 레지스트리 수정)은 게임이 확실히 통제할 수 없으니 기대지 않기. 클라이언트: TCP_NODELAY 켜기, 한 프레임 동안의 메시지를 모아 한 번에 쓰기.
수치 감각: 지연 ACK는 리눅스가 보통 40ms(상황에 따라 최대 200ms)입니다. 윈도우는 예전 버전이 200ms였고 요즘 버전은 40ms입니다(윈도우 서버 2019 기본 템플릿 40ms). 지연 ACK는 받는 쪽 OS가 정하므로, 서버가 Nagle을 켠 채 메시지를 나눠 보내면 받는 PC에 따라 40~200ms씩 지연될 수 있습니다.
그래프에서는: 처음부터 늘 높음 · 행동 응답 시간(게임 안 RTT)
확인할 곳: 서버 쪽 패킷 캡처(tcpdump·Wireshark)에서 요청·응답 사이의 간격을 보고, 서버·클라이언트 코드가 TCP_NODELAY를 켜는지 확인
이러면 맞음: 회선 핑은 낮은데 작은 패킷 사이에 40ms(윈도우 예전 버전은 200ms) 안팎의 공백이 반복되고, 그 공백은 상대의 ACK가 온 직후 끝남. TCP_NODELAY를 켜면 사라짐
이러면 아님: 응답 간격이 회선 핑과 비슷하면 이 원인이 아님. 게임 서버가 응답을 늦게 만들면 서버 처리 쪽(“메시지 큐 적체”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

RFC 9293: Transmission Control Protocol (TCP) IETF
Nagle은 ACK를 못 받은 데이터가 있으면 작은 데이터를 모아 둠, 연결마다 끌 수 있어야 함, 지연 ACK는 0.5초 미만, 둘이 맞물리는 문제
include/net/tcp.h (Linux v6.12) Linux kernel
리눅스 지연 ACK 최소 TCP_DELACK_MIN(HZ/25 = 40ms), 최대 TCP_DELACK_MAX(HZ/5 = 200ms)
TCP improvements in the Windows network stack (IETF 98 TCPM) Microsoft
윈도우 기본 지연 ACK 타임아웃을 40ms로 바꿈(2017년 발표)
TCP Templates for Windows Server 2019 – How to tune your Windows Server Transports (Advanced users only 😉) Microsoft
서버 2019 템플릿 DelayedAckTimeout 40ms, MaxSynRetransmissions 2, InitialRto 3000ms
Design issues - Sending small data segments over TCP with Winsock Microsoft
예전 윈도우 TCP는 데이터를 받으면 200ms 지연 ACK 타이머를 걸고, Nagle은 기본으로 켜져 있어 작은 패킷이 ACK를 기다림, TCP_NODELAY로 해결

느린 클라이언트로 인한 블로킹 전송 Blocking send on a full socket

ID sk-block-send · 주 담당 게임개발팀·서버 개발

회선이 느린 한 명의 송신 버퍼가 가득 찼는데 블로킹 방식(버퍼에 여유가 생길 때까지 호출이 반환되지 않는 전송)으로 보내면, 서버 스레드가 그 한 명을 기다립니다.

왜 느린 클라이언트의 송신 버퍼가 가득 → 그러면 블로킹 전송이라 서버 스레드가 버퍼에 여유가 생길 때까지 대기 → 화면에서는 그 스레드가 맡은 모두가 멈춤·슬로우모션

증상: 멈춤, 슬로우모션
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 가끔 무작위로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 논블로킹 전송, 클라이언트별 송신 대기열 상한, 오래된 업데이트 버리기.
그래프에서는: 가끔 무작위로 튐 · 서버 틱 시간, 연결별 Send-Q
확인할 곳: ss -tn으로 연결별 Send-Q(ACK를 받지 못했거나 아직 못 보낸 바이트)가 송신 버퍼만큼 찬 연결을 찾고, 틱이 튄 순간 게임 서버의 스레드 덤프(스택)에서 send 호출에 멈춘 스레드가 있는지 봄
이러면 맞음: Send-Q가 가득 찬 느린 연결이 있을 때 그 연결을 맡은 스레드가 send에서 멈춰 있고, 같은 스레드가 맡은 사람들만 함께 멈춤
이러면 아님: 멈춘 스레드가 send 밖(락, DB 호출)에서 기다리면 “락 경합”, “게임 스레드의 동기 호출”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

send(2) — Linux manual page Linux man-pages
송신 버퍼에 자리가 없으면 send()가 블록되고 논블로킹 모드면 EAGAIN으로 바로 돌아옴
send function (winsock2.h) Microsoft
Winsock도 버퍼 공간이 없으면 논블로킹 모드가 아닌 한 send가 블록
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트

느린 클라이언트(slow consumer) 처리 정책 Slow-consumer policy

ID sk-slow-client · 주 담당 게임개발팀·서버 개발

보낼 게 계속 쌓이는 클라이언트에게 서버가 오래된 업데이트를 버리거나 연결을 끊습니다.

왜 클라이언트의 회선이 서버가 보내는 양을 못 따라감 → 그러면 서버가 오래된 업데이트를 버리거나 한도 초과 시 연결 해제 → 화면에서는 그 사람만 순간이동 또는 접속 끊김

증상: 순간이동, 접속 끊김
요인: 손실
누가 겪나: 나만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 보내는 양 줄이기(거리별 갱신 빈도), 품질 낮춰 계속 보내기, 커널에 쌓아 두는 양 줄이기(리눅스 TCP_NOTSENT_LOWAT).
수치 감각: 송신 버퍼가 256KB면 30KB/s 회선에서는 8초 넘게 밀린 데이터가 쌓입니다. 리눅스는 이 버퍼를 자동으로 수 MB까지 키우기도 합니다.
그래프에서는: 일부만 높음 · 연결별 Send-Q, 클라이언트별 버린 업데이트 수
확인할 곳: 게임 서버가 남기는 클라이언트별 송신 대기열 길이·버린 업데이트 수·끊김 사유를 보고, 서버에서 ss -tni로 그 연결의 Send-Q와 cwnd를 함께 확인
이러면 맞음: 튀거나 끊긴 사람의 연결만 Send-Q가 계속 차 있고 게임 로그에 그 사람의 업데이트 폐기나 송신 대기열 초과로 인한 끊김이 기록됨
이러면 아님: Send-Q가 비어 있는데 순간이동하면 서버 송신 쪽 문제가 아님. 그 사람의 회선 손실(“무선 구간 손실”)이나 화면 보간 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

IP Sysctl Linux kernel
tcp_wmem: 자동 조절되는 송신 버퍼 최대치 기본 64KB~4MB(메모리에 따라), tcp_notsent_lowat·TCP_NOTSENT_LOWAT로 아직 안 보낸 데이터 양 제한
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트

keepalive 기본값 2시간 TCP keepalive defaults

ID sk-keepalive · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·서버 인프라

상대가 종료 신호 없이 사라지면 TCP는 한참 뒤에야 감지합니다. keepalive(유휴 연결이 살아 있는지 확인하는 TCP 기능)는 기본으로 꺼져 있고, 켜도 2시간 동안 유휴 상태여야 확인을 시작합니다.

왜 클라이언트가 전원 꺼짐·회선 끊김으로 종료 신호 없이 사라짐 → 그러면 서버는 연결이 살아 있다고 간주(keepalive 기본 7,200초. 보내던 데이터가 있으면 재전송 포기까지 약 15분) → 화면에서는 유령 캐릭터가 남고 재접속하면 “이미 접속 중” 오류

증상: 접속 불가·무한 로딩, 안 보임·유령 개체
요인: 손실
누가 겪나: 나만
언제: 가만히 있다가, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·서버 인프라
게임개발팀 할 일: 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리(TCP_KEEPIDLE·TCP_USER_TIMEOUT 조정), 재접속하면 세션 토큰으로 기존 세션을 교체해 이어 받기. 클라이언트: 게임 수준 하트비트를 수 초~수십 초 간격(가장 짧은 유휴 타임아웃의 절반 이하)으로 보내기, 끊기면 자동 재접속.
인프라팀 할 일: 코드가 따로 정하지 않는 소켓이 따르는 커널 기본값(tcp_keepalive_time 등) 낮추기(SO_KEEPALIVE를 켠 소켓에만 적용).
수치 감각: 리눅스 기본값은 7,200초 유휴 상태면 확인을 시작해 75초 간격으로 프로브를 9번 보내고, 끝까지 응답이 없으면 연결을 끊습니다. 합치면 약 2시간 11분입니다. 윈도우도 기본으로 2시간 유휴 상태여야 확인을 시작합니다.
그래프에서는: 일부만 높음 · 연결별 마지막 수신 뒤 경과 시간
확인할 곳: ss -tnoi로 연결별 lastrcv(마지막 수신 뒤 경과 ms)와 keepalive 타이머(timer:(keepalive,…))를 보고, 게임 서버의 “이미 접속 중” 거절 기록과 맞춰 봄
이러면 맞음: lastrcv가 수 분~수 시간인 ESTABLISHED 연결이 남아 있고 그 계정의 재접속이 “이미 접속 중”으로 거절됨
이러면 아님: 오래 조용한 연결이 없는데 “이미 접속 중”이 나오면 게임 서버의 세션 정리 코드 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

tcp(7) — Linux manual page Linux man-pages
7,200초 유휴 뒤 75초 간격 프로브 9번(약 11분 추가), SO_KEEPALIVE를 켠 소켓에만 적용, TCP_KEEPIDLE·TCP_USER_TIMEOUT
RFC 9293: Transmission Control Protocol (TCP) IETF
keepalive는 기본으로 꺼져 있어야 하고 유휴 간격 기본값은 2시간 이상
SO_KEEPALIVE socket option Microsoft
윈도우 TCP keepalive 기본 타임아웃 2시간
ss(8) — Linux manual page iproute2
-i의 lastrcv(마지막 수신 뒤 경과 ms), -o의 timer:(keepalive,…)

UDP 패킷의 IP 단편화 IP fragmentation of large UDP

ID sk-fragment · 주 담당 게임개발팀·서버 개발

MTU(한 번에 보낼 수 있는 크기)를 넘는 UDP 패킷은 IP 계층에서 단편화되고, 프래그먼트 하나만 잃어도 전체가 버려집니다.

왜 사람 많은 곳의 스냅샷이 1,500바이트를 넘음 → 그러면 여러 프래그먼트로 나뉘어 전송, 하나라도 잃으면 전체 폐기 → 화면에서는 큰 패킷일수록 손실률이 몇 배. 붐비는 곳에서만 순간이동

증상: 순간이동
요인: 손실
누가 겪나: 특정 장소·채널, 특정 지역·통신사
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 패킷을 1,200바이트 이하로 직접 나누기, 변경분만 보내기.
수치 감각: 손실 2%인 회선에서 프래그먼트 4개로 나뉜 패킷은 약 8%가 사라집니다. 단편화된 패킷을 아예 버리는 방화벽·통신사도 있어, 그 사용자는 큰 패킷을 하나도 받지 못합니다.
그래프에서는: 인원·부하를 따라 오름 · IP 단편화 수(IpFragCreates), 스냅샷 크기
확인할 곳: 서버에서 nstat -az의 IpFragCreates(보내면서 만든 프래그먼트 수) 증가량을 보고, 받는 쪽은 IpReasmFails(재조립 실패 수)를 봄. 게임 서버 로그나 패킷 캡처로 UDP 패킷 크기 분포를 확인
이러면 맞음: 사람이 몰리는 곳에서 IpFragCreates가 늘고 1,500바이트를 넘는 UDP 패킷이 있으며 그때 순간이동 제보가 늘어남
이러면 아님: IpFragCreates가 늘지 않으면 서버가 보내는 쪽에서는 단편화가 일어나지 않음
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

RFC 8085: UDP Usage Guidelines IETF
프래그먼트 하나를 잃으면 재조립이 안 돼 패킷 전체를 잃음, UDP 앱은 IP 단편화를 피해야 함
RFC 8900: IP Fragmentation Considered Fragile IETF
방화벽·일부 네트워크가 IP 프래그먼트를 버리는 사례
net/ipv4/proc.c (Linux v6.12) Linux kernel
nstat이 보여 주는 카운터 이름: Ip 그룹의 FragCreates(만든 프래그먼트 수)·ReasmFails(재조립 실패 수)

신뢰성 UDP 재전송 설정 Reliable-UDP tuning (KCP, ENet…)

ID sk-reliable-udp · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

UDP 위에 직접 만든 재전송 규칙이 너무 보수적이면 복구가 늦고 너무 공격적이면 회선을 더 막습니다.

왜 재전송 간격·횟수·윈도우 크기 설정이 회선과 맞지 않음 → 그러면 늦은 복구, 또는 중복 전송으로 혼잡 악화 → 화면에서는 스킬 씹힘, 몰아치기, 혼잡 시 더 심한 렉

증상: 씹힘·롤백, 몰아치기
요인: 손실, 지연
누가 겪나: 나만
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 측정한 왕복 시간 기반 재전송, 중요도별 채널 분리. 클라이언트: 서버와 같은 재전송·채널 설정 적용.
그래프에서는: 가끔 무작위로 튐 · 신뢰성 UDP 재전송 비율, 게임 안 RTT
확인할 곳: 쓰는 라이브러리가 연결마다 가진 통계(재전송 수, 추정 왕복 시간, 재전송 대기 시간)를 서버·클라이언트에서 남기고 같은 유저의 실제 회선 손실률(mtr로 잰 값)과 비교
이러면 맞음: 재전송 비율이 실제 회선 손실률보다 몇 배 높으면 너무 공격적인 설정, 재전송 대기 시간이 측정 왕복 시간의 몇 배면 너무 보수적인 설정
이러면 아님: 재전송 비율이 회선 손실률과 비슷하고 대기 시간이 왕복 시간에 맞으면 설정 문제가 아님. 회선 손실 자체를 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 1건

RFC 8085: UDP Usage Guidelines IETF
재전송은 혼잡을 키울 수 있어 혼잡 제어 대상, 왕복 시간은 여러 측정의 평균(EWMA)으로 추정, 초기 1초, 타이머 만료 시 전송률 낮추기

유휴 후 슬로 스타트 Slow start after idle

ID sk-slowstart · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

TCP는 한동안 유휴 상태면 혼잡 윈도우(한 번에 보낼 수 있는 양)를 다시 줄여, 갑자기 큰 데이터를 보낼 때 여러 번에 나눠 보냅니다.

왜 유휴 상태이던 연결로 마을 입장 등 큰 데이터를 보냄 → 그러면 혼잡 윈도우가 줄어 있어 여러 왕복에 나눠 전송 → 화면에서는 입장 직후 주변 캐릭터와 NPC가 왕복 몇 번만큼 늦게 나타남(먼 서버일수록 눈에 띔)

증상: 입력 지연, 안 보임·유령 개체
요인: 지연
누가 겪나: 나만
언제: 이동 중·지역 전환 때, 가만히 있다가
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 입장 데이터 줄이기(꼭 필요한 것부터 먼저 보내기).
인프라팀 할 일: tcp_slow_start_after_idle 끄기(리눅스, 서버 전체 설정).
수치 감각: RTO보다 오래 유휴 상태면 혼잡 윈도우가 줄기 시작해, 오래 유휴 상태였다면 약 14KB(패킷 10개)까지 내려갑니다. 그러면 100KB는 한 번에 못 보내고 왕복 3번에 나눠 보냅니다.
그래프에서는: 일부만 높음 · 입장 직후 전송 시간(RTT가 긴 유저)
확인할 곳: sysctl net.ipv4.tcp_slow_start_after_idle 값을 확인하고, 유휴 뒤 지역에 입장하는 순간 그 연결의 ss -ti에서 cwnd(혼잡 윈도우)가 작아졌는지 봄
이러면 맞음: 설정이 1(기본)이고 유휴 뒤 입장 순간 cwnd가 10 안팎으로 줄어 전송이 왕복 여러 번에 나뉨. RTT가 긴 유저일수록 늦게 나타나고 0으로 바꾸면 사라짐
이러면 아님: cwnd가 크게 유지되는데도 늦게 나타나면 서버 쪽 입장 처리(“밀집 지역 진입 시 스폰 폭주”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

IP Sysctl Linux kernel
tcp_slow_start_after_idle 기본 켜짐, RTO 동안 유휴면 혼잡 윈도우를 줄임(RFC 2861 방식)
RFC 5681: TCP Congestion Control IETF
RTO보다 오래 데이터를 보내지 않았으면 혼잡 윈도우를 재시작 윈도우 min(IW, cwnd) 이하로 줄이고 슬로 스타트
RFC 6928: Increasing TCP's Initial Window IETF
초기 윈도우 10세그먼트, 최대 14,600바이트
ss(8) — Linux manual page iproute2
-i의 cwnd(혼잡 윈도우)·ssthresh(슬로 스타트 임계값)

혼잡 제어로 전송량 급감 Congestion control backoff

ID sk-congestion · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

TCP는 손실을 혼잡 신호로 보고 전송 속도를 30~50% 줄입니다. 와이파이 손실에도 똑같이 반응합니다.

왜 보낼 양이 많을 때 와이파이나 회선에서 약간의 손실 발생 → 그러면 TCP가 전송 속도를 크게 줄이고 천천히 회복(리눅스·윈도우 기본인 CUBIC은 30% 줄임) → 화면에서는 사람 많은 곳에서 업데이트가 밀려 몰아치기·입력 지연

증상: 몰아치기, 입력 지연
요인: 지연, 정체
누가 겪나: 나만
언제: 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 보내는 양 줄이기(관심 영역, 변경분만), 한꺼번에 몰아 보내지 않게 나눠 보내기.
인프라팀 할 일: BBR 같은 혼잡 제어로 바꾸기(tcp_congestion_control).
그래프에서는: 서서히 오르다 뚝 떨어짐 · 연결별 혼잡 윈도우(cwnd)·전송률
확인할 곳: 업데이트가 밀린 유저 연결을 ss -ti로 여러 번 떠서 cwnd·ssthresh 변화와 혼잡 제어 이름(cubic·bbr)을 보고, Send-Q가 쌓이는지 함께 봄
이러면 맞음: 손실 뒤 cwnd가 크게 줄었다가 천천히 오르기를 반복하고 줄어든 동안 Send-Q가 쌓여 몰아치기·입력 지연 제보 시각과 겹침
이러면 아님: cwnd가 넉넉한데도 밀리면 받는 쪽 윈도우(“제로 윈도우 (재전송처럼 보이는 멈춤)”)나 서버 송신 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

RFC 9438: CUBIC for Fast and Long-Distance Networks IETF
CUBIC은 손실 때 윈도우를 0.7배(30% 감소), Reno는 0.5배, CUBIC이 리눅스·윈도우·애플 기본
TCP BBR congestion control comes to GCP – your Internet just got faster Google Cloud
손실 기반 혼잡 제어는 혼잡 때문이 아닌 손실에도 전송률을 크게 줄임, BBR은 전달률과 RTT로 판단
IP Sysctl Linux kernel
tcp_congestion_control로 새 연결의 혼잡 제어 알고리즘 선택
ss(8) — Linux manual page iproute2
-i의 cwnd·ssthresh와 혼잡 제어 알고리즘 이름
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트

RST 강제 종료로 마지막 데이터 유실 SO_LINGER, abrupt RST

ID sk-linger · 주 담당 게임개발팀·서버 개발

서버가 연결을 급히 끊으면 마지막으로 보낸 안내나 저장 완료 신호가 사라집니다.

왜 서버가 연결을 강제 종료(RST)로 닫음. SO_LINGER를 0초로 두거나, 받은 데이터를 다 읽지 않고 닫으면 생김 → 그러면 아직 전송 중이던 킥 사유·마지막 데이터가 버려짐 → 화면에서는 이유 없는 “알 수 없는 오류로 연결 종료”

증상: 접속 끊김
요인: 손실
누가 겪나: 나만
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 사유를 보낸 뒤 송신 방향만 먼저 닫고(shutdown), 상대가 닫을 때까지 받은 데이터를 끝까지 읽은 다음 닫기, SO_LINGER 0초 피하기.
그래프에서는: 가끔 무작위로 튐 · RST로 끝난 연결 수
확인할 곳: nstat -az의 TcpExtTCPAbortOnData(보낼 데이터가 남은 채 RST로 닫음, SO_LINGER 0초)·TcpExtTCPAbortOnClose(안 읽은 데이터가 남은 채 닫음) 증가량을 보고, 끊김 순간 서버 쪽 패킷 캡처에서 FIN 대신 RST가 나가는지 봄
이러면 맞음: “알 수 없는 오류로 연결 종료” 제보 시각에 서버가 RST를 보내고 AbortOnData·AbortOnClose가 늘어남
이러면 아님: 서버가 FIN으로 정상 종료했는데 사유가 안 보이면 클라이언트의 종료 처리 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

closesocket function (winsock.h) Microsoft
SO_LINGER를 켜고 시간을 0으로 두면 연결을 즉시 리셋하는 강제 종료가 되고 보내지 못한 데이터는 사라짐
RFC 9293: Transmission Control Protocol (TCP) IETF
받은 데이터가 남은 채 닫으면 데이터 유실을 알리려 RST를 보냄
Graceful Shutdown, Linger Options, and Socket Closure Microsoft
shutdown으로 송신만 먼저 닫고 상대의 종료 알림을 받은 뒤 소켓을 닫는 순서
SNMP counter Linux kernel
TcpExtTCPAbortOnData: SO_LINGER 0초 등으로 보낼 데이터가 남은 채 RST로 닫음, TcpExtTCPAbortOnClose: 안 읽은 데이터가 남은 채 닫아 RST를 보냄

블로킹 I/O 구조 Blocking I/O model

ID sk-blocking-io · 주 담당 게임개발팀·서버 개발

소켓 하나를 기다리는 동안 스레드가 다른 일을 못 하는 구조에서는 사람이 늘수록 전체가 느려집니다.

왜 연결마다 읽기·쓰기를 기다리는 방식 → 그러면 한 연결의 지연이 같은 스레드의 다른 연결로 번짐 → 화면에서는 동접이 늘수록 전체가 슬로우모션·입력 지연

증상: 슬로우모션, 입력 지연
요인: 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: epoll·IOCP·io_uring 기반 비동기 I/O로 전환.
그래프에서는: 인원·부하를 따라 오름 · 응답 시간, 스레드 수
확인할 곳: pidstat -w -t로 게임 서버 스레드 수와 스레드별 자발적 컨텍스트 스위칭(cswch/s, 자원을 기다리며 멈춘 횟수)을 보고 동접에 따른 응답 시간과 비교
이러면 맞음: 동접이 늘수록 응답 시간이 가파르게 오르고 연결 수만큼 늘어난 스레드 대부분이 자발적 스위칭만 많고 CPU는 거의 쓰지 않음(소켓 대기)
이러면 아님: 스레드가 대기 없이 CPU를 계속 쓰고 있으면 계산 과부하(“틱 예산 초과”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

epoll(7) — Linux manual page Linux man-pages
많은 fd를 한 번에 감시하도록 확장되는 I/O 이벤트 알림
I/O Completion Ports Microsoft
많은 비동기 I/O를 미리 만든 스레드 풀로 처리하는 윈도우 방식
pidstat(1) — Linux manual page sysstat
-w의 cswch/s: 자원을 기다리며 스스로 멈춘 자발적 컨텍스트 스위칭, -t로 스레드별

SO_REUSEPORT 분배 쏠림 SO_REUSEPORT imbalance, stuck worker

ID sk-reuseport · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

같은 포트를 여러 프로세스가 나눠 받으면, 커널은 접속마다 주소 해시로 담당 프로세스를 정해 두고 바꾸지 않습니다. 담당 프로세스 하나가 멈추면 거기에 배정된 사람만 기다립니다.

왜 게이트웨이·로그인 서버가 SO_REUSEPORT로 프로세스 여러 개를 띄움 → 그러면 한 프로세스가 GC·과부하로 멈춰도 거기에 배정된 새 접속과 UDP 패킷은 다른 프로세스로 넘어가지 않음 → 화면에서는 일부 사람만 접속 불가·멈춤. 프로세스 수가 바뀌는 재시작 때는 일부 UDP 세션이 끊김

증상: 접속 불가·무한 로딩, 멈춤, 접속 끊김
요인: 정체, 손실
누가 겪나: 나만, 서버 전체
언제: 접속·점검 직후, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 받는 스레드는 절대 멈추지 않게, 재시작 때 세션을 넘겨받는 절차 구현.
인프라팀 할 일: 프로세스별 접속 대기열 감시(ss의 Recv-Q), 배포 때 프로세스 수를 바꾸면 세션 넘겨받기 절차를 따르게.
그래프에서는: 일부만 높음 · 리슨 소켓별 접속 대기열(Recv-Q)
확인할 곳: ss -ltnp로 같은 포트의 리슨 소켓마다 Recv-Q(accept를 기다리는 접속 수)와 담당 프로세스를 보고, 프로세스별 처리량을 비교
이러면 맞음: 같은 포트의 여러 소켓 중 하나만 Recv-Q가 계속 쌓이고 그 프로세스가 멈춰 있거나 처리량이 0에 가까움
이러면 아님: 모든 소켓의 Recv-Q가 고르게 쌓이면 전체 과부하(“접속 대기열(backlog) 넘침”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

socket(7) — Linux manual page Linux man-pages
SO_REUSEPORT로 여러 소켓이 같은 주소에 bind해 TCP 접속과 UDP 패킷을 나눠 받음
net/core/sock_reuseport.c (Linux v6.12) Linux kernel
BPF 프로그램이 없으면 패킷 해시 값을 그룹의 소켓 수에 맞춰 나눠 담당 소켓을 고름
Why does one NGINX worker take all the load? Cloudflare
SO_REUSEPORT는 간단한 해시로 워커마다 큐를 나누므로, 워커 하나가 막히면 그 큐에 쌓인 접속이 모두 멈춤
net/ipv4/tcp_diag.c (Linux v6.12) Linux kernel
ss의 Recv-Q·Send-Q 값: 리슨 소켓은 accept를 기다리는 접속 수와 backlog 한도, 연결된 소켓은 앱이 아직 안 읽은 바이트와 ACK를 받지 못한 송신 바이트

윈도우 UDP 소켓의 WSAECONNRESET 오류 WSAECONNRESET on a Windows UDP socket

ID sk-udp-connreset · 주 담당 게임개발팀·서버 개발

윈도우 서버가 이미 떠난 클라이언트에게 UDP를 보내면 “포트 없음”(ICMP) 알림이 돌아옵니다. 그 알림 때문에 다음 수신 호출이 오류로 끝나는데 서버 코드가 이 오류를 소켓 자체의 고장으로 처리하면 그 소켓을 쓰는 모두가 영향을 받습니다.

왜 막 나간 클라이언트의 주소로 계속 UDP를 보내 “포트 없음”(ICMP) 알림이 돌아옴 → 그러면 윈도우가 그다음 수신 호출을 WSAECONNRESET(10054) 오류로 끝내고, 서버 코드가 수신을 멈추거나 소켓을 닫음 → 화면에서는 그 소켓을 쓰던 모든 사람이 한꺼번에 멈춤·접속 끊김

증상: 접속 끊김, 멈춤
요인: 손실, 정체
누가 겪나: 서버 전체
언제: 가끔 무작위로, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: WSAIoctl로 SIO_UDP_CONNRESET을 꺼서 이 알림을 받지 않기, 수신 오류가 나도 로그만 남기고 수신을 계속하기.
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 수신 오류 로그
확인할 곳: 게임 서버 로그에서 UDP 수신 오류 코드(WSAECONNRESET, 10054)와 수신 루프가 멈추거나 소켓을 닫은 기록을 찾고 서버 쪽 패킷 캡처로 직전에 ICMP Port Unreachable이 도착했는지 봄
이러면 맞음: 접속이 한꺼번에 끊기기 직전에 WSAECONNRESET 수신 오류가 기록되고, 그 전에 막 나간 클라이언트 주소에서 ICMP Port Unreachable이 옴
이러면 아님: 리눅스 서버이거나 코드가 SIO_UDP_CONNRESET을 끈 경우면 해당 없음
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Winsock IOCTLs Microsoft
SIO_UDP_CONNRESET으로 UDP “포트 없음”(PORT_UNREACHABLE) 알림 보고를 켜고 끔
recvfrom function (winsock.h) Microsoft
UDP 소켓의 WSAECONNRESET은 이전 전송이 ICMP Port Unreachable을 받았다는 뜻
Windows Sockets Error Codes Microsoft
WSAECONNRESET 오류 번호 10054

L9 서버 게임 프로세스

틱 예산 초과 Tick overrun

ID sp-tick-overrun · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

한 틱 안에 할 일이 예산을 넘으면 서버의 틱 주기가 늘어지고 그 지역 전체가 느리게 흐르거나 뚝뚝 끊깁니다.

왜 한 틱(예: 50ms)에 처리할 일이 예산을 넘음 → 그러면 1초에 20번 계산할 게임 상태를 8번만 계산 → 화면에서는 그 지역 전체 슬로우모션(서버 설계에 따라 뚝뚝 끊김), 스킬 반응 늦음

증상: 슬로우모션, 입력 지연, 뚝뚝 끊김
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 비싼 계산 줄이기, 틱을 여러 스레드로 나누기, 인원 분산(채널), 틱 처리 시간을 지표로 남기기.
인프라팀 할 일: 틱 시간과 코어별 CPU 사용률을 모니터링·경보에 추가, 단일 코어 성능(클럭)이 높은 CPU·인스턴스 검토.
수치 감각: 20틱 서버의 예산은 50ms, 30틱은 33ms, 60틱은 16.7ms. 갑자기 몰릴 때를 대비해 평소에는 예산의 절반 정도만 쓰도록 여유를 두는 편이 안전합니다.
그래프에서는: 인원·부하를 따라 오름 · 서버 틱 시간, 존·채널별 인원, 게임 스레드 CPU
확인할 곳: 서버가 남기는 틱 처리 시간(p99)·틱 초과 횟수를 존·채널별 인원과 같은 그래프에 놓고 봄. 틱 지표가 없으면 pidstat -t 1로 게임 스레드 하나의 CPU 사용률
이러면 맞음: 인원이 몰린 시각에 틱 시간이 예산(20틱이면 50ms)을 넘고 그동안 게임 스레드의 CPU 사용률이 100% 가까이 붙어 있음
이러면 아님: 틱이 넘치는데 게임 스레드 CPU가 낮으면 기다림 쪽 원인(GC 멈춤, 락, 동기 호출). bcc runqlat의 런큐 지연이 길면 스레드가 CPU를 배정받지 못한 것이라 CPU 부족·스레드 과다 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 틱이 늦을 때의 모습은 서버 설계에 따라 다릅니다. 틱마다 게임 상태를 정해진 시간(예: 50ms)만큼 진행하는 서버는 게임 시간 자체가 느려져 슬로우모션이 됩니다. 실제로 흐른 시간만큼 한 번에 움직이는 서버는 게임 진행 속도는 지키지만 패킷이 드물고 한 번에 크게 움직여 뚝뚝 끊김·순간이동으로 보입니다. 어느 쪽이든 입력 반응은 늦어집니다. 게임 스레드 하나가 서버 전체를 맡으면 서버 전체가, 지역마다 스레드를 나눴다면 그 지역이 느려집니다. EVE Online처럼 대규모 전투에서 일부러 게임 시간을 최대 10배까지 늦춰(Time Dilation) 계산을 따라잡게 하는 게임도 있습니다.
실제 사례: CCP Games 2014: EVE Online HED-GP 대규모 함대전의 서버 과부하

출처 5건

VALORANT's 128-Tick Servers Riot Games
128틱 서버는 한 프레임을 7.8125ms 안에 끝내야 함, 서버 프레임 시간을 하위 시스템별로 재고 예산을 나눠 관리
HED-GP Technical Retrospective: What a HED-ache CCP Games
EVE Online은 과부하 때 Time Dilation으로 게임 시간을 늦추고 하한은 10%(10배 느림), 평소 노드 CPU는 80% 아래
Handling variation in time Unity
고정 간격 시뮬레이션이 밀리면 따라잡는 단계를 몰아서 돌리고 한도를 넘긴 시간은 버려 게임 시간이 실제보다 느리게 흐름
pidstat(1) — Linux manual page sysstat
-t로 프로세스에 속한 스레드별 통계(CPU 사용률 등)를 함께 표시
Demonstrations of runqlat, the Linux eBPF/bcc version IO Visor
스케줄러 런큐 지연(작업이 CPU를 배정받기까지 기다린 시간)을 히스토그램으로 보여 줌

시야(AOI) 계산 폭증 (N²) Area-of-interest explosion

ID sp-aoi · 주 담당 게임개발팀·서버 개발

누가 누구를 볼 수 있는지 모두끼리 비교하면, 인원이 10배가 될 때 계산은 100배가 됩니다.

왜 모든 캐릭터끼리 거리를 비교하거나, 격자(그리드)로 나눠도 한 셀 근처에 수백 명이 몰림 → 그러면 100명이면 약 1만 번, 1,000명이면 약 100만 번 비교 → 화면에서는 월드 보스·공성전처럼 몰린 곳에서 틱이 폭증해 슬로우모션·뚝뚝 끊김

증상: 슬로우모션, 뚝뚝 끊김
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 격자·구역으로 나눠 근처만 비교, 멀리 있는 대상은 드물게 갱신, 한 사람이 보는 인원에 상한.
수치 감각: 거리 비교와 보임·안 보임 목록 갱신을 합쳐 두 사람 한 쌍마다 0.1µs(1천만 분의 1초)로 잡으면, 1,000명(약 100만 쌍)이면 한 틱에 100ms. 20틱 예산(50ms)의 두 배입니다.
그래프에서는: 인원·부하를 따라 오름 · 서버 틱 시간, 한곳에 모인 인원
확인할 곳: 존·채널별 인원과 틱 시간을 같은 그래프에 놓고 틱 안에서 시야 계산에 쓴 시간을 따로 잰 값. 따로 잰 값이 없으면 perf top -p로 게임 프로세스의 함수별 CPU 비중
이러면 맞음: 한곳에 모인 인원이 2배가 될 때 틱 시간이 4배 가까이 늘고 시야·거리 계산 함수가 CPU 시간의 대부분을 차지함
이러면 아님: 틱 시간이 인원에 비례해 늘거나 전송·직렬화 함수의 비중이 크면 브로드캐스트 폭증이나 직렬화·압축 비용 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Comparing Interest Management Algorithms for Massively Multiplayer Games ACM
NetGames 2006 논문(저자 공개본). 모든 쌍의 거리를 재는 방식은 인원이 늘면 감당하지 못하고 정사각형 격자로 나누면 주변 9개 셀만 확인
Replication Graph in Unreal Engine Epic Games
액터마다 모든 접속을 따져 보는 기본 방식은 인원·액터가 많으면 서버 CPU 병목, MMORPG 등은 월드를 격자로 나눠 셀별 목록을 재사용
perf-top(1) — Linux manual page perf
실행 중인 프로세스(-p)나 스레드(-t)의 CPU 사용 비중을 함수(심볼)별로 실시간 표시

브로드캐스트 폭증 Broadcast fan-out (N×N)

ID sp-broadcast · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

한 명의 움직임을 그를 보는 모두에게 보내면, 모인 인원의 제곱만큼 보낼 업데이트가 생깁니다.

왜 한 명의 변화를 볼 수 있는 모두에게 전송 → 그러면 1,000명이 서로를 보면 틱마다 100만 개 업데이트 → 화면에서는 전송 대기열과 대역폭이 포화되어 지연·손실(입력 지연·몰아치기·순간이동)

증상: 입력 지연, 순간이동, 몰아치기
요인: 지연, 손실
누가 겪나: 특정 장소·채널, 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 거리·중요도별 갱신 빈도 낮추기(가까운 적은 매 틱, 먼 사람은 1초에 몇 번), 한 사람에게 보내는 양에 상한을 두고 중요한 것부터 채우기, 여러 업데이트를 한 패킷에 묶기, 표시 인원 상한.
인프라팀 할 일: 서버별 송신 대역폭·초당 패킷 수를 NIC·인스턴스 네트워크 한도와 비교해 경보, 대규모 이벤트 전 여유 확인.
수치 감각: 1,000명 × 1,000명 × 20틱 = 초당 2,000만 개. 개당 40바이트면 서버 전체 약 6.4Gbps, 받는 사람 한 명당 약 6.4Mbps. 보이는 인원을 150명으로 제한하면 전체 약 1Gbps, 한 명당 약 1Mbps.
그래프에서는: 인원·부하를 따라 오름 · 서버 송신 패킷·바이트, 한곳에 모인 인원
확인할 곳: sar -n DEV 1의 txpck/s·txkB/s(서버 NIC가 초당 보낸 패킷·KB)를 인원 그래프와 함께 봄. 클라우드 인스턴스는 ethtool -S의 한도 초과 카운터(AWS ENA는 bw_out_allowance_exceeded·pps_allowance_exceeded)
이러면 맞음: 모인 인원이 늘 때 송신 패킷·바이트가 인원보다 가파르게(제곱에 가깝게) 늘고, 한도에 닿은 시각부터 한도 초과 카운터나 송신 폐기가 증가
이러면 아님: 송신량은 그대로인데 틱 시간만 늘면 시야 계산·게임 로직 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: CCP Games 2014: EVE Online HED-GP 대규모 함대전의 서버 과부하

출처 5건

HED-GP Technical Retrospective: What a HED-ache CCP Games
n명이 한 행동을 n명이 봐야 하는 O(n²) 전송이 대규모 함대전의 피할 수 없는 한계 요인
Actor Priority in Unreal Engine Epic Games
연결 대역폭이 포화되면 액터마다 우선순위(거리·시선·마지막 전송 뒤 지난 시간)를 매겨 중요한 것부터 대역폭을 나눠 줌
Detailed Actor Replication Flow in Unreal Engine Epic Games
NetUpdateFrequency로 액터별 갱신 빈도를 정하고 우선순위 순으로 보내다 연결이 포화되면 나머지는 다음 틱으로 미룸
sar(1) — Linux manual page sysstat
sar -n DEV의 rxpck/s·txpck/s(초당 받은·보낸 패킷), rxkB/s·txkB/s(초당 받은·보낸 KB)
Monitor network performance for ENA settings on your EC2 instance AWS
bw_out_allowance_exceeded(송신 대역폭 한도 초과)·pps_allowance_exceeded(PPS 한도 초과)로 큐에 쌓이거나 버려진 패킷 수

단일 스레드 지역 과부하(핫스팟) Single-threaded hot zone

ID sp-hotzone · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

지역마다 스레드 하나가 맡는 구조에서 한곳에 사람이 몰리면 그 코어 하나만 100%가 됩니다.

왜 한 지역(채널)을 스레드 하나가 담당 → 그러면 사람이 한곳에 몰리면 그 코어만 포화, 나머지 코어는 여유 → 화면에서는 그 지역만 렉, 다른 지역은 멀쩡

증상: 슬로우모션, 입력 지연
요인: 정체
누가 겪나: 특정 장소·채널
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 채널 분산, 지역 내부 병렬화, 인원 상한.
인프라팀 할 일: 코어별 CPU 사용률을 모니터링·경보에 추가(서버 전체 평균에는 코어 하나의 포화가 묻힘).
수치 감각: 16코어 서버에서 코어 하나가 100%여도 서버 전체 CPU 사용률은 약 6%로 보입니다. 코어별 사용률을 봐야 찾을 수 있습니다.
그래프에서는: 인원·부하를 따라 오름 · 코어별 CPU 사용률, 스레드별 CPU
확인할 곳: mpstat -P ALL 1로 코어별 사용률, pidstat -t 1로 게임 프로세스의 스레드별 CPU를 보고 가장 바쁜 스레드가 맡은 존의 인원과 비교
이러면 맞음: 서버 전체 CPU는 낮은데 스레드 하나(코어 하나)만 100% 가까이 붙어 있고, 그 시각 그 스레드가 맡은 존에 사람이 몰려 있음
이러면 아님: 여러 코어가 고르게 높으면 서버 전체 과부하. 한 코어의 %soft(수신 처리)만 높으면 NIC 인터럽트 단일 코어 집중 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 지역마다 틱을 따로 돌려야 다른 지역이 멀쩡합니다. 여러 지역 스레드가 매 틱 서로를 기다렸다가 함께 다음 틱으로 넘어가는 구조라면, 가장 바쁜 지역 하나가 서버 전체의 틱을 늦춥니다.
실제 사례: CCP Games 2014: EVE Online HED-GP 대규모 함대전의 서버 과부하

출처 3건

Time Dilation – How’s That Going? CCP Games
EVE Online의 Time Dilation은 노드 단위라 한 노드에 함께 올라간 먼 성계까지 느려짐, 큰 전투는 성계 4개만 올린 강화 노드에서 처리
mpstat(1) — Linux manual page sysstat
프로세서별 사용률과 전체 평균을 따로 보여 줌(-P ALL), %soft는 소프트웨어 인터럽트 처리에 쓴 시간 비율
pidstat(1) — Linux manual page sysstat
-t로 프로세스에 속한 스레드별 통계(CPU 사용률 등)를 함께 표시

락 경합 Lock contention

ID sp-lock · 주 담당 게임개발팀·서버 개발

여러 스레드가 같은 데이터를 쓰려고 락 하나를 기다리면, 스레드를 늘려도 한 번에 하나씩만 실행됩니다.

왜 경매장·길드 창고처럼 공용 데이터를 여러 스레드가 동시에 사용 → 그러면 락을 잡은 스레드가 끝날 때까지 나머지는 대기 → 화면에서는 특정 기능만 느림, 심하면 전체 틱 지연

증상: 입력 지연, 멈춤
요인: 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 락을 잘게 나누기, 락 안에서 하는 일 줄이기, 메시지 기반 구조(데이터마다 담당 스레드를 정하고 다른 스레드는 메시지로 요청만 보내기).
수치 감각: 락 안의 일이 작업의 20%면 스레드를 아무리 늘려도 처리량은 1개일 때의 최대 5배, 40%면 2.5배에서 멈춥니다.
그래프에서는: 인원·부하를 따라 오름 · 요청 처리 시간, 스레드별 CPU·컨텍스트 스위칭
확인할 곳: pidstat -w -t 1로 스레드별 자발적 컨텍스트 스위칭(cswch/s, 자원을 기다리며 멈춘 횟수), bcc offcputime -p로 스레드가 CPU를 떠나 어디서 기다리는지(호출 스택별 대기 시간). .NET은 dotnet-counters의 락 경합 수(.NET 9 이후 dotnet.monitor.lock_contentions, 8 이하 Monitor Lock Contention Count)
이러면 맞음: 부하가 늘어도 CPU 사용률은 낮게 머무는데 처리 시간이 늘고 대기 시간의 대부분이 락을 잡으려는 호출 스택에 몰려 있으며 락 경합 수가 함께 오름
이러면 아님: CPU가 꽉 차 있으면 계산량 문제(틱 예산 초과, 단일 스레드 지역 과부하). 기다리는 곳이 DB·파일 호출이면 게임 스레드의 동기 호출 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 여러 스레드가 게임 데이터를 함께 고치는 구조에서 생깁니다. 지역·기능마다 스레드 하나가 맡고 메시지로만 주고받는 구조는 락이 거의 없는 대신, 한 스레드에 일이 몰리는 문제(단일 스레드 지역 과부하)를 조심해야 합니다. 게임 스레드가 느린 저장 작업이 잡은 락을 기다리면 그 틱 전체가 멈춥니다.
실제 사례: Roblox 2021: Roblox 73시간 장애: 서비스 디스커버리(Consul) 클러스터의 경합

출처 6건

Amdahl's Law in the Multicore Era IEEE
IEEE Computer 2008 논문(저자 공개본). 병렬로 나눌 수 없는 비율이 1−f면 코어를 아무리 늘려도 속도 향상은 1/(1−f)를 넘지 못함(암달의 법칙)
Request scheduling Microsoft
Orleans의 그레인(액터)은 요청을 하나씩 끝까지 처리하는 단일 스레드 실행 모델이라 상태를 동시에 고치지 않음, 서로의 응답을 기다리면 데드락 가능
pidstat(1) — Linux manual page sysstat
-w의 cswch/s는 자원을 기다리느라 멈춘 자발적 컨텍스트 스위칭 수, -t로 스레드별 표시
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
스레드가 멈춰 CPU를 떠난 시간(off-CPU)을 호출 스택별로 합산, -p로 프로세스 지정
Well-known EventCounters in .NET Microsoft
Monitor Lock Contention Count(monitor-lock-contention-count): 모니터 락을 잡으려다 경합이 생긴 횟수
.NET runtime metrics .NET
.NET 9부터 dotnet.monitor.lock_contentions: 프로세스 시작 뒤 모니터 락을 잡으려다 경합이 생긴 횟수

데드락 Deadlock

ID sp-deadlock · 주 담당 게임개발팀·서버 개발

두 스레드가 서로 상대가 잡은 락을 기다리면 영원히 멈춥니다.

왜 스레드 A는 락1을 잡고 락2를, B는 락2를 잡고 락1을 기다림 → 그러면 둘 다 영원히 멈추고 관련 스레드도 줄줄이 멈춤 → 화면에서는 서버 전체 정지, 워치독이 재시작하며 전원 접속 끊김

증상: 멈춤, 접속 끊김
요인: 정체
누가 겪나: 서버 전체, 특정 기능만
언제: 가끔 무작위로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 락 순서 규칙, 타임아웃 있는 락, 워치독과 멈춘 순간의 스레드 덤프 남기기.
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 서버 송신량
확인할 곳: 멈춘 동안 모든 스레드의 호출 스택을 뜸. JVM은 jstack(데드락을 자동으로 찾아 표시), .NET은 dotnet-stack, 네이티브 서버는 gdb의 thread apply all bt, 또는 gcore로 코어 파일을 떠 두고 재시작한 뒤 분석
이러면 맞음: 두 개 이상의 스레드가 서로 상대가 잡은 락을 기다리는 스택으로 멈춰 있고, 그동안 프로세스 CPU 사용률이 0에 가까움
이러면 아님: 멈춘 동안 스레드 하나가 CPU 100%로 돌고 있으면 무한 루프. 스레드들이 DB·외부 응답을 기다리고 있으면 동기 호출이나 스레드 풀 고갈 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 6건

Runtime locking correctness validator Linux kernel
두 락을 서로 반대 순서로 잡으면 순환 대기로 데드락(lock inversion deadlock), 리눅스 커널은 락 순서를 검사해 미리 경고
Liveness, Readiness, and Startup Probes Kubernetes
실행 중이지만 진행하지 못하는 데드락 상태를 라이브니스 검사로 잡아 컨테이너를 재시작
Diagnostic Tools (Java SE 21 Troubleshooting Guide) Oracle
jstack은 실행 중인 JVM의 모든 스레드 스택을 출력하고 데드락도 찾아 표시(Found one Java-level deadlock)
dotnet-stack diagnostic tool - .NET CLI Microsoft
.NET 프로세스의 모든 스레드의 관리 스택을 캡처해 출력
Threads (Debugging with GDB) GNU Project
thread apply all로 모든 스레드에 같은 명령(bt: 호출 스택 출력)을 실행
gcore(1) — Linux manual page gdb
실행 중인 프로그램의 코어 파일을 만들고 만든 뒤에도 프로그램은 그대로 계속 실행

게임 스레드의 동기 호출 Synchronous DB / file I/O on the game loop

ID sp-sync-call · 주 담당 게임개발팀·서버 개발

틱 도중 DB 응답이나 파일 쓰기를 기다리면, 그 시간만큼 서버의 게임 진행 전체가 멈춥니다.

왜 틱 안에서 DB 조회·저장, 로그 쓰기, 외부 API 호출을 기다림 → 그러면 DB가 100ms 걸리면 틱도 100ms 멈춤 → 화면에서는 DB·디스크가 느려질 때마다 필드 전체가 멈칫

증상: 멈춤, 뚝뚝 끊김
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 특정 행동을 할 때, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 느린 일(DB 조회·저장, 로그 쓰기, 외부 API 호출)은 모두 비동기로 넘기고 결과는 다음 틱에 반영(타임아웃만 두면 기다리는 동안은 여전히 멈춤).
수치 감각: 같은 데이터센터 DB 왕복 0.5ms도 한 틱에 100번 부르면 50ms. 20틱 예산을 혼자 다 씁니다.
그래프에서는: 가끔 무작위로 튐 · 서버 틱 시간, DB 쿼리 지연
확인할 곳: 틱 시간 그래프와 DB 쿼리 지연(slow query log 등)·디스크 지연을 같은 시간축에 놓고 봄. 틱 지표가 없으면 bcc offcputime -p로 게임 스레드가 어디서 기다리는지
이러면 맞음: 틱이 튄 시각이 DB·파일 지연이 튄 시각과 겹치고 게임 스레드의 대기 시간이 DB 응답 수신·파일 쓰기 호출 스택에 몰려 있음
이러면 아님: DB·디스크 지연이 조용한데 틱이 튀면 GC 멈춤이나 락 경합 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Designs, Lessons and Advice from Building Large Distributed Systems Google
LADIS 2009 기조연설(Jeff Dean). 같은 데이터센터 안 왕복 약 0.5ms(500,000ns)
ASP.NET Core Best Practices Microsoft
데이터 접근·I/O·오래 걸리는 작업은 비동기로 호출, 동기 블로킹 호출은 스레드 풀 고갈과 응답 지연을 부름
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
스레드가 멈춰 CPU를 떠난 시간(off-CPU)을 호출 스택별로 합산, -p로 프로세스 지정

메시지 큐 적체 Mailbox / job queue backlog

ID sp-queue · 주 담당 게임개발팀·서버 개발

요청이 처리 속도보다 빨리 들어와 대기열에 쌓이면, 뒤쪽 요청은 몇 초 뒤에야 처리되거나 버려집니다.

왜 요청이 처리 속도보다 빨리 도착 → 그러면 대기열이 길어지고 한도를 넘으면 버림 → 화면에서는 스킬·거래 반응이 늦거나 씹힘

증상: 입력 지연, 씹힘·롤백
요인: 지연, 손실
누가 겪나: 특정 장소·채널, 특정 기능만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 대기열 길이 모니터링, 오래된 요청 우선 폐기 정책, 처리 병렬화.
그래프에서는: 한도에 닿아 평평해짐 · 큐 길이·가장 오래된 메시지 나이, 초당 처리 수
확인할 곳: 서버가 남기는 큐별 길이, 가장 오래된 메시지의 나이, 초당 들어온 수·처리한 수·버린 수. 코드 지표가 없으면 ss(또는 netstat)로 게임 소켓의 Recv-Q(커널이 받아 두었지만 프로세스가 아직 읽지 않은 양)
이러면 맞음: 들어오는 수가 처리 수를 넘는 동안 처리 수는 한 값에서 더 오르지 못하고, 큐 길이·나이와 버린 수가 계속 늘어남
이러면 아님: 큐가 짧고 나이도 작은데 반응이 늦으면 회선 지연이나 틱 자체의 지연 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
실제 사례: CCP Games 2014: EVE Online HED-GP 대규모 함대전의 서버 과부하

출처 4건

Avoiding insurmountable queue backlogs AWS
Amazon Builders' Library. 적체는 대기 중인 메시지의 나이로 감시, 실시간 시스템은 새 데이터부터 처리(LIFO에 가깝게), 오래된 메시지는 버리기도 함
Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
처리 속도보다 요청이 빠르면 큐가 차서 지연이 늘고 FIFO 대신 LIFO나 CoDel로 이미 쓸모없어진 오래된 요청을 덜어 냄
ss(8) — Linux manual page iproute2
소켓 통계를 보여 주는 도구(netstat과 비슷한 정보), -p로 소켓을 쓰는 프로세스 표시
netstat(8) — Linux manual page net-tools
Recv-Q: 연결된 소켓에서 사용자 프로그램이 아직 가져가지 않은 바이트 수

타이머 동시 발동 몰림 Synchronized timers

ID sp-timer-burst · 주 담당 게임개발팀·서버 개발

모든 몬스터 리스폰, 모든 버프 만료, 정각 보상이 같은 틱에 몰리면 그 틱만 수십 배 무거워집니다.

왜 리스폰·만료·보상·자동 저장 타이머가 같은 시각에 맞춰짐 → 그러면 그 한 틱에 평소의 수십 배 작업 → 화면에서는 정해진 시각마다 한 번씩 멈칫

증상: 멈춤, 뚝뚝 끊김
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 일정한 주기로
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 타이머 시각을 무작위로 조금씩 분산, 여러 틱에 나눠 처리.
그래프에서는: 일정 주기로 튐 · 서버 틱 시간
확인할 곳: 틱 시간이 튄 시각들을 모아 간격을 봄(정각, 5분마다 등). 같은 시각에 도는 리스폰·버프 만료·보상·자동 저장 타이머 목록과 대조
이러면 맞음: 틱이 매번 같은 시각이나 같은 간격으로 튀고 그 시각에 한꺼번에 발동하는 게임 타이머 작업이 있음
이러면 아님: 주기는 있지만 GC 로그의 멈춤 시각이나 서버의 크론·백업 시각과 겹치면 서버 GC 전체 멈춤, 예약 작업 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 1건

Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library. 모든 타이머·주기 작업·지연 작업에 지터를 더해 같은 시각에 몰리는 부하를 흩뜨림, 여러 서버의 1분 주기 요청이 매분 첫 몇 초에 몰린 사례

길찾기 폭주 Pathfinding storms

ID sp-pathfinding · 주 담당 게임개발팀·서버 개발

수백 마리 몬스터가 동시에 플레이어를 쫓으며 경로를 계산하면 CPU를 크게 씁니다.

왜 몰이 사냥, 대규모 스폰으로 몬스터가 동시에 추적 → 그러면 몬스터마다 길찾기 계산 → 화면에서는 그 사냥터만 슬로우모션

증상: 슬로우모션
요인: 정체
누가 겪나: 특정 장소·채널
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 경로 캐시, 계산 횟수 상한, 여러 틱에 나누기.
그래프에서는: 인원·부하를 따라 오름 · 서버 틱 시간, 존별 몬스터 수
확인할 곳: 존별로 플레이어를 추적 중인 몬스터 수와 틱 시간. 따로 센 값이 없으면 perf top -p로 게임 프로세스의 함수별 CPU 비중
이러면 맞음: 몰이 사냥·대규모 스폰 때 틱 시간이 늘고 길찾기(경로 탐색) 함수가 CPU 시간의 큰 비중을 차지
이러면 아님: 몬스터는 적고 플레이어만 많을 때 틱이 늘면 시야 계산이나 브로드캐스트 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

AI.NavMesh.pathfindingIterationsPerFrame Unity
길찾기를 프레임마다 정해진 노드 수만큼만 처리해 여러 프레임에 나눔, 경로가 길거나 요청이 한꺼번에 많을 때도 게임이 매끄러움
perf-top(1) — Linux manual page perf
실행 중인 프로세스(-p)의 CPU 사용 비중을 함수(심볼)별로 실시간 표시

직렬화·압축 비용 Serialization / compression cost

ID sp-serialize · 주 담당 게임개발팀·서버 개발

보낼 데이터를 바이트로 바꾸고 압축하는 데도 CPU가 들고 사람이 많으면 이 비용이 폭증합니다.

왜 업데이트마다 구조체를 바이트로 변환·압축 → 그러면 인원 제곱에 비례해 비용 증가 → 화면에서는 전송이 늦어져 입력 지연

증상: 입력 지연
요인: 정체, 지연
누가 겪나: 특정 장소·채널
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 한 번 만든 패킷을 여러 명에게 재사용, 가벼운 포맷.
그래프에서는: 인원·부하를 따라 오름 · 서버 CPU 사용률, 패킷을 만드는 스레드의 CPU
확인할 곳: perf top -p로 게임 프로세스의 CPU 시간 중 직렬화·압축·암호화 함수(zlib·LZ4·OpenSSL 같은 라이브러리 함수 포함)의 비중을 인원이 적을 때와 몰릴 때 비교
이러면 맞음: 인원이 몰릴수록 직렬화·압축·암호화 함수의 비중이 커지고 패킷을 만드는 스레드의 CPU가 먼저 포화
이러면 아님: 이 함수들의 비중이 작으면 시야 계산·게임 로직 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 패킷을 암호화하는 연결(TLS·DTLS 등)이라면 암호화·복호화도 CPU를 씁니다. 암호화는 연결마다 따로 하므로, 한 번 만든 패킷을 여러 명에게 재사용해도 암호화 비용은 받는 사람 수만큼 듭니다. AES-GCM 같은 대칭 암호는 코어 하나가 초당 수 GB를 처리할 만큼 빨라 평소 비중은 작습니다. 속도는 한 번에 암호화하는 단위(레코드)의 크기에 따라 크게 달라서 게임처럼 작은 패킷이 많으면 바이트당 비용이 커집니다. 접속마다 한 번 하는 핸드셰이크에서는 서버가 인증서 키로 서명하고 키 교환(ECDHE)을 계산합니다. 코어 하나가 초당 서명은 약 1,100번(RSA 2048)에서 1만 8천 번(ECDSA P-256), 키 교환은 약 9천 번 정도라 로그인이 몰릴 때 부담이 됩니다.

출처 4건

Introduction to Iris in Unreal Engine Epic Games
복제할 상태를 양자화한 사본 하나로 들고 있어 비싼 작업을 줄이고 그 작업을 여러 접속이 나눠 씀
VALORANT's 128-Tick Servers Riot Games
매 프레임 복제 변수를 클라이언트마다 비교해 바뀐 값을 묶는 방식은 메모리를 여기저기 읽는 느린 작업이라 서버 CPU를 크게 씀
How "expensive" is crypto anyway? Cloudflare
BoringSSL 측정: AES-128-GCM 초당 약 3.7GB(레코드 크기에 따라 크게 달라짐), 코어 하나가 초당 RSA 2048 서명 1,120번·ECDSA P-256 서명 18,477번·P-256 ECDHE 9,394번, Cloudflare 엣지 서버에서 TLS 라이브러리가 쓴 CPU는 약 1.8%
perf-top(1) — Linux manual page perf
실행 중인 프로세스(-p)의 CPU 사용 비중을 함수(심볼)별로 실시간 표시

서버 크래시 Server process crash

ID sp-crash · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

처리하지 못한 오류로 서버 프로세스가 죽으면, 그 서버에 있던 모두의 접속이 동시에 끊깁니다.

왜 없는 대상을 가리키는 오류(널 참조), 잘못된 데이터, 메모리 부족 등 치명적 오류 → 그러면 서버(또는 존) 프로세스 종료 → 화면에서는 모두 동시에 접속 끊김, 마지막 저장 이후 진행은 롤백될 수 있음

증상: 접속 끊김, 씹힘·롤백
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 가끔 무작위로, 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 크래시 덤프 분석으로 원인 수정, 자주 저장.
인프라팀 할 일: 프로세스 자동 재시작, 크래시 덤프 수집·보관 환경, 서버 다운 즉시 경보.
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 프로세스 재시작 횟수
확인할 곳: coredumpctl list의 코어 덤프 기록(시각, PID, 종료 신호)과 서비스 관리자(systemd)의 비정상 종료·재시작 기록. 윈도우 서버는 WER이 남긴 덤프 파일
이러면 맞음: 접속 수가 한순간 0 가까이 떨어진 시각에 게임 서버 프로세스의 비정상 종료와 코어 덤프가 있음
이러면 아님: 프로세스는 계속 살아 있는데 접속이 끊겼으면 네트워크 장비·유휴 타임아웃 쪽. 오래 멈춘 뒤 워치독이 재시작한 기록이면 무한 루프·데드락 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Collecting User-Mode Dumps Microsoft
윈도우 오류 보고(WER)로 사용자 모드 프로그램이 크래시할 때 전체·미니 덤프를 로컬에 모으도록 설정
systemd.service(5) — Linux manual page systemd
Restart=on-failure는 비정상 종료·신호 종료(코어 덤프 포함)·워치독 시간 초과 때 서비스를 자동 재시작, 오래 도는 서비스에 권장
coredumpctl(1) — Linux manual page systemd
systemd-coredump가 저장한 코어 덤프를 list로 조회, 크래시 시각·PID·크래시를 일으킨 신호 표시

스레드 풀 고갈 Thread pool starvation

ID sp-threadpool · 주 담당 게임개발팀·서버 개발

작업을 처리할 워커 스레드가 모두 느린 작업에 묶이면 새 요청은 무작정 기다립니다.

왜 워커 스레드들이 외부 API·DB 응답을 기다리며 묶임 → 그러면 새 요청이 배정받을 스레드가 없음 → 화면에서는 로그인·상점 등 특정 기능 무한 로딩

증상: 접속 불가·무한 로딩, 입력 지연, 멈춤
요인: 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 사람이 몰릴 때, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 느린 호출에 타임아웃, 기능별 스레드 풀 분리, 비동기화.
그래프에서는: 한도에 닿아 평평해짐 · 스레드 풀 스레드 수·대기열 길이, 요청 처리 시간
확인할 곳: .NET은 dotnet-counters monitor의 스레드 풀 스레드 수와 대기열 길이(.NET 9 이후 dotnet.thread_pool.thread.count·dotnet.thread_pool.queue.length, 8 이하 ThreadPool Thread Count·ThreadPool Queue Length)를 보고, dotnet-stack으로 워커 스레드들이 어디서 기다리는지 확인. JVM·네이티브 서버는 스레드 덤프로 같은 것을 확인
이러면 맞음: CPU 사용률은 100%보다 한참 낮은데 스레드 수가 천천히 계속 늘거나 상한에 붙어 있고, 대기열이 쌓이며 워커 대부분이 같은 외부 호출(DB·HTTP) 응답을 기다림
이러면 아님: 대기열이 비어 있는데도 느리면 호출 대상 자체가 느린 것이라 연쇄 장애·외부 서비스 의존 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 패킷 받기와 게임 로직이 같은 워커 스레드 풀을 나눠 쓰는 구조라면, 느린 작업 몇 개가 워커를 모두 점유하는 순간 서버 전체의 패킷 처리가 멈춥니다.
실제 사례: Riot Games 2021: League of Legends EUW 5시간 장애: 부가 DB 하나가 서버 전체를 멈춤

출처 5건

Debug ThreadPool Starvation Microsoft
풀에 남은 스레드가 없어 새 작업이 대기하면 응답이 느려짐, 스레드를 점유하는 블로킹 코드가 원인. dotnet-counters에서 CPU는 100%보다 한참 낮은데 dotnet.thread_pool.thread.count가 천천히 계속 늘면 고갈 신호(dotnet.thread_pool.queue.length도 큰 경우가 많음), dotnet-stack으로 스레드가 기다리는 곳 확인
Avoiding insurmountable queue backlogs AWS
동시 처리 수 = 도착률 × 지연(리틀의 법칙). 초당 100건에서 지연이 100ms에서 10초로 늘면 스레드 10개가 1,000개로 늘어 풀이 고갈
Bulkhead Pattern Microsoft Azure
호출 대상마다 커넥션·스레드 풀을 따로 두면 한 대상의 장애가 그 풀만 막음
.NET runtime metrics .NET
dotnet.thread_pool.thread.count(스레드 풀 스레드 수)·dotnet.thread_pool.queue.length(대기 중인 작업 수)는 .NET 9부터
Well-known EventCounters in .NET Microsoft
.NET 8 이하의 ThreadPool Thread Count(threadpool-thread-count)·ThreadPool Queue Length(threadpool-queue-length)

무한 루프·로직 폭주 Infinite loop / runaway logic

ID sp-infinite-loop · 주 담당 게임개발팀·서버 개발

버그로 한 틱이 끝나지 않으면 서버가 멈추고 워치독이 강제로 재시작합니다.

왜 잘못된 조건으로 반복이 끝나지 않거나 재귀 폭주 → 그러면 틱이 끝나지 않아 서버 정지 → 화면에서는 멈춤 후 전원 접속 끊김

증상: 멈춤, 접속 끊김
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 특정 행동을 할 때, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 반복 상한, 워치독, 문제 입력 재현 테스트.
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 스레드별 CPU
확인할 곳: 멈춘 동안 pidstat -t 1로 스레드별 CPU를 보고 100%로 도는 스레드가 어느 함수에서 도는지 perf top -t(스레드 ID)나 gdb로 확인. 이미 재시작됐다면 워치독 시간 초과 기록(systemd의 WatchdogSec, 쿠버네티스 라이브니스 검사 실패)
이러면 맞음: 서버가 멈춘 동안 게임 스레드 하나가 CPU 100%로 붙어 있고 스택이 같은 함수·반복문 안에서 계속 돎
이러면 아님: 멈춘 동안 CPU가 0에 가까우면 데드락이나 외부 응답 대기 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

systemd.service(5) — Linux manual page systemd
WatchdogSec=: 서비스가 정한 시간 안에 살아 있다는 신호(WATCHDOG=1)를 보내지 않으면 실패로 보고 종료, Restart= 설정에 따라 자동 재시작
Liveness, Readiness, and Startup Probes Kubernetes
실행 중이지만 진행하지 못하는 상태를 라이브니스 검사로 잡아 재시작, 기본은 10초마다 검사해 3번 연속 실패하면 재시작
pidstat(1) — Linux manual page sysstat
-t로 프로세스에 속한 스레드별 통계(CPU 사용률 등)를 함께 표시
perf-top(1) — Linux manual page perf
실행 중인 스레드(-t)나 프로세스(-p)의 CPU 사용 비중을 함수(심볼)별로 실시간 표시

한 대상에 몰린 전투 (월드 보스) Hot entity / combat event fan-out

ID sp-hot-entity · 주 담당 게임개발팀·서버 개발

수백 명이 보스 하나를 동시에 때리면, 보스 한 마리의 계산이 한곳에 몰리고 타격 정보가 보는 모두에게 전송됩니다.

왜 수백 명이 한 보스에게 스킬·버프·디버프를 쉬지 않고 사용 → 그러면 보스의 체력·어그로 목록·디버프 계산이 한곳에 몰리고 타격마다 데미지 숫자·이펙트 패킷을 보는 모두에게 전송 → 화면에서는 스킬이 늦게 들어가고 데미지 숫자가 몰아서 뜸, 보스 주변만 슬로우모션

증상: 입력 지연, 몰아치기, 슬로우모션
요인: 정체, 지연
누가 겪나: 특정 장소·채널
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 남의 데미지 숫자·이펙트는 묶거나 생략, 한 대상에 걸리는 디버프 수 상한, 타격 처리를 여러 틱에 나누기.
수치 감각: 800명이 초당 2번씩 때리면 초당 1,600번의 타격. 이를 보는 800명에게 모두 알리면 초당 128만 개의 메시지입니다.
그래프에서는: 인원·부하를 따라 오름 · 서버 틱 시간, 송신 메시지 수
확인할 곳: 보스전 시각의 틱 시간과 송신 패킷 수를 보스 주변 인원과 함께 보고 가능하면 대상별 초당 이벤트(타격·버프·디버프) 수
이러면 맞음: 보스 주변 인원이 늘 때 틱 시간과 송신량이 가파르게 늘고 보스 한 마리의 초당 이벤트 수가 다른 대상보다 수십 배 많음
이러면 아님: 보스와 상관없이 한곳에 모이기만 해도 똑같이 느려지면 시야 계산이나 브로드캐스트 폭증 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 1건

HED-GP Technical Retrospective: What a HED-ache CCP Games
공격 한 번도 보는 모든 클라이언트에 알려야 해서 n명이 n명에게 알리는 O(n²) 부담이 생기고, 메시지가 많은 드론 공격은 이 부담이 더 빨리 커짐

밀집 지역 진입 시 스폰 폭주 Spawn burst when entering a crowd

ID sp-spawn-burst · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

사람이 가득한 마을로 텔레포트하면, 서버는 새로 보이게 된 수백 명의 외형·장비·상태를 한꺼번에 보내야 합니다.

왜 텔레포트·접속·채널 이동으로 붐비는 곳에 갑자기 나타남 → 그러면 수백 명분의 전체 정보를 한 번에 만들어 보내고 내 PC도 한 번에 불러옴 → 화면에서는 도착 직후 잠깐 멈춤, 캐릭터가 늦게 하나씩 나타나고 입력이 늦음

증상: 멈춤, 입력 지연, 몰아치기
요인: 정체, 지연
누가 겪나: 나만, 특정 장소·채널
언제: 이동 중·지역 전환 때, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 가까운 순서로 여러 틱에 나눠 보내기, 외형 정보 캐시. 클라이언트: 로딩 화면 동안 미리 받기, 받은 캐릭터를 여러 프레임에 나눠 생성.
수치 감각: 한 명의 외형·장비·버프 정보가 300바이트면 500명은 약 150KB. 평소 한 틱 전송량(수 KB)의 수십 배가 한순간에 몰립니다.
그래프에서는: 접속·점검 직후 폭증 · 연결별 송신 바이트, 클라이언트 프레임 시간
확인할 곳: 붐비는 곳에 도착한 직후 몇 초 동안 그 연결로 보낸 바이트·패킷 수(서버 로그)와 클라이언트 프레임 시간(넷그래프·클라이언트 로그)
이러면 맞음: 도착 직후 그 연결의 송신량이 평소 한 틱의 수십 배로 솟았다가 가라앉고 같은 순간 클라이언트 프레임 시간도 튐
이러면 아님: 한산한 곳으로 이동해도 똑같이 멈추면 존 이동(서버 간 이관)이나 클라이언트 로딩 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Detailed Actor Replication Flow in Unreal Engine Epic Games
액터 채널을 처음 열 때 초기 위치·회전 같은 정보를 함께 보내고 연결이 포화되면 남은 액터는 다음 틱으로 미룸
Actor Priority in Unreal Engine Epic Games
거리와 시선 방향으로 우선순위를 매겨 가깝고 보이는 액터부터 보냄

개체 누적 (정리되지 않은 아이템·소환물) Entity / timer buildup over uptime

ID sp-entity-buildup · 주 담당 게임개발팀·서버 개발

사라져야 할 바닥 아이템, 소환물, 끝난 타이머가 정리되지 않고 쌓이면, 서버를 오래 켜 둘수록 매 틱 할 일이 늘어납니다.

왜 바닥 아이템·소환물·만료된 타이머·빈 파티 정보가 제때 지워지지 않음 → 그러면 틱마다 순회하는 목록이 날마다 길어짐 → 화면에서는 점검 직후엔 멀쩡하다가 며칠 지나면 그 서버·지역만 점점 굼뜸

증상: 슬로우모션, 뚝뚝 끊김, 입력 지연
요인: 정체
누가 겪나: 서버 전체, 특정 장소·채널
언제: 오래 켜 둘수록
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 지역별 개체 수를 지표로 남겨 추세 보기, 개체마다 수명과 개수 상한, 주기적 정리.
수치 감각: 틱마다 모든 개체를 한 번씩 순회하는 서버라면, 개체 수가 두 배가 되면 그 부분의 틱 시간도 두 배가 됩니다.
그래프에서는: 서서히 오르다 뚝 떨어짐 · 존별 개체 수, 서버 틱 시간
확인할 곳: 존·서버별 개체 수(바닥 아이템·소환물·타이머)와 틱 시간을 점검 주기보다 긴 기간(몇 주)으로 봄
이러면 맞음: 점검 직후 낮게 시작한 개체 수와 틱 시간이 날마다 오르다가 점검·재시작 때 뚝 떨어지기를 반복하고, 그동안 메모리는 넉넉함
이러면 아님: 틱은 그대로인데 메모리만 계속 오르면 메모리 누수 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 메모리 누수처럼 오래 켤수록 나빠지지만 메모리는 넉넉한 채로 틱 시간만 늘어납니다. 개체 수 그래프가 점검 주기마다 톱니 모양이면 이 경우입니다.

출처 2건

Actor Ticking in Unreal Engine Epic Games
액터·컴포넌트는 따로 간격을 정하지 않으면 매 프레임 한 번씩 틱을 돌고 필요 없으면 틱을 끌 수 있음
AActor::SetLifeSpan Epic Games
액터에 수명을 정하면 만료될 때 자동으로 파괴

패치로 트래픽 패턴이 바뀜 Patch changes traffic pattern

ID sp-patch-traffic · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·네트워크 인프라

새 콘텐츠·이펙트·동기화 항목이 패킷 크기와 빈도를 늘리면, 잘되던 서버가 패치 뒤부터 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·커널·드라이버·펌웨어 업데이트 뒤 성능 변화”와 가립니다.

출처 7건

RFC 8085: UDP Usage Guidelines IETF
UDP 앱은 경로 MTU를 넘는 데이터그램을 보내지 말아야 함(SHOULD NOT), 프래그먼트 하나를 잃으면 단편화된 패킷 전체를 잃고 일부 NAT·방화벽은 프래그먼트를 모두 버림
RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports IETF
UDP 같은 데이터그램 전송의 기본 안전 크기(BASE_PLPMTU)로 1,200바이트 권장
Maximum transmission unit and maximum segment size Cloudflare
인터넷 경로 MTU 1,500, GRE 터널을 지나면 1,476
Monitor network performance for ENA settings on your EC2 instance AWS
pps_allowance_exceeded·bw_out_allowance_exceeded: 인스턴스의 PPS·송신 대역폭 한도를 넘어 큐에 쌓이거나 버려진 패킷 수
sar(1) — Linux manual page sysstat
sar -n DEV의 rxpck/s·txpck/s(초당 패킷)·rxkB/s·txkB/s(초당 KB), sar -n IP의 fragcrt/s(초당 만든 IP 프래그먼트, ipFragCreates)
CloudWatch metrics that are available for your instances AWS
NetworkPacketsOut(인스턴스가 모든 네트워크 인터페이스로 보낸 패킷 수)·NetworkOut(보낸 바이트 수)
8.7. Packet Lengths Wireshark
캡처한 패킷을 길이 구간별로 나눠 개수·평균·최소·최대를 보여 줌

L10 메모리

서버 GC 전체 멈춤 Stop-the-world GC pause

ID mem-gc · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

Java·C# 서버가 가비지를 수집하려고 모든 스레드를 멈추는 동안(stop-the-world) 서버 전체가 멈춥니다.

왜 힙이 차서 GC 시작 → 그러면 모든 게임 스레드를 멈추고 수집(살아 있는 데이터가 많을수록 오래) → 화면에서는 서버의 모두가 동시에 멈췄다가 몰아치기

증상: 멈춤, 몰아치기
요인: 정체
누가 겪나: 서버 전체
언제: 일정한 주기로, 오래 켜 둘수록
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 멈춤이 짧은 GC(ZGC, Shenandoah, 목표 시간을 줄인 G1)를 실행 옵션으로 직접 지정, 할당 줄이기, 힙 크기 조정.
인프라팀 할 일: 힙을 넉넉히 줄 수 있는 메모리의 인스턴스, 컨테이너에는 CPU 2개 이상·메모리 약 1.8GB 이상 배정(JDK 26 이하는 그보다 작으면 Serial GC를 기본으로 고름), GC 멈춤 시간 모니터링.
수치 감각: 새 객체(Young 영역)만 수집하는 Minor GC는 수~수십 ms. 살아 있는 데이터가 수 GB인 힙 전체를 수집하는 Full GC는 1초를 넘기도 합니다. ZGC는 힙 크기와 거의 상관없이 1ms 미만이고 Shenandoah도 멈춤이 힙 크기에 비례하지 않아 짧습니다.
그래프에서는: 일정 주기로 튐 · 서버 틱 시간, GC 멈춤 시간
확인할 곳: GC 로그를 켜서 멈춘 시각과 길이를 서버 틱 시간 그래프에 겹쳐 봄. Java는 시작 옵션 -Xlog:gc*(JDK 8 이하는 -XX:+PrintGCDetails)의 Pause 줄, .NET은 dotnet-counters의 GC 멈춤 지표(.NET 9 이후 dotnet.gc.pause.time, 8 이하 % Time in GC since last GC), Go는 GODEBUG=gctrace=1이 GC마다 남기는 줄을 봄
이러면 맞음: 틱이 튄 시각과 GC 멈춤 시각이 겹치고 멈춤 길이가 튄 길이와 비슷함. 서버의 모든 존·채널이 같은 순간에 튐
이러면 아님: GC 로그에 긴 멈춤이 없는데도 틱이 튀면 락·동기 호출·디스크 쓰기 같은 다른 원인. 한 존만 튀면 스크립트 엔진의 GC(mem-script-gc)나 그 존의 부하
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: Java의 G1은 한 번 멈춤 목표가 기본 200ms라, 20틱 서버에서는 틱 4개에 해당합니다. 컨테이너에 CPU를 2개 미만이나 메모리를 약 1.8GB 미만으로 주면 JDK 26 이하의 Java는 단일 스레드로 수집하는 Serial GC를 기본 GC로 골라 멈춤이 훨씬 길어집니다. C#(.NET) 서버는 보통 서버 GC와 백그라운드 GC를 켜지만 새 객체를 담는 0·1세대(Gen0·1) 수집과 압축을 동반한 Full GC는 여전히 모든 스레드를 멈춥니다. Go는 멈춤이 보통 1ms 미만이지만 할당이 많으면 메모리를 요청한 쪽이 GC 작업을 분담해야 해서 틱이 느려집니다. 어느 방식이든 할당이 수집보다 빠르면 결국 게임 스레드가 멈춥니다. G1은 Full GC로 넘어가고 ZGC는 메모리를 요청한 스레드를 수집이 끝날 때까지 멈춥니다.
실제 사례: Riot Games 2021: League of Legends EUW 5시간 장애: 부가 DB 하나가 서버 전체를 멈춤

출처 10건

Garbage-First (G1) Garbage Collector Oracle
G1 멈춤 목표 기본값 200ms(MaxGCPauseMillis), 수집 중 메모리가 바닥나면 힙 전체를 멈추고 압축하는 Full GC로 넘어감
JEP 523: Make G1 the Default Garbage Collector in All Environments OpenJDK
그동안 CPU 1개이거나 메모리 1792MB 미만이면 Serial GC를 기본으로 골랐고, JDK 27부터는 어디서나 G1이 기본
JEP 439: Generational ZGC OpenJDK
ZGC 멈춤은 1ms 이하이고 힙 크기와 무관, G1 멈춤은 수 ms~수 초. 할당이 회수보다 빠르면 할당 멈춤(allocation stall) 위험
JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) OpenJDK
Shenandoah 멈춤 시간은 힙이 200MB든 200GB든 비슷함
Background garbage collection .NET
백그라운드 GC는 2세대 수집에만 적용되고 0·1세대 수집(포그라운드 GC)은 관리 스레드를 모두 멈춤
A Guide to the Go Garbage Collector Go
Go GC는 대부분 동시에 돌고 짧은 전체 멈춤만 있음, 할당이 많으면 고루틴이 GC 일을 떠맡아(assist) 지연이 생김
JEP 271: Unified GC Logging OpenJDK
JDK 9부터 GC 로그를 통합 로깅(-Xlog)으로 다시 구현, -Xlog:gc는 예전 -XX:+PrintGC처럼 GC마다 한 줄
The java Command Oracle
예전 GC 로그 옵션을 -Xlog로 바꾸는 표: -XX:+PrintGCDetails는 -Xlog:gc*
dotnet-counters diagnostic tool .NET
.NET 9 이후는 System.Runtime 미터(dotnet.gc.pause.time 등), .NET 8 이하는 예전 EventCounter(% Time in GC since last GC 등)로 표시
runtime package Go
GODEBUG=gctrace=1: GC마다 한 줄, 단계별 벽시계 시간, GC 시작·끝의 힙 크기와 목표 힙

스크립트 엔진의 GC 멈춤 Scripting VM GC (Lua, etc.)

ID mem-script-gc · 주 담당 게임개발팀·서버 개발

C++ 서버라도 퀘스트·AI·스킬을 Lua 같은 스크립트로 돌리면, 스크립트 엔진의 GC가 도는 동안 그 존이 멈춥니다.

왜 존마다 스크립트 엔진이 퀘스트·AI·이벤트를 실행하며 임시 객체를 대량 생성 → 그러면 스크립트 엔진의 GC가 한 번에 많이 수집하면 그 존의 틱이 멈춤 → 화면에서는 특정 존·특정 이벤트 중에만 주기적으로 멈칫

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 특정 장소·채널
언제: 사람이 몰릴 때, 일정한 주기로
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 점진적·세대별 GC 설정, 틱마다 조금씩 GC 진행, 스크립트의 임시 객체 줄이기.
수치 감각: 스크립트 힙이 수백 MB로 커지면 한 번에 몰아서 하는 수집(점진적 수집을 끄거나 세대별 모드의 전체 수집)에 수십~수백 ms가 걸리기도 합니다.
그래프에서는: 일정 주기로 튐 · 존별 틱 시간, 스크립트 엔진 메모리
확인할 곳: 존별 틱 시간과, 그 존 스크립트 엔진의 메모리 사용량(Lua는 collectgarbage("count"))을 틱마다 기록해 한 그래프에 겹쳐 봄
이러면 맞음: 스크립트 메모리가 뚝 떨어지는 순간(한 번에 몰아서 수집)과 그 존의 틱 튐이 겹치고, 다른 존은 멀쩡함
이러면 아님: 스크립트 메모리 변화 없이 튀면 그 존의 부하나 락. 서버의 모든 존이 동시에 튀면 서버 GC(mem-gc)나 스왑(mem-swap)
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 1건

Lua 5.4 Reference Manual Lua.org
점진적 모드는 수집을 작은 단계로 나눠 실행 사이에 끼워 넣고(단계를 크게 잡으면 전체 멈춤), 세대별 모드의 major 수집은 모든 객체를 도는 전체 멈춤, collectgarbage("count")는 Lua가 쓰는 메모리 총량(KB)

할당 폭주 Allocation storms

ID mem-alloc · 주 담당 게임개발팀·서버 개발

이벤트 중 임시 객체를 대량으로 만들면 GC가 평소보다 훨씬 자주 돕니다.

왜 아이템 드롭·전투 로그·이벤트 보상으로 임시 객체 폭증 → 그러면 GC가 몇 배 자주 돌고 미처 버려지지 않은 객체가 Old 영역으로 넘어가 Full GC도 앞당겨짐 → 화면에서는 이벤트 때만 주기적으로 멈칫

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 서버 전체, 특정 장소·채널
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 오브젝트 풀, 재사용 버퍼, 할당 프로파일링.
그래프에서는: 인원·부하를 따라 오름 · GC 횟수, 할당 속도
확인할 곳: GC 로그(Java -Xlog:gc, Go GODEBUG=gctrace=1)로 분당 GC 횟수를 세고 .NET은 dotnet-counters의 할당량과 GC 횟수(.NET 9 이후 dotnet.gc.heap.total_allocated·dotnet.gc.collections, 8 이하 Allocation Rate·Gen 0 GC Count)를 봄. 동시 접속 수·이벤트 시각과 겹쳐 봄
이러면 맞음: 이벤트가 시작되면 할당 속도와 GC 횟수가 인원 증가보다 가파르게 늘고 짧은 멈춤이 잦아짐. 이벤트가 끝나면 원래대로 돌아옴
이러면 아님: GC 횟수는 그대로인데 한 번의 멈춤이 길어지면 살아 있는 데이터가 늘어난 것(mem-gc-thrash, mem-leak)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Garbage Collector Implementation Oracle
Young 영역이 차면 minor GC, 살아남은 객체 일부가 Old 영역으로 옮겨지고 Old가 차면 힙 전체를 수집(minor보다 훨씬 오래 걸림), -Xlog:gc는 GC마다 한 줄씩 기록
A Guide to the Go Garbage Collector Go
할당 속도가 높을수록 GC 주기가 잦아짐, GODEBUG=gctrace=1로 GC 추적 출력
dotnet-counters diagnostic tool .NET
.NET 9 이후는 dotnet.gc.heap.total_allocated·dotnet.gc.collections, .NET 8 이하는 Allocation Rate·Gen 0 GC Count로 표시

메모리 누수 Memory leak

ID mem-leak · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

해제되지 않는 메모리가 조금씩 쌓이면 며칠 뒤 GC 폭주·스왑·강제 종료가 일어납니다.

왜 접속 종료한 캐릭터 정보·이벤트 핸들러가 해제되지 않음 → 그러면 며칠에 걸쳐 여유 메모리가 줄어듦 → 화면에서는 점검 직후엔 멀쩡, 날이 갈수록 렉, 결국 서버 다운

증상: 슬로우모션, 멈춤, 접속 끊김
요인: 정체
누가 겪나: 서버 전체
언제: 오래 켜 둘수록, 저녁 피크 시간
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 힙 덤프 분석, 장시간 부하 테스트.
인프라팀 할 일: 프로세스별 메모리 사용량 추세 모니터링과 경보.
그래프에서는: 서서히 오름 · 프로세스 메모리(RSS), GC 직후 힙
확인할 곳: 게임 서버 프로세스의 메모리(pidstat -r의 RSS)를 며칠 단위로 보고, GC를 쓰는 서버는 GC 직후 남은 힙을 봄. Java는 -Xlog:gc 줄에 나오는 GC 전·후 사용량 가운데 GC 후 값, .NET은 dotnet-counters의 GC 뒤 힙 크기(.NET 9 이후 dotnet.gc.last_collection.heap.size, 8 이하 GC Heap Size)
이러면 맞음: GC 직후 남은 힙(바닥선)이 재시작 뒤 날마다 올라가고 인원이 적은 새벽에도 내려오지 않음
이러면 아님: 힙 바닥선은 평평한데 RSS만 오르면 단편화(mem-fragment)나 네이티브 메모리 쪽. 인원을 따라 오르내리면 정상 사용량
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 정기 점검으로 매주 재시작하면 누수가 가려져 오래 발견되지 않습니다. 점검이 한 번 미뤄지거나 이벤트로 인원이 늘었을 때 갑자기 드러나는 경우가 많습니다.

출처 5건

Troubleshoot Memory Leaks Oracle
실행이 점점 느려지면 누수를 의심, 결국 메모리가 바닥나 비정상 종료. 누수 분석의 핵심 자료는 힙 덤프
Debug a memory leak in .NET .NET
GC가 있어도 필요 없는 객체를 계속 참조하면 누수, 성능 저하와 OutOfMemoryException. 메모리 추세 확인과 덤프 분석
Garbage Collector Implementation Oracle
-Xlog:gc 줄은 “GC 전 사용량->GC 후 사용량(힙 크기)” 형식
dotnet-counters diagnostic tool .NET
.NET 9 이후는 dotnet.gc.last_collection.heap.size, .NET 8 이하는 GC Heap Size로 표시
pidstat(1) — Linux manual page sysstat
-r: 프로세스별 RSS(실제 램에 올라 있는 메모리)와 페이지 폴트

GC 스래싱 (힙 여유 부족) GC thrashing (heap nearly full)

ID mem-gc-thrash · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

살아 있는 데이터가 힙 한도에 가까워지면, GC가 돌아도 회수할 것이 거의 없어 GC가 쉬지 않고 반복됩니다.

왜 이벤트 인원 증가나 누수로 살아 있는 데이터가 힙 한도 가까이 참 → 그러면 GC가 조금밖에 회수하지 못해 곧바로 다시 Full GC, CPU 대부분을 GC가 씀 → 화면에서는 서버 전체가 몇 분간 슬로우모션·멈춤을 반복하다 메모리 부족으로 종료

증상: 슬로우모션, 멈춤, 접속 끊김
요인: 정체
누가 겪나: 서버 전체
언제: 저녁 피크 시간, 사람이 몰릴 때, 오래 켜 둘수록
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 힙을 피크 때 살아 있는 데이터보다 넉넉하게(보통 2배 이상) 설정, 오래 참조하는 데이터·누수 줄이기.
인프라팀 할 일: GC 시간 비율 경보, 버티지 말고 빨리 재시작, 힙을 키울 수 있게 메모리가 넉넉한 인스턴스.
수치 감각: 실행 시간의 10% 넘게 GC가 쓰면 보통 위험 신호로 봅니다. Java의 일부 GC는 시간의 98%를 GC에 쓰고도 거의 회수하지 못하면 메모리 부족 오류를 냅니다.
그래프에서는: 한도에 닿아 평평해짐 · GC 직후 힙, GC 시간 비율
확인할 곳: GC 직후 남은 힙이 최대 힙에 얼마나 가까운지와 GC에 쓴 시간 비율을 봄. Java는 -Xlog:gc 줄의 “GC 후(힙 크기)”와 Pause Full 줄의 빈도, .NET은 dotnet-counters(.NET 8 이하 % Time in GC since last GC, .NET 9 이후 dotnet.gc.pause.time 증가량), Go는 GODEBUG=gctrace=1 줄 사이 간격을 봄
이러면 맞음: GC 직후에도 힙이 최대치 가까이 남고 Full GC가 연달아 돌며 GC 시간 비율이 평소보다 크게(보통 10% 넘게) 올라감. 그동안 서버 전체 틱이 함께 느려짐
이러면 아님: GC 직후 힙에 여유가 있는데 멈춤만 길면 GC 방식·설정 쪽(mem-gc)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

The Parallel Collector Oracle
병렬 GC는 전체 시간의 98% 넘게 GC를 하고도 힙을 2% 미만 회수하면 OutOfMemoryError
Garbage-First Garbage Collector Tuning Oracle
G1은 기본(GCTimeRatio=12)으로 GC 시간을 전체의 약 8% 이하로 맞추도록 힙 크기를 정함, 힙 점유가 너무 높아 생긴 Full GC는 로그의 Pause Full (G1 Compaction Pause)로 찾음
A Guide to the Go Garbage Collector Go
기본 GOGC=100이면 목표 힙이 살아 있는 힙의 약 2배, 메모리 한도에 붙으면 GC가 쉬지 않고 도는 스래싱, GODEBUG=gctrace=1로 GC 추적 출력
Garbage Collector Implementation Oracle
-Xlog:gc 줄은 GC 종류(Pause Young, Pause Full)와 “GC 전 사용량->GC 후 사용량(힙 크기)”, 멈춘 시간
dotnet-counters diagnostic tool .NET
.NET 9 이후는 dotnet.gc.pause.time, .NET 8 이하는 % Time in GC since last GC로 표시

스왑 Swapping

ID mem-swap · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

메모리가 모자라 OS가 일부를 디스크로 내보내면, 그 메모리를 쓸 때마다 1,000배 넘게 느린 디스크를 기다립니다.

왜 사용 메모리가 실제 램을 넘음 → 그러면 OS가 일부를 디스크로 내보내고 필요할 때 다시 읽음 → 화면에서는 틱이 수백 ms로 폭증해 서버의 모든 유저가 슬로우모션·멈춤

증상: 슬로우모션, 멈춤
요인: 정체
누가 겪나: 서버 전체
언제: 오래 켜 둘수록, 저녁 피크 시간
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 프로세스 메모리 사용량에 상한(힙 크기 등)을 두고 누수 점검.
인프라팀 할 일: 게임 서버는 스왑을 쓰지 않도록 설정, 메모리 경보로 대응, 스왑을 끄면 메모리가 모자라는 순간 강제 종료(OOM)되므로 피크 사용량보다 램을 넉넉히 확보.
수치 감각: RAM 읽기 약 100ns, SSD에서 되읽기 약 100µs(1,000배), 네트워크 너머 클라우드 디스크는 약 1ms(1만 배), HDD는 10ms(10만 배).
그래프에서는: 서서히 오름 · 스왑 사용량, 스왑 인·아웃
확인할 곳: vmstat 1의 si·so 열(초당 스왑에서 읽어 들인·내보낸 양), /proc/pressure/memory의 some·full(메모리를 기다리느라 멈춘 시간 비율), 게임 서버 프로세스의 pidstat -r majflt/s(디스크에서 읽어 와야 했던 페이지 폴트)를 틱 시간과 겹쳐 봄
이러면 맞음: 렉 시각에 si가 0보다 크고 게임 서버의 majflt/s와 memory의 full 값이 함께 오름
이러면 아님: si·so가 0이고 memory 압박(PSI)도 0 근처면 스왑이 원인이 아님. 스왑이 없는데 majflt/s와 PSI가 오르면 메모리가 바닥나 코드 페이지를 다시 읽는 상태라 메모리 확보가 먼저
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: GC를 쓰는 서버는 수집할 때 힙 곳곳을 읽기 때문에, 힙 일부만 스왑돼도 GC 한 번이 수 초~수십 초로 늘어날 수 있습니다. 스왑을 끄면 스왑 때문에 느려지는 단계 없이 강제 종료(OOM)로 넘어가므로, 여유 메모리를 먼저 확보해야 합니다. 스왑이 없어도 메모리가 바닥에 가까우면 OS가 실행 파일의 코드 페이지까지 메모리에서 내렸다가 다시 읽느라, 강제 종료 전에 한동안 서버 전체가 심하게 느려질 수 있습니다.

출처 8건

Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
“Numbers Everyone Should Know”: 메인 메모리 참조 100ns, 디스크 탐색 10ms(2009년 기준)
Documentation for /proc/sys/vm/ Linux kernel
swappiness: 스왑과 파일 페이지 회수의 상대 비용, 스왑은 무작위 I/O라 비쌈
Concepts overview Linux kernel
디스크에 원본이 있는 페이지 캐시와 스왑 가능한 페이지를 회수하고 그래도 모자라면 OOM 킬러가 프로세스를 죽임
Solidigm™ D7-P5520 and D7-P5620 Product Brief Solidigm
서버용 NVMe SSD의 99.99% 지연(four-nines latency) 130µs: SSD 한 번 읽기가 100µs 안팎이라는 근거
Amazon EBS General Purpose SSD volumes AWS
클라우드 기본 디스크(gp3)의 지연은 한 자릿수 ms
vmstat(8) — Linux manual page procps-ng
si: 초당 스왑에서 읽어 들인 메모리, so: 초당 스왑으로 내보낸 메모리
PSI - Pressure Stall Information Linux kernel
/proc/pressure/memory의 some(일부 작업이 멈춘 시간 비율)과 full(모든 작업이 동시에 멈춘 시간 비율)
pidstat(1) — Linux manual page sysstat
-r: majflt/s(디스크에서 페이지를 읽어 와야 했던 폴트 수)

캐시 미스 CPU cache misses

ID mem-cache-miss · 주 담당 게임개발팀·서버 개발

데이터가 메모리 여기저기 흩어져 있으면 CPU가 매번 느린 RAM까지 가서 기다립니다.

왜 객체가 포인터로 흩어져 있고 순서 없이 접근 → 그러면 CPU 캐시에 없어서 매번 RAM에서 읽음(100배 안팎 느림) → 화면에서는 같은 일을 해도 틱 비용이 몇 배, 심하면 슬로우모션

증상: 슬로우모션
요인: 정체
누가 겪나: 서버 전체
언제: 항상, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 자주 함께 쓰는 데이터를 연속으로 배치(데이터 지향 설계).
그래프에서는: 처음부터 늘 높음 · 틱 시간, CPU 사용률
확인할 곳: 게임 서버 프로세스에 perf stat -d -p PID를 걸어 사이클당 명령어 수(insn per cycle)와 L1·LLC 캐시 미스를 재고, 틱 시간·CPU 사용률과 함께 봄
이러면 맞음: CPU를 계속 바쁘게 쓰는데 insn per cycle이 낮고 LLC 미스가 많음. 데이터 배치를 바꾼 빌드에서 같은 인원의 틱 시간이 크게 줄면 확정
이러면 아님: CPU 사용률이 낮은데 틱이 느리면 락·I/O 대기처럼 CPU 밖에서 기다리는 원인
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 2건

Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
L1 캐시 0.5ns, L2 캐시 7ns, 메인 메모리 100ns(2009년 기준): RAM까지 가면 캐시보다 한두 자릿수 느림
perf-stat(1) — Linux manual page perf
-p로 실행 중인 프로세스의 하드웨어 이벤트를 세고 insn per cycle을 보여 줌, -d는 L1·LLC 데이터 캐시 이벤트를 더함

메모리 단편화 Heap fragmentation

ID mem-fragment · 주 담당 게임개발팀·서버 개발

할당과 해제를 반복해 빈 공간이 잘게 쪼개지면, 실제로 쓰는 양보다 훨씬 많은 메모리를 점유합니다.

왜 크기가 제각각인 메모리를 여러 스레드가 오랫동안 할당·해제 → 그러면 빈 공간이 잘게 흩어져 OS에 돌려주지 못하고 사용량이 누수처럼 계속 늘어남 → 화면에서는 오래 켤수록 스왑·메모리 부족으로 느려지다 강제 종료

증상: 슬로우모션, 접속 끊김
요인: 정체
누가 겪나: 서버 전체
언제: 오래 켜 둘수록
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 크기별 메모리 풀, 단편화에 강한 할당기(jemalloc, mimalloc 등).
그래프에서는: 서서히 오름 · 프로세스 메모리(RSS)
확인할 곳: 같은 빌드의 서버 둘을 띄워 하나만 환경 변수 MALLOC_ARENA_MAX로 glibc 아레나 수를 줄이거나 jemalloc 같은 다른 할당기로 바꾸고, 며칠 동안 pidstat -r의 RSS를 비교함
이러면 맞음: 인원·개체 수는 비슷한데 바꾼 서버만 RSS 증가가 멈추거나 크게 줄어듦
이러면 아님: 할당기를 바꿔도 똑같이 오르면 해제하지 않는 메모리(mem-leak)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 누수와 모양이 같아서 힙 분석으로는 누수 지점이 안 보입니다. 리눅스 기본 할당기(glibc)는 스레드가 많은 서버에서 특히 심해, 할당기만 바꿔도 사용량이 크게 줄기도 합니다.

출처 3건

mallopt(3) — Linux manual page Linux man-pages
glibc malloc은 스레드 경합을 줄이려고 아레나를 CPU 수의 배수까지 만들고, 아레나가 많을수록 메모리 사용이 늘어남(M_ARENA_MAX로 제한, 환경 변수 MALLOC_ARENA_MAX로도 설정)
jemalloc memory allocator jemalloc
단편화 회피와 동시성 확장을 중시하는 범용 malloc 구현
pidstat(1) — Linux manual page sysstat
-r: 프로세스별 RSS(실제 램에 올라 있는 메모리)

NUMA 원격 메모리 Remote NUMA access

ID mem-numa · 주 담당 인프라팀·서버 인프라

CPU가 두 개인 서버에서 반대편 CPU에 붙은 메모리를 쓰면 접근이 느려집니다.

왜 스레드와 메모리가 서로 다른 CPU 소켓에 배치 → 그러면 메모리 접근이 느려짐(장비에 따라 1.5~2배) → 화면에서는 같은 사양인데 프로세스마다 성능 차이

증상: 슬로우모션
요인: 정체
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: 프로세스·메모리를 한 소켓에 고정(numactl), 소켓이 둘이면 소켓마다 게임 서버 프로세스를 나눠 배치.
그래프에서는: 일부만 높음 · 프로세스별 틱 시간, 노드별 메모리
확인할 곳: numastat -p PID로 게임 서버 프로세스의 메모리가 어느 NUMA 노드에 있는지, numastat의 numa_miss·other_node가 늘어나는지 보고 그 프로세스가 도는 CPU의 노드와 비교함
이러면 맞음: 느린 프로세스만 메모리 대부분이 자기가 도는 CPU와 다른 노드에 있고 numactl로 CPU·메모리를 한 노드에 고정해 다시 띄우면 차이가 사라짐
이러면 아님: 빠른 프로세스와 노드 배치가 같은데도 느리면 노이지 네이버, CPU 스로틀링, 그 프로세스의 부하 같은 다른 원인
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

What is NUMA? Linux kernel
같은 셀의 메모리는 더 빠르고 대역폭이 크며 다른(원격) 셀의 메모리는 접근이 느림
numactl(8) — Linux manual page numactl
--cpunodebind·--membind로 프로세스의 CPU와 메모리를 특정 NUMA 노드에 고정
numastat(8) — Linux manual page numactl
numa_miss(원하던 노드가 아닌 곳에 할당)·other_node(다른 노드에서 도는 프로세스가 이 노드에 할당) 카운터, -p로 프로세스의 노드별 메모리

L11 디스크

동기 로그 쓰기 Synchronous logging

ID dk-sync-log · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

게임 스레드가 로그 한 줄마다 디스크 완료를 기다리면, 디스크가 바쁠 때 게임 진행도 같이 멈춥니다.

왜 전투·거래 로그를 게임 스레드에서 바로 파일에 씀 → 그러면 확실한 저장(fsync)을 요구하거나 OS의 쓰기 버퍼(페이지 캐시)가 한도에 차면, 디스크가 바쁠 때 쓰기 한 번이 수십 ms → 화면에서는 로그 많은 전투에서 멈칫

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 비동기 로깅(메모리 버퍼 + 별도 스레드), 로그 양 줄이기, 게임 스레드에서 fsync 하지 않기.
인프라팀 할 일: 로그 로테이션·압축은 I/O 우선순위를 낮춰 실행, 로그를 데이터와 다른 디스크에, 디스크 쓰기 지연 모니터링.
그래프에서는: 가끔 무작위로 튐 · 서버 틱 시간, 디스크 쓰기 지연
확인할 곳: iostat -x 1의 w_await·aqu-sz를 틱 시간과 겹쳐 보고 perf trace -p PID --duration 10으로 게임 서버에서 10ms 넘게 걸린 write·fsync 호출과 그 스레드를 찾음
이러면 맞음: 틱이 튄 시각에 게임 스레드의 write·fsync 호출이 수십 ms 걸리고, 그 순간 디스크 쓰기 지연도 솟음. 로그 로테이션·압축 시각과 겹치는 경우가 많음
이러면 아님: 게임 스레드에 오래 걸린 시스템 호출이 없는데 틱이 튀면 GC·락·틱 예산 초과 같은 다른 원인. 로그 전용 스레드만 오래 걸리면 게임 진행에는 영향이 없음
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 보통 OS는 쓰기를 먼저 메모리(페이지 캐시)에 받아 두고 나중에 디스크로 내려보내서, 로그 한 줄은 대개 곧바로 끝납니다. 멈춤은 fsync로 확실한 저장을 요구할 때, 밀린 쓰기가 한도를 넘어 OS가 쓰기 호출을 블로킹할 때, 로그 파일을 로테이션하거나 압축할 때 생깁니다. 평소엔 멀쩡하다가 디스크가 바쁜 순간에만 튑니다.

출처 5건

fsync(2) — Linux manual page Linux man-pages
fsync는 바뀐 데이터를 디스크(디스크 캐시 포함)까지 내려보내고 장치가 완료를 알릴 때까지 블록
Documentation for /proc/sys/vm/ Linux kernel
밀린 쓰기(dirty)가 dirty_ratio에 닿으면 쓰기를 하는 프로세스가 직접 디스크 기록을 떠맡음
ionice(1) — Linux manual page util-linux
idle I/O 우선순위로 돌린 작업은 다른 프로그램이 디스크를 쓰지 않을 때만 디스크 시간을 받음
iostat(1) — Linux manual page sysstat
-x: w_await(쓰기 요청이 대기열에서 기다린 시간을 포함한 평균 처리 시간), aqu-sz(평균 대기열 길이, 예전 이름 avgqu-sz)
perf-trace(1) — Linux manual page perf
-p로 실행 중인 프로세스의 시스템 호출을 추적, --duration으로 지정한 ms보다 오래 걸린 호출만 표시

fsync 폭주 fsync storms

ID dk-fsync · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·DB 인프라

데이터를 “확실히” 디스크에 쓰도록 요청하면 디스크에 따라 한 번에 0.1ms~수십 ms가 걸리고, 몰리면 대기열이 길어집니다.

왜 정기 저장·로그아웃 러시로 확실한 쓰기 요청이 몰림 → 그러면 디스크 대기열이 길어짐 → 화면에서는 저장 시각마다 렉, 로그아웃·채널 이동 지연

증상: 뚝뚝 끊김, 입력 지연
요인: 정체, 지연
누가 겪나: 서버 전체
언제: 일정한 주기로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·DB 인프라
게임개발팀 할 일: 저장 묶어서 한 번에(여러 저장을 fsync 한 번으로), 저장 시각 분산.
인프라팀 할 일: 서버 장비·OS: 전원 보호 기능이 있는 서버용 SSD, 디스크 대기열 길이·fsync 지연 모니터링. DB 장비: 저장이 DB로 가면 DB 로그 디스크도 같은 SSD로, 커밋 지연 모니터링.
수치 감각: 한 번에 걸리는 시간은 장비마다 다르지만 대략 서버용 SSD(전원 보호 기능) 0.1ms, 보통 SSD 1~수 ms, 클라우드 디스크 1~2ms, HDD 10ms 이상. 한 스레드가 하나씩 기다리면 HDD는 1초에 100번도 못 합니다.
그래프에서는: 일정 주기로 튐 · 디스크 대기열 길이, 플러시·쓰기 지연
확인할 곳: iostat -x 1의 f/s·f_await(디스크가 처리한 플러시 수와 걸린 시간), w/s·aqu-sz·w_await를 정기 저장·로그아웃 시각과 겹쳐 봄. 예전 sysstat은 aqu-sz를 avgqu-sz로 표시함. 클라우드 디스크는 EBS의 VolumeQueueLength·VolumeAvgWriteLatency를 봄
이러면 맞음: 저장 시각·로그아웃 러시마다 플러시 수와 대기열 길이가 함께 솟고 w_await·f_await가 평소의 몇 배가 됨. 그때 저장·채널 이동이 늦어짐
이러면 아님: 저장·로그아웃과 상관없는 시각에 대기열이 솟으면 백업·압축(dk-backup)이나 IOPS 한도(dk-iops). 플러시 수는 그대로인데 느려지면 버스트 크레딧 소진(dk-burst) 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 6건

fsync(2) — Linux manual page Linux man-pages
fsync는 디스크 캐시까지 비우고 장치가 완료를 알릴 때까지 블록
Reliability (PostgreSQL Documentation) PostgreSQL
일반 SATA 디스크와 많은 SSD는 정전에 날아가는 쓰기 캐시를 가져, 확실한 저장에는 배터리·전원 보호가 있는 캐시가 필요
Amazon EBS General Purpose SSD volumes AWS
클라우드 기본 디스크(gp3) 지연은 한 자릿수 ms, io2 Block Express는 16KiB I/O 평균 500µs 미만
Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
HDD 탐색 한 번 10ms
iostat(1) — Linux manual page sysstat
-x: f/s·f_await(디스크가 처리한 플러시 요청 수와 평균 시간), w/s, w_await, aqu-sz(예전 이름 avgqu-sz)
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeQueueLength(완료를 기다리는 요청 수), VolumeAvgWriteLatency(1분 평균 쓰기 지연, Nitro 인스턴스)

클라우드 디스크 버스트 크레딧 소진 Burst credit depletion

ID dk-burst · 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라

일부 클라우드 디스크와 작은 서버 사양은 잠깐 기준보다 빠르게 쓸 수 있는 버스트 크레딧이 있어서, 바쁜 시간이 길어져 크레딧이 바닥나면 속도가 갑자기 떨어집니다.

왜 기준 성능 이상으로 오래 사용 → 그러면 버스트 크레딧이 바닥나 기준 성능으로 급락 → 화면에서는 매일 저녁 몇 시간 지나서부터 렉 시작

증상: 뚝뚝 끊김, 슬로우모션, 입력 지연
요인: 정체, 지연
누가 겪나: 서버 전체
언제: 저녁 피크 시간, 오래 켜 둘수록
담당: 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라
인프라팀 할 일: 서버 장비·OS: 성능 보장형 디스크(gp3, IOPS 지정형), 크레딧 잔량 경보, 인스턴스의 디스크 대역폭 버스트 한도와 CPU 크레딧도 함께 확인. DB 장비: 관리형 DB를 포함한 DB 디스크도 성능 보장형으로 바꾸고 크레딧 잔량 경보.
수치 감각: AWS gp2 100GB 디스크는 평소 300, 버스트 3,000 IOPS이고 크레딧이 가득 차 있으면 약 30분 버팁니다. gp3는 크레딧 없이 늘 3,000입니다. Azure의 작은 Premium SSD도 크레딧으로 최대 30분 버스트합니다.
그래프에서는: 한도에 닿아 평평해짐 · IOPS, 버스트 크레딧 잔량
확인할 곳: CloudWatch의 EBS BurstBalance(gp2·st1·sc1), 인스턴스의 EBSIOBalance%·EBSByteBalance%(버스트하는 일부 인스턴스), 버스트형 인스턴스의 CPUCreditBalance를 봄. Azure는 Data Disk Used Burst IO Credits Percentage 같은 버스트 크레딧 사용률 지표를 봄
이러면 맞음: 잔량이 0 가까이 떨어진 시각부터 IOPS(VolumeReadOps·VolumeWriteOps)가 기준 성능에서 평평해지고 VolumeQueueLength와 렉이 함께 늘어남. 피크가 몇 시간 이어진 뒤에 시작됨
이러면 아님: 잔량이 모두 넉넉한데 IOPS가 평평하면 볼륨·인스턴스의 고정 한도(dk-iops)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 디스크가 멀쩡해도 작은 가상 서버는 인스턴스의 디스크 대역폭 자체에 버스트 한도(하루 최소 30분 등)가 있어 같은 모양이 나옵니다. CPU 크레딧을 쓰는 저가형 서버도 크레딧이 바닥나면 기준 성능까지 느려집니다.

출처 7건

Amazon EBS General Purpose SSD volumes AWS
gp2 기준 성능은 GiB당 3 IOPS(최소 100), I/O 크레딧으로 3,000 IOPS까지 버스트, 크레딧 540만 개로 최소 30분. gp3는 버스트 없이 늘 3,000 IOPS
Managed disk bursting Microsoft Azure
Premium SSD P20 이하는 크레딧 기반 버스트, 크레딧이 가득 차면 최대 버스트 속도로 30분
Amazon EBS-optimized instance types AWS
일부 인스턴스는 EBS 최대 성능을 24시간에 한 번 30분만 유지하고 이후 기준 성능으로 돌아감
Standard mode for burstable performance instances AWS
표준 모드의 버스트형 인스턴스는 CPU 크레딧이 떨어지면 CPU 사용률을 기준 수준으로 (급락하지 않게 서서히) 낮춤
Amazon CloudWatch metrics for Amazon EBS AWS
BurstBalance: gp2의 I/O 크레딧, st1·sc1의 처리량 크레딧 잔량(%), VolumeReadOps·VolumeWriteOps·VolumeQueueLength
CloudWatch metrics that are available for your instances AWS
EBSIOBalance%·EBSByteBalance%: 24시간에 한 번 30분 버스트하는 일부 인스턴스의 EBS 크레딧 잔량, CPUCreditBalance: 버스트형 인스턴스의 CPU 크레딧 잔량
Disk metrics Microsoft Azure
Data Disk Used Burst IO Credits Percentage 등 디스크·VM 버스트 크레딧 사용률(5분 간격)

IOPS 한도·대기열 포화 IOPS limit / queue saturation

ID dk-iops · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 인프라팀·DB 인프라

디스크가 1초에 처리할 수 있는 요청 수를 넘으면 대기열이 길어져 지연이 폭증합니다.

왜 읽기·쓰기 요청이 디스크 처리 능력에 근접 → 그러면 대기열이 길어짐(대개 이용률 90% 이상에서 폭증) → 화면에서는 저장·로딩 지연, 동기 호출이면 멈춤

증상: 입력 지연, 멈춤
요인: 지연, 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 인프라팀·DB 인프라
게임개발팀 할 일: 요청 합치기, 자주 읽는 데이터는 캐시, 게임 스레드에서 디스크를 기다리지 않게 비동기로.
인프라팀 할 일: 서버 장비·OS: 더 빠른 디스크, 인스턴스 유형별 디스크 대역폭·IOPS 한도 확인, 디스크 이용률·대기열 경보, 큰 파일 복사는 한가한 시간에. DB 장비: DB 디스크도 IOPS·처리량 이용률 경보, DB 인스턴스 사양의 디스크 한도 확인.
수치 감각: HDD 약 150, SATA SSD 수만, NVMe 수십만 IOPS. 클라우드 기본 디스크(AWS gp3)는 3,000 IOPS, 초당 125MiB입니다. 초당 전송량 한도는 IOPS와 별도라서 큰 파일 복사가 이 한도를 채우면 작은 쓰기까지 밀립니다.
그래프에서는: 한도에 닿아 평평해짐 · IOPS, 디스크 대기열 길이
확인할 곳: iostat -x 1의 r/s·w/s, rkB/s·wkB/s, aqu-sz, r_await·w_await를 봄. 클라우드는 EBS의 VolumeReadOps·VolumeWriteOps·VolumeQueueLength와 한도 초과 여부 VolumeIOPSExceededCheck·VolumeThroughputExceededCheck, 인스턴스 쪽 InstanceEBSIOPSExceededCheck·InstanceEBSThroughputExceededCheck를 봄
이러면 맞음: 초당 요청 수나 전송량이 한도 값에서 평평해지고 aqu-sz와 await가 함께 치솟음. 클라우드에서는 초과 확인 지표가 1
이러면 아님: %util이 100%여도 await가 낮으면 아직 여유가 있을 수 있음. 요청을 병렬로 처리하는 SSD·RAID에서는 %util이 한도를 뜻하지 않음. 한도에 닿지 않았는데 await만 높으면 디스크 자체 지연(dk-hdd)이나 fsync(dk-fsync)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 클라우드에서는 디스크 한도와 별도로 서버 사양(인스턴스 유형)마다 디스크 대역폭·IOPS 한도가 있습니다. 비싼 디스크를 붙여도 서버가 작으면 인스턴스 한도에서 막힙니다.

출처 8건

Exos X18 Data Sheet Seagate
7,200rpm 서버용 HDD의 4K 무작위 읽기 170 IOPS(QD16)
D3-S4520 SSD Solidigm
서버용 SATA SSD 4KB 무작위 읽기·쓰기 최대 92K/48K IOPS
Solidigm™ D7-P5520 and D7-P5620 Product Brief Solidigm
서버용 NVMe SSD 무작위 읽기·쓰기 1,000K/200K IOPS
Amazon EBS General Purpose SSD volumes AWS
gp3 기본 성능 3,000 IOPS와 125MiB/s, 둘은 따로 늘릴 수 있는 별개 한도
Amazon EBS-optimized instance types AWS
인스턴스 유형마다 EBS 대역폭·처리량·IOPS의 기준·최대 한도가 따로 있음
iostat(1) — Linux manual page sysstat
-x: r/s·w/s, rkB/s·wkB/s, aqu-sz(예전 이름 avgqu-sz), r_await·w_await, %util. 요청을 병렬로 처리하는 RAID·최신 SSD에서는 %util이 성능 한도를 나타내지 않음
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeIOPSExceededCheck·VolumeThroughputExceededCheck: 볼륨의 IOPS·처리량 한도를 넘기려 했으면 1(Nitro 인스턴스), VolumeQueueLength
CloudWatch metrics that are available for your instances AWS
InstanceEBSIOPSExceededCheck·InstanceEBSThroughputExceededCheck: 인스턴스의 EBS IOPS·처리량 한도를 넘기려 했으면 1

디스크 가득 참 Disk full

ID dk-full · 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라, 게임개발팀·서버 개발

로그와 덤프가 쌓여 디스크가 가득 차면 쓰기가 실패하고 대비가 없으면 서버가 죽습니다.

왜 로그·덤프·임시 파일이 쌓여 100% → 그러면 쓰기 실패. 오류 처리가 없으면 크래시, 있으면 저장 실패 → 화면에서는 접속 끊김, 진행 롤백

증상: 접속 끊김, 씹힘·롤백
요인: 정체
누가 겪나: 서버 전체
언제: 오래 켜 둘수록
담당: 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라, 게임개발팀·서버 개발
게임개발팀 할 일: 쓰기 실패를 처리해 크래시 대신 저장 재시도와 경보, 불필요한 로그·덤프 줄이기.
인프라팀 할 일: 서버 장비·OS: 로그 로테이션, 용량 경보, 로그와 데이터 디스크 분리. DB 장비: DB 트랜잭션 로그(WAL, binlog)가 복제 중단·로그 백업 누락으로 쌓이지 않는지 감시.
그래프에서는: 서서히 오름 · 디스크 사용률
확인할 곳: df -h의 사용률과 df -i의 inode 사용률을 보고 서버·DB 로그에서 ENOSPC 오류를 찾음. DB는 PostgreSQL pg_replication_slots에서 active가 false인 슬롯, MySQL SHOW BINARY LOGS의 파일 수·크기, SQL Server sys.databases의 log_reuse_wait_desc, RDS는 FreeStorageSpace를 봄
이러면 맞음: 사용률이 며칠에 걸쳐 꾸준히 오르다 100%에 닿은 시각과 크래시·저장 실패 시각이 겹치고, 로그에 ENOSPC가 남음
이러면 아님: 공간이 넉넉한데 쓰기가 실패하면 권한·파일 크기 한도 같은 다른 원인
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: DB의 트랜잭션 로그(WAL, binlog 등)는 복제본이 멈추거나 로그 백업이 빠지면 지워지지 않고 계속 쌓입니다. 이 디스크가 차면 DB의 모든 쓰기가 멈춰 저장·거래가 한꺼번에 실패합니다.

출처 8건

write(2) — Linux manual page Linux man-pages
장치에 공간이 없으면 쓰기가 ENOSPC 오류로 실패
Monitoring Disk Usage (PostgreSQL Documentation) PostgreSQL
WAL 디스크가 가득 차면 DB 서버가 패닉으로 종료될 수 있음
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
복제 슬롯은 복제본이 받을 때까지 WAL을 지우지 않아 pg_wal 공간을 채울 수 있음(max_slot_wal_keep_size로 제한)
Troubleshoot a full transaction log (SQL Server Error 9002) Microsoft SQL Server
로그가 가득 차면 DB는 읽기만 되고 수정 불가, 로그 백업 누락·복제 지연·긴 트랜잭션이 로그 정리를 막는 흔한 원인, 무엇이 막는지는 sys.databases의 log_reuse_wait_desc로 확인
df(1) — Linux manual page coreutils
파일 시스템별 사용량, -i는 블록 대신 inode 사용량
pg_replication_slots (PostgreSQL Documentation) PostgreSQL
active: 지금 스트리밍 중인 슬롯인지, wal_status: 슬롯이 잡아 둔 WAL이 max_wal_size를 넘었는지
SHOW BINARY LOGS Statement MySQL
서버의 바이너리 로그 파일 목록과 파일 크기(File_size)
Amazon CloudWatch metrics for Amazon RDS AWS
FreeStorageSpace: DB 인스턴스의 남은 저장 공간

백업·압축·검사 작업 Backup / compression / scans

ID dk-backup · 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라

새벽 백업, 로그 압축, 보안 검사가 디스크를 독점하면 게임 서버의 읽기·쓰기가 밀립니다.

왜 예약된 백업·압축 작업 시작 → 그러면 디스크 대역폭과 IOPS를 대부분 차지 → 화면에서는 매일 같은 시각 렉

증상: 뚝뚝 끊김, 입력 지연
요인: 정체, 지연
누가 겪나: 서버 전체
언제: 일정한 주기로
담당: 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라
인프라팀 할 일: 서버 장비·OS: 백업·압축·검사 작업의 I/O 우선순위 낮추기, 시각 분산. DB 장비: 백업은 복제본에서.
그래프에서는: 일정 주기로 튐 · 디스크 이용률, 디스크 대기 시간
확인할 곳: sar -d로 지난 며칠 기록(/var/log/sa의 일별 파일, sadc가 -S DISK로 디스크 항목까지 모아야 함)의 %util·await·aqu-sz를 날짜별로 겹쳐 보고, 그 시각에 pidstat -d 1로 kB_rd/s·kB_wr/s가 가장 큰 프로세스를 찾아 크론·systemd 타이머 일정과 대조함
이러면 맞음: 매일 같은 시각 await와 %util이 솟고 그때 백업·압축·검사 프로세스가 디스크 읽기·쓰기 대부분을 차지함
이러면 아님: 솟는 시각이 날마다 다르면 예약 작업일 가능성이 낮음. 그 시각 I/O 대부분이 게임 서버 자신이면 저장·로그 쪽(dk-fsync, dk-sync-log)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

ionice(1) — Linux manual page util-linux
idle 클래스로 돌린 작업은 다른 프로그램이 디스크를 쓰지 않을 때만 디스크 시간을 받음
Using Replication for Backups MySQL
복제본을 멈추고 백업해도 주 DB 운영에 영향이 없음
sar(1) — Linux manual page sysstat
-d: 일별 기록 파일(기본 /var/log/sa)의 장치별 await·aqu-sz·%util, 디스크 항목은 sadc의 -S DISK 옵션으로 모아야 함
pidstat(1) — Linux manual page sysstat
-d: 프로세스별 kB_rd/s·kB_wr/s(초당 디스크 읽기·쓰기량)

서버의 지연 로딩 Lazy loading on the server

ID dk-lazy-load · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

서버가 던전·맵 데이터를 처음 요청받을 때 디스크에서 읽으면, 그 틱 동안 모두가 멈춥니다.

왜 누군가 처음으로 던전·지역에 입장 → 그러면 서버가 게임 스레드에서 데이터를 디스크에서 읽음 → 화면에서는 그 서버의 모두가 잠깐 멈춤

증상: 멈춤
요인: 정체
누가 겪나: 특정 장소·채널, 서버 전체
언제: 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 서버 시작 때 미리 로딩, 비동기 로딩.
인프라팀 할 일: 스냅샷으로 막 만든 서버는 서비스 투입 전 디스크 예열(전체 블록을 한 번 읽기) 또는 빠른 스냅샷 복원 기능 사용.
그래프에서는: 가끔 무작위로 튐 · 서버 틱 시간, 디스크 읽기
확인할 곳: 멈춘 시각을 게임 서버 로그의 던전·지역 첫 입장 기록과 맞춰 보고 그 순간 게임 서버의 디스크 읽기(pidstat -d의 kB_rd/s)와 perf trace --duration으로 오래 걸린 read·open 호출을 봄. 새로 뜬 클라우드 서버라면 EBS의 VolumeAvgReadLatency를 오래된 서버와 비교함
이러면 맞음: 처음 입장하는 순간에만 멈추고 같은 곳에 두 번째로 들어갈 때는 멈추지 않음. 멈춘 동안 게임 스레드가 파일 읽기에서 기다림
이러면 아님: 이미 로딩된 지역에서도 똑같이 멈추면 틱 예산 초과·GC 같은 다른 원인
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 클라우드에서 스냅샷(디스크 사본)으로 막 만든 서버는 처음 읽는 블록마다 원격 스토리지에서 받아 와 평소보다 훨씬 느립니다. 오토스케일링으로 새로 뜬 서버에서만 첫 입장이 유독 오래 걸린다면 이것을 의심합니다.

출처 5건

Initialize Amazon EBS volumes AWS
스냅샷으로 만든 볼륨은 블록을 S3에서 받아 오는 동안 지연이 늘고 성능이 떨어짐, dd·fio로 전체 블록을 읽어 미리 초기화
Amazon EBS fast snapshot restore AWS
빠른 스냅샷 복원은 만들 때부터 초기화된 볼륨을 줘 첫 접근 지연을 없앰
pidstat(1) — Linux manual page sysstat
-d: 프로세스별 kB_rd/s(초당 디스크 읽기량)
perf-trace(1) — Linux manual page perf
--duration으로 지정한 ms보다 오래 걸린 시스템 호출만 표시
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeAvgReadLatency: 1분 평균 읽기 지연(Nitro 인스턴스)

코어 덤프 기록 Core dump writing

ID dk-coredump · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

서버가 죽을 때 수 GB 메모리를 디스크에 기록하느라 재시작이 몇 분씩 늦어지기도 합니다.

왜 서버 크래시로 메모리 전체를 파일로 기록 → 그러면 수 GB를 쓰는 동안 재시작 불가 → 화면에서는 서버가 죽어 접속이 끊긴 뒤 한참 동안 접속 불가

증상: 접속 불가·무한 로딩
요인: 정체
누가 겪나: 서버 전체
언제: 가끔 무작위로
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 필요한 메모리만 담는 작은 덤프(미니 덤프) 방식 검토, 크래시 원인 수정.
인프라팀 할 일: 덤프 크기 제한(OS 코어 덤프 설정), 빠른 디스크, 재시작과 덤프 분리(덤프 압축·업로드는 재시작 뒤 따로 처리).
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 서버 재시작 시각
확인할 곳: 크래시 시각과 코어 파일 크기(coredumpctl list·info, 또는 core_pattern이 가리키는 곳의 파일), 파일이 다 써진 시각, 서비스가 다시 뜬 시각을 나란히 놓고 그동안 iostat -x의 wkB/s를 봄
이러면 맞음: 크래시 뒤 수 GB짜리 코어 파일을 쓰는 동안 디스크 쓰기가 한도 가까이 붙어 있고, 기록이 끝난 뒤에야 재시작이 시작됨
이러면 아님: 코어 덤프가 꺼져 있거나 작게 끝났는데도 재시작이 늦으면 맵 로딩이나 DB 콜드 캐시(db-cold-cache) 같은 서버 시작 과정 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

core(5) — Linux manual page Linux man-pages
RLIMIT_CORE로 코어 파일 크기 상한, coredump_filter로 담을 메모리 영역 선택, 코어 덤프를 프로그램으로 파이프해 따로 처리
Minidump Files Microsoft
미니 덤프는 크래시 덤프 정보의 유용한 일부만 담아 빠르고 작게 만듦
coredumpctl(1) — Linux manual page systemd
list: 저널에 남은 코어 덤프 목록(TIME은 커널이 알린 크래시 시각), info: 덤프별 상세와 디스크에 쓴 크기
iostat(1) — Linux manual page sysstat
-x: wkB/s(초당 디스크 쓰기량)

HDD 탐색 지연 HDD seek latency

ID dk-hdd · 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라, 게임개발팀·서버 개발

HDD는 헤드가 플래터 위를 움직여야(탐색, seek) 해서 흩어진 데이터를 읽고 쓰는 데 한 번에 10ms 가까이 걸립니다.

왜 오래된 서버나 저가 스토리지에서 HDD 사용 → 그러면 흩어진 읽기·쓰기마다 약 10ms → 화면에서는 전반적인 저장·로딩 지연

증상: 입력 지연
요인: 지연
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 인프라팀·서버 인프라 · 함께 인프라팀·DB 인프라, 게임개발팀·서버 개발
게임개발팀 할 일: 순차 쓰기 위주 설계.
인프라팀 할 일: 서버 장비·OS: SSD로 교체(흩어진 읽기·쓰기가 많은 저장 디스크부터). DB 장비: 흩어진 읽기·쓰기가 가장 많은 DB 디스크를 먼저 SSD로 교체.
그래프에서는: 처음부터 늘 높음 · 디스크 읽기·쓰기 지연(r_await·w_await)
확인할 곳: lsblk -d -o NAME,ROTA로 회전 디스크(HDD)인지 확인하고, iostat -x 1의 r/s·w/s와 r_await·w_await를 봄. 가상 서버는 클라우드·스토리지 사양에서 디스크 종류를 확인함
이러면 맞음: 회전 디스크이고 초당 요청이 수십~백여 개 수준인데도 r_await·w_await가 늘 수 ms~수십 ms
이러면 아님: SSD인데 지연이 높으면 대기열 포화(dk-iops)나 버스트 크레딧 소진(dk-burst) 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
디스크 탐색 한 번 10ms, 디스크에서 1MB 순차 읽기 20ms
Exos X18 Data Sheet Seagate
7,200rpm HDD 평균 회전 지연 4.16ms, 4K 무작위 읽기 170 IOPS
lsblk(8) — Linux manual page util-linux
-o로 출력 열 선택, 장치 토폴로지 열에 ROTA(회전형 여부) 포함
ABI stable symbols Linux kernel
/sys/block/(디스크)/queue/rotational: 장치가 회전형인지 비회전형인지 나타냄
iostat(1) — Linux manual page sysstat
-x: r/s·w/s, r_await·w_await(대기열에서 기다린 시간을 포함한 요청당 평균 처리 시간)

L12 데이터베이스

인덱스 없는 쿼리 Missing index / full table scan

ID db-no-index · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

인덱스 없이 조건에 맞는 행을 찾으려면 테이블 전체를 읽어야 합니다(풀 스캔).

왜 새 기능 배포로 인덱스가 없는 조건 검색 추가 → 그러면 수백만 행을 모두 스캔해 쿼리 하나에 수백 ms~수 초 → 화면에서는 우편함·거래 기록 로딩 지연, 커넥션이 묶여 다른 요청까지 대기

증상: 입력 지연, 접속 불가·무한 로딩
요인: 지연, 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 새 쿼리는 배포 전 실행 계획 검토, 인덱스 추가, 고치는 쿼리(UPDATE·DELETE)도 인덱스를 타는지 확인.
인프라팀 할 일: 느린 쿼리 로그 감시, 풀 스캔 쿼리를 찾아 게임팀에 공유, 운영 중 인덱스 추가는 잠금이 짧은 온라인 방식으로 적용.
수치 감각: 인덱스가 있으면 수 ms, 없으면 데이터 크기에 비례해 느려져 큰 테이블에서는 수백~수만 배.
그래프에서는: 어느 순간부터 계단처럼 올라감 · DB 쿼리 지연, 읽은 행 수
확인할 곳: MySQL은 slow query log(log_queries_not_using_indexes를 켜면 인덱스를 안 쓴 쿼리도 기록)의 Rows_examined·Rows_sent, performance_schema events_statements_summary_by_digest의 SUM_NO_INDEX_USED·SUM_ROWS_EXAMINED를 보고 EXPLAIN을 돌림. PostgreSQL은 pg_stat_user_tables의 seq_scan·seq_tup_read를 보고 EXPLAIN을 돌림
이러면 맞음: 배포 뒤 새로 나타난 쿼리가 돌려준 행(Rows_sent)보다 수천 배 많은 행을 읽고(Rows_examined), EXPLAIN에 테이블 전체 스캔(MySQL type ALL, PostgreSQL Seq Scan)이 나옴. 큰 테이블의 seq_tup_read가 배포 시각부터 가파르게 늘어남
이러면 아님: 인덱스를 타는데도 느리면 잠금 대기(db-hot-row, db-ddl-lock)나 실행 계획 변경(db-plan-flip). 작은 테이블의 전체 스캔은 정상일 수 있음
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 인덱스가 없으면 쓰기도 영향을 받습니다. 인덱스 없이 고치는 쿼리(UPDATE·DELETE)는 DB에 따라 스캔한 행까지 잠가 상관없는 플레이어의 저장까지 막을 수 있습니다.

출처 8건

How MySQL Uses Indexes MySQL
인덱스가 없으면 첫 행부터 테이블 전체를 읽고 테이블이 클수록 비용이 커짐
Locks Set by Different SQL Statements in InnoDB MySQL
맞는 인덱스가 없어 테이블 전체를 스캔하면 모든 행이 잠겨 다른 사용자의 추가까지 막힘
The Slow Query Log MySQL
long_query_time(기본 10초)을 넘긴 쿼리 기록, 인덱스를 안 쓰는 쿼리도 따로 기록 가능
CREATE INDEX (PostgreSQL Documentation) PostgreSQL
CONCURRENTLY로 만들면 쓰기를 막지 않고 인덱스 생성, 일반 생성은 끝날 때까지 쓰기를 막음
Statement Summary Tables MySQL
events_statements_summary_by_digest: 같은 모양 쿼리별 SUM_NO_INDEX_USED(인덱스 없이 실행한 횟수)·SUM_ROWS_EXAMINED
EXPLAIN Output Format MySQL
type이 ALL이면 테이블 전체 스캔, 보통 인덱스를 추가해 피함
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_user_tables의 seq_scan(순차 스캔 횟수)·seq_tup_read(순차 스캔으로 읽은 행 수)
Using EXPLAIN (PostgreSQL Documentation) PostgreSQL
Seq Scan: 테이블의 모든 행을 차례로 읽는 실행 계획

핫 로우 잠금 경합 Hot row lock contention

ID db-hot-row · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

모두가 같은 행(길드 창고, 경매장 인기 아이템, 서버 전체 카운터)을 고치려 하면 한 명씩만 잠금을 얻습니다.

왜 이벤트·인기 아이템으로 같은 행에 수정이 몰림 → 그러면 잠금을 얻을 때까지 요청이 대기 → 화면에서는 거래 실패, “잠시 후 다시 시도”, 타임아웃

증상: 씹힘·롤백, 입력 지연
요인: 정체, 지연
누가 겪나: 특정 기능만
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 행을 나누기(샤딩된 카운터), 트랜잭션 짧게, 메모리에서 모아 한 번에 반영.
인프라팀 할 일: 행 잠금 대기 시간·건수를 모니터링해 경합이 몰리는 행을 찾아 공유.
수치 감각: 한 요청이 잠금을 10ms 잡고 있으면 그 행은 1초에 최대 100번만 고칠 수 있습니다. 트랜잭션 안에 다른 서버 왕복이 끼면 그만큼 더 줄어듭니다.
그래프에서는: 인원·부하를 따라 오름 · 행 잠금 대기 수·시간
확인할 곳: MySQL은 Innodb_row_lock_waits·Innodb_row_lock_time 증가량과 Innodb_row_lock_current_waits를 보고, sys.innodb_lock_waits로 누가 누구를 기다리는지 찾음. PostgreSQL은 pg_stat_activity에서 wait_event_type이 Lock인 세션, pg_locks에서 granted가 false인 요청을 보고 log_lock_waits(기본 꺼짐)를 켜면 오래 기다린 잠금이 로그에 남음
이러면 맞음: 이벤트·인원을 따라 잠금 대기가 가파르게 늘고 기다리는 요청 대부분이 같은 테이블의 같은 행(같은 키)을 가리킴
이러면 아님: 대기가 여러 테이블·행에 고르게 흩어지면 디스크·CPU 포화 쪽. 한 세션이 잠금을 오래 잡고 놓지 않으면 오래 열린 트랜잭션(db-long-tx)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 7건

InnoDB Locking MySQL
한 트랜잭션이 행(인덱스 레코드)에 잠금을 걸면 다른 트랜잭션은 그 행을 고치지 못하고 기다림
How to Minimize and Handle Deadlocks MySQL
트랜잭션을 작고 짧게 유지하고 관련 변경 직후 바로 커밋해 충돌을 줄이라는 권고
Server Status Variables MySQL
Innodb_row_lock_waits·Innodb_row_lock_time으로 행 잠금 대기 횟수와 시간, Innodb_row_lock_current_waits로 지금 기다리는 수를 확인
The innodb_lock_waits and x$innodb_lock_waits Views MySQL
기다리는 쿼리(waiting_query)와 막고 있는 세션(blocking_pid), 대기 시간(wait_age)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity의 wait_event_type: Lock이면 무거운 잠금을 기다리는 중
pg_locks (PostgreSQL Documentation) PostgreSQL
granted가 false면 그 프로세스가 잠금을 얻으려고 기다리는 중
Error Reporting and Logging (PostgreSQL Documentation) PostgreSQL
log_lock_waits: deadlock_timeout보다 오래 잠금을 기다리면 로그를 남김, 기본 꺼짐

DB 데드락 Database deadlock

ID db-deadlock · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

두 트랜잭션(한 묶음으로 처리되는 DB 작업)이 서로 상대가 잠근 행을 기다리면 DB가 한쪽을 강제로 취소합니다.

왜 거래 A는 아이템→재화, B는 재화→아이템 순서로 잠금 → 그러면 DB가 데드락을 감지해 한쪽을 롤백 → 화면에서는 거래·제작이 가끔 실패, 아이템이 되돌아감

증상: 씹힘·롤백, 입력 지연
요인: 손실, 정체
누가 겪나: 특정 기능만
언제: 사람이 몰릴 때, 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 잠금 순서 통일, 트랜잭션 짧게, 실패 시 자동 재시도.
인프라팀 할 일: 데드락 감지를 켜 두고 데드락 기록을 수집해 공유, 감지를 끈 MySQL 서버는 잠금 대기 한도(기본 50초) 줄이기.
수치 감각: 감지까지 MySQL(InnoDB)은 거의 즉시, PostgreSQL은 기본 1초, SQL Server는 최대 5초쯤 걸립니다. 그동안 두 요청 모두 멈춰 있습니다. 동시 요청이 아주 많아 MySQL의 감지를 꺼 둔 서버라면 잠금 대기 한도(기본 50초)까지 기다립니다.
그래프에서는: 가끔 무작위로 튐 · 데드락 수, 거래 실패 수
확인할 곳: MySQL은 SHOW ENGINE INNODB STATUS의 LATEST DETECTED DEADLOCK(가장 최근 1건), innodb_print_all_deadlocks를 켜면 에러 로그에 남는 모든 데드락, INFORMATION_SCHEMA.INNODB_METRICS의 lock_deadlocks를 봄. PostgreSQL은 pg_stat_database의 deadlocks, SQL Server는 기본으로 켜진 system_health 세션의 xml_deadlock_report를 봄. 게임 서버 쪽 오류 코드는 MySQL 1213, PostgreSQL 40P01, SQL Server 1205
이러면 맞음: 거래·제작 실패 시각에 데드락 수가 늘고 기록된 두 트랜잭션이 같은 테이블들을 서로 반대 순서로 잠그고 있음
이러면 아님: 데드락 수는 그대로인데 실패하면 잠금 대기 한도 초과(MySQL 오류 1205)나 핫 로우(db-hot-row)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 10건

InnoDB Startup Options and System Variables MySQL
감지가 켜져 있으면(기본) InnoDB는 데드락을 즉시 감지해 롤백, innodb_lock_wait_timeout 기본 50초
Deadlock Detection MySQL
동시성이 아주 높으면 감지 자체가 느려질 수 있어 끄고 잠금 대기 한도에 맡기기도 함
Lock Management (PostgreSQL Documentation) PostgreSQL
deadlock_timeout 기본 1초: 이만큼 잠금을 기다린 뒤에야 데드락 검사
Deadlocks guide Microsoft SQL Server
데드락 검사 기본 간격 5초, 데드락이 자주 나면 100ms까지 줄어듦, 기본으로 켜진 system_health 세션이 xml_deadlock_report를 수집, 희생된 쪽은 오류 1205
How to Minimize and Handle Deadlocks MySQL
여러 행·테이블은 늘 같은 순서로 고치기, 실패하면 다시 시도, innodb_print_all_deadlocks로 모든 데드락 기록
InnoDB Standard Monitor and Lock Monitor Output MySQL
LATEST DETECTED DEADLOCK: 가장 최근 데드락의 두 트랜잭션, 잡은·기다린 잠금, 롤백한 쪽
InnoDB INFORMATION_SCHEMA Metrics Table MySQL
INNODB_METRICS의 lock_deadlocks 카운터(기본 활성)
Server Error Message Reference MySQL
1213 ER_LOCK_DEADLOCK(데드락), 1205 ER_LOCK_WAIT_TIMEOUT(잠금 대기 한도 초과)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_database의 deadlocks: 이 DB에서 감지한 데드락 수
PostgreSQL Error Codes (PostgreSQL Documentation) PostgreSQL
40P01 deadlock_detected

커넥션 풀 고갈 Connection pool exhaustion

ID db-pool · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

DB와 맺어 둔 연결 수가 정해져 있어서 느린 쿼리가 연결을 점유하면 나머지는 대기합니다.

왜 느린 쿼리나 요청 폭주로 모든 연결이 사용 중 → 그러면 새 요청은 연결이 날 때까지 대기 → 화면에서는 로그인 무한 로딩, 저장 지연, 타임아웃

증상: 접속 불가·무한 로딩, 입력 지연
요인: 정체, 지연
누가 겪나: 서버 전체, 특정 기능만
언제: 접속·점검 직후, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 느린 쿼리 제거, 풀 크기와 대기 타임아웃 조정(풀을 무작정 키우지 않기), 기능별 풀 분리.
인프라팀 할 일: DB의 최대 연결 수와 CPU·IOPS 여유 확인, 증설·오토스케일링 전에 서버 수 × 풀 크기가 최대 연결 수 안인지 확인, 커넥션 대기·락 대기 지표를 모니터링에 추가.
수치 감각: 필요한 연결 수는 “초당 요청 × 한 건이 연결을 점유하는 시간”으로 어림합니다. 1초에 2,000건, 건당 5ms면 평균 10개가 늘 바쁩니다. 몰릴 때를 생각해 보통 그 두세 배를 둡니다. 쿼리가 150ms로 느려지면 같은 요청에 300개가 필요해집니다.
그래프에서는: 한도에 닿아 평평해짐 · 사용 중 DB 연결 수, 커넥션 대기 시간
확인할 곳: DB 쪽에서 게임 서버별 연결 상태를 셈. MySQL은 SHOW PROCESSLIST의 Host·Command(쉬는 연결은 Sleep)·Time과 Threads_connected·Threads_running, 거부된 연결 수 Connection_errors_max_connections를 봄. PostgreSQL은 pg_stat_activity를 client_addr·state로 묶어 셈. 게임 서버의 커넥션 풀 라이브러리가 대기 수·대기 시간을 내보내면 함께 봄
이러면 맞음: 한 게임 서버의 연결이 풀 크기만큼 모두 쿼리 실행 중이고 쉬는 연결이 0인 동안 로그인·저장이 대기함. 또는 DB 전체 연결 수가 max_connections에 닿아 새 연결이 거부됨
이러면 아님: 쉬는 연결이 넉넉한데도 느리면 쿼리 자체의 지연(db-no-index, db-hot-row)이나 DB 자원 포화 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 풀을 무작정 키우면 DB CPU와 잠금 경쟁만 늘어 모두가 같이 느려집니다. 또 서버 수 × 풀 크기가 DB의 최대 연결 수를 넘으면, 증설한 서버나 재시작한 서버가 연결조차 못 맺습니다. 오토스케일링이나 점검 직후에 흔합니다.

출처 6건

Number Of Database Connections PostgreSQL
DB 자원을 다 쓴 뒤에는 연결을 늘려도 처리량이 오히려 떨어짐, 활성 연결을 자원에 맞추고 나머지는 대기열에 두는 편이 지연·처리량 모두 좋음
Too many connections MySQL
max_connections를 모두 쓰면 새 연결이 Too many connections 오류로 거부됨
Connections and Authentication (PostgreSQL Documentation) PostgreSQL
max_connections: 동시 연결 수 상한, 기본은 보통 100
SHOW PROCESSLIST Statement MySQL
Host(클라이언트 주소), Command(쉬는 세션은 Sleep), Time, State
Server Status Variables MySQL
Threads_connected·Threads_running, Connection_errors_max_connections(max_connections에 닿아 거부된 연결 수)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: 연결마다 client_addr와 state(active, idle, idle in transaction 등)

복제 지연 Replication lag

ID db-replica-lag · 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발

쓰기는 주 DB에, 읽기는 복제본에서 하는데 복제본이 늦게 따라오면 방금 쓴 내용이 안 보입니다.

왜 주 DB에 쓰기가 몰려 복제본이 수 초 뒤처짐 → 그러면 방금 저장한 내용을 복제본에서 읽으면 아직 없음 → 화면에서는 방금 산 아이템이 안 보임, 거래소 가격이 옛날 값, 중복 지급 버그

증상: 씹힘·롤백
요인: 지연
누가 겪나: 특정 기능만
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 방금 쓴 데이터는 주 DB에서 읽기, 지급 여부 확인과 지급은 주 DB에서 한 트랜잭션으로(유니크 키나 조건부 UPDATE로 중복 차단).
인프라팀 할 일: 복제 지연 경보, 복제본 사양을 주 DB 이상으로 두고 병렬 복제 적용, 대량 삭제는 잘게 나눠 실행, 복제본에서 오래 도는 집계 쿼리 관리.
그래프에서는: 인원·부하를 따라 오름 · 복제 지연(초)
확인할 곳: MySQL은 복제본에서 SHOW REPLICA STATUS의 Seconds_Behind_Source(8.0.22 이전 버전은 SHOW SLAVE STATUS)를 봄. PostgreSQL은 주 서버 pg_stat_replication의 write_lag·flush_lag·replay_lag, RDS는 ReplicaLag를 봄
이러면 맞음: “안 보인다”는 제보 시각에 지연이 수 초 이상이고 지연이 풀린 뒤 다시 보면 정상. 쓰기 폭주나 대량 삭제, 복제본의 긴 집계 쿼리 시각에 지연이 커짐
이러면 아님: 지연이 0 근처인데도 안 보이면 게임 서버의 캐시나 동기화 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 쓰기가 많지 않아도 뒤처질 수 있습니다. 주 DB에서 10분 걸린 대량 삭제 하나는 복제본에서도 다시 실행되므로 복제본이 그만큼 뒤처집니다. 복제본에서 오래 도는 집계 쿼리도 따라가기를 늦춥니다.

출처 6건

SHOW REPLICA STATUS Statement MySQL
Seconds_Behind_Source: 복제본이 지금 적용 중인 이벤트가 주 DB에서 기록된 시각과의 차이(복제 지연)
Replica Server Options and Variables MySQL
replica_parallel_workers로 여러 스레드가 트랜잭션을 병렬 적용(기본 4, 0이면 한 스레드가 순서대로)
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
스트리밍 복제는 기본 비동기라 커밋과 복제본 반영 사이에 지연이 있음(복제본이 따라갈 수 있으면 보통 1초 미만)
MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement MySQL
8.0.22부터 SHOW SLAVE STATUS 대신 SHOW REPLICA STATUS, 그 이전 버전은 SHOW SLAVE STATUS
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_replication의 write_lag·flush_lag·replay_lag: 주 서버가 WAL을 기록한 뒤 복제본이 쓰고·디스크에 내리고·적용했다고 알릴 때까지 걸린 시간
Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag: 읽기 복제본이 원본보다 뒤처진 시간(초)

체크포인트·로그 플러시 Checkpoint / log flush stalls

ID db-checkpoint · 주 담당 인프라팀·DB 인프라

DB가 메모리의 변경분을 주기적으로 디스크에 몰아서 쓰는 순간 쿼리가 느려집니다.

왜 변경분이 쌓여 주기적으로 디스크에 기록 → 그러면 그 순간 디스크가 바빠져 쿼리 지연 → 화면에서는 주기적으로 저장·로딩이 느려짐

증상: 입력 지연, 뚝뚝 끊김
요인: 지연
누가 겪나: 서버 전체, 특정 기능만
언제: 일정한 주기로
담당: 주 담당 인프라팀·DB 인프라
인프라팀 할 일: 체크포인트를 잘게 나눠 고르게, 트랜잭션 로그(redo 로그, WAL)를 넉넉하게, 빠른 디스크.
그래프에서는: 일정 주기로 튐 · DB 쿼리 지연, 디스크 쓰기량
확인할 곳: PostgreSQL은 log_checkpoints(최근 버전은 기본으로 켜짐) 로그의 체크포인트 시각과 쓴 버퍼 수, 체크포인트 횟수(17 이후 pg_stat_checkpointer의 num_timed·num_requested, 16 이하 pg_stat_bgwriter의 checkpoints_timed·checkpoints_req), checkpoint_warning 경고를 봄. MySQL은 SHOW ENGINE INNODB STATUS의 LOG 섹션에서 Log sequence number와 Last checkpoint at의 차이를 봄. 서버의 디스크 쓰기량·쓰기 지연을 함께 겹침
이러면 맞음: 쿼리 지연이 튄 시각이 체크포인트 시각과 겹치고 그때 디스크 쓰기량과 쓰기 지연이 솟음. PostgreSQL에서 요청 체크포인트(num_requested)가 시간 체크포인트(num_timed)보다 훨씬 많으면 WAL이 max_wal_size에 자주 닿아 체크포인트가 앞당겨지는 것으로 봄
이러면 아님: 체크포인트 시각과 무관한 주기로 튀면 백업·배치(dk-backup, db-batch)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 변경 기록을 담는 트랜잭션 로그(MySQL의 redo 로그, PostgreSQL의 WAL)를 너무 작게 잡으면, 로그가 찰 때마다 DB가 급하게 체크포인트를 몰아 하느라 쓰기 처리량이 잠깐씩 크게 떨어집니다.

출처 7건

WAL Configuration (PostgreSQL Documentation) PostgreSQL
체크포인트는 기본 5분 또는 WAL 1GB(max_wal_size)마다, 더티 페이지를 모두 써서 비쌈. checkpoint_completion_target으로 쓰기를 나눠 I/O 폭주를 피함. 체크포인트 간격이 checkpoint_warning보다 짧으면 max_wal_size를 늘리라는 경고를 로그에 남김
Configuring Buffer Pool Flushing MySQL
redo 로그가 차면 급한(sharp) 체크포인트로 처리량이 잠깐 떨어짐, 적응형 플러시로 고르게 나눠 씀
Error Reporting and Logging (PostgreSQL Documentation) PostgreSQL
log_checkpoints: 체크포인트마다 쓴 버퍼 수와 걸린 시간을 로그에 남김, 기본 켜짐
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_checkpointer의 num_timed(시간이 되어 한 체크포인트)·num_requested(요청된 체크포인트)
PostgreSQL 17 Release Notes PostgreSQL
pg_stat_checkpointer 신설, 체크포인트 관련 열을 pg_stat_bgwriter에서 옮김
The Cumulative Statistics System (PostgreSQL 16 Documentation) PostgreSQL
16까지는 pg_stat_bgwriter의 checkpoints_timed·checkpoints_req
InnoDB Standard Monitor and Lock Monitor Output MySQL
LOG 섹션: 현재 로그 시퀀스 번호와 마지막 체크포인트 위치

콜드 캐시 (재시작 직후) Cold buffer pool after restart

ID db-cold-cache · 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발

DB를 재시작하면 메모리 캐시가 비어 있어서 한동안 조회하는 데이터를 모두 디스크에서 읽습니다.

왜 점검으로 DB 재시작 → 그러면 자주 쓰던 데이터가 메모리에 없어 디스크에서 읽음 → 화면에서는 점검 직후 한동안 로그인·로딩이 느림

증상: 접속 불가·무한 로딩, 입력 지연
요인: 지연
누가 겪나: 서버 전체
언제: 접속·점검 직후
담당: 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 점진적 오픈(로그인 대기열로 로그인 인원을 단계적으로 늘리기).
인프라팀 할 일: 재시작 후 캐시 예열(워밍, 버퍼 풀 저장·복원 설정 확인), 스냅샷으로 되살린 DB는 디스크도 미리 읽기.
그래프에서는: 접속·점검 직후 폭증 · 디스크 읽기, 버퍼 캐시 적중률
확인할 곳: MySQL은 Innodb_buffer_pool_reads(버퍼 풀에 없어 디스크에서 읽은 횟수)와 Innodb_buffer_pool_read_requests의 비율, 예열 진행 상황 Innodb_buffer_pool_load_status를 봄. PostgreSQL은 pg_stat_database의 blks_read·blks_hit을 봄. DB 서버의 디스크 읽기 수도 함께 봄
이러면 맞음: 재시작 직후 디스크 읽기가 솟고 적중률이 낮았다가 시간이 지나며 회복되고 그 구간에 로그인·로딩이 느림
이러면 아님: 적중률이 평소와 같은데 점검 직후 느리면 로그인 폭주·N+1(db-login-storm)이나 커넥션 풀(db-pool)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: MySQL은 꺼질 때 버퍼 풀의 페이지 목록을 저장했다가 켜질 때 백그라운드에서 다시 읽어 오지만, 다 채우기까지는 시간이 걸립니다. 클라우드에서 DB를 스냅샷(디스크 사본)으로 되살렸다면 디스크 자체도 처음 읽는 블록마다 느려서 더 오래 갑니다.
실제 사례: Roblox 2021: Roblox 73시간 장애: 서비스 디스커버리(Consul) 클러스터의 경합

출처 5건

Saving and Restoring the Buffer Pool State MySQL
재시작 뒤 예열 시간을 줄이려고 꺼질 때 최근 쓴 페이지 목록(기본 25%)을 저장하고 켜질 때 다시 읽음, 둘 다 기본으로 켜져 있음
pg_prewarm — preload relation data into buffer caches PostgreSQL
공유 버퍼 내용을 주기적으로 기록해 두었다가 재시작 뒤 다시 올림(autoprewarm)
Initialize Amazon EBS volumes AWS
스냅샷에서 만든 볼륨은 모든 블록을 받아 올 때까지 지연이 늘고 성능이 떨어짐
Server Status Variables MySQL
Innodb_buffer_pool_reads(버퍼 풀에 없어 디스크에서 직접 읽은 논리 읽기 수), Innodb_buffer_pool_read_requests, Innodb_buffer_pool_load_status(예열 진행 상황)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_database의 blks_read(디스크에서 읽은 블록 수)·blks_hit(버퍼 캐시에서 찾은 블록 수)

대량 배치 작업 Batch jobs during service

ID db-batch · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

랭킹 집계, 우편 일괄 발송, 오래된 데이터 정리를 운영 중에 돌리면 잠금과 디스크를 차지합니다.

왜 운영 시간에 대량 작업 실행 → 그러면 넓은 범위 잠금, 디스크·CPU 점유 → 화면에서는 특정 시간대 거래·저장 실패, 로딩 지연

증상: 입력 지연, 씹힘·롤백
요인: 지연, 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 일정한 주기로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 잘게 나눠 조금씩, 집계는 복제본에서.
인프라팀 할 일: 집계용 복제본 제공, 배치는 한가한 시간대로 예약, 잠금 에스컬레이션·갭 락 대기 감시.
그래프에서는: 일정 주기로 튐 · DB 쿼리 지연, 잠금 대기
확인할 곳: 렉 시각에 돌던 긴 쿼리를 찾음. MySQL은 slow query log, PostgreSQL은 pg_stat_activity의 query_start·query를 보고, 같은 시각의 잠금 대기 지표와 배치 일정(크론, DB 이벤트 스케줄러)을 대조함. SQL Server는 lock_escalation 확장 이벤트로 잠금 에스컬레이션을 기록함
이러면 맞음: 매번 같은 시각 대량 UPDATE·DELETE·집계 쿼리가 돌고 그동안 잠금 대기와 디스크 이용률이 함께 오름
이러면 아님: 그 시각에 긴 쿼리가 없으면 체크포인트(db-checkpoint)나 서버 백업(dk-backup)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: SQL Server는 한 문장이 행 잠금을 약 5,000개 넘게 잡으면 테이블 잠금으로 바꿉니다(잠금 에스컬레이션). 그 순간 같은 테이블을 쓰는 모든 요청이 멈춥니다. MySQL도 기본 설정에서 범위 조건으로 고치면 행 사이 빈틈까지 잠가(갭 락) 새 행 추가를 막습니다.

출처 4건

Transaction Locking and Row Versioning Guide Microsoft SQL Server
한 문장이 한 테이블(또는 인덱스)에서 잠금을 5,000개 이상 잡으면 잠금 에스컬레이션, lock_escalation 확장 이벤트로 기록
InnoDB Locking MySQL
InnoDB 기본 격리 수준 REPEATABLE READ에서는 검색·스캔에 next-key 잠금을 써서, 갭 락이 그 빈틈의 새 행 추가를 막음
The Slow Query Log MySQL
long_query_time을 넘긴 쿼리를 실행 시간(Query_time)·잠금 시간(Lock_time)·읽은 행 수와 함께 기록
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: 세션마다 지금 실행 중인 쿼리(query)와 시작 시각(query_start)

DB 장애 전환 Database failover

ID db-failover · 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발

주 DB가 죽어 예비 DB로 전환되는 동안 쓰기가 안 되고 복제되지 못한 마지막 데이터는 사라질 수 있습니다.

왜 주 DB 장애로 예비 DB가 승격 → 그러면 전환 중 수 초~몇 분 쓰기 불가, 비동기 복제라면 미복제 데이터 유실 가능 → 화면에서는 잠깐 모든 저장 실패, 아이템·경험치 롤백

증상: 씹힘·롤백, 멈춤, 접속 끊김, 접속 불가·무한 로딩
요인: 정체, 손실
누가 겪나: 서버 전체
언제: 가끔 무작위로
담당: 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 재시도 가능한 저장, 끊긴 연결을 빨리 버리고 새 주소로 다시 맺는 설정(커넥션 풀·DNS 캐시), 전환 훈련 때 재연결 확인.
인프라팀 할 일: 동기·반동기 복제(쓰기 지연과 맞바꿈), 전환 훈련, 전환 시간·복제 지연 모니터링.
수치 감각: 관리형 DB의 자동 전환은 보통 수십 초~2분. 비동기 복제라면 복제 지연만큼(1초 미만~수 초) 최근 저장을 잃을 수 있습니다.
그래프에서는: 연결이 한꺼번에 끊김 · DB 연결 수, 쓰기 오류 수
확인할 곳: DB 쪽 장애 전환 기록(RDS는 이벤트 RDS-EVENT-0013 전환 시작·RDS-EVENT-0049 전환 완료, 직접 운영하는 DB는 승격 로그)과 게임 서버의 DB 연결 수·연결 오류 수를 한 그래프에 놓음. 비동기 복제라면 장애 직전의 복제 지연(RDS ReplicaLag, PostgreSQL pg_stat_replication의 replay_lag)도 봄
이러면 맞음: 저장 실패가 한 구간에 몰리고 그 구간이 장애 전환 시작·완료 사이와 겹침. 되돌아간 양이 장애 직전 복제 지연과 비슷함. 전환이 끝난 뒤에도 오류가 이어지는 게임 서버는 옛 주소로 맺은 연결을 계속 쓰고 있는 것
이러면 아님: 전환 기록이 없는 시각의 연결 끊김은 네트워크나 DB 과부하 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: Riot Games 2021: League of Legends EUW 5시간 장애: 부가 DB 하나가 서버 전체를 멈춤

출처 7건

Failing over a Multi-AZ DB instance for Amazon RDS AWS
Multi-AZ 전환은 보통 60~120초, 전환 뒤 연결을 다시 맺어야 하고 JVM의 DNS 캐시 TTL은 60초 이하 권장
High availability for Amazon Aurora AWS
장애 중 읽기·쓰기가 실패하고 보통 60초 안(흔히 30초 안)에 복구
Semisynchronous Replication MySQL
비동기 복제는 주 DB가 죽으면 커밋한 트랜잭션이 복제본에 없을 수 있음, 반동기는 복제본 하나의 수신 확인을 기다려 줄이는 대신 지연이 늘어남
Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
로그 전달은 비동기라 주 서버가 죽으면 아직 보내지 못한 트랜잭션을 잃음, 스트리밍 복제 지연은 보통 1초 미만
Amazon RDS event categories and event messages AWS
RDS-EVENT-0013: Multi-AZ 장애 전환 시작, RDS-EVENT-0049: Multi-AZ 장애 전환 완료
Amazon CloudWatch metrics for Amazon RDS AWS
ReplicaLag: 읽기 복제본이 원본보다 뒤처진 시간(초)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_replication의 replay_lag: 주 서버가 WAL을 기록한 뒤 복제본이 적용했다고 알릴 때까지 걸린 시간

긴 저장 주기로 인한 진행 유실 Periodic save window

ID db-save-interval · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

부하를 줄이려 몇 분에 한 번만 저장하면, 그 사이 서버가 죽을 때 진행이 사라집니다.

왜 캐릭터 상태를 몇 분마다 한 번 저장 → 그러면 그 사이 서버 크래시·장애 발생 → 화면에서는 다시 접속하니 몇 분 전 상태(롤백)

증상: 씹힘·롤백
요인: 손실
누가 겪나: 서버 전체, 특정 장소·채널
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 중요 이벤트(거래, 희귀 획득)는 즉시 저장, 변경 로그 기록.
인프라팀 할 일: 저장 주기를 줄였을 때 늘어나는 쓰기를 감당할 DB의 IOPS·CPU 여유 확인.
그래프에서는: 연결이 한꺼번에 끊김 · 접속 수, 롤백 신고 수
확인할 곳: 크래시·장애 시각과, 롤백을 신고한 캐릭터의 마지막 저장 시각(게임 서버의 저장 로그나 DB의 수정 시각 컬럼)을 나란히 놓음
이러면 맞음: 되돌아간 시점이 크래시 직전의 마지막 저장 시각과 일치하고 잃은 시간이 저장 주기보다 짧음
이러면 아님: 게임 서버 로그에는 저장이 끝났다고 남아 있는데도 되돌아갔으면 DB 장애 전환의 데이터 유실(db-failover)이나 복제본에서 읽은 옛 값(db-replica-lag)
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Asynchronous Commit (PostgreSQL Documentation) PostgreSQL
기록을 모아 늦게 내리면 처리량이 오르는 대신, 장애 때 가장 최근 트랜잭션이 사라질 수 있음(같은 맞바꿈)
Redis persistence Redis
RDB 스냅샷을 몇 분마다 만들면 비정상 종료 때 마지막 몇 분의 데이터를 잃을 각오를 해야 함

캐시 스탬피드 Cache stampede / thundering herd

ID db-cache-stampede · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

인기 데이터의 캐시가 동시에 만료되면 수천 개 요청이 한꺼번에 DB로 몰립니다.

왜 Redis 등에 저장된 인기 데이터가 동시에 만료 → 그러면 같은 데이터를 다시 만들려는 요청이 DB로 한꺼번에 몰림 → 화면에서는 DB 과부하로 여러 기능이 줄줄이 느려지거나 멈춤

증상: 입력 지연, 멈춤, 접속 불가·무한 로딩
요인: 정체, 지연
누가 겪나: 서버 전체
언제: 일정한 주기로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 만료 시각을 무작위로 분산, 한 요청만 갱신하고 나머지는 옛 값 사용.
인프라팀 할 일: Redis 재시작·장애 때 캐시가 통째로 비지 않게 복제본·자동 전환 구성, 캐시가 비어도 버틸 DB 여유 확인.
그래프에서는: 일정 주기로 튐 · 캐시 적중률, DB 초당 쿼리 수
확인할 곳: Redis INFO의 keyspace_hits·keyspace_misses(적중률), expired_keys, 재시작 여부(uptime_in_seconds)를 DB 초당 쿼리 수와 겹쳐 보고, 그 순간 DB에서 같은 쿼리가 동시에 몇 개 도는지(MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity) 셈
이러면 맞음: 캐시 미스가 한순간 치솟는 시각에 DB 쿼리 수가 함께 솟고 동시에 도는 쿼리 대부분이 같은 데이터를 읽는 같은 쿼리임. 인기 키의 만료 주기나 Redis 재시작 시각과 겹침
이러면 아님: 캐시 미스는 평소와 같은데 DB 쿼리만 늘면 로그인 폭주(db-login-storm)나 배치(db-batch)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: Redis가 재시작되거나 장애로 캐시가 통째로 비어도 같은 일이 생깁니다. 캐시를 믿고 DB를 작게 잡아 둔 구조일수록 위험합니다.

출처 6건

Scaling Memcache at Facebook (NSDI '13) USENIX
자주 쓰는 키가 무효화되면 많은 읽기가 DB로 몰리는 thundering herd, 리스(한 클라이언트만 갱신)·옛 값 반환으로 막음, 캐시가 빈 클러스터는 따로 예열
Optimal Probabilistic Cache Stampede Prevention VLDB Endowment
인기 항목이 만료되면 여러 요청이 동시에 재생성하는 캐시 스탬피드, 만료 전에 확률적으로 미리 갱신해 막음
High availability with Redis Sentinel Redis
주 서버가 죽으면 복제본을 승격하는 자동 전환
INFO Redis
keyspace_hits·keyspace_misses(키 조회 성공·실패 수), expired_keys(만료된 키 수), uptime_in_seconds(시작 뒤 지난 시간)
SHOW PROCESSLIST Statement MySQL
세션마다 실행 중인 문장(Info)과 현재 상태에 머문 시간(Time, 초)
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity: 세션마다 지금 실행 중인 쿼리(query)

오래 열린 트랜잭션 Long-running transaction / MVCC purge lag

ID db-long-tx · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

트랜잭션 하나가 오래 열려 있으면 잠금을 계속 잡고 있고 DB가 옛 버전 데이터를 정리(purge)하지 못해 전체가 점점 느려집니다.

왜 트랜잭션을 연 채 다른 서버 응답을 기다리거나, 운영 중 주 DB에서 긴 집계 쿼리 실행 → 그러면 잡은 잠금이 풀리지 않고 정리해야 할 옛 버전 데이터가 계속 쌓임 → 화면에서는 그 행을 쓰는 기능 타임아웃, 몇 시간에 걸쳐 저장·조회가 전반적으로 느려짐

증상: 입력 지연, 씹힘·롤백
요인: 지연, 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 오래 켜 둘수록, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 트랜잭션 안에서 네트워크 호출·사용자 입력 기다리지 않기, 집계 쿼리는 복제본에서.
인프라팀 할 일: 오래 열린 트랜잭션 경보와 강제 종료, 집계용 복제본 제공, 언두 로그·죽은 행 증가 감시.
그래프에서는: 서서히 오름 · 언두 로그 길이(History list length), 죽은 행 수
확인할 곳: MySQL은 INFORMATION_SCHEMA.INNODB_TRX의 trx_started로 가장 오래된 트랜잭션을 찾고, SHOW ENGINE INNODB STATUS의 TRANSACTIONS 섹션에 나오는 History list length(아직 정리하지 못한 언두 로그 양)를 봄. PostgreSQL은 pg_stat_activity의 xact_start와 state가 idle in transaction인 세션, pg_stat_user_tables의 n_dead_tup을 봄
이러면 맞음: 몇 분~몇 시간 된 트랜잭션이 있고 그동안 History list length나 n_dead_tup이 계속 오르다 그 트랜잭션을 끝낸 뒤 정리(purge·VACUUM)가 돌면서 줄어듦
이러면 아님: 오래된 트랜잭션이 없는데 전반적으로 느리면 체크포인트(db-checkpoint)나 디스크 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: DB는 읽는 쪽이 고치기 전 모습을 볼 수 있도록 옛 버전을 남겨 둡니다(MVCC). 가장 오래된 트랜잭션이 끝나야 이 기록을 지울 수 있습니다. 트랜잭션 하나가 몇 시간 열려 있으면 MySQL은 언두 로그가, PostgreSQL은 VACUUM이 정리하지 못한 죽은 행(dead tuple)이 쌓입니다. SQL Server는 트랜잭션 로그가 줄지 않아 디스크를 채우기도 합니다.

출처 7건

InnoDB Multi-Versioning MySQL
옛 버전을 볼 수 있는 트랜잭션이 남아 있으면 update 언두 로그를 버리지 못해 롤백 세그먼트가 커짐, 읽기만 하는 트랜잭션도 자주 커밋 권고
Routine Vacuuming (PostgreSQL Documentation) PostgreSQL
옛 행 버전은 다른 트랜잭션이 볼 수 있는 동안 지울 수 없고 오래 열린 트랜잭션은 끝내거나 세션을 종료해야 함
Client Connection Defaults (PostgreSQL Documentation) PostgreSQL
idle_in_transaction_session_timeout: 트랜잭션을 연 채 쉬는 세션을 끊어 잠금을 오래 잡고 있지 못하게 함
Troubleshoot a full transaction log (SQL Server Error 9002) Microsoft SQL Server
오래 실행 중인 활성 트랜잭션이 트랜잭션 로그 정리를 막음
The INFORMATION_SCHEMA INNODB_TRX Table MySQL
TRX_STARTED: 트랜잭션 시작 시각
Purge Configuration MySQL
커밋된 트랜잭션의 언두 로그 목록(history list)을 purge가 정리, 밀린 양은 SHOW ENGINE INNODB STATUS의 TRANSACTIONS 섹션 History list length로 표시
The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
pg_stat_activity의 xact_start(트랜잭션 시작 시각)와 state(idle in transaction), pg_stat_user_tables의 n_dead_tup(죽은 행 추정치)

Redis 느린 명령 Redis blocking commands (single-threaded)

ID db-redis-block · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

Redis는 명령을 한 번에 하나씩 처리해서 느린 명령 하나가 그 뒤의 모든 요청을 막습니다.

왜 운영 중 KEYS로 전체 검색, 원소 수백만 개짜리 랭킹·목록을 통째로 읽거나 지움 → 그러면 그 명령이 끝날 때까지 다른 모든 요청이 대기(수십 ms~수 초) → 화면에서는 세션·랭킹·캐시를 쓰는 기능이 동시에 멈칫, 로그인 지연

증상: 멈춤, 입력 지연, 접속 불가·무한 로딩
요인: 정체, 지연
누가 겪나: 서버 전체, 특정 기능만
언제: 가끔 무작위로, 일정한 주기로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: KEYS 대신 SCAN, 큰 키 쪼개기, 지우기는 UNLINK(백그라운드 삭제), 같은 초에 몰리는 만료 시각 분산.
인프라팀 할 일: 느린 명령 기록(SLOWLOG) 감시, KEYS 같은 위험 명령은 운영 서버에서 막기, 큰 키 정기 점검, THP 끄고 fork할 메모리 여유 확보, RDB·AOF 저장은 복제본에서.
수치 감각: 보통 명령은 1ms 미만. 원소 수백만 개를 한 번에 다루면 수백 ms에서 수 초까지 걸리기도 합니다.
그래프에서는: 가끔 무작위로 튐 · Redis 응답 지연, 느린 명령 수
확인할 곳: SLOWLOG GET으로 slowlog-log-slower-than을 넘긴 명령을 보고, CONFIG SET latency-monitor-threshold로 지연 모니터(기본 꺼짐)를 켠 뒤 LATENCY LATEST·LATENCY DOCTOR로 fork·expire-cycle 같은 이벤트별 지연을 봄. INFO의 latest_fork_usec와 redis-cli --bigkeys로 fork 시간과 큰 키도 확인함
이러면 맞음: 멈춘 시각에 SLOWLOG에 KEYS나 큰 키를 통째로 다루는 명령이 남아 있거나, LATENCY에 같은 시각 fork·expire-cycle 이벤트가 수십 ms 이상으로 기록됨
이러면 아님: SLOWLOG·LATENCY가 비어 있는데 게임 서버 쪽에서만 느리면 네트워크나 게임 서버 안의 대기(SLOWLOG는 명령 실행 시간만 재고 클라이언트와 주고받는 시간은 넣지 않음)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 저장 파일(RDB 스냅샷)을 만들거나 AOF를 다시 쓰려고 프로세스를 복제(fork)하는 순간에도 멈춥니다. 요즘 서버에서 메모리 1GB당 약 10ms라, 30GB면 300ms쯤입니다. 큰 페이지(THP)를 켜 두면 fork 뒤 쓰기마다 큰 페이지를 통째로 복사해(copy-on-write) 멈춤과 메모리 사용이 크게 늘어서, 보통 THP를 끄고 메모리 여유를 넉넉히 둡니다. 같은 초에 만료되는 키가 아주 많을 때도 Redis가 지우느라 잠깐 멈춥니다.

출처 7건

Diagnosing latency issues Redis
요청을 한 스레드가 차례로 처리해 느린 명령이 뒤를 모두 막음, KEYS 대신 SCAN, fork는 물리 서버·최신 VM 실측 1GB당 약 9~13ms, THP는 fork 뒤 복사로 지연·메모리 급증, 같은 초에 대량 만료되면 멈춤
KEYS Redis
운영 환경에서는 극히 조심해서 쓸 것, 큰 DB에서 성능을 망가뜨릴 수 있음(보급형 노트북에서 키 100만 개에 40ms)
UNLINK Redis
키를 즉시 떼어 내고 메모리 회수는 다른 스레드에서 하는 비동기 삭제
SLOWLOG Redis
slowlog-log-slower-than을 넘긴 명령을 기록하는 느린 명령 로그, 실행 시간에는 클라이언트와 주고받는 I/O가 빠짐
Redis latency monitoring Redis
latency-monitor-threshold 기본 0(꺼짐), LATENCY LATEST·LATENCY DOCTOR, fork·expire-cycle 같은 이벤트별 지연 기록
INFO Redis
latest_fork_usec: 마지막 fork에 걸린 시간(마이크로초)
Redis CLI Redis
--bigkeys: 키 공간을 훑어 큰 키를 찾음

실행 계획 변경으로 인한 쿼리 지연 Query plan regression (stats, parameter sniffing)

ID db-plan-flip · 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발

코드는 그대로인데 DB가 같은 쿼리를 처리하는 방법(실행 계획)을 바꾸면, 어제 2ms였던 쿼리가 오늘 수백 ms가 됩니다.

왜 통계 자동 갱신, DB 재시작, 데이터 분포 변화로 DB가 실행 계획을 새로 세움 → 그러면 인덱스를 안 타는 계획이 골라져 같은 쿼리가 수십~수백 배 느려지고 커넥션이 묶임 → 화면에서는 배포도 없었는데 특정 기능 로딩이 갑자기 느려지고 다른 요청까지 대기

증상: 입력 지연, 접속 불가·무한 로딩
요인: 지연, 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 가끔 무작위로
담당: 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 값에 따라 결과 수가 크게 다른 쿼리는 나눠 쓰거나 계획 힌트 검토, 인덱스를 확실히 타는 쿼리 설계.
인프라팀 할 일: 느린 쿼리와 실행 계획 기록 감시, 좋은 계획 고정(SQL Server 쿼리 저장소 등), 통계 갱신 시각 관리.
그래프에서는: 어느 순간부터 계단처럼 올라감 · 쿼리별 평균 실행 시간
확인할 곳: 같은 모양 쿼리의 평균 시간을 주기적으로 모아 추이를 봄. MySQL은 events_statements_summary_by_digest의 AVG_TIMER_WAIT, PostgreSQL은 pg_stat_statements의 mean_exec_time(12 이하는 mean_time)임. 느려진 전후의 실행 계획은 EXPLAIN이나 PostgreSQL auto_explain, SQL Server는 쿼리 저장소의 회귀된 쿼리(Regressed Queries) 화면으로 비교함
이러면 맞음: 배포가 없던 시각에 한 쿼리의 평균 시간이 계단처럼 몇십 배 오르고 그 시점이 통계 갱신·DB 재시작과 겹치며 실행 계획이 바뀌어 있음
이러면 아님: 실행 계획은 그대로인데 느려졌으면 데이터 증가, 잠금 대기(db-hot-row), 디스크 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: SQL Server는 처음 들어온 값에 맞춰 세운 계획을 다시 씁니다(파라미터 스니핑). 아이템이 몇 개뿐인 새 캐릭터로 세운 계획이 아이템 수만 개인 오래된 캐릭터에게 쓰이면 크게 느려지고, 반대 경우도 흔합니다. 재시작으로 계획이 지워지면 멀쩡해졌다가 다시 나빠지기도 합니다.

출처 7건

Query Processing Architecture Guide Microsoft SQL Server
파라미터 스니핑: 컴파일·재컴파일 때 들어온 파라미터 값에 맞춰 실행 계획을 세움
Parameter Sensitive Plan Optimization Microsoft SQL Server
데이터 분포가 고르지 않으면 캐시된 계획 하나가 모든 파라미터 값에 맞지 않음
Monitor performance by using the Query Store Microsoft SQL Server
통계·스키마·인덱스 변화로 계획이 바뀌고 계획 캐시는 최신 계획만 둠, 쿼리 저장소의 계획 강제로 좋은 계획 고정, 회귀된 쿼리(Regressed Queries) 화면으로 느려진 쿼리와 계획 비교
Statement Summary Tables MySQL
events_statements_summary_by_digest: 같은 모양 쿼리별 COUNT_STAR·AVG_TIMER_WAIT(평균 시간)
pg_stat_statements — track statistics of SQL planning and execution PostgreSQL
문장별 calls, total_exec_time, mean_exec_time(평균 실행 시간)
pg_stat_statements (PostgreSQL 12 Documentation) PostgreSQL
12까지는 열 이름이 total_time·mean_time
auto_explain — log execution plans of slow queries PostgreSQL
auto_explain.log_min_duration보다 오래 걸린 쿼리의 실행 계획을 로그에 남김

운영 중 스키마 변경(DDL) 잠금 Schema change lock (DDL / metadata lock)

ID db-ddl-lock · 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발

서비스 중에 테이블에 컬럼이나 인덱스를 추가하면, 잠깐 필요한 잠금 하나 때문에 그 테이블을 쓰는 모든 요청이 대기할 수 있습니다.

왜 핫픽스로 운영 중인 테이블에 컬럼·인덱스 추가 → 그러면 스키마 변경이 앞서 열린 긴 트랜잭션을 기다리고 뒤에 오는 모든 요청은 그 스키마 변경을 기다림 → 화면에서는 그 테이블을 쓰는 기능(인벤토리, 우편 등)이 통째로 멈추고 타임아웃

증상: 입력 지연, 씹힘·롤백, 접속 불가·무한 로딩
요인: 정체
누가 겪나: 특정 기능만, 서버 전체
언제: 가끔 무작위로, 접속·점검 직후
담당: 주 담당 인프라팀·DB 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 스키마 변경이 든 핫픽스는 DB 인프라와 일정 협의, 새 컬럼이 없어도 동작하는 코드를 먼저 배포.
인프라팀 할 일: 잠금 대기 한도를 짧게 걸고 실패하면 다시 시도, 긴 트랜잭션이 없을 때 실행, 온라인 변경 도구 사용, 큰 테이블은 점검 시간에.
그래프에서는: 어느 순간부터 계단처럼 올라감 · 잠금 대기 세션 수, 그 테이블의 쿼리 지연
확인할 곳: MySQL은 SHOW PROCESSLIST에서 State가 Waiting for table metadata lock인 세션을 세고, sys.schema_table_lock_waits로 막고 있는 세션(blocking_pid)을 찾음. PostgreSQL은 pg_locks에서 granted가 false인 요청과 AccessExclusiveLock을 보고, pg_blocking_pids()로 막고 있는 세션을 찾음
이러면 맞음: 스키마 변경을 시작한 시각부터 그 테이블을 쓰는 모든 쿼리가 잠금 대기로 쌓이고, 맨 앞에 끝나지 않은 트랜잭션이나 스키마 변경 문장이 있음
이러면 아님: 대기가 특정 행에만 몰리고 같은 테이블의 다른 행은 잘 처리되면 핫 로우(db-hot-row)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: MySQL은 스키마를 바꿀 때 메타데이터 잠금을, PostgreSQL은 가장 강한 테이블 잠금을 잠깐 잡습니다. 변경 자체는 순식간이어도, 앞에 끝나지 않은 트랜잭션이 하나 있으면 그 뒤로 모든 요청이 대기합니다.

출처 8건

Online DDL Performance and Concurrency MySQL
온라인 DDL도 끝낼 때 배타적 메타데이터 잠금이 잠깐 필요, 긴 트랜잭션이 있으면 기다리고 기다리는 잠금 요청이 뒤의 모든 트랜잭션을 막음
Server System Variables MySQL
lock_wait_timeout: 메타데이터 잠금 대기 한도, 기본값 31,536,000초(1년)
ALTER TABLE (PostgreSQL Documentation) PostgreSQL
따로 적지 않은 ALTER TABLE은 가장 강한 ACCESS EXCLUSIVE 잠금을 잡음
Client Connection Defaults (PostgreSQL Documentation) PostgreSQL
lock_timeout: 잠금을 이 시간 넘게 기다리면 문장을 중단
General Thread States MySQL
Waiting for table metadata lock: 메타데이터 잠금을 기다리는 스레드 상태
The schema_table_lock_waits and x$schema_table_lock_waits Views MySQL
메타데이터 잠금을 기다리는 세션(waiting_query)과 막고 있는 세션(blocking_pid)
pg_locks (PostgreSQL Documentation) PostgreSQL
granted가 false면 잠금을 기다리는 중, mode에 AccessExclusiveLock 같은 잠금 종류
System Information Functions and Operators (PostgreSQL Documentation) PostgreSQL
pg_blocking_pids(): 지정한 세션이 잠금을 못 얻게 막고 있는 세션 목록

L13 서버 구성과 운영

게이트웨이·프록시 경유 Gateway / proxy hop

ID in-gateway · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발

클라이언트와 게임 서버 사이에 중간 서버를 두면, 한 번 거칠 때마다 처리 시간이 붙고 그 서버가 단일 장애 지점이 됩니다.

왜 클라이언트 ↔ 게이트웨이 ↔ 게임 서버 구조 → 그러면 중간 서버의 처리·대기 추가, 과부하 시 모두에게 영향 → 화면에서는 전체 핑 상승, 게이트웨이 장애 시 그곳을 거치는 사용자 전원 접속 끊김

증상: 입력 지연, 접속 끊김
요인: 지연, 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 항상
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 게이트웨이를 여러 대로 늘릴 수 있는 구조, 게이트웨이가 죽어도 다른 게이트웨이로 다시 붙으면 캐릭터가 그대로 이어지는 구조(세션 재연결). 클라이언트: 게이트웨이가 끊기면 자동 재접속.
인프라팀 할 일: 게이트웨이 수평 확장(대수 추가), 게이트웨이별 CPU·연결 수·처리 지연 모니터링.
수치 감각: 같은 데이터센터 안이라 평소에는 한 번 거칠 때 1ms 미만. 게이트웨이가 과부하면 수십~수백 ms로 늘어납니다.
그래프에서는: 인원·부하를 따라 오름 · 게이트웨이 처리 지연, 게이트웨이 CPU·연결 수
확인할 곳: 게이트웨이의 CPU·연결 수와 게이트웨이 소켓의 Recv-Q(ss·netstat), 게이트웨이를 지나기 전과 지난 뒤의 지연 차이. 서비스 메시를 거치는 HTTP·gRPC 호출이면 Istio 표준 지표 istio_request_duration_milliseconds를 보내는 쪽(reporter=source)과 받는 쪽(reporter=destination)으로 나눠 비교
이러면 맞음: 게임 서버의 처리 시간은 그대로인데 게이트웨이 구간의 지연만 늘고 그 시각 게이트웨이의 CPU가 포화되거나 Recv-Q가 쌓임
이러면 아님: 게이트웨이를 거치지 않는 경로(직접 접속, 다른 게이트웨이)도 똑같이 느리면 회선이나 게임 서버 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 서비스 메시(Istio 등)를 쓰면 서버마다 옆에 붙는 사이드카 프록시(Envoy)도 한 단계로 더해집니다. 서비스 사이의 요청은 보내는 쪽 사이드카와 받는 쪽 사이드카를 차례로 거치고, 프록시에 로그·지표 수집 같은 기능을 더할수록 처리 시간과 대기 시간이 늘어납니다.
실제 사례: Riot Games 2020: League of Legends 유럽·브라질 서버의 엣지 호스트 과부하

출처 7건

The Unique Architecture behind Amazon Games’ Seamless MMO New World AWS
New World는 클라이언트가 공개 주소가 있는 입구 서버(REP) 4대 중 하나로 접속하고, 그 뒤의 시뮬레이션 서버(허브)와 통신
Designs, Lessons and Advice from Building Large Distributed Systems Google
LADIS 2009 기조연설(Jeff Dean). 같은 데이터센터 안 왕복 약 0.5ms
Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
과부하로 큐가 길어지면 대기 시간이 처리 시간의 몇 배로 늘어남(처리 100ms, 큐가 스레드 수의 10배면 1.1초)
Performance and Scalability Istio
사이드카 모드에서 요청은 보내는 쪽 사이드카와 받는 쪽 사이드카 프록시를 차례로 거침, 기능을 더할수록 프록시 안의 처리 경로가 길어지고 텔레메트리 수집이 다음 요청의 대기 시간을 늘림
What is Envoy Envoy
Envoy는 모든 애플리케이션 서버 옆에서 따로 도는 프로세스이고 앱은 localhost의 Envoy를 거쳐 주고받음
Istio Standard Metrics Istio
istio_request_duration_milliseconds(HTTP·gRPC 요청 처리 시간 분포), reporter 라벨로 보내는 쪽(source)·받는 쪽(destination) 프록시 구분
netstat(8) — Linux manual page net-tools
Recv-Q: 연결된 소켓에서 사용자 프로그램이 아직 가져가지 않은 바이트 수

존 이동 (서버 간 이관) Zone / server handoff

ID in-zone-transfer · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

다른 지역·던전에 들어갈 때 캐릭터 정보를 다른 서버로 넘기는 과정에서 지연과 실패가 생깁니다.

왜 던전 입장, 대륙 이동으로 담당 서버가 바뀜 → 그러면 저장 → 전달 → 불러오기, 대상 서버가 붐비거나 빈 던전 인스턴스가 없으면 대기 → 화면에서는 긴 로딩, 입장 실패, 이동 중 접속 끊김

증상: 접속 불가·무한 로딩, 멈춤, 접속 끊김, 고무줄
요인: 지연, 정체
누가 겪나: 나만, 특정 장소·채널
언제: 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 이관 데이터 줄이기, 대상 서버 미리 예약, 실패 시 원래 자리로 복귀.
인프라팀 할 일: 던전·존 서버의 빈 인스턴스 여유 모니터링, 피크 전 대수 확보.
그래프에서는: 인원·부하를 따라 오름 · 존 이동 소요 시간·실패 수
확인할 곳: 서버가 남기는 이관 단계별 소요 시간(저장, 전달, 불러오기)과 실패 사유, 대상 서버의 인원과 빈 인스턴스 수
이러면 맞음: 긴 로딩·입장 실패 제보 시각에 이관 시간이 늘거나 실패가 몰리고 대상 서버가 붐비거나 빈 인스턴스가 바닥나 있음
이러면 아님: 이관은 빨리 끝났는데 도착한 뒤 멈추면 밀집 지역 진입 시 스폰 폭주나 클라이언트 로딩 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 로딩 없이 이어진 심리스 월드도 서버 경계를 넘을 때 담당 서버가 바뀝니다. 경계 근처에서 잠깐 멈칫하거나 뒤로 당겨지는 고무줄이 생길 수 있습니다.

출처 1건

The Unique Architecture behind Amazon Games’ Seamless MMO New World AWS
로딩 없는 월드를 격자로 나눠 여러 서버(허브)가 맡고 플레이어가 이동하면 상태를 허브에서 허브로 넘김, 세션형 모드는 공유 풀에서 남는 서버를 받아 씀

연쇄 장애 Cascading failure

ID in-cascade · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라

한 서비스가 느려지면 그걸 부르는 서버들이 응답을 기다리며 묶이고 상관없는 기능까지 멈춥니다.

왜 DB·인증 같은 한 서비스가 느려짐 → 그러면 호출하는 서버들의 스레드와 연결이 응답을 기다리며 묶이고 실패한 요청의 재시도가 부하를 더함 → 화면에서는 상관없어 보이는 기능까지 전부 느려지거나 멈춤

증상: 멈춤, 입력 지연, 접속 불가·무한 로딩
요인: 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라
게임개발팀 할 일: 모든 호출에 타임아웃, 서킷 브레이커, 기능별 격리(벌크헤드), 재시도는 간격을 늘리며 횟수 제한, 헬스체크 응답은 바쁜 작업과 분리.
인프라팀 할 일: 로드밸런서 헬스체크가 잠깐 느린 서버를 바로 빼지 않도록 실패 횟수·간격에 여유, 한꺼번에 빠지는 서버 수 제한.
그래프에서는: 한도에 닿아 평평해짐 · 서비스별 응답 시간·오류율, 스레드·커넥션 사용 수
확인할 곳: 서비스별 응답 시간·오류율·재시도 수를 시간축을 맞춰 한 화면에 놓고 가장 먼저 느려진 곳을 찾음. 로드밸런서 뒤라면 대상 응답 시간(AWS ALB는 TargetResponseTime), 대상의 5xx 수(HTTPCode_Target_5XX_Count), 비정상으로 빠진 대상 수(UnHealthyHostCount)
이러면 맞음: 한 서비스의 지연이 먼저 오르고 뒤이어 그 서비스를 부르는 쪽의 스레드·커넥션 사용 수가 한도에 붙으며 오류가 다른 서비스로 번지고, 재시도 수와 빠진 대상 수가 함께 늘어남
이러면 아님: 여러 서비스가 같은 순간 함께 느려졌다면 공용 자원(DB, 네트워크, 호스트) 장애부터 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 헬스체크(살아 있는지 확인하는 검사)도 연쇄를 키웁니다. 바쁜 서버가 검사에 늦게 답하면 로드밸런서가 멀쩡한 서버를 빼 버리고 그 트래픽이 남은 서버로 몰려 다음 서버도 늦어집니다.
실제 사례: Riot Games 2020: League of Legends 유럽·브라질 서버의 엣지 호스트 과부하
Riot Games 2021: League of Legends EUW 5시간 장애: 부가 DB 하나가 서버 전체를 멈춤
Roblox 2021: Roblox 73시간 장애: 서비스 디스커버리(Consul) 클러스터의 경합
AWS 2021: AWS us-east-1 내부 네트워크 혼잡
AWS 2025: AWS us-east-1 DynamoDB DNS 장애와 긴 복구

출처 4건

Site Reliability Engineering, Chapter 22: Addressing Cascading Failures Google
과부하 서버가 헬스체크에 실패해 빠지면 남은 서버에 부하가 몰리고 재시도가 부하를 키움, 재시도 횟수 제한·무작위 지수 백오프·데드라인 권장
Circuit Breaker Pattern Microsoft Azure
타임아웃까지 막힌 요청이 스레드·DB 연결을 점유해 상관없는 기능까지 실패시킴, 정해진 시간 안에 실패가 쌓이면 호출을 바로 거부
Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library. 5단 호출에서 층마다 3번씩 재시도하면 DB 부하가 243배, 재시도는 한 곳에서만 하고 토큰 버킷으로 제한
CloudWatch metrics for your Application Load Balancer AWS
TargetResponseTime(요청이 로드밸런서를 떠나 대상이 응답을 시작할 때까지 걸린 시간), HTTPCode_Target_5XX_Count(대상이 낸 5xx 수), UnHealthyHostCount(비정상 대상 수)

부가 서버 장애 Auxiliary service outage

ID in-subservice · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

채팅·파티·경매장처럼 게임 서버와 따로 도는 서버에 장애가 나면 그 기능만 동작하지 않습니다.

왜 기능 전용 서버가 느려지거나 죽음 → 그러면 해당 기능 요청만 응답 없음 → 화면에서는 채팅 안 됨, 파티 초대 무반응, 거래소 무한 로딩(전투는 정상)

증상: 씹힘·롤백, 접속 불가·무한 로딩
요인: 정체, 손실
누가 겪나: 특정 기능만
언제: 가끔 무작위로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 실패해도 게임은 계속되게 설계, 기능별 상태 표시, 여러 기능을 중앙 서버 한 대에 몰지 않기.
인프라팀 할 일: 부가 서버별 헬스체크·경보, 이중화와 자동 재시작.
그래프에서는: 연결이 한꺼번에 끊김 · 기능별 요청 성공률, 부가 서버 연결 수·헬스체크
확인할 곳: 채팅·파티·경매장 같은 부가 서버별 헬스체크·프로세스 상태와 연결 수, 기능별 요청 성공률·응답 시간. 로드밸런서 뒤라면 대상 그룹의 UnHealthyHostCount
이러면 맞음: 제보된 기능을 맡은 서버만 헬스체크 실패나 연결 급락을 보이고 게임 서버의 틱과 전투는 정상
이러면 아님: 여러 기능이 한꺼번에 멈췄으면 그 기능들을 함께 중계하는 중앙 서버나 연쇄 장애 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 파티·길드·귓속말·서버 간 이동을 한 대의 중앙 서버(월드·매니저 서버)가 모두 중계하는 구조라면, 그 서버 하나가 느려질 때 여러 기능이 한꺼번에 멈춥니다.

출처 3건

Bulkhead Pattern Microsoft Azure
구성 요소를 풀로 격리하면 하나가 실패해도 나머지는 계속 동작하고 장애가 번지지 않음
REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies AWS
AWS Well-Architected. 의존 대상이 장애여도 핵심 기능은 약간 오래된 데이터나 대체 데이터로 계속 동작하도록 설계
CloudWatch metrics for your Network Load Balancer AWS
UnHealthyHostCount: 헬스체크에서 비정상으로 판정된 대상 수

배포·재시작 Deploy / rolling restart

ID in-deploy · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

업데이트하려고 서버를 재시작할 때 연결을 옮기지 않으면 그 서버에 있던 사람들의 접속이 끊기고, 종료 직전 저장과 재접속이 한꺼번에 몰립니다.

왜 핫픽스 배포로 서버를 순서대로 재시작 → 그러면 연결을 다른 서버로 옮기지 않고 종료, 그 서버에 있던 모든 유저의 저장이 DB에 몰림 → 화면에서는 공지 없는 접속 끊김, 재접속 폭주

증상: 접속 끊김, 접속 불가·무한 로딩, 입력 지연
요인: 정체
누가 겪나: 서버 전체, 특정 장소·채널
언제: 가끔 무작위로, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 드레인 기능(새 접속만 막고 기존 사람이 빠질 때까지 기다리기), 캐릭터를 다른 서버로 옮기기, 종료 전 저장 나눠 하기, 재시작 뒤 캐시 로딩·JIT 워밍업을 마치고 준비 완료 알리기, 핫 리로드는 별도 스레드에서 미리 읽어 두고 틱 사이에 한 번에 교체.
인프라팀 할 일: 배포 도구가 한 대씩 드레인을 기다린 뒤 재시작, 재시작한 서버는 준비 완료(예열 끝)를 확인한 뒤 트래픽 받기, 배포 시각 공지.
수치 감각: 서버 한 대에 5,000명이면 종료 직전 몇 초 안에 저장 5,000건이 DB로 몰립니다.
그래프에서는: 연결이 한꺼번에 끊김 · 서버별 접속 수, DB 쓰기 수
확인할 곳: 배포 도구의 작업 기록(서버별 재시작 시각)을 접속 수·끊김 수·DB 쓰기·로그인 요청 그래프에 세로선(주석)으로 겹쳐 봄
이러면 맞음: 서버별 접속 수가 재시작 시각에 한 대씩 차례로 급락하고 그 직전에 DB 쓰기가, 직후에 로그인 요청이 솟음
이러면 아님: 끊긴 시각이 배포·재시작 기록과 겹치지 않으면 서버 크래시나 네트워크 장비 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 다시 켠 직후 몇 분도 느립니다. 캐시가 비어 DB 조회가 몰리고 Java·C# 서버는 실행하면서 코드를 최적화하는 과정(JIT 워밍업)이 끝나기 전이라 같은 일에 시간이 더 듭니다. 서버를 끄지 않고 스크립트·데이터 테이블을 다시 읽는 방식(핫 리로드)도 읽는 동안 틱이 멈춰 잠깐 멈춤이 생깁니다.

출처 3건

Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter Google
SIGTERM을 받은 서버는 lame duck 상태로 새 요청을 다른 서버로 돌리고 진행 중인 요청만 마침, 재시작 직후 몇 분은 JIT 최적화 전이라 자원이 더 들어 예열 뒤 트래픽을 받게 함
Liveness, Readiness, and Startup Probes Kubernetes
레디니스 검사로 연결 수립·파일 로딩·캐시 예열이 끝날 때까지 트래픽을 보내지 않음
Edit target group attributes for your Network Load Balancer AWS
대상을 등록 해제하면 새 연결은 보내지 않고 기존 연결은 드레인(기본 300초)

오토스케일링 지연 Autoscaling lag

ID in-autoscale · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

사람이 몰리면 서버를 자동으로 늘리지만 준비에 몇 분이 걸리고 그동안 기존 서버가 과부하입니다.

왜 이벤트 시작으로 접속 급증 → 그러면 새 서버가 켜지고 준비되기까지 수 분 → 화면에서는 이벤트 시작 직후 몇 분간 슬로우모션·접속 불가

증상: 슬로우모션, 접속 불가·무한 로딩
요인: 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 접속·점검 직후
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 채널 분산(이미 붐비는 채널에 있는 사람은 새 서버로 옮길 수 없음), 새 서버의 시작·데이터 로딩 시간 줄이기.
인프라팀 할 일: 이벤트 전 미리 확장, 예열된 예비 서버, 줄일 때는 남은 사람이 빠진 뒤 끄기.
수치 감각: 부하를 감지하는 데 1~몇 분(지표를 몇 분 평균해서 보기 때문), 새 서버를 켜고 게임 데이터를 읽고 캐시를 채우는 데 또 수 분.
그래프에서는: 접속·점검 직후 폭증 · 인스턴스 수, CPU 사용률, 접속 대기
확인할 곳: 오토스케일링 활동 기록(확장을 결정한 시각, 새 인스턴스가 서비스에 들어간 시각)을 CPU 사용률·접속 수 그래프에 겹쳐 봄. AWS는 Auto Scaling 그룹 지표(켜 두어야 보임) GroupDesiredCapacity(목표 대수)·GroupPendingInstances(준비 중)·GroupInServiceInstances(서비스 중)
이러면 맞음: 접속이 급증한 뒤 몇 분 동안 목표 대수와 준비 중 인스턴스만 늘고 기존 서버의 CPU가 한도에 붙어 있다가, 서비스 중 인스턴스가 늘어난 시각부터 풀림
이러면 아님: 새 인스턴스가 들어온 뒤에도 느리면 서버 대수 밖의 원인(DB 같은 공용 자원, 연쇄 장애) 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 오토스케일링은 주로 로그인·게이트웨이·던전처럼 새 서버에 새 사람을 받으면 되는 곳에 씁니다. 줄일 때도 탈이 납니다. 사람이 빠진 새벽에 서버를 줄이면서 남은 사람이 빠지기를 기다리지 않고 끄면 그 사람들의 접속이 끊깁니다.
실제 사례: AWS 2021: AWS us-east-1 내부 네트워크 혼잡
AWS 2025: AWS us-east-1 DynamoDB DNS 장애와 긴 복구

출처 4건

Target tracking scaling policies for Amazon EC2 Auto Scaling AWS
EC2 기본 지표는 5분 간격(상세 모니터링을 켜면 1분)이라, 빨리 반응하려면 1분 이하 간격의 지표 권장
Amazon CloudWatch metrics for Amazon EC2 Auto Scaling AWS
그룹 지표는 켜야 1분 단위로 게시됨, GroupDesiredCapacity(유지하려는 대수)·GroupPendingInstances(아직 서비스 전인 인스턴스 수)·GroupInServiceInstances(서비스 중인 인스턴스 수)
Scheduled scaling for Amazon EC2 Auto Scaling AWS
예측할 수 있는 부하 변화에 맞춰 정한 시각에 용량을 미리 늘리고 줄임
Decrease latency for applications with long boot times using warm pools AWS
부팅이 오래 걸리는 앱은 미리 초기화해 둔 인스턴스 풀(웜 풀)로 확장 지연을 줄임

로그·모니터링 과부하 Logging / monitoring overhead

ID in-monitoring · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라

장애가 나면 로그가 폭증하고 로그를 동기로 넘기는 서버는 로그 때문에 더 느려집니다.

왜 오류가 나며 로그·지표 전송량 폭증 → 그러면 로그 수집기가 밀리고 동기 전송하는 서버는 대기 → 화면에서는 장애 때 뚝뚝 끊김·멈춤이 로그 때문에 더 심해짐

증상: 뚝뚝 끊김, 멈춤
요인: 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라
게임개발팀 할 일: 비동기 전송, 샘플링, 버퍼 넘치면 버리기, 같은 오류 로그는 묶어서 보내기.
인프라팀 할 일: 로그 수집기 용량을 장애 때 폭증량 기준으로 확보, 수집기 적체 경보.
그래프에서는: 가끔 무작위로 튐 · 로그 전송량, 로그 수집기 대기열
확인할 곳: 서버의 초당 로그 줄 수·바이트와 로그 수집 에이전트의 대기열·버린 수를 틱 시간과 함께 봄. 멈춘 스레드가 있으면 bcc offcputime -p로 로그 쓰기·전송에서 기다리는지
이러면 맞음: 틱이 튄 시각에 로그 양이 평소의 수십 배로 솟고 게임 스레드의 대기 시간이 로그 쓰기·전송 호출 스택에 몰려 있음
이러면 아님: 로그 양이 평소와 같거나 게임 스레드가 로그 쪽에서 기다리지 않으면 로그 폭증은 장애의 결과일 뿐이므로, 처음 오류를 낸 원인을 따로 찾음
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Logging in C# Microsoft
.NET 로그 메서드는 동기라서, 저장소가 느리면 바로 쓰지 말고 빠른 저장소에 먼저 쓴 뒤 나중에 옮기도록 권장
Asynchronous loggers Apache Software Foundation
비동기 로깅은 짧은 폭증을 큐로 흡수하지만 출력이 계속 느리면 큐가 차서 가장 느린 출력 속도로 떨어지거나 정책에 따라 로그를 버림(Discard)
Demonstrations of offcputime, the Linux eBPF/bcc version IO Visor
스레드가 멈춰 CPU를 떠난 시간(off-CPU)을 호출 스택별로 합산, -p로 프로세스 지정

서버 간 시계 차이 Clock skew between servers

ID in-clock-skew · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

서버마다 시계가 조금씩 다르면 쿨타임·버프·이벤트 시작 판정이 서버마다 어긋납니다.

왜 시간 동기화가 멈춘 서버의 시계가 다른 서버와 수백 ms~수 초 벌어짐 → 그러면 버프 끝나는 시각 같은 절대 시각을 서버 사이에 넘기면 판정이 어긋남 → 화면에서는 이동하니 버프가 사라지거나 쿨타임이 다시 참

증상: 씹힘·롤백
요인: 지연
누가 겪나: 나만
언제: 이동 중·지역 전환 때
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 서버 사이에는 절대 시각 대신 남은 시간으로 전달.
인프라팀 할 일: 시간 동기화(NTP·chrony) 감시, 서버 간 시계 차이 경보.
수치 감각: 시간 동기화(NTP·chrony)가 정상이면 같은 데이터센터 서버끼리는 보통 수 ms 안쪽입니다. 동기화가 멈추거나 가상 서버가 오래 멈췄다 풀리면 수백 ms~수 초로 벌어집니다.
그래프에서는: 서서히 오름 · 서버별 시계 오프셋
확인할 곳: 서버마다 chronyc tracking의 System time(시스템 시계와 NTP 시계의 차이)·Last offset과 Ref time(마지막으로 시간 원본의 측정값을 반영한 시각)을 모아 비교
이러면 맞음: 문제 서버의 오프셋이 다른 서버보다 수백 ms 이상 벌어져 있거나 Ref time이 오래전에 멈춰 있고, 판정 어긋남이 그 서버를 오가는 이동에서만 생김
이러면 아님: 모든 서버의 오프셋이 수 ms 안이면 게임 쪽 시간 계산이나 클라이언트의 시계 동기화 오차 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 한 서버의 시계가 한 번에 앞뒤로 뛰는 일은 서버 OS 층의 “시스템 시계 점프 (NTP 스텝)”에서 다룹니다.

출처 4건

RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification IETF
빠른 LAN의 NTP 클라이언트는 보통 수백 µs 안으로 맞음
chrony – Frequently Asked Questions chrony
보통 컴퓨터 시계의 드리프트는 100ppm 미만이지만 가상 머신은 더 클 수 있음, 일시 정지했다 재개한 가상 머신은 시각이 틀어져 스텝 보정이 필요할 수 있음
clock_gettime(2) — Linux manual page Linux man-pages
CLOCK_REALTIME은 수동 변경·NTP 보정으로 불연속하게 뛸 수 있고, CLOCK_MONOTONIC은 그런 점프의 영향을 받지 않음
chronyc(1) chrony
chronyc tracking의 System time(NTP 시계와 시스템 시계의 차이), Last offset(마지막 보정 때 추정한 오프셋), Ref time(시간 원본의 마지막 측정값을 반영한 시각)

매크로·봇 과다 Bots and macros

ID in-bots · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라

봇은 사람보다 훨씬 자주 요청을 보내 서버 처리량을 잠식합니다.

왜 사냥·이동·거래를 쉬지 않고 반복하는 봇 대량 접속 → 그러면 서버 처리량과 DB 부하 증가 → 화면에서는 특정 사냥터나 서버 전체가 느려짐(슬로우모션·입력 지연)

증상: 슬로우모션, 입력 지연
요인: 정체
누가 겪나: 서버 전체, 특정 장소·채널
언제: 항상, 저녁 피크 시간
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라
게임개발팀 할 일: 봇 탐지, 계정·캐릭터별 요청 빈도 제한.
인프라팀 할 일: IP별 접속·요청 빈도 제한(PC방·모바일망은 여러 명이 한 IP를 쓰므로 여유 있게), 방화벽·WAF로 봇 대역 차단.
그래프에서는: 일부만 높음 · 계정·IP별 초당 요청 수
확인할 곳: 게임 서버 로그로 계정·캐릭터별 초당 요청 수의 분포와 상위 목록을 봄. 코드 지표가 없으면 방화벽·WAF의 IP별 요청 수
이러면 맞음: 소수 계정·IP가 사람이 낼 수 없는 빈도로 쉬지 않고 요청하고 이들을 제한하면 서버 부하가 눈에 띄게 줄어듦
이러면 아님: 요청이 계정마다 고르게 퍼져 있으면 정상 인원 증가 쪽(틱 예산 초과, 오토스케일링 지연)
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Using rate-based rule statements in AWS WAF AWS
IP 등 기준별로 요청 수를 세어 정한 시간 창 안에 너무 많으면 속도 제한
RFC 6269: Issues with IP Address Sharing IETF
여러 가입자가 IP 하나를 함께 쓰면 IP 기준 차단·제한이 다른 사용자까지 막음

외부 서비스 의존 External dependencies (auth, billing, platform)

ID in-external · 주 담당 외부·외부 · 함께 게임개발팀·서버 개발

플랫폼 로그인, 결제, 본인 인증 같은 외부 서비스가 느리거나 멈추면 그 단계에서 막힙니다.

왜 외부 인증·결제 서비스 장애나 지연 → 그러면 해당 단계에서 응답을 기다림 → 화면에서는 로그인 불가, 결제 실패. 이미 게임 중인 사람은 멀쩡

증상: 접속 불가·무한 로딩, 씹힘·롤백
요인: 정체
누가 겪나: 서버 전체, 특정 기능만
언제: 접속·점검 직후, 특정 행동을 할 때
담당: 주 담당 외부·외부 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 외부 호출에 타임아웃과 친절한 안내, 인증 결과 캐시, 결제 재시도·보상 절차.
외부 할 일: 인증·결제·플랫폼 사업자에 장애 확인과 복구 요청, 유저에게 외부 서비스 장애임을 안내.
그래프에서는: 어느 순간부터 계단처럼 올라감 · 외부 호출 응답 시간·오류율, 로그인 성공 수
확인할 곳: 플랫폼 로그인·결제·본인 인증 같은 외부 호출별 응답 시간·오류율·타임아웃 수와 사업자의 상태 페이지
이러면 맞음: 로그인·결제 실패가 몰린 시각부터 특정 외부 호출의 오류·타임아웃만 한 단계 올라 머물고, 사업자 상태 페이지에 같은 시각의 장애가 있음
이러면 아님: 외부 호출은 정상인데 로그인이 막히면 로그인 서버 자체(스레드 풀 고갈, DB)나 운영체제의 접속 대기열(backlog) 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
실제 사례: Fastly 2021: Fastly CDN 전 세계 오류
AWS 2021: AWS us-east-1 내부 네트워크 혼잡
AWS 2025: AWS us-east-1 DynamoDB DNS 장애와 긴 복구

출처 3건

Timeouts, retries, and backoff with jitter AWS
Amazon Builders' Library. 응답을 기다리는 동안 스레드·연결 같은 자원을 점유하므로 타임아웃을 두고 부작용이 있는 API는 멱등성이 보장될 때만 재시도
Circuit Breaker Pattern Microsoft Azure
실패할 가능성이 큰 호출은 타임아웃까지 기다리지 않고 바로 거부해 응답 시간을 지킴
REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies AWS
AWS Well-Architected. 의존 서비스가 장애여도 약간 오래된 데이터로라도 핵심 기능을 유지(인증 결과 캐시의 근거)

매치메이킹·리전 배정 오류 Wrong region assignment (matchmaking / GeoDNS)

ID in-region-match · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·네트워크 인프라, 외부·외부

가까운 리전 대신 먼 리전의 서버에 배정되면, 회선이 멀쩡해도 그 유저만 핑이 늘 높습니다.

왜 GeoIP 데이터 오류, VPN, 파티원 평균 핑으로 파티 전체를 배정, 인원이 모자랄 때 먼 리전까지 넓히는 규칙, DNS 리졸버 위치 기준 배정 → 그러면 가까운 리전이 있는데도 바다 건너 리전의 서버에 접속 → 화면에서는 여러 리전에 서버를 둔 게임에서 나만(또는 우리 파티만) 핑이 늘 높고 입력 지연·고무줄·스킬 씹힘

증상: 입력 지연, 고무줄, 씹힘·롤백
요인: 지연
누가 겪나: 나만, 특정 지역·통신사
언제: 항상, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·네트워크 인프라, 외부·외부
게임개발팀 할 일: 서버: GeoIP 대신 클라이언트가 잰 리전별 핑으로 배정, 먼 리전으로 넓히는 규칙에 핑 상한 두기, 파티는 평균과 함께 가장 높은 파티원 핑도 보기, 배정한 리전과 그때의 핑을 로그로 남기기. 클라이언트: 리전별 핑을 UDP로 재서 매칭 요청에 함께 보내기, 접속한 리전과 핑을 화면에 표시, 리전을 직접 고르는 선택지.
인프라팀 할 일: DNS로 리전을 고른다면 권한 DNS가 EDNS Client Subnet을 지원하는지 확인(유저가 쓰는 리졸버가 보내지 않으면 리졸버 위치로 배정됨), GeoIP 데이터베이스 정기 갱신, 리전별 서버의 접속 로그에 GeoIP 국가·ASN을 붙여 먼 리전으로 가는 국가·통신사 찾기.
외부 할 일: 유저에게 VPN·게임 가속기를 끄고 다시 접속해 보도록 안내, 회사·해외 DNS를 쓰는 유저에게 통신사 DNS로 바꿔 보도록 안내, GeoIP 사업자에 틀린 위치 정정 요청.
수치 감각: 서울 유저가 도쿄 대신 미국 서부 리전에 배정되면 핑이 약 30ms에서 약 130ms로 늘어납니다. GeoIP는 나라 단위로는 약 99.8% 맞지만 도시 단위는 미국에서도 50km 안에 드는 비율이 약 66%입니다. VPN을 쓰면 유저 대신 VPN 서버의 위치가 나옵니다.
그래프에서는: 일부만 높음 · 유저별 RTT(핑), 배정된 리전 분포
확인할 곳: 리전별 서버의 접속 기록(로드밸런서 접속 로그, VPC 플로 로그)에 남은 클라이언트 IP에 GeoIP 국가·ASN을 붙여, 국가·통신사별로 어느 리전에 접속했는지 셈. 유저 한 명이면 그 유저가 실제로 접속한 리전과, 가까운 리전까지 잰 핑(유저가 재거나 그 리전 서버에서 유저 IP로 mtr)을 비교
이러면 맞음: RTT가 높은 유저·국가가 가까운 리전 대신 먼 리전에 접속해 있고 가까운 리전으로 잰 핑은 낮음
이러면 아님: 가까운 리전에 제대로 배정됐는데도 핑이 높으면 우회 라우팅이나 그 유저의 회선·와이파이 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: DNS로 리전을 고르는 방식(지역·지연 기반 DNS)은 유저 대신 유저가 쓰는 DNS 리졸버의 주소를 보고 위치를 짐작합니다. 리졸버가 유저 주소 일부를 전달하는 EDNS Client Subnet을 지원하지 않으면, 회사 DNS나 멀리 있는 DNS를 쓰는 유저는 리졸버가 있는 곳 기준으로 배정됩니다. 매칭 시스템도 파티를 파티원 핑의 평균으로 판단하거나, 오래 기다리면 핑 기준을 넓혀 먼 리전에 배정하기도 합니다. AWS GameLift Servers도 파티 핑의 기본 기준이 평균이고 핑 상한을 50ms에서 100ms, 200ms로 넓혀 가는 설정을 예로 듭니다. VPN을 켠 유저는 중계 서버를 거치며 늘어난 지연(“VPN·게임 가속기 경유”)과 먼 리전 배정이 겹칠 수 있습니다. 둘은 VPN을 끄고 다시 접속했을 때 배정된 리전이 바뀌는지로 가립니다. 가까운 리전이 아예 없어서 먼 리전에 접속하는 경우는 “전파 지연 (물리적 거리)”에서 다룹니다.

출처 8건

RFC 7871: Client Subnet in DNS Queries IETF
위치에 따라 다르게 답하는 DNS는 질의를 보낸 리졸버의 주소로 위치를 짐작하고, 유저와 멀리 떨어진 중앙 리졸버를 쓰면 부적절한 답이 나옴. EDNS Client Subnet(선택 기능)으로 유저 주소 일부를 전달
How Amazon Route 53 uses EDNS0 to estimate the location of a user AWS
리졸버가 edns-client-subnet을 지원하지 않으면 리졸버의 주소로 유저 위치를 짐작해 리졸버 위치 기준으로 답함(지역·지연 기반 라우팅 공통)
Geolocation accuracy MaxMind
나라 단위 약 99.8%, 미국 도시 단위(50km 안) 약 66%, VPN을 쓰면 최종 사용자 대신 VPN 서버 위치, 모바일망 IP는 넓은 지역에서 쓰여 세밀한 위치를 알 수 없음, 데이터베이스는 계속 갱신해야 함, 정정 요청 가능
FlexMatch rule types AWS
지연 규칙(maxLatency)은 위치별 플레이어 지연을 보고 파티는 기본으로 파티원 평균(partyAggregation avg)을 씀, 큐는 지연 규칙에 맞지 않는 리전에도 배치할 수 있음
Create a player latency policy AWS
모든 플레이어의 평균 지연이 가장 낮은 위치에 배치하지만 지연이 극단적인 플레이어도 배치됨, 핑 상한을 50ms에서 100ms, 200ms로 넓혀 가는 정책 예
Amazon GameLift Servers UDP ping beacons AWS
게임 클라이언트가 호스팅 위치마다 있는 UDP 엔드포인트로 지연을 재서 배치·매칭에 씀, ICMP 핑보다 실제 게임 트래픽에 가까움
Azure network round-trip latency statistics Microsoft Azure
서울(Korea Central) 기준 실측 왕복 중앙값: 도쿄(Japan East) 29ms, 미국 서부 124~136ms
Flow log records AWS
VPC 플로 로그 레코드의 srcaddr: 들어오는 트래픽이면 보낸 쪽 IP 주소

TLS 인증서 만료·설정 오류 TLS certificate expiry / misconfiguration

ID in-cert · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발

로그인·API·패치 서버의 인증서가 만료되거나 중간 인증서가 빠지면, 그 순간부터 새로 연결하는 클라이언트의 TLS 연결이 실패합니다.

왜 인증서 유효 기간이 지났거나, 서버가 중간 인증서를 빼고 보내거나, 유저 기기의 날짜·시간이 틀림 → 그러면 클라이언트가 인증서 검증에 실패해 TLS 연결을 끊음 → 화면에서는 로그인·패치 단계에서 접속 불가·무한 로딩, 상점 같은 HTTPS 기능만 실패. 이미 접속해 있던 사람은 대개 멀쩡

증상: 접속 불가·무한 로딩, 씹힘·롤백
요인: 정체
누가 겪나: 서버 전체, 특정 기능만, 나만
언제: 접속·점검 직후, 특정 행동을 할 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 인증서 오류를 다른 접속 실패와 구분한 오류 코드로 남기고 안내, 날짜 오류면 기기의 날짜·시간을 자동으로 맞추라고 안내, 인증서 고정(pinning)을 쓰면 예비 키를 함께 넣고 인증서 교체 일정을 인프라팀과 맞추기.
인프라팀 할 일: 네트워크: 로드밸런서·CDN에서 TLS를 끝내는 경우 관리형 인증서의 자동 갱신 상태와 남은 일수 경보(ACM은 DaysToExpiry), 검증용 DNS 레코드 유지. 서버 장비·OS: 서버에서 TLS를 끝내는 경우 갱신 자동화와 갱신 뒤 설정 다시 읽기, 중간 인증서까지 넣은 체인으로 설정, 로그인·API·패치 주소마다 남은 유효 기간을 밖에서 주기적으로 검사해 경보.
수치 감각: Let’s Encrypt 인증서는 90일짜리라 60일마다 갱신을 권하고 AWS Certificate Manager는 DNS로 검증한 인증서를 만료 45일 전에 확인해 자동 갱신합니다. 자동 갱신이 조용히 실패하면 정확히 만료 시각에 새 접속이 한꺼번에 막힙니다.
그래프에서는: 연결이 한꺼번에 끊김 · 로그인 성공 수, TLS 핸드셰이크 오류 수
확인할 곳: openssl s_client -connect HOST:443 -showcerts로 서버가 실제로 보내는 인증서 목록을 보고, 각 인증서의 만료일(notAfter)을 openssl x509 -noout -enddate로 확인. 로드밸런서에서 TLS를 끝낸다면 TLS 협상 오류 수(AWS ALB·NLB는 ClientTLSNegotiationErrorCount)와 로그인 성공 수
이러면 맞음: 만료일이 지났거나 서버가 보낸 목록에 중간 인증서가 빠져 있고 오류가 늘기 시작한 시각이 만료 시각이나 인증서를 바꾼 시각과 겹침
이러면 아님: 인증서 목록과 만료일이 정상인데 일부 유저만 실패하면 그 유저 기기의 날짜·시간이나 오래된 OS의 루트 인증서 목록을 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 중간 인증서가 빠진 설정은 PC 브라우저로 열면 멀쩡해 보일 수 있습니다. 브라우저는 다른 사이트에서 받아 둔 중간 인증서를 기억해 빈 곳을 채우지만, 안드로이드 앱처럼 그런 기억이 없는 클라이언트는 실패합니다. 유효 기간도 짧아지는 중입니다. Let’s Encrypt는 기본 유효 기간을 2027년 64일, 2028년 45일로 줄일 예정입니다. 60일마다 갱신하도록 고정해 둔 설정은 64일짜리 인증서에서는 여유가 나흘뿐이고 45일짜리에서는 만료를 넘깁니다. AWS Certificate Manager도 가져온(import) 인증서는 자동 갱신하지 않고, 검증용 DNS 레코드를 지우면 갱신에 실패합니다. 로그인이 막히는 모양은 “DNS 장애·지연”과 비슷하지만 인증서 문제는 서버 주소를 찾은 뒤 TLS 핸드셰이크에서 실패하고 시작 시각이 만료 시각이나 인증서를 바꾼 시각과 겹칩니다.

출처 12건

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile IETF
인증서 유효 기간은 notBefore부터 notAfter까지, 경로 검증은 체인의 인증서마다 현재 시각이 유효 기간 안인지 확인(검증하는 쪽의 시계가 틀리면 실패)
FAQ Let's Encrypt
기본 인증서 유효 기간 90일, 60일마다 갱신 권장
Decreasing Certificate Lifetimes to 45 Days Let's Encrypt
기본 유효 기간을 2027년 2월부터 64일, 2028년 2월부터 45일로 단축, 60일 고정 간격 갱신으로는 부족해져 유효 기간의 약 3분의 2 시점 갱신 권장
Renewal for domains validated by DNS AWS
만료 45일 전에 AWS 서비스에서 사용 중인지와 검증용 CNAME 레코드가 있는지 확인해 자동 갱신, 검증하지 못하면 만료 30·15·7·3·1일 전에 알림
Managed certificate renewal in AWS Certificate Manager AWS
가져온(import) 인증서와 이미 만료된 인증서는 자동 갱신 대상이 아님
Supported CloudWatch metrics AWS
DaysToExpiry: 인증서 만료까지 남은 일수, 만료 전까지 하루 두 번 게시
Security with network protocols Android (Google)
서버가 중간 인증서를 빼고 보내면 안드로이드 앱은 SSLHandshakeException으로 실패하지만 PC 브라우저는 받아 둔 중간 인증서로 채워 오류가 안 날 수 있음, openssl s_client로 서버가 보내는 체인 확인
Network security configuration Android (Google)
인증서 고정을 쓰면 키 교체·CA 변경에 대비해 예비 키를 함께 넣어야 하고, 그러지 않으면 앱을 업데이트할 때까지 연결이 끊김
openssl-s_client OpenSSL
-showcerts: 서버가 보낸 인증서 목록을 보낸 순서 그대로 표시(검증된 체인이 아님)
openssl-x509 OpenSSL
-enddate: 인증서 만료일(notAfter) 출력, -checkend: 지정한 초 안에 만료되는지 검사
CloudWatch metrics for your Application Load Balancer AWS
ClientTLSNegotiationErrorCount: 클라이언트가 서버 인증서 검증에 실패해 연결을 끊은 경우 등 TLS 세션을 맺지 못한 연결 수
CloudWatch metrics for your Network Load Balancer AWS
ClientTLSNegotiationErrorCount: 클라이언트와 TLS 리스너 사이의 협상에 실패한 TLS 핸드셰이크 수

동기화 설계

서버 응답 후에만 연출 (요청-응답 방식) Request-response (no client-side feedback)

ID sy-request-response · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

버튼을 누르면 서버 답이 올 때까지 애니메이션도 소리도 없습니다. 핑이 곧 반응 속도가 됩니다.

왜 스킬·이동·줍기를 서버 확인이 온 뒤에 재생 → 그러면 누른 순간부터 왕복 시간 + 틱 대기만큼 아무 반응 없음 → 화면에서는 핑 150ms면 모든 행동이 0.2초씩 굼뜸

증상: 입력 지연
요인: 지연
누가 겪나: 나만
언제: 항상, 특정 행동을 할 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 애니메이션·소리·이펙트는 누르는 즉시 시작(선연출), 결과(데미지·보상)만 서버 확정 뒤 표시, 이동·기본 공격은 예측해 바로 반영, 서버의 위치 보정을 받으면 그 위치에서 아직 확인받지 못한 입력을 다시 적용. 서버: 받은 입력으로 이동을 직접 계산해 클라이언트가 예측한 위치와 차이가 기준을 넘을 때만 보정 값 보내기.
수치 감각: 반응 시간 ≈ 핑 + 틱 간격의 절반 + 한 프레임. 20틱·핑 150ms면 약 190ms.
그래프에서는: 처음부터 늘 높음 · 입력에서 연출 시작까지 걸린 시간, RTT(핑)
확인할 곳: 개발 빌드의 클라이언트 로그에 버튼 입력 시각, 첫 애니메이션·소리 시작 시각, 서버 응답 도착 시각을 남기고 게임 안 RTT와 나란히 봄. 엔진의 네트워크 에뮬레이션(Unreal NetEmulation.PktLag)이나 시험 서버의 리눅스 tc netem으로 지연을 넣어 핑을 바꿔 가며 잼
이러면 맞음: 연출 시작이 늘 서버 응답 도착과 같은 순간이고 입력에서 연출까지 걸린 시간이 RTT + 틱 대기만큼이며 넣은 지연만큼 그대로 늘어남
이러면 아님: 연출은 누르는 즉시 시작하고 데미지 숫자 같은 결과만 늦으면 정상 설계. 핑이 낮은 곳에서도 틱 간격 이상 늦으면 이중 틱 대기나 클라이언트 프레임 문제
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 턴제, 카드, 방치형처럼 빠른 반응이 필요 없는 게임은 이 방식이 가장 단순하고 안전합니다. 실시간 조작이 있는 게임에서 이동이나 기본 공격까지 이렇게 만들면 문제가 됩니다.

출처 5건

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
서버 결과만 기다리는 클라이언트는 지연이 500ms면 모든 행동이 500ms 뒤에야 보임. 클라이언트 예측과 서버 보정으로 해결
Using Gameplay Abilities in Unreal Engine Epic Games
Local Predicted는 누르는 즉시 실행하고 서버가 최종 결정, Server Initiated는 예측이 없어 쓰는 사람에게 지연이 보임
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
클라이언트가 이동을 예측·저장해 두고 서버 오차가 허용치(MAXPOSITIONERRORSQUARED)를 넘을 때만 보정하며 보정 뒤 저장한 이동을 다시 적용
Using Network Emulation in Unreal Engine Epic Games
서버·클라이언트에 최소·최대 지연과 패킷 손실 비율을 넣어 시험, 콘솔에서는 NetEmulation.PktLag처럼 설정
tc-netem(8) — Linux manual page iproute2
나가는 패킷에 지연·지터(delay TIME JITTER)와 손실(loss random PERCENT)을 넣어 실제 네트워크를 흉내 내는 시험 도구

순차 왕복이 많은 프로토콜 (chatty) Chatty protocol / sequential round trips

ID sy-chatty · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

조작 한 번에 서버 왕복이 여러 번 순서대로 필요하면, 핑이 그 횟수만큼 곱해집니다.

왜 상점 열기 → 목록 요청 → 가격 확인 → 구매 → 인벤토리 갱신을 각각 따로 요청 → 그러면 앞 요청의 답을 받아야 다음 요청을 보냄 → 화면에서는 핑 150ms에서 한 번 사는 데 1초 가까이. 로딩이 유난히 김

증상: 입력 지연, 접속 불가·무한 로딩
요인: 지연
누가 겪나: 특정 기능만, 나만
언제: 특정 행동을 할 때, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 여러 단계를 한 번에 묶어 요청·응답하도록 프로토콜 변경(예: 구매 응답에 갱신된 인벤토리를 함께 담기). 클라이언트: 필요한 데이터를 미리 받아 두기, 결과를 기다리지 않는 UI.
수치 감각: 걸리는 시간 ≈ 왕복 수 × (핑 + 서버 처리 + 틱 대기). 5번이면 핑 150ms에서 약 0.85~1초.
그래프에서는: 처음부터 늘 높음 · 기능별 완료 시간, 조작 한 번의 왕복 수
확인할 곳: 서버 쪽 패킷 캡처(Wireshark)에서 시험 계정으로 상점 구매·로그인 같은 조작을 한 번 하는 동안 요청과 응답이 몇 번 번갈아 오가는지와 그 간격을 셈. 서버 요청 로그가 있으면 세션 ID로 묶어 요청 수와 요청별 도착·응답 시각을 봄
이러면 맞음: 조작 하나에 요청이 앞 응답을 기다렸다가 차례로 여러 번 오가고 완료 시간이 대략 왕복 수 × RTT이며 핑이 높은 지역 유저일수록 같은 기능이 비례해서 느림
이러면 아님: 왕복은 한두 번인데 응답 하나가 오래 걸리면 서버 처리·DB 쪽 원인. 핑과 상관없이 모든 유저가 똑같이 느리면 서버 부하를 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 1건

Chatty I/O antipattern Microsoft Azure
작은 I/O 요청이 많으면 누적 지연이 응답성을 크게 떨어뜨림. 요청을 더 크고 적게 묶으라는 권고

스킬 선입력 없음 No input/spell queue

ID sy-no-queue · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

앞 스킬이 서버에서 끝났다는 확인을 받아야 다음 스킬을 누를 수 있으면, 연계마다 왕복 시간이 끼어듭니다.

왜 다음 스킬 입력을 “이전 스킬 확정 후”에만 받음 → 그러면 스킬 사이마다 핑만큼 빈 시간이 생김 → 화면에서는 연계 사이마다 빈틈이 생기고 핑이 높을수록 DPS가 줄어듦

증상: 입력 지연, 씹힘·롤백
요인: 지연
누가 겪나: 나만, 특정 기능만
언제: 특정 행동을 할 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 쿨다운 끝나기 전 일정 시간(예: 0.3~0.4초) 안의 입력도 받아 바로 서버에 보내는 선입력 허용 시간. 서버: 조금 일찍 도착한 입력을 거절하지 말고 쿨다운이 끝나는 순간 실행.
수치 감각: 쿨다운 1초짜리 연계에서 핑 150ms면 스킬 사이마다 0.15초 이상 비어, 같은 시간에 쓰는 스킬이 13% 넘게 줄어듭니다.
그래프에서는: 처음부터 늘 높음 · 스킬 사이 빈 시간, RTT(핑)
확인할 곳: 서버 로그에 캐릭터별로 스킬 쿨다운이 끝난 시각, 다음 스킬 요청이 도착한 시각, 실행 시각을 남기고 그 사이 빈 시간을 유저 RTT와 비교
이러면 맞음: 쿨다운이 끝나고 다음 스킬이 실행되기까지 늘 RTT 정도가 비고 핑이 높은 유저일수록 빈 시간이 길고 같은 시간에 쓴 스킬 수가 적음
이러면 아님: 빈 시간이 핑과 상관없이 일정하면 공통 쿨다운이나 애니메이션 길이 설계. 빈 시간이 가끔만 크게 튀면 지터·손실이나 틱 예산 초과를 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 예를 들어 월드 오브 워크래프트는 선입력 허용 시간을 두고 플레이어가 설정에서 조절할 수 있게 했습니다. 허용 시간이 왕복 시간보다 길면 연계 사이에 핑이 거의 끼지 않습니다.

출처 1건

Latency and Player Actions in Online Games (Communications of the ACM, 2006) ACM
에버퀘스트 2에서 지연이 커질수록 캐릭터가 주는 피해가 줄어 전투가 길어짐(0→500ms에서 약 2분 전투에 5초 추가)

핑에 먹히는 짧은 판정 구간 Timing window too short for latency + reaction

ID sy-short-window · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·서버 인프라

회피·패링·가드처럼 반응해야 하는 시간이 짧으면, 핑이 그 시간을 먹어 버려 피할 수 없는 공격이 생깁니다.

왜 보스 공격 예고 0.5초, 패링 판정 0.2초처럼 짧은 판정 구간 → 그러면 예고를 늦게 보고(내려오는 지연 + 보간), 내 입력도 늦게 도착(올라가는 지연 + 틱 대기) → 화면에서는 분명 피했는데 맞음, 패링이 씹힘

증상: 씹힘·롤백, 입력 지연
요인: 지연
누가 겪나: 나만, 특정 기능만
언제: 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·서버 인프라
게임개발팀 할 일: 서버: 공격 예고를 서버 시각으로 예약해 미리 보내기, 판정 구간을 핑만큼 늘리기(지연 보상). 클라이언트: 받은 예고를 예약된 서버 시각에 맞춰 재생.
인프라팀 할 일: 유저가 많은 지역 가까이에 서버 배치(지역 서버)해 핑 자체를 줄이기.
수치 감각: 핑 150ms, 보간 100ms면 예고가 내 화면에 뜨기까지 약 0.18초, 내 입력이 서버에 닿기까지 약 0.1초가 듭니다. 사람 반응 0.25초를 더하면 0.5초 예고는 피하기가 거의 불가능합니다.
그래프에서는: 일부만 높음 · 회피·패링 실패율(핑 구간별)
확인할 곳: 서버 로그에 판정 구간의 시작·끝 시각, 유저 입력의 서버 도착 시각, 그 유저의 RTT를 남기고 실패율을 핑 구간(예: 50ms 단위)별로 나눠 봄
이러면 맞음: 핑이 높은 구간일수록 실패율이 뚜렷이 높고 실패한 입력이 판정 구간이 끝나고 조금 뒤(RTT와 보간 시간을 더한 값 이내)에 도착함
이러면 아님: 핑 구간과 상관없이 실패율이 비슷하면 패턴 난이도 문제. 입력이 판정 구간 안에 도착했는데도 실패로 나오면 판정 코드나 서버 검증을 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015) Frontiers
단순 반응 시간 평균 약 231ms(장비 지연 보정 시 213ms), 최근 대규모 연구들은 233~400ms
Latency and Player Actions in Online Games (Communications of the ACM, 2006) ACM
정밀하고 마감 시간이 짧은 행동일수록 지연에 민감(1인칭 약 100ms, 3인칭 약 500ms, 전지적 시점 약 1,000ms에서 한계)
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
서버 시각(ServerTime)에 맞춰 이벤트를 예약해 모든 클라이언트가 같은 순간에 재생하는 방법

지연 보상 없는 판정 Server-now hit validation

ID sy-no-lagcomp · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

서버가 “지금 서버에 있는 위치”로만 명중을 판정하면, 내가 본 화면과 판정이 어긋납니다.

왜 내 화면의 상대는 약 0.2초 과거 위치(핑 150ms, 보간 100ms일 때) → 그러면 서버는 현재 위치로 판정해 내가 조준한 곳엔 이미 없음 → 화면에서는 분명 맞혔는데 빗나감. 움직이는 대상을 앞질러 쏴야 함

증상: 씹힘·롤백
요인: 지연
누가 겪나: 나만
언제: 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 공격자가 보던 시점으로 되감아 판정(지연 보상), 또는 대상 지정 방식으로 바꾸기. 클라이언트: 공격할 때 자기가 보던 시점(보간 중인 서버 시각)을 함께 보내기.
그래프에서는: 일부만 높음 · 움직이는 대상 명중률(핑 구간별)
확인할 곳: 서버 판정 로그에 공격 시각, 공격자 화면의 대상 위치(클라이언트가 보낸 값), 판정에 쓴 서버의 대상 위치, 공격자 RTT를 함께 남김. 개발 빌드에서 서버가 판정에 쓴 위치를 클라이언트 화면에 겹쳐 그리면 바로 보임
이러면 맞음: 빗나간 판정에서 두 위치 차이가 대략 대상 속도 × (공격자 RTT + 보간 시간)이고, 핑이 높을수록 움직이는 대상의 명중률만 떨어짐
이러면 아님: 멈춰 있는 대상도 빗나가면 판정 박스·충돌 검사 문제. 되감기를 하는데도 어긋나면 클라이언트가 보간 시간을 서버에 잘못 알리는지 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
지연 보상이 없으면 지연만큼 앞질러 쏴야 함. 서버가 지연과 보간 시간만큼 되감아 판정하는 지연 보상
Peeking into VALORANT's Netcode Riot Games
서버가 사격 순간 플레이어가 보던 게임 상태로 되감아 명중 판정, 클라이언트가 보던 시뮬레이션 시각을 함께 보냄
Source SDK 2013: player_lagcompensation.cpp Valve
Source 엔진의 되감는 시간 = 네트워크 지연 + 보간 시간

지연 보상 과다 Excessive lag compensation

ID sy-lagcomp-overreach · 주 담당 게임개발팀·서버 개발

공격자 기준으로 너무 멀리 되감아 주면, 맞는 쪽은 이미 숨었는데도 맞습니다.

왜 핑 높은 공격자를 위해 서버가 크게 되감아 판정 → 그러면 맞는 사람 화면에서는 이미 엄폐한 뒤 → 화면에서는 “벽 뒤에서 맞았다”, 핑 높은 사람이 유리

증상: 씹힘·롤백
요인: 지연
누가 겪나: 나만, 특정 지역·통신사
언제: 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 되감기 상한 두기(예: 200~250ms), 그보다 핑이 높은 공격자는 한도까지만 되감고 나머지는 스스로 앞질러 쏘게 두기.
그래프에서는: 일부만 높음 · 명중별 되감은 시간(공격자 핑별)
확인할 곳: 서버 판정 로그에 명중마다 되감은 시간, 공격자 RTT, 맞는 쪽이 엄폐에 들어간 서버 시각을 남김. 개발 빌드에서 되감은 판정 박스를 화면에 그려 봄(Source 엔진은 sv_showlagcompensation)
이러면 맞음: “벽 뒤에서 맞았다” 제보의 명중이 되감은 시간이 긴 공격자에게 몰리고 되감은 시간이 상한 없이 공격자 핑을 따라 늘어남
이러면 아님: 되감은 시간이 짧은 명중에서도 벽 뒤 피격이 나오면 판정 박스·충돌 검사 문제. 맞는 쪽의 핑이 높으면 그 사람의 이동이 서버에 늦게 닿아 생긴 일
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 되감기 판정은 “쏜 사람 우선”입니다. 맞는 쪽이 자기 화면에서 이미 안전한 곳에 들어갔다면 되감지 않는 “맞는 쪽 우선” 예외도 제안되어 있습니다.

출처 3건

Peeking into VALORANT's Netcode Riot Games
되감기에 한도가 없으면 지연 500ms인 사람이 엄폐 0.5초 뒤에도 맞힐 수 있어 한도를 둠
A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022) ACM
“코너 뒤에서 맞음(shot around the corner)” 현상, 상용 FPS의 되감기 한도, 맞는 쪽이 안전하면 되감지 않는 기법 제안
Source SDK 2013: player_lagcompensation.cpp Valve
Source 엔진의 되감기 상한 sv_maxunlag 기본 1초(최대 1초), sv_showlagcompensation은 되감은 판정 박스를 화면에 표시

클라이언트 권위 Client-authoritative results

ID sy-client-auth · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

각자 자기 결과를 결정하면 내 화면은 쾌적하지만 다른 사람 화면과 결과가 어긋나고 해킹에 약합니다.

왜 위치·명중을 클라이언트가 정하고 서버는 전달만 → 그러면 두 사람이 서로 먼저 맞혔다고 주장, 서버는 검증 못 함 → 화면에서는 상대가 순간이동·벽 통과, “나는 맞혔는데 안 맞음”

증상: 순간이동, 씹힘·롤백
요인: 지연
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 중요한 결과(명중 등)는 직접 검증, 이동은 속도·거리 검사. 클라이언트: 서버가 거절·보정한 결과를 받으면 그 값으로 되돌리기.
그래프에서는: 처음부터 늘 높음 · 불가능한 이동 속도·엇갈린 명중 보고 수
확인할 곳: 서버에서 클라이언트가 보고한 위치·명중을 그대로 기록해 두고 이어진 위치 보고로 이동 속도를 계산해 최대 속도를 넘는 보고와 두 사람이 서로 먼저 맞혔다는 보고를 셈
이러면 맞음: 서버가 보고를 검증 없이 다른 클라이언트에 전달하고 불가능한 속도나 서로 엇갈린 명중 보고가 패치·지역과 상관없이 꾸준히 나옴
이러면 아님: 서버가 결과를 직접 계산하거나 검증하고 있으면 이 원인이 아님. 그때의 순간이동은 손실이나 보간 버퍼 쪽을 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
클라이언트가 결과를 보고하는 방식은 클라이언트를 믿을 수 있을 때만 가능. 해킹 우려로 권위 서버를 둠
Peeking into VALORANT's Netcode Riot Games
서버 권위 모델: 서버는 클라이언트가 본 게임 상태를 절대 믿지 않음
Distributed authority topologies (Netcode for GameObjects 2.5) Unity
권한을 클라이언트에 나누면 치팅이 쉬워지고 모든 개체를 다스리는 단일 시뮬레이션이 없어짐

락스텝에서 가장 느린 플레이어 대기 Lockstep waits for the slowest peer

ID sy-lockstep · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

모두가 같은 턴을 함께 계산하는 구조에서는, 한 명의 입력이 늦으면 모두가 기다립니다.

왜 턴마다 모든 플레이어의 입력이 모여야 계산 가능 → 그러면 한 명의 입력이 지터·손실로 늦게 도착 → 화면에서는 모든 사람이 동시에 멈칫, 심하면 “플레이어 기다리는 중” 창

증상: 멈춤, 뚝뚝 끊김, 입력 지연
요인: 지터, 손실, 정체
누가 겪나: 특정 장소·채널
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 입력 지연을 핑에 맞춰 자동 조절, 늦는 사람만 잠깐 떨어뜨려 나머지는 기다리지 않고 진행. 클라이언트: 정해진 입력 지연 적용, 중계 서버 없는 P2P라면 입력 지연 조절과 늦는 사람 처리도 호스트 클라이언트가 맡기.
수치 감각: 입력 지연을 “입력이 상대에게 닿는 시간 + 지터”보다 짧게 잡으면 멈춤이 잦아집니다. 닿는 시간은 서로 직접 주고받으면 핑의 절반, 중계 서버를 거치면 두 사람 핑을 더한 값의 절반쯤입니다.
그래프에서는: 가끔 무작위로 튐 · 턴 대기 시간, 플레이어별 입력 도착 지연
확인할 곳: 턴마다 플레이어별 입력 도착 시각과 턴이 멈춰 기다린 시간을 남기고 멈춘 턴에서 누구의 입력을 기다렸는지 봄. 중계 서버가 있으면 서버 쪽 패킷 캡처에서 플레이어별 입력 패킷의 도착 간격으로도 볼 수 있음
이러면 맞음: 멈춘 턴마다 같은 한 사람의 입력이 입력 지연보다 늦게 도착했고 그 시각에 그 사람의 지터·손실이 튐
이러면 아님: 입력은 모두 제때 왔는데 멈추면 가장 느린 PC의 계산 시간이나 서버 처리 문제. 멈춤 없이 두 화면의 결과만 달라지면 계산 결과의 어긋남(desync)이니 명령 동기화의 경로 계산 불일치를 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Deterministic Lockstep Gaffer On Games
프레임 n의 입력이 모두 와야 계산할 수 있어 늦으면 기다림. 지터를 흡수하는 재생 지연 버퍼가 작으면 멈칫함
1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond Game Developer
명령을 두 턴 뒤에 실행하도록 예약하고 가장 느린 컴퓨터와 핑에 맞춰 턴 길이를 조절(Speed Control)
A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022) ACM
입력 지연(incoming delay)을 “A→서버 + 서버→B” 지연만큼 두어 모두가 같은 순간에 적용

롤백 넷코드의 예측 실패 Rollback misprediction

ID sy-rollback · 주 담당 게임개발팀·클라이언트 개발

상대 입력을 예측해 먼저 보여 주다가 틀리면 되감아 다시 계산합니다. 핑이 클수록 되감는 폭이 커집니다.

왜 상대가 입력을 바꿈(예측과 다름) → 그러면 실제 입력이 핑의 절반만큼 늦게 도착해 그만큼 되감아 재계산 → 화면에서는 상대 동작이 몇 프레임 건너뛰거나 갑자기 바뀜

증상: 순간이동
요인: 지연, 지터
누가 겪나: 나만
언제: 특정 행동을 할 때, 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 입력 지연을 1~3프레임 섞어 되감기 폭 줄이기, 되감기 상한 두기.
수치 감각: 핑 100ms(한쪽 50ms)면 60fps에서 약 3프레임을 되감습니다. 입력 지연을 2프레임 두면 1프레임으로 줄어듭니다.
그래프에서는: 가끔 무작위로 튐 · 되감은 프레임 수, RTT(핑)
확인할 곳: 클라이언트가 되감기마다 되감은 프레임 수, 그때의 RTT, 입력 지연 설정, 되감기·재계산에 걸린 시간을 기록
이러면 맞음: 상대 동작이 튀었다는 순간에 되감은 프레임 수가 크고 평균 되감기 폭이 대략 (한쪽 지연 − 입력 지연) ÷ 프레임 시간이며 핑이 클수록 커짐
이러면 아님: 되감기 폭이 작은데도 뚝뚝 끊김이 생기면 재계산이 한 프레임 시간을 넘는 성능 문제. 되감은 뒤에도 두 화면의 결과가 계속 다르면 계산 결과의 어긋남(desync)
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

GGPO Rollback Networking SDK GGPO
상대 입력을 예측해 먼저 진행하고 실제 입력이 다르면 어긋난 시점부터 현재까지 다시 계산
8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2' GDC
롤백으로 락스텝의 로컬 입력 지연을 없애고 16ms 안에 최대 8프레임을 되감아 재계산

타임스탬프 없는 도착 즉시 재생 Events played on arrival (no timestamps)

ID sy-no-timestamp · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

서버 이벤트에 발생 시각을 붙이지 않고 받자마자 재생하면, 네트워크 지터 때문에 연출 타이밍이 그대로 들쭉날쭉해집니다.

왜 “공격 시작”, “이펙트 재생” 이벤트를 도착 즉시 실행 → 그러면 패킷마다 도착 시간이 달라 간격이 들쭉날쭉 → 화면에서는 연속 공격 모션이 빨라졌다 느려졌다, 보스 패턴 타이밍이 매번 다름

증상: 뚝뚝 끊김, 몰아치기
요인: 지터
누가 겪나: 나만
언제: 항상
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 이벤트에 붙은 시각에 맞춰 재생(이벤트 예약·보간 버퍼). 서버: 이벤트에 발생 시각(서버 시각)을 붙여 보내기.
그래프에서는: 가끔 무작위로 튐 · 이벤트 재생 간격, 패킷 도착 간격
확인할 곳: 서버 로그의 이벤트 발생 시각과 클라이언트 로그의 도착·재생 시각을 이벤트 번호로 맞춰 간격을 비교. 개발 빌드에서 지터를 넣어(tc netem의 지터 값, Unreal 네트워크 에뮬레이션의 최소·최대 지연) 재현해 봄
이러면 맞음: 서버에서 잰 발생 간격은 일정한데 재생 간격이 도착 간격을 그대로 따라 들쭉날쭉함
이러면 아님: 도착 간격은 고른데 재생이 들쭉날쭉하면 클라이언트 프레임 문제(프레임 타임 스파이크). 서버 발생 간격부터 흔들리면 틱 예산 초과
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 5건

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
업데이트마다 서버 시각을 붙이고 현재 시각에서 보간 시간(100ms)을 뺀 목표 시각의 위치로 그림
Snapshot Interpolation Gaffer On Games
받은 스냅샷을 바로 그리면 지터 때문에 끊기고 보간 버퍼에 잠깐 모았다 그리면 매끄러움
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
RPC에 보낸 시각을 담아 받는 쪽이 서버 시각에 맞춰 효과를 재생하는 예
tc-netem(8) — Linux manual page iproute2
나가는 패킷에 지연·지터(delay TIME JITTER)와 손실(loss random PERCENT)을 넣어 실제 네트워크를 흉내 내는 시험 도구
Using Network Emulation in Unreal Engine Epic Games
서버·클라이언트에 최소·최대 지연과 패킷 손실 비율을 넣어 시험, 콘솔에서는 NetEmulation.PktLag처럼 설정

이중 틱 대기 Double tick quantization

ID sy-double-tick · 주 담당 게임개발팀·서버 개발

요청을 다음 틱까지 모았다가 처리하고 결과도 그다음 틱에 보내면 틱 간격이 두 번 더해집니다.

왜 받은 요청은 다음 틱에서 처리 → 그러면 처리 결과도 다음 전송 틱에 모아서 보냄 → 화면에서는 회선 핑은 낮은데 반응이 틱 간격의 1.5배쯤 일정하게 늦음. 10틱 서버면 평균 0.15초, 최악 0.2초

증상: 입력 지연
요인: 지연
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 처리한 틱에 바로 응답 보내기, 틱레이트 올리기, 중요한 응답은 즉시 전송.
수치 감각: 10틱 서버는 한 틱이 100ms라 틱 대기만으로 평균 150ms, 최악 200ms가 더해집니다. 한 번만 기다리면 평균 50ms입니다.
그래프에서는: 처음부터 늘 높음 · 요청 도착에서 응답 전송까지 시간
확인할 곳: 서버 쪽 패킷 캡처에서 시험 계정이 같은 행동(예: 아이템 사용)을 여러 번 할 때 요청 패킷이 도착한 시각과 그 응답 패킷이 나간 시각의 간격을 잼. 서버 로그가 있으면 요청 도착 시각, 처리한 틱 번호, 응답을 보낸 시각을 봄
이러면 맞음: 서버 안에서 걸린 시간이 평균 틱 간격의 1.5배, 최대 2배쯤이고 RTT와 상관없이 일정함
이러면 아님: 서버 안 시간이 평균 틱 간격의 절반 안팎이면 틱 대기는 한 번뿐. 틱 간격보다 들쭉날쭉 길면 틱 예산 초과를 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Peeking into VALORANT's Netcode Riot Games
도착한 입력은 틱 경계까지 최대 한 틱을 기다리고 적용·전송에 다시 한 프레임이 듦. 틱레이트가 높을수록 줄어듦
VALORANT's 128-Tick Servers Riot Games
지연의 일부는 네트워크, 일부는 서버 틱레이트에서 옴
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
NetworkVariable 변경은 즉시 보내지 않고 네트워크 틱마다 모아 전송

너무 엄격한 서버 검증 Over-strict server validation

ID sy-strict-check · 주 담당 게임개발팀·서버 개발

이동 속도·쿨타임·사거리를 서버가 너무 엄격하게 검사하면, 지터로 몰려 온 정상 입력까지 거절합니다.

왜 “한 틱에 이동 가능한 거리”, “쿨타임 0ms 허용” 같은 엄격한 기준 → 그러면 지터로 명령 두 개가 한 틱에 몰려 도착하면 규칙 위반으로 판정 → 화면에서는 고무줄, 쿨타임 됐는데 스킬 거절

증상: 고무줄, 씹힘·롤백
요인: 지터
누가 겪나: 나만
언제: 가끔 무작위로, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 누적 허용량(토큰 버킷) 방식으로 검사, 핑·지터만큼 여유 두기.
그래프에서는: 가끔 무작위로 튐 · 서버 검증 거절·위치 보정 수
확인할 곳: 서버 로그에 검증 거절·위치 보정마다 사유, 그 틱에 도착한 그 유저의 명령 수, 직전 명령과의 도착 간격을 남김
이러면 맞음: 거절·보정이 한 틱에 명령이 2개 이상 몰려 도착한 순간에 몰리고 몇 초 단위로 합친 이동량·사용 횟수는 규칙 안에 있음
이러면 아님: 몇 초 단위로 합쳐도 규칙을 넘으면 실제 과속·치트 가능성. 거절이 특정 통신사와 저녁 시간에 몰리면 특정 통신사 사용자에게 몰리는 검증 오탐 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Source SDK 2013: player.cpp Valve
틱마다 쌓이는 명령 처리 예산(최대 sv_maxusrcmdprocessticks 24틱)으로 몰려 온 명령을 허용. 더 엄격하게 막으면 정상 유저도 뚝뚝 끊김을 겪었다는 개발 주석
RFC 2697: A Single Rate Three Color Marker IETF
토큰 버킷: 평균 속도(CIR)와 한 번에 허용하는 버스트 크기(CBS)로 판정

호스트(방장) 구조 Listen server / host advantage

ID sy-host · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·서버 인프라

한 플레이어의 PC가 서버 역할을 하면, 그 사람의 회선과 PC 성능이 모두의 체감을 정합니다.

왜 방장 PC가 서버 역할(P2P, 리슨 서버) → 그러면 방장 회선이나 PC가 느리면 모두에게 전파, 방장은 핑 0 → 화면에서는 방장만 유리, 방장이 나가면 모두 멈춤·접속 끊김

증상: 뚝뚝 끊김, 멈춤, 접속 끊김
요인: 지연, 정체
누가 겪나: 특정 장소·채널
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발, 인프라팀·서버 인프라
게임개발팀 할 일: 서버: 판정을 맡는 전용 서버로 전환, 그 전까지는 매칭 때 회선·PC가 좋은 사람을 방장으로 고르기. 클라이언트: 호스트 이전(마이그레이션) 지원, 매칭 때 다른 참가자와의 핑·업로드 속도·PC 성능을 측정해 보내기.
인프라팀 할 일: 전용 서버용 서버 장비·인스턴스 확보, 유저가 많은 지역 가까이에 배치.
그래프에서는: 일부만 높음 · 방장별 렉 제보·접속 끊김 수
확인할 곳: 매치 로그에 방장(호스트)의 업로드 속도, 참가자별 방장과의 RTT, 방장 PC의 프레임 시간, 방장이 나간 시각을 남기고 렉·접속 끊김 제보를 방장별로 묶어 봄. 유저도 같은 사람들끼리 방장만 바꿔 다시 해 보면 확인할 수 있음
이러면 맞음: 렉·접속 끊김이 특정 방장의 방에 몰리고 그 방장의 업로드 속도가 낮거나 프레임 시간이 길 때 참가자 모두가 함께 나빠지며, 호스트 이전이 없으면 방장이 나간 순간 모두의 접속이 끊김
이러면 아님: 방장과 상관없이 같은 지역 참가자만 나쁘면 회선·경로 문제. 전용 서버 구조라면 이 원인이 아님
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Networking Overview for Unreal Engine Epic Games
리슨 서버의 호스트는 다른 클라이언트보다 유리하고 서버와 렌더링을 함께 맡아 부하가 큼
Distributed authority topologies (Netcode for GameObjects 2.5) Unity
세션 소유자가 나가면 남은 클라이언트 중에서 새 소유자를 자동 선출
A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022) ACM
P2P 게임도 호스트가 서버 역할을 겸하는 클라이언트-서버 구조로 볼 수 있음

선연출 뒤 서버 거절 Client-side feedback rejected by server

ID sy-optimistic-reject · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

내 화면에서 먼저 보여 준 타격·스킬을 서버가 나중에 인정하지 않으면, 분명히 본 결과가 없던 일이 됩니다.

왜 타격 이펙트·스킬 모션을 서버 확인 전에 먼저 재생(선연출) → 그러면 서버가 사거리·대상 위치·쿨다운·자원을 다시 따져 보고 거절 → 화면에서는 피가 튀었는데 데미지 없음, 스킬 모션만 나가고 효과 없음, 쿨다운만 돎

증상: 씹힘·롤백, 고무줄
요인: 지연
누가 겪나: 나만, 특정 기능만
언제: 특정 행동을 할 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 데미지 숫자·사망·보상처럼 확정이 필요한 부분만 서버 결과로 표시, 흔한 거절 사유는 먼저 검사, 거절되면 쿨다운·자원을 되돌리고 이유를 보여 주기. 서버: 사거리·대상 위치 검사에 핑만큼 여유 두기, 거절 응답에 사유를 담아 보내기, 스킬별 거절 비율을 지표로 모으기.
수치 감각: 거절 응답은 누른 뒤 핑 + 틱 대기만큼 늦게 옵니다. 핑 150ms면 약 0.2초 동안 “맞힌 줄” 압니다.
그래프에서는: 일부만 높음 · 스킬별 서버 거절 비율(핑 구간별)
확인할 곳: 서버에서 스킬별 거절 비율과 거절 사유(사거리, 대상 위치, 쿨다운, 자원)를 모으고 유저 RTT 구간별로 나눔. 클라이언트에는 선연출한 행동이 거절된 횟수를 기록
이러면 맞음: 거절이 특정 스킬과 사거리·대상 위치 사유에 몰리고 핑이 높을수록 거절 비율이 오름
이러면 아님: 거절 사유가 쿨다운·자원이고 핑과 상관없으면 클라이언트와 서버의 데이터 값(쿨다운, 비용)이 다른지 봄. 거절은 없고 연출이 서버 응답 뒤에야 시작되면 서버 응답 후에만 연출(요청-응답 방식)
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 선연출은 핑을 가리는 가장 좋은 방법입니다. 다만 클라이언트와 서버가 판단에 쓰는 정보(상대 위치, 남은 자원)가 다를수록 거절이 잦아집니다. 스킬별 거절 비율을 지표로 모아 두면 판정이 어긋나는 곳을 찾기 쉽습니다.

출처 2건

Using Gameplay Abilities in Unreal Engine Epic Games
Local Predicted 능력은 클라이언트에서 즉시 실행하지만 서버가 최종 결정하고 결과를 뒤집을 수 있음
Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
무기 발사를 클라이언트에서 예측해 효과를 먼저 재생하고 서버 결과로 예측 오차를 바로잡음

명령 동기화의 경로 계산 불일치 Command sync with divergent pathing

ID sy-path-mismatch · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

“여기로 가라”만 주고받고 경로는 양쪽이 각자 계산하면, 계산이 조금만 달라도 캐릭터나 몬스터가 다른 경로로 가다가 제자리로 끌려옵니다.

왜 클릭 이동·몬스터 추적에서 목적지만 보내고 경로는 클라이언트가 따로 계산 → 그러면 지형 데이터 차이, 다른 캐릭터와의 충돌, 계산 순서 차이로 서버와 다른 경로로 이동 → 화면에서는 몬스터가 벽을 뚫고 가다 휙 옮겨짐, 클릭한 캐릭터가 미끄러지듯 방향을 틂

증상: 순간이동, 고무줄
요인: 지연
누가 겪나: 특정 장소·채널, 나만
언제: 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 경로의 중간 지점(웨이포인트)까지 함께 보내기, 주기적으로 위치 맞추기. 클라이언트: 어긋남은 부드럽게 수렴, 서버와 같은 지형 데이터 사용.
그래프에서는: 가끔 무작위로 튐 · 개체별 위치 보정 횟수·거리
확인할 곳: 서버가 보낸 위치와 클라이언트가 계산한 위치의 차이를 개체마다 기록하고 보정이 일어난 좌표를 지도 위에 찍어 봄. 양쪽의 경로 결과나 위치를 체크섬으로 요약해 주기적으로 비교하면 어긋나기 시작한 시점을 찾을 수 있음
이러면 맞음: 보정이 특정 지형(문턱, 좁은 통로, 경사)이나 붐비는 곳에 몰리고 네트워크 지표가 정상인 유저에게도 같은 자리에서 반복됨
이러면 아님: 장소와 상관없이 손실·지터가 튄 순간에만 보정되면 회선 문제. 몬스터 한 마리가 여러 사람 화면에서 함께 튀면 몬스터 제어 권한이 느린 클라이언트에 있는지 봄
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 이 방식은 클릭 이동·탭 타겟 게임이 핑에 둔감한 이유 중 하나입니다. 대신 양쪽 결과가 같다는 보장이 없어서 가끔 위치를 맞춰 주는 장치가 꼭 필요합니다. 부동소수점 계산은 CPU 종류, 컴파일러와 그 최적화 설정(디버그·릴리스 빌드 차이 포함)에 따라 결과가 조금씩 달라질 수 있습니다. 락스텝·롤백처럼 입력만 주고받고 양쪽 계산 결과가 똑같다고 가정하는 구조에서는 이 작은 차이가 쌓여 두 화면의 게임 상태가 갈라지는 어긋남(desync)이 생길 수 있습니다.

출처 6건

Deterministic Lockstep Gaffer On Games
같은 기계에서 결정적이어도 컴파일러·OS·CPU가 다르면 부동소수점 결과가 달라질 수 있음
State Synchronization Gaffer On Games
입력과 함께 상태를 보내면 완벽한 결정성 없이도 양쪽을 맞출 수 있음
Peeking into VALORANT's Netcode Riot Games
패킷 손실이나 두 캐릭터가 같은 자리로 가려 할 때 서버·클라이언트 시뮬레이션이 어긋나 보정이 필요
1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond Game Developer
아주 작은 차이가 시간이 지나며 커져 일꾼의 경로가 조금씩 어긋남. 월드·개체·경로 탐색을 체크섬으로 비교해 어긋남(out-of-sync)을 찾음
Floating Point Determinism Gaffer On Games
같은 부동소수점 코드도 컴파일러·CPU 아키텍처, 디버그·릴리스 빌드에 따라 결과가 달라질 수 있음. AMD와 Intel CPU가 초월 함수에서 조금 다른 값을 낸 사례
/fp (Specify floating-point behavior) Microsoft
/fp:fast는 부동소수점 연산 순서를 바꾸거나 합쳐 다른 /fp 설정과 결과가 달라질 수 있고, FMA로 합친 연산도 따로 곱하고 더한 결과와 다를 수 있음

낮은 스냅샷 전송률 Low snapshot / update rate

ID sy-low-send-rate · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

서버가 위치 업데이트(스냅샷)를 1초에 몇 번만 보내면 보간 버퍼를 그만큼 길게 잡아야 해서, 다른 캐릭터를 더 먼 과거로 봅니다.

왜 전송량을 아끼려고 위치 업데이트를 1초에 5~10번만 보냄 → 그러면 매끄럽게 그리려면 버퍼를 패킷 간격의 2배(200~400ms)로 잡아야 하고, 짧게 잡으면 패킷 하나만 놓쳐도 멈춤 → 화면에서는 상대의 방향 전환이 늦게 보이고 판정과 어긋남. 버퍼가 짧으면 뚝뚝 끊기고 손실 때 순간이동

증상: 뚝뚝 끊김, 순간이동, 씹힘·롤백
요인: 지연, 손실
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 가깝거나 전투 중인 대상은 자주, 먼 대상은 드물게 보내기, 바뀐 부분만 보내(델타 압축) 한 번의 크기를 줄이고 주기를 올리기. 클라이언트: 보간 버퍼 길이를 패킷 간격에 맞춰 자동 조절.
수치 감각: 1초에 10번이면 패킷 간격 100ms, 버퍼 200ms. 핑 150ms의 한쪽 지연 75ms를 더하면 상대를 약 0.3초 과거로 봅니다.
그래프에서는: 처음부터 늘 높음 · 클라이언트별 패킷 도착 간격, 보간 버퍼 길이
확인할 곳: 서버 쪽 패킷 캡처에서 한 유저에게 가는 흐름만 걸러 Wireshark의 I/O Graphs로 초당 패킷 수와 간격을 봄. 게임 쪽 로그가 있으면 개체별 업데이트 간격과 클라이언트 보간 버퍼 여유(다음 스냅샷이 올 때까지 남은 시간)를 함께 봄
이러면 맞음: 위치 업데이트가 초당 5~10번(간격 100~200ms)으로 늘 드물고 보간 버퍼를 200ms 넘게 잡고 있거나 버퍼 여유가 자주 0이 됨
이러면 아님: 업데이트는 촘촘히 나가는데 도착 간격만 흔들리면 지터·손실 쪽. 사람이 붐빌 때 먼 개체만 드물게 받으면 연결별 전송 예산·우선순위
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 4건

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
초당 10회 업데이트면 보간 200ms로 한 번의 누락을 견딤. Half-Life 기본은 초당 20회·보간 100ms
Snapshot Interpolation Gaffer On Games
초당 10개면 두 개 연속 손실까지 견디려 350ms 지연이 필요, 초당 30개면 150ms로 줄어듦
State Synchronization Gaffer On Games
우선순위 누적으로 중요한 개체를 더 자주 보내고 대역폭 한도 안에서 나머지를 돌아가며 전송
8.8. The “I/O Graphs” Window Wireshark
표시 필터에 맞는 패킷 수·바이트를 시간 구간별 그래프로 그림

일부에게만 생기는 문제

느린 사람이 남의 화면에서 몰아서 움직임 Laggy player seen by others (bursty inputs)

ID pt-slow-burst · 주 담당 게임개발팀·서버 개발 · 함께 외부·외부

회선이 나쁜 사람의 입력은 들쭉날쭉 몰려서 서버에 도착합니다. 서버가 틱마다 받은 만큼 적용하면, 다른 사람 눈에는 그 캐릭터가 멈칫했다가 한 번에 여러 걸음을 갑니다.

왜 느린 사람의 이동 명령이 어떤 틱엔 0개, 어떤 틱엔 2~3개씩 도착 → 그러면 서버가 받은 틱에 한꺼번에 적용해 그 캐릭터 위치가 계단처럼 변함 → 화면에서는 다른 사람 화면에서 그 캐릭터만 멈칫하다 한 번에 몰아서 이동. 나머지는 멀쩡

증상: 몰아치기, 순간이동
요인: 지터, 손실
누가 겪나: 특정 캐릭터만 이상해 보임, 특정 지역·통신사
언제: 항상, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 외부·외부
게임개발팀 할 일: 플레이어별 입력 버퍼로 명령을 고르게 나눠 적용, 입력 시퀀스 번호를 보고 원래 간격대로 적용, 다른 사람 화면의 보간 버퍼만 늘리는 것으로는 부족(서버의 위치 기록 자체가 계단 모양이기 때문).
외부 할 일: 느린 유저에게 유선 연결, 와이파이·공유기 점검 안내.
수치 감각: 지터 80ms면 20틱(50ms) 서버에서 틱당 명령 수가 0~3개로 흔들립니다.
그래프에서는: 일부만 높음 · 플레이어별 틱당 적용 명령 수, 플레이어별 지터
확인할 곳: 서버 쪽 패킷 캡처에서 제보된 유저가 보낸 패킷만 걸러 틱 간격(예: 50ms)마다 몇 개씩 도착했는지 세고 다른 유저와 비교. 서버 로그가 있으면 플레이어별로 틱마다 적용한 이동 명령 수와 입력 시퀀스 번호를 봄
이러면 맞음: 제보된 유저의 패킷만 틱마다 0개와 2~3개를 오가며 몰려 도착하고 그 유저의 지터·손실이 높으며, 다른 유저의 패킷은 고르게 도착함. 그 유저가 유선으로 바꾸면 줄어듦
이러면 아님: 여러 캐릭터가 한꺼번에 몰아서 움직이면 서버 틱 지연이나 보는 사람 쪽 회선. 도착과 적용이 고른데도 그 캐릭터만 튀어 보이면 보는 쪽의 보간·표시 문제
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 서버 권위 구조에서는 이것이 정상 동작입니다. 느린 한 사람의 렉은 “그 사람이 이상하게 움직이는 모습”으로만 남에게 보이고 다른 사람의 조작이나 몬스터 움직임에는 영향을 주지 않습니다. 다만 그 사람과 직접 주고받는 일(거래, 파티 기믹, PvP 판정)은 함께 늦어집니다.

출처 3건

Peeking into VALORANT's Netcode Riot Games
서버는 플레이어별 이동 대기열에 도착한 입력을 틱 순서대로 넣고 비면 예측으로 채움. 보정은 그 플레이어에게만 보이고 나머지는 매끄럽게 봄
State Synchronization Gaffer On Games
초당 60번 보낸 패킷도 한 프레임에 2개, 다음 프레임에 0개처럼 몰려 도착
Source SDK 2013: player.cpp Valve
몰려 온 명령을 서버 틱에 나눠 처리(meter out)

도착 즉시 처리하는 서버의 몰아치기 Event-driven processing of bursty inputs

ID pt-event-server · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

패킷이 도착하는 대로 바로 처리하고 알리는 서버에서는, 느린 사람의 몰려 온 행동이 연달아 즉시 실행됩니다.

왜 느린 사람의 스킬·이동 요청이 몰려서 도착 → 그러면 서버가 받는 즉시 순서대로 실행하고 바로 모두에게 알림 → 화면에서는 다른 사람 눈에 그 사람이 스킬 여러 개를 한순간에 쓰거나 빨리 감기처럼 움직임

증상: 몰아치기
요인: 지터
누가 겪나: 특정 캐릭터만 이상해 보임
언제: 특정 행동을 할 때, 항상
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 행동에 붙은 입력 시각의 간격대로 실행(시각은 허용 범위 안에서만 인정), 또는 몰려 온 행동을 거절하지 말고 최소 간격(공통 쿨다운)만큼 벌려 차례로 실행, 도착 시각만 보고 쿨다운 검사하지 않기(정상 입력이 씹힘). 클라이언트: 행동에 입력 시각을 붙여 보내기.
그래프에서는: 일부만 높음 · 플레이어별 행동 실행 간격
확인할 곳: 서버 로그에 플레이어별 행동의 도착 시각, 실행 시각, 클라이언트가 붙인 입력 시각(있다면)을 남겨 실행 간격과 입력 간격을 비교. 서버 쪽 패킷 캡처에서 그 유저 패킷의 도착 간격도 함께 봄
이러면 맞음: 입력 간격은 정상인데 서버 도착·실행 간격이 몇 ms로 뭉쳐 있고 뭉친 순간이 다른 사람들의 몰아치기 제보 시각과 겹침
이러면 아님: 입력 시각 간격부터 뭉쳐 있으면 클라이언트나 매크로 쪽. 서버 실행 간격은 고른데 남 화면에서만 뭉쳐 보이면 보는 사람의 회선
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
서버는 ServerMove를 받을 때마다 이동을 계산하고 직전 이동과의 타임스탬프 차이로 시간 간격을 정함. 서버 시각과 차이가 너무 크면 그 이동을 버림
Deterministic Lockstep Gaffer On Games
도착하는 대로 입력을 적용하면 60Hz로 보내도 간격이 고르지 않아 결과가 들쭉날쭉함

플레이어별 입력 버퍼 크기 Per-player server input buffer (jitter buffer)

ID pt-input-buffer · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

서버가 사람마다 입력을 조금 모아 두었다가 한 틱에 하나씩 꺼내 쓰면, 다른 사람 눈에는 매끄럽지만 본인 행동이 서버에서 확정되는 시점은 그만큼 늦어집니다.

왜 서버가 느린 사람의 입력을 버퍼에 모아 한 틱에 하나씩 적용 → 그러면 버퍼가 작으면 자주 비어 그 캐릭터가 제자리에 서거나 서버가 마지막 입력으로 추측해 움직이고, 크면 본인 입력이 늦게 확정 → 화면에서는 작으면 남 눈에 멈칫, 크면 본인의 스킬 결과가 늦게 나옴(입력 지연)

증상: 뚝뚝 끊김, 입력 지연
요인: 지터
누가 겪나: 특정 캐릭터만 이상해 보임, 나만
언제: 항상
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 사람마다 회선 상태에 맞춰 버퍼 크기를 자동 조절, 밀리면 두 개씩 꺼내 따라잡기, 버퍼가 자주 비는 사람의 클라이언트에는 입력을 앞당겨 보내라고 지시. 클라이언트: 서버 지시에 맞춰 입력을 조금 더 앞당겨 보내기(클라이언트 시간 조절).
수치 감각: 게임마다 다르지만 보통 1~3틱 분량입니다. VALORANT는 128틱 서버에서 서버 버퍼를 평균 반 프레임(약 4ms)으로 더 짧게 유지합니다. 지터가 큰 사람만 버퍼를 늘리는 적응형이 흔합니다.
그래프에서는: 일부만 높음 · 플레이어별 입력 버퍼 길이·빈 횟수
확인할 곳: 서버에 플레이어별로 틱마다 입력 버퍼에 남은 입력 수, 버퍼가 비어 마지막 입력으로 추측해 채운 횟수, 입력 도착에서 적용까지 걸린 시간을 남김
이러면 맞음: 버퍼가 작은 사람은 빈 횟수가 많고 그 순간 남 화면에서 짧게 멈추며 버퍼가 큰 사람은 입력에서 적용까지 걸린 시간이 버퍼 길이만큼 늘어 있음
이러면 아님: 버퍼가 거의 비지 않는데 남 화면에서 뚝뚝 끊김이 보이면 보는 쪽의 보간 문제. 버퍼가 짧은데도 입력 지연이 크면 RTT 자체나 이중 틱 대기
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Peeking into VALORANT's Netcode Riot Games
서버가 클라이언트 시간 기준을 조정해 입력 대기열을 지연이 최소이면서 고르지 않은 도착을 흡수할 만큼만 유지. 서버 버퍼링 목표는 평균 반 프레임
NetworkTimeSystem class (Netcode for GameObjects 2.5) Unity
LocalBufferSec: 서버가 클라이언트 메시지를 버퍼링할 시간. 클라이언트 시간을 앞당겨 메시지가 서버에 더 일찍 도착
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
회선이 나쁜 플레이어는 버퍼 값을 늘릴 수 있음

특정 통신사 사용자에게 몰리는 검증 오탐 Anti-cheat / movement validation false positives on bad ISPs

ID pt-isp-validation · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라

지터가 큰 회선을 쓰는 사람들은 입력이 몰려 도착해서 서버의 속도·쿨타임 검사에 자주 걸립니다.

왜 특정 통신사·지역 회선의 지터가 저녁에 커짐 → 그러면 몰려 도착한 정상 입력을 서버가 과속·쿨타임 위반으로 판단 → 화면에서는 그 통신사 사용자만 고무줄, 스킬 거절, 심하면 서버가 내보내 접속 끊김

증상: 고무줄, 씹힘·롤백, 접속 끊김
요인: 지터
누가 겪나: 특정 지역·통신사, 나만
언제: 저녁 피크 시간, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·네트워크 인프라
게임개발팀 할 일: 검사는 몇 초에 걸친 누적 허용량으로, 회선 상태(핑·지터)를 참고해 기준 완화, 강제 종료 전 경고 단계, 플레이어별 입력 버퍼로 몰려 온 입력을 틱마다 고르게 나눠 오탐 자체를 줄이기.
인프라팀 할 일: 통신사별 손실률·지터 분포를 시간대별로 확인해 게임팀에 공유, 해당 통신사 구간의 경로 점검(양방향 mtr), 필요하면 경로 변경·통신사 에스컬레이션.
그래프에서는: 특정 시간대에만 높음 · 통신사(ASN)별 검증 거절·강제 종료 수, 통신사별 지터
확인할 곳: 서버의 검증 거절·보정·강제 종료 로그에 접속 IP의 통신사(ASN)와 시각을 붙여 통신사·시간대별로 셈. 인프라팀은 같은 시간에 그 통신사 쪽으로 양방향 mtr을 돌려 지터·손실을 봄
이러면 맞음: 거절·강제 종료가 특정 통신사에 몰리고 저녁에 늘며 같은 시간 그 통신사의 지터가 함께 높고 몇 초 단위로 합친 이동량은 규칙 안에 있음
이러면 아님: 통신사와 상관없이 특정 계정만 반복되면 실제 치트 가능성. 모든 통신사에서 함께 늘면 서버 틱이 밀려 명령이 몰려 적용되는 서버 쪽 원인(틱 예산 초과)
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Source SDK 2013: player.cpp Valve
틱마다 쌓이는 명령 예산으로 과속을 막되, 더 엄격한 제한은 정상 유저에게도 뚝뚝 끊김을 만든다는 개발 주석
RFC 2697: A Single Rate Three Color Marker IETF
토큰 버킷: 평균 속도와 허용 버스트 크기로 판정
Understanding Networked Movement in the Character Movement Component for Unreal Engine Epic Games
클라이언트·서버 타임스탬프 차이가 크면 이동을 버리거나 시간 차이 해소 절차로 처리, 서버 시각으로 계산해 속도 핵 방지

느린 파티원 한 명과 보스 기믹 One laggy member in a synchronized mechanic

ID pt-raid-member · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

모두가 정해진 순간에 함께 반응해야 하는 레이드 기믹에서는, 느린 한 사람의 늦은 반응이 파티 전체의 실패가 됩니다.

왜 “모두 동시에 흩어지기”, “한 명이 버튼 누르기” 같은 공동 기믹 → 그러면 느린 사람은 예고를 늦게 보고 입력도 늦게 도착 → 화면에서는 그 사람 한 명 때문에 전멸, 다른 파티원은 “렉 걸린 사람 때문”이라고 느낌

증상: 씹힘·롤백, 입력 지연
요인: 지연
누가 겪나: 특정 장소·채널, 특정 캐릭터만 이상해 보임
언제: 사람이 몰릴 때, 특정 행동을 할 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 기믹 판정 구간을 핑만큼 여유 있게, 예고는 서버 시각으로 미리 보내기, 한 명 실패가 전멸로 이어지지 않는 설계. 클라이언트: 받은 예고를 서버 시각에 맞춰 재생.
그래프에서는: 일부만 높음 · 기믹 실패를 부른 플레이어별 RTT
확인할 곳: 서버 기믹 로그에 실패를 부른 플레이어, 그 사람의 입력 도착 시각, 판정 구간, 그 사람의 RTT·손실을 남김
이러면 맞음: 전멸을 부른 입력이 대부분 같은 한 사람의 것이고 그 사람의 RTT가 파티 평균보다 뚜렷이 높으며 입력이 판정 구간 직후에 도착함
이러면 아님: 실패가 파티원에게 고르게 나뉘면 판정 구간 자체가 짧은 문제(핑에 먹히는 짧은 판정 구간). 느린 사람의 입력이 판정 구간 안에 왔는데도 실패하면 서버 판정 코드
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
서버 시각에 맞춰 이벤트를 예약해 모두가 같은 순간에 재생하는 방법
Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015) Frontiers
단순 반응 시간 평균 약 231ms

몬스터 제어 권한이 느린 클라이언트에 있음 Monster movement delegated to a player client

ID pt-mob-control · 주 담당 게임개발팀·서버 개발

서버 부하를 줄이려고 몬스터 이동 계산을 근처 플레이어 한 명의 클라이언트에 맡기는 게임이 있습니다. 그 사람 회선이 나쁘면 그 몬스터가 모두의 화면에서 이상하게 움직입니다.

왜 서버가 몬스터 이동 계산을 가장 가까운(또는 먼저 온) 플레이어의 클라이언트에 맡김 → 그러면 맡은 사람의 결과 보고가 늦거나 몰려서 서버에 도착 → 화면에서는 그 몬스터만 주변 모두의 화면에서 멈칫하다 순간이동. 맡은 사람 본인 화면에서는 멀쩡

증상: 순간이동, 뚝뚝 끊김, 몰아치기
요인: 지터, 손실
누가 겪나: 특정 캐릭터만 이상해 보임, 특정 장소·채널
언제: 항상, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 제어 권한을 회선이 좋은 사람에게 넘기기(핑·손실 기준), 보고가 끊기면 서버가 즉시 회수, 보스처럼 중요한 몬스터는 서버가 직접 계산.
그래프에서는: 일부만 높음 · 몬스터별 위치 보고 간격(제어 권한을 가진 클라이언트별)
확인할 곳: 서버에 몬스터마다 제어 권한을 가진 클라이언트와 그 클라이언트의 보고 간격, RTT, 손실을 남김. 서버 쪽 패킷 캡처에서 그 클라이언트가 보낸 패킷의 도착 간격도 볼 수 있음
이러면 맞음: 이상하게 움직이는 몬스터의 제어 권한이 모두 같은 한 사람에게 있고 그 사람의 보고 간격이 들쭉날쭉하거나 끊기며 권한을 다른 사람에게 넘기면 바로 정상
이러면 아님: 서버가 직접 계산하는 몬스터도 똑같이 튀면 서버 틱 지연이나 보는 사람 쪽 회선. 권한을 옮겨도 계속 튀면 명령 동기화의 경로 계산 불일치
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 맡은 사람은 멀쩡하다고 느끼므로 제보는 “몬스터가 이상하다”로만 들어옵니다. 한 사람만 빼고 모두가 같은 몬스터를 이상하게 본다면, 그 몬스터의 제어 권한을 누가 가졌는지부터 확인합니다.

출처 2건

Authority (Netcode for GameObjects 2.5) Unity
분산 권한 모델에서는 게임 인스턴스(클라이언트)마다 일부 네트워크 개체의 권한을 맡아 그 개체를 계산
Distributed authority topologies (Netcode for GameObjects 2.5) Unity
권한이 클라이언트에 나뉘면 단일 시뮬레이션이 없고 치팅에 취약

특정 캐릭터의 데이터가 비대함 One character with oversized data (inventory, mail, buffs)

ID pt-heavy-char · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라

아이템·우편이 수천 개 쌓였거나 친구·차단 목록, 버프가 유난히 많은 캐릭터는 접속하고 저장하고 주변에 알릴 양이 남보다 몇 배 큽니다. 회선과 상관없이 그 캐릭터로만 느립니다.

왜 오래 키운 캐릭터나 이벤트 보상이 인벤토리·우편함에 수천 개 쌓임 → 그러면 접속·지역 이동·저장 때마다 그만큼 DB를 읽고 쓰고 주변에 보낼 장비·버프 정보도 큼 → 화면에서는 그 캐릭터만 입장 로딩이 길고 인벤토리·우편을 열 때 멈칫. 저장을 게임 스레드에서 기다리는 서버라면 주변 사람까지 잠깐 멈춤

증상: 접속 불가·무한 로딩, 입력 지연, 멈춤
요인: 정체
누가 겪나: 나만, 특정 기능만
언제: 접속·점검 직후, 특정 행동을 할 때, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·DB 인프라
게임개발팀 할 일: 인벤토리·우편 보관 한도와 오래된 우편 자동 정리, 필요한 부분만 나눠 불러오기, 저장은 바뀐 부분만 게임 스레드 밖에서.
인프라팀 할 일: 느린 쿼리 로그에서 같은 캐릭터로 반복되는 느린 조회를 찾아 게임팀에 전달, 아이템·우편 행 수가 많은 캐릭터 상위 목록 제공.
수치 감각: 아이템 한 개가 DB 한 줄이라면, 아이템 5,000개짜리 캐릭터는 접속할 때마다 5,000줄을 읽습니다. 평범한 캐릭터의 수십 배입니다.
그래프에서는: 일부만 높음 · 캐릭터별 접속·저장 시간, 캐릭터별 DB 조회 행 수
확인할 곳: DB의 느린 쿼리 로그(MySQL slow query log, PostgreSQL log_min_duration_statement)에서 같은 캐릭터 ID로 반복되는 느린 조회·저장을 찾고, 아이템·우편 테이블의 캐릭터별 행 수 상위 목록을 뽑음
이러면 맞음: 느린 쿼리가 몇몇 캐릭터 ID에 몰리고 그 캐릭터의 아이템·우편 행 수가 평균의 수십 배이며 다른 PC·회선에서 접속해도 똑같이 느림
이러면 아님: 같은 계정의 다른 캐릭터나 다른 유저도 함께 느리면 DB 장비·잠금 쪽. 그 캐릭터가 다른 PC에서는 멀쩡하면 유저 환경
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 같은 캐릭터로 다른 PC·회선에서 접속해도 똑같이 느리고 같은 계정의 다른 캐릭터는 멀쩡하다면 캐릭터 데이터를 의심합니다. 이를 가려내려면 제보에 캐릭터 이름이 꼭 필요합니다.

출처 3건

Extraneous Fetching antipattern Microsoft Azure
필요 이상으로 데이터를 가져오면 I/O 부담이 커지고 응답이 느려짐
PostgreSQL Documentation: Error Reporting and Logging PostgreSQL
log_min_duration_statement: 일정 시간 이상 걸린 SQL을 기록해 느린 쿼리 추적
The Slow Query Log MySQL
long_query_time을 넘긴 쿼리를 기록하는 느린 쿼리 로그

채널·인스턴스·페이즈 차이 Different channel / instance / phase

ID pt-phase · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

두 캐릭터가 다른 채널이나 인스턴스에 있거나, 퀘스트 진행도에 따라 보이는 NPC가 다른 “페이즈”에 있으면 서로 다른 세상을 봅니다.

왜 두 번째 캐릭터가 다른 채널로 배정되거나 퀘스트 단계가 다름 → 그러면 서버가 그 캐릭터에게는 해당 NPC를 보내지 않음(정상) → 화면에서는 한쪽에만 NPC가 없음. 버그처럼 보이지만 설계대로

증상: 안 보임·유령 개체
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 항상, 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 채널·페이즈 정보를 클라이언트에 보내기, QA 체크리스트에 “두 캐릭터의 채널·퀘스트 단계 확인” 추가. 클라이언트: 채널·페이즈를 화면에 표시.
그래프에서는: 일부만 높음 · 클라이언트별 주변 개체 수, 채널·페이즈
확인할 곳: 두 캐릭터의 채널 번호와 해당 퀘스트 진행 단계를 게임 화면에서 비교하고 같은 채널·단계로 맞춰 다시 봄. 서버 개체 전송 로그가 있으면 그 NPC를 그 캐릭터에게 보내지 않은 이유(채널·페이즈)를 확인
이러면 맞음: 두 캐릭터의 채널이나 퀘스트 단계가 다르고 같게 맞추면 NPC가 보임
이러면 아님: 채널·단계가 같은데도 한쪽에만 없으면 로딩 중 도착한 등장 알림 폐기, 입장 직후 몰리는 등장 정보 유실, 시야 등록 순서 꼬임 쪽
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 퀘스트 진행을 계정 단위로 저장하는지 캐릭터 단위로 저장하는지도 확인합니다. 같은 계정의 두 캐릭터라면 한쪽의 진행이 다른 쪽의 페이즈를 바꿀 수 있습니다.

출처 2건

Actor Relevancy in Unreal Engine Epic Games
서버는 연결마다 관련 있는(relevant) 액터만 복제하고 관련 없는 액터는 보내지 않음
Object visibility (Netcode for GameObjects 2.5) Unity
CheckObjectVisibility로 클라이언트별로 보이는 개체를 정하고, 숨긴 개체는 그 클라이언트에 전송하지 않음

로딩 중 도착한 등장 알림 폐기 Spawn messages dropped before the client is ready

ID pt-loading-drop · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

존에 들어가자마자 서버가 주변 NPC 등장 알림을 보내는데 클라이언트가 아직 맵을 불러오는 중이라 그 알림을 버립니다.

왜 서버가 입장 처리 직후 주변 개체 등장 알림을 발송 → 그러면 클라이언트는 로딩 중이라 메시지 핸들러가 아직 없어 알림을 버림 → 화면에서는 서버는 이미 보낸 것으로 처리해 다시 안 보냄. 시야를 벗어났다 오기 전까지 NPC가 안 보임

증상: 안 보임·유령 개체
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 접속·점검 직후, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 로딩이 끝나면 “준비 완료” 보내기, 또는 로딩 중 받은 패킷을 보관했다가 처리. 서버: “준비 완료”를 받은 뒤에 주변 정보 전송.
수치 감각: 같은 PC에서 두 클라이언트가 동시에 로딩하거나 로딩하는 쪽이 백그라운드 창이면, CPU·디스크를 나눠 쓰고 처리도 제한되어 그쪽 로딩이 몇 배 길어질 수 있습니다. 서버 입장 처리가 빨라져도 같은 버그가 드러납니다.
그래프에서는: 일부만 높음 · 클라이언트별 로딩 시간, 로딩 중 버린 메시지 수
확인할 곳: 클라이언트가 로딩 중 받아서 버린 메시지의 수·종류와 로딩 완료 시각을, 서버가 등장 알림을 보낸 시각과 비교. 같은 PC에서 두 클라이언트를 동시에 로딩하거나 로딩하는 쪽을 백그라운드 창으로 두면 재현하기 쉬움
이러면 맞음: 안 보이는 NPC의 등장 알림을 서버는 보냈고 도착 시각이 로딩 완료 전이며, 그 시간에 버린 메시지 수가 늘어 있음. 로딩이 긴 쪽 클라이언트에서만 생김
이러면 아님: 등장 알림이 로딩 완료 뒤에 도착했는데도 안 보이면 기준 스냅샷 유실이나 개체 ID 재사용 혼동. 서버가 그 NPC 알림을 아예 보내지 않았으면 시야 등록 순서 꼬임이나 채널·페이즈 차이
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

NetworkConfig class (Netcode for GameObjects 2.5) Unity
SpawnTimeout: 아직 생성되지 않은 개체의 메시지는 보류했다가, 시간 안에 생성되지 않으면 버림
Actor Relevancy in Unreal Engine Epic Games
관련성이 없어진 액터는 클라이언트에서 지워지고 다시 관련되면 새로 복제

시야 등록 순서 꼬임 Interest-management race on enter/leave

ID pt-aoi-race · 주 담당 게임개발팀·서버 개발

캐릭터가 시야 격자에 등록되는 순간과 NPC가 격자를 옮기는 순간이 겹치면, 그 NPC의 등장 알림이 누락될 수 있습니다.

왜 입장·채널 이동·순간이동 처리와 NPC 이동이 같은 순간에 겹침 → 그러면 “새로 보이게 된 개체” 계산에서 그 NPC가 빠짐 → 화면에서는 특정 NPC 몇 마리만 안 보이거나 이미 떠난 NPC가 남아 있음

증상: 안 보임·유령 개체
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 이동 중·지역 전환 때, 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 시야 갱신을 한 스레드·한 순서로 처리, 주기적으로 “보이는 목록” 전체를 다시 맞추기.
그래프에서는: 가끔 무작위로 튐 · 서버 보이는 목록과 클라이언트 개체 목록의 차이 수
확인할 곳: 서버에 시야 격자 등록, 개체의 셀 이동, 등장·퇴장 알림 발송을 틱 번호와 함께 남기고 주기적으로 서버의 “보이는 목록”과 클라이언트가 가진 목록을 비교
이러면 맞음: 빠진 NPC가 그 캐릭터의 입장·순간이동 처리와 같은 틱에 셀을 옮겼고 그 NPC의 등장 알림 발송 기록이 없음
이러면 아님: 등장 알림은 보냈는데 클라이언트가 못 받았거나 버렸으면 전달 쪽(입장 직후 몰리는 등장 정보 유실, 로딩 중 도착한 등장 알림 폐기). 늘 같은 NPC만 빠지면 페이즈나 표시 옵션 차이
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Replication Graph in Unreal Engine Epic Games
MMORPG 등은 월드를 격자로 나눠 셀마다 액터 목록을 두고 클라이언트가 있는 셀 기준으로 전송
Actor Relevancy in Unreal Engine Epic Games
관련성은 연결마다 판단하고 관련 없어진 액터는 클라이언트에서 지워짐

기준 스냅샷 유실 Lost baseline for delta compression

ID pt-baseline · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

서버가 “지난번과 달라진 것만” 보내는 방식에서, 처음 한 번 보내는 전체 정보(기준)를 잃으면 그 뒤 변화분을 적용할 수 없습니다.

왜 개체의 전체 정보(기준) 패킷이 손실되거나 처리 전에 버려짐 → 그러면 클라이언트가 이후의 변화분을 적용할 대상이 없어 무시 → 화면에서는 그 개체가 안 보이거나, 한참 뒤 갑자기 나타남

증상: 안 보임·유령 개체, 순간이동
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 기준은 수신 확인(ACK)을 받을 때까지 반드시 재전송, 변화분은 클라이언트가 받았다고 확인한 기준을 바탕으로만 만들기. 클라이언트: 기준은 실제로 적용한 뒤에 수신 확인(ACK) 보내기, 모르는 개체의 변화분을 받으면 서버에 다시 요청.
그래프에서는: 가끔 무작위로 튐 · 모르는 개체의 변화분 수신 수
확인할 곳: 클라이언트가 기준 없이 받은 변화분을 버린 횟수와 개체 ID를, 서버가 그 개체의 기준을 보낸 시각·ACK를 받은 시각과 대조. 개발 환경에서 손실을 넣어(tc netem의 loss, Unreal 네트워크 에뮬레이션의 패킷 손실 비율) 재현
이러면 맞음: 서버는 안 보이는 개체의 기준을 보냈지만 ACK를 받지 못했는데도 변화분만 계속 보냈고, 클라이언트는 그 변화분을 버림
이러면 아님: 기준이 ACK까지 받고 클라이언트에 적용됐는데 안 보이면 퇴장 알림 유실이나 개체 ID 재사용 혼동
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 4건

Snapshot Compression Gaffer On Games
변화분은 상대가 받았다고 확인(ack)한 기준(baseline)을 바탕으로만 만들어야 하고, 초기 상태는 따로 보냄
Quake III Arena source: code/server/sv_snapshot.c id Software
클라이언트가 확인한 스냅샷을 기준으로 델타 압축하고 기준이 너무 오래되면 전체 스냅샷을 보냄
tc-netem(8) — Linux manual page iproute2
나가는 패킷에 지연·지터(delay TIME JITTER)와 손실(loss random PERCENT)을 넣어 실제 네트워크를 흉내 내는 시험 도구
Using Network Emulation in Unreal Engine Epic Games
서버·클라이언트에 최소·최대 지연과 패킷 손실 비율을 넣어 시험, 콘솔에서는 NetEmulation.PktLag처럼 설정

퇴장 알림 유실 (유령 개체) Missed despawn (ghost entity)

ID pt-ghost · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

“사라졌다”는 알림을 놓치면, 이미 죽었거나 떠난 NPC·플레이어가 내 화면에만 남습니다.

왜 죽음·퇴장·시야 이탈 알림이 손실되거나 순서가 꼬임 → 그러면 클라이언트는 그 개체가 아직 있다고 판단 → 화면에서는 때려도 반응 없는 몬스터, 이미 나간 플레이어가 서 있음

증상: 안 보임·유령 개체
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 가끔 무작위로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 주기적으로 “지금 보이는 목록” 보내기. 클라이언트: 목록에 없는 개체는 지우기, 움직여야 할 개체가 오래 갱신이 없으면 숨기기.
그래프에서는: 가끔 무작위로 튐 · 클라이언트에만 남은 개체 수
확인할 곳: 서버가 보내는 “지금 보이는 목록”과 클라이언트가 가진 개체 목록을 비교해 클라이언트에만 있는 개체를 세고 퇴장 알림의 발송·수신 로그를 개체 ID로 대조
이러면 맞음: 유령 개체의 퇴장 알림을 서버는 보냈는데 클라이언트 수신 기록이 없거나, 퇴장이 등장보다 먼저 도착해 순서가 뒤집혀 있음
이러면 아님: 서버의 보이는 목록에도 그 개체가 남아 있으면 서버 쪽 개체 정리 누락. 같은 ID로 새 개체가 나타난 직후라면 개체 ID 재사용 혼동
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

Actor Relevancy in Unreal Engine Epic Games
관련성이 없어진 동적 액터는 클라이언트에서 삭제됨
Object visibility (Netcode for GameObjects 2.5) Unity
개체를 숨기면 그 클라이언트는 개체를 despawn·삭제

입장 직후 몰리는 등장 정보 유실 Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)

ID pt-spawn-burst · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

존에 들어서는 순간 서버는 주변 개체 수십~수백 개의 등장 정보를 한꺼번에 보냅니다. 이 정보를 비신뢰(unreliable) 채널로 보내거나, 로딩 중이라 소켓을 못 읽는 사이 수신 버퍼가 넘치면 일부가 사라지고 다시 오지 않습니다.

왜 입장 직후 등장 정보가 짧은 순간에 몰려 도착 → 그러면 로딩 중인 클라이언트가 소켓을 늦게 읽어 OS 수신 버퍼가 넘치거나, 큰 UDP 패킷이 단편화되어 프래그먼트 하나만 잃어도 통째로 사라짐. 비신뢰 채널이면 다시 보내 주지도 않음 → 화면에서는 로딩이 느린 쪽 클라이언트에서만 NPC 몇 마리가 빠짐. 시야를 벗어났다 돌아오면 보임

증상: 안 보임·유령 개체
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 접속·점검 직후, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 등장·퇴장 알림은 반드시 재전송이 보장되는 신뢰 채널로, 초기 정보는 나눠서 보내기. 클라이언트: 수신은 로딩과 별개의 스레드에서, 수신 버퍼 크기 늘리기.
수치 감각: PC의 UDP 수신 버퍼 기본값은 OS마다 다르지만 대개 수십~수백 KB입니다. 사람 많은 마을의 입장 정보가 이보다 크면, 로딩 때문에 소켓을 잠깐만 못 읽어도 넘칩니다.
그래프에서는: 접속·점검 직후 폭증 · 입장 직후 수신량, 등장 알림 누락 수
확인할 곳: 서버가 입장 직후 보낸 등장 알림 수와 클라이언트가 받은 수를 비교하고 어느 채널(신뢰·비신뢰)로 보냈는지 봄. 서버 쪽 패킷 캡처에서 입장 직후 그 유저에게 간 양과 단편화된 패킷(Wireshark 필터 ip.flags.mf == 1 || ip.frag_offset > 0)을 봄
이러면 맞음: 받은 수가 보낸 수보다 적고 빠진 것이 입장 직후 몰린 구간에 모여 있으며, 비신뢰 채널로 보냈거나 큰 패킷이 단편화되어 있음. 로딩이 느린 쪽 클라이언트에서 더 자주 생김
이러면 아님: 보낸 수와 받은 수가 같은데 안 보이면 받은 뒤 버린 것(로딩 중 도착한 등장 알림 폐기)이나 시야 계산 문제. 입장 직후와 상관없이 수시로 빠지면 회선 손실
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 4건

RFC 8085: UDP Usage Guidelines IETF
단편화된 패킷은 프래그먼트 하나만 잃어도 통째로 사라짐
UDP vs. TCP Gaffer On Games
UDP는 전달·순서를 보장하지 않아 잃은 패킷은 직접 감지해 다시 보내야 함
Socket.ReceiveBufferSize Property Microsoft
소켓 수신 버퍼 기본 크기는 OS마다 다름
Display Filter Reference: Internet Protocol Version 4 Wireshark
ip.flags.mf(More fragments)·ip.frag_offset(Fragment Offset)로 단편화된 IP 패킷을 거름

개체 ID 재사용 혼동 Entity ID reused without a generation counter

ID pt-id-reuse · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

죽은 NPC가 다시 나타날 때 서버가 같은 개체 ID를 다시 쓰면, 그 사이 퇴장 알림을 놓친 클라이언트는 새 NPC를 옛 NPC로 오인합니다.

왜 NPC가 죽고 같은 개체 ID로 다시 등장 → 그러면 퇴장 알림을 놓친 클라이언트는 “이미 아는 개체”라며 등장 알림을 무시하거나 죽은 상태를 그대로 둠 → 화면에서는 한쪽 화면에만 NPC가 없거나 쓰러진 채로 보임, 다른 NPC의 모습으로 보이기도 함

증상: 안 보임·유령 개체
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 가끔 무작위로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 개체 ID에 세대 번호를 붙여 재사용을 구분. 클라이언트: 이미 아는 ID의 등장 알림을 받으면 기존 개체를 지우고 새로 만들기.
그래프에서는: 가끔 무작위로 튐 · 이미 아는 ID의 등장 알림 수
확인할 곳: 서버에 개체 ID별 생성·삭제 시각(세대 번호가 있으면 함께)을 남기고 클라이언트가 이미 아는 ID로 등장 알림을 받은 횟수와 시야 갱신 때 “변화 없음”으로 처리된 삭제·재생성을 셈
이러면 맞음: 안 보이거나 쓰러진 채 보이는 NPC의 ID가 직전에 죽은 NPC와 같고 그 사이 그 클라이언트가 퇴장 알림을 받지 못했거나 서버가 퇴장·등장 알림을 둘 다 보내지 않음
이러면 아님: ID에 세대 번호가 있고 비교에도 쓰고 있으면 이 원인이 아님. 재사용된 ID가 아닌데도 안 보이면 등장 알림 유실 쪽
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요
더 알아보기: 서버 쪽에서도 생깁니다. 시야 안 개체 목록을 ID로만 비교하면, 두 번의 시야 갱신 사이에 죽고 같은 ID로 다시 스폰된 NPC를 “변화 없음”으로 보고 퇴장·등장 알림을 둘 다 보내지 않습니다. 시야 갱신 시점이 사람마다 어긋나 있으면 그 순간에 걸린 클라이언트만 겪습니다.

출처 2건

Entity struct (Entities 1.3) Unity
Entity는 Index와 세대 번호(Version)로 이뤄져, 재사용된 Index가 아직 유효한지 구분
NetworkConfig class (Netcode for GameObjects 2.5) Unity
RecycleNetworkIds·NetworkIdRecycleDelay: 네트워크 ID를 일정 시간 비운 뒤 재사용

고정 UDP 포트 충돌 Two clients bound to the same local UDP port

ID pt-port-collision · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

클라이언트가 정해진 로컬 포트를 쓰도록 만들어져 있으면, 같은 PC의 두 번째 클라이언트는 포트를 못 쓰거나 첫 번째와 패킷을 나눠 받습니다.

왜 두 클라이언트가 같은 로컬 UDP 포트를 열려고 함(재사용 옵션으로 억지로 공유) → 그러면 OS가 들어온 패킷을 한쪽 소켓에만 넘기거나, 어느 쪽이 받을지 보장하지 않음. 공유기와 서버도 두 클라이언트를 같은 주소로 봄 → 화면에서는 한쪽은 월드 패킷을 못 받아 NPC·다른 플레이어가 안 보이거나 접속이 끊김

증상: 안 보임·유령 개체, 접속 끊김, 접속 불가·무한 로딩
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만
언제: 접속·점검 직후, 항상
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 로컬 포트는 OS가 자동으로 고르게(0번 바인드). 서버: 연결마다 발급한 세션 토큰으로 연결 구분.
그래프에서는: 일부만 높음 · 클라이언트별 수신 패킷 수
확인할 곳: 유저 PC에서 두 클라이언트를 켠 채 명령 프롬프트에서 netstat -ano -p udp로 게임 프로세스(PID)마다 연 로컬 UDP 포트를 봄. 서버 쪽에서는 두 세션이 같은 공인 IP·같은 포트로 들어오는지 확인
이러면 맞음: 두 게임 프로세스가 같은 로컬 포트에 묶여 있거나, 서버에서 두 세션이 같은 IP·포트로 보임. 한쪽만 켜면 정상
이러면 아님: 두 클라이언트가 서로 다른 로컬 포트를 쓰는데도 한쪽이 이상하면 IP·기기 기준 세션 구분 버그나 멀티 클라이언트 제한
확인 수단: 유저 쪽 환경에서 확인

출처 3건

Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE Microsoft
SO_REUSEADDR로 같은 포트에 두 번째로 bind하면 포트를 가로채고, 어느 소켓이 패킷을 받을지 알 수 없음
bind function (winsock.h) Microsoft
포트를 0으로 bind하면 동적 포트 범위(49152~65535)에서 고유 포트를 할당
netstat Microsoft
-a는 TCP·UDP 포트, -n은 숫자 주소, -o는 프로세스 ID(PID), -p udp는 UDP만 표시

IP·기기 기준 세션 구분 버그 Session keyed by IP or machine ID

ID pt-session-key · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

서버나 중간 서버가 연결을 IP나 기기 ID로 구분하면, 같은 PC(같은 공인 IP)의 두 클라이언트를 한 사람으로 인식합니다.

왜 세션 테이블을 IP 또는 IP+기기 ID로 만듦 → 그러면 두 번째 클라이언트의 정보가 첫 번째 세션에 덮어써지거나 섞임 → 화면에서는 한쪽은 NPC가 안 보이고 다른 쪽은 접속이 끊기거나 남의 정보를 받음

증상: 안 보임·유령 개체, 접속 끊김
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 같은 집, 특정 지역·통신사
언제: 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 서버·중간 서버 모두 연결마다 고유한 세션 토큰으로 구분, 같은 집(공유기 NAT 뒤)의 여러 사람과 통신사가 IP 하나를 여러 가입자에게 나눠 주는 모바일 회선(CGNAT) 사용자도 같은 문제를 겪으니 꼭 고치기. 클라이언트: 실행한 클라이언트마다 따로 받은 세션 토큰 사용.
그래프에서는: 일부만 높음 · 같은 공인 IP의 동시 세션 수, 세션 덮어쓰기 수
확인할 곳: 서버·중간 서버 로그에 세션을 찾을 때 쓴 키, 세션 토큰, 클라이언트 IP·포트를 남기고 같은 IP에서 두 번째 접속이 들어온 순간 기존 세션이 바뀌었는지 봄. 같은 PC에서 두 클라이언트를 차례로 켜면 재현됨
이러면 맞음: 두 번째 클라이언트가 접속한 순간 첫 번째 세션의 주소나 캐릭터 정보가 바뀌고, 같은 공유기나 모바일 회선(CGNAT) 뒤의 다른 유저들에게서도 같은 접속 끊김이 보임
이러면 아님: 같은 IP의 두 세션이 서로 다른 토큰으로 따로 유지되면 이 원인이 아님. 두 프로세스가 같은 로컬 포트를 쓰고 있으면 고정 UDP 포트 충돌
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 1건

RFC 6269: Issues with IP Address Sharing IETF
NAT·CGN으로 여러 가입자가 IPv4 주소 하나를 공유하면 IP만으로는 사용자를 구분할 수 없음

멀티 클라이언트 제한 Multi-client restriction policy

ID pt-multiclient · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

보안 모듈이나 서버 정책이 한 PC의 여러 클라이언트를 제한하면, 두 번째 클라이언트는 실행·접속이 막히거나 먼저 켠 쪽의 접속이 끊깁니다. 일부 게임은 추가 클라이언트의 기능만 막습니다.

왜 보안 모듈이 중복 실행을 감지, 또는 서버가 같은 기기의 추가 접속을 제한 → 그러면 두 번째 실행·접속을 거절하거나 한쪽을 끊음. 드물게 추가 클라이언트의 일부 기능만 차단 → 화면에서는 접속 불가나 한쪽 접속 끊김. 기능만 막는 게임에서는 한쪽만 NPC·상점이 안 보임

증상: 접속 불가·무한 로딩, 안 보임·유령 개체, 접속 끊김
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만
언제: 접속·점검 직후
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 제한할 거면 명확한 안내 메시지, 보안 모듈에 QA용 예외 설정. 서버: 같은 기기 접속 제한에도 QA용 예외 설정.
그래프에서는: 일부만 높음 · 사유별 접속 거절·끊김 수(중복 접속)
확인할 곳: 두 번째 클라이언트를 켤 때 나오는 메시지와 먼저 켠 쪽의 끊김 메시지를 봄. 서버의 접속 거절·강제 종료 로그에 중복 접속·같은 기기 같은 사유 코드가 남는지 확인
이러면 맞음: 두 번째 실행·접속 순간 거절 메시지가 뜨거나 먼저 켠 쪽이 중복 접속 사유로 끊기고, 클라이언트를 하나만 켜면 문제가 없음
이러면 아님: 거절·끊김 사유 없이 두 쪽 다 접속되는데 한쪽만 NPC가 안 보이면 고정 UDP 포트 충돌, IP·기기 기준 세션 구분 버그, 로딩·표시 쪽 원인
확인 수단: 유저 쪽 환경에서 확인

출처 1건

CreateMutexW function (synchapi.h) Microsoft
이름 있는 뮤텍스가 이미 있으면 ERROR_ALREADY_EXISTS를 돌려줘 중복 실행 감지·단일 실행 제한에 쓰임

백그라운드 창의 처리 제한 Background window throttling

ID pt-background · 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부

클라이언트 창이 백그라운드에 있으면 게임·엔진·OS가 그 클라이언트의 프레임과 처리를 줄입니다. 받은 패킷을 제때 처리하지 못해 밀리거나 넘칩니다.

왜 게임 옵션이나 그래픽 드라이버의 백그라운드 프레임 제한(예: NVIDIA 드라이버는 초당 20~200 중에서 지정), 절전, 엔진의 백그라운드 정지 설정. OS도 앞에 있는 창(포그라운드)에 CPU·GPU를 우선 배정 → 그러면 프레임마다 처리하는 패킷 수가 줄어 대기열이 쌓이고 수신 버퍼가 넘치면 버려짐 → 화면에서는 창을 앞으로 가져오면 몰아서 나타나거나, 일부 NPC가 끝내 안 보임

증상: 안 보임·유령 개체, 몰아치기, 접속 끊김
요인: 정체, 손실
누가 겪나: 같은 PC의 한쪽 클라만
언제: 가만히 있다가, 항상
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부
게임개발팀 할 일: 네트워크 수신은 게임 루프와 별도 스레드에서 계속, 백그라운드에서도 최소 처리량 보장, 엔진의 백그라운드 실행 설정(Unity는 runInBackground) 켜기.
외부 할 일: 유저에게 그래픽 드라이버의 백그라운드 프레임 제한과 PC 절전 모드를 끄도록 안내.
수치 감각: Unity는 runInBackground 설정이 꺼져 있으면 창이 포커스를 잃는 순간 게임 루프가 멈춥니다. 수신을 그 루프에서만 하면 그동안 패킷이 전혀 처리되지 않습니다.
그래프에서는: 끊겼다가 몰아서 · 클라이언트 프레임 간격, 프레임당 처리한 패킷 수
확인할 곳: 같은 PC에서 한쪽 창을 앞에, 다른 쪽을 뒤에 두고 역할을 바꿔 가며 비교. PresentMon으로 두 프로세스의 프레임 간격을 재고 게임 쪽 로그가 있으면 창 포커스 상태와 프레임마다 처리한 패킷 수를 봄
이러면 맞음: 백그라운드 창일 때만 프레임 간격이 크게 늘거나(드라이버 제한이면 설정한 프레임 수에 맞는 간격에서 평평해짐) 처리가 멈추고, 창을 바꾸면 문제도 다른 클라이언트로 옮겨 감
이러면 아님: 앞에 있는 창에서도 똑같이 생기면 백그라운드 제한 탓이 아님. 창 위치와 상관없이 늘 같은 클라이언트만 이상하면 표시 옵션이나 버전 차이
확인 수단: 유저 쪽 환경에서 확인

출처 4건

Application.runInBackground Unity
runInBackground 기본값은 false이며 이때 앱은 백그라운드에서 일시 정지
Manage 3D Settings (reference) — NVIDIA Control Panel Help NVIDIA
Background Application Max Frame Rate: 백그라운드 게임의 최대 프레임을 초당 20~200으로 제한
Priority Boosts Microsoft
Windows는 포그라운드 창의 프로세스 우선순위를 백그라운드 프로세스 이상으로 높임
PresentMon README Intel
윈도우 그래픽 앱의 CPU·GPU·디스플레이 프레임 시간을 앱별로 수집하는 도구

캐시·에셋 파일 동시 접근 충돌 Shared cache / asset file lock conflicts

ID pt-asset-lock · 주 담당 게임개발팀·클라이언트 개발

두 클라이언트가 같은 캐시 폴더에 동시에 쓰거나 파일을 잠그면, 한쪽이 NPC 모델·텍스처를 못 불러옵니다.

왜 두 클라이언트가 같은 설치 폴더의 캐시·패치 파일을 동시에 씀 → 그러면 파일 잠금 실패나 반쯤 쓰인 파일을 읽어 로딩 실패 → 화면에서는 이름표는 있는데 캐릭터 모델이 없거나 투명한 NPC

증상: 안 보임·유령 개체
요인: 정체
누가 겪나: 같은 PC의 한쪽 클라만
언제: 접속·점검 직후, 이동 중·지역 전환 때
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 클라이언트별 캐시 폴더, 파일 잠금 실패 시 재시도, 로딩 실패 시 기본 모델이라도 표시.
그래프에서는: 일부만 높음 · 클라이언트별 에셋 로딩 실패 수
확인할 곳: 유저 PC에서 Process Monitor로 게임 설치·캐시 폴더 경로만 걸러 두 게임 프로세스의 파일 열기·쓰기 결과를 봄. 클라이언트 로그가 있으면 에셋 로딩 실패와 파일 열기 오류 코드(ERROR_SHARING_VIOLATION)를 찾음
이러면 맞음: 안 보이는 모델의 파일 열기가 공유 위반·잠금 실패로 끝났고 같은 시각 다른 클라이언트가 그 파일을 쓰고 있었음. 하나만 켜거나 설치·캐시 폴더를 나누면 사라짐
이러면 아님: 클라이언트를 하나만 켜도 같은 모델이 안 보이면 파일 손상이나 클라이언트 버전·데이터 불일치. 파일은 잘 열렸는데 안 그려지면 메모리·VRAM 부족
확인 수단: 유저 쪽 환경에서 확인

출처 2건

Creating and Opening Files Microsoft
공유 모드 없이 연 파일은 다른 프로세스가 열 수 없고 ERROR_SHARING_VIOLATION이 남
Process Monitor Microsoft
파일 시스템·레지스트리·프로세스 활동을 실시간으로 기록하고 경로 등 모든 항목으로 거를 수 있음

메모리·VRAM 부족으로 스트리밍 실패 Memory / VRAM exhaustion

ID pt-vram · 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부

클라이언트 두 개가 그래픽 메모리를 나눠 쓰면, 새로 필요한 모델·텍스처를 올릴 자리가 없어 일부가 안 그려집니다.

왜 두 클라이언트가 VRAM·RAM을 나눠 씀. OS는 백그라운드 창의 그래픽 메모리 할당량을 먼저 줄이기도 함 → 그러면 엔진이 새 모델·텍스처를 올리지 못하거나 계속 내렸다 올림 → 화면에서는 NPC가 늦게 나타나거나 흐릿하거나 안 보임, 뚝뚝 끊김

증상: 안 보임·유령 개체, 뚝뚝 끊김
요인: 정체
누가 겪나: 같은 PC의 한쪽 클라만
언제: 이동 중·지역 전환 때, 사람이 몰릴 때
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 외부·외부
게임개발팀 할 일: 메모리 예산에 맞춘 품질 자동 조절, 로딩 실패 시 대체 모델 표시.
외부 할 일: 두 클라이언트를 함께 켜는 유저에게 그래픽 품질을 낮추거나 저사양 모드를 쓰도록 안내, 권장 VRAM·RAM 사양 안내.
그래프에서는: 한도에 닿아 평평해짐 · 프로세스별 전용 GPU 메모리 사용량
확인할 곳: 유저 PC의 작업 관리자 “세부 정보” 탭에 전용 GPU 메모리 열을 추가해 두 클라이언트의 사용량 합을 그래픽카드 VRAM 용량과 비교. 게임 쪽에는 DXGI의 QueryVideoMemoryInfo가 알려 주는 예산(Budget)과 현재 사용량(CurrentUsage)을 기록
이러면 맞음: 두 클라이언트 사용량 합이 VRAM 용량 근처에서 평평하고 현재 사용량이 예산을 넘은 시각에 모델·텍스처 로딩 실패가 몰림. 품질을 낮추거나 하나만 켜면 사라짐
이러면 아님: VRAM에 여유가 있는데도 안 보이면 캐시·에셋 파일 동시 접근 충돌이나 표시 옵션 차이
확인 수단: 유저 쪽 환경에서 확인

출처 3건

Residency (Direct3D 12) Microsoft
비디오 메모리 예산은 다른 앱으로 전환하면 크게 줄 수 있고 예산을 넘으면 멈추거나 생성이 실패. 포그라운드가 아니면 예약분도 보장 안 됨
GPUs in the task manager Microsoft
작업 관리자 세부 정보 탭에 열을 추가하면 프로세스별 전용·공유 GPU 메모리 사용량을 볼 수 있음. 전용 GPU 메모리는 그래픽카드의 VRAM
DXGI_QUERY_VIDEO_MEMORY_INFO structure (dxgi1_4.h) Microsoft
Budget(OS가 정한 비디오 메모리 예산)과 CurrentUsage(앱의 현재 사용량). 사용량이 예산을 넘으면 끊김이 생길 수 있음

표시 옵션 차이 Different display settings

ID pt-display-option · 주 담당 게임개발팀·클라이언트 개발

표시 인원 제한, NPC 이름표·모델 숨김, 저사양 모드 같은 옵션이 두 클라이언트에서 다르면 보이는 것이 다릅니다.

왜 한쪽 클라이언트만 “주변 캐릭터 표시 수 제한”이나 저사양 모드 → 그러면 멀리 있거나 우선순위 낮은 NPC를 그리지 않음(정상) → 화면에서는 한쪽에만 NPC가 없음

증상: 안 보임·유령 개체
요인: 정체
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 사람이 몰릴 때, 항상
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 옵션으로 숨긴 개체임을 알 수 있게 표시, 설정 파일을 클라이언트별로 분리해 섞이지 않게.
그래프에서는: 일부만 높음 · 클라이언트별 화면에 그린 개체 수
확인할 곳: 두 클라이언트의 표시 인원 제한, 이름표·모델 숨김, 저사양 모드 설정을 나란히 비교하고 한쪽을 다른 쪽과 똑같이 맞춰 봄. 두 클라이언트가 설정 파일 하나를 함께 쓰며 서로 덮어쓰는지도 확인
이러면 맞음: 설정을 같게 맞추면 두 화면이 같아지고 안 보이던 NPC는 표시 제한 인원 밖의 먼 개체나 우선순위 낮은 개체였음
이러면 아님: 설정을 똑같이 맞춰도 한쪽에만 없으면 채널·페이즈 차이나 등장 알림 유실 쪽
확인 수단: 유저 쪽 환경에서 확인

출처 1건

Changing the Quantity of Characters Displayed On-screen (FINAL FANTASY XIV UI Guide) Square Enix
표시 제한(Character and Object Quantity) 설정으로 화면에 그리는 캐릭터·오브젝트 수를 조절

클라이언트 버전·데이터 불일치 Client version / data table mismatch

ID pt-version · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

두 번째 클라이언트가 다른 설치본이거나 패치가 덜 되었으면, 서버가 보낸 새 NPC ID를 몰라 조용히 무시합니다.

왜 다른 폴더의 설치본, 또는 패치 중 실행한 클라이언트 → 그러면 모르는 NPC ID·모델 ID를 받으면 건너뜀 → 화면에서는 새로 추가된 NPC만 한쪽에 안 보임

증상: 안 보임·유령 개체
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만
언제: 접속·점검 직후
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 클라이언트: 접속 시 데이터 버전 보내기, 모르는 ID를 받으면 로그를 남기고 대체 표시. 서버: 접속 시 데이터 버전을 확인해 다르면 접속 거절·패치 안내.
그래프에서는: 일부만 높음 · 클라이언트 버전별 모르는 ID 수신 수
확인할 곳: 두 클라이언트의 실행 파일 경로와 화면·로그에 나오는 클라이언트·데이터 버전을 비교. 게임 쪽에는 접속 때 보낸 데이터 버전과 모르는 NPC·모델 ID를 받아 건너뛴 횟수를 기록
이러면 맞음: 두 클라이언트의 버전이나 설치 폴더가 다르고 안 보이는 NPC가 최근 패치로 추가된 것이며 패치를 마친 설치본에서는 보임
이러면 아님: 버전과 설치 폴더가 같은데 한쪽에만 없으면 채널·페이즈 차이나 로딩·전달 쪽 원인
확인 수단: 유저 쪽 환경에서 확인

출처 1건

NetworkConfig class (Netcode for GameObjects 2.5) Unity
ProtocolVersion이 다르면 서로 통신하지 않고 ForceSamePrefabs로 접속 때 프리팹 목록 차이를 검사

연결별 전송 예산·우선순위 Per-connection bandwidth budget and priority

ID pt-priority · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

서버가 연결마다 보낼 양에 한도를 두고 가까운 것부터 보내면, 한도가 낮게 잡힌 쪽은 멀리 있는 NPC를 늦게 받거나 못 받습니다.

왜 사람 많은 곳에서 서버가 연결별 전송량 한도 안에서 중요도 순으로 전송 → 그러면 대역폭 추정이 낮게 잡힌 연결(예: 백그라운드 창이라 수신 확인이 늦은 쪽)은 뒤쪽 개체를 계속 미룸 → 화면에서는 멀리 있는 NPC가 한쪽에서만 늦게 보이거나 안 보임

증상: 안 보임·유령 개체, 입력 지연
요인: 지연
누가 겪나: 같은 PC의 한쪽 클라만, 특정 장소·채널
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 밀린 개체의 우선순위를 시간이 지날수록 올리기(starvation 방지), 최소 갱신 주기 보장. 클라이언트: 백그라운드에서도 수신 확인을 제때 보내 대역폭 추정이 낮아지지 않게.
그래프에서는: 인원·부하를 따라 오름 · 연결별 미룬 개체 수, 연결별 전송량
확인할 곳: 서버에 연결마다 틱별 전송 바이트, 전송 한도(추정 대역폭), 보내지 못하고 미룬 개체 수, 개체별 마지막 전송 뒤 지난 시간을 남김. Unreal은 Networking Insights에서 연결별 패킷 크기와 그 안에 담긴 복제 개체를 볼 수 있음
이러면 맞음: 안 보이는 NPC가 그 연결에서 오래 미뤄진 개체이고 그 연결의 한도가 다른 연결보다 낮으며 사람이 붐빌수록 미룬 개체가 늘어남
이러면 아님: 미룬 개체가 없고 그 NPC도 제때 보냈으면 전송 뒤 단계(수신 버퍼, 로딩, 표시 옵션). 모든 연결이 한도에 붙어 있으면 서버 전체의 전송량·시야 설계 문제
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 3건

Actor Priority in Unreal Engine Epic Games
대역폭이 포화되면 우선순위(거리·시선·마지막 복제 후 경과 시간)에 따라 복제할 액터를 고름. 모든 액터가 매번 복제되지는 않음
State Synchronization Gaffer On Games
우선순위 누적: 이번 패킷에 못 들어간 개체가 다음 패킷에 먼저 들어가고 대역폭 한도는 실시간 조절
Networking Insights in Unreal Engine Epic Games
연결별로 주고받은 패킷의 크기와 그 안에 담긴 복제 개체·속성을 보여 줌

시계 추정 오차로 개체 보류 Clock estimate error holds or discards entities

ID pt-clock-hold · 주 담당 게임개발팀·클라이언트 개발

클라이언트가 추정한 서버 시각이 틀리면, 막 도착한 개체 정보를 “아직 미래”라며 보류하거나 “너무 옛날”이라며 버립니다.

왜 한쪽 클라이언트의 서버 시각 추정이 크게 어긋남(로딩 중 측정, 절전 복귀) → 그러면 보간 기준 시각과 개체 정보 시각이 맞지 않음 → 화면에서는 개체가 늦게 나타나거나 멈춘 채로 보임

증상: 안 보임·유령 개체, 뚝뚝 끊김
요인: 지연
누가 겪나: 같은 PC의 한쪽 클라만
언제: 가만히 있다가, 접속·점검 직후
담당: 주 담당 게임개발팀·클라이언트 개발
게임개발팀 할 일: 시간 동기화를 주기적으로 다시 하고 차이가 크면 즉시 재설정, 로딩 중이나 절전 복귀 직후에 잰 값은 쓰지 않기.
그래프에서는: 일부만 높음 · 클라이언트별 서버 시각 추정 오차
확인할 곳: 클라이언트에 추정한 서버 시각, RTT, 시간 동기화를 다시 한 시각, 개체 정보를 보류하거나 버린 횟수를 기록. 로딩 직후나 절전 복귀 직후에 재현해 봄
이러면 맞음: 문제가 난 클라이언트만 추정 오차가 재설정 기준(Unity는 hardResetThresholdSec, 기본 0.2초)을 넘고 개체 정보를 미래라며 보류하거나 과거라며 버린 기록이 있으며 시간 동기화를 다시 하면 바로 정상
이러면 아님: 추정 오차가 작은데 늦게 나타나면 연결별 전송 예산·우선순위나 로딩 쪽 원인
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처 2건

NetworkTimeSystem class (Netcode for GameObjects 2.5) Unity
시간 차이가 hardResetThresholdSec(기본 0.2초)를 넘으면 강제로 맞추고, 평소엔 adjustmentRatio로 조금씩 빠르게·느리게 조정
NetworkTime and ticks (Netcode for GameObjects 2.5) Unity
LocalTime은 서버보다 앞서고 ServerTime은 뒤처짐. 늦게 도착한 메시지는 대기 시간이 음수가 될 수 있음

TCP 재전송의 근본 원인

무선 구간 손실 Wi-Fi / cellular link loss

ID rt-wireless · 주 담당 외부·외부 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발

와이파이와 모바일망은 무선 구간에서 몇 번 재전송하다가, 그래도 안 되면 패킷을 버립니다. 버려진 패킷은 TCP가 한참 뒤에 다시 보냅니다.

왜 전파가 약하거나 간섭이 심해 무선 구간 전송이 연달아 실패 → 그러면 무선 장비의 재시도 한도(보통 수~십여 번)를 넘으면 패킷을 버림 → 화면에서는 TCP 재전송 대기만큼 멈춤, 뒤 패킷은 수신 버퍼에서 대기하다 몰아치기

증상: 멈춤, 몰아치기, 순간이동
요인: 손실, 지터
누가 겪나: 나만, 같은 집
언제: 가끔 무작위로, 이동 중·지역 전환 때
담당: 주 담당 외부·외부 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: TCP_NODELAY 켜기(Nagle이 켜져 있으면 RACK이 손실 판단에 쓸 뒤따르는 패킷이 없음), 재전송으로 막힌 동안 보낼 상태 업데이트는 쌓아 두지 말고 최신 것만 보내기(커널에 쌓이는 양은 TCP_NOTSENT_LOWAT로 제한). 클라이언트: TCP_NODELAY 켜기(내 입력 방향의 손실은 클라이언트 OS가 복구), 손실이 몰리거나 핑이 급등하면 화면에 네트워크 상태 표시.
인프라팀 할 일: RACK-TLP로 손실 복구를 빠르게 하기(서버는 무선 손실을 막을 수 없고 복구를 빠르게 하는 것까지만 가능), 최신 리눅스 기본값인 net.ipv4.tcp_recovery=1(RACK)·net.ipv4.tcp_early_retrans=3(TLP)이 바뀌지 않았는지 확인.
외부 할 일: 유저에게 유선 연결, 5GHz·6GHz 사용, 공유기 위치·채널 바꾸기 안내.
수치 감각: 무선 손실 1%면 게임 패킷 100개에 1개가 사라집니다. 1초에 10개를 받으면 10초에 한 번꼴로 멈칫합니다. RACK-TLP가 없으면 한 번마다 RTO(핑 + 200ms 이상)만큼 멈춥니다.
그래프에서는: 일부만 높음 · 연결별 재전송률, 연결별 RTT(핑)
확인할 곳: 유저 PC에서 공유기(게이트웨이) 주소와 게임 서버로 각각 ping을 수백 번 보내 손실과 지연 폭을 비교하고, 유선이나 모바일 데이터로 바꿔 다시 잼. 서버에서는 ss -ti로 그 유저 연결의 retrans와 rtt(평균/편차)를 봄
이러면 맞음: 공유기까지 가는 ping에서 이미 손실이나 들쭉날쭉한 지연이 보이고 유선으로 바꾸면 사라짐. 서버에서 보면 그 유저 연결만 retrans와 RTT 편차가 큼
이러면 아님: 공유기까지는 깨끗하고 그 너머에서 손실이 시작되면 통신사·경로 쪽(“병목 대기열 넘침”, “경로 변경·ECMP 불량 경로”). 같은 통신사 유저 여럿이 동시에 나빠지면 통신사 구간부터 봄
확인 수단: 유저 쪽 환경에서 확인
더 알아보기: 무선 장비의 재시도는 지터를 만들고(재시도마다 수 ms), 재시도 한도를 넘은 경우만 손실이 됩니다. 그래서 무선 품질이 나빠질수록 “지터 → 가끔 멈춤 → 잦은 멈춤” 순서로 증상이 커집니다. 공유기(AP) 사이를 옮겨 가는 순간(로밍)에는 수십 ms~수 초 동안 연달아 잃기도 합니다. 모바일망은 기지국 구간에서 재전송을 많이 하므로, 손실보다 수백 ms 지연 급등으로 나타나는 경우가 많습니다.
실제 사례: Square Enix 2021: FINAL FANTASY XIV 확장팩 출시 혼잡과 로그인 대기열 오류

출처 8건

net/wireless/core.c Linux kernel
리눅스 무선 스택의 기본 재시도 한도: 짧은 프레임 7번, 긴 프레임 4번(dot11ShortRetryLimit·dot11LongRetryLimit)
RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
모바일망은 링크 계층 재전송 덕분에 IP 손실은 적지만 그 복구가 지터와 지연 급등으로 나타남
Wi-Fi roaming support in Apple devices Apple
AP를 옮길 때 새 AP 인증이 끝날 때까지 데이터를 보낼 수 없고 802.1X 환경에서는 몇 초 걸릴 수 있음
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK(시간 기준 손실 판단)과 TLP(끝 패킷 재전송)의 정의
IP Sysctl Linux kernel
tcp_recovery 기본 0x1(RACK), tcp_early_retrans 기본 3(TLP 켜짐), TCP_NOTSENT_LOWAT·tcp_notsent_lowat로 아직 보내지 않은 데이터 양 제한
tcp(7) — Linux manual page Linux man-pages
TCP_NODELAY는 Nagle 알고리즘을 꺼 작은 데이터도 바로 보냄
include/net/tcp.h Linux kernel
RTO 최소값 TCP_RTO_MIN = 200ms
misc/ss.c iproute2
ss -ti는 retrans:지금 재전송 중인 수/누적 재전송 수와 rtt:RTT/RTT 편차(rttvar)를 표시

병목 대기열 넘침 (혼잡 손실) Tail drop at a congested bottleneck

ID rt-queue-drop · 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부, 게임개발팀·클라이언트 개발

공유기, 통신사 사이 연결 구간, 데이터센터 회선처럼 가장 좁은 곳의 대기열이 가득 차면 새로 오는 패킷을 버립니다.

왜 영상·다운로드·다른 사용자 트래픽으로 병목 구간이 꽉 참 → 그러면 대기열이 찬 동안 새로 도착하는 패킷이 연달아 버려짐(tail drop). 버려지지 않은 패킷도 꽉 찬 대기열 끝에서 기다림 → 화면에서는 여러 패킷이 한꺼번에 사라져 긴 멈춤 뒤 몰아치기, 저녁 시간에 잦음

증상: 멈춤, 몰아치기, 고무줄
요인: 손실, 지연
누가 겪나: 같은 집, 특정 지역·통신사, 서버 전체
언제: 저녁 피크 시간, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 외부·외부, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 손실이 몰리거나 핑이 급등하면 화면에 네트워크 상태 표시(같은 회선의 대용량 전송 가능성 안내).
인프라팀 할 일: 데이터센터 회선 여유 확보, 우리 회선·스위치 포트의 대기열 폐기(output drops) 카운터 확인, 통신사 구간이 막히면 다른 회선·피어링으로 우회.
외부 할 일: 유저에게 공유기 SQM(fq_codel, CAKE)과 ECN 사용 안내(대기열이 넘치기 전에 속도를 줄이게 함), 통신사에 병목 구간 증설 요청.
수치 감각: 대기열이 넘치는 순간에는 수십 ms 동안 들어오는 패킷의 상당수가 한꺼번에 사라집니다. 연달아 잃고 다시 보낸 것까지 잃기 쉬워 RTO까지 가는 경우가 많습니다.
그래프에서는: 특정 시간대에만 높음 · 재전송률, RTT(핑)
확인할 곳: 서버 재전송률(nstat을 1분 간격으로 실행한 TcpRetransSegs ÷ TcpOutSegs 증가분)과 연결별 RTT를 지역·통신사·시간대별로 나눠 보고, 우리 회선·스위치 포트의 출력 폐기(ifOutDiscards)를 함께 봄. 문제 지역으로 피크 시간과 한가한 시간에 mtr을 떠서 비교함
이러면 맞음: 저녁 피크에만 재전송률이 오르고 손실 직전에 RTT가 먼저 오름(대기열이 차는 모습). mtr에서 피크 시간에만 어느 구간부터 끝까지 손실과 지연이 함께 늘어남
이러면 아님: 손실 직전에 RTT가 오르지 않으면 “폴리서의 초과분 폐기”. 시간대와 상관없이 늘 비슷하게 잃으면 “물리 오류”나 “경로 변경·ECMP 불량 경로”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: Riot Games 2015: 멀리 돌아가던 League of Legends 트래픽과 Riot Direct

출처 9건

RFC 7567: IETF Recommendations Regarding Active Queue Management IETF
tail drop은 대기열을 오래 가득 찬 채로 두어 지연을 늘리고 몰린 손실을 만든다는 설명과 AQM 권고
RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm IETF
fq_codel: 흐름별 대기열과 AQM으로 대기열을 짧게 유지해 버퍼블로트를 줄임
RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP IETF
ECN: 패킷을 버리는 대신 IP 헤더 표시로 혼잡을 알림
Smart Queue Management Bufferbloat.net
SQM: 흐름별 스케줄링, 대기열 길이 관리(AQM), 셰이핑을 함께 쓰는 방식
Cake Bufferbloat.net
CAKE: 셰이퍼와 fq_codel 계열 대기열 관리를 합친 공유기용 SQM
net/ipv4/proc.c Linux kernel
nstat에 나오는 TcpRetransSegs·TcpOutSegs(Tcp 항목의 RetransSegs·OutSegs)
nstat(8) — Linux manual page iproute2
nstat은 기본으로 이전 실행 이후의 증가분을 보여 줌
RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards: 오류가 없는데도 버퍼 공간 확보 등의 이유로 내보내지 않고 버린 패킷 수
An Internet-Wide Analysis of Traffic Policing Google
대기열 넘침은 손실 전에 대기 시간과 RTT가 먼저 오르고 폴리싱은 RTT 증가 없이 초과분을 버린다는 구분(SIGCOMM 2016)

송신 버스트로 얕은 버퍼 넘침 Sender bursts overflow shallow buffers

ID rt-burst · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·네트워크 인프라

서버가 틱마다 수천 명분 업데이트를 한순간에 몰아 보내면, 스위치의 작은 버퍼나 클라우드의 순간 한도가 1ms도 안 돼 넘쳐 일부가 버려집니다.

왜 틱 시작 순간 모든 사람에게 보낼 패킷을 한꺼번에 전송 → 그러면 여러 서버의 트래픽이 모이는 스위치 포트 버퍼(포트당 수백 KB~수 MB)나 클라우드 인스턴스 한도가 순간적으로 넘침(평균 사용률은 낮음) → 화면에서는 여러 사람이 동시에 순간이동·멈칫, 평균 지표로는 원인이 안 보임

증상: 순간이동, 멈춤, 몰아치기
요인: 손실
누가 겪나: 특정 장소·채널, 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·네트워크 인프라
게임개발팀 할 일: 한 틱의 전송을 틱 안에 나눠 보내기(수천 개 연결이 틱 시작에 몰리는 것은 연결별 페이싱으로 잘 안 풀림), 서버마다 틱 시작 시각을 분산, 큰 데이터를 보내는 연결은 SO_MAX_PACING_RATE로 속도 상한.
인프라팀 할 일: 서버 장비·OS: 서버 전체 송신 속도 상한(서버 OS의 셰이퍼, 리눅스 tc), 연결 하나가 몰아 보내는 것은 페이싱(리눅스 fq 큐, BBR)으로 고르게. 네트워크: 버퍼 큰 스위치, 스위치 포트의 출력 폐기 카운터를 짧은 간격으로 확인(평균 사용률로는 안 보임).
수치 감각: 10Gbps 포트로 1ms 동안 보낼 수 있는 양은 약 1.25MB. 여러 서버의 틱이 맞물려 한 포트로 몰리면 버퍼가 순식간에 찹니다.
그래프에서는: 인원·부하를 따라 오름 · 스위치 포트 출력 폐기 수, 재전송률
확인할 곳: 서버가 붙은 스위치 포트와 그 윗단 포트의 출력 폐기(ifOutDiscards)를 몇 초 간격으로 모으고, 클라우드면 ethtool -S의 bw_out_allowance_exceeded·pps_allowance_exceeded를 봄. 같은 시각의 재전송을 bcc tcpretrans로 모아 맞춰 봄
이러면 맞음: 분 단위 평균 사용률은 낮은데 출력 폐기나 allowance 초과가 늘고 그 양이 동시 접속·한곳에 모인 인원을 따라 커짐. 재전송이 특정 유저 IP 대역(통신사·지역)에 몰리지 않고 그 서버의 여러 연결에서 같은 순간에 생김
이러면 아님: 같은 포트에 CRC·입력 오류가 함께 늘면 “물리 오류”. 받는 서버의 NIC 폐기 카운터나 softnet dropped가 늘면 “수신 서버 호스트의 패킷 폐기”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 페이싱은 연결마다 따로 작동합니다. 수천 개 연결이 틱 시작에 한두 개씩 보내는 몰림은 연결별 페이싱으로 잘 안 풀리고, 게임 서버가 보내는 시점을 직접 나눠야 합니다. 반대로 한 연결이 큰 데이터를 보낼 때는 NIC가 수십 KB 데이터를 패킷 크기로 잘라 연달아 내보내는데(TSO), 이런 몰림은 페이싱이 잘 나눠 줍니다.

출처 7건

High-Resolution Measurement of Data Center Microbursts Meta
데이터센터 랙 스위치 버스트의 70% 이상이 수십 µs 안에 끝나고 분 단위 평균 사용률과 드롭의 관계가 약함(IMC 2017)
tc-fq(8) — Linux manual page iproute2
fq 큐는 소켓(연결)마다 페이싱하고 SO_MAX_PACING_RATE로 연결별 최대 속도를 정함
net/ipv4/tcp_bbr.c Linux kernel
BBR은 추정한 병목 대역폭으로 pacing_rate를 정해 보냄
IP Sysctl Linux kernel
TCP는 흐름 속도에 맞춰 TSO 프레임 크기를 정함(최대 64KB, tcp_min_tso_segs)
Monitor network performance for ENA settings on your EC2 instance AWS
bw_out_allowance_exceeded·pps_allowance_exceeded: 인스턴스의 대역폭·초당 패킷 한도를 넘어 대기열에 넣거나 버린 패킷 수
RFC 2863: The Interfaces Group MIB IETF
ifOutDiscards: 오류가 없는데도 버퍼 공간 확보 등의 이유로 내보내지 않고 버린 패킷 수
Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
재전송마다 상대 주소·포트·연결 상태를 한 줄씩 보여 줌

폴리서의 초과분 폐기 Traffic policing

ID rt-policer · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발

통신사 요금제, 클라우드 인스턴스 한도, DDoS 방어 장비는 정해진 속도를 넘는 패킷을 대기열에 넣지 않고 즉시 버리기도 합니다.

왜 순간 전송량이 허용 속도·허용 버스트를 넘음 → 그러면 넘는 패킷을 대기열 없이 바로 폐기(폴리싱) → 화면에서는 버스트가 큰 순간마다 여러 개가 사라져 멈춤 뒤 몰아치기, 평균 속도는 한도 아래로 보임

증상: 멈춤, 몰아치기, 순간이동
요인: 손실
누가 겪나: 서버 전체, 특정 지역·통신사, 나만
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발
게임개발팀 할 일: 틱마다 몰아 보내는 양을 틱 안에 나눠 보내 순간 전송량을 허용 버스트 아래로 낮추기, 초당 패킷 수 한도에 걸리면 한 틱의 메시지를 한 패킷에 합치기.
인프라팀 할 일: 네트워크: 장비의 폴리서 초과 카운터 확인, 폴리서 대신 셰이퍼, 허용 버스트 늘리기. 서버 장비·OS: 클라우드 한도 초과 지표(AWS는 ethtool -S의 bw_out_allowance_exceeded·pps_allowance_exceeded) 확인, 인스턴스 상향, 서버 페이싱(리눅스 fq 큐).
수치 감각: 셰이퍼(대기열에 넣어 늦춤)는 지연을 늘리고 폴리서(즉시 폐기)는 손실을 늘립니다. TCP 게임 연결은 손실 한 번에 수백 ms 멈출 수 있어, 한도를 잠깐 넘는 정도라면 대개 폴리서 쪽이 영향이 큽니다.
그래프에서는: 한도에 닿아 평평해짐 · 짧은 간격의 송신량, 폴리서·allowance 초과 카운터
확인할 곳: 폴리서가 걸린 장비의 초과(exceed)·폐기 카운터를 보고 클라우드면 ethtool -S의 bw_out_allowance_exceeded·pps_allowance_exceeded를 봄. 손실이 난 연결은 ss -ti의 rtt나 패킷 캡처로 손실 직전의 RTT를 봄
이러면 맞음: 초과 카운터가 늘고 짧은 간격으로 본 송신량이 어떤 값에서 잘린 듯 평평함. 손실 직전에 RTT가 오르지 않고 버스트가 큰 순간에만 여러 패킷이 한꺼번에 사라짐
이러면 아님: 손실 직전에 RTT가 먼저 오르면 대기열 넘침(“병목 대기열 넘침”, “송신 버스트로 얕은 버퍼 넘침”). 초과 카운터가 그대로면 다른 원인
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

RFC 2475: An Architecture for Differentiated Services IETF
셰이핑은 패킷을 늦춰 트래픽 프로파일에 맞추고 폴리싱은 프로파일을 넘는 패킷을 버린다는 정의
An Internet-Wide Analysis of Traffic Policing Google
폴리싱이 걸린 전송은 손실률이 평균 6배 높고 페이싱·셰이핑으로 같은 목적을 이룰 수 있음. 폴리싱은 RTT 증가 없이 초과분을 버리고 대기열 넘침은 손실 전에 RTT가 오른다는 구분(SIGCOMM 2016)
Monitor network performance for ENA settings on your EC2 instance AWS
ethtool -S의 bw_out_allowance_exceeded·pps_allowance_exceeded: 인스턴스 한도를 넘어 대기열에 넣거나 버린 패킷 수
tc-fq(8) — Linux manual page iproute2
리눅스 fq 큐의 연결별 페이싱
ss(8) — Linux manual page iproute2
ss -i의 rtt(평균 왕복 시간)

물리 오류 (불량 선·광모듈·커넥터) Bit errors: bad cable, optics, dirty fiber

ID rt-physical · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 외부·외부

케이블 손상, 먼지 낀 광커넥터, 수명이 다한 광모듈은 비트 오류를 만들고 깨진 패킷은 장비가 조용히 버립니다.

왜 선·광모듈·커넥터 불량으로 비트가 뒤집힘 → 그러면 체크섬(CRC)이 맞지 않는 패킷을 장비가 폐기 → 화면에서는 그 경로를 지나는 사람만 꾸준히 짧게 멈칫했다 몰아치기, 시간대와 상관없음

증상: 멈춤, 몰아치기, 순간이동
요인: 손실
누가 겪나: 특정 장소·채널, 같은 집
언제: 항상
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 외부·외부
인프라팀 할 일: CRC 오류는 깨진 방향의 받는 쪽에 쌓이므로 양쪽 끝을 모두 확인. 네트워크: 장비 포트의 CRC·입력 오류 카운터 확인, 광 신호 세기 점검(스위치의 광모듈 정보), 광커넥터 청소, 선·광모듈 교체. 서버 장비·OS: 서버 ethtool -S의 rx_crc_errors(드라이버마다 이름이 조금 다름) 확인, 광 신호 세기 점검(ethtool -m), 서버 쪽 선·NIC 교체.
외부 할 일: 유저 집 구간이면 랜선·공유기 교체 안내, 통신사 회선 구간이면 통신사에 회선 점검 요청.
수치 감각: 0.1% 손실도 게임 패킷 1,000개에 한 번입니다. 그 경로를 지나는 사람이 수십 명이면 몇 초마다 누군가 멈칫합니다. 비트 오류는 큰 패킷일수록 잘 걸립니다.
그래프에서는: 일부만 높음 · 포트별 CRC 오류 수, 서버·포트별 재전송률
확인할 곳: 링크 양쪽 끝의 CRC 카운터를 봄. 서버는 ethtool -S의 rx_crc_errors나 ip -s -s link의 crc, 스위치는 포트의 FCS 오류(dot3StatsFCSErrors)·입력 오류(ifInErrors). 광 링크면 ethtool -m과 스위치의 광모듈 정보로 수신 광 세기를 봄
이러면 맞음: 한 포트의 CRC 오류가 시간대와 상관없이 꾸준히 늘고 그 포트를 지나는 서버·연결만 재전송률이 높음. 같은 종류의 다른 링크보다 수신 광 세기가 낮음
이러면 아님: CRC는 그대로인데 출력 폐기만 늘면 대기열 넘침(“송신 버스트로 얕은 버퍼 넘침”, “병목 대기열 넘침”). 한쪽의 늦은 충돌과 다른 쪽의 CRC가 함께 늘면 “듀플렉스 불일치”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 3건

Interface statistics Linux kernel
rx_crc_errors는 받는 쪽 인터페이스가 CRC 오류로 센 패킷 수, ip -s -s link와 ethtool -S로 확인
ethtool(8) — Linux manual page ethtool
-S로 NIC·드라이버별 통계, -m으로 광모듈(SFP+·QSFP) EEPROM과 광 진단 정보 확인
RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
스위치 포트의 FCS 오류(dot3StatsFCSErrors), 이 오류는 입력 오류(ifInErrors)로 합산

듀플렉스 불일치 Duplex mismatch

ID rt-duplex · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라

한쪽은 자동 협상, 다른 쪽은 속도·듀플렉스를 고정해 두면 한쪽이 반이중으로 동작하며 부하가 걸릴 때마다 충돌로 패킷을 잃습니다.

왜 장비 한쪽만 속도·듀플렉스를 고정 설정 → 그러면 한쪽은 전이중, 다른 쪽은 반이중으로 동작해 충돌·늦은 충돌 발생 → 화면에서는 평소엔 멀쩡하다가 트래픽이 늘면 그 장비를 지나는 사람 모두가 멈췄다 몰아치기

증상: 멈춤, 몰아치기
요인: 손실
누가 겪나: 서버 전체, 특정 장소·채널
언제: 사람이 몰릴 때, 저녁 피크 시간
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라
인프라팀 할 일: 양쪽 모두 자동 협상 또는 양쪽 모두 같은 값으로 고정. 네트워크: 스위치 포트 상태에서 속도·듀플렉스 확인, 포트 카운터에서 반이중 쪽은 늦은 충돌, 전이중 쪽은 CRC 오류·너무 짧은 프레임(runt)이 느는지 확인. 서버 장비·OS: ethtool로 속도·듀플렉스 확인.
수치 감각: 1Gbps 구리선은 자동 협상이 필수이고 10Gbps 이상에는 반이중이 아예 없습니다. 그래서 요즘은 주로 100Mbps 이하의 오래된 장비, 관리용 포트, 일부 회선 연결 구간에서 생깁니다.
그래프에서는: 인원·부하를 따라 오름 · 포트 늦은 충돌·CRC 오류 수, 재전송률
확인할 곳: 링크 양쪽의 실제 속도·듀플렉스를 봄. 서버는 인터페이스 이름만 붙여 실행한 ethtool, 스위치는 포트 상태나 SNMP의 dot3StatsDuplexStatus. 늦은 충돌(서버 tx_window_errors, 스위치 dot3StatsLateCollisions)과 CRC 오류도 함께 봄
이러면 맞음: 한쪽은 반이중, 다른 쪽은 전이중으로 나옴. 트래픽이 늘 때마다 반이중 쪽은 늦은 충돌, 전이중 쪽은 CRC 오류가 함께 늘어남
이러면 아님: 양쪽 속도·듀플렉스가 같고 CRC만 늘면 “물리 오류”. 10Gbps 이상 링크는 반이중이 없으니 이 원인에서 뺌
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 6건

Linux Base Driver for Intel(R) Ethernet Network Connection Linux kernel
1000BASE-T 규격은 자동 협상을 요구함
IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives IEEE
10기가비트 이더넷은 전이중만 지원
IEEE P802.3ba Objectives IEEE
40·100기가비트 이더넷도 전이중만 지원
Interface statistics Linux kernel
tx_window_errors는 늦은 충돌(late collision)로 실패한 전송 수, rx_crc_errors는 CRC 오류로 받은 패킷 수
ethtool(8) — Linux manual page ethtool
ethtool -s의 speed·duplex·autoneg로 속도·듀플렉스·자동 협상 설정, 인터페이스 이름만 주면 현재 설정을 보여 줌
RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types IETF
dot3StatsDuplexStatus(halfDuplex·fullDuplex로 현재 듀플렉스 표시), dot3StatsLateCollisions(늦은 충돌 수)

수신 서버 호스트의 패킷 폐기 Receiver host drops (ring, softirq, CPU)

ID rt-host-drop · 주 담당 인프라팀·서버 인프라

패킷은 서버까지 왔는데 NIC의 링 버퍼(도착한 패킷을 잠시 담아 두는 버퍼)가 넘치거나, 커널의 수신 처리 코어가 포화되어 버려집니다.

왜 접속자 폭증·코어 하나에 몰린 인터럽트·가상 머신 CPU 스틸·가상 스위치 과부하 → 그러면 링 버퍼(rx_missed_errors 등, 이름은 드라이버마다 다름)나 커널 수신 대기열(softnet dropped)에서 폐기 → 화면에서는 사람 몰릴 때 서버 전체에서 동시에 입력이 늦게 먹히고 멈칫

증상: 입력 지연, 멈춤, 몰아치기, 순간이동
요인: 손실, 정체
누가 겪나: 서버 전체
언제: 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라
인프라팀 할 일: ethtool -S의 rx_missed_errors 같은 폐기 카운터와 /proc/net/softnet_stat의 dropped를 모니터링에 추가, 링 버퍼 크기 늘리기(ethtool -G), RSS·인터럽트를 여러 코어로 분산, 게임 스레드와 수신 처리 코어 분리, CPU 여유 확보, 가상 머신이면 CPU 스틸·가상 스위치 부하 확인.
수치 감각: 서버가 받다가 버린 패킷은 클라이언트가 다시 보내므로 서버의 재전송 지표에는 잘 안 잡힙니다. 이런 폐기는 ethtool -S의 rx_missed_errors 같은 폐기 카운터(이름은 드라이버마다 다름)와 /proc/net/softnet_stat의 dropped에 먼저 나타납니다.
그래프에서는: 한도에 닿아 평평해짐 · 코어별 softirq 사용률, NIC 폐기 카운터
확인할 곳: ethtool -S의 폐기 카운터(rx_missed_errors 등, mlx5는 rx_out_of_buffer·rx_discards_phy), ip -s -s link의 missed, /proc/net/softnet_stat의 2번째 열(dropped)·3번째 열(time_squeeze)을 보고, mpstat -P ALL로 코어별 %soft(소프트 인터럽트 처리)를 봄. 가상 머신이면 %steal도 봄
이러면 맞음: 사람이 몰리는 시각에 폐기 카운터나 softnet dropped가 늘고 수신 처리를 맡은 코어의 %soft가 100% 가까이에서 더 오르지 못함. 그 서버의 모든 연결에서 동시에 입력이 늦어짐
이러면 아님: 서버의 폐기 카운터가 그대로이고 재전송이 특정 지역·통신사 연결에 몰리면 경로 쪽 손실. 서버가 보낸 패킷을 경로에서 잃으면 서버의 nstat TcpRetransSegs가 늘고 이 카운터들은 그대로임
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 10건

Interface statistics Linux kernel
rx_missed_errors는 버퍼가 없어 호스트가 받지 못한 패킷 수(/proc/net/dev에서는 drop에 합산), ip -s -s link로 확인
drivers/net/ethernet/intel/igb/igb_ethtool.c Linux kernel
ethtool -S 카운터 이름은 드라이버가 정함(예: igb의 rx_missed_errors·rx_no_buffer_count)
Ethtool counters Linux kernel
mlx5 드라이버의 rx_out_of_buffer(수신 큐에 버퍼가 없음)·rx_discards_phy(포트 버퍼 부족으로 폐기)
net/core/net-procfs.c Linux kernel
/proc/net/softnet_stat은 CPU마다 한 줄, 16진수이며 2번째 열이 dropped, 3번째 열이 time_squeeze
Documentation for /proc/sys/net/ Linux kernel
netdev_max_backlog: 커널이 처리하는 것보다 빨리 들어올 때 쌓아 두는 수신 대기열 한도
Scaling in the Linux Networking Stack Linux kernel
RSS: NIC가 여러 수신 큐로 나눠 여러 CPU에서 처리
ethtool(8) — Linux manual page ethtool
-G(--set-ring)로 링 버퍼 크기 변경
proc_stat(5) — Linux manual page Linux man-pages
/proc/stat의 steal: 가상화 환경에서 다른 OS가 CPU를 쓴 시간
mpstat(1) — Linux manual page sysstat
mpstat -P ALL로 코어별 사용률, %soft는 소프트 인터럽트 처리 시간, %steal은 하이퍼바이저가 다른 가상 CPU를 처리하느라 기다린 시간
net/ipv4/proc.c Linux kernel
nstat에 나오는 TcpRetransSegs(Tcp 항목의 RetransSegs)

방화벽·연결 추적의 폐기 Stateful firewall / conntrack drops

ID rt-stateful-fw · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발

방화벽이나 리눅스 연결 추적(conntrack, 지나가는 연결을 테이블에 기록하는 기능)은 테이블이 가득 차거나, 연결 상태가 맞지 않는다고 판단하면 패킷을 버립니다.

왜 연결 추적 테이블 가득(table full), 또는 오가는 경로가 달라 한쪽 방향만 방화벽을 지남(비대칭 경로) → 그러면 방화벽이 “모르는 연결”이나 “윈도우 범위를 벗어난 시퀀스 번호”의 패킷으로 보고 폐기 → 화면에서는 테이블이 차면 새 접속이 막히고 경로가 어긋나면 그 경로의 사람만 반복 재전송 끝에 접속 끊김

증상: 멈춤, 접속 끊김, 접속 불가·무한 로딩
요인: 손실
누가 겪나: 서버 전체, 특정 지역·통신사
언제: 사람이 몰릴 때, 접속·점검 직후, 가끔 무작위로
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 테이블이 차는 경우에 대비해 로그인 대기열 시스템으로 몰리는 접속 조절, 짧은 연결을 반복하지 않게 연결 재사용(서버 간 호출 포함), 하트비트가 끊긴 연결은 먼저 정리. 클라이언트: 접속이 실패하거나 끊기면 재시도 간격을 늘려 가며 무작위로 분산(테이블이 찼을 때 한꺼번에 다시 몰리지 않게).
인프라팀 할 일: 네트워크: 방화벽의 연결 추적 테이블 크기 늘리기, 게임 포트는 연결 추적에서 빼기, 왕복 경로가 같은 방화벽을 지나게 라우팅 맞추기, 방화벽의 TCP 윈도우 검사 설정 확인. 서버 장비·OS: 리눅스 테이블 크기 늘리기(nf_conntrack_max), 게임 포트는 연결 추적에서 빼기(NOTRACK), TCP 윈도우 검사 설정 확인(nf_conntrack_tcp_be_liberal), AWS는 conntrack_allowance_exceeded도 확인.
수치 감각: 리눅스 conntrack 기본 한도(nf_conntrack_max)는 메모리에 따라 수만~수십만 개. 현재 개수(nf_conntrack_count)가 한도에 닿으면 로그에 “nf_conntrack: table full, dropping packet”이 남습니다.
그래프에서는: 한도에 닿아 평평해짐 · conntrack 항목 수(nf_conntrack_count), 새 접속 실패 수
확인할 곳: 리눅스 서버는 nf_conntrack_count와 nf_conntrack_max, dmesg의 “nf_conntrack: table full, dropping packet”, /proc/net/stat/nf_conntrack의 drop·invalid(코어마다 한 줄, 16진수)를 봄. 방화벽은 세션 테이블 사용량과 드롭 로그, AWS는 ethtool -S의 conntrack_allowance_exceeded를 봄
이러면 맞음: 항목 수가 한도에서 평평해지고 같은 시각에 table full 로그와 drop, 또는 conntrack_allowance_exceeded가 늘어남. 비대칭 경로면 한도에는 여유가 있는데 invalid와 방화벽 드롭 로그가 특정 경로의 연결에서 늘어남
이러면 아님: 항목 수가 한도에서 멀고 invalid·드롭 로그도 그대로면 다른 원인. 테이블은 여유가 있는데 방화벽의 CPU나 초당 패킷 수가 가득하면 “중간 장비 처리 한도 초과”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 5건

Netfilter Conntrack Sysfs variables Linux kernel
nf_conntrack_max 기본값은 해시 버킷 수(메모리÷16384, 1,024~262,144), 현재 개수는 nf_conntrack_count, nf_conntrack_tcp_be_liberal은 윈도우 밖 RST만 INVALID로 처리
net/netfilter/nf_conntrack_core.c Linux kernel
테이블이 가득 차면 “nf_conntrack: table full, dropping packet” 로그를 남기고 폐기(drop 통계 증가), 연결 상태에 맞지 않는 패킷은 invalid 통계 증가
iptables-extensions(8) — Linux manual page netfilter
raw 테이블의 CT --notrack으로 연결 추적에서 제외
Amazon EC2 security group connection tracking AWS
인스턴스별 추적 연결 수 한도를 넘으면 패킷을 버리고 conntrack_allowance_exceeded로 확인, 비대칭 경로는 피하라는 권고
net/netfilter/nf_conntrack_standalone.c Linux kernel
/proc/net/stat/nf_conntrack은 코어마다 한 줄, 16진수이고 entries·invalid·insert_failed·drop·early_drop 등의 열이 있음

중간 장비 처리 한도 초과 (방화벽·IPS·DDoS 방어) Inline appliance PPS / CPU overload

ID rt-appliance-pps · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발

방화벽, 침입 방지 장비(IPS), DDoS 방어 장비는 지나가는 패킷을 하나하나 검사합니다. 검사 능력을 넘는 순간부터 처리하지 못한 패킷을 버립니다.

왜 피크 시간·이벤트에 작은 게임 패킷이 초당 수십만 개 넘게 몰림, 또는 검사 규칙이 무거움 → 그러면 장비의 CPU·초당 패킷 수 한도가 차서 장비에서 폐기. 오탐이면 정상 패킷도 차단 → 화면에서는 그 장비 뒤의 서버 전체에서 동시에 멈춤·순간이동, 사람 몰릴 때만 심해짐

증상: 멈춤, 몰아치기, 순간이동, 접속 끊김
요인: 손실, 지연
누가 겪나: 서버 전체, 특정 지역·통신사
언제: 저녁 피크 시간, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 게임 트래픽 패턴(포트, 패킷 크기, 초당 패킷 수)을 인프라팀에 공유, 한 틱에 보낼 작은 메시지는 모아서 한 번에 보내 패킷 수 줄이기.
인프라팀 할 일: 장비의 CPU·초당 패킷 수·드롭 카운터를 게임 지표와 함께 보기, 작은 패킷 기준으로 장비 용량 잡기, 게임 포트는 무거운 검사에서 빼기, DDoS 방어 규칙을 게임 트래픽 패턴에 맞추기.
수치 감각: 장비 사양의 “10Gbps”는 1,500바이트 큰 패킷 기준으로 적힌 경우가 많습니다. 100바이트 안팎인 게임 패킷은 같은 대역폭에서 패킷 수가 10배 넘게 많아, 회선이 한가해 보여도 초당 패킷 수 한도가 먼저 찹니다.
그래프에서는: 한도에 닿아 평평해짐 · 장비 초당 패킷 수·CPU 사용률, 장비 드롭 수
확인할 곳: 장비의 CPU·초당 패킷 수·드롭 카운터를 보고 장비 앞뒤 스위치 포트의 패킷 수를 같은 간격으로 비교함. 동시 접속 수, 서버 재전송률과 한 화면에 겹쳐 봄
이러면 맞음: 피크·이벤트 때 장비의 초당 패킷 수나 CPU가 한 값에서 더 오르지 못하고, 장비로 들어간 패킷보다 나온 패킷이 적어지며 같은 시각에 그 뒤 서버 전체의 재전송률이 함께 오름
이러면 아님: 장비 앞뒤 패킷 수가 같고 장비 드롭도 없으면 다른 원인. 서버의 NIC 폐기 카운터나 softnet dropped가 늘면 “수신 서버 호스트의 패킷 폐기”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 1건

RFC 2544: Benchmarking Methodology for Network Interconnect Devices IETF
장비 성능은 최소·최대 크기를 포함한 여러 프레임 크기로 시험해야 함(패킷 크기에 따라 처리 성능이 달라짐)

MTU 블랙홀 (큰 패킷만 반복 손실) PMTU black hole

ID rt-mtu · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발

중간 구간이 받을 수 있는 크기가 작아졌는데 “너무 크다”는 알림(ICMP)이 막히면, 큰 패킷은 몇 번을 다시 보내도 계속 사라집니다.

왜 VPN·터널 구간에서 최대 크기가 줄고 크기 초과 알림은 방화벽에 막힘 → 그러면 보내는 쪽은 이유를 모른 채 같은 큰 패킷을 계속 재전송, RTO는 두 배씩 증가 → 화면에서는 평소엔 멀쩡하다가 인벤토리·사람 많은 곳·입장 로딩처럼 큰 데이터가 오가는 순간 뒤따르는 작은 패킷까지 전부 멈춤, 결국 접속 끊김이나 무한 로딩

증상: 멈춤, 접속 끊김, 접속 불가·무한 로딩
요인: 손실
누가 겪나: 특정 지역·통신사, 나만
언제: 특정 행동을 할 때, 접속·점검 직후
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라, 게임개발팀·서버 개발
게임개발팀 할 일: 서버 쪽에서 직접 낮추려면 소켓의 최대 세그먼트 크기(TCP_MAXSEG) 설정, 게임 코드에서 메시지를 잘게 쪼개는 것만으로는 안 막힘(TCP가 보낼 데이터를 MSS 크기로 다시 묶음).
인프라팀 할 일: 네트워크: 경계 장비에서 MSS 조정(clamping), 방화벽·클라우드 네트워크 ACL에서 크기 초과 ICMP(유형 3 코드 4, fragmentation needed) 허용. 서버 장비·OS: 경로 MTU 설정, 서버 방화벽·클라우드 보안 그룹에서도 크기 초과 ICMP가 막히지 않는지 확인, 마지막 안전망으로 리눅스 tcp_mtu_probing=1.
수치 감각: 보통 1,500바이트, 터널을 지나면 1,400 안팎. 같은 패킷이 5~6번 재전송되면 멈춤이 10초를 넘습니다.
그래프에서는: 일부만 높음 · 연결별 RTO·backoff, 지역·통신사별 끊김 수
확인할 곳: 문제 연결의 재전송을 서버 쪽 패킷 캡처나 bcc tcpretrans -s(시퀀스 번호 표시)로 보고, ss -ti로 그 연결의 mss·pmtu·backoff를 봄. 서버에서 그 유저 주소로 작은 ping과 DF를 켠 1,500바이트 ping(ping -M do -s 1472)을 보내 비교함
이러면 맞음: MSS만큼 꽉 찬 패킷이 같은 시퀀스 번호로 간격을 두 배씩 늘리며 계속 재전송되고, 그보다 작은 패킷은 오감. 크기 초과 ICMP(Wireshark 필터 icmp.type == 3 and icmp.code == 4)는 오지 않고, 작은 ping은 응답하는데 큰 DF ping만 응답 없이 사라짐
이러면 아님: 작은 패킷도 함께 사라지면 크기와 상관없는 손실(“병목 대기열 넘침”, “경로 변경·ECMP 불량 경로”). 크기 초과 ICMP가 도착하고 ss -ti의 pmtu가 줄어들면 경로 MTU 탐색이 제대로 동작하는 것
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: tcp_mtu_probing=1은 재전송 타임아웃이 몇 초(tcp_retries1=3에 해당) 이어진 뒤에야 블랙홀로 판단하고 MSS를 1,024바이트로 낮춥니다. 그 사이는 멈춤이므로 마지막 안전망으로 두고 미리 막는 MSS 조정이 먼저입니다.

출처 15건

RFC 1191: Path MTU discovery IETF
경로 MTU 탐색: 너무 큰 패킷은 ICMP “fragmentation needed and DF set”(유형 3 코드 4)로 알림
RFC 2923: TCP Problems with Path MTU Discovery IETF
ICMP가 막혀 큰 패킷만 계속 사라지는 PMTU 블랙홀 문제
RFC 4821: Packetization Layer Path MTU Discovery IETF
ICMP 없이 전송 계층이 패킷 크기를 탐색하는 방법(리눅스 tcp_mtu_probing의 바탕)
IP Sysctl Linux kernel
tcp_mtu_probing: 0 꺼짐, 1 블랙홀이 감지될 때만, 2 항상(시작 MSS는 tcp_base_mss). tcp_retries1 기본 3
net/ipv4/tcp_timer.c Linux kernel
RTO 재전송이 tcp_retries1만큼 이어지면 블랙홀 감지로 보고 MTU 탐색을 켜 MSS를 낮춤
include/net/tcp.h Linux kernel
TCP_BASE_MSS = 1,024바이트
RFC 6298: Computing TCP's Retransmission Timer IETF
재전송 타이머가 만료될 때마다 RTO를 두 배로 늘림
iptables-extensions(8) — Linux manual page netfilter
TCPMSS --clamp-mss-to-pmtu: ICMP를 막는 구간 때문에 큰 패킷이 멈추는 문제를 SYN의 MSS 조정으로 우회
tcp(7) — Linux manual page Linux man-pages
TCP_MAXSEG: 나가는 패킷의 최대 세그먼트 크기, 연결 전에 설정하면 상대에게 알리는 MSS도 바뀜
Network maximum transmission unit (MTU) for your EC2 instance AWS
인터넷 게이트웨이·VPN은 MTU 1,500, PMTUD에는 ICMP 유형 3 코드 4가 필요하고 보안 그룹·네트워크 ACL이 막으면 받지 못함
MTU considerations | Cloud VPN Google Cloud
Cloud VPN 게이트웨이 MTU 1,460바이트, IPv4 터널의 페이로드 MTU 1,406바이트(터널을 지나면 1,400 안팎)
Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
재전송마다 한 줄씩 보여 주고 -s는 재전송한 패킷의 시퀀스 번호를 함께 표시
ss(8) — Linux manual page iproute2
ss -i의 mss, pmtu(경로 MTU), backoff(RTO가 두 배로 늘어난 횟수)
ping(8) — Linux manual page iputils
-M do는 DF를 켜고 커널이 아는 경로 MTU보다 큰 패킷은 보내지 않음, -s는 데이터 크기(ICMP 헤더 8바이트 별도)
Display Filter Reference: Internet Control Message Protocol Wireshark
icmp.type·icmp.code 표시 필터

연결 도중 NAT·로드밸런서 매핑 만료 NAT / load balancer mapping expired mid-connection

ID rt-mapping · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발, 인프라팀·네트워크 인프라, 인프라팀·서버 인프라

유휴 연결의 매핑(이 연결을 어디로 전달할지 기록한 항목)을 중간 장비가 지우면, 다음에 보내는 패킷은 전달되지 못합니다. 재전송만 반복하다 접속이 끊기거나, 장비가 연결 거부(RST)를 돌려보내 곧바로 끊깁니다.

왜 한동안 오가는 패킷이 없는 연결(자리 비움, 로비) → 그러면 공유기 NAT·통신사 CGNAT·방화벽·로드밸런서·클라우드 보안 그룹이 유휴 매핑을 삭제 → 화면에서는 다시 움직이는 순간 재전송이 이어지다 접속 끊김, 또는 바로 접속 끊김

증상: 접속 끊김, 멈춤
요인: 손실
누가 겪나: 나만, 특정 지역·통신사
언제: 가만히 있다가
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발, 인프라팀·네트워크 인프라, 인프라팀·서버 인프라
게임개발팀 할 일: 클라이언트: 가장 짧은 유휴 타임아웃의 절반 이하 간격으로 하트비트 보내기(유저 공유기·통신사 CGNAT의 매핑은 안에서 나가는 패킷으로만 확실히 갱신되고 타임아웃은 우리가 못 바꾸므로 클라이언트가 보냄), 끊기면 자동 재접속. 서버: 하트비트에 응답하고 일정 시간 못 받으면 연결을 먼저 정리(TCP keepalive 간격 줄이기(TCP_KEEPIDLE 등 소켓 옵션), TCP_USER_TIMEOUT으로 빨리 감지), 세션 토큰으로 이어 받기.
인프라팀 할 일: 네트워크: 경로에 있는 방화벽·로드밸런서의 유휴 타임아웃을 모아 게임팀에 공유, 우리 방화벽·로드밸런서는 필요하면 늘리기. 서버 장비·OS: 클라우드 보안 그룹의 연결 추적 시간을 확인해 게임팀에 공유.
수치 감각: TCP 매핑을 유지하는 시간은 장비마다 수 분에서 몇 시간까지 제각각입니다. 클라우드 보안 그룹이 연결을 추적하는 설정이면 AWS Nitro v6 인스턴스 유형은 기본 350초 뒤 추적 항목을 지웁니다(그 밖의 유형은 5일, “클라우드 보안 그룹의 연결 추적 만료” 항목 참고). 리눅스 TCP keepalive는 기본값이 “2시간 유휴 상태면 확인”이라 대부분의 장비보다 늦습니다.
그래프에서는: 연결이 한꺼번에 끊김 · 끊김 수, 끊기기 전 유휴 시간
확인할 곳: 끊긴 연결의 마지막 몇 분을 서버 쪽 패킷 캡처로 보고 살아 있는 연결은 ss -ti의 lastsnd·lastrcv(마지막으로 보내고 받은 뒤 지난 ms)로 유휴 시간을 봄. nstat의 TcpExtTCPAbortOnTimeout(타이머가 다 돼 연결을 포기한 수)도 함께 봄
이러면 맞음: 끊긴 연결마다 직전 유휴 시간이 비슷한 값(경로에 있는 장비의 유휴 타임아웃, 예: AWS Nitro v6 인스턴스 보안 그룹의 350초)을 넘었고 유휴 뒤 첫 패킷부터 ACK 없이 재전송만 이어지다 포기하거나 곧바로 RST가 돌아옴
이러면 아님: 유휴 시간과 상관없이 게임 중에도 끊기면 다른 원인(“경로 변경·ECMP 불량 경로”, “방화벽·연결 추적의 폐기”). 하트비트가 가장 짧은 유휴 타임아웃의 절반 이하 간격으로 오가는 연결이면 이 원인에서 뺌
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 8건

RFC 5382: NAT Behavioral Requirements for TCP IETF
TCP NAT의 연결 유휴 타임아웃은 2시간 4분 이상이어야 한다는 권고(장비가 유휴 세션을 먼저 지울 수 있음을 전제)
RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP IETF
NAT 매핑은 안에서 나가는 패킷으로 갱신되어야 하고(REQ-6), 밖에서 들어오는 패킷의 갱신은 선택 사항(UDP 기준)
Amazon EC2 security group connection tracking AWS
TCP 유휴 추적 타임아웃 기본값은 Nitro v6 인스턴스 유형 350초, 그 밖의 유형 432,000초(5일). 5분보다 짧은 간격의 keepalive 권고
IP Sysctl Linux kernel
tcp_keepalive_time 기본 2시간
tcp(7) — Linux manual page Linux man-pages
TCP_KEEPIDLE(keepalive를 시작하기 전 유휴 시간), TCP_USER_TIMEOUT(확인받지 못한 데이터를 기다리다 연결을 닫는 시간)
RFC 5482: TCP User Timeout Option IETF
TCP 사용자 타임아웃: 보낸 데이터가 확인받지 못한 채 얼마나 지나면 연결을 닫을지
ss(8) — Linux manual page iproute2
ss -i의 lastsnd·lastrcv: 마지막으로 보내고 받은 뒤 지난 시간(ms)
SNMP counter Linux kernel
TcpExtTCPAbortOnTimeout: TCP 타이머가 다 돼 RST 없이 연결을 포기한 수

경로 변경·ECMP 불량 경로 Route change / bad ECMP member

ID rt-path · 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부

인터넷 경로가 바뀌는 몇 초 동안, 또는 여러 ECMP 경로 중 불량인 경로에 배정된 연결에서 패킷이 사라집니다.

왜 BGP 경로 재계산, 또는 여러 경로(ECMP·LAG) 중 한 경로의 장비·회선 불량 → 그러면 경로 전환 중 일시 손실, 또는 그 경로를 타는 연결만 꾸준한 손실 → 화면에서는 갑자기 몇 초 멈춘 뒤 몰아치기, 또는 “재접속하면 나아짐”(다른 경로로 배정)

증상: 멈춤, 몰아치기, 순간이동
요인: 손실
누가 겪나: 특정 지역·통신사
언제: 가끔 무작위로
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 게임개발팀·서버 개발, 외부·외부
게임개발팀 할 일: 연결별 재전송 통계(TCP_INFO)를 남겨 겪는 사람의 IP·포트와 시각을 뽑을 수 있게 하기, 몇 초 멈춘 연결을 바로 끊지 않기.
인프라팀 할 일: 지역·통신사별 재전송률 모니터링, 재접속으로 경로가 바뀌는지 확인, 여러 통신사 회선 확보, 우리 장비의 ECMP·LAG 경로 중 불량 링크 점검, 경로 측정도 게임과 같은 TCP 포트로(mtr --tcp --port. 경로는 주소·포트로 정해지므로 보통 핑은 다른 경로로 가서 멀쩡하게 나오기도 함).
외부 할 일: 통신사에 같은 TCP 포트로 잰 경로 측정 결과와 재접속 전후 비교를 붙여 불량 경로 보고.
그래프에서는: 어느 순간부터 계단처럼 올라감 · RTT(핑), 지역·통신사별 재전송률
확인할 곳: bcc tcpretrans -c로 재전송을 연결별로 모아 겪는 유저의 주소·포트를 뽑고, 서버에서 유저 쪽으로, 유저 쪽에서 서버로 게임과 같은 TCP 포트로 mtr(mtr -T -P PORT)을 떠서 비교함. 재접속 전후 결과도 비교함
이러면 맞음: 어느 시각을 기점으로 한 지역·통신사의 RTT가 계단처럼 바뀌며 몇 초 손실이 몰리거나, 같은 통신사 안에서도 일부 연결(주소·포트 조합)만 꾸준히 재전송하고 재접속하면 나아짐. 일반 ping은 멀쩡한데 TCP mtr에서만 손실이 보이기도 함
이러면 아님: 그 통신사의 모든 연결이 저녁 피크에 함께 나빠지면 “병목 대기열 넘침”. 한 유저만 나쁘고 공유기까지 가는 ping부터 손실이면 “무선 구간 손실”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: Cloudflare 2020: Cloudflare 백본 설정 오류로 일부 도시의 트래픽 손실

출처 5건

RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
다중 경로에서는 ping·traceroute 같은 진단 도구의 결과를 믿기 어렵고, 흐름을 해시해 경로를 고정하는 방식을 설명
RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
ECMP는 흐름을 구분하는 헤더 필드의 해시로 다음 경로를 고름(같은 흐름은 같은 경로)
tcp(7) — Linux manual page Linux man-pages
TCP_INFO: 소켓별 상태(struct tcp_info) 조회
mtr(8) manual page source mtr
-T(--tcp)는 ICMP 대신 TCP SYN으로, -P(--port)는 대상 포트 지정
Demonstrations of tcpretrans, the Linux eBPF/bcc version IO Visor
재전송마다 상대 주소·포트를 한 줄씩 보여 주고 -c는 흐름별 재전송 수를 집계

지연 급등으로 인한 불필요한 재전송 Spurious RTO from delay spikes

ID rt-spurious-delay · 주 담당 외부·외부 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발

패킷은 사라지지 않고 잠깐 아주 늦게 도착했을 뿐인데, 그 지연이 RTO보다 길면 보내는 쪽이 손실로 판단해 재전송합니다.

왜 버퍼블로트, 와이파이 절전, 모바일 무선 상태 전환, 가상 머신 일시 정지로 순간 지연이 수백 ms → 그러면 RTO가 먼저 만료되어 재전송, 원본도 곧 도착(받는 쪽은 중복으로 받음) → 화면에서는 멈춤·몰아치기는 지연 급등 자체 때문. 불필요한 재전송은 멈춤을 거의 늘리지 않고 재전송 지표만 올려 손실로 오해받음

증상: 멈춤, 몰아치기, 입력 지연
요인: 지연, 지터
누가 겪나: 나만, 서버 전체
언제: 가끔 무작위로, 가만히 있다가
담당: 주 담당 외부·외부 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 안드로이드 10 이상 클라이언트는 게임 중 저지연 와이파이 모드(WIFI_MODE_FULL_LOW_LATENCY 와이파이 잠금, 화면이 켜져 있고 게임이 앞에 있을 때만 적용)를 요청해 절전으로 생기는 지연 급등 줄이기.
인프라팀 할 일: 버스트형 인스턴스 피하기, RTO 최소값을 너무 낮추지 않기, F-RTO·타임스탬프 유지(tcp_frto, tcp_timestamps), 재전송 지표는 nstat의 TCPSpuriousRTOs·TCPDSACKRecv와 함께 봐서 손실로 오해하지 않기.
외부 할 일: 지연 급등 자체를 줄이도록 유저에게 공유기 SQM 사용, 와이파이 절전 끄기 안내.
수치 감각: 리눅스는 F-RTO로 불필요한 RTO를 감지하고 전송량 축소를 되돌리기도 합니다. nstat의 TCPSpuriousRTOs(불필요한 RTO로 판정한 횟수)와 TCPDSACKRecv(받는 쪽이 “이미 받은 것”이라고 알려 온 횟수)로 확인합니다.
그래프에서는: 가끔 무작위로 튐 · RTT(핑), 불필요한 RTO 수
확인할 곳: nstat을 1분 간격으로 실행해 TcpExtTCPTimeouts(RTO 만료), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv, TcpExtTCPLostRetransmit의 증가분을 함께 봄. 패킷 캡처가 있으면 Wireshark 필터 tcp.analysis.spurious_retransmission을 씀
이러면 맞음: RTO가 늘 때 TcpExtTCPSpuriousRTOs나 TcpExtTCPDSACKRecv도 함께 늘고, 같은 시각에 RTT가 수백 ms로 튐. 받는 쪽 캡처에 원본과 재전송이 모두 도착해 있음
이러면 아님: TcpExtTCPSpuriousRTOs·DSACK은 그대로인데 TcpExtTCPLostRetransmit(다시 보낸 것까지 또 잃음)이 늘면 실제 손실. RTT는 튀지 않는데 DSACK만 꾸준히 많으면 “순서 뒤바뀜으로 인한 불필요한 빠른 재전송”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 11건

RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP IETF
F-RTO: RTO 뒤에 온 ACK로 불필요한 RTO였는지 가려냄
RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks IETF
모바일망의 지연 급등(핸드오버, 링크 복구 등)이 불필요한 TCP 타임아웃·재전송과 혼잡 윈도우 축소를 일으킴
RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP IETF
DSACK: 받는 쪽이 중복 수신을 알려 보내는 쪽이 불필요한 재전송을 알 수 있음
SNMP counter Linux kernel
TcpExtTCPSpuriousRTOs(F-RTO가 감지한 불필요한 RTO), TcpExtTCPDSACKRecv(받은 DSACK 수), TcpExtTCPLostRetransmit(다시 보낸 패킷을 또 잃었다고 SACK이 알려 온 수)
IP Sysctl Linux kernel
tcp_frto 기본 켜짐(RTT가 흔들리는 무선망에 유리), tcp_timestamps 기본 1
RFC 6298: Computing TCP's Retransmission Timer IETF
불필요한 재전송을 막으려면 큰 최소 RTO가 필요하다는 근거(최소 1초 권고)
WifiManager Android (Google)
WIFI_MODE_FULL_LOW_LATENCY(API 29, 안드로이드 10): AP에 연결되어 있고 화면이 켜져 있고 앱이 앞에 있을 때만 적용되는 저지연 와이파이 잠금
net/ipv4/proc.c Linux kernel
nstat에 나오는 카운터 이름 TCPTimeouts·TCPSpuriousRTOs·TCPDSACKRecv·TCPLostRetransmit
net/ipv4/tcp_timer.c Linux kernel
TCPTimeouts는 재전송 타이머(RTO)가 만료될 때 증가
nstat(8) — Linux manual page iproute2
nstat은 기본으로 이전 실행 이후의 증가분을 보여 줌
Display Filter Reference: Transmission Control Protocol Wireshark
tcp.analysis.spurious_retransmission 표시 필터

순서 뒤바뀜으로 인한 불필요한 빠른 재전송 Reordering triggers spurious fast retransmit

ID rt-reorder · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라

여러 경로나 묶인 링크를 지나며 패킷 순서가 바뀌면, 받는 쪽이 중복 ACK로 “빠진 패킷 있음”을 알리고 보내는 쪽은 멀쩡한 패킷을 다시 보냅니다.

왜 패킷 단위로 경로를 나누는 장비, 패킷 단위로 나눠 싣는 LAG(링크 묶음), 경로가 바뀌는 순간이 순서를 뒤섞음 → 그러면 뒤 패킷이 먼저 도착해 중복 ACK 3개가 쌓임 → 빠른 재전송 → 화면에서는 드문드문 오가는 게임 패킷은 거의 영향 없음. 사람 많은 곳의 큰 업데이트와 패치 다운로드가 느려지고 가끔 뚝뚝 끊김

증상: 뚝뚝 끊김, 입력 지연
요인: 지터
누가 겪나: 특정 지역·통신사, 서버 전체
언제: 항상, 사람이 몰릴 때
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라
인프라팀 할 일: 네트워크: 패킷 단위 분산 대신 연결 단위 분산(ECMP·LAG를 주소·포트 해시로). 서버 장비·OS: RACK(시간 기준 손실 판단, 순서 뒤바뀜에 강함. DSACK으로 불필요한 재전송을 감지하면 순서 뒤바뀜 허용 폭을 자동으로 늘림) 사용, 리눅스가 연결마다 자동으로 추정한 순서 뒤바뀜 정도 확인(ss -ti의 reordering 값, 시작값은 tcp_reordering=3).
그래프에서는: 처음부터 늘 높음 · 순서 뒤바뀜 감지 수, DSACK 수신 수
확인할 곳: nstat의 TcpExtTCPSACKReorder·TcpExtTCPTSReorder(순서 뒤바뀜을 감지한 횟수)와 TcpExtTCPDSACKRecv를 보고, 연결별로는 ss -ti의 reordering(3이 아니면 표시)·reord_seen을 봄. 패킷 캡처에서는 Wireshark 필터 tcp.analysis.out_of_order를 씀
이러면 맞음: 순서 뒤바뀜 카운터와 DSACK이 시간대와 상관없이 꾸준히 오르고 특정 경로·장비를 지나는 연결의 reordering 값이 3보다 커져 있음. 받는 쪽 캡처에서 뒤 패킷이 먼저 오고 앞 패킷도 곧 도착함
이러면 아님: 순서 뒤바뀜 카운터는 그대로이고 TcpExtTCPLostRetransmit이 늘면 실제 손실. RTT가 튀는 순간에만 DSACK이 늘면 “지연 급등으로 인한 불필요한 재전송”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 9건

RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection IETF
패킷 단위로 경로를 나누면 순서가 바뀌고 뒤 패킷 3개 이상이 먼저 오면 TCP가 불필요한 빠른 재전송을 함
RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm IETF
흐름을 구분하는 헤더 필드의 해시로 경로를 고르는 ECMP(흐름 단위 분산)
RFC 5681: TCP Congestion Control IETF
세 번째 중복 ACK에서 빠른 재전송
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK은 시간 기준으로 손실을 판단해 순서 뒤바뀜에 강하고 DSACK을 받으면 순서 뒤바뀜 허용 시간(reo_wnd)을 늘림
IP Sysctl Linux kernel
tcp_reordering 시작값 3(연결마다 tcp_max_reordering까지 자동 조정), tcp_recovery의 RACK 설정
misc/ss.c iproute2
ss -ti는 연결의 reordering 값이 기본값 3과 다를 때 reordering:값을, 순서 뒤바뀜을 겪은 적이 있으면 reord_seen:횟수를 표시
SNMP counter Linux kernel
TcpExtTCPSACKReorder·TcpExtTCPTSReorder(순서 뒤바뀜 감지), TcpExtTCPDSACKRecv(받은 DSACK 수), TcpExtTCPLostRetransmit(다시 보낸 패킷을 또 잃음)
include/uapi/linux/tcp.h Linux kernel
tcp_info의 tcpi_reord_seen: 연결이 겪은 순서 뒤바뀜 횟수
Display Filter Reference: Transmission Control Protocol Wireshark
tcp.analysis.out_of_order 표시 필터

ACK가 늦거나 사라짐 (업로드 포화) ACK path congestion on asymmetric links

ID rt-ack-path · 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발

데이터는 잘 도착했는데 “받았다”는 ACK가 꽉 찬 업로드 대기열에서 늦어지거나 사라지면, 보내는 쪽이 손실로 판단해 재전송합니다.

왜 집에서 영상 업로드·클라우드 백업으로 업로드가 꽉 참 → 그러면 ACK가 공유기 대기열에서 수백 ms 늦어지거나 넘쳐서 버려짐 → 화면에서는 서버가 보내는 게임 패킷은 대체로 제때 옴. 같은 업로드 대기열에 쌓인 내 입력이 늦어 입력 지연·고무줄, 가끔 불필요한 재전송

증상: 입력 지연, 고무줄
요인: 지연, 손실
누가 겪나: 같은 집
언제: 가끔 무작위로, 저녁 피크 시간
담당: 주 담당 외부·외부 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 핑이 급등하면 화면에 네트워크 상태 표시, “업로드 중인 프로그램 확인” 안내 띄우기.
외부 할 일: 유저에게 공유기 SQM으로 업로드 대기열 짧게, 작은 패킷(ACK) 우선 처리, 업로드 속도 제한(영상 업로드·클라우드 백업) 안내.
수치 감각: ACK는 뒤의 ACK가 앞의 것을 대신 확인해 주므로 몇 개 사라지는 것은 대개 괜찮습니다. 렉을 만드는 것은 대기열에서 늦어지는 ACK입니다.
그래프에서는: 일부만 높음 · 연결별 RTT(핑)
확인할 곳: 유저 PC에서 업로드(영상 업로드·클라우드 백업)를 켠 상태와 끈 상태로 게임 서버 ping을 비교함. 서버에서는 ss -ti로 그 유저 연결의 rtt를 봄
이러면 맞음: 업로드 중에만 ping이 수백 ms로 오르고 입력 지연·고무줄이 생기며 업로드를 멈추면 곧 돌아옴. 서버에서 보면 그때 그 연결의 rtt도 함께 오름
이러면 아님: 업로드와 상관없이 손실과 지연이 생기면 “무선 구간 손실”이나 경로 쪽 원인. 서버에서 유저로 가는 방향만 늦고 업로드와 상관없으면 “병목 대기열 넘침”
확인 수단: 유저 쪽 환경에서 확인

출처 4건

RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF
업로드가 좁은 비대칭 회선에서 ACK가 늦거나 사라지면 TCP 성능이 떨어짐, ACK는 누적 확인이라 일부가 사라져도 뒤 ACK가 대신함, ACK 우선 스케줄링 같은 대책
Smart Queue Management Bufferbloat.net
공유기에서 대기열 관리와 셰이핑으로 대기열을 짧게 유지
tc-cake(8) — Linux manual page iproute2
CAKE는 흐름을 나눠 드문드문 보내는 흐름(sparse flow)의 지연을 최소화
ss(8) — Linux manual page iproute2
ss -i의 rtt(평균 왕복 시간)와 rttvar(편차)

RTO 설정이 환경과 맞지 않음 RTO min too low or too high

ID rt-rto-setting · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발

RTO 최소값을 너무 낮추면 조금만 늦어도 불필요한 재전송이 나고 기본값(200ms)은 게임 입장에서 너무 길어 한 번 잃을 때마다 오래 멈춥니다.

왜 데이터센터용으로 RTO 최소값을 크게 낮춤, 또는 인터넷 구간에 기본값 그대로 사용 → 그러면 낮으면 순간 지연에도 재전송 폭주, 높으면 손실마다 긴 대기 → 화면에서는 기본값이면 손실 한 번에 수백 ms 멈춤 뒤 몰아치기, 너무 낮추면 멈춤은 줄지만 불필요한 재전송이 급증해 회선을 낭비

증상: 멈춤, 몰아치기, 입력 지연
요인: 지연
누가 겪나: 서버 전체
언제: 항상
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발
게임개발팀 할 일: 리눅스 6.15 이상이면 게임 연결에 TCP_RTO_MAX_MS로 RTO 상한 낮추기 검토(포기까지 걸리는 시간도 짧아지므로 TCP_USER_TIMEOUT으로 끊김 판정 시간을 함께 정하기), 서버 간 내부 연결만 소켓 옵션 TCP_RTO_MIN_US(6.15 이상)로 RTO 최소값 낮추기, 소켓 옵션 TCP_THIN_LINEAR_TIMEOUTS로 게임 연결만 연속 RTO가 두 배로 늘지 않게 하기 검토.
인프라팀 할 일: 서버 간 내부 연결만 경로별로 rto_min 낮추기, 인터넷 구간은 기본값 유지하되 RACK-TLP·thin stream 설정(tcp_thin_linear_timeouts)으로 보완.
수치 감각: 리눅스 RTO = 왕복 시간 + max(200ms, RTT 편차×4). 실패할 때마다 두 배, 최대 120초. 리눅스 6.15 이상은 TCP_RTO_MAX_MS로 이 상한을 1초까지 낮출 수 있습니다.
그래프에서는: 처음부터 늘 높음 · 연결별 RTO, 불필요한 RTO 수
확인할 곳: 서버의 RTO 최소값 설정(ip route show의 rto_min, 리눅스 6.11 이상은 sysctl net.ipv4.tcp_rto_min_us)과 ss -ti의 rto·rtt를 보고, nstat의 TcpExtTCPSpuriousRTOs 증가분을 봄
이러면 맞음: 최소값을 낮춘 서버에서 인터넷 연결의 rto가 rtt에 바짝 붙어 있고 TcpExtTCPSpuriousRTOs가 많이 늘어남. 기본값 그대로면 게임 연결의 rto가 rtt보다 200ms 이상 크고 손실 한 번마다 그만큼 멈춤
이러면 아님: rto가 기본 계산대로(rtt + 200ms 안팎)이고 불필요한 RTO도 적은데 멈춤이 유난히 길면 연속 손실이나 복구 방식 쪽(“thin stream의 느린 복구”, “중간 장비의 TCP 옵션 제거”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 12건

RFC 6298: Computing TCP's Retransmission Timer IETF
RTO = SRTT + max(G, 4·RTTVAR), 최소 1초 권고, 실패할 때마다 두 배, 최대값을 두려면 60초 이상
include/net/tcp.h Linux kernel
리눅스 TCP_RTO_MIN 200ms, TCP_RTO_MAX 120초
net/ipv4/tcp_input.c Linux kernel
리눅스 RTO는 SRTT + rttvar이고 rttvar는 RTO 최소값(기본 200ms) 아래로 내려가지 않음
tcp: add the ability to control max RTO Linux kernel
TCP_RTO_MAX_MS 소켓 옵션 추가(1~120초), 리눅스 6.15부터
tcp: add sysctl_tcp_rto_min_us Linux kernel
서버 전체 기본 RTO 최소값 tcp_rto_min_us 추가, 리눅스 6.11부터
tcp: support TCP_RTO_MIN_US for set/getsockopt use Linux kernel
소켓마다 RTO 최소값을 정하는 TCP_RTO_MIN_US 소켓 옵션 추가, 리눅스 6.15부터
IP Sysctl Linux kernel
tcp_rto_min_us 기본 200000(경로 옵션 rto_min, 소켓 옵션 TCP_RTO_MIN_US가 우선), tcp_rto_max_ms 1,000~120,000(기본 120,000), tcp_thin_linear_timeouts
ip-route(8) — Linux manual page iproute2
경로별 rto_min 옵션: 그 목적지와 통신할 때의 RTO 최소값
Thin-streams and TCP Linux kernel
TCP_THIN_LINEAR_TIMEOUTS로 thin stream 연결만 지수 백오프를 끌 수 있음
tcp(7) — Linux manual page Linux man-pages
TCP_USER_TIMEOUT: 확인받지 못한 데이터를 기다리다 연결을 닫기까지의 시간
ss(8) — Linux manual page iproute2
ss -i의 rto(ms)와 rtt
SNMP counter Linux kernel
TcpExtTCPSpuriousRTOs: F-RTO가 감지한 불필요한 RTO

thin stream의 느린 복구 Thin streams fall back to RTO

ID rt-thin · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발

게임처럼 작은 패킷을 드문드문 보내면 “뒤따르는 패킷 3개”가 모이기 전에 RTO가 먼저 옵니다. 대용량 전송보다 같은 손실에 훨씬 오래 멈춥니다.

왜 패킷 간격이 100ms 안팎이라 아직 ACK를 받지 못한(in-flight) 패킷이 몇 개 없음 → 그러면 중복 ACK 3개가 모이려면 300ms 넘게 걸려 RTO(핑 + 200ms)가 먼저 발동, 연속 손실이면 두 배씩 → 화면에서는 손실 한 번에 0.3초 안팎 멈춤, 다시 보낸 것까지 잃으면 1초 가까이 멈춘 뒤 몰아치기

증상: 멈춤, 몰아치기
요인: 손실, 정체
누가 겪나: 나만, 서버 전체
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: TCP_NODELAY 켜기(Nagle이 켜져 있으면 RACK이 판단에 쓸 뒤따르는 패킷이 없음), 실시간 패킷은 UDP 위의 자체 재전송으로. 클라이언트: TCP_NODELAY 켜기, 실시간 패킷은 서버와 같은 방식(UDP)으로.
인프라팀 할 일: RACK-TLP 사용(최신 리눅스 기본), tcp_thin_linear_timeouts로 연속 RTO가 두 배로 늘지 않게.
수치 감각: 패킷 간격 100ms, 핑 60ms면 빠른 재전송까지 약 360ms(뒤 패킷 3개가 도착하고 그 확인이 돌아올 때까지), RTO는 약 260ms. RACK을 쓰면 다음 패킷의 확인이 돌아오는 약 160ms에 바로 다시 보냅니다. 패킷 간격이 200ms를 넘으면 RACK도 RTO보다 빠르지 않습니다.
그래프에서는: 끊겼다가 몰아서 · 연결별 수신량, RTO 만료 수
확인할 곳: nstat의 TcpExtTCPTimeouts(RTO 만료)·TcpExtTCPFastRetrans(빠른 재전송)·TcpExtTCPLossProbes·TcpExtTCPLossProbeRecovery(TLP) 증가분을 비교하고, 게임 연결을 ss -ti로 보아 rto·backoff를 봄. 서버의 net.ipv4.tcp_recovery·tcp_early_retrans·tcp_sack 값도 확인함
이러면 맞음: 재전송 가운데 RTO 만료가 빠른 재전송보다 많고 게임 연결에서 backoff가 0보다 큰 경우(RTO를 겪는 중)가 자주 보임. 멈춘 동안 받은 양이 0이다가 복구되면 한꺼번에 몰려옴
이러면 아님: 같은 서버의 대용량 전송도 똑같이 오래 멈추면 연결 모양과 상관없는 손실 문제. SACK·타임스탬프가 빠진 연결에 몰리면 “중간 장비의 TCP 옵션 제거”
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 리눅스에는 예전에 thin stream용 중복 ACK 1개 재전송 옵션(tcp_thin_dupack)도 있었지만 2017년에 없어졌고, 지금은 RACK이 그 역할을 대신합니다. Nagle이 켜져 있으면(TCP_NODELAY 꺼짐) 잃은 패킷의 확인을 기다리는 동안 새 패킷도 보내지 않습니다. RACK이 판단에 쓸 뒤따르는 패킷이 없으니 RTO까지 기다립니다.

출처 11건

Thin-streams and TCP Linux kernel
게임처럼 드문드문 보내는 thin stream은 빠른 재전송이 잘 작동하지 않아 긴 타임아웃에 기댐, 아직 ACK를 받지 못한 패킷(in-flight) 4개 미만이 기준
RFC 5681: TCP Congestion Control IETF
세 번째 중복 ACK에서 빠른 재전송
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK은 뒤에 보낸 패킷이 전달된 것으로 손실을 판단, TLP 대기는 2·SRTT(확인받지 못한 패킷이 하나뿐이면 지연 ACK 여유를 더함)
include/net/tcp.h Linux kernel
TCP_RTO_MIN 200ms, thin stream 판정(in-flight 패킷 4개 미만)과 선형 재시도 6번
tcp: remove thin_dupack feature Linux kernel
2017년 1월 thin_dupack 삭제(리눅스 4.11), RACK이 그 역할을 대신한다는 설명
IP Sysctl Linux kernel
tcp_thin_linear_timeouts: thin stream이면 최대 6번까지 RTO를 두 배로 늘리지 않음(기본 꺼짐)
tcp(7) — Linux manual page Linux man-pages
TCP_NODELAY는 Nagle 알고리즘을 끔
net/ipv4/proc.c Linux kernel
nstat에 나오는 카운터 이름 TCPTimeouts·TCPFastRetrans·TCPLossProbes·TCPLossProbeRecovery
net/ipv4/tcp_timer.c Linux kernel
TCPTimeouts는 재전송 타이머(RTO)가 만료될 때 증가
SNMP counter Linux kernel
TcpExtTCPFastRetrans(Loss 상태가 아닐 때의 재전송), TcpExtTCPLossProbes(TLP를 보냄)·TcpExtTCPLossProbeRecovery(TLP로 손실을 복구)
ss(8) — Linux manual page iproute2
ss -i의 rto(ms), backoff(RTO가 두 배로 늘어난 횟수)

중간 장비의 TCP 옵션 제거 Middlebox strips TCP options

ID rt-sack-stripped · 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라

일부 방화벽·가속 장비가 TCP 옵션을 지우거나 고치면, 여러 개를 잃었을 때 한 왕복에 하나씩만 복구하거나 윈도우(한 번에 보낼 수 있는 양)가 작아져 느려집니다.

왜 방화벽의 “TCP 정규화”, 오래된 가속 장비가 SACK·타임스탬프·윈도우 스케일 옵션을 제거 → 그러면 잃은 패킷이 여러 개면 왕복마다 하나씩 복구, 윈도우가 64KB로 제한됨 → 화면에서는 손실마다 멈춤이 훨씬 길어지고(SACK이 없으면 RACK-TLP도 못 씀) 풀리면 몰아치기. 패치 같은 대용량 전송도 느림

증상: 멈춤, 몰아치기
요인: 정체, 지연
누가 겪나: 특정 지역·통신사, 서버 전체
언제: 항상
담당: 주 담당 인프라팀·네트워크 인프라 · 함께 인프라팀·서버 인프라
인프라팀 할 일: 네트워크: 해당 장비의 TCP 정규화 설정 끄기, 방화벽의 시퀀스 번호 무작위화도 확인, 양쪽 끝 패킷 캡처로 SYN의 옵션 비교. 서버 장비·OS: ss -ti에서 sack·wscale 표시가 빠진 연결이 특정 경로에 몰리는지 확인(ts는 윈도우 PC가 설정에 따라 쓰지 않으므로 ts만 빠진 것은 정상일 수 있음), 서버의 net.ipv4.tcp_sack이 1인지 확인.
그래프에서는: 처음부터 늘 높음 · SACK 없이 시작한 복구 수(TcpExtTCPRenoRecovery)
확인할 곳: ss -ti에서 연결마다 sack·wscale 표시가 있는지 보고 nstat의 TcpExtTCPRenoRecovery(SACK 없이 시작한 복구)와 TcpExtTCPSackRecovery의 비율, TcpExtTCPSACKDiscard(앞뒤가 맞지 않아 버린 SACK 블록 수)를 봄. 의심 경로는 양쪽 끝에서 SYN을 캡처해 옵션(Wireshark의 tcp.options.sack_perm 등)을 비교함
이러면 맞음: 특정 경로·장비를 지나는 연결만 sack·wscale이 빠져 있고 TcpExtTCPRenoRecovery 비중이 높음. 보낸 쪽 SYN에 있던 SACK 허용 옵션이 받은 쪽 SYN에는 없음. 시퀀스 번호 무작위화가 원인이면 옵션은 남아 있는데 TcpExtTCPSACKDiscard가 늘어남
이러면 아님: 모든 연결에서 sack이 빠져 있으면 서버의 net.ipv4.tcp_sack 값부터 확인. 옵션이 온전하고 TcpExtTCPSACKDiscard도 그대로면 복구가 느린 이유는 다른 곳(“thin stream의 느린 복구”)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 옵션이 남아 있어도 SACK이 망가질 수 있습니다. 방화벽의 시퀀스 번호 무작위화(sequence randomization)가 헤더의 시퀀스 번호만 바꾸고 SACK 안의 번호는 그대로 두면, 보내는 쪽은 앞뒤가 맞지 않는 SACK을 버립니다. 2019년 SACK 보안 문제 때 서버에서 tcp_sack=0으로 꺼 두고 잊은 경우도 결과가 같습니다.

출처 10건

RFC 2018: TCP Selective Acknowledgment Options IETF
SACK 없이 누적 ACK만으로는 왕복마다 잃은 패킷 하나만 알 수 있음
RFC 7323: TCP Extensions for High Performance IETF
윈도우 스케일 옵션이 없으면 윈도우는 최대 2^16 = 64KiB
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP IETF
RACK-TLP는 SACK 사용이 필수
net/ipv4/tcp_output.c Linux kernel
리눅스 TLP는 SACK을 쓰는 연결에서만 예약됨
IP Sysctl Linux kernel
tcp_sack 기본 1(켜짐)
misc/ss.c iproute2
ss -ti는 연결이 쓰는 옵션에 따라 ts, sack, wscale:송신,수신을 표시
tcp: limit payload size of sacked skbs Linux kernel
2019년 SACK 처리 취약점(CVE-2019-11477) 수정 커밋
Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service vulnerabilities (NFLX-2019-001) Netflix
당시 임시 대책으로 tcp_sack=0(SACK 처리 끄기)이 안내됨
SNMP counter Linux kernel
TcpExtTCPRenoRecovery(SACK 없이 복구 시작)·TcpExtTCPSackRecovery(SACK으로 복구 시작), TcpExtTCPSACKDiscard(유효하지 않은 SACK 블록 수)
Display Filter Reference: Transmission Control Protocol Wireshark
tcp.options.sack_perm(SYN의 SACK 허용 옵션) 표시 필터

제로 윈도우 (재전송처럼 보이는 멈춤) Zero window, often mistaken for retransmission

ID rt-zero-window · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발, 인프라팀·서버 인프라

받는 쪽 프로그램이 소켓을 제때 읽지 않아 버퍼가 가득 차면, 보내는 쪽은 전송을 멈추고 제로 윈도우 프로브만 보냅니다. 회선 문제가 아닙니다.

왜 클라이언트 프레임 멈춤, 서버 스레드 막힘으로 소켓을 못 읽음 → 그러면 수신 윈도우가 0이 되어 보내는 쪽이 전송을 멈추고 프로브만 보냄(간격이 점점 늘어남) → 화면에서는 멈춤 뒤 몰아치기. 패킷 캡처에 “ZeroWindow”가 보이고 손실은 없음

증상: 멈춤, 몰아치기
요인: 정체
누가 겪나: 나만, 서버 전체
언제: 사람이 몰릴 때, 가끔 무작위로
담당: 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발, 인프라팀·서버 인프라
게임개발팀 할 일: 패킷 캡처에서 ZeroWindow를 보낸 쪽(소켓을 못 읽는 쪽)부터 확인, 네트워크 수신은 별도 스레드에서 계속 읽기, 수신 버퍼 적정 크기. 클라이언트: 로딩·GC 같은 프레임 멈춤 원인 해결. 서버: 소켓을 읽는 스레드가 막히는 원인 해결.
인프라팀 할 일: 서버의 nstat TcpExtTCPToZeroWindowAdv(서버가 수신 윈도우를 0으로 알린 횟수)를 모니터링에 추가(늘면 서버 쪽이므로 서버 개발에 전달), 서버 쪽 패킷 캡처 제공.
그래프에서는: 끊겼다가 몰아서 · 연결별 수신량, 제로 윈도우 횟수
확인할 곳: 패킷 캡처에서 Wireshark 필터 tcp.analysis.zero_window로 윈도우 0을 알린 쪽을 찾음. 서버의 nstat에서는 TcpExtTCPToZeroWindowAdv(서버가 윈도우 0을 알림)와 TcpExtTCPWinProbe(상대의 윈도우 0에 프로브를 보냄)를 나눠 보고, 서버 소켓의 Recv-Q(ss에서 프로그램이 아직 읽지 않은 바이트)를 봄
이러면 맞음: 멈춘 동안 재전송은 없고 제로 윈도우와 프로브만 오감. 서버의 TcpExtTCPToZeroWindowAdv나 서버 소켓의 Recv-Q가 늘면 서버가 제때 읽지 못하는 것, TcpExtTCPWinProbe가 늘면 클라이언트가 제때 읽지 못하는 것
이러면 아님: 캡처에 제로 윈도우가 없고 같은 데이터가 다시 보내지면 손실이나 불필요한 재전송 쪽 원인
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
실제 사례: Roblox 2021: Roblox 73시간 장애: 서비스 디스커버리(Consul) 클러스터의 경합

출처 7건

RFC 9293: Transmission Control Protocol (TCP) IETF
수신 윈도우가 0이면 보내는 쪽은 제로 윈도우 프로브를 보내고 프로브 간격은 지수적으로 늘림
7.5. TCP Analysis Wireshark
TCP ZeroWindow: 받는 쪽이 윈도우 0을 알려 보내는 쪽에 전송을 멈추게 한 패킷
Display Filter Reference: Transmission Control Protocol Wireshark
tcp.analysis.zero_window, tcp.analysis.zero_window_probe 표시 필터
SNMP counter Linux kernel
TcpExtTCPToZeroWindowAdv: 수신 윈도우를 0이 아닌 값에서 0으로 알린 횟수
net/ipv4/proc.c Linux kernel
nstat에 나오는 카운터 이름 TCPToZeroWindowAdv·TCPWinProbe
net/ipv4/tcp_output.c Linux kernel
TCPWinProbe: 상대 수신 윈도우가 0일 때 보내는 프로브(tcp_send_probe0)마다 증가
net/ipv4/tcp_diag.c Linux kernel
ss의 Recv-Q는 연결이면 받았지만 프로그램이 아직 읽지 않은 바이트 수

접속 요청(SYN) 재전송 SYN retransmission on connect

ID rt-syn · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·네트워크 인프라, 게임개발팀·클라이언트 개발

접속 요청이 접속 대기열(backlog) 넘침이나 방화벽 차단으로 사라지면, 클라이언트 OS가 1초 뒤부터 간격을 늘려 가며 다시 보냅니다.

왜 점검 직후 접속 폭주로 서버 접속 대기열이 넘치거나, 방화벽·DDoS 방어가 SYN을 버림 → 그러면 클라이언트 OS가 1초 뒤부터 정해진 간격으로 SYN 재전송(예전 리눅스는 1초 → 2초 → 4초) → 화면에서는 접속 버튼 뒤 1초, 3초처럼 초 단위로 딱 떨어지게 늦고 계속 실패하면 접속 불가·무한 로딩

증상: 접속 불가·무한 로딩
요인: 손실
누가 겪나: 서버 전체, 특정 지역·통신사
언제: 접속·점검 직후
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·네트워크 인프라, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: listen의 backlog 인자 늘리기(somaxconn과 함께), 게임 서버가 accept를 제때 부르게 하기, 로그인 대기열 시스템. 클라이언트: 접속 재시도 간격 늘리기(무작위로 분산).
인프라팀 할 일: 서버 장비·OS: 서버 접속 대기열 넘침은 nstat의 TcpExtListenOverflows·TcpExtListenDrops와 로그의 “Possible SYN flooding” 경고로 확인, somaxconn 늘리기(listen 인자와 함께), SYN 쿠키. 네트워크: 방화벽·DDoS 방어의 SYN 제한 완화.
수치 감각: 리눅스(안드로이드 포함) 첫 SYN 재전송은 1초 뒤입니다. 예전 커널은 이후 간격을 두 배씩 늘려 1, 3, 7, 15초 …에 다시 보냅니다. 6.5 이상은 1, 2, 3, 4, 5초에 다섯 번 다시 보낸 뒤 두 배씩(7, 11, 19초 …) 늘립니다(tcp_syn_linear_timeouts=4). 안드로이드 폰은 OS를 업데이트해도 출시 때의 커널을 계속 쓰는 경우가 많아, 같은 안드로이드 버전이라도 기기마다 다를 수 있습니다. 어느 쪽이든 모두 실패하면 약 2분 뒤 포기합니다. 윈도우는 버전과 설정에 따라 1초 또는 3초부터 늘어나고 다시 보내는 횟수가 2~4번이라 20~30초 만에 포기합니다(그 PC의 값은 netsh int tcp show global의 Max SYN Retransmissions로 확인).
그래프에서는: 접속·점검 직후 폭증 · 접속 시도 수, 접속 대기열 넘침 수
확인할 곳: 서버의 nstat에서 TcpExtListenOverflows·TcpExtListenDrops와 dmesg의 “Possible SYN flooding on port” 경고를 보고 ss -lnt로 접속 대기 소켓의 Recv-Q(accept를 기다리는 연결 수)가 Send-Q(backlog 한도)에 닿는지 봄. 서버 쪽 캡처로 SYN이 도착하는지, SYN-ACK를 돌려보내는지 확인함
이러면 맞음: 점검 직후 접속 폭주 때 TcpExtListenOverflows가 늘고 Recv-Q가 Send-Q에 붙어 있음. 캡처에서 같은 클라이언트의 SYN이 초 단위 간격으로 다시 오는데 서버가 응답하지 않음
이러면 아님: SYN이 서버까지 오지 않고 서버 카운터도 그대로면 앞단 방화벽·DDoS 방어가 버린 것이니 그 장비의 SYN 제한·드롭 로그를 봄. 서버가 SYN-ACK를 보냈는데도 접속이 늦으면 돌아가는 방향의 손실
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처 11건

include/net/tcp.h Linux kernel
첫 RTO TCP_TIMEOUT_INIT = 1초(RFC 6298의 초기값)
RFC 6298: Computing TCP's Retransmission Timer IETF
초기 RTO 1초, 재전송 때마다 두 배
IP Sysctl Linux kernel
tcp_syn_retries 기본 6, tcp_syn_linear_timeouts 기본 4(SYN RTO 1, 1, 1, 1, 1, 2, 4 …), 마지막 재전송 67초·포기 131초, somaxconn 기본 4096, tcp_syncookies 기본 1
tcp: make the first N SYN RTO backoffs linear Linux kernel
SYN 재전송 앞부분을 일정 간격으로 바꾼 커밋, 리눅스 6.5부터(기본 4는 macOS·iOS 방식을 따름)
Android common kernels Android (Google)
5.10~6.18 공통 커널이 함께 지원되고 이전 플랫폼용 커널(예: android14-6.1)을 새 안드로이드 기기의 출시나 업그레이드에 쓸 수 있음
TcpMaxConnectRetransmissions Microsoft
예전 윈도우 기본값: SYN 재전송 2번, 첫 대기 3초에서 두 배씩, 마지막 뒤 두 배를 더 기다리고 포기(3+6+12=21초)
TCP/IP connectivity issues troubleshooting Microsoft
SYN 재전송 횟수는 OS마다 다르며 netsh int tcp show global의 Max SYN Retransmissions로 확인
listen(2) — Linux manual page Linux man-pages
listen의 backlog 인자는 somaxconn으로 잘림(리눅스 5.4부터 기본 4096, 이전 128)
SNMP counter Linux kernel
accept 대기열이 차면 SYN을 버리고 TcpExtListenOverflows·TcpExtListenDrops가 함께 늘어남, TcpExtTCPSynRetrans
net/ipv4/tcp_input.c Linux kernel
“Possible SYN flooding on port …” 로그 메시지
net/ipv4/tcp_diag.c Linux kernel
접속 대기 소켓이면 ss의 Recv-Q는 accept를 기다리는 연결 수, Send-Q는 backlog 한도

상황별 절차

패치 이후 렉

특정 패치·배포 뒤부터 렉 제보가 늘었을 때. “이번 업데이트부터 이상하다”는 제보가 모이거나, 그래프가 어느 시각부터 계단처럼 올라가 그대로 머무는 경우에 쓴다.

해외 국가·지역 추가

서비스 국가를 새로 열거나 새 리전·데이터센터를 추가할 때. 오픈 전 점검과, “국내는 괜찮은데 새 국가 유저만 렉”이라는 제보를 가를 때 함께 쓴다.

실제 장애 사례

게임사와 인프라 회사가 스스로 공개한 사후 분석만 골랐습니다.

CCP Games 2014: EVE Online HED-GP 대규모 함대전의 서버 과부하

무슨 일: 2014년 1월 회고가 다룬 HED-GP 성계의 대규모 함대전에서 서버가 크게 과부하됐다. Time Dilation(과부하 때 게임 시간을 늦추는 기능)이 하한인 10%에 닿아 전장 전체가 슬로우모션이 된 뒤에도 부하가 계속 쌓였고, 모듈의 정지·반복 작동을 처리하는 작업이 밀린 정도(Dogma Lateness)가 최대 게임 시간 193초, 실제 시간으로 약 32분에 이르렀다. 규모가 거의 같았던 2013년 7월 6VDT 전투는 최대 42초(실제 약 7분)였다.
원인: CCP는 성능 분석 도구가 그 자체로 부하를 더해 이런 상황에서는 돌리지 않으므로 확실하지 않다고 전제하고, 두 가지를 유력한 원인으로 꼽았다. 하나는 전투가 길어지며 처리하지 못하고 계속 쌓인 부하다. 다른 하나는 드론 사용 증가로, 전투 동안 배치된 드론 수(중복 제외)는 6VDT 21,123개, HED-GP 38,852개로 84% 많았다. 한 명의 행동을 보는 모두에게 알려야 하는 전송은 인원의 제곱(O(n²))으로 늘어나는데, 드론은 공격 한 번에 메시지가 더 많다. 드론이 공격 대상을 고르는 코드도 같은 전장의 공격 가능한 대상을 자주 전부 살펴서, 비용이 n²에 가깝게 늘어난다.
배울 점: 인원이 몰린 한 지역의 처리량이 한계를 넘으면 그 지역 전체가 슬로우모션이 되고, 전투가 길수록 밀린 처리가 쌓여 입력 지연이 커진다. 확인 신호는 그 지역을 맡은 서버(노드)의 틱 시간·밀린 작업량과 인원·개체 수이고, 다른 지역은 멀쩡한 것이 특징이다. 주 담당은 게임개발팀(서버)이며 한 행동을 알릴 대상의 범위와 AI의 대상 탐색 비용이 고칠 곳이다. 게임 시간을 늦추는 설계는 과부하를 없애지는 못하지만 모두가 같은 속도로 느려지게 해서 일부 행동만 한없이 밀리는 일을 막는다.
관련 원인: 브로드캐스트 폭증, 틱 예산 초과, 메시지 큐 적체, 단일 스레드 지역 과부하(핫스팟)
원문: CCP Games

Riot Games 2015: 멀리 돌아가던 League of Legends 트래픽과 Riot Direct

무슨 일: Riot Games가 인터넷이 실시간 게임에 맞지 않는 이유를 설명한 기술 글이다. League of Legends 유저가 제보한 실제 트래픽은 샌프란시스코에서 포틀랜드로 가면서 로스앤젤레스, 덴버, 시애틀을 거쳐 갔다. 곧장 가면 14ms면 될 것이 70ms 걸렸다. Riot은 라우터가 넘쳐 패킷이 버려지면 다른 챔피언이 화면에서 튀어 다니고 투사체가 순간이동하는 것처럼 보인다고 설명했다.
원인: Riot은 경로와 라우터를 원인으로 들었다. 백본 사업자와 통신사는 지연이 가장 짧은 경로보다 비용이 가장 싼 경로로 트래픽을 보내고, BGP로 정해진 경로가 멀리 돌아가면 거치는 라우터 수도 늘어난다. 라우터는 패킷 크기와 상관없이 개수만큼 처리 부담을 진다. 게임 패킷은 55바이트 안팎이라 같은 데이터양이면 1,500바이트 패킷보다 개수가 27배이고, 그만큼 라우터 입력 버퍼를 빨리 채운다. Riot의 설명으로는 과부하가 걸리면 UDP 패킷부터 버리는 라우터도 많다. 해결책으로 Riot은 미국의 큰 인터넷 거점 10곳에 라우터를 두고 가능한 한 많은 통신사와 직접 연결(피어링)하는 자체 망 Riot Direct를 만들었다. 2부에 따르면 핑 80ms 미만으로 플레이하는 유저 비율이 9개월 남짓 동안 31%에서 50%로 올랐고, 게임 서버를 시카고로 옮긴 뒤 하룻밤 사이 80%가 됐다.
배울 점: 같은 나라 안에서도 특정 통신사 사용자만 핑이 유독 높으면 경로를 의심한다. 확인 신호는 통신사(ASN)별 RTT 분포와 traceroute에 찍히는 경유 도시다. 주 담당은 인프라팀(네트워크)이고 통신사와의 직접 피어링, IX 연결, 서버 위치 선택으로 고친다. 통신사 쪽 경로 정책은 외부(통신사)와 협의할 일이다. 이 사례처럼 서버를 사용자 분포의 중심 가까이 옮기기만 해도 효과가 크다.
관련 원인: 우회 라우팅, 전파 지연 (물리적 거리), 병목 대기열 넘침 (혼잡 손실)
원문: Riot Games

Riot Games 2020: League of Legends 유럽·브라질 서버의 엣지 호스트 과부하

무슨 일: 2020년 2월 말 League of Legends의 EUW·EUNE·BR 서버에서 여러 차례 장애가 나 새로 시작되는 게임 수가 크게 줄었다. 매칭·게임 서버 같은 백엔드 서비스는 모두 상태가 정상이었지만 들어오는 트래픽이 거의 없었다. Riot은 불안정할 수 있는 클러스터에서 토너먼트 모드(Clash)를 열지 않으려고 일정을 한 주 미뤘다. 회고에 장애마다 이어진 시간은 적혀 있지 않다.
원인: 세 가지가 겹쳤다. 한 서비스로 가는 요청이 잘못 만들어져 특정 경우에 계속 실패하고 재시도되면서 요청이 폭증했다. 컨테이너 시스템과 OS 버전의 알려진 궁합 문제로 OS 내부 메모리가 새고 있었는데, 업그레이드는 Riot 전체 컨테이너 환경의 약 60%에서만 끝났고 유럽·라틴아메리카 클러스터는 진행 중이었다. 인터넷 트래픽을 받아 걸러 백엔드로 보내는 엣지 컨테이너는 같은 샤드(서버군) 안에서는 떨어지게 배치됐지만 다른 샤드끼리 몰리는 것은 막지 못해, 장애 때마다 적어도 세 샤드의 엣지 컨테이너가 호스트 한 대에 몰려 있었다. 그 호스트에 재시도 폭증이 겹쳤고 메모리 누수로 호스트가 멈췄다.
배울 점: 뒷단 서비스가 모두 “정상이지만 트래픽이 안 들어온다”고 답하면 그 앞단(엣지·게이트웨이·로드밸런서)을 본다. 확인 신호는 호스트별 인바운드 연결 수의 쏠림과 특정 요청의 실패·재시도 비율이다. 주 담당은 게임개발팀(서버: 잘못된 요청과 재시도 방식)이고 컨테이너 배치 규칙·OS 업그레이드·쏠림 경보는 인프라팀(서버 장비·OS)이 맡는다. Riot은 요청 코드를 고치고 재시도가 급증하지 않게 바꿨으며 샤드 사이 분산을 구현하기 전까지 쏠림 경보를 두었다.
관련 원인: 게이트웨이·프록시 경유, 연쇄 장애
원문: Riot Games

Riot Games 2021: League of Legends EUW 5시간 장애: 부가 DB 하나가 서버 전체를 멈춤

무슨 일: 2021년 1월 22일 League of Legends EUW 서버가 5시간 조금 넘게 제대로 동작하지 않았다. 로그인한 유저 수와 게임 중인 유저 수 지표가 한꺼번에 끊겼고 두 차례 재시작 사이에는 로그인은 늘어도 게임은 거의 시작되지 않았다.
원인: 중요하지 않은 기능을 맡던 DB의 주 서버에 하드웨어 고장이 났고 그 DB는 예비 서버로 자동 전환하도록 설정되어 있지 않았다. DB마다 커넥션 풀은 나뉘어 있었지만 모든 풀이 같은 스레드 풀을 썼다. 고장 난 DB에 보낸 작업이 끝나지 않은 채 스레드를 점유해 시스템 전체가 쓸 스레드가 바닥났다. 경보가 쏟아지는 가운데 최근 겪은 악의적인 네트워크 공격과 다른 지역의 하드웨어 작업을 먼저 의심하느라, 고장 난 DB의 경보는 약 1시간 뒤에야 눈에 띄었다. 모든 시스템이 한 JVM에서 도는 구조라, 재시작 뒤 재접속 부하 속에서 GC가 몇 초씩 프로세스를 멈추자 지표 수집에도 큰 공백이 생겼다. 로그인 대기열도 설정한 한도를 지키지 않아 유입이 들쭉날쭉했다.
배울 점: 중요하지 않다고 여긴 부가 DB 하나도 스레드 풀 같은 공유 자원을 통해 전체를 멈출 수 있다. 확인 신호는 DB별 대기 중인 요청 수와 스레드 풀 사용률, 그리고 로그인 수에 비해 게임 시작 수가 너무 적은 비율이다. 담당은 게임개발팀(서버: 스레드 풀 격리·타임아웃)과 인프라팀(DB: 자동 전환)이다. 경보가 쏟아질 때는 최근에 겪은 문제(공격 등)부터 의심하기 쉬우니, 판정 순서(범위 → 시점 → 계층)대로 하나씩 배제한다. 재시작 뒤에는 로그인 대기열이 설정대로 유입을 제한하는지도 함께 본다.
관련 원인: 스레드 풀 고갈, DB 장애 전환, 연쇄 장애, 서버 GC 전체 멈춤
원문: Riot Games

Roblox 2021: Roblox 73시간 장애: 서비스 디스커버리(Consul) 클러스터의 경합

무슨 일: 장애는 2021년 10월 28일 오후(태평양 시간) Consul 서버 한 대의 높은 CPU 부하로 시작됐다. 16시 35분 접속 중인 유저 수가 평소의 절반으로 떨어진 뒤 서비스 전체가 멈췄다. 10월 31일 16시 45분에야 모든 유저가 다시 들어올 수 있었고 장애 시작부터 73시간이 걸렸다. Roblox는 매일 5천만 명이 이용한다고 밝혔다.
원인: Roblox는 서비스 디스커버리(서비스끼리 서로의 주소를 찾는 기능), 헬스체크, KV 저장소에 HashiCorp Consul을 쓰는데 Consul 클러스터 하나가 여러 워크로드를 함께 맡고 있었다. 근본 원인은 두 가지였다. 첫째, 몇 달에 걸쳐 넓혀 온 Consul의 새 streaming 기능을 장애 전날 트래픽 라우팅 서비스에도 켜고 그 서비스의 노드 수를 50% 늘렸다. 이 기능은 읽기와 쓰기가 모두 매우 많은 부하에서 공유 자원(Go 채널) 하나에 경합을 일으켰다. 장애 중 바꿔 넣은 코어 수가 더 많은 듀얼 소켓(NUMA) 서버에서는 경합이 더 심했다. 둘째, Consul이 Raft 로그 저장에 쓰는 BoltDB의 빈 페이지 목록(freelist) 관리가 병적으로 느려져, 16kB 이하를 추가할 때마다 7.8MB를 디스크에 썼다. 평소 300ms 미만이던 KV 쓰기 지연 중앙값이 2초가 됐고 느린 리더 서버에서는 TCP 버퍼가 가득 차는 제로 윈도우도 관찰됐다. 텔레메트리가 Consul에 기대고 있어 원인을 찾는 데 필요한 지표도 함께 사라졌다.
배울 점: 여러 서비스가 함께 기대는 기반 시스템(서비스 디스커버리·설정 저장소·인증)이 느려지면 모든 기능이 한꺼번에 멈춘다. 확인 신호는 그 시스템의 쓰기 지연·리더 교체·CPU와, 장애 직전의 설정 변경이다. 담당은 게임개발팀(서버)과 인프라팀(서버 장비·OS) 양쪽이다. 모니터링은 감시 대상 시스템에 기대지 않게 분리해야 장애 때도 지표를 볼 수 있다. 복구할 때는 캐시가 비어 있어 한꺼번에 받으면 다시 무너질 수 있으므로, Roblox는 DNS로 입장할 유저 비율을 조절하며 약 10%씩 늘렸다.
관련 원인: 연쇄 장애, 락 경합, 제로 윈도우 (재전송처럼 보이는 멈춤), 콜드 캐시 (재시작 직후)
원문: Roblox

Square Enix 2021: FINAL FANTASY XIV 확장팩 출시 혼잡과 로그인 대기열 오류

무슨 일: 2021년 12월 확장팩 Endwalker의 얼리 액세스부터 각 월드가 극심하게 붐볐다. 로그인 대기열이 길어졌고 캐릭터 선택 화면에서 로그인할 때나 대기열에서 기다리는 중에 Error 2002가 자주 났다. 일부 월드·존의 다운(Error 3001)과 대기열 타임아웃(Error 4004)도 있었다. 12월 11일 공지 시점에도 얼리 액세스 8일째 혼잡이 이어지고 있었다.
원인: Error 2002는 두 경우에 난다. 하나는 논리 데이터센터마다 대기 인원이 17,000명을 넘을 때다. 대기열이 너무 길어져 로그인 서버가 다운되는 것을 막으려는 상한이고 이때는 클라이언트가 완전히 종료된다. 12월 7일 개발용 예비 장비를 로비 서버에 투입해 상한을 올리자 이 오류는 줄었지만 대기열은 오히려 길어졌다. 다른 하나는 대기 중 유저의 회선이 불안정할 때다. 대기 시간이 길어지면서 인터넷 경로의 패킷 손실이나 와이파이 불안정으로 연결이 잠깐 끊기는 일이 늘었다. 로비 서버는 수십 초에서 1분 정도 재연결을 기다려 주고 그 안에 다시 붙으면 대기열 중간부터 이어 가지만 넘기면 맨 뒤로 가야 한다. Square Enix는 제보 대부분이 이 경우라고 밝혔다. 반도체 부족으로 월드를 바로 늘릴 수도 없었다.
배울 점: 대기열이 길어질수록 대기 중인 유저의 짧은 회선 끊김이 접속 오류로 바뀐다. 같은 혼잡에서도 오류가 와이파이나 불안정한 회선을 쓰는 사람에게 몰려 “일부에게만” 생기는 문제가 된다. 확인 신호는 대기열 길이·대기 시간과, 끊김 사유 가운데 대기 중 연결 끊김의 비율이다. 주 담당은 게임개발팀(서버: 대기열 상한과 재연결 유예 시간)이고 로비·월드 서버 증설은 인프라팀이 함께 한다. 재연결 유예 시간을 넉넉히 두면 유저 회선의 짧은 끊김이 대기 순번을 잃는 일로 번지는 것을 줄일 수 있다.
관련 원인: 로그인 대기열 상한·재접속 유예 부족, 와이파이 간섭·신호 약화, 무선 구간 손실
원문: Square Enix

Cloudflare 2020: Cloudflare 백본 설정 오류로 일부 도시의 트래픽 손실

무슨 일: 많은 게임이 웹·API·DDoS 방어를 CDN 사업자에 맡기므로, 게임도 함께 영향을 받는 유형의 인프라 장애다. 2020년 7월 17일 21:12부터 21:39(UTC)까지 27분 동안 Cloudflare 네트워크 전체 트래픽이 약 50% 줄었다. 영향은 백본에 연결된 미국·유럽·러시아·브라질의 일부 도시 거점에 한정됐고, 다른 거점은 정상이었다.
원인: 뉴어크–시카고 백본 구간 장애로 애틀랜타–워싱턴 구간이 혼잡해지자, 엔지니어가 애틀랜타의 백본 트래픽을 덜어 내려고 라우터 설정을 바꿨다. 정책 항목(term) 전체를 꺼야 했는데 그 안의 조건(prefix-list)만 끄는 바람에, 애틀랜타 라우터가 모든 BGP 경로를 더 높은 우선순위(local-preference 200)로 백본 전체에 퍼뜨렸다. 각 거점이 자기 서버로 가는 경로에 준 우선순위는 100이어서 백본에 연결된 거점의 트래픽이 모두 애틀랜타로 몰렸다. 애틀랜타는 과부하되고 영향받은 거점은 처리할 트래픽이 거의 없어졌다. 애틀랜타 라우터를 백본에서 빼자 복구됐다. Cloudflare는 공격이나 침해와 관계가 없다고 밝혔다.
배울 점: 특정 도시·지역 유저만 한꺼번에 접속 끊김이나 접속 불가·무한 로딩을 겪고 나머지는 멀쩡하면, 직전의 경로 설정 변경을 먼저 의심한다. 그래프에서는 한 거점만 CPU·트래픽이 치솟고 영향받은 거점은 오히려 0 가까이 떨어진다. 주 담당은 인프라팀(네트워크)이고 사업자 쪽 장애라면 외부다. Cloudflare는 백본 BGP 세션에 받을 수 있는 경로 수 상한(maximum-prefix)을 두기로 했고, 한 거점이 다른 거점의 트래픽을 끌어가지 못하게 우선순위를 조정했다.
관련 원인: BGP 경로 변경·수렴, 경로 변경·ECMP 불량 경로
원문: Cloudflare

Fastly 2021: Fastly CDN 전 세계 오류

무슨 일: 많은 게임이 패치 파일·런처·웹 페이지를 CDN으로 내려보내므로, 게임도 함께 영향을 받는 유형의 인프라 장애다. 2021년 6월 8일 09:47(UTC)부터 Fastly 네트워크의 85%가 오류를 돌려주었다. 49분 안에 네트워크의 95%가 정상으로 돌아왔고 12:35에 장애가 수습됐다.
원인: 5월 12일 시작한 소프트웨어 배포에, 특정 고객 설정이 특정 조건을 만날 때 발동하는 버그가 들어 있었다. 6월 8일 한 고객이 정상적인 설정 변경을 올리면서 그 조건이 맞아떨어졌다. Fastly는 1분 만에 이상을 감지했고 원인이 된 고객 설정을 찾아 끄자 복구가 시작됐다. 버그 수정 배포는 같은 날 17:25에 시작됐다.
배울 점: 배포한 지 몇 주 지난 코드도 드문 조건을 만나면 한순간에 전 세계 장애가 된다. 게임 쪽 확인 신호는 패치·런처·웹 요청의 HTTP 오류율이 모든 지역에서 동시에 오르는 것과 CDN 사업자의 상태 페이지다. 이미 접속한 게임 연결은 CDN을 거치지 않으면 멀쩡하고 새 접속·패치 다운로드·웹 로그인만 막히는 것이 특징이다. 주 담당은 외부(CDN 사업자)이고 게임개발팀·인프라팀은 CDN을 둘 이상 쓰거나 원본 서버로 바로 받는 우회 경로를 준비해 둔다.
관련 원인: 외부 서비스 의존
원문: Fastly

Meta 2021: Facebook 백본 명령 하나로 DNS까지 사라진 장애

무슨 일: 게임사의 자체 네트워크와 DNS에서도 똑같이 생길 수 있는 유형의 인프라 장애다. 2021년 10월 4일 Facebook(현 Meta)의 서비스가 전 세계에서 접속되지 않았다. 데이터센터를 잇는 백본이 모두 끊기고 인터넷 쪽에서 Facebook의 DNS 서버를 찾을 수 없게 됐다. 회고에 장애가 이어진 시간은 적혀 있지 않다.
원인: 정기 유지보수 작업 중 전 세계 백본 용량을 확인하려고 내린 명령이 의도와 달리 백본의 모든 연결을 끊었고, 이런 명령을 막아야 할 감사 도구는 버그 때문에 막지 못했다. 소규모 거점의 DNS 서버는 데이터센터와 통신할 수 없으면 스스로 비정상으로 판단해 BGP 광고를 거두도록 되어 있어서, DNS 서버가 살아 있는데도 인터넷에서 닿을 수 없게 됐다. 평소의 접속 경로와 대역 외(out-of-band) 접속이 모두 끊기고 내부 도구도 DNS를 잃어, 엔지니어를 데이터센터로 직접 보내야 했고 보안 절차 때문에 시간이 더 걸렸다. 복구 때는 데이터센터마다 전력 사용이 수십 MW씩 줄어 있어 한꺼번에 되돌리면 전력 설비부터 캐시까지 위험할 수 있다고 보고, 부하를 단계적으로 올렸다.
배울 점: 모든 지역·모든 통신사에서 동시에 접속 불가·무한 로딩이 생기면 게임 서버보다 DNS와 BGP 경로를 먼저 본다. 외부 DNS 조회와 공개된 BGP 경로 정보로 회사 밖에서도 확인할 수 있다. 주 담당은 인프라팀(네트워크)이다. 장애 때 쓸 대역 외 접속 경로와 내부 도구가 같은 DNS·네트워크에 기대지 않는지 미리 점검하고, 복구할 때는 재접속이 한꺼번에 몰리지 않게 부하를 단계적으로 올린다.
관련 원인: BGP 경로 변경·수렴, DNS 장애·지연
원문: Meta

AWS 2021: AWS us-east-1 내부 네트워크 혼잡

무슨 일: 많은 게임이 서버·로그인·데이터를 퍼블릭 클라우드에 두므로, 게임도 함께 영향을 받는 유형의 인프라 장애다. 2021년 12월 7일 오전 7시 30분(태평양 표준시) 북버지니아 리전(us-east-1)의 내부 네트워크가 혼잡해졌다. 7시 33분부터 EC2 API 오류와 지연이 늘어 새 인스턴스를 띄우기 어려웠다(인스턴스 시작은 오후 2시 40분 회복). 콘솔 로그인 실패, Route 53 설정 변경 불가, CloudWatch 지표 지연과 일부 유실도 이어졌다. 네트워크 장비는 오후 2시 22분에 완전히 회복됐다. 이미 돌던 EC2 인스턴스와 기존 DNS 응답은 영향을 받지 않았다.
원인: 메인 네트워크에 있는 한 서비스의 용량을 늘리는 자동 작업이 내부 네트워크의 수많은 클라이언트에서 예상하지 못한 동작을 일으켜 연결 시도가 폭증했다. 내부 네트워크와 메인 네트워크를 잇는 장비가 넘쳐 통신이 지연됐고 지연이 다시 연결 시도와 재시도를 늘려 혼잡이 이어졌다. 클라이언트에는 이런 혼잡 때 요청 간격을 늘리는 백오프 동작이 있었지만 잠재된 결함 때문에 제대로 작동하지 않았다. 내부 모니터링도 같은 네트워크에 기대고 있어, 운영팀은 실시간 지표 없이 로그를 보며 대응했다.
배울 점: 재시도가 간격을 늘리지 못하면 짧은 혼잡이 몇 시간짜리 장애가 된다. 게임 쪽에서 보면 이미 돌던 게임 서버는 멀쩡해도, 새 서버 증설(오토스케일링), 클라우드 API를 쓰는 로그인·매칭·결제, 모니터링이 함께 막힐 수 있다. 확인 신호는 클라우드 사업자의 상태 페이지와 클라우드 API 오류율, 인스턴스 시작 실패다. 주 담당은 외부(클라우드 사업자)다. 게임개발팀은 모든 재시도에 무작위 간격의 지수 백오프와 횟수 제한을 두고 인프라팀은 증설이 막혀도 버틸 여유 용량과 다른 리전 대안을 준비한다.
관련 원인: 연쇄 장애, 오토스케일링 지연, 외부 서비스 의존
원문: AWS

Cloudflare 2025: Cloudflare 공용 DNS 1.1.1.1 장애

무슨 일: 유저가 기기나 공유기에 직접 설정해 쓰는 공용 DNS 리졸버의 장애로, 그 설정을 쓰는 유저에게만 모든 게임과 서비스가 함께 막히는 유형이다. 2025년 7월 14일 21:52부터 22:54(UTC)까지 62분 동안 1.1.1.1 리졸버가 전 세계에서 응답하지 않았다. Cloudflare는 많은 사용자에게 이것이 사실상 모든 인터넷 서비스를 쓸 수 없다는 뜻이었다고 밝혔다. UDP·TCP·DNS over TLS 조회가 영향을 받았고 도메인 이름으로 접속하는 DNS over HTTPS는 비교적 안정적이었다.
원인: 6월 6일 앞으로 쓸 다른 서비스의 서비스 토폴로지(어느 거점에서 IP 대역을 광고할지 정한 구성)를 준비하면서, 1.1.1.1 리졸버의 IP 대역이 실수로 그 구성에 함께 묶였다. 7월 14일 그 서비스 구성을 바꾸자 리졸버 대역을 광고하는 거점이 모든 곳에서 오프라인 거점 한 곳으로 줄었고, 전 세계에서 BGP 경로가 철회됐다. 이 변경은 카나리 배포를 거치지 않고 모든 데이터센터에 바로 퍼졌다. 22:20 설정을 되돌리자 트래픽이 약 77%까지 돌아왔다. 그사이 엣지 서버의 약 23%에서 필요한 IP 설정이 지워져 다시 설정하느라 22:54에야 정상이 됐다. Cloudflare는 공격이나 BGP 하이재킹과는 관계가 없는 내부 설정 오류라고 밝혔다.
배울 점: 게임 서버와 다른 유저는 멀쩡한데 일부 유저만 로그인·패치 서버에 접속 불가·무한 로딩이면 그 유저들이 쓰는 DNS를 의심한다. 이미 연결된 세션은 유지되고 새 접속만 실패하는 것이 특징이다. 유저에게 DNS 설정을 바꾸거나 서버 주소를 직접 조회해 보게 하면 바로 가려진다. 주 담당은 외부(DNS 운영자·통신사)이고 게임개발팀(클라이언트)이 이름 풀이 실패를 다른 오류와 구분해 안내하면 고객 지원에서 바로 판정할 수 있다.
관련 원인: DNS 장애·지연, BGP 경로 변경·수렴
원문: Cloudflare

AWS 2025: AWS us-east-1 DynamoDB DNS 장애와 긴 복구

무슨 일: 많은 게임이 서버·로그인·데이터를 퍼블릭 클라우드에 두므로, 게임도 함께 영향을 받는 유형의 인프라 장애다. 2025년 10월 19일 오후 11시 48분부터 20일 오후 2시 20분(태평양 서머타임)까지 북버지니아 리전에서 세 단계로 영향이 이어졌다. 20일 오전 2시 40분까지 DynamoDB API 오류가 늘었다. 오전 2시 25분부터 10시 36분까지 새 EC2 인스턴스 시작이 실패했다(일부 새 인스턴스의 연결 문제는 오후 1시 50분에 해소). 오전 5시 30분부터 오후 2시 9분까지는 일부 Network Load Balancer(NLB)의 연결 오류가 늘었다.
원인: DynamoDB의 DNS를 관리하는 자동화에 잠재된 경쟁 상태(race condition)가 있었다. 서로 다른 가용 영역에서 DNS 계획을 적용하는 실행기(DNS Enactor) 가운데 유난히 늦어진 하나가 오래된 계획으로 새 계획을 덮어썼다. 곧이어 다른 실행기의 정리 작업이 그 오래된 계획을 지워 리전 엔드포인트(dynamodb.us-east-1.amazonaws.com)의 DNS 레코드가 빈 값이 됐다. 자동화는 이를 고치지 못해 사람이 직접 복구해야 했다. EC2의 물리 서버 관리 시스템은 DynamoDB에 기대고 있어 그동안 물리 서버마다 유지하던 리스(lease)가 만료됐다. DynamoDB가 돌아온 뒤에는 리스를 다시 맺어야 할 물리 서버가 너무 많았다. 작업이 끝나기 전에 시간 초과되고 재시도 작업이 다시 쌓여 “혼잡 붕괴(congestive collapse)” 상태에 빠졌다. 새로 뜬 인스턴스의 네트워크 설정이 늦게 퍼지면서 NLB 헬스체크가 성공과 실패를 오갔고, 정상 노드까지 DNS에서 빠졌다가 돌아오기를 반복했다.
배울 점: 한 곳의 DNS 레코드 오류가 그 서비스에 기대는 다른 서비스로 번진다. 원인이 풀린 뒤에도 밀린 작업과 헬스체크 흔들림 때문에 복구가 몇 시간 더 걸린다. 게임 쪽에서 보면 이미 돌던 서버는 버텨도 새 서버를 못 띄워 오토스케일링이 멈추고, 헬스체크가 흔들리면 로드밸런서가 멀쩡한 서버를 빼는 일이 생긴다. 확인 신호는 클라우드 상태 페이지, 관리형 서비스 API 오류율, 인스턴스 시작 실패, 로드밸런서의 정상 대상 수다. 주 담당은 외부(클라우드 사업자)이고 인프라팀은 헬스체크 실패로 한꺼번에 빠지는 서버 수를 제한하고 다른 리전 대안을 준비한다.
관련 원인: 외부 서비스 의존, 연쇄 장애, 오토스케일링 지연, 로드밸런서 쏠림·헬스체크 오판, DNS 장애·지연
원문: AWS

용어 사전

참고 문헌

자료 616건, 발행처 83곳. 표준 문서, 커널·OS·클라우드·엔진·DB 공식 문서, 논문, 원개발사 기술 글입니다.