사실 게임 "게임 퍼블리싱 플랫폼"이라고 거창하게 적었지만
초기에는 해외의 유저들에게 게임에 접속할 수 있는 홈페이지를 제공하고,
결제를 위해 해외 PG사와 빌링 모듈 연동 개발을 진행하여 결제 웹사이트를 제공하는 단 두가지의 영역만 있었습니다.
(이제는 ai가 설명을 잘해줘서 활용할 맛 나네요. 앞으로 이런스타일로 용어를 설명하겠습니다.)
게임 퍼블리싱 플랫폼(Game publishing platform)은 게임 개발사가 개발한 게임을 발행하고 유통하는 플랫폼입니다. 이러한 게임 퍼블리싱 플랫폼은 게임 개발사에게 다양한 발행 및 유통 지원 서비스를 제공하여 게임을 대중에게 선보이는 역할을 합니다.
게임 퍼블리싱 플랫폼에는 게임을 발행하는데 필요한 마케팅, 프로모션, PR 등의 다양한 서비스가 포함되어 있습니다. 또한, 게임을 유통하기 위한 다양한 채널과 유통 방법을 제공하며, 게임 개발사와 계약을 체결하여 수익을 나누는 방식으로 게임을 유통합니다.
이러한 게임 퍼블리싱 플랫폼은 게임 개발사가 자체적으로 게임을 유통하기 어려운 경우에 유용하게 사용됩니다. 예를 들어, 게임 개발사가 마케팅, 프로모션, PR 등에 투자할 자금이 부족하거나, 게임 유저들과 직접적인 연결고리가 없는 경우에 게임 퍼블리싱 플랫폼을 통해 게임을 대중에게 선보일 수 있습니다.
대표적인 게임 퍼블리싱 플랫폼으로는 스팀(Steam), 에픽게임즈(Epic Games), 유비소프트(Ubisoft), 엘레강스(EA) 등이 있으며, 이들 플랫폼은 게임 개발사에게 다양한 발행 및 유통 서비스를 제공하고, 게임 유저들에게도 쉽고 편리한 방법으로 게임을 구매하고 즉시 즐길 수 있는 기능을 제공합니다.
DB1대와 통신하며 java로 개발한 산출물을 띄운 웹서버를 직접 운영하는 원시적인 형태였는데
IDC에 준비된 서버에 VM을 올려 윈도우서버를 받아 tomcat을 직접 설치하고
빌드된 war파일을 구동했습니다.
오류가 나면 직접 서버에 들어가 서버를 확인하고 서버가 멈추면 장애로 직결되는 구조였죠
파란색 영역이 직접 개발/배포/운영을 담당하던 부분으로
해당 WAS의 기능은 단순히 게임 정보를 제공하는 웹화면과
빌링을 담당하는 API와 어드민 이었습니다.
게임업계에서의 빌링(billing)은 게임 내에서 결제를 처리하는 과정을 말합니다. 이는 일반적으로 유저들이 게임 내에서 구매한 가상 아이템, 캐릭터 스킨, 게임 화폐 등의 결제를 처리하고, 이에 대한 입금, 출금, 결제 거부, 환불 등의 처리를 포함합니다.
빌링 시스템은 게임 업계에서 수익을 창출하는 중요한 수단 중 하나로, 보안과 안정성이 매우 중요합니다. 따라서 대부분의 게임 회사들은 빌링 시스템을 자체적으로 개발하거나, 외부 업체의 빌링 서비스를 도입합니다.
또한, 빌링 시스템은 게임 서비스의 중요한 부분이기 때문에 게임 업계에서는 빌링에 대한 법적인 규제도 존재합니다. 예를 들어, 일부 국가에서는 결제 시스템에 대한 보안 요건을 강화하고, 보호자 동의를 받지 않은 미성년자의 결제를 제한하는 등의 규제가 있습니다.
그외에는 api를 통해 게임서버에 쿠폰을 발급하는 부분과 무려 activeX로 개발된 게임을 호출하는 런처도 개발했었네요
이때 개발 비중은 백엔드와 프론트의 비율이 7:3쯤 되었습니다.
운영과 개발 비중을 따지자면 9:1쯤 되겠군요!(이 비율은 서서히 달라져갑니다)
백엔드에 사용된 프레임워크는 자바기반의 스프링이었습니다.
주로 회원의 가입과 충전을 담당하는 포털과, 게임 컨텐츠를 제공하는 게임 웹사이트가 이때 개발되었습니다.
백엔드측은 API서버와 백오피스를 외부 솔루션에 의존하고 있었습니다.
여기서 백엔드부분에 해당하는 API서버와 백오피스를 내재화하기로 결정이 되었고
설계부터 개발을 진행하기 시작했습니다.
IT 개발 회사에서의 내재화(internalization)란, 소프트웨어 제품이 다양한 언어, 문화, 지역 등 다양한 국가나 지역에서 사용 가능한 상태로 개발되고 준비되는 것을 말합니다.
내재화는 제품을 다국어 및 다문화 환경에서 사용 가능하도록 하는 것을 의미하며, 사용자들이 자연스럽게 제품을 사용할 수 있게 합니다. 이는 일반적으로 UI/UX, 메뉴얼, 지역화된 콘텐츠 등을 포함합니다.
내재화는 국제적인 시장에서 경쟁력 있는 제품을 만드는 데 있어서 매우 중요한 요소입니다. 국제 시장에서 내재화를 통해 제품을 다양한 언어로 제공할 수 있으며, 사용자들에게 가치를 제공하여 제품 인지도와 이용률을 높일 수 있습니다.
내재화를 위해서는 기술적인 측면에서 다양한 언어 및 문화를 지원하는 기술, 프로세스, 툴 등이 필요합니다. 또한, 개발팀과 번역팀 등 다양한 역할의 인원들 간의 협업과 커뮤니케이션이 필요합니다.
가장먼저 개발언어를 찾기 시작했습니다.
소규모 인원이(사실 당시 혼자) 기존 스킬셋을 가지고(java spring 계열) 생산성을 최대한 높일 수 있는 프레임워크를 찾기 시작했습니다. 그게 grails였어요. 지금은 잘안쓰지만 당시에는 최선이었던 것 같습니다.
https://cusmaker.tistory.com/213
필요기능들의 흐름을 파악하고 API를 도출했습니다.
API들은 Restful(이 되고 싶었던) json형식으로 만들어졌습니다.
다섯가지정도의 API 스펙이 정의되고 나서,
게임이 늘어날 경우를 대비해 문서화에도 나름(제기준) 신경을 썼던것 같습니다.
grails를 사용하다보니 Domain Driven Development 를 공부하여 도메인 기반으로 테이블을 설계했습니다.
Domain Driven Development (DDD)은 소프트웨어 개발 방법론 중 하나로, 복잡한 비즈니스 도메인에 대한 이해를 중심으로 소프트웨어 시스템을 설계하고 구축하는 방법입니다.
DDD에서는 비즈니스 도메인을 중심으로 소프트웨어 시스템을 개발합니다. 비즈니스 도메인은 해당 비즈니스에서 사용되는 용어, 규칙, 프로세스 등을 의미합니다. DDD는 이러한 비즈니스 도메인에 대한 전문 지식을 획득하고 이를 소프트웨어 개발에 적용하여 도메인에 특화된 모델을 개발하고, 이를 기반으로 소프트웨어 시스템을 구축합니다.
DDD에서는 도메인 모델링을 통해 비즈니스 도메인을 분석하고 모델링합니다. 도메인 모델은 비즈니스 도메인을 표현한 모델로, 도메인의 핵심 개념, 규칙, 프로세스 등을 포함합니다. 도메인 모델은 개발자와 도메인 전문가들이 공동으로 작업하며, 도메인 전문가들의 지식을 코드에 반영하고, 도메인 모델을 개선하면서 소프트웨어 시스템을 발전시킵니다.
DDD는 소프트웨어 시스템의 복잡성을 관리하기 위해 다양한 패턴과 구조를 제공합니다. 예를 들어, Aggregate, Entity, Value Object, Repository, Service 등의 개념을 사용하여 도메인 모델을 구성하고, Bounded Context, Ubiquitous Language, Context Mapping 등의 개념을 사용하여 도메인을 분리하고 통합합니다.
DDD는 복잡한 비즈니스 도메인에 대한 이해와 해당 도메인의 모델링을 중심으로 소프트웨어 시스템을 구축하는 방법론으로, 비즈니스와 IT 부서 간의 협업을 강화하고, 소프트웨어 시스템의 유지보수성과 확장성을 높이는 데에 효과적입니다.
API와 백오피스의 개발이 끝나고
기존 솔루션에서 사용되던 API의 트래픽을 끊고, 새로만든 API로 연결할때는
테스트를 수차례 했음에도 짜릿한 장애들을 여러차례 맛봐야 했습니다.
이때 밤을 제일 많이 샜던것 같습니다.
이관을 어찌어찌 잘 마친후
자체적인 API서버와 백오피스의 초기버전이 구성되었습니다.
마침내 솔루션에 의존하던 컴포넌트들을 자체 개발이 완료된 것이지요
초기에는 당연히 많은 오류와 버그들이 있었지만
운영팀의 피드백과 지속적인 고도화로 기능개선을 시도했습니다.
그러나 점차 사용자가 늘어날수록
아키텍쳐상의 문제점들이 드러나기 시작했습니다.
예를들어 DDOS공격을 막기위한 장치나,
DDoS(Distributed Denial of Service) 공격은 인터넷을 통해 대량의 요청을 보내 서버나 네트워크를 과부하 상태로 만들어 정상적인 서비스 제공을 방해하는 공격입니다.
일반적으로 DDoS 공격은 여러 대의 컴퓨터나 네트워크 장비를 이용해 수행됩니다. 이를 통해 공격 대상 서버 또는 네트워크에 대량의 트래픽을 보내면, 서버는 해당 트래픽을 처리할 수 없게 되어 서비스가 마비될 수 있습니다.
DDoS 공격은 여러 가지 형태로 나타날 수 있습니다. 가장 일반적인 형태로는 대규모의 봇넷(Botnet)을 이용하여 공격 대상 서버나 네트워크로 대량의 요청을 보내는 것입니다. 이때 봇넷은 해커나 사이버 범죄 조직 등에서 감염된 다수의 컴퓨터 또는 IoT 장비들로 이루어집니다.
DDoS 공격은 서비스 거부와 함께 정보 유출, 서비스 강요, 손상, 협박 등의 추가적인 공격 수단을 이용할 수도 있습니다.
DDoS 공격을 막기 위해서는 다양한 방법이 존재합니다. 대표적으로는 서비스 제공 업체나 보안 업체에서 제공하는 DDoS 방어 서비스를 이용하는 것이 있습니다. 이 외에도 네트워크나 서버 보안 대책을 마련하거나, 가용성이 높은 서버 구성, 트래픽 분산, 캐시 서버 등을 이용하는 방법 등이 있습니다.
SPOF를 대응할 장치도 전혀없었고
SPOF(Single Point of Failure)란, 시스템 구성 요소 중에서 하나의 부분이 고장이나 장애가 발생하면 전체 시스템이 마비되거나 정지되는 위험이 있는 것을 의미합니다.
예를 들어, 서버를 이용한 웹 서비스에서 서버가 하나만 있고, 그 서버에 장애가 발생하면 웹 사이트 전체가 다운되는 경우가 SPOF의 대표적인 예입니다. 또는, 네트워크 인프라에서 하나의 라우터가 고장나면 해당 라우터를 거쳐 가는 모든 트래픽이 중단되는 경우도 SPOF입니다.
SPOF를 제거하기 위해서는 여러 가지 방법이 있습니다. 가장 간단한 방법은, 복수의 서버 또는 네트워크 구성 요소를 동시에 사용하여 다중화 시키는 것입니다. 이렇게 구성하면, 하나의 구성 요소가 고장나더라도 다른 구성 요소가 그 역할을 대신 수행하여 시스템 전체가 정상 동작할 수 있습니다. 이를 통해 시스템 가용성과 안정성을 높일 수 있습니다.
또 다른 방법은, 클라우드 서비스와 같이 외부에 시스템 구성 요소를 위임하는 것입니다. 이 경우, 클라우드 서비스 제공 업체가 다중화된 서버와 네트워크 인프라 등을 제공하여 SPOF 문제를 해결할 수 있습니다.
하지만, SPOF를 완전히 제거하는 것은 불가능합니다. 시스템의 복잡성과 규모가 커질수록 SPOF의 위험성은 커집니다. 따라서, SPOF를 최소화하고 감지 및 복구 기능을 강화하는 것이 중요합니다.
무엇보다 당시 구축된 게임 플랫폼은 작은 규모를 고려하여 설계되었기 때문에, 확장성이 떨어지는 구조였습니다.
이에 따라 개선할 부분이 생기게 되었고, 이를 해결하기 위해 아키텍처에 관여하고 구조를 변경하는 등
이때부터 운영에 대해 생각을 아니하지 않을 수 없게 되었습니다...만
오픈 초기에는 게임들이 본격적으로 늘어나기 시작했기때문에
운영에 집중하기보다는 사이드 프로젝트를 진행하며 개발에 더 집중했던 것 같습니다.
다음 글에는 개발에 집중하기위해 진행했던 사이드 프로젝트에 대해 적어보겠습니다.
이후에는 아키텍처 변경과 개발에 대한 내용을 다룰 예정입니다.
'커리어' 카테고리의 다른 글
| [무작정 게임 퍼블리싱 플랫폼 구축기] 6. 못다이룬 TDD, MSA, cloud, docker, MSA ... (0) | 2023.04.13 |
|---|---|
| [무작정 게임 퍼블리싱 플랫폼 구축기] 5. 개선 포인트를 찾아보자 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 4. 서버 터지기 싫으면 바꿔야해 (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 3. 사이드 프로젝트도 틈틈히 .. (0) | 2023.04.08 |
| [무작정 게임 퍼블리싱 플랫폼 구축기] 1. 어쩌다 해외취업, 개발, 그리고 운영 (0) | 2023.04.08 |
