Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference

11,548 views

Published on

부제: HTTPS 만 잘 알면 모바일 게임이 빨라진다?

Published in: Technology
  • Be the first to comment

KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference

  1. 1. HTTPS로 모바일 게임 서버 구축한다는 것 KOREA GAMES CONFERENCE 2016
  2. 2. LOADCOMPLETE 강연자 자기소개 ▸김웅룡 (Jin Xionglong) ▸ 로드컴플릿 (주) ▸<크루세이더 퀘스트> 스핀오프 신작 <라이드 제로> 메인 서버 개발자 ▸<크루세이더 퀘스트> 메인 서버 개발자 ▸<디스코판다> 메인 서버 개발자 ▸중국의 로컬정보 포탈사이트 58둥청(58.com) ▸검색엔진 개발과 DevOps
  3. 3. 부제 ▸HTTPS 만 잘 알면 모바일 게임 서버가 빨라진다?
  4. 4. ▸“뻥치지 마! ▸빠른 서버 만들고 싶으면 누가 HTTP 를 쓰겠냐!”
  5. 5. WHY HTTP? ▸모바일 게임들에서 HTTP 를 사용하는 이유들 (이미 많이 언급되고 공유된 내용) ▸안정적인 인터넷 연결을 가정하기 어렵고 ▸(얼마전까지만 해도) (또는 글로벌 환경에서) ▸대역폭 (bandwidth) 도 이상적이지 않고 ▸데이터 사용량 압박도 있고 ▸배터리 사용량 압박도 있고 ▸모바일 특성상 유저 인터랙션도 제한적이고 ▸가끔 글로벌 원서버의 요구도 있고 하여
  6. 6. WHY HTTP? ▸결과적으로: ▸게임 만들 때 아예 “항시 연결” 과 “빠 른 서버 응답” 이 필요없게 만드는 경 향이다
  7. 7. WHY NOT HTTP? ▸하지만 시대가 달라졌다. HTTP를 사용하지 않는 모바일 게임 도 많아졌다 ▸장르상의 필요로 한 경우를 제외하고라도 (MOBA, FPS 등 실시간 컨텐츠) ▸단순히 응답속도 개선 (서버 레이턴시 개선) 을 통해 유저 경험을 향상시키기 위해 HTTP 사용을 포기하기도 한다
  8. 8. 하지만 HTTP 포기는 대가가 따른다 ▸소켓 게임 서버 VS 웹 애플리케이션 서버 (WAS): ▸개발 생산성, 다른 말로, 용이도, 편이성 ▸믿고 따르는 웹프렘워크들의 MVC, ORM… ▸안전성 (무상태라서 크래시 위협으로부터 자유로워짐) (안전함이 검증된 리 퀫들의 독립성) ▸수평 확장성 ▸가유지보수성 ▸가용성 ▸이상 모든 것은 맨먼스로 환산될 수 있다
  9. 9. ▸빠른 게임서버를 만들려면 어쩔 수 없이 HTTP 를 포기해야만 하는가?
  10. 10. ▸빠른 게임서버를 만들려면 어쩔 수 없이 HTTP 를 포기해야만 하는가? ▸아니다
  11. 11. 본질로 회귀해보자 ▸게임에서의 데이터 ▸기획 데이터 ▸플레이 데이터 (캐릭터 좌표, 수중의 패 등) ▸유저 데이터 (유저의 재화, 무기 리스트 등) ▸기준 ▸데이터 성격 | 업데이트 빈도수 | 라이프 사이클 | 데이터 사이즈
  12. 12. 본질로 회귀해보자 ▸HTTP vs TCP? ❌ ▸HTTP vs Binary Protocol? ❌ ▸유상태 vs 무상태? O
  13. 13. 본질로 회귀해보자 ▸레이턴시와 스루풋에 영향주는 가장 큰 요인: ▸프로토콜의 차이가 아니라 ▸상태를 관리하는 저장 매개체의 차이! ▸상태관리 엔진! ▸메모리 vs DB 2%5% 82% 11% WAS단 레이턴시 분포 HTTP WAS DB Others 도표 데이터는 대략적인 수량관계만 나타낸다. 특정 애플리케이션에 따라 많이 차이 난다.
  14. 14. 트랜잭션 엔진으로서의 데이터베이스 ▸모바일 게임은 “플레이 데이터” 가 클라에 집중되는 구조 ▸따라서 서버는 “유저 데이터” 에 집중하게 된다 ▸“플레이 데이터” 는 설령 관리가 필요하다고 하더라도 따 로 TCP 서버 (유상태 서버) 를 별도로 붙히는 구조로 ▸“유저 데이터” 에 있어 RDBMS 는 너무 이상적인 상태 관리 엔 진 & 트랜잭션 엔진 ▸(여기서 이상적이란 말은: 사용 편이성, 성능, 안전성 등 여 러가지 방면으로 비추어 봤을 때를 가리킴)
  15. 15. ▸병목지점이 관심을 많이 줘야 하는 부분이다. 병목이 아닌 부 분은 성능적 시점의 관심을 많이 기울이지 않아도 된다 ▸Use SSD! ▸스루풋과 레이턴시에 모두 수량급 향상을 가져온다 ▸Reddit CTO: ▸SSD 를 비싼 디스크가 아니라 저렴한 RAM으로 간 주하라. ▸SSD 는 4배 비싸지만 16배 빠르다. [1] 병목지점은 DB 물론 DBMS 캐시 최적화는 DB 트랜잭션 스루풋에 큰 영향을 줄 수도 있지만, 응용 시나리오가 그런 최적화를 허용하는 경우에만 가능하기에 그런 장치가 없다고 비교하는게 합리적이다
  16. 16. 자 이제 DB 는 해결됐으니 ▸그 다음으로 레이턴시 병목으로 부상하는 건 무엇일까?
  17. 17. 자 이제 DB 는 해결됐으니 ▸그 다음으로 레이턴시 병목으로 부상하는 건 무엇일까? ▸통신!
  18. 18. HTTP 의 문제점 ▸말 한마디 할 때마다 새로 “전화를 걸어야” 한다
  19. 19. HTTP 의 문제점 하이 하이 방가방가 방가방가 TCP 인사법
  20. 20. HTTP 의 문제점 하이 하이 방가방가 방가방가 통신거리가 멀어지면
  21. 21. HTTP 의 문제점 충분히 강합니다 까마귀는 지금도 HTTPS 의 추가 인사 실제 SSL/TLS 핸드셰이킹 스텝은 위 그림보다 복잡하다. TCP 만 1번 왕복, TCP + SSL 은 총 3번 왕복. 자세한 정보는 IETF RFC 5246 참조.
  22. 22. HTTPS 안 쓰면 안 되냐? ▸보안을 위해선 HTTPS. (그중 “S” 의 뜻은 SSL/TLS. (이하 “SSL” 로 대체 .)) ▸서버 authentication ▸세션 맺어주기 ▸패킷 시퀀스 관리 => 패킷 리플레이 공격 방어! ▸암호화 (& 유니크 세션) =>도청 방지 (세션 리플레이 공격 방어) ▸패킷 무결성 검사 => 위변조 방지 ▸어정쩡하게 따라해 SSL 만큼의 보안효과를 흉내내기 어렵다. 걍 HTTPS 를 쓰는게 훨씬 편하고 보안 신뢰성도 높다 서버사이드 인증과 헷갈릴 가능성 때문에 authentication 을 번역하지 않았다. 여기서는 서버의 신분을 인증함을 나타낸다.
  23. 23. ▸그럼 통신 레이턴시는 어떻게 잡아야 하 나?
  24. 24. 해결책 NGINX 가 커넥션들을 다 쥐고있으면 된다 또는 NGINX 에 준하는 기타 솔루션
  25. 25. 해결책 NGINX 가 커넥션들을 다 쥐고있으면 된다 Keepalive 를 3분 이상으로 필요시 10분까지도 또는 NGINX 에 준하는 기타 솔루션
  26. 26. WHY NGINX? Apache 에도 event MPM 이 추가됐다
  27. 27. WHY NGINX? ▸Today NGINX serves more than 146 million sites on the Internet. Successful online services such as Netflix, Dropbox, Pinterest, Airbnb, WordPress.com, Box, Instagram, GitHub, SoundCloud, Zappos, and Yandex, use NGINX as part of their infrastructure. [3]
  28. 28. NGINX 를 ▸웹서버로 사용해 Web front 의 작용을 해주거나 ▸그게 어렵다면* 단순히 Reverse Proxy 의 역할로 사용해주면 된다 ▸덤으로 ▸WAS 는 암호화와 인증 부담이 없어졌다. 이는 큰 부 담을 덜은 셈이다 ▸WAS 는 HTTP 커넥션을 더욱 짧게 쥐게 되었다 ▸L7 로드밸런서 기능 * 주: 예를 들어 웹서버 교체를 할 수 없는 경우
  29. 29. KEEP-ALIVE 는 어떻게 하나? ▸문제는 HTTP keep-alive 기능은 HTTP 1.1 부터 제대로 들어 간다는 거다. HTTP 1.0 의 keep-alive 기능은 설계문제가 있 다 ▸HTTP 1.1 에서 Keep-alive 는 디폴트. 웹서버만 Keep-alive 하 게 하면 됨 ▸새로운 문제가 찾아온다: ▸과연 유니티 엔진의 WWW 클래스는 HTTP 1.1 을 잘 지 원할까?
  30. 30. KEEP-ALIVE 는 어떻게 하나? ▸유니티 문서를 찾아보니 언급 안됨 ▸실제로 실험해본 결과 유니티 엔진의 WWW 클래스는 HTTP 1.1 을 지원 ▸Keepalive 기능도 잘 지원 ▸(UA 로 판단했을 때 libcurl 을 사용) (libcurl 이 MIT/X derivate license 임을 고려하면 신뢰도가 더욱 상승) ▸User-Agent: UnityPlayer/5.4.1f1 (UnityWebRequest/1.0, libcurl/7.46.0-DEV) ▸libcurl 은 풀피쳐 HTTP 클라이언트 라이브러리이다. 신뢰가 간다 ▸설령 클라가 HTTP 1.1 을 지원 안한다고 하더라도 (요즘은 드물지만), 서버단에서 Keep-alive 헤더만 잘 넘기면 keep-alive 할 수 있다
  31. 31. 헤더는 이렇게 ▸NGINX 에서 헤더를 아래와 같이 내려주도록 하면, keep-alive 를 HTTP 버전에 상관 없이 보장할 수 있다. 예시는 5분 ▸Connection: keep-alive ▸Keep-Alive: timeout=300
  32. 32. CHECK POINT: 클라가 유니티 엔진일 경우 ▸NGINX 의 Keepalive 기능만 잘 활용해주면 ▸SSL 이 붙었음에도 불구하고 ▸HTTP 임에도 불구하고 ▸응답 요청 레이턴시가 소켓서버 못지 않게 된다는 놀라운 결 론을 얻게 된다 ▸(같은 무상태 서버 기준) (즉 소켓 무상태 서버도 DB 로 트랜잭션을 처리하는 경우)
  33. 33. 웹서버라서 느릴 수 있는 또다른 요소 ▸HTTP 에는 푸시 매커니즘이 없다. 그래서 안 해도 됐을뻔한 읽기 요청을 과다하게 많이 해야 하는 경우들이 발생한다 ▸예를 들면 우편함 ▸해결할 방법이 없을까?
  34. 34. 타산지석: 웹쪽에서 이러한 문제를 ▸HTTP 에도 푸시 매커니즘이 생겼다 — HTTP/2 ▸하지만 아직은 많이 보급되지 않았다 ▸많이 사용하는 방식 ▸웹소켓 ▸그리고 요즘은 그다지 많이 사용하지 않는 방식: HTTP 롱 폴링
  35. 35. 꼭 웹소켓이 아니어도 ▸게임서버에서는 소켓을 직접 사용해도 된다 ▸웹소켓 장점 ▸웹서버로 처리 가능 (그냥 웹서버에 얹는 방법) (e.g. Node.js) ▸라이브러리가 많다 ▸Python 같은 경우 흔히 인터페이스인 WSGI 는 아예 푸시 매커니즘을 지원하지 않는다. WSGI 가 아닌 다른 인터페이스를 사용하는 방법도 있다 ▸아예 ZeroMQ 같은 메세지 큐를 사용하는 방법도 있다 ▸더 쉬운 방법은 푸시를 전담하는 소켓서버를 따로 두는 방법이다
  36. 36. 파이프라이닝
  37. 37. 파이프라이닝? ▸파이프라이닝이란? 쉽게 표현하자면 ▸한명 갔다 온 후에 다른 한명 보내는 것이 아니라 ▸여러명을 한번에 같이 보내고 같이 돌아오게 ▸목적: 서버 레이턴시 감소 ▸많은 사람들이 HTTP 파이프라이닝이 HTTP/2 의 피쳐라고 잘못 알고있는데, 실은 HTTP 1.1 에 이미 있다. HTTP/2 의것 은 최적화된 버전
  38. 38. 파이프라이닝 ▸또 HTTP/2 에 (잘) 되있는 기능. [4] ▸본 PPT 가 HTTP/2 홍보가 되가는 느낌 ▸ 2015년 표준* 답게 HTTP/2 는 역시 현대적이다 ▸문제는 역시 HTTP/2 가 아직 보급되지 않았다 ▸HTTP 1.1 에서는 어떻게 잘 활용할 것인가? 역시 유니티 엔 진에 달렸는데.. ▸그것보다 쉽고 간단한 방법이 있다: * RFC 7540 in May 2015
  39. 39. API STYLE ▸API Style ▸RESTful: 메소드는 HTTP Method 와 URL 경로에 ▸JSON-RPC-like: 메소드는 HTTP POST body 에 JSON 으로 ▸RESTful 은 파이프라이닝하려면 유니티가 HTTP 파이프라이 닝을 잘 해주길 바랄 수밖에 없다 ▸JSON-RPC-like 은 요청정보가 JSON 이기에 여러개의 요청 을 묶어서 한번에 보낼 수 있다
  40. 40. 온라인게임식의 서버보다 아직도 많이 부족하잖아! ▸프로토콜? Node.js 같은 “요즘” 웹서버는 HTTP 파싱도 네이 티브 모듈로 한다 ▸하지만 프로토콜 따위 짜잘한 요소를 모두 무색하게 만드는게
  41. 41. 온라인게임식의 서버보다 아직도 많이 부족하잖아! ▸프로토콜? Node.js 같은 “요즘” 웹서버는 HTTP 파싱도 네이 티브 모듈로 한다 ▸하지만 프로토콜 따위 짜잘한 요소를 모두 무색하게 만드는게 ▸상태관리 엔진: ▸메모리 vs DB ▸유상태 vs 무상태
  42. 42. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다
  43. 43. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다
  44. 44. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다: ▸마술
  45. 45. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다: ▸마술 연출
  46. 46. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다: ▸마술 연출 ▸0.1 초와 1 초사이* 의 수량급 차이를 연출이 메꿔줄 수 있다 ▸웹서버가 1 초씩이나 걸린다는 말이 아니고, 웹서버 도 0.1 초 안에 여유롭게 들어올 수 있다 * 주: 상기 데이터는 양자를 비교할 의미있는 수치이지 실제 측정치가 아니다. 실제 측정 수치는 애플리케이션에 따라 다르다.
  47. 47. 연출 ▸MSDN: Async 는 반응성을 향상시킨다 ▸비동기 방식은 블락킹 가능성이 있는 행동들에 필요하다 . 예를 들어 애플리케이션이 웹을 액세스할 경우. 웹에 대 한 접근은 가끔 느리고 지연된다. 이런 행동이 동기적인 과정에 의해 블락킹 된다면 전체 애플리케이션은 기다려 야만 한다. 하지만 비동기 작동방식에서는 애플리케이션 이 다른 일들을 계속할 수 있게 된다. [2]
  48. 48. 연출 ▸Python 진영에서도 => ▸Python 이 언제 GUI 프로 그래밍에 쓰였다고 좀 쓰 인다
  49. 49. 연출 ▸그렇다면 연출의 “눈속임”을 어떻게 해야 하는가? ▸여기서 부터는 서버기술 세션의 범위를 벗어남으로 실은 강연 자의 능력범위를 벗어남으로 ▸더이상의 자세한 설명은 생략한다 ▸요즘 이런 사례들도 점점 많이 보인다 ▸가장 유명한 사례는 스타크래프트 1 에서 연출로 반응성 향상 시킨 케이스라고 한다
  50. 50. 금기마법 ▸그래도 더 빨랐으면 하는게 사람 마음이고 서버 프로그래머의 욕심이다 ▸Reddit 같은 초대형 웹사이트들에서 사용하는 방법인데 ▸HTTP 요청은 메세지 큐 쓰기만 하고 DB 트랜잭션 처리 는 HTTP 응답과 별개로 비동기적으로 처리한다 ▸하지만 이로 인해 리스크 모델이 완전 바뀌어버릴 수 있다. 더 이상 “무상태 서비스”라고 할 수 있을지도 모호해진다 ▸이정도 도룡지기(屠龍之技) 는 왕왕 “너무 왔음” (투머치)의 신 호이다
  51. 51. 여기까지 ▸웹 애플리케이션 서버 형태의 모바일 게임 서버를 “빠르게” 만 드는 ▸쉽고 효과적인 방법부터 ▸트릭키한 흑마법까지 살펴봤다 ▸말하고자 하는 포인트는 ▸모바일 게임에 대해 웹서버 또는 무상태 서버로 커버 불가능 을 너무 섣부르게 선고하지 말고, 최대한 이런 최적화 방법을 사용하여 무상태서버의 이점을 충분히 누려보자는데 있다
  52. 52. REFERENCES ▸[1] Reddit: Lessons Learned From Mistakes Made Scaling To 1 Billion Pageviews A Month: http://highscalability.com/blog/2013/8/26/reddit- lessons-learned-from-mistakes-made-scaling-to-1-billi.html ▸[2] Asynchronous Programming with Async and Await (C# and Visual Basic): https://msdn.microsoft.com/ko- kr/library/hh191443(v=vs.110).aspx ▸[3] NGINX Becomes Number One Web Server for Top 10,000 Busiest Websites in the World: https://www.nginx.com/press/nginx-becomes- number-one-web-server-top-10000-busiest-websites-world/ ▸[4] HTTP Pipelining: https://en.wikipedia.org/wiki/HTTP_pipelining
  53. 53. THANK YOU

×