Quick Comparison

shard, zone, instance는 모두 server를 나눈다는 말이지만 기준이 다릅니다. 용어를 이름만으로 통일하지 말고, "누가 같은 economy와 social graph를 보는가", "누가 같은 공간 상호작용을 하는가", "언제 만들어지고 사라지는가"를 각각 답하게 합니다.

같은 게임도 lobby는 global service, overworld는 zone, dungeon은 instance를 함께 쓸 수 있습니다. 따라서 "우리 게임은 shard형"처럼 하나로 분류하기보다 feature마다 authority boundary를 정합니다.

경계를 정하는 질문

한 entity가 다른 entity와 실시간으로 충돌·전투·시야를 공유해야 하면 같은 simulation boundary에 두는 편이 단순합니다. 반대로 서로 영향을 주지 않는 player population은 같은 process에 넣을 이유가 없습니다. 가장 비용 큰 상호작용을 찾고, 그 상호작용이 process 경계를 넘을 때 필요한 handoff 또는 cross-server message 비용을 비교합니다.

player가 portal 진입
  -> 현재 zone이 이동 조건과 소유 state를 확정
  -> target zone 또는 instance에 handoff reservation 생성
  -> client가 새 endpoint에서 join snapshot 수신
  -> source가 ownership을 해제

경계는 scaling만을 위해 자르지 않습니다. moderation, region 정책, build revision, fault isolation도 같은 경계에 영향을 줍니다. 예를 들어 global auction house를 zone process에 넣으면 zone crash가 거래 전체를 멈추고, match result를 global service가 직접 simulation하려 하면 tick ownership이 흐려집니다.

너무 이르게 나눌 때

처음부터 zone 간 자유 이동, cross-zone projectile, seamless world를 모두 지원하면 session directory, cross-server ordering, ownership transfer, reconnect, observability가 한 번에 필요해집니다. player 수가 적은 초기 서비스라면 instance와 단순 loading transition으로 먼저 시작하고, 실제 hotspot과 population 분포를 관찰한 뒤 zone 분리를 결정하는 편이 낫습니다.

반대로 경계 없이 하나의 world process를 오래 키우면 특정 crowded area가 전체 world tick을 밀 수 있습니다. zone을 나눌 신호는 평균 접속자 수보다 한 곳에 모일 때의 tick overrun, replication bytes, process memory, 장애 범위입니다.

자주 틀리는 부분

zone ID를 단순 map coordinate로만 만들면 event instance와 phase가 다른 두 player가 서로 보일 수 있습니다. zone·instance·phase를 포함한 replication scope를 사용하고, client가 보낸 zone ID를 authority 판단에 그대로 믿지 않습니다.

또한 shard를 server machine의 별칭처럼 쓰면 운영 중에 의미가 바뀝니다. shard가 population partition인지, deployment unit인지, database partition인지 문서와 API에서 하나로 고정합니다.