오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
SMARTSTUDY 에서 몬스터 슈퍼 리그를 개발하면서 빠른 개발 진행을 위해 선택했던 Python 게임 서버, '잘 되면 다시 만들지 뭐'라는 생각에서 시작했지만 다시 만들 일은 영원히 오지 않았습니다... Python으로 게임 서버를 만들었을 때 사용한 것은 무엇인지 또 실제 오픈 했을 때 서버는 안녕했는지 알아봅니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps...hoondong kim
[Tensorflow-KR Offline 세미나 발표자료]
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps Cycle 구성 방법론. (Azure Docker PaaS 위에서 1만 TPS Tensorflow Inference Serving 방법론 공유)
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
SMARTSTUDY 에서 몬스터 슈퍼 리그를 개발하면서 빠른 개발 진행을 위해 선택했던 Python 게임 서버, '잘 되면 다시 만들지 뭐'라는 생각에서 시작했지만 다시 만들 일은 영원히 오지 않았습니다... Python으로 게임 서버를 만들었을 때 사용한 것은 무엇인지 또 실제 오픈 했을 때 서버는 안녕했는지 알아봅니다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 1부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps...hoondong kim
[Tensorflow-KR Offline 세미나 발표자료]
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps Cycle 구성 방법론. (Azure Docker PaaS 위에서 1만 TPS Tensorflow Inference Serving 방법론 공유)
머신러닝 및 데이터 과학 연구자를 위한 python 기반 컨테이너 분산처리 플랫폼 설계 및 개발Jeongkyu Shin
머신러닝 및 데이터 과학 분야의 컴퓨팅 수요는 해가 갈수록 급증하고 있습니다. 이와 더불어 분산처리 기술, 데이터 파이프라이닝 및 개발 환경 스택 관리 등의 관련된 다양한 이슈들 또한 엄청나게 늘어나고 있습니다. 머신러닝 모델의 기하급수적인 모델 복잡도 증가 추세와 마찬가지로, 모델 학습을 위한 환경 관리 또한 갈수록 복잡도가 높아지는 추세입니다.
이 세션에서는 이러한 문제를 해결하기 위해 python 언어 기반의 분산처리 스케쥴링/오케스트레이션 미들웨어 플랫폼을 개발한 4년간의 과정에서 겪은 다양한 문제들에 대해 다룹니다. 2015년 컨테이너 기반의 고밀도 분산처리 플랫폼 설계 및 프로토타이핑 과정을 PyCon KR에서 발표한 이후, 실제 구현 및 오픈소스화, 안정화를 거치며 겪은 다양한 기술적/비기술적 문제들에 대한 경험을 공유합니다.
기술적으로는 최근 몇 년 간의 클러스터 플랫폼 관련 기술의 진보와 함께 탄생한 다양한 도구들과, 이러한 도구들을 python 기반으로 엮어내기 위해 사용하고 개발한 다양한 오픈소스들을 다룹니다. Python 기반의 컨테이너 스케쥴링 및 오케스트레이션 과정의 구현과, 다양한 프로그래밍 언어로 만든 SDK를 graphQL을 이용하여 연동하는 과정에서의 몇몇 유의점을 설명합니다. 아울러 python 기반의 SDK를 다양한 언어로 포팅했던 경험을 간단하게 안내합니다.
플랫폼을 개발하는 중 등장한 TensorFlow, PyTorch 등의 다양한 머신러닝 프레임워크들을 도입하며 겪은 문제와 해결 과정에 대해서도 나눕니다. 연구 분야에는 Python 2.7 기반의 프레임워크들이 여전히 많습니다. 이러한 프레임워크 및 라이브러리의 지원을 위하여 Python 2 기반의 프레임워크와 Python 3.7로 구현한 컨테이너 인터페이스를 단일 컨테이너 환경에 중복 빌드 및 상호 간섭 없이 공존시키기 위해 개발한 아이디어를 소개합니다.
마지막으로 Python 기반의 프레임워크를 개발, 배포 및 상용화 하는 과정에서 겪은 다양한 어려움을 소개합니다. 솔루션을 배포 및 보급할 때 겪는 다양한 런타임, 하드웨어 환경 및 개인 정보 보호를 위한 폐쇄망 대상의 디플로이 등에 대응하기 위하여 Python 응용프로그램을 단독 실행용으로 패키징하는 과정에서 겪은 팁들을 설명합니다. 또한 GUI 빌드 및 Python, Go 및 C++을 함께 사용한 드라이버 가상화 레이어 개발 등의 내용도 살짝 다룹니다.
이 슬라이드는 PyCon KR 2019의 발표 슬라이드입니다. ( https://www.pycon.kr/program/talk-detail?id=138 )
GDB와 strace로 Hang 걸린 Python Process 원격 디버깅Youngmin Koo
Python 프로그램을 디버깅하실 때 어떤 툴을 사용하시나요? 아무래도 가장 많이 사용하고 계신 툴은 PyCharm이 아닐까 싶습니다. PyCharm은 JetBrains에서 만든 GUI 환경에서 사용할 수 있는 Python IDE입니다.
PyCharm은:
로컬 컴퓨터에서 디버깅 모드로 (PyDev로) Python 프로세스를 실행할 수 있습니다.
로컬 컴퓨터에서 실행 중인 Python 프로세스에 Attach해 디버깅할 수 있습니다.
원격 서버에서 디버깅 모드로 (PyDev로) Python 프로세스를 실행할 수 있습니다.
하지만 원격에서 동작하고 있는 프로세스에 디버거를 Attach하는 기능은 제공하지 않고 있습니다. 또한 Python 디버깅 모듈인 pdb를 사용하여도 동작하고 있는 프로세스에 Attach하는 것은 지원하고 있지 않습니다.
로컬 환경에서는 문제 없이 돌아갔던 Python 프로그램이 원격 서버에서는 아무런 로그 없이 멈춰 버리는 경우 어디서부터 손을 대야 할지 정말 막막합니다. 이 때 GDB와 strace를 이용하면 어디에서 문제가 발생했는지 진단할 수 있습니다. 이 세션에서는 GDB와 strace를 이용해 디버깅하여 원격 리눅스 서버에서 Python Process가 Hang 되어 버리는 문제를 진단하고 해결했던 경험을 공유하려고 합니다.
빌드? 우선 사용부터 매뉴얼? Getting started 한 번 돌려보기 TV 리모컨 버튼 5개 전문가는 교육받아 만들어진다? 경험=시간+시행착오+성공실패 오픈소스 트러블슈팅 “메시지” 구글링 오픈소스 함부로 수정하지 마라 최신 버전을 대하는 우리의 자세 LTS로 대동단결 팀장 설득하기 오픈소스는 공짜가 아닙니다. 저도 기여하고 싶어요 2,000년 톰캣을 시작으로 Ant, Eclipse, JUnit, JMeter를 거쳐 현재 개발에 잘 사용하고 있는 Yona, Git, VSCode, Jenkins, CentOS, VirtualBox, Nginx, Node.js, Express.js, MariaDB, Uptime, Mocha, SonarQube, ZAP 이야기 등입니다.
https://www.youtube.com/watch?v=5LHOTBxG0hc
(GameTech2015) Live Operation by Adbrix의 Node.js와 MongoDB를 이용한 멀티테넌트 인프라 구축사례Jeongsang Baek
대부분의 중소 모바일 게임 업체는 앱을 잘 만들기에도 시간이 모자라 출시일을 잘 맞추기 급급한 상황이다. 그러다 보니 운영을 위한 툴은 소홀히 개발하는 경우가 대부분이고 운영 캠페인은 날림으로 개발하거나 그때 그때 개발자가 필요한 부분만 개발하기 일쑤다. 그러다보니 마케터는 결국 늘 개발자 눈치만 살피게 된다. 필자는 블루윈드에서 이러한 문제를 절감했고 '모바일 게임 개발사가 앱 개발에만 집중할 수 있게 해주고 싶다'는 IGAworks의 철학에 공감하여 라이브 오퍼레이션 프로젝트를 시작하게 되었다.
라이브 오퍼레이션의 개발 중점과제는 5가지였다. 첫번째, 다수의 개발사가 하나의 큰 클라우드 시스템을 사용하도록 multi-tenant 인프라를 구축해야 한다. 두번째, TCO(Total cost of ownership)를 최소화해야 한다. 세번째, 앱의 핵심유저를 실시간으로 그룹화하여 타게팅 캠페인을 할 수 있어야 한다. 네번째, 캠페인의 성과를 마케터에게 실시간으로 피드백해야 한다. 다섯째, 3개월 안에 정식 서비스가 되어야 한다는 점이었다. (왜 우리에게 주어지는 시간은 늘 3개월인가) 그리고 당연하지만 이 서비스를 혼자 개발해야 했다.
이 다섯가지 이슈를 해결하기 위하여 AWS 클라우드 상에 생산성과 성능이 검증된 node.js 와 mongodb를 이용하여 서비스 백엔드를 구성하였고, multi-tenant를 구성하기 위한 여러가지 고민과 그 해결책을 직접 구현하였다. 필자는 node.js와 mongodb를 사용해 본 경험이 충분하다 생각했지만 대규모 정식 서비스를 진행하며 많은 함정에 빠졌고 결국 해결했다.
이 발표를 통해 청강자는 node.js와 mongodb를 이용하여 multi-tenant 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
이 발표는 [야생의 땅: 듀랑고]의 지형 배포 시스템과 생태계 시뮬레이션 자동화 시스템에 대한 이야기를 다룹니다. 듀랑고의 각 섬은 크기와 지형, 기후 조건이 다양하고 섬의 개수가 많아서 수동으로 관리하는 것은 사실상 불가능합니다. 몇번의 사내 테스트와 베타 테스트를 거치면서 이러한 문제를 해결해주는 자동화된 도구의 필요성이 절실해졌고, 작년에 NDC에서 발표했던 생태계 시뮬레이터와 Docker, 그리고 아마존 웹서비스(AWS)를 이용하여 수많은 섬들을 자동으로 생성하고 관리하는 자동화 시스템을 구축하게 되었습니다. 그 과정에서 했던 고민들, 기존의 애플리케이션을 "Dockerizing" 했던 경험, AWS의 각 서비스들을 적절히 활용했던 이야기, AWS의 각 지역별 요금이 상이하다는 점을 이용해서 비용을 절감한 사례, 그리고 자동화 시스템의 문제점과 앞으로의 방향에 대해서 이야기 할 계획입니다.
Similar to [Play.node] node.js 를 사용한 대규모 글로벌(+중국) 서비스 (20)
6. node.js 사용 환경
• v6.9.1 LTS 버전 사용중 (’16/11/01 현재)
• A사 cloud 3개 리전, 약 20개의 인스턴스에서 사용중
• 스크립트들도 가급적 node.js 를 사용
• CPU, 메모리 적게 먹어서 참 좋음..
• 그런데… 버전업이 참 빠르네?
7. Node.js in Flitto
• v0.8.8 - ’12/09/07
• v0.10.x
• v0.12.x
• io.js test
• v4.2.1 - ’15/10/27 (v4.2.0 LTS ’15/10/12)
• v6.9.1 - ’16/11/01 (v6.9.0 LTS ’16/10/18)
• => 만 4년 넘게 node.js 로 서비스 중..
in
8. Node.js in Flitto
• 왜 node.js 로 시작했나요?
• 혼자 Front-end, Back-end 등 다해야 해서..
• Cloud service 무료 크레딧 최대한 이용하려고…
• 2012년에는 왠지 cool해 보여서..
9. 주요 발표 내용
• node.js로 5년째 개발하면서 만났던 문제들
• 사실 별거 없었습니다만.. 그래도..
• node.js 버전 업데이트는 어떻게 하나요?
• 구조 개선을 통한 효율 증가
• 중국에서 서비스 하기
• 그 외..
11. node.js 버전 관리는 어떻게 하나요?
• 또… 새버전 나왔어요…?
• 지난 주에 버전업 했는데…
12. node.js 버전 관리 원칙
• LTS 는 서버에서 얼른 업데이트
• Minor, Patch 업데이트는 Change Log를 보고 중요도에 따라 적용
• Major 버전 업데이트시 사내 Coding Convention도 업데이트
• Current 버전은 개발자의 재량으로 사용
• 아무도 안씀.. 내가 먼저 쓰자
• Open source maintaining 하는 repository 는
최대한 많은 버전을 지원하도록.. (travis ci 사용)
13. node.js 버전업 - 준비
• 각종 라이브러리가 지원하는지 확인
• n 패키지를 통해 틈틈히 작업하면서 테스트
• node-gyp 등으로 컴파일 하는 라이브러리는 점점 사용하지 않게 됨
• ex> geoip, node-xml2json 등
• 특별한 방법이 없이.. 하나씩 올리면서 테스트
• 이때 test case 가 큰 도움
• node 6.x 로 버전업 할때 주의점
• GLOBAL => global
• graceful-fs deprecate warning
14. node.js 버전업 - 작업
• 하루 날 잡고, 빌드 서버부터 update를 함..
• 새벽 작업은 1년에 두세번쯤 하는데 그 중 하나가 node.js 버전업
• 작업 순서(서버)
1.node.js 기존 패키지 삭제
2.node.js 신규 패키지 설치
3.npm cache clean ; rm -rf ~/.node-gyp
4.CI 등을 이용하여 다시 배포
15. node.js 버전업 - 작업후 코딩 컨벤션 업데이트
• v6.9.1 업데이트 후, 새로 추가된 사내 컨벤션 규칙 (예시)
• Arrow Functions
18. push 구조 개선을 통한 효율 증가
• 어제까지는 잘 돌았는데..
• 오늘은 왜..?
19. • 플리토 서비스 내 푸시 로직
• 특정 이벤트 발생시, 푸시를 개인화 하여 보냄
• redis에 개인의 push id list와 push 내용을 저장
• 이 때 redis key에 TTL을 7일로 설정
user_id: 홍길동
id[0]: 1
id[1]: 11
push 구조 개선을 통한 효율 증가
id: 1
상태: 읽음
내용: 새로운 요청
id: 11
상태: 안읽음
내용: 새로운 컨텐츠
20. push 구조 개선을 통한 효율 증가 - 첫번째 코드
• 먼저, 이벤트 발생 시, 대상 user list 추출함.
• Step 라이브러리의 this.group() 을 사용하여
• 개인별 push 내용을 redis에 넣고, 개별 push를 전송
25. push 구조 개선을 통한 효율 증가 - 두번째 코드
• 예상대로 서버는 또 죽었습니다..
26. push 구조 개선을 통한 효율 증가 - 세번째 코드
• 근본적인 문제를 생각하기 시작
• Maximum call stack size exceeded 를 막기 위하여
나누어 하기로 함
• 5,000개씩 쪼개서.. async.queue 사용
• queue concurrency 는 1로
28. push 구조 개선을 통한 효율 증가 - 세번째 코드
• 다행히도 이제 죽지는 않음
• 하지만 전송 시간이 7분
29. push 구조 개선을 통한 효율 증가 - 네번째 코드
• push의 공통 요소 별로 묶되,
개인화 요소는 개인의 key에만 관리
• async.queue를 이용하되 한번에 push서버로 보냄
user_id: 홍길동
id[0]: 1:읽음
id[1]: 11:안읽음
id: 1
내용: 새로운 요청
id: 11
내용: 새로운 컨텐츠
user_id: 김길동
id[0]: 11:읽음
30. push 구조 개선을 통한 효율 증가 - 네번째 코드
user_id: 홍길동
id[0]: 1:읽음
id[1]: 11:안읽음
id: 1
내용: 새로운 요청
id: 11
내용: 새로운 컨텐츠
user_id: 김길동
id[0]: 11:읽음
user_id: 홍길동
id[0]: 1
id[1]: 11
id: 1
상태: 읽음
내용: 새로운 요청
id: 11
상태: 안읽음
내용: 새로운 컨텐츠
user_id: 김길동
id[0]: 12
id: 12
상태: 읽음
내용: 새로운 컨텐츠
34. 중국에서 서비스 하기
• 한국 인구의 1%는 50만
• 중국 인구의 1%는 1,350만
• 니…하오?
35. 중국에서 node.js 서비스 하기
• 들어가기 전에
• 비즈니스, ICP 관련된 내용은 여기서 다루지 않음
• 제한 사항
• 서버가 중국에 존재해야 할 수 있음
• Frontend/Backend가 두벌이 필요할 수 있음
36. 생각의 전환이 필요합니다
• 중국은 단지 하나의 국가가 아닌
• 또 하나의 global이라고 생각해야 합니다.
37. 어느 cloud를 이용할 것인가
• 설마 서버를 직접 사서 넣진 않았겠죠?
• 각 cloud별 비교 테스트
• Aliyun
• AWS
• Qingcloud
38. 중국의 network 환경
• GFW
• 참고: 만리장성(the Great Wall)
• 중국의 Great FireWall 을 뜻함
• 외부 ping test
• 중국 서버 => 해외 서버(singapore) 24시간 ping test
• 패킷 loss 평균 7%
• 평균 27X ms
39. 구축 초기
• npm이 왜 이렇게 느리지…
• npm loves you, but doesn’t love China?
• npm install 실행하고 오랜 시간이 걸릴 때가 종종 있음
• 긴급 배포시 문제가 될 가능성
• npm이 지금은 많이 빨라졌으나, cnpm도 사용 고려
40. cnpm이란?
• cnpm이란?
• china…npm?
• https://npm.taobao.org
• npm을 중국내 CDN에 주기적으로 동기화
• sync 등의 명령어를 통한 수동 동기화도 지원
• cnpm을 이용한 패키지 인스톨시,
내부적으로는 npminstall package를 이용합니다.
• GitHub private repo 사용 시 문제 발생할 수 있음: --by=npm 옵션 고려
41. 구축 초기
• OS package 업데이트도 오래 걸림
• 즉, node.js 버전업도 오래 걸림
• 가끔 github도 많이 느림
• 긴급 상황에 bug fix 배포가 안될 수도 있음
• 빌드/배포는 중국 서버에서
• 중국내에서 해외로, 해외에서 중국으로 API 호출시
timeout 이 종종 발생
42. 서비스 속도 향상
• 중국내 CDN 사용
• 해외 CDN vs 중국 CDN
• 118kb file D/L test: 7.8초 vs 100ms
• 글로벌 서버와 전용망 구축 고려
• 하지만 비용이 많이 비쌈
43. 회원 가입 부터가 문제
• 휴대폰 번호 가입을 지원해야 함
• SMS 발송 기능 추가시 abuser 주의
• CAPCHA - ccap
• WeChat, Weibo, QQ 등의 중국 SNS 로그인
• passport를 이용
• 중국 외 서버에서 중국 SNS API호출시 느릴 수 있음