NDC 2018 리뷰

인하우스 웹 프레임워크 "Jul8" 제작기

---

발표자

데프캣 스튜디오 낫게임팀 윤석주

github.com/devcat-studio/Jul8

발표자료

CMS 를 만들 때 보통의 경우 ...

워드프레스같은 프레임워크를 사용한다.

상용에 여럿 사용 케이스가 존재하는 프레임워크 또는 라이브러리를 사용한다.

이유?

• 프레임워크 신규 제작 공수
• 직접 만들었다고 더 좋다는 보장이 없음
• 있는거 쓰자
  

데브캣 스튜디오의 경우

1. 게임 스튜디오라는 특성때문에 웹 개발자가 많지 않음
2. 때문에 빠르게 변하는 웹 프레임워크에 일일이 업데이트 대응하기 어려움
3. 보통 웹 프레임워크는 대부분 러닝커브가 김

게임의 특징

• 한번 만들어 놓으면 러닝 타임이 길다.

  관리 툴 역시 러닝 타임이 길다. 때문에 장기간 유지보수가 가능해야 한다.

웹 프론트엔드 프레임워크의 특징

• 대세가 빠르게 바뀐다.
• 1년마다 major version up 을 한다.
• 심지어 지금 대세도 대세가 된지 얼마 되지 않아 불안하다
• 대부분의 웹 프레임워크는 기능이 많다. == 그만큼 알아야 하는 것도 많다.
• 프레임워크에 정해진 룰에 의존성이 크다.

필요한 특징

• 많은 기능 대신 필요한 기능만 있으면 된다.
• 본 서비스가 러닝타임이 길어 유지보수를 오랫동안 해야 하기에 누구나 알아보기 쉬워야 한다.
• 팀 상황에 맞아야 한다.

때문에 자체 프레임워크 Jul8 제작을 결정하였다고 한다.

Jul8 특징

React 의 Component 개념을 도입하여 템플릿을 기능별로 분리하였고

템플릿의 DOM 을 js object 에 추상화하는 가상 DOM 개념을 사용함

간단한 구조로 디자이너, 퍼블리셔도 바로 이해하고 사용

> 디자인 단에서 바로 뷰를 작성하여 제공해주니 프로젝트 진행 효율 증대

만들고 나서

게임 개발자에게 맞는 프레임워크가 된듯, 처음 접해보기 때문에 익숙한 구조의 Jul8 이 좋았음

템플릿과 구현이 완전히 분리되어있기 때문에 타 팀 디자이너와 비동기로 협업하기 수월했음

분산 환경을 위한 ORM 구현 경험 공유

---

발표자

아이펀팩토리 - 남승현

발표자료

게임 업계에서의 ORM

• 보통 직접 쿼리를 작성. 가끔 사용하기도 하지만 직접 만드는 경우는 정말 흔치 않다.
• 개발기간을 단축할 수 있도록 ORM 을 사용하려 하였다.
• 게임에 맞는 ORM 을 찾다가 직접 만들었다.

구현한 기능들

• SQL 처리
• lock
• cache
• 분산환경에서의 동작

상세 구현

인터페이스 자동생성

JSON 으로 모델 작성, Python Jinja2 사용하여 인터페이스 코드를 생성

쿼리 자동생성

등록된 모델 정보를 이용하여 런타임에 쿼리를 자동 생성

이벤트 시스템

이벤트 상태

• 실행 준비: 실행하기 위해 스레드를 기다림
• 실행: 스레드를 할당 받아 실행 중
• 중단(롤백): 오브젝트를 즉시 사용할 수 없는 경우 대기
  • DB 에서 읽어와야 할 때
  • 잠금을 얻을 수 없을 때
  • 오브젝트를 사용할 수 있을때 재 실행

오브젝트 저널

• 이벤트 함수 안에서 오브젝트 수정은 임시 저장
• 중단(롤백) 시 임시 저장 내용 삭제
• 완료(완료) 시 캐시 및 Database 에 반영

캐시

• DB IO 를 줄여 성능 향상
• DB 오브젝트를 메모리에 저장

Lock

직접 구현한 이유?

