인하우스 웹 프레임워크 "Jul8" 제작기
발표자
데프캣 스튜디오 낫게임팀 윤석주
발표자료
CMS 를 만들 때 보통의 경우 ...
워드프레스같은 프레임워크를 사용한다.
상용에 여럿 사용 케이스가 존재하는 프레임워크 또는 라이브러리를 사용한다.
이유?
- 프레임워크 신규 제작 공수
- 직접 만들었다고 더 좋다는 보장이 없음
- 있는거 쓰자
데브캣 스튜디오의 경우
- 게임 스튜디오라는 특성때문에 웹 개발자가 많지 않음
- 때문에 빠르게 변하는 웹 프레임워크에 일일이 업데이트 대응하기 어려움
- 보통 웹 프레임워크는 대부분 러닝커브가 김
게임의 특징
- 한번 만들어 놓으면 러닝 타임이 길다.
관리 툴 역시 러닝 타임이 길다. 때문에 장기간 유지보수가 가능해야 한다.
웹 프론트엔드 프레임워크의 특징
- 대세가 빠르게 바뀐다.
- 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 대신 사용한다고 합니다.
기존 업무문화와 왓스튜디오의 차이
기존 업무문화
- 기획을 한다
- 기획을 토대로 시안을 만든다
- 기획과 시안을 토대로 프론트엔드를 만든다
- 서버에 올리고 서비스를한다
=> 각자의 전문 분야에서 자신의 역할을 수행하는 일
왓스튜디오
각자의 전문 분야가 있지만 아이디어를 제시하고 구체화하고 실현 시키는 것은 모두의 일
높은 자유도
원래 하던 업무가 아닌 업무도 자유롭게 컨트리뷰트.
한 프로젝트에 대한 메인테이너가 지정되면 사내에서 오픈소스 컨트리뷰팅 하듯이 멤버를 모집한다고 합니다.
=> 타 분야의 지식이 자신의 업무에 도움이 되는일이 굉장히 잦았음
업무 영역의 확장
분야에 상관없고 배우고 참여하는 문화, 팀 내에 있는 전문가들에게 직접 배울 수 있다
전반적인 게임 운영에 필요한 도구를 만든다. 따라서 게임기술을 전반적으로 파악하고 있어야 한다.
모토
"프로그래머나 기획자나 모델러나 분야와 스킬에 상관없이 나와 내 옆에서 같이 일하고 있는 사람들은 모두 게임 개발자다."
듀랑고 데이터 엔지니어링 이야기 - 로그 시스템 구축 경험 공유
발표자
왓 스튜디오 전효준
내용
듀랑고 로그 시스템의 특징
- 로그를 버리지 않고 적재
- 실시간 로그 조회 및 검색
- 분석 및 시각화
- 관리부담 최소화
로그가 필요한 이유
서비스 운영을 위한 로그 조회(ex: 아이템 복구)
지속적 발전을 위한 중요한 도구
오류코드 할당
오류코드는 해당시점의 서버 오류를 찾기 위한 단서.
분산 서버에서 로그를 바로 찾아 원인파악을 하기 위함. 많은 수의 서버로부터 시스템 로그를 모두 수집
어떤 서버에서 어떤 에러가 발생하는지 코드가 어떤 경로로 호출되었는지 Traceback 을 남김
로그의 활용
플레이로그
- 서비스 운영
- 의사결정
- 주요지표 추출
시스템로그
- 개발자 생산성 확대
- 빠른 이슈 대응
듀랑고 로그시스템 요구사항
- 복잡한 시스템 > 복잡한 로그 스키마
- 플레이로그 + 시스템로그 = 대규모 로그
- 대규모 분석
- 빠른 조회 및 검색
높은 가용성
시스템이 죽어도 로그가 유실되면 안됨
실시간 조회
빠른 조회는 생산성 향상과 직결됨
빠르고 쉽게 검색이 가능해야함
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
'it > information' 카테고리의 다른 글
HTML Data attribute 에 대한 고찰 (0) | 2018.10.30 |
---|---|
Coupang Spring 2017 세미나 참관 자료 (0) | 2018.10.30 |
실전 UX 능력 강화로 성공하는 서비스 만들기 - 강의자 토크 - 세상은 어떻게 진화해 가고 있는가? (0) | 2018.10.30 |