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.

NDC 2015 마비노기 듀얼 패치 시스템

  • Login to see the comments

NDC 2015 마비노기 듀얼 패치 시스템

  1. 1. <마비노기 듀얼> 패치 시스템 김 재석 우리는 바퀴를 다시 만들게 될 것이다. 늘 그랬듯이 ㈜넥슨코리아 데브캣스튜디오 데브캣개발실 듀얼팀 서버파트
  2. 2. 김 재석 E1 (전문연구원) 2014/현재 마비노기 듀얼 2014/2014 링토스 세계여행 2010/2013 마비노기2: 아레나 2006/2009 마비노기 영웅전 2004/2005 마비노기 2003/2004 프로젝트 T2 2001/2013 오즈
  3. 3. 강연의 목적 • 패치 (자동 업데이트) 시스템의 기본 구성 요소를 설명하고 • 모바일 OS에서 어떻게 구성해야 하는지 • 마비노기 듀얼 프로젝트에서 적용한 사례를 바탕으로 • 공유하려고 합니다.
  4. 4. 자동 업데이트 시스템 • 현재 버전이 최신인지를 감지하고 • 최신 버전을 받아 • 프로그램을 최신 상태로 갱신한다
  5. 5. 자동 업데이트 시스템 • 현재 버전이 최신인지를 감지하고 • 최신 버전을 받아 • 프로그램을 최신 상태로 갱신한다 버전 제어 체계 (VCS) 콘텐트 배달망 (CDN) 파일 체계 (FS)
  6. 6. 그런데, 왜 하죠? 온라인 게임 회사가 20년이나 되었으면 준비된 것이 있지 않나요? Lucky Louie, HBO, 2006
  7. 7. 불행히도 (1) • 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다 • 사용자가 처한 환경이 데스크톱 때와 많이 달라졌다 • 개발 환경도 많이 달라졌다 • 당장 운영체제부터 다르다
  8. 8. 불행히도 (2) • 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다 • 배포 플랫폼 (App Store, Google Play, Windows Store) • 단순하지만 긴급한 업데이트가 통과되지 않아 치명적인 문제가 계속된다든가 • 통제할 수 없지만 예측할 수 있다
  9. 9. • 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다 • 배포 플랫폼 (App Store, Google Play, Windows Store) • ∴ 일부는 배포 플랫폼을 활용하고 일부는 만들어 구성한다.
  10. 10. • 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다 • 배포 플랫폼 (App Store, Google Play, Windows Store) • ∴ 일부는 배포 플랫폼을 활용하고 일부는 만들어 구성한다. 무엇을? 어떻게? 왜? 가 이제 할 이야기
  11. 11. 다시 돌아와서 • 버전 제어 체계 (Version Control System) • 콘텐트 배달망 (Content Delivery Network) • 파일 체계 (File System)
 
 각각 어떻게 구현할 지 결정해야 하는데
  12. 12. 다시 돌아와서 • 버전 제어 체계 (Version Control System) • 콘텐트 배달망 (Content Delivery Network) • 파일 체계 (File System)
 
 각각 어떻게 구현할 지 결정해야 하는데 외부 요인에 의해 정해지는 부분부터 해결
  13. 13. 콘텐트 배달망
  14. 14. 콘텐트 배달망 • 자체 프로토콜? • 데이터 센터를 보유하고 있지 않는 한 (아마도) 해서는 안 될 선택 • 선택해야만하는 장점이 있기 전까지는 보류한다
  15. 15. 콘텐트 배달망 • 자체 프로토콜 • 잘 알려진 프로토콜 • BitTorrent
  16. 16. 콘텐트 배달망 • 자체 프로토콜 • 잘 알려진 프로토콜 • BitTorrent
  17. 17. 단점 • 사용자의 패킷 사용량을 증가시킨다 • 대기 중에도 자원을 소모한다 • 상대적으로 구현하기도 복잡하다 BitTorrent 장점 • CDN 비용이 싸게 든다 • 빠를 수도 있다
  18. 18. 단점 • 사용자의 패킷 사용량을 증가시킨다 • 대기 중에도 자원을 소모한다 • 상대적으로 구현하기도 복잡하다 BitTorrent 모든 장점을 상쇄하고도 남을 단점 (1) 모바일 데이터 요금제는 사용량 기반
  19. 19. 단점 • 사용자의 패킷 사용량을 증가시킨다 • 대기 중에도 자원을 소모한다 • 상대적으로 구현하기도 복잡하다 BitTorrent 모든 장점을 상쇄하고도 남을 단점 (2) 배터리 기술 발전은 더디다
  20. 20. 콘텐트 배달망 • 자체 프로토콜 • 잘 알려진 프로토콜 • BitTorrent • HTTP 복잡도가 커진다
  21. 21. HTTP • 대부분의 콘텐트 배달망 회사가 지원한다 • 부하 분산을 예비할 수 있다 • 모바일 운영체제는 웹 시대 이후에 발전했다 • 라이브러리가 기본적으로 제공된다 • 캐시
  22. 22. 콘텐트 배달망 • 자체 프로토콜 • 잘 알려진 프로토콜 • BitTorrent • HTTP CDN • Akamai, CloudFlare, CloudFront, ucloud biz, …
  23. 23. 선정 해야 할 경우 고려 사항 • 명령줄 인터페이스 (CLI) 또는
 응용 프로그램 인터페이스 (API) 를 제공하는가? • 자동화를 할 수 없으면 매우 곤란하다 • 안정성 • 응답 시간 / 배포 시간 (글로벌 배포 고려)
  24. 24. Amazon CloudFront 아마존 웹 서비스를 다루는 기술: 실무에서 필요한 AWS 클라우드의 모든 것! 참고
  25. 25. S3/CloudFront 장점 • S3의 API / 라이브러리가 잘 갖춰져 있음 • 일괄 수행 스크립트를 만들기 위한 언어 선택의 폭도 넓음 • 초기 설정 이후에 S3에서 가장자리 (edge) 서버로 배포는 알아서 잘 됨 • 초기 설정은 SE느님께서 잘 챙겨주셔서 개발팀이 신경 쓸 것이 적다
  26. 26. S3 주의점 • 색인 노출이 안 되도록 설정해야 한다 • 웹 기반 서비스 공통의 주의사항이지만 • S3의 경우 개별 경로 색인을 막아도
 최상단 경로가 열려 있으면 전체 파일 목록이 보임 • 가상 경로를 사용하는 객체 저장소 구조의 특성
  27. 27. CloudFront 주의점 • 가장자리까지 배포되는 데에는 예열이 필요하다 • 가장자리로 배포된 파일은 1일 정도의 캐시 보관을 한다 • 같은 파일이름으로 배포하면 파일이 지연된다. • 따라서 캐시 무효화 명령을 내리거나, • 항상 다른 파일 이름으로 배포해야 한다.
  28. 28. CloudFront 캐시 무효화 • 명령이 전세계 가장자리로 전파되는데 15분 정도 • 배포되면 안 되는 파일을 회수하려는 목적으로는 유용하겠지만
 배포 완료 시기를 예측하기에는 적합하지 않아 배포 용도로는 사용하지 않음
  29. 29. 항상 다른 파일 이름을 사용 • 가상 경로를 생성하고 버전 제어 체계에 각 파일별 가상 경로를 보관하면
 항상 다른 파일 이름으로 접근하는 것이 가능할 것이다
  30. 30. 항상 다른 파일 이름을 사용 • 가상 경로를 생성하고 버전 제어 체계에 각 파일별 가상 경로를 보관하면
 항상 다른 파일 이름으로 접근하는 것이 가능할 것이다 쓸모 없이 비싸기만 할 것 같다?
  31. 31. 버전 제어 체계
  32. 32. 버전 제어 체계 • 버전 제어 체계 (Version Control System) • 분산 버전 제어 체계: Git, Mercurial, Plastic SCM • 상기한 기술들은 자동 업데이트 용도로 한정하면 초과 사양 • 업데이트에 필요한 기술은 제대로 된 버전 제어 체계가 아니라
 브랜치마다 최신 버전을 받을 수 있는 정도면 충분할 것이다
  33. 33. 특정 버전을 받기 위해 • (파일 목록, 버전 정보) 목록이 필요하다: 색인 (index) • 웹으로 주고 받기 위해 JSON 형식 채택
 {
 “path/filename”:{…}
 } • 경로는 중첩해서 쓰지 않고 전체 경로를 사용: 차분 비교/병합에 유리
  34. 34. 비교를 위한 정보들 • 최종 변경 시각 • 파일 크기 • 요약 해시
  35. 35. 비교를 위한 정보들 • 최종 변경 시각 • 파일 크기 • 요약 해시 파일 정보 API 호출 한번에 얻을 수 있다
  36. 36. 비교를 위한 정보들 • 최종 변경 시각 • 파일 크기 • 요약 해시 파일 정보 API 호출 한번에 얻을 수 있다 파일 전체를 읽고 계산해야 한다
  37. 37. 특별한 HTTP 헤더 Content-Length 콘텐트 길이 (바이트 단위) 파일 정합성 검사에 사용 Content-MD5 콘텐트 해시 (MD5, 128b) Cache-Control 재전송 및 캐시 제어 Pragma
  38. 38. 특별한 HTTP 헤더 Last-Modifed 최종 변경일 Expires 만료 기한 ETag 변경 감지
  39. 39. 버전을 판단하기 위한 정보 • Content-Length: 해시 계산을 안 해도 명백한 경우를 진단 • Last-Modified: CDN 개별 웹서버 호스트 정책을 신뢰하지 않아 제외 • ETag: Amazon S3의 경우 MD5 요약의 16진수 표현값을 사용 • 주의: 5G가 넘는 파일은 계산 방법이 다르다
  40. 40. 다시 색인 파일의 형태 • {
 “path1/filename1”:{“length”:123,”md5”:”encoded1”},
 …
 “pathK/filenameK”:{“length”:789,”md5”:”encodedK”}
 }
  41. 41. 인코딩 방법 • 바이너리 인코딩은 Base-N Encoding 사용 • base16, base32, base64, base64url 중 선택 • 요약 해시의 길이는 고정이므로 채움 문자는 사용하지 않음
  42. 42. 실제 파일의 위치 • 색인 상에서 다음과 같은 정보는
 “path/filename”:{”md5”:”digest”} • 매번 새로 파일 이름을 생성할 수도 있지만
 S3 상에서 path/filename/digest 를 사용하는 것으로도 충분하다 • 64b 이내에서 해시 충돌이 발생할 수 있지만
 인접 버전에서 발생할 가능성은 (1/264) 무시해도 좋기 때문
  43. 43. 파일 이름 생성 규칙 • MD5 대신에 증가하는 숫자 등을 써도 되지 않을까? • 가능하다: 하지만 S3는 ETag로 MD5를 사용하고,
 ETag로 다른 값을 사용하는 CDN에서도 Content-MD5 지정을 할 수 있다 • SHA1와 같은 최신 해시를 사용하지 않는 것도 같은 이유 • 무작위 공격에 대한 방어가 목표가 아닌
 관리 상의 충돌만 일어나지 않는 것이 목표
  44. 44. 색인 파일의 배포 • 색인 파일도 파일이다: 파일 길이, 요약 해시 • S3 상의 indexpath/digest 경로에 저장하는 것으로 충분 • 최상위 인터페이스에서는 브랜치 이름을 입력받고 색인 파일을 출력
  45. 45. 예시 (브랜치) GET /project/branch HTTP/1.1
 Host: example.com
 Content-Length: 0
 
 HTTP/1.1 302 Found
 Location: https://example.cloundfront.net/indexpath/branchdigest
 Content-Length: 0
  46. 46. 예시 (색인 파일) GET /indexpath/branchdigest HTTP/1.1
 Host: example.cloundfront.net
 Content-Length: 0
 
 HTTP/1.1 200 OK
 Content-Type: application/json; charset=UTF-8
 
 {
 “empty”:{“length”:0,”md5”:“1B2M2Y8AsgTpgAmY7PhCfg”},
 “dir/filename.txt”:{“length”:4,”md5”:“CY9rzUYh03PK3k6DJie09g”}
 }
  47. 47. 예시 (1) GET /projectroot/empty/1B2M2Y8AsgTpgAmY7PhCfg HTTP/1.1
 Host: example.cloundfront.net
 Content-Length: 0
 
 HTTP/1.1 200 OK
 Content-Length: 0
 ETag: “d41d8cd98f00b204e9800998ecf8427e"
 

  48. 48. 예시 (2) GET /projectroot/dir/filename.txt/CY9rzUYh03PK3k6DJie09g HTTP/1.1
 Host: example.cloundfront.net
 Content-Length: 0
 
 HTTP/1.1 200 OK
 Content-Type: plain/text; charset=UTF-8
 Content-Length: 4
 ETag: “098f6bcd4621d373cade4e832627b4f6"
 
 test

  49. 49. 개발팀 내부에서 색인 생성은 • 일괄 처리 스크립트로 생성 • 로컬 혹은 공유 경로에 원본 파일을 넣고,
 일괄 처리 스크립트가 파일을 읽으면서 저장소에 저장하고
 색인 파일을 로컬에 생성 • 로컬에 생성된 색인 파일은 따로 버전 관리
  50. 50. 개발팀 내부에서 버전 관리는 • 색인 파일은 JSON 파일이므로 배포 시마다 기존 버전 제어 체계에 (git) 제출 • 저장소에 (S3) 올라간 실제 파일들은 여러 버전이 섞여 있음
 색인 파일로부터 접근하기 때문 • 저장 비용 절감을 위해서는: 색인 파일을 저장소에서 삭제할 때
 모든 색인파일에서 접근할 수 없는 버전을 찾아 지운다
 (일종의 쓰레기 수거)
  51. 51. 배포 관리는 • 각 배포판마다 색인 파일을 비교해서 병합 • 텍스트 파일이고, 파일 하나의 정보가 한 줄이므로 기존 도구 활용이 용이하다 • 파일 정보로부터 실제 리소스 파일을 확인할 수 있는 도구는 필요 • 문자열 생성 후 웹브라우저 열기가 전부
  52. 52. 만들고 보니 • 기존 버전 제어 체계와 웹 저장소를 조합한
 분산 색인 + 리소스 중앙집중식 버전 제어 체계 • 색인만 기존 버전 제어 체계를 사용하기 때문에 분산해도
 모든 대형 리소스를 보관하지 않음 • 리소스 저장소는 중앙 집중식이지만 전세계에서 빠르게 접근 가능 • 구현 난이도도 높지 않음
  53. 53. 파일 체계
  54. 54. 고려 사항 • 파일 묶음 (archive) • 압축 • 암호화
  55. 55. – Richard Hill, Hewlett-Packard S.A., Geneva, Switzerland “Don't write a new program if one already does more or less what you want.
 And if you must write a program, use existing code to do as much of the work as possible.”
  56. 56. 안 만드는 이유: 묶음 처리 • 데스크톱에서는 디스크 헤드 이동을 줄여 파일 입출력 시간을 빠르게 하기 위해 • 모바일에서는 디스크가 아닌 메모리 사용
  57. 57. 안 만드는 이유: 파일 보안 • 모바일 OS에서 응용 데이터 경로는 기본적으로 막혀 있음 • 안드로이드의 경우 미디어 검색에서 제외: .nomedia • 대부분의 경우 민감한 파일도 없다 • 있다면 민감한 파일만 모아 압축하고 암호화
  58. 58. 지역화 리소스 업데이트
  59. 59. 지역화 리소스 • 언어-국가 별로 다른 리소스가 필요하다 • 저장 용량, 네트워크 사용량의 문제로 분리해서 관리할 필요가 있음 • 번체 지역에 간체, 간체 지역에 번체 폰트가 배포돼도 사용되지 않음
  60. 60. 지역화 리소스의 특징 (1) • 선택 우선 순위가 명백하다 (좁은 로케일에서 넓은 로케일 순) • 사용자 정의 로케일 (ko-KR-x-private) • 언어-국가 로케일 (ko-KR) • 언어 로케일 공통 (ko) • 불변 로케일 (invariant)
  61. 61. 지역화 리소스의 특징 (2) • 사용자에 의해 쓰기가 발생하지 않는다 • 업데이트할 때를 빼고는 사실상 읽기 전용 • 잘 분류된 경우 로케일별로 겹치는 파일은 거의 없다 • ∴ 모두 받고 우선 순위에 따라 읽는다
 저장소가 여러 개가 있는 것처럼 처리
  62. 62. 개발 리소스 배포 제한
  63. 63. 문제 • 개발 중인 리소스가 실수로 배포되지 않아야 한다 • 관리하기 비교적 편하게
  64. 64. 배포를 막는 방법 • 발효 시각-만료 시각을 기록하는 방법
  65. 65. 배포를 막는 방법 • 발효 시각-만료 시각을 기록하는 방법 • (업데이트 일정 등의) 시각은 예상하기 어려움 • 종속성 설정을 만들고 특정 목록만 받도록 하는 방법 • 스프레드시트 파일로부터 생성한다면 (VBA) 관리할만하다
  66. 66. 종속성 설정 • 색인 파일과 달리 저장소 공통으로 사용 (상대 경로가 동일한 파일이 많으므로) • JSON 형식 사용
 {
 “#main”:{“dependsOn”:[”#card”,”#portrait”]},
 “cardpath/card1.png”:{“affects”:”#card”},
 “imagepath/npc1.png”:{“affects”:”#portrait”}
 } • URL에 사용되지 않는 문자를 태깅에 이용
  67. 67. 종속성 적용 • 각각의 종속성 목록은 이행 폐쇄를 (transitive closure) 구해 적용 • 사고를 막기 위해 금지를 허가보다 우선시 한다 • 제외 목록에 있는 파일은 빼고 • 남은 파일 중 포함 목록에 있는 파일만 받는다 • 예: #portrait을 빼고 #main을 받으면 예시에서는 #card만 받음
  68. 68. 정리
  69. 69. 용도별 업데이트 방법 • 바이너리: 패키지를 배포 플랫폼에 제출해 업데이트 한다 • 리소스: 색인 파일을 배포하고 동기화한다 • 색인은 (경로, 길이, 요약) 정보로 구성한다
  70. 70. 지역화 리소스 배포 방법 • 로케일의 우선순위를 정하고 • 로케일마다 색인 파일을 따로 생성해서 • 구동하는데 필요한 모든 로케일의 파일을 받도록 한다 • 파일을 실제로 읽을 때에는 우선순위에 따라 읽는다
  71. 71. 개발 리소스 배포를 막는 방법 • 리소스의 종류를 구분해서 미리 표시해 놓고 • 배포에 포함된 것으로 표시된 파일들에 대해서만 받도록 설정한다
  72. 72. Q&A twitter:@tcaesvk

×