1. <마비노기 듀얼> 패치 시스템
김 재석
우리는 바퀴를 다시 만들게 될 것이다. 늘 그랬듯이
㈜넥슨코리아 데브캣스튜디오 데브캣개발실 듀얼팀 서버파트
2. 김 재석
E1 (전문연구원)
2014/현재 마비노기 듀얼
2014/2014 링토스 세계여행
2010/2013 마비노기2: 아레나
2006/2009 마비노기 영웅전
2004/2005 마비노기
2003/2004 프로젝트 T2
2001/2013 오즈
3. 강연의 목적
• 패치 (자동 업데이트) 시스템의 기본 구성 요소를 설명하고
• 모바일 OS에서 어떻게 구성해야 하는지
• 마비노기 듀얼 프로젝트에서 적용한 사례를 바탕으로
• 공유하려고 합니다.
4. 자동 업데이트 시스템
• 현재 버전이 최신인지를 감지하고
• 최신 버전을 받아
• 프로그램을 최신 상태로 갱신한다
5. 자동 업데이트 시스템
• 현재 버전이 최신인지를 감지하고
• 최신 버전을 받아
• 프로그램을 최신 상태로 갱신한다
버전 제어 체계 (VCS)
콘텐트 배달망 (CDN)
파일 체계 (FS)
6. 그런데, 왜 하죠?
온라인 게임 회사가 20년이나 되었으면 준비된 것이 있지 않나요?
Lucky Louie, HBO, 2006
7. 불행히도 (1)
• 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다
• 사용자가 처한 환경이 데스크톱 때와 많이 달라졌다
• 개발 환경도 많이 달라졌다
• 당장 운영체제부터 다르다
8. 불행히도 (2)
• 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다
• 배포 플랫폼 (App Store, Google Play, Windows Store)
• 단순하지만 긴급한 업데이트가 통과되지 않아 치명적인 문제가 계속된다든가
• 통제할 수 없지만 예측할 수 있다
9. • 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다
• 배포 플랫폼 (App Store, Google Play, Windows Store)
• ∴ 일부는 배포 플랫폼을 활용하고 일부는 만들어 구성한다.
10. • 모바일에서는 데스크톱에서 만든 환경을 그대로 가져다 쓸 수 없다
• 배포 플랫폼 (App Store, Google Play, Windows Store)
• ∴ 일부는 배포 플랫폼을 활용하고 일부는 만들어 구성한다.
무엇을? 어떻게? 왜? 가 이제 할 이야기
11. 다시 돌아와서
• 버전 제어 체계 (Version Control System)
• 콘텐트 배달망 (Content Delivery Network)
• 파일 체계 (File System)
각각 어떻게 구현할 지 결정해야 하는데
12. 다시 돌아와서
• 버전 제어 체계 (Version Control System)
• 콘텐트 배달망 (Content Delivery Network)
• 파일 체계 (File System)
각각 어떻게 구현할 지 결정해야 하는데
외부 요인에 의해
정해지는 부분부터 해결
25. S3/CloudFront 장점
• S3의 API / 라이브러리가 잘 갖춰져 있음
• 일괄 수행 스크립트를 만들기 위한 언어 선택의 폭도 넓음
• 초기 설정 이후에 S3에서 가장자리 (edge) 서버로 배포는 알아서 잘 됨
• 초기 설정은 SE느님께서 잘 챙겨주셔서 개발팀이 신경 쓸 것이 적다
26. S3 주의점
• 색인 노출이 안 되도록 설정해야 한다
• 웹 기반 서비스 공통의 주의사항이지만
• S3의 경우 개별 경로 색인을 막아도
최상단 경로가 열려 있으면 전체 파일 목록이 보임
• 가상 경로를 사용하는 객체 저장소 구조의 특성
27. CloudFront 주의점
• 가장자리까지 배포되는 데에는 예열이 필요하다
• 가장자리로 배포된 파일은 1일 정도의 캐시 보관을 한다
• 같은 파일이름으로 배포하면 파일이 지연된다.
• 따라서 캐시 무효화 명령을 내리거나,
• 항상 다른 파일 이름으로 배포해야 한다.
28. CloudFront 캐시 무효화
• 명령이 전세계 가장자리로 전파되는데 15분 정도
• 배포되면 안 되는 파일을 회수하려는 목적으로는 유용하겠지만
배포 완료 시기를 예측하기에는 적합하지 않아 배포 용도로는 사용하지 않음
29. 항상 다른 파일 이름을 사용
• 가상 경로를 생성하고 버전 제어 체계에 각 파일별 가상 경로를 보관하면
항상 다른 파일 이름으로 접근하는 것이 가능할 것이다
30. 항상 다른 파일 이름을 사용
• 가상 경로를 생성하고 버전 제어 체계에 각 파일별 가상 경로를 보관하면
항상 다른 파일 이름으로 접근하는 것이 가능할 것이다
쓸모 없이 비싸기만 할 것 같다?
32. 버전 제어 체계
• 버전 제어 체계 (Version Control System)
• 분산 버전 제어 체계: Git, Mercurial, Plastic SCM
• 상기한 기술들은 자동 업데이트 용도로 한정하면 초과 사양
• 업데이트에 필요한 기술은 제대로 된 버전 제어 체계가 아니라
브랜치마다 최신 버전을 받을 수 있는 정도면 충분할 것이다
33. 특정 버전을 받기 위해
• (파일 목록, 버전 정보) 목록이 필요하다: 색인 (index)
• 웹으로 주고 받기 위해 JSON 형식 채택
{
“path/filename”:{…}
}
• 경로는 중첩해서 쓰지 않고 전체 경로를 사용: 차분 비교/병합에 유리
39. 버전을 판단하기 위한 정보
• Content-Length: 해시 계산을 안 해도 명백한 경우를 진단
• Last-Modified: CDN 개별 웹서버 호스트 정책을 신뢰하지 않아 제외
• ETag: Amazon S3의 경우 MD5 요약의 16진수 표현값을 사용
• 주의: 5G가 넘는 파일은 계산 방법이 다르다
40. 다시 색인 파일의 형태
• {
“path1/filename1”:{“length”:123,”md5”:”encoded1”},
…
“pathK/filenameK”:{“length”:789,”md5”:”encodedK”}
}
41. 인코딩 방법
• 바이너리 인코딩은 Base-N Encoding 사용
• base16, base32, base64, base64url 중 선택
• 요약 해시의 길이는 고정이므로 채움 문자는 사용하지 않음
42. 실제 파일의 위치
• 색인 상에서 다음과 같은 정보는
“path/filename”:{”md5”:”digest”}
• 매번 새로 파일 이름을 생성할 수도 있지만
S3 상에서 path/filename/digest 를 사용하는 것으로도 충분하다
• 64b 이내에서 해시 충돌이 발생할 수 있지만
인접 버전에서 발생할 가능성은 (1/264) 무시해도 좋기 때문
43. 파일 이름 생성 규칙
• MD5 대신에 증가하는 숫자 등을 써도 되지 않을까?
• 가능하다: 하지만 S3는 ETag로 MD5를 사용하고,
ETag로 다른 값을 사용하는 CDN에서도 Content-MD5 지정을 할 수 있다
• SHA1와 같은 최신 해시를 사용하지 않는 것도 같은 이유
• 무작위 공격에 대한 방어가 목표가 아닌
관리 상의 충돌만 일어나지 않는 것이 목표
44. 색인 파일의 배포
• 색인 파일도 파일이다: 파일 길이, 요약 해시
• S3 상의 indexpath/digest 경로에 저장하는 것으로 충분
• 최상위 인터페이스에서는 브랜치 이름을 입력받고 색인 파일을 출력
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
49. 개발팀 내부에서 색인 생성은
• 일괄 처리 스크립트로 생성
• 로컬 혹은 공유 경로에 원본 파일을 넣고,
일괄 처리 스크립트가 파일을 읽으면서 저장소에 저장하고
색인 파일을 로컬에 생성
• 로컬에 생성된 색인 파일은 따로 버전 관리
50. 개발팀 내부에서 버전 관리는
• 색인 파일은 JSON 파일이므로 배포 시마다 기존 버전 제어 체계에 (git) 제출
• 저장소에 (S3) 올라간 실제 파일들은 여러 버전이 섞여 있음
색인 파일로부터 접근하기 때문
• 저장 비용 절감을 위해서는: 색인 파일을 저장소에서 삭제할 때
모든 색인파일에서 접근할 수 없는 버전을 찾아 지운다
(일종의 쓰레기 수거)
51. 배포 관리는
• 각 배포판마다 색인 파일을 비교해서 병합
• 텍스트 파일이고, 파일 하나의 정보가 한 줄이므로 기존 도구 활용이 용이하다
• 파일 정보로부터 실제 리소스 파일을 확인할 수 있는 도구는 필요
• 문자열 생성 후 웹브라우저 열기가 전부
52. 만들고 보니
• 기존 버전 제어 체계와 웹 저장소를 조합한
분산 색인 + 리소스 중앙집중식 버전 제어 체계
• 색인만 기존 버전 제어 체계를 사용하기 때문에 분산해도
모든 대형 리소스를 보관하지 않음
• 리소스 저장소는 중앙 집중식이지만 전세계에서 빠르게 접근 가능
• 구현 난이도도 높지 않음
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. 안 만드는 이유: 묶음 처리
• 데스크톱에서는 디스크 헤드 이동을 줄여 파일 입출력 시간을 빠르게 하기 위해
• 모바일에서는 디스크가 아닌 메모리 사용
57. 안 만드는 이유: 파일 보안
• 모바일 OS에서 응용 데이터 경로는 기본적으로 막혀 있음
• 안드로이드의 경우 미디어 검색에서 제외: .nomedia
• 대부분의 경우 민감한 파일도 없다
• 있다면 민감한 파일만 모아 압축하고 암호화
65. 배포를 막는 방법
• 발효 시각-만료 시각을 기록하는 방법
• (업데이트 일정 등의) 시각은 예상하기 어려움
• 종속성 설정을 만들고 특정 목록만 받도록 하는 방법
• 스프레드시트 파일로부터 생성한다면 (VBA) 관리할만하다
66. 종속성 설정
• 색인 파일과 달리 저장소 공통으로 사용 (상대 경로가 동일한 파일이 많으므로)
• JSON 형식 사용
{
“#main”:{“dependsOn”:[”#card”,”#portrait”]},
“cardpath/card1.png”:{“affects”:”#card”},
“imagepath/npc1.png”:{“affects”:”#portrait”}
}
• URL에 사용되지 않는 문자를 태깅에 이용
67. 종속성 적용
• 각각의 종속성 목록은 이행 폐쇄를 (transitive closure) 구해 적용
• 사고를 막기 위해 금지를 허가보다 우선시 한다
• 제외 목록에 있는 파일은 빼고
• 남은 파일 중 포함 목록에 있는 파일만 받는다
• 예: #portrait을 빼고 #main을 받으면 예시에서는 #card만 받음
