SlideShare une entreprise Scribd logo
1  sur  84
Nexon America DevOps
김영현(Senior Technical Operations Engineer)
<이카루스 북미>
북미와 유럽을 위한 액션 RPG 베타서비스의 효과적인 활용법
DevOps?
기술적인 검토 : 서버 및 네트워크 구성
서버 셋업
배포 자동화
모니터링 시스템 구축 및 자동화
4/27 9:50am 김태현
DevOps? DevOps 개발자? 북미에서 6년
게임 서버 셋업
서버 구성 분석
로그인 서버
일반 DB
월드
로비 서버
게임 서버
게임 서버
게임 서버
게임 DB
서버의 사양
필요 서버수
적절한 데이터 센터 선정
자료출처 : http://www.pngall.com/server-png
게임 서버 셋업
데이터 흐름 분석
로그인 서버
일반 DB
월드
로비 서버
게임 서버
게임 서버
게임 서버
게임 DB
유저로부터 속도
연결 구성
자료출처 : http://lemmino.deviantart.com/art/Forever-A-Gamer-in-HD-362895641
게임 서버 셋업
로그인 서버
일반 DB
데이터량 분석
월드
로비 서버
게임 서버
게임 서버
게임 서버
게임 DB
5.2 kb/s 80.2 kb/s
8mb/s
필요한 밴드위쓰
(내부, 외부)
필요한 네트워크 장비
필요한 회선
게임 서버 셋업
로그인 서버
일반 DB
서버 수용인원 분석
월드
로비 서버
게임 서버
게임 서버
게임 서버
게임 DB
5.2 kb/s 80.2 kb/s
8mb/s
1000명
1000명
1000명
5000명
10000명
서버의 사양
필요 서버수
게임 서버 셋업
로그인 서버
일반 DB
오토스케일링
월드
로비 서버
게임 서버
게임 서버
게임 서버
게임 DB
로그인 서버
로비 서버
게임 서버
게임 서버
게임 서버
모니터링
Provisioning
Scaling condition
HA (High Availability) 구성
게임 서버 셋업
로그인 서버
일반 DB
보안
월드
로비 서버
게임 서버
게임 서버
게임 서버
게임 DB
패킷암호화
보안장비
패킷암호화
DDOS 방지 보안장비
로그 관리 및 분석 시나리오
게임 서버 셋업
서버 구성 분석
데이터 흐름 분석
데이터량 분석
서버 수용인원 분석
오토스케일링
로그, 보안
게임 서버 셋업
서버 구성 분석
데이터 흐름 분석
데이터량 분석
서버 수용인원 분석
오토스케일링
로그, 보안
확인 및 검증 내부 테스트
비공개 외부 테스트
클로즈드 베타?
서버
접속
국내서비스 vs 글로벌서비스
국내 서비스 글로벌 서비스
서버 구성 단일지역 단일 또는 복수지역
데이터 흐름 인터넷 속도 최강국 너무 다양함
단일서버
일반 MMORPG
200ms내외
DB, 게임서버 동일지역
렉이 생겨도 할수 없는…
별 사전 조사 없이 있는
IDC에 세팅
2000년대 중후반
자료출처 : https://clipartfest.com/categories/view/0620badd3d83d1eaf5b01b85e1e5416a4012b8a3/world-map-labeled-clipart.html
중앙서버 + 다수지역서버 FPS형태
50ms내외
유저와 가까운 중계서버
특별한 분석이 없는…
Ping 자료에 따라서 가까운곳
적절한 호스팅이나 클라우드
2010년대 초반
판단의 기준
Ping 자료  개개인 유저의 데이타를 수집하기 어려움
경험  어떤 IDC 가 좋다(더라). 어떤 회선이 좋다(더라).
현실  클베 한번 이후 바로 오베. 다른 지역 확보의 어려움.
검증과 분석의 부족함
초기 세팅 수년간 서비스를 좌우
세팅 된 서버 이전/변경의 어려움
검증의 어려움
성공여부
오베클베 또는 유사 : 부정적인 영향
이카루스
위메이드에서 오랜기간 개발
2013년 한국 오픈
2016년 북미/유럽 오픈
기술적인 특징
기본적인 MMOPRG + 많은 액션
요구된 최적 latency
이카루스 : 100~150ms
FPS : < 50ms
일반 MMO : 150 ~ 200ms
자료출처 : https://mmos.com/review/riders-of-Icarus
요구사항(requirements)
클로즈드 베타 (closed beta)
1차, 2차, 3차
요구사항
3. 클베는 세번
1. 게임서버는 DB와 동일한 지역에 셋업
2. 북미와 유럽 모두 서비스
일반적인 MMO
일반 서버 DB 서버 게임 서버
월드
요구사항
게임서버는 DB와 동일한 지역에 셋업
일반적인 FPS
일반 서버 DB 서버 게임 서버
게임 서버
게임 서버게임 서버
요구사항
게임서버는 DB와 동일한 지역에 셋업
이카루스 서버
지역선택
인증 서버
요구사항
게임서버는 DB와 동일한 지역에 셋업
일반 서버 DB 서버 게임 서버
월드
일반 서버 DB 서버 게임 서버
월드
일반 서버 DB 서버 게임 서버
월드
일반 서버 DB 서버 게임 서버
월드
요구사항
3. 클베는 세번
1. 게임서버는 DB와 동일한 지역에 셋업
2. 북미와 유럽 모두 서비스
미대륙 : 약 12.6억평
유럽 : 약 3억평
한국 : 약 3000만평
520배
요구사항
북미와 유럽 모두 서비스
너무 많은 ISP
요구사항
북미와 유럽 모두 서비스
너무 많은 IDC
요구사항
북미와 유럽 모두 서비스
한국 : 136개(2016년)자료출처 : http://www.datacentermap.com
옵션
호스팅 업체 ( 동부, 서유럽 )
아마존 AWS ( 동부:버지니아, 서유럽:프랑크푸르트, 런던 )
넥슨 유럽 IDC ( 룩셈부르크 )
요구사항
북미와 유럽 모두 서비스
미서부 : 라스베가스 IDC
기존자료
Ping 자료는 쉽게 구할 수 있다.
요구사항
북미와 유럽 모두 서비스
자료출처 : https://wondernetwork.com/pings/Los+Angeles
몸풀기 분석
몸풀기 분석
엑셀에서 회귀분석
데이타분석
회귀분석
엑셀에서 회귀분석
상관계수(Correlation Coefficients)
얼마나 연관성이 있는가?
0.65 이상일때 의미
회귀분석 용어
회귀식(Regression equation)
예측을 할 수 있게 해주는 1차 방정식
0.0162x(1000) + 10.448 = 26.648
LA와 1000km 떨어진 곳의 ping 예측?
회귀분석 용어
결정계수(Coefficient of Determination)
회귀식에 맞는 데이타율
회귀분석 용어
요구사항
2. 북미와 유럽 모두 서비스
1. 게임서버는 DB와 동일한 지역에 셋업
3. 클베는 세번
1차 클베 : 서부서버. 데이터 분석
전략
2차 클베 : 동부서버. 커버리지 분석
3차 클베 : 후보지 선정.
내부 테스트 : 클베로 부족한 부분 확인
요구사항
클베는 세번???
오픈베타까지 3주
3차 클베 : 1+2차의 결과에 따라서 옵션
옵션 A : 미서부, 미동부, 유럽
옵션 B : 미동부
옵션 C : 미서부, 미중부, 미동부, 유럽
옵션 D : 미서부, 유럽
요구사항
클베는 두번!!
무엇이 필요할까??
Ping만으로 충분할까?
서버와 DB에서 처리되는 시간은 무시해도
될까?
아이템을 줍거나 스킬을 쓸때 얼마나 걸릴까?
의외로 빠르거나 느린 지역이 있지 않을까?
게임 서버
ping
DB 서버
필요사항
DB 서버게임 서버
ping : 32 byte ICMP packet
DB 서버게임 서버
유저의 액션부터 서버, DB를 거쳐서 다시 돌아오는 값
TCP game packet
아이템, 스킬 시전에 latency를 측정
개발사의 적극적인 협조 – 아이템/스킬 latency 측정 추가 개발
최초 로그 형태
285-173=112ms
분석 0차
필요한 필드 정리, 추출방법 결정
파일이 아닌 DB에 로그 적재
Python 으로 추출, R 에 적용
미동부
~100ms
~30ms
미서부
https://jagt.github.io/clumsy/
실제 플레이 + 랙 강제 발생
 200ms 정도면 쾌적