캐시에 로드된 오브젝트는 SQL 락이 불가

DB 샤딩 시 SQL 락 사용 어려움

데드락 회피를 위해 두 가지 방법 시도

• 타이머 이용 – 점유대기 방지
  • 획득한 모든 락 해제하고 이벤트 중단
  • 일정시간 후 락이 풀렸기를 기대하며 이벤트 재호출(일정시간 = Exponental backoff 알고리즘)
• 선점형 락 – 비선점 방지

  • 모든 이벤트는 발생 시간에 의한 우선순위를 갖는다

  • 먼저 발생된 이벤트는 늦게 발생된 이벤트가 중단 상태이면 잠금을 해제할 수 있다.

분산환경에서의 캐시 - 락

Fetch 함수가 오브젝트를 불러 올때 다른 서버의 캐시와 락 이용

Zookeeper

• 오픈소스 분산 코디네이션 서버
• 클러스터를 구성하여 SPoF 를 만들지 않음
• 파일 시스템처럼 사용
• 경로를 지정하여 데이터 저장
• 오브젝트 소유권 관리
• 캐싱
• 오브젝트를 캐시에 입력하기 전 A 파일에 서버 ID 저장, 해당 경로에 이미 파일이 있으면 해당 서버의 캐시와 락을 RPC 로 접근
• 해당 오브젝트 락 처리 타임아웃
• 오브젝트를 캐시에서 읽어 응답으로 전달
• 반납 RPC 수신 시 변경 사항이 있다면 반영

Server A > Zookeeper > DB > Caching > Zookeeper noti

Server B > Zookeeper > Server A Cache RPC > Return RPC

Server A > Return RPC to Cache > DB

캐시적중률

오브젝트를 로그인, 로비 서버가 캐싱하는 현상. Lease RPC 과도하게 발생

더 높은 빈도로 접근하는 서버가 있으면 캐시에서 삭제 후 그 서버가 캐싱

왓 스튜디오의 웹 프로그래머란?

---

발표자

왓 스튜디오 황은빛

발표자료

https://1boon.kakao.com/thisisgame/news001351

http://www.gamevu.co.kr/news/articleView.html?idxno=8340

슬라이드를 찾을 수 없어 보도자료로 대체합니다.

Evolution of web

http://www.evolutionoftheweb.com/

웹의 발전을 시각화한 페이지입니다. 재밌어서 메모한 것 같네요.

작업방식

프로젝트에 메인테이너만 존재하고 사 내에서 각자 필요한 기능을 컨트리뷰트 하면서 진행한다고 합니다.

APNG

gif 대신 사용한다고 합니다.

기존 업무문화와 왓스튜디오의 차이

기존 업무문화

1. 기획을 한다
2. 기획을 토대로 시안을 만든다
3. 기획과 시안을 토대로 프론트엔드를 만든다
4. 서버에 올리고 서비스를한다

=> 각자의 전문 분야에서 자신의 역할을 수행하는 일

왓스튜디오

각자의 전문 분야가 있지만 아이디어를 제시하고 구체화하고 실현 시키는 것은 모두의 일

높은 자유도

원래 하던 업무가 아닌 업무도 자유롭게 컨트리뷰트.

한 프로젝트에 대한 메인테이너가 지정되면 사내에서 오픈소스 컨트리뷰팅 하듯이 멤버를 모집한다고 합니다.

=> 타 분야의 지식이 자신의 업무에 도움이 되는일이 굉장히 잦았음

업무 영역의 확장

분야에 상관없고 배우고 참여하는 문화, 팀 내에 있는 전문가들에게 직접 배울 수 있다

전반적인 게임 운영에 필요한 도구를 만든다. 따라서 게임기술을 전반적으로 파악하고 있어야 한다.

모토

"프로그래머나 기획자나 모델러나 분야와 스킬에 상관없이 나와 내 옆에서 같이 일하고 있는 사람들은 모두 게임 개발자다."

듀랑고 데이터 엔지니어링 이야기 - 로그 시스템 구축 경험 공유

---

발표자

왓 스튜디오 전효준

내용

