[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버Heungsub Lee
NDC14에서 발표한 "[야생의 땅: 듀랑고] 서버 아키텍처" 세션의 슬라이드입니다.
슬라이드에 설명이 많지 않은데, 디스이즈게임에서 발표 내용을 잘 정리해주었습니다. 기사도 함께 보시면 좋을 것 같습니다.
http://www.thisisgame.com/webzine/news/nboard/4/?n=54955
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
서비스 런칭을 위해 라이온하트와 카카오게임즈가 어떻게 최적 성능의 인스턴스를 선택하고, Windows 운영 체제를 최적화하며, 왜 Amazon Aurora를 기본 데이터베이스로 채택하였는지를 설명합니다. 또한, 출시부터 운영까지의 과정에서 MMORPG가 어떻게 AWS 상에서 설계되고, 게임 서버 성능을 극대할 수 있었는지에 대해 전달해드립니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
멀티플레이어 게임을 서비스하는 데 필요한 게임 장르별 백엔드 아키텍처에 대한 설명해 드립니다. 기본적인 게임의 상태 동기화 개념과 서버 구성에 관한 이야기, 게임 클라이언트 엔진(Unity, Lumberyard, Unreal Engine 등)에서 제공하는 복제 프레임워크를 통하여 손쉽게 게임 서버를 만드는 방법에 대한 내용을 다룹니다. 또한, 이렇게 만들어진 게임 서버를 Amazon GameLift라는 클라우드 서비스를 통해 DevOps형태의 비용 효율적으로 서비스하는 방법에 대해 소개합니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
멀티플레이어 게임을 서비스하는 데 필요한 게임 장르별 백엔드 아키텍처에 대한 설명해 드립니다. 기본적인 게임의 상태 동기화 개념과 서버 구성에 관한 이야기, 게임 클라이언트 엔진(Unity, Lumberyard, Unreal Engine 등)에서 제공하는 복제 프레임워크를 통하여 손쉽게 게임 서버를 만드는 방법에 대한 내용을 다룹니다. 또한, 이렇게 만들어진 게임 서버를 Amazon GameLift라는 클라우드 서비스를 통해 DevOps형태의 비용 효율적으로 서비스하는 방법에 대해 소개합니다.
머신러닝 및 데이터 과학 연구자를 위한 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 )
HTTP/2도 잘 모르는데 벌써 HTTP/3? (2020/4/23) (Korean and English)Junho Choi
2020/4/23 IT 인프라 엔지니어그룹 밋업 발표 https://festa.io/events/973
2nd half of the slides are in English. This is a updated version from https://www.slideshare.net/InfraEngineer/meetup3rd-http2-http3
사례들로 알아보는 컨테이너, 언제 어떻게 쓰면 좋을까? – 김성수 AWS 솔루션즈 아키텍트, 허준 AWS 어카운트 매니저, 이창명 선데이토...Amazon Web Services Korea
컨테이너를 활용할 수 있는 Workload는 정해져 있는 걸까? 이제는 주변에서 쉽게 보고 들을 수 있는 컨테이너, 하지만 정작 내가 쓰려면 어떻게 써야 할지 감을 잡기 어려운 것도 사실이죠. 유명 게임, 웹 서비스에서 컨테이너를 어떻게, 왜 쓰게 되었는지를 알아봅니다. 그리고 컨테이너에 올리는 작업의 특성을 파악하면 활용할수 있는 팁들까지, 실사례를 통해서 알아봅니다!
Openshift 활용을 위한 Application의 준비, Cloud Nativerockplace
What is Cloud-native - DevOps, MSA and Cloud-native: Openshift 활용을 위한 Application의 준비, Cloud Native
*웨비나 다시보기 영상 바로가기:
https://www.youtube.com/watch?v=tzSBS-vki6w
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 방법론 공유)
Similar to Quic을 이용한 네트워크 성능 개선 (20)
4. 4
쿠키런 by 데브시스터
즈
쿠키런 for Kakao LINE COOKIERUN Cookie Run: OvenBreak
• 2016년 10월 27일 출시 예정
• 글로벌 원 서버 / 원 빌드
• 일본, 태국, 대만 등에서
6000만 다운로드 돌파
• 네트워크 끊김에 대한
CS 꾸준히 접수
• 한국에서 2,600만 다운
로드, 최고 300만 DAU
기록
• 한국의 탄탄한 모바일
망을 기반으로 안정적으
로 서비스 중
9. 9
Issues in HTTP/1.1
• Head-of-line blocking (HoL)
• Single request per connection
• Request must be responded in order (FIFO)
• Not optimized well
• Uncompressed headers
• Redundant headers
• Lack of Server-side push
10. 10
SPDY & HTTP2
• Multiplexed streams
• Multiple streams over single TCP connection
• Request Prioritization
• HTTP header compression
• HPACK format
• Huffman code
• Server Push
22. 22
구글의 목표
• 오늘날의 인터넷 세상에 바로 적용 가능할 것
• 통신 과정의 Latency를 개선할 것
• Packet Loss로 인한 HOL 문제를 해결할 것
• TCP의 혼잡 제어 알고리즘을 개선할 것
• TLS 이상으로 안전할 것
• Mobile 환경에서 Cellular <=> Wifi 사이의 마이그레이션이 일어나도 잘 동작할 것
27. • Pluggable Congestion Control Algorithm
• Based on TCP cubic
• Pacing based on bandwidth estimation
• Equivalent to 2 TCP connection
27
QUIC Congestion Control
http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf
30. 30
초기 목표
• 빠르게 프로토타이핑한 후 정말로 효과가 있는지 검증
• 한 가지 이상의 다른 언어와 잘 결합할 수 있는 형태로 구현 (Go? Python? Java? Rust?)
• 멀티코어를 완전히 활용해서 실제 Production에 사용 가능한 수준의 RPS로 최적화
• 현재 제공중인 서비스에 Transparent 하게 적용할 수 있는 형태여야 함
• QUIC 적용을 위해 모든 인프라와 클라이언트를 뜯어 고쳐야 한다면 사용할 수 없다!
• 큰 공수 없이 유지/보수 가능해야 함
• QUIC은 아직도 매우 활발히 변화가 일어나는 프로토콜 (1년에 메이저 버전 3~4개 릴리즈)
• 메이저 릴리즈 될 때마다 새로 구현해야 하면 매우 곤란
32. 32
Chromium Project
• Toy Server / Toy Client / Chrome 브라우저를 이용해 동작 확인 가능
• Not performant at scale
• 구글에서 사용하는 서버 구현체는 아직도 미공개
• Event Loop, Multi-threading, I/O 등등 구현 필요
“Chromium 위에 직접 구현해서 붙여볼까…?”
34. 34
libquic / goquic
• libquic
• Chromium codebase에서 주기적으로 sync
• Python 스크립트와 자체 패치 시스템을 이용해 Dependency 최대한 제거
• goquic
• Go 언어로 만든 libquic binding
• 메인 로직의 경우 libquic의 C++ class를 cgo로 사용 => 유지보수 최소화
• 멀티쓰레딩, GC, Non-blocking I/O 등 구현시 Golang의 장점을 살릴 수 있음
36. 36
현재 알려진 서버 구현
체• GoQuic: Linux나 Mac, FreeBSD 환경에서 구동할 수 있는 Reverse Proxy
• https://github.com/devsisters/goquic/
• Docker Image로도 제공: http://devsisters.github.io/goquic/
• quic-go: Pure Go Implementation
• https://github.com/lucas-clemente/quic-go
• Caddy: Web Server like Apache, nginx, … implemented in Golang
• https://github.com/mholt/caddy
• QUIC support based on quic-go
37. 37
현재 알려진 서버 구현
체
• 치트키: Google App Engine을 사용하면 자동으로 QUIC 통신이 가능함
39. 39
서비스에 적용하기 - 서
버• Load Balancer에 UDP support가 되지 않는 경우 DNS RR 기반으로 부하 분산 (예: AWS)
• 외부에서의 장애 감지 로직과 Failover Plan이 꼭 필요
• QUIC 서버의 경우 대부분 CPU가 병목일 만큼 연산량이 많은 편
40. 40
서비스에 적용하기 - 클라이언트
• Android: Cronet (https://chromium.googlesource.com/chromium/src/+/master/components/cronet)
• JNI를 통해 C++쪽 네트워크 스택을 이용할 수 있는 형태
• ICS 이하 기기 지원 X, ARMv6 기기 지원 X
• 파편화로 인해 특정 플랫폼에서 크래시 나는 경우가 종종 있음
• 실제로 겪은 예: NEON 미지원 기기(Tegra 칩셋) 에서 100% 크래시
• 디바이스 커버리지 위주로 꼼꼼한 테스트 필요
• Crash Analytics
• 기기/OS/칩셋 등 공통점 파악
• Chrome 쪽 문제인 경우: crbug.com
• 우리 쪽 문제인 경우: 대부분 race condition
41. 41
서비스에 적용하기 - 클라이언트
• iOS: CrNet (https://chromium.googlesource.com/chromium/src.git/+/master/ios/crnet/)
• iOS 기본 네트워크 스택을 교체하는 형태로 작동
• Android에 비해 큰 문제는 없는 편
• Obj-C ARC(automatic reference counting) 사용하지 않으므로 MRR로 변경 필수
• Android/iOS 공통으로, static library 빌드와 실제 app 빌드시 파라미터를 맞추는 작업이 매우 중
• 특히 -DNDEBUG 플래그 => 수많은 원인 모를 크래시의 주범
• no-RTTI가 Default => C++ 프로젝트에서 RTTI 사용시 수동으로 켜줘야 함
• https://omahaproxy.appspot.com/ 를 기준으로 stable chrome version에 맞추기
42. 42
Alternate Protocol
“ 이 서버는 QUIC을 지원합니다!
만약 이 클라이언트가 QUIC 통신을 할 줄 안다면,
udp:443 포트로 오세요! ”
•첫 통신의 경우 평범한 HTTP를 이용해 Negotiation하고, 그 다음 요청부터 QUIC으로 접속
•Cronet에선 CronetEngine.addQuicHint 을 통해 Hint를 추가해두면 QUIC부터 시도
오늘 발표의 주제는 ... 인데요. 먼저 저희가 왜 네트워크 성능에 ... , QUIC이 문제를 어떻ㄱ ㅔ해결해 주는지, 실제로 유의미한 효과를 얻었는지에 대해 실제 흐름을 따라가면서 이야기해보도록 하겠습니다.
먼저 저희가 왜 네트워크 스택의 개선에 관심을 가지게 되었고 어떻게 QUIC을 접하게 되었는지에 대해 간단히 말씀드리겠습니다.
모두들 아시겠지만, 데브시스터즈는 …
쿠키런 for Kakao 소개
LINE COOKIERUN 소개.
네트워크 끊김에 대한 CS가 매달 접수됨. 여러 가지 원인 발견.
오븐브레이크 소개, 글로벌 마켓 대상, 글로벌 원 서버.
먼저 일반적인 모바일 게임의 구조에 대해서…
특히 대형 IDC에 서버를 고정적으로 유지하기 어려운 중소규모 팀에서는, AWS/GCP ..
서머너즈워
CR
COC
neighbor,
라우팅을 빙 돌려서
DNS cache이슈
ISP에서 하는 이상한 짓들, 자기들맘대로 캐시를 한다거나
User-agent, Host, Accept
이미지 스프라이트 / 도메인 샤딩 / script minimize
가장 큰 문제는, 낡았다는 것
Emulation에 의한 결과임
AT&T
아예 링크가 끊어지거나 약한 상황은 혼잡 상황이 아닌데 혼잡으로 인지
유선망이니까..
가장 중요한 것은 바로 이것인데요. 물론 Transport layer에서 기존의 TCP나 UDP를 대체하면서 이러한 문제를 개선할 수 있는 새로운 프로토콜을 제안하고, 구현하는 방식으로 해결할 수도 있습니다.
실제로도 그런 시도에서 표준화가 진행중인 프로토콜들이 여러개 있다 -> Multipath TCP라거나, SCTP라거나 ….
이런 프로토콜의 결정적인 문제는 Kernel 서포트가 필요하다는 것. 서버, 클라이언트 뿐만 아니라 전송 과정의 라우터, 스위치, 공유기, ….
물론 이런 과정들은 나름대로 의미가 있으나, 빠르게 iteration 하고 결과를 보기엔 부적합
가장 먼저 들여다봤던 코드는 Google Chrome 브라우저의 모태가 되는 Chromium 프로젝트였습니다.
QUIC 프로토콜 자체가 이 프로젝트에서 출발했고, 저희가 쓰는 구현체나 다른 모든 구현체의 구현 방식도 사실상 Chromium의 것을 따라서 쓰고 있는데요.
홈페이지에 들어가보면 장난감 서버와 클라이언트 구현체가 있고, 실제로 장난감 서버를 띄워 놓고 크롬 브라우저를 이용해 동작을 확인할 수도 있었습니다.
하지만 실제로 사용하기에는 정말 동작 확인만 가능한 정도로 구현되어 있고, 무엇보다 Production 수준에서 제대로 최적화되어 있지 않아서, 충분한 성능이 나오지 않았습니다.
구글에서 실제로 사용하는 구현체는 아직 공개되지 않았는데요. 구글 관련 서비스나 구글 클라우드 인프라에 제공되는 Google Frontend라는 프로그램에 서버 구현체가 내장되어 있는 것으로 알려져 있습니다.
구글 관계자에 의하면 Toy server와 크게 다르지는 않다고 하는데요. 구현해야 할 것들은 어쩌구 저쩌구
저희는 처음에는 이 구현체를 바탕으로 저희만의 Reverse Proxy를 구현하는 것을 생각했었는데요.
이 사진은 quic_connection이라는 하나의 클래스를 사용하기 위한 dependency들의 어쩌구 저쩌구…
golang
대부분 우리쪽 문제
심지어 NDEBUG 플래그 관련한 문제는 디버그 모드에선 잡히지도 않음..
iOS는 상대적으로 훨씬 깔끔한 편
유닛테스트를 참고할 것 거의 대부분의 메소드에 달려 있음
또 하나 중요한 부분은 1초가 넘어가는 비중인데요. 기존 방식의 경우 1초가 넘어가는 통신이 전체의 5%가 넘습니다. 반면에 QUIC의 경우 1초가 넘어가는 통신은 1% 미만입니다.
90% 가로선 하나
또 하나 중요한 부분은 1초가 넘어가는 비중인데요. 기존 방식의 경우 1초가 넘어가는 통신이 전체의 5%가 넘습니다. 반면에 QUIC의 경우 1초가 넘어가는 통신은 1% 미만입니다.
90% 가로선 하나