클베 준비
DB 로 로그를 이동
로그를 어떻게 가공할지 python, R로 확인
분석 방법 결정
북미서부에만 서버를 세팅하여 테스트
1차 클베 : 서부서버. 데이터 분석
전략
2차 클베 : 동부서버. 커버리지 분석
3차 클베 : 후보지 선정.
내부 테스트 : 클베로 부족한 부분 확인
오픈베타까지 3주
1차 클베
프로토타이핑
2차 클베 3차 클베
1차 클베
자료출처 : http://www.vegasissues.com/2017/02/01/13-things-you-know-only-if-you-grew-up-in-vegas/
Google map
로그 : 미흡한 자료 보충 및 DB 저장
1차 클베
게임 latency
데이타 및 분석
아이템 latency & 스킬 latency
데이터 추출 및 가공 작업 (Python 의 panda 라이브러리 활용)
약 1,000,000건  5천건으로 압축 및 가공
IP를 바탕으로 국가, 위치, ISP 정보  free web api
1차 클베
1차 클베
최소 평균 중간 최대
중간값(median)
평균값
vs
중간값
1차 클베
최대
최소
40
20
중간값(median)
1차 클베
Outlier
1차 클베
1차 클베
https://carto.com/
1차 클베의 소득
1차 클베
DB
DB로 옮긴 데이타의 가공법 확립
분석 방법 및 방향 확립
1차 클베
시각화 방법 확립
불완전요소 확인(위치값)
서부 서버로는
전체 커버 불가능 확인
2차 클베
실패의 확인, 결과는 성공
3차 클베1차 클베
1차 클베 : 서부서버. 데이터 분석
전략
2차 클베 : 동부서버. 커버리지 분석
3차 클베 : 후보지 선정.
내부 테스트 : 클베로 부족한 부분 확인
오픈베타까지 3주
동부 단독 서버 과거 경험에 대한 기대
Python + api 호출  DBA + GeoIP 활용
2차 클베
너무 불안정한 IDC : 예상보다 적은 유저 , 데이터
결과
2차 클베
2차 클베
1차 클베
2차 클베
65% 86% 91%
게임latency 200ms 미만
2차 클베
53%
게임latency 200ms 미만
35%
Ping 과 게임 latency 와의 관계
2차 클베
거리에 따른 ping 값(기존자료)
1차 클베 : 서부서버. 데이터 분석
전략
2차 클베 : 동부서버. 커버리지 분석
3차 클베 : 후보지 선정.
내부 테스트 : 클베로 부족한 부분 확인
오픈베타까지 3주
유럽 내부테스트
사내직원 및 지인들을 대상
룩셈부르크 넥슨유럽 IDC : 사용불가
프랑크푸르트 아마존 AWS에 테스트
내부테스트
호스팅 보다는 클라우드
2차 클베의 소득
유럽 – 내부테스트로 확인
53%
35%
65%
86% 91%
동부에 셋업하는 것은 배제
3차 클베
확인
1차 클베 2차 클베
1차 클베 : 서부서버. 데이터 분석
전략
2차 클베 : 동부서버. 커버리지 분석
3차 클베 : 후보지 선정.
내부 테스트 : 클베로 부족한 부분 확인
오픈베타까지 3주
3차 클베 : 1+2차의 결과에 따라서 옵션
옵션 A : 미서부, 미동부, 유럽
옵션 B : 미동부
옵션 C : 미서부, 미중부, 미동부, 유럽
옵션 D : 미서부, 유럽
요구사항
클베는 두번!!
위치 후보 선정
미서부, 미동부
룩셈부르크, 프랑크푸르트,런던
3차 클베
최종 서버 지역
3차 클베
자료출처 : https://www.youtube.com/watch?v=2OUTN1Eyv_k
대륙별 최적 latency 비율
유럽 : 88%미국 : 78% 캐나다 : 70%
3차 클베
자료출처 : http://mapssite.blogspot.com/2008/11/map-of-europe-countries.html
https://clipartfest.com/categories/view/e1e6b1561afcae051f4aca2b13e1964288791acd/us-map-flag-clipart.html
http://www.prepaid-wireless-guide.com/cell-phone-providers.htm
3차 클베
VPN
3차 클베의 소득
미국:78%
캐나다:70%
유럽:88%
오픈 베타
라스베가스(미서부) + 프랑크푸르트(유럽) 으로 서비스중
포스트 모템 요약 버전
액션 RPG의 서버 구성 및 지역 산출
프로젝트 정리
북미와 유럽을 모두 커버
두번의 클베로 후보지를 선정. 마지막 클베로 확인.
간단한 통계로 데이터의 연관성 확인
프로젝트 결과
실제 게임 데이타의 전송 속도를 측정
Ping 과 실제 게임 데이타는 차이가 있으나, 연관성은 높음
플레이에 쾌적한 데이타 산출. 이를 바탕으로 커버지역 산출
유니크 IP 에 대한 데이터 산출 : 기술 뿐 아니라 사업적으로 활용
호스팅이 아닌 클라우드로 처음부터 접근했어야…
Wrong or Missing
클베 사이 간격이 분석, 전략, 수행의 시간적 여유가 좀 더 있었으면…
게임 서버와 DB의 물리적 먼거리에서 테스트 부재
개발되고 적재된 데이타의 2차 활용의 지속 부족
Python의 Panda + R로 기본적인 데이터 가공작업을 한것
특별히 잘한 부분
시각화로 모든 사람이 한눈에 보고 이해할 수 있었던 점
개발사의 협조로 게임 latency 를 유저별 추출해서 분석한점
무료 API 호출로 지역정보를 가져오는데 2-3시간 걸림
특별히 어려웠던 부분
평소에 수학공부를 좀 해둘걸…
클베 두번으로 최적화된 장소를 찾기에는 시간부족
기본적인 수학공부는 틈틈이
Action Plan
클베간의 일정은 사업팀과 조율을…
요구조건에서 조금이라도 의심이 생기면 테스트와 검증으로 확인
감으로, 경험으로 판단하지 말고 검증하자
클라우드의 다양한 지역에 서버를 둬서 내부 테스트를 해보자
Thank You.

