이 발표는 [야생의 땅: 듀랑고]의 지형 배포 시스템과 생태계 시뮬레이션 자동화 시스템에 대한 이야기를 다룹니다. 듀랑고의 각 섬은 크기와 지형, 기후 조건이 다양하고 섬의 개수가 많아서 수동으로 관리하는 것은 사실상 불가능합니다. 몇번의 사내 테스트와 베타 테스트를 거치면서 이러한 문제를 해결해주는 자동화된 도구의 필요성이 절실해졌고, 작년에 NDC에서 발표했던 생태계 시뮬레이터와 Docker, 그리고 아마존 웹서비스(AWS)를 이용하여 수많은 섬들을 자동으로 생성하고 관리하는 자동화 시스템을 구축하게 되었습니다. 그 과정에서 했던 고민들, 기존의 애플리케이션을 "Dockerizing" 했던 경험, AWS의 각 서비스들을 적절히 활용했던 이야기, AWS의 각 지역별 요금이 상이하다는 점을 이용해서 비용을 절감한 사례, 그리고 자동화 시스템의 문제점과 앞으로의 방향에 대해서 이야기 할 계획입니다.
'야생의 땅: 듀랑고'의 초반 플레이 디자인 과정을 훑어봤습니다. 프로토타입부터 출시까지 어떤 고민과 함께 각 초반 플레이를 만들어 왔는지 담으려 했습니다.
실제 발표에서는 한 슬라이드를 조금씩 쪼개어 볼 수 있게 했으나, 업로드 과정에서 문제가 생겨 공개 버전에서는 애니메이션들을 대부분 삭제했습니다.
감사합니다.
'야생의 땅: 듀랑고'의 초반 플레이 디자인 과정을 훑어봤습니다. 프로토타입부터 출시까지 어떤 고민과 함께 각 초반 플레이를 만들어 왔는지 담으려 했습니다.
실제 발표에서는 한 슬라이드를 조금씩 쪼개어 볼 수 있게 했으나, 업로드 과정에서 문제가 생겨 공개 버전에서는 애니메이션들을 대부분 삭제했습니다.
감사합니다.
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
[NDC 2014] 유저 수만큼 다양한 섬을 만들자
<야생의>의 절차적인 섬 생성 기법
발표장에서 시간이 없어서 답변드리지 못했던 Q&A 내용들을 뒷 부분에 추가하였습니다.
GIF 가 포함된 부분은 잘 나오지 않으므로 궁금하시면 직접 다운로드 받아서 보시기 바랍니다. - http://goo.gl/UUKmjL
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
발표 당일에 발표를 결심하는 바람에 아침부터 코엑스로 가는 버스 안에서, 점심 시간과 쉬는 쉬간에 틈틈이 작업하느라 리허설을 한 번밖에 해보지 못해서 발표할 때 거의 슬라이드 노트를 읽다시피 했던 점 넓은 마음으로 양해 부탁드립니다. 마지막 한 문장을 남겨두고 징이 울려서 매우 아쉽네요. 좋은 행사를 만드는데 기여하신 모든 스텝, 발표자 그리고 참가자 분들께 진심으로 감사드립니다. 내년에 또 뵐 수 있었으면 좋겠습니다.
Difference between Discriminative Learning and Generative Learning
Cosine distance as a Basic metric of Deep Learning
Multi-layer Perceptron as a common part of Deep Learning Variants
Analogy between Similarity in Deep Learning and Wave Coherence
Deep Neural Net. as a Wave Extractor
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
[NDC 2014] 유저 수만큼 다양한 섬을 만들자
<야생의>의 절차적인 섬 생성 기법
발표장에서 시간이 없어서 답변드리지 못했던 Q&A 내용들을 뒷 부분에 추가하였습니다.
GIF 가 포함된 부분은 잘 나오지 않으므로 궁금하시면 직접 다운로드 받아서 보시기 바랍니다. - http://goo.gl/UUKmjL
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
발표 당일에 발표를 결심하는 바람에 아침부터 코엑스로 가는 버스 안에서, 점심 시간과 쉬는 쉬간에 틈틈이 작업하느라 리허설을 한 번밖에 해보지 못해서 발표할 때 거의 슬라이드 노트를 읽다시피 했던 점 넓은 마음으로 양해 부탁드립니다. 마지막 한 문장을 남겨두고 징이 울려서 매우 아쉽네요. 좋은 행사를 만드는데 기여하신 모든 스텝, 발표자 그리고 참가자 분들께 진심으로 감사드립니다. 내년에 또 뵐 수 있었으면 좋겠습니다.
Difference between Discriminative Learning and Generative Learning
Cosine distance as a Basic metric of Deep Learning
Multi-layer Perceptron as a common part of Deep Learning Variants
Analogy between Similarity in Deep Learning and Wave Coherence
Deep Neural Net. as a Wave Extractor
How to implement realistic fabric material by Unreal engine?
This slider shows the way. You can make realistic and physically correct fabric shader by this method.
2D 컴퓨터비젼에 대한 설명. 영상으로부터 정보를 추출해내는 공학/과학 분과인 컴퓨터비젼의 기술에 대한 쉬운 설명. 파이썬(Python)의 컴퓨터비젼/영상처리 라이브러리인 scikit-image를 주로 활용하였으며 코드를 함께 담음.
R컨퍼런스 발표본 (2014.5.30) 임.
3월 중순부터 한달이라는 기간동안 선거운동을 경험하면서 느낀점과 의견들을 정리해 봤습니다. 비전문가의 의견이라 부족한 점이 많고, 선거캠프의 공식적인 입장이나 견해와도 다른 개인의 생각일 뿐입니다.
IT업계가 단기간에 성장을 할 수 있었던 이유는 지식의 공유 문화가 활발했었기 때문이라고 생각합니다. 성공하든 실패하든 자신의 경험을 다른 사람들과 공유하고, 그것을 통해 배움으로써 업계 전체가 빠르게 발전할 수 있었습니다.
정치계에서는 이런 식으로 무언가를 공유하는 문화가 낯설고 걱정도 되시겠지만, 개인적으로는 우리나라 정치권에서도 사소한 지식이라도 문서로 정리되고 공유하는 문화가 만들어 지면 좋겠다고 생각합니다. 그런 문화 속에서 자연스럽게 정치권에 종사하시는 분들이 서로 배우고 성장해, 우리나라의 정치를 더 발전시켜 주실테니까요. 고 노무현 대통령이 대통령 기록실을 만드신 취지도 그런 게 아니었을까 감히 추측해봅니다.
벌써 선거가 끝난 지 한달이 지났고, 저는 다시 일상으로 돌아왔습니다. 그 전과 달라진 게 있다면 정치뉴스란을 좀 더 흥미롭게 읽을 수가 있게 되었다는 정도? 많이 부족한 글이지만 그냥 이런 의견도 있구나 정도로 가볍게 읽어봐 주세요. 감사합니다.
Approximate nearest neighbor methods and vector models – NYC ML meetupErik Bernhardsson
Nearest neighbors refers to something that is conceptually very simple. For a set of points in some space (possibly many dimensions), we want to find the closest k neighbors quickly.
This presentation covers a library called Annoy built my me that that helps you do (approximate) nearest neighbor queries in high dimensional spaces. We're going through vector models, how to measure similarity, and why nearest neighbor queries are useful.
NDC 16에서 발표한 '스매싱더배틀 1년간의 개발일지'라는
제목의 포스트 모템입니다.
PT의 내용은 실제 발표 자료에 조금 더 설명을 붙였으며
PT의 내용에 대한 질문은 아래의 주소를 통해서
문의 부탁드립니다.
Twitter
https://twitter.com/Studio_HG
Facebook
https://www.facebook.com/GameStudioHG
오픈소스 개발을 시작하기로 결정했더라도, 처음 개발하는 경우에는 막상 무엇을 개발할지, 그리고 어떻게 개발해야 할 지 막막하기만 합니다. 이 때는 기존에 공개되어 있는 오픈소스 프로젝트를 활용해 개선해나가는 프로젝트부터 시작하면 많은 도움이 됩니다. 이번 강연에서는 기존 오픈소스 프로젝트를 처음부터 새로 만들어가면서 개선해나갔던 경험을 이야기하고 어떻게 하면 오픈소스 개발에 쉽게 접근할 수 있는지를 알려줍니다.
2016 아이펀팩토리 Dev Day 발표 자료
강연 제목 : Docker 로 Linux 없이 Linux 환경에서 개발하기
발표자 : 김진욱 CTO
<2016>
- 일시 : 2016년 9월 28 수요일 12:00~14:20
- 장소 : 넥슨 판교 사옥 지하 1층 교육실
머신러닝 및 데이터 과학 연구자를 위한 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 )
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
빌드? 우선 사용부터 매뉴얼? 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 인프라를 구축해야 할 때 고려해야 할 설계 방식과 기술적인 고민, 그것에 대한 현실적인 해법을 얻을 수 있다.
2017년 12월 6일 W3C Conference에서 "Docker와 DevOps에서 Serverless와 NoOps로의 여정"라는 주제로 발표한 자료입니다.
데모로 시연한 샘플코드는 아래와 같습니다.
https://github.com/novemberde/serverless-webapp-demo
‘더 나은 번역기’는 일본어 중역을 이용한 번역 서비스입니다. 2013년 봄, 장난스럽게 시작한 프로젝트가 이제는 직장인들과 대학생들이 즐겨 쓰는, 하루 4만건 이상의 번역 요청을 처리하는 인기 서비스가 되었습니다. 더 나은 번역기가 어떤 계기로 만들어졌는지, 2년 반 넘게 운영하면서 어떤 에피소드들이 있었는지 이야기 해볼 계획입니다. 더불어, 더 나은 번역기가 대학원 시절 방황하던 제 삶에 어떤 긍정적 변화를 주었는지, 앞으로의 방향은 무엇인지에 대해서도 이야기 하겠습니다.
[야생의 땅: 듀랑고]의 식물 생태계를 담당하는 21세기 정원사의 OpenCL 경험담Sumin Byeon
이 발표는 넥슨의 신규 개발 게임인 듀랑고의 생태계에 대한 간략한 소개와 OpenCL 을 이용한 병렬 처리에 관한 전반적인 기술적 내용을 다룹니다. 게임 속의 세계에서 지형과 기후, 지질 조건에 맞게 여러 종류의 식물과 광물들을 알맞은 곳에 배치시키는 것이 생태계 시뮬레이터의 역할인데, 이 시뮬레이터는 방대한 양의 계산을 수행합니다. 초기에 만들어진 프로토타입은 이러한 계산을 수행하는데 30분이 넘게 걸렸지만, 병렬처리, 알고리즘 시간복잡도 개선 등의 여러가지 방법들을 통해 그 시간을 11초까지 단축시켰습니다. 구체적으로 어떤 방법들을 시도했었고, 어떤 방법들이 효과가 있었는지 여러분과 그 경험담을 공유하고자 합니다.
Cross-language information retrieval (CLIR) is a technique to locate documents written in one natural language by queries expressed in another language. This project investigates the feasibility of CLIR based on domain-specific bilingual corpus databases.
SLINKY is a different kind of linking technique to overcome drawbacks of static linking without the complexity of dynamic linking, by implicit sharing of data chunks based on their digests. SLINKY suffers virtually no performance degradation and provides a comparable memory footprint to the dynamic linking counterparts.
Self-Tuning Wireless Network Power ManagementSumin Byeon
Explores strategies to design and implement an intelligent power management module that adapts to the usage pattern and the characteristics of the network interface card.
Anand, Manish, Edmund B. Nightingale, and Jason Flinn. "Self-Tuning Wireless Network Power Management." Wireless Networks 11.4 (2005): 451-69. Print.
1. <야생의 땅: 듀랑고> 지형 관리 완전 자동화
생생한 AWS와 Docker 체험기
넥슨코리아
변수민
2. 발표자 소개
<야생의 땅: 듀랑고> 서버 프로그래머 @넥슨코리아
Computer Science, MS @University of Arizona
Computer Science, BS @University of Arizona
Research Programmer @University of Arizona
2010
2011
2012
2013
2014
2015
2016
소프트웨어 엔지니어 @스포카
3. 듀랑고 서버 개발자는 무슨 일을 할까요?
지형 배포, 전투 개선, 국제화, 블록 건축, 사유지 작업, 레벨 디자인, 거시적 밸런
스, 동물 배치, 생태계 시뮬레이션, 생활 컨텐츠 개선, 아이템 시스템 개선, 장터
검색, 화폐 시스템, 함정, 운영툴, 보안 관련 작업, 네트워크 기반 작업, 로그 수집
및 관리, 채팅방, 데이터베이스, 동기화, …
4. 듀랑고 서버 개발자는 무슨 일을 할까요?
지형 배포, 전투 개선, 국제화, 블록 건축, 사유지 작업, 레벨 디자인, 거시적 밸런
스, 동물 배치, 생태계 시뮬레이션, 생활 컨텐츠 개선, 아이템 시스템 개선, 장터
검색, 화폐 시스템, 함정, 운영툴, 보안 관련 작업, 네트워크 기반 작업, 로그 수집
및 관리, 채팅방, 데이터베이스, 동기화, …
그 중에 제가 맡고 있는건 이정도…?
5. 듀랑고 지형 통계
• 2차 LBT 참여자 수 = 6,937명
• 테스트 기간동안 발견된 섬의 수 = 836개
• 인구가 가장 많은 섬 = 플레밍 우랄맥 (504명)
6. 지형 자동 생성
• 이번에 준비한 지형 개수 = 약 300개
• 지형을 수작업으로 만드는 것이 아니라 자동으로 생성하기 때문에 가능한 일
23. 지형 배포 절차
자동화된 검수 과정을 거침
assert x == y
assert z == w
assert essential_files_exist()
assert terrain_contains_this_and_that()
assert validate_chunked_tiles()
24. 지형 배포 절차
• 지형 색인 파일 업데이트
• 지형 파일들을 지형 파일 저장소(Git)에 커밋 & 푸시
25. 지형 배포 절차
Git 서브모듈 업데이트
• (서버 코드 저장소)
• README
• setup.py
• lib
• k1terrains.git
• tests
• (지형 파일 저장소)
• README
• terrains
• (아까 만든 지형)
• (기존 지형 1)
• (기존 지형 2)
• tests
HEAD
26. 지형 파일 관리에 Git을 쓰는 이유?
버전 1
지형 1
서버 저장소
지형 저장소 지형 2 지형 3
버전 1
지형 1
서버 저장소
지형 저장소 지형 2 지형 3
버전 2
지형 4
서버 코드와 함께 버전 관리를 하기 위함 없어진 지형을 참조하는 것을 방지
27. 지형 파일 관리에 Git을 쓰는 이유?
• 입사 전에 이미 만들어진 시스템이라 지형 파일을 Git으로 관리하는 것에 대한
별다른 의문을 가지지 않았지만
• 의문을 가져야 했었다
28. 지형 배포 절차
• 복잡해보이지만 대부분 스크립트로 만들어 놓음
• 하지만 프로그래머가 아닌 사람이 보기엔 여전히 장벽이 높음
이 부분에 대한 고민도 했어야…
34. 생태계 시뮬레이션
Frontend node 1
Frontend node 2
Frontend node n
서버 클러스터
…
Ecosystem Simulator
지형 관리 도구
로컬 머신
데이터베이스
35. 지형 관리 자동화 요구조건
• 고성능 계산 능력이 필요
• 플레이어의 행동에 따라 실행 주기, 작업 규모가 달라질 수 있음
• 여러대의 머신에서 동시에 실행될 수 있고
• 자유로운 스케일 아웃(scale-out)
36. 지형 관리 시스템에 필요한 것들
Ubuntu Linux
.NET runtime (mono)
Python runtime
Python package 1
Python package 2
Python package n
…
Libraries
System tools
서버 코드 지형 관리 도구Other utilities
복잡한 지형 관리 시스템 구성
37. 지형 관리 도구 배포
지형 관리 도구 + 필요한 것들
머신 1 머신 2 머신 3 머신 n…
42. Docker?
• 소프트웨어가 구동되는데 필요한 모든 것 - 코드, 런타임 환경, 시스템 도구,
라이브러리 등 - 을 담고 있는 컨테이너를 제공
• 소프트웨어 배포에 관련된 여러가지 문제를 해결
43. 전통적인 소프트웨어 배포 방식의 문제점
• 배포 환경마다 커널 버전, 설치된 라이브러리 등 런타임 환경이 상이함
• 개발자들의 전통적인 변명 “It works on my machine!”
44. 문제는 표준 규격의 부재
• 소프트웨어 배포 방식의 표준이라고 할만한 것이 없음
배포 스크립트, 가상 머신 이미지, Chef/Puppet, 인스톨러
• 우리가 작성하는 프로그램이 수많은 외부 환경에 의존적인 것도 문제
커널 버전, 라이브러리, 프레임워크, 인터프리터
45. 컨테이너
물류 업계는 ‘컨테이너’라는 통일된 규격을 만들
어서 물건의 종류에 상관 없이 전세계 어디로든
배송 가능하도록 문제를 해결했는데 우리는 왜 그
렇게 하지 못할까
46. 그래서 고안된 것이 바로 Docker
• 컨테이너 안에만 들어가면 옥수수든 아이폰이든 물건의 종류의 상관 없이 원하
는 목적지까지 보낼 수 있다
• Docker 컨테이너로 패키징 된 소프트웨어는 Docker 실행 환경이 갖추어진
곳에서는 별다른 배포, 설치 절차 없이 바로 실행할 수 있다
47. 소프트웨어 배포의 일곱가지 죄악
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
48. 소프트웨어 배포의 일곱가지 죄악
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
49. 소프트웨어 배포의 일곱가지 죄악
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
50. 소프트웨어 배포의 일곱가지 죄악
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
51. 소프트웨어 배포의 일곱가지 죄악
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
52. 소프트웨어 배포의 일곱가지 죄악
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
53. 소프트웨어 배포의 일곱가지 죄악
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
54. Docker가 해결해줄 수 있는 문제
• 나태: 배포 스크립트 미작성
• 탐욕: 싸구려 스테이징 서버
• 식탐: 대규모 변경
• 교만: 코드를 충분히 테스트하지 않음
• 색욕: 검증되지 않았지만 매력적인 도구들
• 시기: 구성원들간 의사소통이 원활하지 않음
• 분노: 현장 디버깅
https://lwn.net/Articles/562333/
55. 가상머신으로도 그런 문제를 해결할 수 있지 않나요?
• 격리: 하나의 호스트 OS에서 여러개의 게스트 OS를 실행하더라도 개별 게스
트 OS 안에서 보기엔 독립된 머신처럼 보임
• 자급자족성: 코드가 실행되는데 필요한 모든 조건을 미리 갖추고 있을 수 있음
56. Docker의 장점
• 격리: 하나의 호스트에서 여러개의 Docker 컨테이너를 실행하더라도 개별 컨
테이너 안에서 보기엔 독립된 머신처럼 보임
• 자급자족성: 코드가 실행되는데 필요한 모든 조건을 미리 갖추고 있을 수 있음
• 자원 효율성: 각 컨테이너마다 커널을 따로 띄울 필요가 없음
57. Docker의 장점
Virtual Machines Docker Containers
Images excerpted from https://www.docker.com/what-docker
이렇게 각 게스트 OS를 실행하기 위해서 낭비되는 자원이 없음
58. Docker의 장점
• 같은 성능의 호스트 머신이라도 더 많은 컨테이너를 띄울 수 있음
• 실제로 테스트 기간동안 하나의 머신에 수십개의 컨테이너를 띄우기도 했음
60. chroot
• chroot = change root directory
• Chroot is an operation that changes the apparent root directory for
the current running process and their children. A program that is run
in such a modified environment cannot access files and commands
outside that environmental directory tree. This modified environment
is called a chroot jail.
(C) Warner Bros., 1999
86. Running a Docker Image
• docker run postgres
• docker run postgres:9.4
• docker run -d postgres
• docker run -d -p 5432:5432 -e ENV=value postgres
• docker run -i -t postgres /bin/bash
87. Running a Docker Image
• docker run postgres
• docker run postgres:9.4
• docker run -d postgres
• docker run -d -p 5432:5432 -e ENV=value postgres
• docker run -i -t postgres /bin/bash
이미지 이름만으로 실행, 암시적으로 최신 버전
88. Running a Docker Image
• docker run postgres
• docker run postgres:9.4
• docker run -d postgres
• docker run -d -p 5432:5432 -e ENV=value postgres
• docker run -i -t postgres /bin/bash
이미지 이름과 버전을 명시해서 실행
89. Running a Docker Image
• docker run postgres
• docker run postgres:9.4
• docker run -d postgres
• docker run -d -p 5432:5432 -e ENV=value postgres
• docker run -i -t postgres /bin/bash
데몬으로 (백그라운드에서) 실행
90. Running a Docker Image
• docker run postgres
• docker run postgres:9.4
• docker run -d postgres
• docker run -d -p 5432:5432 -e ENV=value postgres
• docker run -i -t postgres /bin/bash
포트 매핑 & 환경 변수
91. Running a Docker Image
• docker run postgres
• docker run postgres:9.4
• docker run -d postgres
• docker run -d -p 5432:5432 -e ENV=value postgres
• docker run -i -t postgres /bin/bash 인터랙티브 모드로 실행
95. Docker Container
> Containers that write a lot of data will consume more space than
containers that do not. This is because most write operations consume
new space in the container’s thin writable top layer. If your container
needs to write a lot of data, you should consider using a data volume.
[^1]
[^1]: https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
98. Content Addressability
8b9022a8dfe4 696.9 KB
876fc4769c5a 1,894 KB
27f381189a32 87.49 KB
1a86c4c9077a 353.1 KB
39387babad77 1.327 MB
876fc4769c5a 1,894 KB
32132a7c82e9 1,994 KB
6467734fa93c 2.403 MB
이미지 1 이미지 2
서로 다르게 빌드된 이미지라도 같은 내용을 가진 레이어가 있다면 상호간 공유 가능
99. Dockerizing
• 애플리케이션이 Docker 환경에서 실행될 수 있도록 하는 일
• 입력은 환경 변수로 받고, 출력은 표준 출력으로
(필수는 아니지만 이렇게 하면 일이 여러가지로 쉬워짐)
• 포트 매핑
100. 우리가 빌드한 Docker 이미지들
런타임 환경
k1eco-base
런타임 환경
지형 관리 도구
k1eco-complete
101. 우리가 빌드한 Docker 이미지들
런타임 환경
k1eco-base
런타임 환경
지형 관리 도구
k1eco-complete
CI
102. 우리가 빌드한 Docker 이미지들
지형 관리 도구
런타임 환경
k1eco-base
런타임 환경
지형 관리 도구
k1eco-complete
CI
103. 우리가 빌드한 Docker 이미지들
지형 관리 도구
런타임 환경
k1eco-base
런타임 환경
지형 관리 도구
k1eco-complete
CI
104. 로컬 개발 환경
• 로컬 개발 환경은 갖추어졌다
• 프로덕션 런타임 환경은?
• Docker 이미지는 어디에 저장하지?
105. EC2 Container Service
Life was much simpler when Amazon was just a forest
CC Shawn O’Neil, 2013 <https://www.flickr.com/photos/oneilsh/14601920735>
106. EC2 Container Service (ECS)
• Docker 컨테이너들을 실행하고 관리할 수 있는 환경과 도구를 제공
• 컨테이너를 실행하기 위해서는 EC2 인스턴스가 필요
• Docker 이미지를 저장할 수 있는 레지스트리 서비스인 ECR을 제공
107. Container Instance
• Docker 이미지가 실행되는 가상머신
• Docker 실행 환경 + ECS 데몬
• 개별 컨테이너 인스턴스에 신경쓰지 않고 Docker 컨테이너만 실행할 수 있는
서비스였으면 좋았겠지만…
Docker 엔진의 일부 동작이 루트 권한을 요구하기 때문에 보안상의 이유로 그
렇게 하기 어렵지 않았을까 하는 추측
108. Cluster
• EC2 컨테이너 인스턴스를 묶는 논리적 그룹
• 한 개 이상의 EC2 인스턴스로 구성
• 각 지역마다 고유함(region-specific)
109. Task Definition
• Docker 컨테이너의 속성을 정의하는 JSON 문서
• CPU, 메모리 요구 사항, 포트 매핑, 저장소 마운트, 환경 변수 정의, 컨테이너
이름 지정, 다른 컨테이너와 연결 등
• 많은 경우에 Docker 이미지 ≠ 수행하고자 하는 일
110. Task Definition
ECS
Override
• Env. variables
• Port mappings
• Command
Task Definition
Image excerpted from http://plainicon.com/download-icon/50348/docker
Container
111. Task Definition
ECS
Override
• Env. variables
• Port mappings
• Command
Task Definition
Image excerpted from http://plainicon.com/download-icon/50348/docker
Container
X
112. Task Definition
ECS
Override
• Env. variables
• Port mappings
• Command
Task Definition
Image excerpted from http://plainicon.com/download-icon/50348/docker
Container
X
113. Task Definition
ECS
Override
• Env. variables
• Port mappings
• Command
Task Definition
Image excerpted from http://plainicon.com/download-icon/50348/docker
Container
X
114. Docker 이미지를 어디에 저장하지? ➔ ECR
• EC2 Container Registry
• 아마존에 의해서 관리되는(fully-managed) Docker 이미지 저장소 서비스
• 인증 절차를 제외하고는 도커 허브(Docker Hub)와 동일한 방법으로 이용
• (2016년 4월) 현재는 버지니아 지역(us-east-1)에서만 이용 가능
115. ECS 클러스터와 ECR이 같은 지역에 있어야 하는 줄 알았어…
그래서 도쿄-버지니아 VPC간을 연결하는 VPN 망 구성
하지만 ECS 클러스터가 버지니아 이외의 지역에 있어도 된다는 것을 나중에 깨달음
VPN
Tokyo VA
116. 다소 먼 길을 돌아왔지만
• 미래에는 다른 지역에도 <야생의 땅: 듀랑고>를 런칭할 계획도 있으니, 지역간
VPN 구축 작업이 시간 낭비는 아니었음
117. 어부지리로 비용 절감
• c4.xlarge, 온-디맨드 인스턴스 기준
• 도쿄: $0.265/hr
• 버지니아: $0.209/hr
• 27% 차이
118. 어부지리로 비용 절감
• 일주일간의 베타 테스트 기간동안 다양한 타입의 인스턴스를 켜놓았는데
• c4.xlarge 기준으로 인스턴스당 $9.408 절약 (1년이면 $491)
122. 지형 배포 Recap
• 지형 데이터 생성
• 지형 파일 후처리
• 지형 파일을 Git 저장소에 커밋 & 푸시
• 서버 코드 저장소에도 반영
123. 지형 배포 Recap
• 지형 데이터 생성
• 지형 파일 후처리
• 지형 파일을 Git 저장소에 커밋 & 푸시
• 서버 코드 저장소에도 반영
이 부분을 좀 개선할 수는 없을까
124. We’ve been abusing Git
• Git은 바이너리 파일을 다루기에 적합하지 않음
• 지형을 추가, 수정할수록 히스토리가 걷잡을 수 없이 커지는 문제
• 지형 파일 저장소를 서버 코드 저장소의 서브모듈 형태로 관리, 사용하지 않는
지형까지 모두 체크아웃
• Docker 이미지를 빌드할 때에도 모든 지형이 다 들어가기 때문에 자원 낭비
지형 관리 도구가 서버 코드를 포함하고, 서버 코드 저장소가 지형 저장소를 포함하고 있기 때문에…
126. 지형 배포 시스템 개편
• 지형 파일을 Git 저장소에 저장
• 서버 코드 저장소에서 서브모듈로 지형 저장
소를 참조
• 서버 노드마다 모든 지형 파일을 다 가지고
있음
2세대1세대
• 지형 파일을 AWS S3에 저장
• 서버 설정 파일에 저장된 지형 ID를 참조
• 실제로 사용하는 지형만 그때그때 받아옴
127. 지형 배포 2세대
• 지형 데이터 생성
• 지형 파일 후처리
• 지형 파일을 지형 저장소(S3)에 올리기
• 서버 코드 저장소에도 반영
128. 지형 배포 2세대
• 지형 데이터 생성
• 지형 파일 후처리
• 지형 파일을 지형 저장소(S3)에 올리기
• 서버 코드 저장소에도 반영
이 과정을 자동화
136. 지형 배포 자동화 시스템
CloudWatch
ECS
S3
Lambda
SQS
지형 파일
지형 배포
137. Simple Storage Service (S3)
• 오브젝트 스토리지
• 주로 파일을 저장하는데 사용
• 상당수의 POSIX 파일시스템 시맨틱을 제공하지는 않지만,
높은 확장성(scalability)을 제공
• Object versioning
• Multi-regional replications ➔ high-availability
139. 지형 배포 자동화 시스템
CloudWatch
ECS
S3
Lambda
SQS
지형 파일
지형 배포
140. Lambda
• (사용자가 따로 서버를 마련하지 않고) AWS의 기반 시설에서 코드를 수행할
수 있는 서비스
• Java 8, Node.js 0.10, Node.js 4.3, Python 2.7
141. Lambda
• 명시적으로 호출할 수도 있고
• AWS의 다른 서비스에서 어떤 이벤트가 발생했을 때 트리거
• S3에 파일이 올라오거나
• DynamoDB의 레코드가 업데이트 되거나
• Kinesis 스트림에 데이터가 들어오거나
• CloudWatch Event에서 특정 시간마다 이벤트를 발생시키거나
142. Lambda
• 명시적으로 호출할 수도 있고
• AWS의 다른 서비스에서 어떤 이벤트가 발생했을 때 트리거
• S3에 파일이 올라오거나
• DynamoDB의 레코드가 업데이트 되거나
• Kinesis 스트림에 데이터가 들어오거나
• CloudWatch Event에서 특정 시간마다 이벤트를 발생시키거나
우리는 이것을 이용
143. Lambda
• 여러가지 제한들
• 최대 수행 시간: 300초 (5분)
• 코드 패키지 최대 크기: 250MB
• 사용할 수 있는 디스크 공간: 512MB
• (다른 제한들도 많지만, 공간이 협소하니 자세한 내용은 AWS 문서를 참고)
• 메모리 사용량, ms 단위로 측정된 수행 시간을 기준으로 과금
144. Lambda
• 오래 걸리거나 자원 사용량이 많은 코드 (X)
• Lambda에서 직접 처리하는 대신 ECS 태스크를 띄우기 (O)
145. 지형 배포 자동화 시스템
CloudWatch
ECS
S3
Lambda
SQS
지형 파일
지형 배포
146. Simple Queue Service (SQS)
• 분산 메세지 큐 서비스
• 신뢰성 있는 메세지 전달 보장
• 높은 확장성(scalability), 높은 가용성(availability)
147. Simple Queue Service (SQS)
Producer ConsumerB U F F E R 0
Producer
Producer
Consumer
Consumer
148. 지형 배포 자동화 시스템
CloudWatch
ECS
S3
Lambda
SQS
지형 파일
지형 배포
149. CloudWatch
• AWS의 여러가지 자원을 모니터링 할 수 있는 서비스
• 각 서비스에 대한 여러가지 지표(metrics)들을 제공,
사용자 정의 지표도 가능
• 로그 수집, 알람 기능
150. 자동화 된 지형 파일 배포
• 로컬 가상머신에 지형 파일을 준비
• 지형 배포 명령어를 수동으로 수행
• 서버 코드 저장소에 변경사항 반영
• 프로그래머의 개입이 필요
자동화 시스템기존 시스템
• 지형 파일을 S3에 업로드
• S3이벤트 트리거에 의해서 자동으로 지형
배포 태스크 실행
• 처리된 지형 파일들을 S3에 저장
• 프로그래머가 필요 없음
우리의 일자리가 위험…읍읍
151. 자동화 된 지형 파일 배포
지형 파일 올리기 지형 파일 후처리 지형 저장소에 커밋 서버 저장소 업데이트
지형 파일 올리기
지형 제작자 프로그래머 프로그래머 프로그래머
지형 제작자
지형 파일 후처리 지형 저장소에 업로드
자동화 전
자동화 후
152. 그러던 어느날
• CI 머신에서 디스크 용량 부족 오류 메세지가 뜨기 시작
• 디스크 사용량은 50% 미만이라 당황(!)
• 알고보니 파일 개수가 많아서 사용 가능한 inode를 모두 소진
• 몇년마다 한 번씩 겪는 문제라 매번 낚임. 오류 메세지를 수정해서 리눅스 커널
패치를 보내볼까…
153. 너무 많은 파일 개수
• 지형 개수 = 약 1,000개 (미사용 지형 포함; 베타테스트 시작 전 갑자기 많아짐)
• 지형별 파일 개수 = 지형의 크기에 따라서 1,000-400,000개
• 총 파일 개수 = 약 1,300,000
• CI가 다섯번만 돌면 inode 모두 소진
154. 해결책: .zip으로 압축하자
• 하나의 지형당 파일 하나
• 지형 배포 코드, 서버 코드에서 지형 파일 읽어오는 부분만 재빠르게 수정
• 더이상 안 쓰는 지형 파일도 지우자
155. 또다른 문제점: .zip 파일 성능 병목
• 파일 개수가 많다보니 .zip 파일을 열기 위해서 많은 메모리를 사용
• 파일 색인을 위한 트리 구조를 메모리에 가지고 있기 때문
156. 해결책: 전용 포맷을 만들자
• 지형 속성별(군계, 강, 호수, 바다, 온도, 습도, 랜드마크 등) 파일 한 개
• 청크 좌표만 가지고 바로 읽어올 수 있는 고정 크기 파일
• Sparse data일때 용량 낭비가 있지만, 스토리지는 싸니까 괜찮아!
158. 생태계 시뮬레이션 자동화
플레이어들이 나무를 마구 베어도 걱정 없어요
Image excerpted from https://en.wikipedia.org/wiki/Computer_simulation#/media/File:Typhoon_Mawar_2005_computer_simulation_thumbnail.gif
164. 시스템 구조 - 주기적으로 자연 상태 파악
LambdaCloudWatch Events
165. 시스템 구조 - 주기적으로 자연 상태 파악
ECSLambdaCloudWatch Events
Parkranger
166. 시스템 구조 - 주기적으로 자연 상태 파악
ECSLambda
SQS
CloudWatch Events
Parkranger
167. 시스템 구조 - 주기적으로 자연 상태 파악
ECSLambda
SQS
CloudWatch Events
CloudWatch Events Lambda ECS
Parkranger
Gardener
Gardener
Gardener
Gardener
…
168. 시스템 구조 - 주기적으로 자연 상태 파악
ECSLambda
SQS
CloudWatch Events
CloudWatch Events Lambda ECS
Parkranger
Gardener
Gardener
Gardener
Gardener
…
169. Parkranger, Gardener
지형 관리 도구
Parkranger
(task definition)
지형 관리 도구
Gardener
(task definition)
• Parkranger
• 섬의 자연 상태를 조사
• 일정 수준 이상 훼손되었을 경우 생태계 시뮬레이션 작업 요청
• 정원사
• 큐에서 시뮬레이션 작업 요청 받아옴
• 작업 요청대로 시뮬레이션 실행
+
+
170. 선택적으로 자연 상태 파악
• 사람의 손이 닿지 않은 곳이라면 굳이 조사할 필요 없음
• 채집 활동이 활발한 섬 위주로 자연 상태 파악
183. Supply & Demand Mismatches
시간
채집 활동 처리 용량
잉여 처리 용량
➔ 비용 낭비
부족한 처리 용량
➔ 부정적 사용자 경험
184. Supply & Demand Mismatches
시간
채집 활동 처리 용량
잉여 처리 용량
➔ 비용 낭비
부족한 처리 용량
➔ 부정적 사용자 경험
넥슨은 어서 갈대를 뿌려라!
185. ECS 클러스터 오토 스케일링
• CPU, 메모리 사용량 등 다양한 지표
• 지표에 따라 EC2 인스턴스의 수를 조절
하여 수요 변화에 탄력적으로 대응
• 동시 접속자, 채집된 자연물의 수와 같
은 게임 내 지표를 참조할수도…
186. Amazon Simple Workflow Service (SWF)
• Amazon SWF helps developers build, run, and scale background
jobs that have parallel or sequential steps. You can think of Amazon
SWF as a fully-managed state tracker and task coordinator in the
cloud.[^1]
• If your app's steps take more than 500 milliseconds to complete,
you need to track the state of processing, and you need to recover
or retry if a task fails, Amazon SWF can help you.
[^1]: https://aws.amazon.com/swf/
187. 스팟 인스턴스를 이용한 비용 절감
• 아마존에서 미사용(unused) 컴퓨팅 자원을 싸게 파는 일종의 경매 시스템
• 수요와 공급에 따라서 가격이 실시간으로 변화
189. 스팟 인스턴스를 이용한 비용 절감
• 일주일간의 테스트 기간동안 고성능 인스턴스들을 원래 가격의 15-20% 수준
에 사용
• 특정 인스턴스 타입에 지불하고자 하는 최대 가격을 제출하고 그 가격이 시장가
보다 높거나 같으면 인스턴스 사용, 시장 가격보다 낮아지면 인스턴스가 꺼짐
• 인스턴스가 꺼졌을 때 적절히 대응할 수 있는 소프트웨어 아키텍처가 필요
190. 지형 런타임 공급
• 지형을 미리 제작하고 배포하는 것은 과도기적 해결책
• 우리의 꿈은 빌드 타임에 지형을 공급하는 것이 아니라 런타임에 공급하는 것
191. 지형 런타임 공급
지형 1
지형 2
지형 n
서버 1
서버 2
서버 3
서버 n
…
오늘 새로운 지형을
만들어볼까?
지형 제작 도구
지형 배포 도구
지형 풀(pool) 서버 코드 업데이트 없이
필요할때마다 지형 꺼내 쓰기