내재화의 장점중 하나로
의존하고 있던 솔루션에 대한 외부 커뮤니케이션 채널을 하나 줄어드니
게임을 더 빠르게 붙일 수 있게 되었고, 실제로도 다수의 게임들을 이때부터
본격적으로 추가하기 시작했는데요
게임마다 특성이 다르지만 게임 퍼블리싱 플랫폼 입장에서 게임을 바라보면
대체로 비슷한 프로세스로 진행되고 있었습니다.
1. 게임을 들여오고, 현지화 작업을 하고
2. 내부 회원이 게임에 접속 할수 있도록 사이트와 런처등을 준비하고
3. 게임에 로그인과 각종 이벤트를 통한 아이템 지급에 필요한 기능, 결제가 가능하도록 API를 연동하고
4. CBT와 OBT를 거치고 나서 데이터를 운영에 맞춰 준비하고
5. 오픈이후 필요한 통계 지표들을 제공하기 위한 어드민을 제공 하는 등
반복되는 게임 런칭 프로세스를 사람 손을 최대한 덜타고 자동화 하는 것이 중요했습니다.
이러한 작업들은 실제로 오픈 전까지는 눈에 보이지 않아
기획자가 하나하나 체크하지 않으면 놓칠 수 있는 부분이 많기때문에
사이드 프로젝트로 게임 런칭프로세스를 한눈에 파악 할 수 있는 기능을 개발하였습니다.
상대 개발사에도 전달하기위한 api 테스트 사이트를 제공하기도 했습니다.
여기서 이러한 사이드 프로젝트를 부담없이 빠르게 진행할 수 있었던 것은
Grails의 Scaffolding 덕분이었는데요, python의 django처럼 풀스택 프레임워크에는 이러한 기능이 있어
단순한 CRUD를 빠르게 쳐낼 수 있었습니다. (하지만 grails는 요즘 인기가 없습니다)
https://cusmaker.tistory.com/215
[Grails Part1-3] Scaffolding for Basic CRUD
안녕하세요 cocy입니다.저번 포스팅에는 Grails를 통해 hello world를 출력하는 부분까지 진행했는데요,이번 포스팅에서는 Grails의 scaffolding 기능을 활용하여 간단한 CRUD를 구현(?) 생성(!) 해 보도록 하
cusmaker.tistory.com
그 외에도 게임이 많아지자 자연스럽게 이벤트 개발, 신규 런칭 등 다양한 개발 요소들이 생겨났고,
이러한 요소들의 일정을 관리하기위해 일정관리 기능을 추가하였습니다.
다만 이후 trello와 같은 툴을 사용하면서 직접 사용되지는 않았습니다.
그리고 간간히 공격으로 의심되는 IP가 확인되었는데요
예를 들면 무차별 대입공격을 통해 아이디와 패스워드를 알아내기위한 요청들,
웹서버 취약점을 노린 알려진 취약점 요청들 등
IP를 바꾸지도 않고 같은 IP에서 지속적으로 오는 요청에 대한 제한이 필요했습니다.(대부분 중국)
그래서 이를 플랫폼단위에서도 제어할 수 있도록 IP 제한 기능을 부랴부랴 만들어 보았었습니다.
이 그림은 서버가 점점 많아지니 시각화가 필요할것 같아
자주 변경되는 서버의 정보들을 일괄적으로 관리하기위해 drag & drop기반의
인터페이스로 서버 관리 기능을 추가하였습니다.
http 요청을 통해 간단한 헬스체크를 하고 신호등을 구현하다 말았던 기억이 나네요
응용 프로그램 헬스체크(Health Check)는 응용 프로그램이 정상적으로 동작하고 있는지를 확인하는 작업입니다. 일반적으로 헬스체크는 응용 프로그램의 상태를 모니터링하여 에러나 장애가 발생하기 전에 예방조치를 취할 수 있도록 도와줍니다.
헬스체크는 주기적으로 수행되며, 응용 프로그램이 정상적으로 동작하는 경우에는 'OK'를 반환하고, 그렇지 않은 경우에는 'FAIL'을 반환합니다. 이를 통해 응용 프로그램의 상태를 파악하고, 문제가 발생한 경우 빠르게 대처할 수 있습니다. 특히, 클라우드 환경에서는 응용 프로그램이 여러 대의 서버에 분산되어 운영되는 경우가 많기 때문에, 헬스체크를 통해 서버 상태를 모니터링하고, 서버가 정상적으로 운영되는지 여부를 확인할 수 있습니다.
헬스체크는 일반적으로 HTTP API를 통해 수행되며, 이를 통해 응용 프로그램의 상태를 체크할 수 있습니다. 또한, 데이터베이스 연결상태, 디스크 공간, CPU 사용량 등 다양한 요소를 모니터링하여, 응용 프로그램의 상태를 파악할 수 있습니다. 이러한 정보를 수집하여 분석하고, 문제가 발생했을 때 빠르게 대처할 수 있도록 하는 것이 헬스체크의 목적입니다.
물론 요즘은 굳이 직접 구현하지 않아도 오픈소스가 많이 있습니다.
이런 사이드 프로젝트들은
사이드 프로젝트는 개발자가 본업 이외의 개인적인 프로젝트를 진행하는 것을 말합니다. 이러한 사이드 프로젝트를 진행하는 이유 중 하나는, 본업에서 해야 할 업무 이외에 자신이 하고 싶은 기술 습득이나 새로운 아이디어를 구현하기 위한 시도 등의 목적이 있을 수 있습니다. 사이드 프로젝트를 통해 실제 서비스를 개발하면서 얻은 경험을 본업에서도 활용할 수 있습니다.
커뮤니케이션 비용을 줄이고 개발에만 집중하고자(살기위해) 진행했습니다.
해외다보니 개발자 수급이 쉽지 않았고, 개발외에 대응이나 서류작업에 시간을 쓰는것이 아까웠거든요
지금 생각해보면 오픈소스나 유용한 툴들을 잘 찾아보면 좀 더 효율적으로 할 수 있지 않았을까 생각됩니다.
다음글에서는 이후 아키텍쳐 개선 내용을 다뤄보겠습니다.
'커리어' 카테고리의 다른 글
| [무작정 게임 퍼블리싱 플랫폼 구축기] 6. 못다이룬 TDD, MSA, cloud, docker, MSA ... (0) | 2023.04.13 |
|---|---|
| [무작정 게임 퍼블리싱 플랫폼 구축기] 5. 개선 포인트를 찾아보자 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 4. 서버 터지기 싫으면 바꿔야해 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 2. 개발만 하던 개발자가 운영을 한다면 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 1. 어쩌다 해외취업, 개발, 그리고 운영 (0) | 2023.04.08 |
