만들어야 산다

드디어 앱들을 배포할 시간이 되었다. 배포할 컴포넌트들은 게임 에뮬레이터와 인코딩을 담당하는 기판(Gipan)과 이를 WebRTC 혹은 유저 인터렉션으로 이어주는 오락기(Orakki), 그리고 이것들을 코디네이션하고 주요비즈로직을 담고 있으며 프론트의 API서버인 아줌마(Azumma), 프론트앱인 애새끼(Esekki, 이건 따로 안다뤘음)가 있다. 이번 포스팅에서는 이것들을 어디에 어떤식으로 배포할지를 다뤄보겠다. 물론 답은 정해져 있는데 어디에? AWS에 어떻게? EKS(k8s)를 이용해서 배포해보고자한다. 그리고 이 배포 관련 형상을 관리하는 프로젝트르의 메타포는 아저씨(Azussi)로 한다. 그 옛날 내가 다니던 오락실에서 난닝구 입은 아저씨가 오락실 문앞을 청소하시고 드라이버를 들고 조명이나 오락..

이번에 다룰 컴포넌트는 오락실 오락기의 코어에 가깝다고 할 수 있는 기판이다. 기판을 뜯어보면서 어떤식으로 동작하는지 살펴보고 그 중에서도 비디오 인코딩(오디오 인코딩은 파라미터나 고려할 것들이 비디오에 비해 상대적으로 제한적이라 생략) 관련 부분을 좀더 자세히 살펴보고자 한다. 아키텍처 위 그림은 기판의 쓰레드 구성, 의존하는 모듈, 제어 및 데이터의 흐름을 한곳에 담아보려고 그려보았다. 부연을 해보자면, 쓰레드는 크게 네가지가 있다. 메인 쓰레드 - 롬(Rom)매니저를 통해 필요한 게임롬들을 다운로드하고 프레임콜백을 등록하는 등의 초기화를 수행한 후에 에뮬레이터를 실해시킨다. 프레임콜백이 호출되면 채널을 통해 인코더쓰레드에게 프레임 데이터를 전달한다. 커맨드 처리 쓰레드 - IPC로부터 입력된 Key..

왜 WebRTC 인가? 아무래도 게임이다보니 유저의 입력과 그것이 반영된 화면의 갱신 사이에 딜레이가 있으면 원활한 플레이를 할 수가 없다. 롤할때 젤 많이 하는 소리가 가족분들 안부 묻는거고 그 다음이 아마 핑(ping)계일거다. 그래서 인코딩한 패킷을 가장 빨리 전달할 수 있는 프로토콜을 골라야한다. 오락기의 라이브스트리밍을 위한 프로토콜을 고르기 위해 대표적으로 언급되는 RTMP, HLS, WebRTC를 비교해봤다. 가장 중요한 요소는 얼마나 Low-latency 인지 얼마나 Browser에서 잘 지원되는지였다. 요소 RTMP HLS WebRTC Browser Support Flash 기술이 들어간 Plugin 이 필요함 표준은 따로 있지만(MPEG-DASH) 거의 De-facto 처럼 많이 쓰임 ..

이번에 다룰 컴포넌트는 오락기이며 학습해볼만한 주제는 메시지큐로 잡아봤다. 유스케이스 오락기는 외부에서 요청할만한 엔드포인트를 가지 않는 백엔드 컴포넌트로써 다음과 같은 유스케이스가 있다. - WebRTC 세션을 맺기 위해 아줌마를 거쳐서 클라이언트와 Signaling (SDP/ICE Exchange)을 하게 되는데 이때 아줌마와 통신을 위해 메시지큐(RabbitMQ)를 이용 - 게임(에물레이션)이 돌아가는 기판으로부터 IPC를 통해 인코딩된 비디오/오디오 패킷을 가져오고 유저의 컨트롤데이터를 기판에 전송하기 위해서도 메시지큐(Nanomsg)를 이용 비슷하면서도 다른 두 사례를 통해 각각이 사용하는 메시지큐의 특징과 용법 등을 알아보고 RabbitMQ를 이용한 간단한 수제 RPC 프레임워크인 mqrpc ..

이번 포스팅부터는 오락실의 각 컴포넌트를 소개하면서 학습이 되었던 주제들을 하나씩 뽑아보고자 한다. 일단 이 한 문장을 지르긴 했는데 잘 될지 모르겠다. 일단 첫번째 대상은 프론트의 API 서버이자 오락실의 주요 비즈니스 로직을 담당하는 아줌마 컴포넌트이다. 이 컴포넌트의 주요 기능과 여기에 적용했던 클린 아키텍처에 대해서 간단히 소개해보고 소감을 정리해보겠다. 아줌마 소개 아줌마의 주요 기능은 간단하다. 아래와 같다. 플레이어 및 게임 API 플레이어 생성 내 플레이어 정보 (코인 등) 조회 게임 목록 조회 게임 실행 게임 참가 가능 여부 조회 오락기 드라이버 게임 실행시 오락기 Pod(프로세스)을 프로비저닝(Provisioning) 오락기와 프론트 사이의 중개 역할 시그널링(WebRTC) API SD..

