Quick Flow

rolling update는 새 process를 띄우는 일만이 아닙니다. 새 process가 client와 protocol을 협상할 수 있고, 같은 match에 들어갈 game build·rule revision을 실행하는지 확인한 뒤, 새 match만 새 build에 배정합니다. 이미 시작한 match는 기존 build로 끝내거나 명시적인 migration 경로를 거칩니다.

새 build 기동 -> readiness와 protocol compatibility 확인
  -> 새 match placement를 새 build로 전환
  -> 기존 build는 새 placement 중지 후 drain
  -> 남은 match 종료·deadline 처리
  -> 기존 build 종료

ready는 process가 실행 중이라는 뜻보다 강해야 합니다. map·data table load, required dependency 접근, schema migration 상태, protocol decoder, health check가 모두 통과한 뒤에만 ready로 보고합니다. readiness 없이 traffic을 열면 rollout 초반 client가 half-initialized server에 들어갑니다.

호환성 matrix를 먼저 정하기

deployment 전에 client build x server build x protocol version x rule revision 조합 중 허용할 것을 정합니다. 예를 들어 새 server가 구 client의 protocol을 읽을 수 있어도, 새 weapon data를 모르는 구 client와 동일 match를 허용할지는 별도 판단입니다. 이 matrix는 코드의 조건문에 흩어두지 말고 release artifact와 admission policy에서 같은 값을 사용합니다.

function canPlace(match: MatchRequest, server: ServerBuild) {
  return server.ready
    && server.protocolRange.contains(match.protocol)
    && server.rulesRevision === match.rulesRevision
    && server.mapRevision === match.mapRevision;
}

database schema를 바꾸면 expand -> 새 code 읽기 -> data backfill -> 이전 code 제거 순서로 합니다. 새 code가 먼저 새 column을 필수로 만들면 rollout 중인 이전 process가 실패하고, 이전 code를 먼저 지우면 rollback 경로가 사라집니다. message schema의 add-only 변화도 같은 원칙으로 배포합니다.

멈춤과 rollback 기준

rollout은 percentage만으로 완료를 판단하지 않습니다. activation 실패, admission 실패, tick overrun, disconnect reason, protocol decode error, match result save 실패를 이전 build와 비교해 threshold를 넘으면 멈춥니다. 새 build를 더 늘리기 전에 새 placement를 중지하고, 이미 시작한 새-build match를 어떻게 끝낼지 결정합니다.

code rollback이 가능해도 irreversible data migration이나 새 rule로 확정한 결과까지 자동으로 되돌아가지는 않습니다. rollback 계획에는 binary, configuration, schema, content data, compatibility policy 각각의 되돌림 가능 여부가 있어야 합니다.

자주 틀리는 부분

deployment controller의 ready pod 수만 보고 기존 server를 바로 종료하면, 게임의 긴 match와 reconnect grace를 무시하게 됩니다. infrastructure rollout과 game session drain은 다른 lifecycle이므로 control plane에서 둘 다 확인합니다.

또한 새 process가 구 protocol을 decode할 수 있다는 이유만으로 구 client에서 새 기능을 활성화하지 않습니다. feature flag와 build capability를 따로 확인해 UI와 server rule이 어긋나지 않게 합니다.