듀랑고 로그 시스템의 특징

• 로그를 버리지 않고 적재
• 실시간 로그 조회 및 검색
• 분석 및 시각화
• 관리부담 최소화

로그가 필요한 이유

서비스 운영을 위한 로그 조회(ex: 아이템 복구)

지속적 발전을 위한 중요한 도구

오류코드 할당

오류코드는 해당시점의 서버 오류를 찾기 위한 단서.

분산 서버에서 로그를 바로 찾아 원인파악을 하기 위함. 많은 수의 서버로부터 시스템 로그를 모두 수집

어떤 서버에서 어떤 에러가 발생하는지 코드가 어떤 경로로 호출되었는지 Traceback 을 남김

로그의 활용

플레이로그

• 서비스 운영
• 의사결정
• 주요지표 추출

시스템로그

• 개발자 생산성 확대
• 빠른 이슈 대응

듀랑고 로그시스템 요구사항

1. 복잡한 시스템 > 복잡한 로그 스키마
2. 플레이로그 + 시스템로그 = 대규모 로그
3. 대규모 분석
4. 빠른 조회 및 검색

높은 가용성

시스템이 죽어도 로그가 유실되면 안됨

실시간 조회

빠른 조회는 생산성 향상과 직결됨

빠르고 쉽게 검색이 가능해야함

ex: 로그발생 > 5초 이내 조회가능

분석 및 시각화

대규모 로그도 빠르게 분석

SQL 쿼리 사용가능

그래프 자동 생성

관리부담 최소화

하드웨어 이슈로부터 탈출

쉬운 확장 및 축소

로그 시스템 아키텍쳐

수집

게임서버 > Fluentd > Kinesis(Stream) > Lambda > S3

Fluentd

C+Ruby 다양한 플러그인, 간편한설정 오픈소스 데이터 수집기하나의 머신에는 여러 프로세스가 실행. 여러 프로세스의 로그 수집 에이전트

Kinesis

• AWS 관리형 서비스(높은 가용성)
• 스트리밍 데이터를 저장하는 큐 역할
• 최대 7일 동안 데이터 보존
• 데이터 유입량에 따라 무중단 확장 및 축소 가능
  Kinesis > Lambda
  Lambda > S3
  Lambda > ES
  Lucene 기반, 역인덱스, Kibana, 완전관리형 서비스, 한국어 형태소 분석기 지원

조회

Elastic search

분석

AWS EMR(Spark, Zeppelin)

Data Pipeline 배치 job

• Apache Spark
• Apache Zeppelin
  대화식 분석이 가능. 다양한 인터프리터 사용 가능. 쉬운 시각화
• AWS EMR
  Spark 클러스터를 쉽게 구성 + Zeppelin
  스팟 인스턴스 사용 가능
  쉬운 확장 및 축소

Kinesis 의 샤드 개수는 어떻게 결정?

샤드의 처리량 제한

Lambda 의 처리속도

샤드갯수 == Lambda의 동시실행수

람다의 가용 메모리를 증가 > CPU 성능 증가

용량을 줄이기 위함

JSON 에서 Parquet(스키마를가진 컬럼형 데이터 포맷) 로 변환

Table Partitioning

• 데이터 스캔 범위를 제한가능
• 저장경로에 key-value 로 분리

로그 스키마 관리

• 다양한 스키마를 가진다 새로운 스키마 추가되야 한다
• 스키마 변경 시 적재로그를 모두 마이그레이션 할 수있어야 한다
• 컬럼추가만 가능: 하위호환성 유지

스키마 별 Class 추가 또는 업데이트

배포 시 Struct Type jSON 포맷

EMR Spark 클러스터 스펙

메모리가 중요하므로 r4 선호

작은 인스턴스 4개보다 큰 인스턴스 1개

좋은 인스턴스가 네트워크 속도도더 빠르다

분석의 대중화

분석가는 언제나 부족

비 개발자도 분석하기 쉬웠으면

SQL 은 쉬운가?

대중화 실패

분석 규모에 따른 오토 스케일링

로그 스키마 변경

이미 쌓인 로그에 대하여 수정 불가

