1. 만들고 붓고 부수고
김찬웅
〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
넥슨 컴퍼니 왓 스튜디오

2. 저작물 인용
저작권법 제35조의 3 ‘공정이용’ 조항에 따라 교육과 연구 목적으로 이용
하고 있습니다. 혹시 문제가 있을 경우, cwkim@nexon.co.kr 로 연락
주시면 적절한 조치를 취하겠습니다.

3. 김찬웅
넥슨, 왓 스튜디오, 백엔드 엔지니어
자동화가 취미인 프로그래머
• NDC15 <그룹웨어에 새 에너지를>
• NDC16 <Find My AndPhone>
• NDC16 <Effective Git>
• NDC17 <왓 스튜디오 서비스파트>kexplo
https://chanwoong.kim
cwkim@nexon.co.kr
kexplo

4. 만들고 붓고 부수고
〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기

5. 발표에서 다룰 내용
• 서버 인프라 관리
• 인프라 관리 변천사
• 변천 과정에서 도입한 도구 소개

6. 발표에서 다루지 않는 내용
• 게임 서버 아키텍처
• 게임 플레이 프로그래밍

7. 초기 〈야생의 땅: 듀랑고〉의 서버 인프라 관리

9. 초기에 AWS를 사용할 때

10. 초기에 AWS를 사용할 때
일단 웹 콘솔에 들어가서

11. 초기에 AWS를 사용할 때
일단 웹 콘솔에 들어가서
EC2 인스턴스를 하나 만들고

12. 초기에 AWS를 사용할 때
일단 웹 콘솔에 들어가서
EC2 인스턴스를 하나 만들고
IP 주소를 확인하고 SSH로 들어가서

13. 초기에 AWS를 사용할 때
일단 웹 콘솔에 들어가서
EC2 인스턴스를 하나 만들고
IP 주소를 확인하고 SSH로 들어가서
필요한 걸 설치하고

14. 초기에 AWS를 사용할 때
일단 웹 콘솔에 들어가서
EC2 인스턴스를 하나 만들고
IP 주소를 확인하고 SSH로 들어가서
필요한 걸 설치하고
원하는 작업을 수행

15. 삭제도 수동으로

16. 왜 안 되지?
뭘 빼먹었지?
이런 방식이면 언젠간..

17. 전부 수동으로 관리하다 보면,
실수할 여지가 많고,
숙련되지 않으면 빠르게 수행하기도 어렵다.

18. 자동화..
흠..

19. 자동화..
흠..
내가 안 하면 자동이지
남을 시킬까?

20. 자동화 하면 빠질 수 없는게 바로..
Application Programming Interface

21. Boto 3
https://boto3.readthedocs.io/en/latest/guide/quickstart.html

22. EC2를 원하는 스펙으로 생성하는
CLI 프로그램을 제작
>_
Command line interface

23. http://click.pocoo.org/5/

25. 시스템 설정, 배포는 Fabric으로
http://www.fabfile.org/

26. Fabric
Fabric은 agent 없이 동작하는 (agentless) 배포 도구

27. Fabric
Fabric은 agent 없이 동작하는 (agentless) 배포 도구

28. Fabric은 fabtools와 함께 사용하면 매우
효율적으로 사용할 수 있습니다

29. fabtools

30. fabtools
fabtools는 많은 low-level 행동들을 인터페이스로 제공합니다

31. fabtools
fabtools는 많은 low-level 행동들을 인터페이스로 제공합니다
덕분에 선언적인 배포 코드를 짤 수 있습니다

32. https://docs.gitlab.com/ee/ci/multi_project_pipeline_graphs.html

33. 저장소에 코드 푸시
Fabric
= 호스트

34. Fabric
저장소에 코드 푸시
CI 테스트 통과
= 호스트

35. Fabric
CI 테스트 통과
저장소에 코드 푸시
= 호스트

36. Fabric
배포저장소에 코드 푸시
CI 테스트 통과
= 호스트

37. Fabric
배포저장소에 코드 푸시
CI 테스트 통과
= 호스트

38. 인스턴스 식별

39. 인스턴스 식별
인스턴스에는 식별할 수 있는 Tag 들을 달았습니다

