한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

매치메이킹·리전 배정 오류 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을 끄고 다시 접속했을 때 배정된 리전이 바뀌는지로 가립니다. 가까운 리전이 아예 없어서 먼 리전에 접속하는 경우는 “전파 지연 (물리적 거리)”에서 다룹니다.

출처

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 주소

매치메이킹·리전 배정 오류 Wrong region assignment (matchmaking / GeoDNS)

출처

함께 보면 좋은 원인

같은 층: L13 서버 구성과 운영

같은 증상(입력 지연)의 다른 층 원인