100개가 넘는 스키마, 모두 기억하지 못함

문서가 없기 때문에 발생 > DocString

꿈을 현실화하기

# 꿈을 현실화하기

야생의 땅 듀랑고 게임 디자인 리뷰

퍼머넌트한 MMO 월드?

연결된 하나의 세계에서 어디서나 개척과 건설

거대대륙모델

인구밀도문제 존재

개척과 건설 반복

여러 대륙모델

유저 유입에 따라 신대륙 출현

늙은 대륙과 젊은 대륙

탐험과 개척의 풍취

야생에 조난당했는데 첫인상이 대도시!?

공룡시대 탐험을 원했는데 보이는건 온통 집 뿐?

탐험할 새로운 땅을 공급하면

전체 땅 넓이가 넓어짐

인구밀도 제어가 안됨

새로운 땅이 공급되는 만큼 땅을 줄여야

개척해둔 마을이 사라지면 곤란 ..

사유지의 지리적 이점

좋은 땅을 선점하는게 중요

게임 시작 직후에는 좋은 땅을 알아보기 어려움

알아챈 뒤엔 이미 늦음

게임에 익숙해진 후 자연스러운 이사가 필요

변화하는 환경

프로토타입

비옥도, 씨앗, 식물, 동물 생태계 존재

플레이에 따라 자원분포 변화.

자원의 멸종 및 과번식, 동물의 무덤현상

땅의 크기가 넓어짐

훨씬 빠른 로직필요

아름다운 자연물 배치 아트요구 조건 증가

특정 자원이 게임 진행에 필수, 멸종하면 곤란 ..

좋은 자원에는 난관이 필요 동물이 지키고 있어야 ..

자원 스팟 (크레이터 도입) > 인과율 포기

절차적 생성되는 환경 O

유저 플레이에 반응해서 변화하는 환경 X

실제같은 체험

무엇으로 게이머의 행동을 이끌어낼 것인가 ..

생존과 협력

살아남기 위해 행동, 나한테 필요한 걸 하는 것보다 다른 사람이 필요한걸 해주는게 훨씬 보람차다

생존 플레이

상태 전달이 어려움

하드코어하고 복잡한 게임

죽지 않기 위한 게임 ..

속성기반 제작

자원을 다양하게 활용

진짜 같은 생존 체험 제공

채집자와 제작사 사이의 협업 고도화

복잡도와 생산성

디자이너가 관리하기 곤란

콘텐츠 조립 생산성이 낮음

실수하면 망함

= 인과율의 폭주

현재의 모델

적절한 자유도와 현실성

콘텐츠 디자인 의도 반영

조립 생산성 개선

재미있는 협업

협업 플레이는 검증

솔로플레이 동기부여 문제

장터를 통한 느슨한 협업 장려

장터 접근성 향상 ...

신규 플레이

장터로 해결하면 된다는 걸 잘 모름 게임진행이 막히면 바로 이탈!
장터를 통해 해결하는 걸 치트처럼 받아들임

가이드로 온보딩 필요

단기 가이드 게임 시스템 교육

행동에 대한 반응형 가이드

장기 가이드 주로 성장에 대한 가이드

조심스레 접근

퀘스트 처럼 보이지 않았으면

하라는 대로 하는 게임이 아니었으면

솔로 플레이 유저군은 동기부여를 잃는 현상이 반복됨

초반 리텐션이 최우선 과제

일직선 가이드 도입 약간의 스토리

갑자기 할게 없어져 당황

스스로 동기부여가 될 떄까지 잡아줄 플레이 루프 필요

복잡한 스킬트리, 높은 성장 자유도, 높은 학습곡선, 스스로 동기부여 ..

단일 레벨 성장, 제한된 자유도, 낮은 학습 곡선, 직관적인 동기부여 ..

하드코어 유저의 빠른 성장 방지. 연구시간

모든 행동에 대해 두갈래 성장

> 주 레벨, 계열 레벨

3개 이상의 계열 가능 > 학습 곡선이 낮아 졌기 때문

직업 정체성이 생김

게이머 스스로 정체화

자연스럽게 역할분담