Page History
대용량 서비스를 개발하고 로드 테스트를 수행하기
| Warning |
|---|
개요
| Info |
|---|
Native c++ 방식으로 통신을하면서 운영중인 게임서버 에서 웹서비스 요구에따라 , 기존 실시간 서비스를 중계 웹서비스 방식으로 변경하기로 결정 사용언어도 변경하기로 결정 ( c++ → java ) 새로운 언어및 플래폼 전환시 발생한 극한까지 수행한 로드테스트 관련 내용입니다. |
신규 플래폼:
- AKKA-Actor(Scala and JAVA)
- Atmosphere(Websocket)
- PlayFrameWork(Micro webservice
- JNI ( JAVA ↔ c++ ) : 기존 c++과 통신해야하는 부분은 JNI로 커버
설계
이 아티클은 대용량 웹 서비스개발을 위한 표준적인 해결방법을 잘 정리한 문서는 아니며 플랫폼 변화과정에서 대용량 웹서비스 위한 전체 아키텍을 설계하고 로스테스트를 수행한 과정을 상세하게 기술한 내용입니다. 일반적인 웹서비스는 아니며 간단하게 특징을 요약하면 다음과같습니다.
|
개요
| Info |
|---|
Native c++ 방식으로 통신을하면서 운영중인 게임서버 에서 웹서비스 패러다임으로 변경되면서 웹서비스에 적합하 JAVA언어를 사용하기로 결정하고 경험있는 JAVA 웹서비스 개발자들을 영입하면서 프로젝트를 진행 |
신규 플래폼:
- AKKA-Actor(Scala and JAVA)
- Atmosphere(Websocket)
- PlayFrameWork(Micro webservice
- JNI ( JAVA ↔ c++ ) : 기존 c++과 통신해야하는 부분은 JNI로 커버
설계
단일 병목지점 포인트단일 병목지점 포인트( Aux-DB,DC)는 항상 존재를 하며 단일지점의 요청을 얼마나 줄이고 분산되는 시스템에 나눠서 일을 시킬수 있느냐가 설계포인트
DB를 호출하는 대부분의 병목 단일지점은 Aux라고 네이밍 지어진 장비, DB의 호출을 책임지고 있는 장비라고 보시면 됩니다.
애시당초 중앙 DB의 병목 현상을 , 서비스를 스케일아웃한다고 해결할수 있는것이아닙니다.
애시당초 중앙 DB의 병목 현상을 , 서비스를 스케일아웃한다고 해결할수 있는것이아닙니다.
서비스 패러다임이 변경되어, 경험있는 다양한 웹서비스 개발자들을 영입을 시도하던 때였으며 그들이 할수 있는 것은 SQL을 호출하여 전달하는것이
다였으며 아무런 도움이 되질 못하였습니다. 그렇다고 고성능 쿼리를 짤수 있는 것도 아니였으며
데이터 중심(쿼리)으로 진행된 몇가지 신규 게임서비스를 망쳐놓기까지 했습니다. 100명의 실시간 게임 사용자가 버튼을 통해 끊임없이 트랜잭션을
유도한다란 의미는 일반적인 웹서비스에 10배가 넘는 사용자가 발생하는 트랜잭션의 양일수도 있으나 그것을 구분하지 못하고 실제로
가장 최신의 DB장비로 그것을 해결하지 못하였습니다.
우리는 이때 웹서비스를 공부하며, RestAPI를 ForkInjoin하여 효율적으로 병렬처리하는 방식과 가비지컬렉터가 작동하는 방식을포함하여
웹소켓을 최적화하고 그것을 분산처리하는 방법등 심지어 고성능 Json 사용방법 , 처음 접해보는 JAVA의 형변환 최적화등을 스스로 연구하기로 하였습니다.
이 당시 어떠한 언어를 사용하던 웹서비스 개발자의 수준이 SQL결과문을 전달하는것이였으며 , 경험있는 웹서비스 개발자를 영입하여
게임 웹서비스에 참여 시도한것은 대부분 실패하였습니다.
| Info |
|---|
간단한 로컬 용어정리 DC/TMS : 데이터센터로 생산된 정보중 중요한 정보를 DB에 적는 역활,DB가 뻗어도 작동되게 설계가 되어집니다. LS/TLS : C++로 작성된 로그인/로비게임들을 관리하는 서버 LobbyAPI : 모던웹 규격에 맞게 웹인터페이스를 제공하고, 백엔드 메시지처리는 C++패킷을 통해처리 로비 : 로그인처러 게임내결제를 비롯하여 수만명 사용자가 게임에 접근하기위한 게임테이블을 정보를 제공 |
...
기존 실시간 처리되는 저수준 패킷들을 모두 Rest화를 합니다. 기존 비동기 처리를 응답을 기다려야하는 Rest와 성능을 유지하면서
설계를 해야할지가 고민이며 웹프레임워크의 튜닝요소를 깊게 살펴보는것에서부터 시작합니다.
이러한 API는 DB설계에 맞추어 이루어지는것이 아닙니다. 우리가 원하는 스펙을 API를 통해 구체적으로 명시화하고
DB는 단지 그 과정에서 저장해야할것을 저장하는 Persitence의 역활만 하면되었기때문입니다.
또한 데이터를 먼저 정의한후 어플리케이션을 설계하려고하면, 구조적인 불일치뿐만아니라
게임웹서비스는 아무것도 못하고 망할 가능성이 높으며 실제로 그러했습니다.
URL : https://www.playframework.com/documentation/2.1.0/ThreadPools
...