40. 인스턴스 식별
인스턴스에는 식별할 수 있는 Tag 들을 달았습니다
Fabric을 이용할 때, 이 Tag를 가지고 배포 대상을 추려낼 수 있었습니다

41. Limited Beta Test를 겪으며

42. = 호스트

43. 자동화된 생성, 제거, 배포
자동화의 영역 수동의 영역
Name Type Count
server1 m4.large 4
server2 m4.2xlarge 2
server3 m4.large 1
>_
수동으로 관리되던 인프라 구성 관리

44. 자동화의 영역 수동의 영역
Name Type Count
server1 m4.large 3
server2 m4.2xlarge 2 1
server3 m4.large 1
server4 m4.large 1
>_
자동화된 생성, 제거, 배포
수동으로 관리되던 인프라 구성 관리
인프라 구성이 바뀌면, 인프라 정보 동기화 필요!!

45. Fabric
배포저장소에 코드 푸시
GitLab CI
앱 배포 시, Git 저장소에서 필요한 코드를 복제

46. Fabric
배포저장소에 코드 푸시
셀프 DDoS Attack!
앱 배포 시, Git 저장소에서 필요한 코드를 복제
DDoS attack: Distributed Denial of Service attack
GitLab CI

47. Fabric
배포저장소에 코드 푸시
큰 규모의 인프라가, 저장소 서버에 과부하를 야기!!
셀프 DDoS Attack!
DDoS attack: Distributed Denial of Service attack
GitLab CI
앱 배포 시, Git 저장소에서 필요한 코드를 복제

48. 마일스톤 막바지가 되면..
※ 설치형 GitLab EE를 사용하고 있습니다.
GitLab 코드 푸시
GitLab 장애
코드 푸시를 못 함. (쌓임)
GitLab이 살아남 배포 (DDoS를 야기)

50. 앞의 문제들을 해결해야 했습니다
• 인프라 관리 자동화
• 배포 정상화

51. 인프라 관리 대안

53. Infrastructure as code

54. Infrastructure as code

55. Infrastructure as code
t2.micro

56. • 인프라(코드)의 버전 관리 가능
• AWS 제품별 API(boto)를 직접 만지지 않아도 됨
• 인프라의 모듈화 가능
• 인프라의 생성/복제/제거가 자유로워 짐
• 그 외 코드가 갖는 모든 장점
• Code review
• Merge request

57. 인프라 복제
develop

58. 인프라 복제
develop
nightly

59. 인프라 복제
develop
nightly
canary

60. 인프라 삭제
develop
nightly
canary
$ terraform destroy

61. 배포 저장소 과부화 대안

62. Debian Packaging

63. 〈야생의 땅: 듀랑고〉의 게임 서버는
Python을 사용합니다

64. Python 프로그램을 배포하는 4가지 방법
• Git+pip
• Docker
• PEX
• dh-virtualenv