목표 이전 포스트의 스케치에서 어떤식으로 동작하면 되겠다라는 대충의 윤곽이 그려졌고 이를 실제로 구현해낼 수 있는지 프로토타이핑으로 검증하는 단계를 가져봤다. 이때 작업했던 것들이 제일 고통스러웠지만 가장 핵심적이기도 한 내용들이었다. 프로토타이핑의 목표는, "마메(MAME)에서 렌더링된 프레임을 인코딩해서 WebRTC 를 통해 브라우저로 스트리밍한다" 이를 위해 크게 3파트로 나눠서 진행했다. 1. 마메(MAME) 에뮬레이터로부터 이미지 프레임 추출 일단 한장이라도 추출할 수 있으면 구현 가능성이 급격히 올라간다. 2. Headless MAME 라이브러리 제작 마메(MAME)를 빌드하면 기본적으로 sdl2 기반 UI를 가진 앱이 생성되는데 우리는 이미지/오디오 프레임 데이터만 가져올 수 있으면 되기 때..

스케치 일단 러프하게 어떻게 구현할 수 있을지 스케치를 해본다. 대충 통밥으로 게임 에뮬레이터, 비디오/오디오 인코딩, 스트리밍 및 컨트롤이 있을 것 같다. 이들이 어떻게 조화를 이룰지 좀더 살을 붙여보자면, 1. 서버에서 돌고 있는 게임 에뮬레이터는 자신의 tick 에 맞춰 열심히 프레임(이미지, 오디오)를 만들어 낼텐데 2. 이 프레임을 넘겨받아 코덱을 이용해 인코딩을 한 후 3. 연결된 클라이언트(브라우저)에 인코딩된 패킷을 전송(스트리밍)하면 4. 클라이언트(브라우저)는 video element를 이용해 동영상 데이터를 플레이한다 5. 유저의 키입력이 발생하면 이걸 서버로 보내고 6. 서버에서는 이 키입력을 게임 에뮬레이터로 전달해 게임에 반영한다 7. 그리고는 1번으로 가서 계속 반복 게임 에뮬..

뭐 없냐 무슨일을 하든 동기부여가 필요하다. 수입도 안되는 사이드프로젝트에서는 특히나 더. 그때도 사냥거리가 뭐라도 걸려들길 이리저리 배회하고 있었다. 마법의 주문 '뭐 없냐? 뭐 없냐고?'를 외면서 말이다. 근데 마침 구글 스태이디아(Stadia)가 눈길을 끌면서 이것의 토이버전을 한번 만들어보면 어떨까 싶었다. 또 마침 당시 나의 욕구 불만은 몇가지가 있었는데 아마도 이런 것들이었던거 같다. - 비디오/오디오 스트리밍 - 러스트(Rust) 스터디 - 뭔가 만들만한거.. 마메(MAME)같은 에물레이터 소스를 좀 뜯어고쳐서 클라이언트는 키이벤트만 서버로 보내고 렌더링된 이미지/사운드 프레임을 뽑아내서 이걸 인코딩해서 클라이언트에게 보내서 그린다면? 추억의 오락실 게임을 브라우저, 특히 모바일 브라우저에서..

시작 최근에 사이드프로젝트 시즌1을 마무리했다. 시작일로 치자면 1년이 좀 넘었나. 중간에 빵꾸도 많았지만 그래도 끈질기게 그리고 즐겁게 이어온 프로젝트였다. 이름은 딱히 고민하지 않았는데 그래도 지칭할만한 이름은 있어야하니까 그냥 이라고 하겠다. 90년대를 아이로 살았던 친구들은 기억할 것이다. 컴컴하고 담배연기 자욱한 ㅇㅇㅇ 오락실 (나에게는 그 ㅇㅇㅇ이 호돌이). 아마 입구를 들어갈라치믄 염주같은걸 주렁주렁 내린 발을 촤르르 제끼고 들어갔더랬지. 양쪽으로 있는 오락기들을 빈틈없이 차지하고 있는 등들의 사이를 겨우겨우 비집고 들어가면 조금씩 보이는 웅성우성 무리들, 가끔씩 들리는 탄성들, 그 시선들이 향하는 곳을 따라가면 이내 이런 화면이 보이지. 그렇다. 그 추억의 오락실을 재현해보고 싶었다. 20..