로드밸런서 쏠림·헬스체크 오판 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 장애와 긴 복구

출처

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: 정상·비정상으로 판정된 대상 수