추억의 오락실 (6/11) - 서비스 아키텍처링

Scalability를 고려한 서비스 레벨로 아키텍쳐링을 다시 해본다.

 

메타포

개발의 반이 이름짓기라고 했던가. 서비스 컴포넌트들의 이름을 짓기 위해 이런 저런 고민을 하다가 실제 오락실에서 접할 수 있는 요소들을 비유로 지어보면 어떨까 싶었다.

 

오락실의 문을 열고 들어가면 아줌마가 나를 반긴다. 천원을 드리며 "돈바꿔주세요" / "너 이돈 어디서 났어!?" 하며 아줌마와 가볍게 인사를 나눈뒤, 오는내내 설레였던 그 오락기 앞으로 발을 옮긴다. 오락기는 웅장하다. 큰 화면과 조이스틱 그리고 동전 넣는 곳이 보인다. 오락기 위에 쌓아둔 동전이 야속하게 사라진다. 가끔 오락기가 돈을 먹거나 문제가 생기면 아줌마가 열쇠로 오락기를 연다. 그 틈으로 보이는 오락기 안쪽으로 반짝반짝 빛나는 초록색 기판이 보인다.... 

주요 컴포넌트가 다 나왔다.

 

아줌마 (Azumma)

오락실에 방문하는 우리들을 호스팅하시는 분(컴포넌트)이다. 게임 타이틀 관리, 동전 충전, 오락기 배정 및 코디네이션 등의 비즈니스로직을 담당한다. 

 

오락기 (Orakki)

오락기는 기판의 컨테이너이자 유저와 기판 사이의 인터랙션을 중개하는 역할을 한다. 오프라인 오락실에는 오락기가 한정적이지만 우리는 디지털이니까 유저의 요구(On Demand)에 따라 얼마든지 늘어날 수 있다.

 

기판 (Gipan)

오락기의 핵심이다. 게임 에뮬레이터를 추상화하고 인코딩 프레임 전송 및 유저 입력을 받는 인터페이스를 제공한다. 이 기판만 있으면 웹이든 콘솔이든 또 다른 디바이스든 이를 이용하는 표현층(Presenter)을 다양화할 수 있다.

 

주요 고려 사항

- 아줌마는 Stateless (서버 이벤트도 Polling 으로)

- 아줌마는 DB 엑세스 가능

- 오락기랑 기판은 한세트(Single Pod)로 구동, 하지만 Decoupling 된 구조

- 스트리밍/인터랙션은 오락기와 유저가 직접 통신

  (아줌마는 오락기를 프로비저닝 후 코디네이션만 하고 빠짐)

- 아줌마와 오락기간의 통신은 메시지큐를 통한 비동기 방식

 

서비스 아키텍처 

그렇게 그려본 구성안

 

기술 스택

컴포넌트	언어, 프레임워크 등	이유
기판 (Gipan)	Rust	MAME 라이브러리의 바인딩 지원 및 인코딩 등 네이티브 요소 필요. 무엇보다 한번 공부해보고 싶어서.
오락기 (Orakki)	Go, Pion(WebRTC)	타입 언어, 게임 엔진으로써 State 관리, 프레임/인풋 등의 동시 처리 용이 (고루틴(Goroutine) + 채널)
아줌마 (Azumma)	Go, Gin(Web)	타입 언어, 웹서버라 뭐든 상관 없지만 오락기와 스택 통일
프론트	Typescript, Next.js, Redux	걍 많이 쓰는 콤보
데이터베이스	MariaDB (MySQL)	특별히 NoSQL 반디스 꼭 써야할 이유 없으면 RDB
메시지큐	RabbitMQ	오락기와 아줌마 간의 통신 매체. Broadcast, Direct 등 다양한 메시지 모델링 가능. 실행 간편. 어드민 툴 굿.
IPC	NanoMsg	오락기와 기판 사이의 프레임/인풋 통신 매체. ZeroMQ를 고려했다가 그 개발자가 새로 시작한 프로젝트라 함.