At a Glance

region 선택은 한 player의 가장 가까운 data center를 고르는 문제가 아닙니다. party와 match 전체에서 누가 어느 정도 지연을 겪는지, 그 region에 capacity가 있는지, 얼마나 더 기다릴 수 있는지를 함께 정하는 정책입니다. 평균 지연만 낮고 한 명이 매우 높은 지연이면 competitive match에는 맞지 않을 수 있습니다.

placement request에는 client가 측정한 candidate region별 latency와 party ID, mode, build revision을 보냅니다. server는 신뢰할 수 없는 raw 값으로 판정을 확정하지 않고, 최근 probe·네트워크 품질·abuse 규칙과 함께 사용합니다. 지연 측정값이 없으면 "0 ms"로 취급하지 말고 정책상 별도 fallback으로 둡니다.

정책을 수치로 만들기

const stages = [
  { forSeconds: 20, maxLatencyMs: 50 },
  { forSeconds: 30, maxLatencyMs: 90 },
  { forSeconds: 40, maxLatencyMs: 140 },
];

function chooseRegion(players: PlayerLatency[], stage: Stage) {
  return regions
    .filter((region) => players.every((p) => p.latencyTo(region) <= stage.maxLatencyMs))
    .sort(byAverageLatencyThenCapacity)[0];
}

숫자는 예시일 뿐입니다. action game, turn-based game, party size, player 지역 분포에 따라 상한과 단계 길이는 달라집니다. 같은 global average라도 한 명의 매우 높은 latency가 simulation과 hit 판정에서 만드는 문제는 average가 감추므로, 개인 최대치와 party 간 편차도 제한합니다.

region을 고른 뒤에는 그 region의 available process, server build, match rule, admission 가능 여부를 다시 확인합니다. "가장 낮은 latency" region이 draining 중이거나 같은 rule revision을 실행하지 않으면 실제 placement 후보가 아닙니다.

player에게 보이는 약속

queue UI는 "낮은 지연 우선으로 region을 찾는 중"과 "더 넓은 region을 확인하는 중"처럼 현재 정책 단계를 알려 줄 수 있습니다. 다만 정확한 내부 score나 다른 player의 지역을 공개할 필요는 없습니다. player가 직접 region을 고르게 한다면 예상 지연, party 영향, 다시 queue에 들어갈 비용을 함께 보여야 합니다.

region fallback은 reconnect에도 적용해야 합니다. match가 이미 시작됐으면 reconnect client를 더 가까운 다른 region으로 보내지 않고 같은 authoritative session으로 돌려보냅니다. 새 region은 새 match placement의 문제이고, 기존 session을 바꾸려면 state handoff가 필요합니다.

자주 틀리는 부분

평균 latency만 정렬하면 한 명의 고지연 player를 희생시킬 수 있습니다. 반대로 가장 느린 player만 보면 모두가 긴 queue를 겪습니다. mode별로 개인 상한, average, 최대 대기 시간을 함께 정해 어떤 trade-off를 허용하는지 명시합니다.

또한 region 이름을 client locale과 혼동하지 않습니다. locale은 언어·상점·법률 표시의 문제이고, placement region은 network path와 server capacity의 문제입니다.