65. pip은 Python 패키지를 설치하는 도구
Python Package Index(https://pypi.org/)로부터 패키지를
내려받아 설치하거나, Git 저장소에서 내려받아 설치할 수 있다.
Git+pip

66. Docker는 컨테이너 가상화 도구
VM과 달리 컨테이너 단위로 환경을 격리해 준다
프로그램과 필요한 의존성을 모아 컨테이너화해서 사용할 수 있다
Docker

67. PEX (Python EXecutable)는 Python 의존성을 같이 패키징
한 .pex 라는 단일 실행 파일을 만들어주는 도구
PEX
https://github.com/pantsbuild/pex

68. PEX (Python EXecutable)는 Python 의존성을 같이 패키징
한 .pex 라는 단일 실행 파일을 만들어주는 도구
PEX
https://github.com/pantsbuild/pex

69. dh-virtualenv는 Python 의존성을 포함한 Debian 패키지 파일
을 생성하는 도구
Debian 패키지를 빌드하는 debhelper의 빌드 과정에
dh_virtualenv 빌드 시퀀스를 추가하여 동작하는 방식
dh-virtualenv
https://github.com/spotify/dh-virtualenv

70. 부끄럽지만..
pip으로 내부 Git 저장소를 통해 설치하는 방식으로 배포를 하고 있었고,
이게 GitLab에 부하를 일으켰던 원인

71. 듀랑고의 서버를 이루는 노드는 모두 연결을 맺고 있는데

72. Docker를 사용하게 되면, 이 때 사용하는
ephemeral ports를 모두 “EXPOSE” 할 수 없었다

73. PEX로는 당시에 Cython등 의존하고 있는 몇 가지 요소를
미리 설치해 놓을 수 없었고
최종적으로 dh-virtualenv를 사용하기로 결정

74. Fabric
배포저장소에 코드 푸시
GitLab CI
패키지 빌드
S3 업로드 배포 과정에서 S3에 있는 패키지 설치

75. Fabric
배포저장소에 코드 푸시
GitLab CI
패키지 빌드
S3 업로드 배포 과정에서 S3에 있는 패키지 설치

76. Fabric
배포저장소에 코드 푸시
GitLab CI
패키지 빌드
S3 업로드 배포 과정에서 S3에 있는 패키지 설치

77. Fabric
배포저장소에 코드 푸시
GitLab CI
패키지 빌드
S3 업로드 배포 과정에서 S3에 있는 패키지 설치
S3는 높은 가용성을 가지고 있기 때문에 버틸 수 있다

78. 추가적인 배포 최적화

79. OS 설정
의존성
AWS는 EC2 이미지인 AMI를 지원한다.
AMI에는 각종 의존성과 OS 설정을 넣어 만들어 놓곤 했는데..
Amazon Machine Image

80. OS 설정
의존성
만들기가 번거롭다 보니, 쉽게 낡아 버리곤 했다
AWS는 EC2 이미지인 AMI를 지원한다.
AMI에는 각종 의존성과 OS 설정을 넣어 만들어 놓곤 했는데..
Amazon Machine Image

81. Fabric
배포
GitLab

82. Fabric
배포
GitLab
그러다 보니 배포 과정에 추가 의존성 설치를 하고 있었다.
추가 의존성 설치

83. Fabric
배포
GitLab
그러다 보니 배포 과정에 추가 의존성 설치를 하고 있었다
배포 속도를 늦추고, 모든 의존성을 한눈에 볼 수 없었다
추가 의존성 설치

85. 다양한 타입의 머신 이미지를 만들 수 있는 도구

88. Packer를 이용해
의존성을 한 곳에서 버전 관리 할 수 있었고,
AMI를 만들어 사용하기도 편해졌다.

89. 서비스 오픈을 앞두고

90. 서비스용 인프라 구축
개발용 VPC

91. 서비스용 인프라 구축
개발용 VPC
기존에는 개발용 VPC에 모든 인프라를 섞어서 쓰고 있었는데…

92. 서비스용 인프라 구축
• 기존에는 개발 VPC에 모든 인프라가 뒤섞여 있었음
• 서비스에서는 서버가 개별 VPC에 분리되어야 함
• 개별 VPC는 운영에 필요한 요소도 전부 갖춰야 함

93. 서비스용 인프라 구축
개발용 VPC

94. 서비스용 인프라 구축
개발용 VPC
module
module
module

95. 서비스용 인프라 구축
개발용 VPC
module
module
module
사실 모두 Terraform 모듈화 되어있었고

96. 서비스용 인프라 구축
개발용 VPC
module
module
module
EC2가 아닌 인프라도 관리할 수 있게 되었다
사실 모두 Terraform 모듈화 되어있었고

97. 서비스용 인프라 구축
개발용 VPC
module
module
module
라이브용 VPC
module
module
module

98. 서비스용 인프라 구축
개발용 VPC
module
module
module
라이브용 VPC
module
module
module
덕분에 라이브용 VPC를 구축할 때, 원하는 요소를 원하는 규모로 복제할 수 있었다

99. 참 쉽죠?

100. = 호스트
더 더 많아진 수량

101. 배포를..

102. 배포를..하는데

103. 배포를..하는데..시간이

104. 배포를..하는데..시간이..너무 걸린다!

105. 게다가
병렬 옵션(-P)을 켜면
호스트별 출력이 모두 섞여버려서
실패한 호스트가 있을 경우 찾기가 힘듦
총 머신 수가 많아지면서 간혹 배포에 실패하는 경우의 수도 많아졌다

107. 사실 fabtools는 Ubuntu 16.04를 지원하지 않을 정도로 낡아 있었고

109. 관리가 안 되는 것처럼 보여, 내부에서 수정된 버전을 쓰고 있었습니다

110. Fabric도 Fabric 2.x의 개발에 집중하려는 모양새였습니다

111. 이 상황에서
당장은 실패한 호스트 목록 표시를 패치 했지만
장기적으로는 다른 대안이 필요하다고 결정

112. 해결 해야 할 배포 문제들
• 느린 배포
• 지속가능한 배포 도구

113. 배포 전용 호스트 도입
느린 배포를 해결할

116. 지속 가능한 배포 도구

118. • 동작 방식이 기존과 유사 (agentless)
• Python으로 되어있어 유사시 직접 고쳐 쓰기 편함
• 커뮤니티 활성
다음과 같은 특징으로 선택하게 됨

123. 1000여 개의 모듈을 제공
기존의 Fabric 배포를 마이그레이션 하는데
전혀 어려움이 없었다
오히려 코딩량이 더 줄어버릴 정도

124. 멱등성
멱등성(冪等性, 영어: idempotence)은 수학이나 전산학에서
연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더
라도 결과가 달라지지 않는 성질을 의미한다.

125. 멱등성

126. 멱등성

127. 멱등성
첫 번째 실행

128. 멱등성
첫 번째 실행

129. 멱등성
두 번째 실행

130. 멱등성
두 번째 실행

131. Ansible이 수행을 마치면 출력하는 Play Recap에서 실패한 호스트를 따로 볼 수 있다
실패 호스트는?

132. Ansible은 실패 호스트를 <playbook filename>.retry
파일을 자동으로 만들어 기록한다.
바로 전 실행 명령어 뒤에 --limit @<playbook filename>.retry
옵션을 붙이면, 실패한 호스트만 재시도할 수 있다
멱등성 덕분에, 혹시나 중복 실행이 가져오는 부작용을 걱정하지 않아도 된다.
실패 호스트는?

133. 서비스 오픈 이후

135. terraform applying… terraform applying…

136. 인프라를 실수 없이 복제하는 일은 Terraform에 맡기고
중요한 초반 이슈를 해결하는데 집중할 수 있었다

137. 대표적으로…

138. 대표적으로…
서버 노드가 어떠한 원인으로 죽게 되면, 다른 노드에 전파되어 동반자살 하게 되는 버그였습니다

139. 오픈 이후 해결되어, 자유로운 종료와 감축이 가능!
이를 바탕으로 무중단 배포를 실현!
자세한 내용은 아래 발표에서
Rolling Update

140. 구버전
신버전
무중단 배포?

141. 구버전
신버전
무중단 배포?

142. 구버전
신버전
무중단 배포?

146. 아직 Fabric을 사용했다면…
직접 Rolling update 정책을 짰어야 했을 것
Ansible의 잠재력을 통해, 변화되는 배포 상황에 유연하게
대처할 수 있었다

147. 그 다음?

148. ChatOps, ClickOps
현재 각 절차는 모두 자동화되어 있어, 다음과 같은 시나리오가 가능
• Jenkins, Rundeck 같은 CI에 연동해 클릭으로 모든 것을 관리
• SlackBot 등을 이용해 채팅으로 관리

149. 정리

150. 손으로 관리 Fabric 배포 도구 도입
API 자동화
Terraform으로
인프라 관리
Ansible 배포 도구 도입
작은 인프라 큰 인프라 더 큰 인프라
>_

151. 손으로 관리 Fabric 배포 도구 도입
API 자동화
Terraform으로
인프라 관리
Ansible 배포 도구 도입
작은 인프라 큰 인프라 더 큰 인프라
>_
인프라 투명성, 기록 가능

152. 손으로 관리 Fabric 배포 도구 도입
API 자동화
Terraform으로
인프라 관리
Ansible 배포 도구 도입
작은 인프라 큰 인프라 더 큰 인프라
>_
규모 대응, 지속가능성

153. Cloud를 쓰신다면 Terraform과 Packer는 꼭 고려해볼 것을 추천
배포 도구는 본인의 인프라 규모, 방법에 따라 결정
AWS외의 다양한 Cloud 환경을 지원

154. 감사합니다

155. WE'RE HIRING!http://what.studio/