Recommended
More Related Content
What's hot
What's hot (20)
Similar to KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
Similar to KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference (20)
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
- 1. HTTPS로 모바일 게임 서버 구축한다는 것 KOREA GAMES CONFERENCE 2016
- 2. LOADCOMPLETE 강연자 자기소개 ▸김웅룡 (Jin Xionglong) ▸ 로드컴플릿 (주) ▸<크루세이더 퀘스트> 스핀오프 신작 <라이드 제로> 메인 서버 개발자 ▸<크루세이더 퀘스트> 메인 서버 개발자 ▸<디스코판다> 메인 서버 개발자 ▸중국의 로컬정보 포탈사이트 58둥청(58.com) ▸검색엔진 개발과 DevOps
- 3. 부제 ▸HTTPS 만 잘 알면 모바일 게임 서버가 빨라진다?
- 4. ▸“뻥치지 마! ▸빠른 서버 만들고 싶으면 누가 HTTP 를 쓰겠냐!”
- 5. WHY HTTP? ▸모바일 게임들에서 HTTP 를 사용하는 이유들 (이미 많이 언급되고 공유된 내용) ▸안정적인 인터넷 연결을 가정하기 어렵고 ▸(얼마전까지만 해도) (또는 글로벌 환경에서) ▸대역폭 (bandwidth) 도 이상적이지 않고 ▸데이터 사용량 압박도 있고 ▸배터리 사용량 압박도 있고 ▸모바일 특성상 유저 인터랙션도 제한적이고 ▸가끔 글로벌 원서버의 요구도 있고 하여
- 6. WHY HTTP? ▸결과적으로: ▸게임 만들 때 아예 “항시 연결” 과 “빠 른 서버 응답” 이 필요없게 만드는 경 향이다
- 7. WHY NOT HTTP? ▸하지만 시대가 달라졌다. HTTP를 사용하지 않는 모바일 게임 도 많아졌다 ▸장르상의 필요로 한 경우를 제외하고라도 (MOBA, FPS 등 실시간 컨텐츠) ▸단순히 응답속도 개선 (서버 레이턴시 개선) 을 통해 유저 경험을 향상시키기 위해 HTTP 사용을 포기하기도 한다
- 8. 하지만 HTTP 포기는 대가가 따른다 ▸소켓 게임 서버 VS 웹 애플리케이션 서버 (WAS): ▸개발 생산성, 다른 말로, 용이도, 편이성 ▸믿고 따르는 웹프렘워크들의 MVC, ORM… ▸안전성 (무상태라서 크래시 위협으로부터 자유로워짐) (안전함이 검증된 리 퀫들의 독립성) ▸수평 확장성 ▸가유지보수성 ▸가용성 ▸이상 모든 것은 맨먼스로 환산될 수 있다
- 9. ▸빠른 게임서버를 만들려면 어쩔 수 없이 HTTP 를 포기해야만 하는가?
- 10. ▸빠른 게임서버를 만들려면 어쩔 수 없이 HTTP 를 포기해야만 하는가? ▸아니다
- 11. 본질로 회귀해보자 ▸게임에서의 데이터 ▸기획 데이터 ▸플레이 데이터 (캐릭터 좌표, 수중의 패 등) ▸유저 데이터 (유저의 재화, 무기 리스트 등) ▸기준 ▸데이터 성격 | 업데이트 빈도수 | 라이프 사이클 | 데이터 사이즈
- 12. 본질로 회귀해보자 ▸HTTP vs TCP? ❌ ▸HTTP vs Binary Protocol? ❌ ▸유상태 vs 무상태? O
- 13. 본질로 회귀해보자 ▸레이턴시와 스루풋에 영향주는 가장 큰 요인: ▸프로토콜의 차이가 아니라 ▸상태를 관리하는 저장 매개체의 차이! ▸상태관리 엔진! ▸메모리 vs DB 2%5% 82% 11% WAS단 레이턴시 분포 HTTP WAS DB Others 도표 데이터는 대략적인 수량관계만 나타낸다. 특정 애플리케이션에 따라 많이 차이 난다.
- 14. 트랜잭션 엔진으로서의 데이터베이스 ▸모바일 게임은 “플레이 데이터” 가 클라에 집중되는 구조 ▸따라서 서버는 “유저 데이터” 에 집중하게 된다 ▸“플레이 데이터” 는 설령 관리가 필요하다고 하더라도 따 로 TCP 서버 (유상태 서버) 를 별도로 붙히는 구조로 ▸“유저 데이터” 에 있어 RDBMS 는 너무 이상적인 상태 관리 엔 진 & 트랜잭션 엔진 ▸(여기서 이상적이란 말은: 사용 편이성, 성능, 안전성 등 여 러가지 방면으로 비추어 봤을 때를 가리킴)
- 15. ▸병목지점이 관심을 많이 줘야 하는 부분이다. 병목이 아닌 부 분은 성능적 시점의 관심을 많이 기울이지 않아도 된다 ▸Use SSD! ▸스루풋과 레이턴시에 모두 수량급 향상을 가져온다 ▸Reddit CTO: ▸SSD 를 비싼 디스크가 아니라 저렴한 RAM으로 간 주하라. ▸SSD 는 4배 비싸지만 16배 빠르다. [1] 병목지점은 DB 물론 DBMS 캐시 최적화는 DB 트랜잭션 스루풋에 큰 영향을 줄 수도 있지만, 응용 시나리오가 그런 최적화를 허용하는 경우에만 가능하기에 그런 장치가 없다고 비교하는게 합리적이다
- 16. 자 이제 DB 는 해결됐으니 ▸그 다음으로 레이턴시 병목으로 부상하는 건 무엇일까?
- 17. 자 이제 DB 는 해결됐으니 ▸그 다음으로 레이턴시 병목으로 부상하는 건 무엇일까? ▸통신!
- 18. HTTP 의 문제점 ▸말 한마디 할 때마다 새로 “전화를 걸어야” 한다
- 19. HTTP 의 문제점 하이 하이 방가방가 방가방가 TCP 인사법
- 20. HTTP 의 문제점 하이 하이 방가방가 방가방가 통신거리가 멀어지면
- 21. HTTP 의 문제점 충분히 강합니다 까마귀는 지금도 HTTPS 의 추가 인사 실제 SSL/TLS 핸드셰이킹 스텝은 위 그림보다 복잡하다. TCP 만 1번 왕복, TCP + SSL 은 총 3번 왕복. 자세한 정보는 IETF RFC 5246 참조.
- 22. HTTPS 안 쓰면 안 되냐? ▸보안을 위해선 HTTPS. (그중 “S” 의 뜻은 SSL/TLS. (이하 “SSL” 로 대체 .)) ▸서버 authentication ▸세션 맺어주기 ▸패킷 시퀀스 관리 => 패킷 리플레이 공격 방어! ▸암호화 (& 유니크 세션) =>도청 방지 (세션 리플레이 공격 방어) ▸패킷 무결성 검사 => 위변조 방지 ▸어정쩡하게 따라해 SSL 만큼의 보안효과를 흉내내기 어렵다. 걍 HTTPS 를 쓰는게 훨씬 편하고 보안 신뢰성도 높다 서버사이드 인증과 헷갈릴 가능성 때문에 authentication 을 번역하지 않았다. 여기서는 서버의 신분을 인증함을 나타낸다.
- 23. ▸그럼 통신 레이턴시는 어떻게 잡아야 하 나?
- 24. 해결책 NGINX 가 커넥션들을 다 쥐고있으면 된다 또는 NGINX 에 준하는 기타 솔루션
- 25. 해결책 NGINX 가 커넥션들을 다 쥐고있으면 된다 Keepalive 를 3분 이상으로 필요시 10분까지도 또는 NGINX 에 준하는 기타 솔루션
- 26. WHY NGINX? Apache 에도 event MPM 이 추가됐다
- 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. NGINX 를 ▸웹서버로 사용해 Web front 의 작용을 해주거나 ▸그게 어렵다면* 단순히 Reverse Proxy 의 역할로 사용해주면 된다 ▸덤으로 ▸WAS 는 암호화와 인증 부담이 없어졌다. 이는 큰 부 담을 덜은 셈이다 ▸WAS 는 HTTP 커넥션을 더욱 짧게 쥐게 되었다 ▸L7 로드밸런서 기능 * 주: 예를 들어 웹서버 교체를 할 수 없는 경우
- 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. 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. 헤더는 이렇게 ▸NGINX 에서 헤더를 아래와 같이 내려주도록 하면, keep-alive 를 HTTP 버전에 상관 없이 보장할 수 있다. 예시는 5분 ▸Connection: keep-alive ▸Keep-Alive: timeout=300
- 32. CHECK POINT: 클라가 유니티 엔진일 경우 ▸NGINX 의 Keepalive 기능만 잘 활용해주면 ▸SSL 이 붙었음에도 불구하고 ▸HTTP 임에도 불구하고 ▸응답 요청 레이턴시가 소켓서버 못지 않게 된다는 놀라운 결 론을 얻게 된다 ▸(같은 무상태 서버 기준) (즉 소켓 무상태 서버도 DB 로 트랜잭션을 처리하는 경우)
- 33. 웹서버라서 느릴 수 있는 또다른 요소 ▸HTTP 에는 푸시 매커니즘이 없다. 그래서 안 해도 됐을뻔한 읽기 요청을 과다하게 많이 해야 하는 경우들이 발생한다 ▸예를 들면 우편함 ▸해결할 방법이 없을까?
- 34. 타산지석: 웹쪽에서 이러한 문제를 ▸HTTP 에도 푸시 매커니즘이 생겼다 — HTTP/2 ▸하지만 아직은 많이 보급되지 않았다 ▸많이 사용하는 방식 ▸웹소켓 ▸그리고 요즘은 그다지 많이 사용하지 않는 방식: HTTP 롱 폴링
- 35. 꼭 웹소켓이 아니어도 ▸게임서버에서는 소켓을 직접 사용해도 된다 ▸웹소켓 장점 ▸웹서버로 처리 가능 (그냥 웹서버에 얹는 방법) (e.g. Node.js) ▸라이브러리가 많다 ▸Python 같은 경우 흔히 인터페이스인 WSGI 는 아예 푸시 매커니즘을 지원하지 않는다. WSGI 가 아닌 다른 인터페이스를 사용하는 방법도 있다 ▸아예 ZeroMQ 같은 메세지 큐를 사용하는 방법도 있다 ▸더 쉬운 방법은 푸시를 전담하는 소켓서버를 따로 두는 방법이다
- 36. 파이프라이닝
- 38. 파이프라이닝? ▸파이프라이닝이란? 쉽게 표현하자면 ▸한명 갔다 온 후에 다른 한명 보내는 것이 아니라 ▸여러명을 한번에 같이 보내고 같이 돌아오게 ▸목적: 서버 레이턴시 감소 ▸많은 사람들이 HTTP 파이프라이닝이 HTTP/2 의 피쳐라고 잘못 알고있는데, 실은 HTTP 1.1 에 이미 있다. HTTP/2 의것 은 최적화된 버전
- 39. 파이프라이닝 ▸또 HTTP/2 에 (잘) 되있는 기능. [4] ▸본 PPT 가 HTTP/2 홍보가 되가는 느낌 ▸ 2015년 표준* 답게 HTTP/2 는 역시 현대적이다 ▸문제는 역시 HTTP/2 가 아직 보급되지 않았다 ▸HTTP 1.1 에서는 어떻게 잘 활용할 것인가? 역시 유니티 엔 진에 달렸는데.. ▸그것보다 쉽고 간단한 방법이 있다: * RFC 7540 in May 2015
- 40. API STYLE ▸API Style ▸RESTful: 메소드는 HTTP Method 와 URL 경로에 ▸JSON-RPC-like: 메소드는 HTTP POST body 에 JSON 으로 ▸RESTful 은 파이프라이닝하려면 유니티가 HTTP 파이프라이 닝을 잘 해주길 바랄 수밖에 없다 ▸JSON-RPC-like 은 요청정보가 JSON 이기에 여러개의 요청 을 묶어서 한번에 보낼 수 있다
- 41. 온라인게임식의 서버보다 아직도 많이 부족하잖아! ▸프로토콜? Node.js 같은 “요즘” 웹서버는 HTTP 파싱도 네이 티브 모듈로 한다 ▸하지만 프로토콜 따위 짜잘한 요소를 모두 무색하게 만드는게
- 42. 온라인게임식의 서버보다 아직도 많이 부족하잖아! ▸프로토콜? Node.js 같은 “요즘” 웹서버는 HTTP 파싱도 네이 티브 모듈로 한다 ▸하지만 프로토콜 따위 짜잘한 요소를 모두 무색하게 만드는게 ▸상태관리 엔진: ▸메모리 vs DB ▸유상태 vs 무상태
- 43. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다
- 44. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다
- 45. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다: ▸마술
- 46. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다: ▸마술 연출
- 47. 어떡하지 ▸빠르고 강력하고 신뢰성 높고 사용이 편한 트랜잭션 엔진 (RDBMS) 의 대가 ▸어쩔 수 없다 이것마저 해결해줄 궁극기가 있다: ▸마술 연출 ▸0.1 초와 1 초사이* 의 수량급 차이를 연출이 메꿔줄 수 있다 ▸웹서버가 1 초씩이나 걸린다는 말이 아니고, 웹서버 도 0.1 초 안에 여유롭게 들어올 수 있다 * 주: 상기 데이터는 양자를 비교할 의미있는 수치이지 실제 측정치가 아니다. 실제 측정 수치는 애플리케이션에 따라 다르다.
- 48. 연출 ▸MSDN: Async 는 반응성을 향상시킨다 ▸비동기 방식은 블락킹 가능성이 있는 행동들에 필요하다 . 예를 들어 애플리케이션이 웹을 액세스할 경우. 웹에 대 한 접근은 가끔 느리고 지연된다. 이런 행동이 동기적인 과정에 의해 블락킹 된다면 전체 애플리케이션은 기다려 야만 한다. 하지만 비동기 작동방식에서는 애플리케이션 이 다른 일들을 계속할 수 있게 된다. [2]
- 49. 연출 ▸Python 진영에서도 => ▸Python 이 언제 GUI 프로 그래밍에 쓰였다고 좀 쓰 인다
- 50. 연출 ▸그렇다면 연출의 “눈속임”을 어떻게 해야 하는가? ▸여기서 부터는 서버기술 세션의 범위를 벗어남으로 실은 강연 자의 능력범위를 벗어남으로 ▸더이상의 자세한 설명은 생략한다 ▸요즘 이런 사례들도 점점 많이 보인다 ▸가장 유명한 사례는 스타크래프트 1 에서 연출로 반응성 향상 시킨 케이스라고 한다
- 51. 금기마법 ▸그래도 더 빨랐으면 하는게 사람 마음이고 서버 프로그래머의 욕심이다 ▸Reddit 같은 초대형 웹사이트들에서 사용하는 방법인데 ▸HTTP 요청은 메세지 큐 쓰기만 하고 DB 트랜잭션 처리 는 HTTP 응답과 별개로 비동기적으로 처리한다 ▸하지만 이로 인해 리스크 모델이 완전 바뀌어버릴 수 있다. 더 이상 “무상태 서비스”라고 할 수 있을지도 모호해진다 ▸이정도 도룡지기(屠龍之技) 는 왕왕 “너무 왔음” (투머치)의 신 호이다
- 52. 여기까지 ▸웹 애플리케이션 서버 형태의 모바일 게임 서버를 “빠르게” 만 드는 ▸쉽고 효과적인 방법부터 ▸트릭키한 흑마법까지 살펴봤다 ▸말하고자 하는 포인트는 ▸모바일 게임에 대해 웹서버 또는 무상태 서버로 커버 불가능 을 너무 섣부르게 선고하지 말고, 최대한 이런 최적화 방법을 사용하여 무상태서버의 이점을 충분히 누려보자는데 있다
- 53. 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
- 54. THANK YOU
Editor's Notes
- 안녕하세요~ 오늘 <HTTPS 로 모바일 게임 서버 구축한다는 것> 이란 제목으로 발표를 하게 된 김웅룡이라고 합니다.
- 자기소개부터 하자면 저는 원래 중국의 로컬정보 포탈 사이트 오팔둥청에서 검색엔진 개발과 데브옵스의 일을 하다가 게임개발사 로드컴플릿에서 디스코판다, 크루세이더 퀘스트 등 게임의 메인서버 프로그래머로 일하다가 현재는 로드컴플릿의 크루세이더 퀘스트 스핀오프 신작 라이드 제로 메인 서버 프로그래머로 일하고 있습니다.
- 이 강연의 제목은 <HTTPS로 모바일 게임 서버 구축한다는 것> 인데 이 강연에는 부제가 있습니다. < HTTPS 만 잘 알면 모바일 게임 서버가 빨라진다?>
- “뻥치지 마! 빠른 서버 만들고 싶으면 누가 HTTP 를 쓰겠냐!” 음.. 하지만 실제로 모바일 게임에서는 HTTP 를 많이 쓰죠. 즉 웹서버로 서버구축을 많이들 하죠. 왜 그럴까요?
- HTTP 로 만드는데는 장점이 많습니다. 모바일 게임들에서 HTTP 를 사용하는 이유들. 뭐 많이 언급되고 토론되고 공유된 내용이기도 합니다 사실. 모바일 게임에서는 안정적인 인터넷 연결을 가정하기 어렵고. 안끊긴다 라는걸 가정하기 어려운거죠. 얼마전까지만 해도, 또는 지금도 글로벌 환경에서 밴드윗도 이상적이지 않고 데이터 사용량 압박도 있고 배터리 사용량 압박도 있고 모바일 게임의 특성상 유저 인터랙션도. 제한적이죠? 가끔 글로벌 원서버의 요구도 있고 하여
- 결과적으로 게임을 만들 때 아예 항시 연결되어있는 것이 필요 없게, 그리고 아주 빠른 서버응답이 꼭 필요하지 않게. 만들 때 그렇게 만드는 편이었습니다.
- 물론 그렇지 않은 경우도 있죠. FPS 라든가..MOBA 라든가. 즉 장르 자체의 요구상. 웹서버로는 안되겠죠. 시대도 달라졌구요. 그래서 지금은 HTTP 를 안쓰는 모바일 게임도 상당히 많죠. 단순히 서버 로딩 속도 개선, 즉 서버 레이턴시 개선이죠. 를 위해서도 요즘은 소켓서버로 모바일게임 서비스하는 경우도 많습니다.
- 물론 좋지만 HTTP 는 포기하기에는 너무 아쉽죠. 업계에는 “HTTP 는 웹의 디버그 모드다”란 말도 있을 정도입니다. 개발자들은 HTTP 를 좋아하죠. HTTP 포기에는 어떤 대가가 따를까요? 우선 개발 생산성, 그리고 편이성. 여기서 생산성이란 말은 성숙한 웹 프레임워크들의 MVC 패턴. 오브젝트 릴레이션 매핑. 줄여서 오아렘. 그리고 안전성. 웹서버는 안전하고 좋죠. 웬만해서는 안죽죠. Node.js 나 맨날 죽지만, 슈퍼바이저가 모니터링하고 수시로 순식간에 재시작해주기 때문에 안죽는거처럼 보입니다. 설령 크래시가 나도 무상태라 상태를 잃어버리지 않는다. 는 장점. 뭐니뭐니해도 웹서버의 수평 확장성. 성숙 웹프레임워크들의 가이드만 따르면 코드 구조가 심플해서 유지보수성도 좋고. 그래서 가용성도 좋고.
- 이렇게 좋은데 빠른 게임서버를 만들려면 어쩔수 없이 http 를 포기해야만 한다?
- 아닙니다.
- 저는 게임에서의 데이터를 세가지로 나눕니다. 기획데이터, 플레이 데이터, 유저 데이터. 처음 보기에는 근거가 없는 나눔법 같아보이지만, 자세히 보면 근거가 명확합니다. 우선 이 세가지 데이터는 대상도 다르고 용도도 다릅니다. 기획데이터는 기획 내용을 설명하고, 예를 들면 밸런스라든지. 플레이 데이터는 현재 인게임의 플레이 상태를 나타냅니다. MMO에서는 캐릭터 좌표 버프 상태 등등입니다. 유저 데이터는 말그대로 유저의 데이터. 유저의 무기 리스트라든, 인벤토리. 이런겁니다. 라이프 사이클도 다릅니다. 플레이 데이터는 인게임 한판 끝나면 사라지고. 데이터 규모도 다릅니다. 유저 데이터는 데이터 규모가 어마어마하죠. 데이터 갱신 빈도수도 다릅니다. 캐릭터 좌표는 1초에도 여러번 업데이트 되는데, 기획 데이터는 특정 게임 버전 내내 안바뀌죠. 다음 “업데이트” 전까지는.
- 사실 여기서 대결 구도는 HTTP 와 TCP 가 아닙니다. 물론 HTTP 도 TCP 에 기반한거이긴 하지만 여기서는 그런 얘기가 아니라. 로소켓과 http 의 차이가 크지 않다는겁니다. http 와 바이너리 프로토콜의 차이도 아닙니다. 다들 아시다싶이 http 는 텍스트 프로토콜입니다. 이 차이도 크지 않습니다. 유상태와 무상태의 대결구도라고 생각합니다. 왜 이렇게 주장한건지 설명드리겠습니다.
- 오른쪽 파이차트에서 가장 큰 면적을 차지하고있는게 DB 인데 웹애플리케이션서버 즉 전체 와스 단에서 DB 가 레이턴시를 가장 많이 가져간다는 의미인데. 실제 웹서버 개발해보신 분들은 전혀 놀라운 수치가 아니죠. 그래서 레이턴시에 결정적인 영향을 주는 요소가 프로토콜의 차이가 아니라 상태를 관리하는 저장 매체. 또는 다른 말로 상태 관리 엔진의 차이다. 라고 말씀드리는겁니다. 상태 관리 엔진이 서버 메모리인가, 아니면 디비인가, 그 차이가 크다라는거죠.
- 트랜잭션 엔진으로서의 데이터베이스 뭐 게임쪽을 제외하면 거의 디비를 상태관리 엔진으로 써서 이 사실을 설명하는것조차 이상합니다. 당연히 디비 써야 한다는것처럼. 게임에서나 메모리로 상태관리를 하기도 하지 다른데서는 거의 디비죠. 하지만 모바일 게임은 위에서 얘기한 “플레이 데이터” 에 집중하는게 아니라 “유저 데이터” 에 집중하게 됩니다. “플레이 데이터” 는 클라에 집중되죠. 물론 하스스톤같이 턴제의 경우는 플레이 데이터가 서버에 있지만, 그냥 대부분 모바일 게임에서 플레이 데이터는 클라에 있다는 얘깁니다. 서버는 유저 데이터만 신경쓴다면 RDBMS 는 너무 이상적인 상태관리 엔진입니다. 그리고 트랜직션 엔진. 여기서 이상적이란 말은 편이성도 좋고, 안전성도 좋고. 여러가지 방면에서 봤을 때 입니다.
- 프로그램 최적화에서는 이런 법칙이 있습니다. DB 레이턴시가 기타 레이턴시보다 한개 수량급 많다면. 즉 10배 시간을 소모한다면. 다른 부분에서 시간을 조금 단축하는게 전체 시간에 별 차이를 내지 않습니다. 그래서 DB 가 가장 신경써줘야 하는 부분으로 됩니다. SSD 를 써라. 놀라시는 분들도 계시고 너무 당연하다고 생각하시는 분들도 계실 것 같습니다. SSD 좋은지 누가 몰라. 물론 서버 엔지니어링에서는 좋다는걸 논증하고 써야 하죠. Reddit 이라는 외국사이트가 있는데 해외 사이트 많이 보시는 개발자분들이라면 많이들 아실겁니다. 알렉사 랭킹에 의하면 레딧은 전세계 트래픽 24 위의 초대형 웹사이트 입니다. 23 위가 구글 독일이었고, 25 위가 구글 UK 였습니다. 구글 독일과 구글 영국 사이에 있는거죠. Reddit 의 CTO 분, 제레미 에드버그(Jeremy Edberg) 라는 분인데. 웹서비스 구축에서 터득한 경험들을 소개할 때 이런 말을 했습니다. SSD 를 비싼 디스크가 아니라 저렴한 RAM으로 간주하라. 그리고 SSD 는 4배 비싸지만 16배 빠르다. SSD 가 좋은지는 보통컴퓨터 사용자도 다 아는거지만, 웹엔지니어도 측정수치로 증명해서 가능하면 SSD 를 추진하자는 겁니다.
- 우리가 DB 의 레이턴시를 한개 수량급 낮춘 후에 DB 다음으로 부상하는건 무엇일까요?
- 통신입니다. 멀티플레이어 게임은 서버 레이턴시와의 전쟁이라는 말도 있습니다. 모바일게임 웹서버는 멀티플레이어게임처럼 레이턴시와의 전쟁까지는 아니지만 빠를수록 좋죠.
- HTTP 의 문제는 이겁니다. 말 한마디 할 때마다 새로 “전화를 걸어야” 한다. 비유인데, TCP 연결을 매번 다시 맺어줘야 한다는거죠.
- TCP 인사법. 하이. 하이 방가방가. 방가방가. 즉 TCP 쓰리 웨이 핸드셰이크.
- 문제는 통신거리가 멀어질 때 입니다. 예를 들어서 서버는 아마존 서울 리젼인데, 접속유저는 북미에 있다. 레이턴시가 확 늘어나겠죠. 클라가 미국에 있을 때와 한국에 있을 때 레이턴시 차이는 10배 넘게 납니다. 보수적인 수치입니다. 사실 이건 소켓서버라도 어쩔 수 없는 부분이긴 합니다
- 더욱 문제가 되는건 HTTP 에스! HTTPS 에는 추가 인사가 붙습니다. 보안을 위해 서로 암호를 주고받는거죠. 자세한 설명은 스킵하고, 자세한 프로토콜은 찾아보시면 되니까, 여기서 간략하게 설명드리자면. TCP 는 쓰리 웨이 핸드셰이크 (3-way 핸드셰이크) 라지만 요즘 서버들은 실제 패킷을 세번째 “인사” 에 바로 이어서 보내는 최적화를 허용해서, 실제 TCP 연결 맺는데는 한번의 왕복이 필요합니다. HTTPS 의 추가인사, 즉 SSL/TLS 를 맺는데만 2번의 라운드트립이 필요합니다. 그리하여 HTTPS 연결을 맺는데 총 3번 왕복이 필요합니다. SSL 서버 인증에만 20 밀리세컨드 넘게 걸리지만, 이 세번의 왕복과 비교하면 아무것도 아니죠.
- HTTPS 안쓰면 안되냐? 보안을 위해서 쓰는건데 HTTPS 쓰는게 제일 편하고 제일 이득입니다. HTTPS 를 빼는 순간 많은걸 수동으로 넣어야 하고 https 흉내를 내야 하는데 번거로울뿐만 아니라 https 만큼 잘하기 어렵습니다. https 가 해주는것들을 살펴보자면 서버 오덴티케이션. 즉 서버 인증이죠. 서버에서 하는 인증과 헷갈릴까봐 영어로 적었는데. 여기서는 서버가 가짜서버가 아닌지 인증한다는 뜻입니다. 세션 맺어주죠. 패킷 시퀀스를 관리해줘서 아무것도 안해도 패킷 리플레이 공격을 방어해주는데. 패킷 리플레이 공격 방어를 위한 방법중에서 ssl 만큼 잘하기 어렵더라구요. 암호화. 유니크 세션. 도청 방지를 해주고 세션 통째로 리플레이하는 공격을 막아줍니다. 패킷 무결성 검사. 위변조방지의 작용을 해줍니다. https 를 쓰면 편하면서도 보안성은 높다 입니다.
- https 쓰면서 통신 레이턴시를 잡는 방법이 있을까?
- NginX 를 쓰면 됩니다. NginX 로 연결들을 다 쥐고 있으면 됩니다. 전화 비유를 이어가자면 NginX 이 모든 회선을 다 유지하고 있는겁니다. 말한마디 하기 위해 다시 전화할 필요 없이, 이미 있는 연결에다 말만 하면 됩니다. 또는 NginX 에 준하는 다른 솔루션. 그런 솔루션 들이 있지만, NginX 만큼 좋은 솔루션은 NginX 만큼 성능이 좋지 않고, NginX 와 동등급 성능의 솔루션들은 NginX 만큽 실전검증을 거치지 않았고. 기능도 엔진엑스처럼 많지 않고. 아마 HAProxy 도 될텐데 HAProxy 는 잘 몰라서 NginX 얘기만 하겠습니다.
- NginX 로 뭘 할것이가 Keepalive 를 3분 이상으로 잡아주는겁니다. 인게임이 3분도 넘는다 한다면 뭐 10분까지 주는 것도 충분히 합리적일 것 같습니다. 자세한 세팅 항목은 NginX 문서를 참조하면 되니까 여기서 설정 주의점만 팁을 드리자면 Keepalive 맥스 타임아웃도 설정해줘야 하지만 같은 설정항목에서 서버가 능동적으로 클라한테 제안하는 킵얼라이브 수치도 설정해줘야 합니다.
- 왜 엔진엑스인가 많이 인용되는 그래프인데 NginX 는 이른바 씨일공K 문제를 지원하는 웹서버라서 성능이 좋습니다. 원리는 사실 Node.js 같은 이벤트 드리븐이죠. 요즘에는 아파치에도 이벤트 MPM 이 생겨서 NginX 랑 비슷하게 작동할 수 있다고는 하는데 제가 안써봐서 넘기겠습니다.
- 오늘날 NginX 서버는 1억4천6백만의 웹사이트를 지탱해주고 있습니다. 일부 가장 성공하고 트래픽이 방대한 온라인 서비스들이 NginX 를 사용하고 있습니다. 이를테면 넷플릭스, 드랍박스, 깃텁 등등. 충분히 연마되었음을 설명하죠.
- NginX 는 어떻게 사용하는가? 웹서버로 사용해 웹프런트의 작용을 해주거나. 정적 파일 서빙도 해주고, 동적 내용 프록시도 해주게 해당 프로그래밍 언어 모듈을 세팅해주는겁니다. 그게 어렵다면, 예를 들어서 웹서버를 바꿀 수 없는 상황이라면 NginX 를 단순히 리버스 프록시로 사용해주면 됩니다. 웹 애플리케이션 서버 앞단에 사용하는 케이스가 되겠네요. 자바에서는 애플리케이션 컨테이너라고 부르고, 파이썬에서는 흔히 위즈끼 서버가 WAS 담당입니다. 이렇게 하면 덤으로 딸려오는 장점들이 있습니다. WAS 는 암호화와 인증의 무거운 부담을 덜게 됩니다. 그리고 WAS 는 http 커넥션을 짧게만 쥐고 있게 되어 리소스 절약하게 됩니다. L7 로드밸런싱 기능도 얻습니다. NginX 가 L7 로드밸런서 역할을 해주기 때문입니다.
- 새로운 문제가 있습니다. HTTP 킵얼라이브 기능은 http 1.1 부터 제대로 들어간다는겁니다. 요즘 모바일 게임에 절대적으로 많이 쓰이는 유니티 엔진은 과연 http 1.1 을 지원할까.
- 그래서 제가 문서를 찾아봤습니다. 유니티 문서의 WWW 클래서 부분에서는 관련 언급이 없었습니다. 그렇거나 제가 못찾았거나. 실제로 실험해본 결과 유니티 엔진의 WWW클래스는 http 1.1 을 지원 했습니다. 킵얼라이브 기능도 잘 작동했구요. UA 로 판단했을 때 유니티가 libcurl 을 사용하는것으로 보였습니다.
- 헤더는 이렇게 내려주도록 설정하면 됩니다.
- 조금 정리해보자면 클라가 유니티일 때 SSL 이 붙었음에도 불구하고 HTTP 임에도 불구하고 응답 레이턴시가 소켓서버 못지 않게 된다는 놀라운 결론을 얻게 됩니다
- 또한가지 해결해야 할 문제점 웹서버라서 느릴 수 있는 요소가 서버푸시가 없어서 쓸데없는 읽기요청을 많이 하게 되는 경향이 있다는겁니다. 이것도 방법이 있습니다.
- HTTP/2 에 있다. 하지만 보급되지 않았다. 많이 사용하는 방식은 웹소켓과 요즘은 많이 안쓰는 HTTP 롱 폴링.
- 웹소켓이 아닌 그냥 소켓을 써도 되는데 웹소켓이 좋은건 라이브러리가 좋다는 점입니다. 웹소켓 라이브러리가 많고 완성도도 높고. 웹소켓 자체도 사용이 소켓보다 쉬운편이라서? 사실 제가 생각하는 더 쉬운 방법은 따로 푸시만 맡는 서버를 두는 것입니다. 이 서버는 소켓서버가 되겠죠. WAS 는 레디스 통해서나 메세지 큐 통해서 이 푸시서버에 푸시를 보내면 되고.
- 파이프라이닝
- 파이프라이닝이란 무엇인가? 쉬운 비유를 대보자면 원래는 한명 보내고 걔가 돌아오면 또한명 보내고 하는 식이여야 하는데 파이프라이닝은 여러명을 한번에 보내는 식이 됩니다. 목적은 당연히 역시 레이턴시 감소죠. 많은 사람들이 HTTP 파이프라이닝이 HTTP/2 의 피쳐라고 잘못 알고있는데, 실은 HTTP 1.1 에 이미 있습니다. HTTP/2 의것은 최적화된 버전이라고 보시면 됩니다.
- 점점 HTTP/2 홍보가 되가는 느낌인데. 그러면서 아직 보급 안됐다카고. 파이프라이닝을 어떻게 잘 활용할 것인가? 역시 유니티 엔진에 달렸는데…… 더 쉽고 확실한 방법이 있습니다.
- 흔히 사용되는 두가지 API 스타일: 레스트풀과 JSON 알피씨 라이크. 레스트 api 에서는 메소드가 http 메소드와 제일 중요하게는 url 경로에 달려있어서 파이프라이닝 하려면 http 파이프라이닝 기능에 기댈수밖에 없어요. 하지만 json RPC 스타일이라면 그냥 개발자가 보낼 때 json 을 묶어서 보내면 됩니다.
- 이런 의문이 있을 수 있습니다. 아직 온라인게임식 소켓서버보다 느리잖아! node.js 같은 요즘 웹서버들은 http 파싱도 네이티브 모듈로 합니다 자바스크립트가 아니라 하지만 이런 짜잘한 부분들을 모두 무색하게 만드는게
- 상태관리엔진. 유상태인가 무상태인가.
- 이건 웹서버를 선택한 대가이니 어쩔 수 없다?
- 아닙니다. 이것마저 해결해줄 궁극기가 있습니다.
- 바로 마술
- 은 아니고 연출
- 연출이 모든걸 지배합니다. 물론 서버 자체도 너무 느리진 말아야 하겠죠. 그래서 지금껏 이렇게 힘들게 최적화를 한거고요.
- MSDN 에 이런 말이 있습니다: Async 는 반응성을 향상시킨다 비동기 방식은 블락킹 가능성이 있는 행동들에 필요하다. 예를 들어 애플리케이션이 웹을 액세스할 경우. 웹에 대한 접근은 가끔 느리고 지연된다. 이런 행동이 동기적인 과정에 의해 블락킹 된다면 전체 애플리케이션은 기다려야만 한다. 하지만 비동기 작동방식에서는 애플리케이션이 다른 일들을 계속할 수 있게 된다.
- 파이썬에 asyncio 넣을 때 오른쪽 화면에 파이썬의 아버지 Guido 로 보이는 분이 이런 말을 하십니다: 비동기 IO 를 넣음으로 UI 의 반응성을 높여줄 수 있습니다.
- 그렇다면 연출을 어떻게 해야 잘했다고 소문날까? 어떻게 해야 느낌상 느리다는게 느껴지지 않을까? 더욱 좋기로는 빠르다고 느껴질 수 있을까? 저는 비쥬얼 스튜디오 코드나 깃크라켄 같이 요즘 다 크롬갖다 만든 GUI 기술들이 좋은 예들이라고 생각합니다. 자바스크립트는 태생 블락킹 없는 코드만 짜오고 라이브러리들도 다 그렇게 되어있어서. 이런 좋은 결과가 가능해진거라고 생각합니다. 그리고 듣기로는 연출로 체감 상승시킨 레전드 케이스가 스타 원때부터 있다고 하더라구요. 뜻인즉 결코 제가 말도 안되는 말을 한게 아니라는겁니다 ㅋㅋㅋ
- 그래도 더 빠르게 하고싶다. 이럴 경우에는 레딧같은 초대형 웹사이트들에서나 사용하는 금기마법을 쓸 수는 있는데. 금기마법이니 그냥 안쓰는게 더 좋겠죠? (대략 설명을 하자면…..
- 어쨌든 본 강연의 포인트는 웹서버가 충분히 충분히 빨라질 수 있다는 점입니다. 모바일 게임을 서비스할 때 웹서버의 부적절하다고 너무 섣불리 판단내리지 말고 웹서버를 너무 일찍부터 아웃시키지 말고 사랑스러운 무상태서비스의 이점을 충분히 누려보자는데 있습니다.
- 나중에 자료 공개되면 이 페이지에서 레퍼런스를 확인하실 수 있습니다.
- 감사힙니다.