개요

기존 설치형(네이티브)클라이언트에서 작동되는 서비스를 , 웹서비스로 전환하게 되었습니다. 전환 전략은 기존 서비스의 코어 로직을 터치하지 않고, 중계 서비스 모델로 작성을 하는것 여기서 두가지 어려운점이 있습니다. 웹 프로토콜에 사용되는(Http/Websocket) 데이터가 기존 Native C++로 작성된 패킷량보다 사이즈가 큰것, 또한 직접 서버와 통신하는것에 비해 중계서비스의 서버 비용이 증가 한다는것

A:영어(클라이언트)↔영어(서버) 이렇게 통신하는 구조에서

B:한국어(클라이언트) ↔ 한국어 영어둘다 하는 중계서비스(번역) ↔ 영어(서버)

당연히 후자인 b의 통신비용이 증가하게됩니다. 아키텍쳐 구성상 바람직하지 않지만, 개발기간,개발비용을 고려했을때

장단점은 있는부분입니다. 어쨋든 개발플래폼은 약간 믹스가되고, 이러한 중계서비스를 만드는데는 성공을 하였습니다.

하지만 이것이 성능적으로 서비스 가능할수 수준인지 검증하는작업은 개발만큼이나 어려운 과정을 요구합니다.

개발된 내용과 별개로 , 성능테스트를 통한 어플리케이션 성능튜닝과정을 요약합니다.

 Native c++ 방식으로 통신을하면서 운영중인 게임서버 

에서 웹서비스 요구에따라 , 기존 실시간 서비스를  중계 웹서비스 방식으로 변경,

개발은 완료되어 테스트되고 QA SignOFF가 났지만

이미 운영중인 최대동접(2만) * 1.5 배 수준의 로드 테스트 검증 과정의 고뇌와 측정 자료를 기록한 자료

3만명 가상 동접의 Load테스트 TPS 목표와 실제 측정 자료

측정 히스토리

클라이트가 아무 액션을 하지 않는 서버의 상태의 스냅샷을 기입합니다. 클라이언트가 아무 액션을 하지 않는다고 서버가 놀고있지는 않습니다. 사용자가 없이 흘러간 시간별 스냅샵 비교는 중요한 테스트 부분입니다.

...

가상시나리오 Time라인/EndPoint별 성공률
사용자 시나리오가 반영된 Endpoint/시간별 성공그래프
네트워크량 변화 측정
API 지속력 측정

기타정보: 3만명 가상 동접의 Load테스트 목표와 테스트 히스토리

...

-부하테스트 스크립트를 최초에 작성시에는, 특정한 스텝을 잘못수행하여 API Error를 유발할수 있습니다. (돈이 없는데 결제를 계속 한다던지? / 중복로그인을 계속한던지? 등등 ) 초기에 Error는 테스트 스크립트가 잘못된게 대부분이며 다음과 같은 초기 구축시 어려움이 있습니다.

...