load test for multiplayer game - 2005

로드 테스트를 위한 분산처리 시스템

2005년제작되었으며, 저수준 모듈을 포함(TCP) 모두 구현해야 했던 시기입니다.

로드 테스트 컨트롤러

• 분산되어 있는 Agent에게 게임 플레이어를 가능하게하는 명령이 가능하였습니다.
• 다양한 환경의 네트워크환경에서 대량의 부하테스트를 해야했으며, 클라우드환경이 없었으며 한국의 PC방 인프라를 이용해야했으며 수십명의 사람을 여러 PC방에 출동시켜 Agent를 구동하였습니다. - PC방을 마비시키지 않는선에서 진행되었으며 이때 레더점수를 관리하는 사용자에게는 베틀넷렉이 간헐적으로 발생했기때문에 미안한일이 였습니다.) 10만 이상의 커넥션을 발생시키고 커넥션을 유지하고 측정하는 것은 현재로서도 쉬운일은 아닙니다.
• 비정상 커넥션 테스트를 위해 Disconnect와 Close를분리 , 모뎀사용자도 많이있었으며 통신상태가 안좋았기때문에 재접속을 통한 게임 재개 기능제공은 중요 기능중 하나였습니다.
• 실시간 게임중, 무중단 서버업데이트도 가능하였으며 게임트랜스퍼라고 불리었으며 이 기능을 항상 유지하는것이 어려운과제중에 하나였습니다. ( 개발 난이도보다는, 버전업마다 QA에서 항상 풀테스트 수행 )

제작히스토리 

테스트를 위해 멀티플리이어 게임에서 1명이 모든역활을 수행하면서 다중으로 플레이를 하기 어려웠으며

QA팀이 테스트를위해 가상으로 게임을 진행할수 있는 Bot이 필요하였으며(2005~2006 년 당시 국내 IT개발기업에서 개발자2~3명당 QA한명배치된것은 이례적입니다. ), 

재현하기 힘든 테스트 시나리오완성을 위해 다양한 모드로 가상의 플레이어를 투입시키는 시스템을 개발하였으며

그것을 게임봇이라고 불렀습니다. 

이렇게 완성된 시스템은, 대용량 테스트를 위해 분산처리로 다시 작성되게 되었으며 HP와 협력하여 서버의 한계까지 극한테스트까지 수행되었습니다.

( 로스테스트에 활용된 HP서버를 대량으로 구매한후 기기검증을 한후, 해외 인프라팀에 배송 - 클라우드가 없던시절  )

Jmeter/loadrunner?

로드 테스트를 구축하야한다고하면 , 직적 분산시스템을 작성할 필요없이 HP-로드러너와 같은 테스툴을 활용할고 측정할수 있습니다.

첫 도입할시 로드테스트기가 하루를 넘기지 못하고 뻗는 사태가 자주 발생하였습니다. 

• JVM 테스트기는 C++에 최적화된 서버 장기간 지속 부하테스트를 못함 , 로드러너가 GC(또는 메모리릭)를 견디지 못하고 먼저 뻗었습니다.  - JVM이 7이하였던것같고 현재는,GC가 많이 최적화되어 메니지드에서도 가능할것으로 추정합니다.

분산처리 시스템 2005 vs AKKA

TCP IOCP

AKKA ACTOR

분산처리 시스템은 2005년 C++로도 작성된 어플리케이션으로도 가능하였으며, 이때는 모든것을 대부분 구현해야 했습니다. 

과거 이용되었던 기술용어및 기술이, AKKA기준 어떻게 변화되었는지 정리를 해보았습니다. 팀 경험기준 용어이기 때문에 모두에게 동의를 받을수 없는 용어정리일수 있으며,

현재는 더 다양한 툴킷및 플랫폼을 선택할수도 있습니다.  - 아직도 성공적인 고성능 리얼타임 멀티플레이어 게임은, 대부분 C++로 작성되어 운영중에 있습니다. 

• TCP-IOCP SOCK(C++) : 과거에는 대용량/대량사용자 처리를 위해, TCP모델을 이해하고 저수준통신모듈을 구현하고 서버개발팀이 라이브러리를 유지해야하는것이 첫번째였다. 이제는 플랫폼별로 네티/시그널R/Boost ASIO/Kafka/Akka등 추상화된 통신모듈 선택 가능하며 OSI 7 Layer를 교양삼아 이해할필요는 있지만, TCP 통신모듈을 직접 제작하는 경우는 없어졌습니다. Akka에서 Transport 교체가 가능하며 Netty로 충분합니다.
• Bot Agent : 과거에는 10만 사용자테스트를 위해 Agent(CS방식)를 만들어 PC방 출동후 분산실행한뒤 중앙에서 제어하여 트래픽을 발생하였습니다. 현재는 컨테이너(ec2,로드러너)를 활용하여 클라우드기반에 분산하여 트래픽을 발생할수 있는 장치를 이용할수 있으며 ,  도커기술(쿠버네틱)+클라우드기술의 혜택으로 분산배치는 더이상 큰이슈가 아닙니다.
• 램프업 : 사용자 트래픽 1만,5만,10만 올려감에따라, 테스트 인프라도 확장하였으며 램프업이란 단어를 사용하였습니다. 제조확장공정에서 사용된 단어로 보이며 현재는 스케일 아웃 또는 탄력적으로 확장할수있는 엘라스틱이라는 용어가 쓰이고 있습니다. Akka에서는 Elastic을 다음과 같이 표현합니다. ( Elastic(Adaptive load balancing, routing, partitioning and configuration-driven remoting. )
• 세션서버/커넥션관리및 분산 : 요즘은 L7영역을 활용하는 로드밸런스(Haproxy및 기타등등)가 잘되어있어서, TCP 커넥션 컨트롤이 룰설정으로 가능하지만 과거에는 커넥션 컨트롤을 직접 프로그래밍화하고 관리하였습니다. Akka에서는 클러스터화하고 Role을 부여하여 마치 하나의 어플리케이션 서버인것처럼 논리적 구성이 가능하며 쿠버네티스를 활용한다고 하면 Ingress를 이용할수 있습니다.
• Manager : Agent의 커넥션이 발생하면 이 커넥션자체를 관리하고, 분산처리될수 있게 트래픽을 모니터하고 직접 분산코드를 작성하였으나 Akka에서는 알려진 라우터활용(메일박스-일을적게하는녀석에게 할당,순차,랜덤,꼬리짜르기등)으로 분산처리방식을 선택하면 됩니다.