서버: 게이트웨이를 여러 대로 늘릴 수 있는 구조, 게이트웨이가 죽어도 다른 게이트웨이로 다시 붙으면 캐릭터가 그대로 이어지는 구조(세션 재연결). 클라이언트: 게이트웨이가 끊기면 자동 재접속.
인프라팀 할 일
게이트웨이 수평 확장(대수 추가), 게이트웨이별 CPU·연결 수·처리 지연 모니터링.
수치 감각
같은 데이터센터 안이라 평소에는 한 번 거칠 때 1ms 미만. 게이트웨이가 과부하면 수십~수백 ms로 늘어납니다.
그래프에서는
인원·부하를 따라 오름 · 게이트웨이 처리 지연, 게이트웨이 CPU·연결 수
확인할 곳
게이트웨이의 CPU·연결 수와 게이트웨이 소켓의 Recv-Q(ss·netstat), 게이트웨이를 지나기 전과 지난 뒤의 지연 차이. 서비스 메시를 거치는 HTTP·gRPC 호출이면 Istio 표준 지표 istio_request_duration_milliseconds를 보내는 쪽(reporter=source)과 받는 쪽(reporter=destination)으로 나눠 비교
이러면 맞음
게임 서버의 처리 시간은 그대로인데 게이트웨이 구간의 지연만 늘고 그 시각 게이트웨이의 CPU가 포화되거나 Recv-Q가 쌓임
이러면 아님
게이트웨이를 거치지 않는 경로(직접 접속, 다른 게이트웨이)도 똑같이 느리면 회선이나 게임 서버 쪽
확인 수단
인프라 도구로 확인(게임 코드 불필요)
더 알아보기
서비스 메시(Istio 등)를 쓰면 서버마다 옆에 붙는 사이드카 프록시(Envoy)도 한 단계로 더해집니다. 서비스 사이의 요청은 보내는 쪽 사이드카와 받는 쪽 사이드카를 차례로 거치고, 프록시에 로그·지표 수집 같은 기능을 더할수록 처리 시간과 대기 시간이 늘어납니다.