Contenu connexe

Tendances

[네트워크] TCP, 믿을 수 있나요!?
[네트워크] TCP, 믿을 수 있나요!?[네트워크] TCP, 믿을 수 있나요!?
[네트워크] TCP, 믿을 수 있나요!?
용민 박
 
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
SANG WON PARK
 
Tdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalabilityTdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalability
흥배 최
 

Tendances (16)

[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis Cluster[2B5]nBase-ARC Redis Cluster
[2B5]nBase-ARC Redis Cluster
 
웹서버와 프라우드넷 서버간 상호작용 가이드
웹서버와 프라우드넷 서버간 상호작용 가이드웹서버와 프라우드넷 서버간 상호작용 가이드
웹서버와 프라우드넷 서버간 상호작용 가이드
 
서버/인프라를 지탱하는 기술
서버/인프라를 지탱하는 기술서버/인프라를 지탱하는 기술
서버/인프라를 지탱하는 기술
 
Streaming platform Kafka in SK planet
Streaming platform Kafka in SK planetStreaming platform Kafka in SK planet
Streaming platform Kafka in SK planet
 
Tcp summary
Tcp summaryTcp summary
Tcp summary
 
[224]nsml 상상하는 모든 것이 이루어지는 클라우드 머신러닝 플랫폼
[224]nsml 상상하는 모든 것이 이루어지는 클라우드 머신러닝 플랫폼[224]nsml 상상하는 모든 것이 이루어지는 클라우드 머신러닝 플랫폼
[224]nsml 상상하는 모든 것이 이루어지는 클라우드 머신러닝 플랫폼
 
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
 
grade server - block socket
grade server - block socketgrade server - block socket
grade server - block socket
 
[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅
 
[네트워크] TCP, 믿을 수 있나요!?
[네트워크] TCP, 믿을 수 있나요!?[네트워크] TCP, 믿을 수 있나요!?
[네트워크] TCP, 믿을 수 있나요!?
 
Journey for provisioning 20k over rbd volumes to kubernetes with openstack
Journey for provisioning 20k over rbd volumes to kubernetes with openstackJourney for provisioning 20k over rbd volumes to kubernetes with openstack
Journey for provisioning 20k over rbd volumes to kubernetes with openstack
 
Optane DC Persistent Memory(DCPMM) 성능 테스트
Optane DC Persistent Memory(DCPMM) 성능 테스트Optane DC Persistent Memory(DCPMM) 성능 테스트
Optane DC Persistent Memory(DCPMM) 성능 테스트
 
[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술
 
Wire shark 사용법 및 네트워크 개론 살짝 설명
Wire shark 사용법 및 네트워크 개론 살짝 설명Wire shark 사용법 및 네트워크 개론 살짝 설명
Wire shark 사용법 및 네트워크 개론 살짝 설명
 
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
 
Tdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalabilityTdc2013 선배들에게 배우는 server scalability
Tdc2013 선배들에게 배우는 server scalability
 

Similaire à [NDC 2017] 이카루스 북미 : 베타서비스 활용법

[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
Jaeseung Ha
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
cranbe95
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
Amazon Web Services Korea
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
devCAT Studio, NEXON
 

Similaire à [NDC 2017] 이카루스 북미 : 베타서비스 활용법 (20)

[MGDC] 리눅스 게임 서버 성능 분석하기 - 아이펀팩토리 김진욱 CTO
[MGDC] 리눅스 게임 서버 성능 분석하기 - 아이펀팩토리 김진욱 CTO[MGDC] 리눅스 게임 서버 성능 분석하기 - 아이펀팩토리 김진욱 CTO
[MGDC] 리눅스 게임 서버 성능 분석하기 - 아이펀팩토리 김진욱 CTO
 
Rhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_ArchitectureRhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_Architecture
 
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
광안 1반 2팀 엠퀴즈 최종 발표 자료.pptx
 
Azure로 MMO게임 서비스하기
Azure로 MMO게임 서비스하기Azure로 MMO게임 서비스하기
Azure로 MMO게임 서비스하기
 
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
 
Advanced nGrinder 2nd Edition
Advanced nGrinder 2nd EditionAdvanced nGrinder 2nd Edition
Advanced nGrinder 2nd Edition
 
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
[IGC 2017] 아마존 구승모 - 게임 엔진으로 서버 제작 및 운영까지
 
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
 
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기 [아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
[아이펀팩토리] 클라이언트 개발자, 서버 개발 시작하기
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
 
What is Game Server ?
What is Game Server ?What is Game Server ?
What is Game Server ?
 
Multiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theoremMultiplayer Game Sync Techniques through CAP theorem
Multiplayer Game Sync Techniques through CAP theorem
 
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
[NDC2017 : 박준철] Python 게임 서버 안녕하십니까 - 몬스터 슈퍼리그 게임 서버
 
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버
 
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
게임 서비스 품질 향상을 위한 데이터 분석 활용하기 - 김필중 솔루션즈 아키텍트:: AWS Cloud Track 3 Gaming
 
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
홍성우, 게임 서버의 목차 - 시작부터 출시까지, NDC2019
 
Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
Gametech 2014: 모바일 게임용 PaaS/BaaS 구현 사례와 디자인 트레이드오프
 
클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
 
[오픈소스컨설팅]파일럿진행예제 on AWS
[오픈소스컨설팅]파일럿진행예제 on AWS[오픈소스컨설팅]파일럿진행예제 on AWS
[오픈소스컨설팅]파일럿진행예제 on AWS
 
스마트폰 온라인 게임에서 고려해야 할 것들
스마트폰 온라인 게임에서 고려해야 할 것들스마트폰 온라인 게임에서 고려해야 할 것들
스마트폰 온라인 게임에서 고려해야 할 것들
 

[NDC 2017] 이카루스 북미 : 베타서비스 활용법

Notes de l'éditeur

  1. 안녕하십니까. 넥슨아메리카에서 일하고 있는 김영현입니다. 이카루스를 북미에 서비스 준비를 하면서 어떻게 베타서비스를 활용했는지에 대해서 얘기를 하려고 합니다. 저는 데브옵스라는 팀에서 일을 하고 있는데… // 북미와 유럽을 위한 액션 RPG 베타서비스의 효과적인 활용법 이라는 제목으로 강연하게될, 넥슨 아메리카 데브옵스 팀의 김영현입니다. 저는 현재 Sr. TechOps Engineer 역할로 일을 하고 있습니다.
  2. 먼저 DevOps 라는 포지션에 대해서 간단히 소개를 드리면.. 특정 솔루션에 대한 기술적인 검토를 합니다. 서버 및 클라이언트의 네트워크 구성이 어떻게 되는지, 어떤 사양으로 해야할지 등등에 대해서 검토를 하고, 이것을 바탕으로 서버를 셋업하고, 클라/서버의 배포를 자동화하는 작업을 합니다. 스크립트를 짜기도 하고, 배포 자동화에 필요한 프로그램을 셋업 관리하기도 합니다. 그리고 서비스를 진행하면서 서버 또는 네트워크에 문제가 있는지에 대해서 모니터링 하는 시스템을 구축하고, 문제가 발생했을때에 그 다음에 어떠한 액션을 취해야할지.. 대처하는 것에 대한 자동화를 개발하고 관리합니다. 더 자세한 얘기는 ..
  3. 게임 서버 셋업이라고 하면 .. 먼저 서버의 구성을 분석합니다… ~~ 선정을 합니다..
  4. 네트워크 흐름에 대한 분석을 합니다… 연결구성을 분석하고 어떻게 네트워크를 구성하면 좋을지 기획을 합니다.
  5. 밴드위쓰를 분석하고, 필요한 장비, 밴드위쓰, 회선등을 기획하고 준비를 합니다.
  6. 유저가 어느정도 들어올지에 대해서 예상을 한 값에 대해서 서버 사양을 어느정도 될지, 스트레스 테스트도 하고, 서버댓수도 산정을 해서 기획하고, 준비합니다.
  7. 오토스케일링이라고 하면.. 유저들이 늘어나고 줄어드는 것에 대해서 자동으로 서버를 배치하거나 없애는 것을 말합니다. 가상화 머신에서 이뤄지고, 서버 모니터링을 하다가, 서버에 로드에 따라서 프로비저닝이 된 호스트 또는 컨테이너를 정해진 룰에 따라서 셋업하는 것을 구성합니다. 프로비저닝 : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것 HA 라는 것은 쉽게 얘기해서 이중화 구성으로 서버에 Single Point Failure 에 대한 대비를 하는 것입니다.
  8. 보안적인 이슈들 해커들로부터 DDOS 공격은 보안장비 및 패킷 암호화로 대비를 하고, Packet 조작으로 인해서 게임에 부당한 이익을 취하는 것에 대한 대비를 합니다. 이것은 서버에 남겨진 로그를 실시간으로 분석해서 Packet 조작을 감지를 하고, 유저들에 대한 처벌 시스템도 구축을 합니다.
  9. 이정도가 게임 서버를 셋업하는 개괄적인 과정이고요… 이중에서
  10. 서버를 셋업화는 과정에서 제일 먼저 이뤄져야 하는 것이 어떤 구성을 하고 있는지, 그리고 데이터는 어떻게 흘러 가는지, 그리고 얼마나 흘러가는지에 대해서는 확인과 검증이 필요합니다. 이러한 분석작업은 저혼자, 또는 몇몇 사람들만 서버에 접속한다면 검증이 힘들기 때문에.. 우리가.. 테스트를 하죠. 그것이 알파 또는 베타서비스라고 합니다. 이러한 알파 및 베타서비스를 이용해서 확인 및 검증을 합니다.
  11. 가장 일반적인 베타 서비스는 유저들이 서버에 접속을 하면, 서버에서는 그 서버가 얼마나 견디는지, 데이터의 흐름과 양은 어느정도 되는지 CPU, Memory, Network traffic, 그리고 DB 의 사용량등을 확인해서 스펙 및 구조를 조절하게 됩니다. 클베마다 어느정도의 유저가 들어오면 어느정도의 사용량이 되는지..어떤 문제가 있는지.. 확인하고, 조절을 하게 되는 것입니다.
  12. 국내는 단일 지역에서 서버를 두기만 하면, 사실 데이터의 속도는 걱정 안해도 됩니다. 하지만, 글로벌 서비스에서는 데이터 흐름에 따라서 서버를 어떻게 구성하는지 매우 달라지게 됩니다. …
  13. 글로벌 서비스에서 단순한 구조는 단일 서버입니다… 한곳에 서버를 두고, 여러지역에 흩어져 있는 유저들이 그 서버에 접속을 하는 구조이죠. 이 구조는 한지역에 서버가 있기 때문에 DB, 게임서버등이 동일한 지역에 셋업이 되고, 약 200ms 이내의 latency 가 요구되는 게임들에 구성이 됩니다. 개인적으로는 2000년대 중후반까지 이러한 형태를 많이 진행했었고, 지금도 일부 게임들은 이 구조로 문제없이 서비스를 진행하고 있습니다. 하지만, 당시 제가 셋업을 했을때에는 별 사전 조사라는 것이 특별히 없이.. 계약된 IDC 에 세팅을 하고.. 따라서 유저들 사이에 렉이 발생해도 특별한 대응을 할 수 없는 그런 상황이었습니다.
  14. 중앙에 DB 서버와 일부 일반 서버들이 있고, 각 지역에 중계서버들이 흩어져있는 구조입니다. 가까운 지역의 유저가 자기와 가까운 지역의 서버를 ‘직접’ 선택해서 접속하는 구조이죠. 50ms 미만의 latency 가 요구되는 게임이고, 주로 유저 pool 이 많은 지역에 중계서버를 셋업하는 형태이고, 글로벌로 서비스하는 FPS 는 이러한 형태를 많이 가집니다. 현재 넥아에서도 이렇게 진행하고 있고요. 호스팅 서비스나 클라우드 서비스가 태동하기 시작한 2010년 초반부터 이러한 세팅들이 특히 FPS 게임에서 종종 볼 수가 있습니다. 많이 관과하는 부분이 ping 자료에 의존해서 세팅하고, 특별한 분석이 없이 그냥 적절한 호스팅이나 클라우드를 정해서 셋업하는 경우가 많았죠.
  15. ~13 minutes… 서버를 셋업할때에 주로 … Ping 자료 또는 자체적인 ping 체크로 셋업을 많이 합니다. 물론 꽤 신뢰도가 높긴 하지만, 해당 게임의 유저들에 대한 더 자세한 정보를 얻기가 어렵습니다. 물론 실제 유저들의 ping 자료를 바탕으로 분석하고 셋업하는 게임들도 많이 있습니다. 그리고 또 한가지는 경험입니다. .. (카더라) .. 라는 것으로 셋업하는 경우도 있죠. 현실적인 문제 또한 더 많은 분석 과 검증에 방해요소가 되곤 합니다. 클베를 한번 또는 두번으로 판단해서 오픈베타를 하는.. 이러한 과거의 경험들은 검증과 분석이 부족했다는 단점이 있습니다…
  16. 이렇게 검증과 분석이 부족한 초기 세팅은 서비스의 질을 좌우하게 됩니다. 만약, 오픈 이후에 서버세팅에 문제가 생긴다면.. 그래서 변경을 해야한다면… 첫번째, 세팅된 서버 자체의 이전이 물리적으로 힘들고 변경 또한 어렵습니다. 아주 장시간 점검을 하죠. 준비/테스트 또한 쉽지 않고요.. 두번째, 검증 또한 어렵습니다. 많은 유저들을 다시 불러서 테스트를 한다는 것도 불가능 하고… 또한 뭔가 테스트의 이미지가 비춰지면 유저들에게는 부정적인 반응을 불러일으키기 때문에 좋은 선택이 될 수 없습니다. 기존 게임들을 개선하고 관리하면서.. 그리고 과거에 신규 게임들을 셋업하면서 초기 세팅에 대한 중요성을 느끼고 있었습니다…
  17. 이런 와중에.. 이카루스라는 게임을 서비스할 수 있는 기회를 얻었습니다. 이카루스라는 게임은 위메이드에서 오랜기간 개발해서 2013년에 한국에 클베를 했었고, 2016년 에 넥슨 아메리카에서 오픈해서 현재 서비스중에 있습니다.
  18. 기본적인 MMORPG 시스템에 액션요소가 많이 가미된 게임으로 FPS 만큼 짧은 latency 를 요구하는 것은 아니지만, 일반 MMO 보다는 짧은 latency 를 요구한다는 것이 시스템상의 특징입니다. 저희 넥슨아메리카에서는 이카루스의 서비스를 결정하고, 제일먼저 고민했던 것은 서버를 어디에 얼마나 두느냐에 대한 것이었습니다.
  19. 그래서.. 기본적인 요구사항들이 어떤것들이 있는지 분석하고, 클로즈 베타를 어떻게 활용할것인지에 대해서 전략을 짜기 시작했습니다.
  20. 첫번째, FPS 게임과 같이 DB는 서부에 두고, 게임서버들만 외부 – 동부, 유럽, 남미등에 둘수가 없었고, 게임서버와 DB가 물리적으로 같은 위치에 있어야 수시로 일어나는 서버의 DB접속에 대한 안정성을 보장했어야 했습니다. 두번째, 북미와 유럽을 모두 서비스를 해야하기 때문에 저희가 메인으로 사용하고 있는 미서부IDC에만 서버를 둘수가 없었습니다. 세번째, 정해진 클베는 세번이었고, 세번째 클베는 오베와 시간차이가 매우 짧은 3주밖에 없었기 때문에 실질적으로는 클베 두번에 최적의 장소에 서버를 셋업하고, 3차클베에서는 최종적인 환경 구축을 했어야 했습니다. 여러지역을 서비스하는 게임들이 많은데…
  21. 일반적인 MMO는 한지역에 서버를 모두 두고도 많은 지역의 커버가 가능합니다…
  22. 한지역에서 서비스가 불가능하면, 이러한 구조로 셋업을 해야합니다.
  23. https://www.instiz.net/pt/3841806 아시다시피 지리적으로 한국과 비교해서 미국과 유럽은 사이즈가 다르죠..
  24. 이렇게 넒은 땅에 인터넷을 커버하기 위해서는 ISP 역시 많이 필요하고… 이렇게 많은 ISP 들이 있기 때문에 유저들이 사용하는, 서버들이 사용하는 라인들이 매우 다양합니다. 아래의 그래프를 보시면, 특정 게임에 어떤 ISP의 유저가 얼마나 접속해있는지 실시간으로 모니터링 할 수 있는 그래프입니다. 실제 저희가 서비스하고 있는 게임의 데이타이고요, … 이러한 ISP 별 동접을 모니터링 해야하는 이유는… 서버에 아무런 문제도 없고 서버에 들어오는 회선에도 아무런 문제가 없는데 동접이 살짝 꺽이는 경우가 있습니다. 그럴경우에 여기 그래프를 보면 , … 특정 ISP 의 동접이 떨어져있는 것을 종종확인할 수 있었습니다. .. ISP에 따라서 속도도 안정성도 매우 다양합니다.
  25. http://www.datacentermap.com 이렇게 많은 옵션때문에.. 우리가 실제로 선택가능한 옵션들을 정해야 했습니다.
  26. 선택에 대한 근거를 만들기 위한 분석이 필요했다.  20 min
  27. https://wondernetwork.com/pings/Los+Angeles 처음 접근한 방식은 기존자료와 경험이었습니다. 기존자료는 network ping 만으로 어느지역이 괜찮은지였습니다. 먼저 오픈되어 있는 기존 ping 자료만으로 어느정도 신뢰를 가지고 있는지, 어느지역이 괜찮은지 알아나가기 시작했습니다. 보시는 자료는 LA를 기준으로 거리에 따른 ping 값을 수시로 체크해주는 사이트에서 발췌했습니다.
  28. 어떻게 분석을 할지에 대해서 방향성을 잡고, 어떤것들이 필요한지 연습이 필요했습니다… 먼저, 거리에 따른 ping 값에 대한 연관성을 보면.. 10,000km 미만을 기준으로 봤을 때에는 눈으로 봤을때 연관성 자체에 큰 문제가 없어보입니다. 거리와 ping, 그리고 나중에 소개드릴 아이템 latency 와의 연관성을 확인하기 위해서 기존자료를 이용해서 거리와 ping 값의 관계를 알아본것입니다. 이 그래프는 엑셀에서 분산형 그래프에 추세선을 넣은것입니다.
  29. 엑셀에서 회귀분석을 할 수 있는 메뉴 설정입니다….
  30. 추가기능 -> 분석 도구 (http://blog.naver.com/PostView.nhn?blogId=sayox&logNo=100116253525&redirect=Dlog&widgetTypeCall=true)
  31. 사실 두 수치간의 연관성을 보시려면 그 위에 다중 상관계수가 좀 더 척도로 많이 쓰입니다. 즉, 점들이 얼마나 직선에 모여있는지를 나타내는 것이고, 이 수치 또한 0.65 이상일때 의미가 있습니다. 결정계수는 전체 변화중에서 회귀선에 의해서 설명이 되는 변동이 차지하는 비율로 사용됩니다. 예측을 할때 쓰이죠.
  32. 클베 세번으로 이러한 요구사항에 맞는 구성을 짜야합니다.
  33. 클베는 3번이지만, 실제로는 두번에 후보지를 선정해서 오픈베타를 준비했어야 했다. 따라서 실질적인 클베는 두번이었던 것이다…
  34. 일반적으로 네트워크를 측정하는 것은 ping 을 많이 사용합니다. 32 byte 짜리 icmp packet 을 날려서 돌아오는 값을 측정하죠.
  35. 최초의 로그는 좀 야생적입니다. 시간을 찍고 메세지를 찍는 방식으로, 액션을 시작한 시간과 돌아온 시간을 일일이 모두 빼야 latency 를 측정할 수 있는 방식이었습니다. -- 26min
  36. 제가 자체적으로 테스트를 먼저 했어야 하기 때문에 클라이언트에 텍스트로 로그를 남겼고, 동부와 서부에 테스트서버를 두고 테스트를 했습니다.
  37. 클라에 렉을 강제로 발생시키는 프로그램을 이용해서 network latency 를 어느정도 두면 게임플레이가 원활한지에 대해서 테스트를 했습니다. 게임을 그닥 잘하는게 아니기 때문에 QA의 도움을 많이 받았고요, 그들의 테스트 결과도 받았습니다. 그 결과 아이템 latency 가 200ms 정도 되면 플레이가 가능한정도, 100ms 는 쾌적한 정도라는 결과를 얻을 수 있었습니다. 이것이 기준이 된것이죠.
  38. Text로 할 수 없으니 DB로… 가공의 프로토타이핑은 python 으로 확인 분석 방법은 R 로 box plot 을 보거나 분포를 본다.
  39. 보여드렸던 전략의 첫번째입니다. 1차클베에서는 미서부, 그에 따라서 데이터 분석을 하는 것이 목표였습니다. -- 30min
  40. http://www.vegasissues.com/2017/02/01/13-things-you-know-only-if-you-grew-up-in-vegas/ 미서부는 라스베가스에 서버를 세팅했습니다…
  41. Param 에 latency data를 그리고 strParam 에는 어떤 액션에 대한 latency 인지 설명하고, 아이피와 유저의 정보, 월드등에 대한 정보를 기록. 활용에 좀 더 용이하게 되었습니다. 아이피마다 측정을 했기 때문에 한유저에 대한 통계를 확실히 뽑을 수 있었습니다…
  42. 아이템 latency만 개발이 되어 이 부분을 바탕으로 분석을 했습니다. 스킬은 클래스마다 사용하는 기본 시간의 차이가 있었기 때문에 스킬 보다는 아이템 latency 를 사용했습니다… CB1이다 보니 유저수는 매우 적었으나, 데이타는 적지 않았기 때문에 불필요한 데이타는 걷어내고 필요한 데이타를 추출해내는 작업을 진행했습니다. python 의 panda 를 사용해서 어떤식으로 데이터를 가공해야할지 개발을 했었습니다. Panda의 연관 데이터들의 grouping 과 필요한 필드들을 추가/가공하고, 조합하는 등의 작업을 진행했었고, ….. 약 백만건의 데이터는 약 5천건의 압축 및 가공된 데이터로 되었고, 이를 바탕으로 실질적인 분석을 했습니다. 유저에게 없는 데이터- 국가 및 위치정보, ISP 정보등은 IP를 바탕으로 free web api (https://freegeoip.net/) 를 호출하여 추출했습니다.
  43. 최종적으로 나온 데이터의 형태. 한 아이피 조합  최소, 평균, 중간, 최대..
  44. 최대, 최소, 4분선…. 평균과 중간값의 차이가 생긴다… 왜냐…
  45. Outlier  상단 4분선 위에 있는 외부값…
  46. DB로 옮긴 데이타의 가공법 확립 분석 방법 및 방향 확립 시각화 방법 확립 – 불완전요소 확인(위치값) 서부 서버로는 전체 커버 불가능 확인
  47. https://kkandori.carto.com/viz/f5962a8c-cb8c-11e5-b18b-0e3a376473ab/public_map 시각화 방법 확립 및 불완전요소 확인(위치값) 서부 서버로는 전체 커버 불가능 확인
  48. 실제로 데이타를 어떻게 가공할지, 어떻게 활용할지, 그리고 어떻게 분석할지는 1차 클베때 다 이뤄졌습니다. 이제 2차 클베는 이 방법을 적용해서 적합한지 여부를 확인하는 것입니다.
  49. 동부에 서버를 두고 FPS를 두었던 경험으로 이 것을 확인했어야 했습니다….
  50. https://www.teamunify.com/Home.jsp?team=eznjslsc 과거에 동부(뉴저지IDC)에 서버를 두고 북미 및 유럽에 FPS를 서비스한 경험이 있기 때문에 이카루스는 어떤지 궁금했습니다. 그리고 비용절감을 위해서 동부에 하나만 두어서 두 대륙을 모두 커버한다면 매우 바람직한 결과일것이라고 생각했습니다. CB1 에서는 DB에서 넘어온 야생의 데이터를 제가 직접 python 으로 데이터를 가공하고 웹 api 를 호출하니 너무 시간이 많이 걸려서, DBA와 GeoIP 데이터베이스의 힘을 빌리기로 했습니다. CB2에서는 더 많은 유저를 대상으로 하기 때문에 데이타또한 CB1보다 훨씬 더 많을 것이라 생각한것도 있었습니다.
  51. 데이터는 좀 적은 양이었지만 성공적이었습니다. 1차는 서부에 서버를 두었을때에는 미 대부분 지역에 200ms 미만이었으나, 2차에서 동부에 서버를 두었을때에는 다른 지역은 괜찮으나 서부지역에서 200ms 미만의 비율이 많이 낮았습니다.
  52. 1차클베때 위치값이 겹쳐서 시각화 하기 어려웠던 부분을 개선했습니다. 그래서 유럽지역의 현황을 좀 더 눈에 보기 쉬웠고.. 하지만, 서유럽은 53% 동유럽은 35% 의 비율로 200ms 미만이 나왔습니다….
  53. 핑과 레이턴시간의 연관성은 0.93 정도입니다. 약 10000개의 데이타에 의한 값이고, 앞선 10,000km 미만의 거리에 따른 ping 값은 170개였는데, 두 값이 비슷하게 나왔습니다. 거리에 따른 ping 과의 연관성은 Ping 과 게임내 latency와의 연관성 정도를 가진다는 예측을 할 수 있었습니다.
  54. 그래서 아마존서비스를 이용해서 내부테스트(약 100여명단위)를 더 진행하기로 했습니다. 아무리 신뢰가 가는 서비스라 할지라도 확인과 검증을 하지 않으면 문제발생에 대한 파악 및 해결시간이 그만큼 더 늘어나기 때문입니다. 일단 테스트 서버를 올려놓고 테스트를 했었고, 서부에서는 테스트가 어려웠기 때문에 유럽쪽에 요청을 해서 테스트를 진행했고, 만족할만한 결과를 얻었습니다. CB3를 진행하면서 실제로 데이터를 더 받아보고 문제가 발생한다면 OBT에 딱 맞추진 못하더라도 다른 지역에 대한 테스트를 진행하는 것으로 합의를 보고, CB3를 북미의 서부와 프랑크푸르트 AWS 에 서버를 두고 오픈을 했습니다.
  55. http://xplorotech.com/hosting-solutions/ 일단 IDC의 네트워크 인프라가 너무 열악해서 수시로 네트웍이 단절되는 현상이 잦았고, 서부까지 커버되는 수준이라서 북미는 가능했지만, 유럽도 일부 서유럽만 커버가 되었기 때문에 동부는 대상에서 제외시키는 것이 좋겠다는 판단을 하기 시작했습니다.
  56. 북미의 경우 서부에 서버를 두는 것이 동부에 두는 것 보다는 나은 것을 1차 클베를 통해서 확인할 수 있었습니다. 그리고, 비용과 관리측면에서는 서부가 용이하다고 판단했고, 동부의 좋은 인프라의 IDC를 찾으면 기대치만큼은 되겠지만 애초에 동부에 서버를 두는 것의 기대는 유럽까지 커버할 수 있길 바란 부분이 컸기 때문에, 동부에 서버를 두는 것은 포기를 했습니다.
  57. CB3와 OBT의 텀이 3주밖에 되지 않았기 때문에 CB3의 값을 가지고 OBT를 준비하는 것이 사실상 불가능했고, 따라서 CB2까지의 값으로 CB3-OBT를 모두 준비해야하는, 즉 결론을 어느정도 내야하는 상황이 되었습니다. ( 1+2차=3차, 변경은 안되고, 제거만 가능 = OB :: 도식화 )
  58. 두번의 클베에 어떤 전략으로 테스트를 할지에 대해서 가설과 계획을 세워야 했죠. 후보지는 미 서/중/동부 그리고 유럽의 서부 정도였습니다. 서부는 라스베가스, 동부는 뉴욕 또는 뉴져지, 유럽의 서부는 런던/프랑크푸르트/룩셈부르크 로 동쪽으로는 터키까지 커버가 가능한것을 목표로 잡았습니다. 남미와 호주쪽에 대한 계획도 있었으나, 이 부분은 비지니스와 마케팅의 요구가 생기면 셋업을 하기로 하고, 어느정도의 latency 가 나오는지 측정만 하기로 했습니다.
  59. https://www.youtube.com/watch?v=2OUTN1Eyv_k 일차적으로 내려진 결론은 서부에 서버를 두면 동부까지 플레이가 원활하게 될 정도의 수준이기 때문에 북미는 커버가 될 것 같고, 유럽을 커버하기 위해서 런던 또는 프랑크푸르트의 아마존 서비스, 그리고 넥슨유럽의 IDC – 룩셈부르크 이렇게 후보지가 결정되었습니다. 런던에 서버를 두면 .. 서유럽은 충분히 커버하겠지만, 동유럽 및 터키까지 커버하기에는 기본적인 ping 값이 높았습니다. 따라서 조금 더 동쪽에 있는 프랑크푸르트 AWS 또는 룩셈부르크였는데, 룩셈부르크는 저희가 사용하기에는 약간의 사정이 생겨서 사용을 못하게 되었고, 프랑크푸르트 밖에 남지 않았습니다.
  60. Eu map : http://mapssite.blogspot.com/2008/11/map-of-europe-countries.html Us map : https://clipartfest.com/categories/view/e1e6b1561afcae051f4aca2b13e1964288791acd/us-map-flag-clipart.html Canada map : http://www.prepaid-wireless-guide.com/cell-phone-providers.htm 캐나다 : 70% 북미 : 78% 유럽 : 88% l
  61. 추가로 .. VPN으로 연결하여 라스베가스 프랑크푸르트 내부보안망 확인