Quick Reference

부하 테스트 bot은 단순히 socket을 많이 여는 client가 아니라, 실제 player처럼 login, matchmaking, input, reconnect, match 종료를 수행하는 검증 도구입니다. connection 수 테스트와 simulation bot 테스트를 분리해야 어느 지점이 한계인지 알 수 있습니다.

성공 기준은 "N명이 접속했다"가 아니라, 목표 동시 match에서 tick deadline, command queue, snapshot byte budget, error rate, memory가 허용 범위 안에 있는지입니다. 기준값과 load scenario는 production server와 같은 build, protocol, data revision에서 고정합니다.

bot이 재현해야 하는 행동

각 bot에는 seed가 있는 행동 script를 둡니다. 같은 seed로 다시 실행하면 같은 join 순서와 input pattern을 재현할 수 있어 문제 match를 좁히기 쉽습니다. input을 매 frame 완전히 난수로 만들면 경로·전투·복제 패턴이 비현실적이고, 실패를 다시 만들기도 어렵습니다.

for (const bot of bots) {
  bot.connect();
  bot.joinMatch();
  bot.everyTick(() => {
    bot.sendInput(bot.behavior.nextInput());
    bot.assertNoInvalidState();
  });
}

assert(p95(tickDurationMs) < TICK_BUDGET_MS);
assert(p99(snapshotBytes) <= CLIENT_SNAPSHOT_BUDGET);

script에는 정상 이동만 넣지 않습니다. 동시에 match 수락하기, match 종료 직전 reconnect하기, 모든 player가 같은 관심 영역에 모이기, inventory event를 retry하기처럼 실제 비용이 집중되는 장면을 포함합니다. 악성 packet과 rate limit 검증은 정상 simulation bot과 별도 scenario로 두어 원인을 섞지 않습니다.

측정과 실패 판정

server는 tick 시작·종료, tick overrun 횟수, command queue 길이, client별 snapshot bytes, dropped/deferred update 수, GC·memory, disconnect reason을 기록합니다. metric label에는 player ID나 match ID처럼 cardinality가 무한히 늘어나는 값을 넣지 않고, match ID는 log와 trace context로 찾습니다. 이 경계는 match debugging과 같습니다.

각 scenario는 목표 부하에 도달하는 ramp time, 유지 시간, 종료 조건을 명시합니다. 예를 들어 p99 tick이 연속 30초 budget을 넘거나, authoritative state assertion이 하나라도 실패하면 실패로 판정합니다. 평균만 보면 드물지만 치명적인 spike가 가려집니다.

실행 환경을 분리하기

production에 임의 bot을 붙여 capacity를 확인하지 않습니다. 별도 test fleet 또는 격리된 namespace에서 실행하고, 외부 결제·보상·ranking 같은 side effect는 sandbox로 향하게 합니다. 테스트가 production과 다른 점은 문서화하되, server binary와 content data까지 다르게 만들어 결과를 무의미하게 하지는 않습니다.

마지막으로 server만 관찰하지 말고 bot 관점의 login 성공률, matchmaking 대기, join snapshot 완료, 입력 ack 또는 보정 횟수도 함께 봅니다. server CPU가 낮아도 client가 계속 timeout이면 사용자가 체감하는 성공이 아닙니다.