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.

[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기

988 views

Published on

NDC 2018, "만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기" 발표 자료입니다.

Published in: Engineering
  • Be the first to comment

[NDC18] 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기

  1. 1. 만들고 붓고 부수고 김찬웅 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기 넥슨 컴퍼니 왓 스튜디오
  2. 2. 저작물 인용 저작권법 제35조의 3 ‘공정이용’ 조항에 따라 교육과 연구 목적으로 이용 하고 있습니다. 혹시 문제가 있을 경우, cwkim@nexon.co.kr 로 연락 주시면 적절한 조치를 취하겠습니다.
  3. 3. 김찬웅 넥슨, 왓 스튜디오, 백엔드 엔지니어 자동화가 취미인 프로그래머 • NDC15 <그룹웨어에 새 에너지를> • NDC16 <Find My AndPhone> • NDC16 <Effective Git> • NDC17 <왓 스튜디오 서비스파트>kexplo https://chanwoong.kim cwkim@nexon.co.kr kexplo
  4. 4. 만들고 붓고 부수고 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
  5. 5. 발표에서 다룰 내용 • 서버 인프라 관리 • 인프라 관리 변천사 • 변천 과정에서 도입한 도구 소개
  6. 6. 발표에서 다루지 않는 내용 • 게임 서버 아키텍처 • 게임 플레이 프로그래밍
  7. 7. 초기 〈야생의 땅: 듀랑고〉의 서버 인프라 관리
  8. 8. 초기에 AWS를 사용할 때
  9. 9. 초기에 AWS를 사용할 때 일단 웹 콘솔에 들어가서
  10. 10. 초기에 AWS를 사용할 때 일단 웹 콘솔에 들어가서 EC2 인스턴스를 하나 만들고
  11. 11. 초기에 AWS를 사용할 때 일단 웹 콘솔에 들어가서 EC2 인스턴스를 하나 만들고 IP 주소를 확인하고 SSH로 들어가서
  12. 12. 초기에 AWS를 사용할 때 일단 웹 콘솔에 들어가서 EC2 인스턴스를 하나 만들고 IP 주소를 확인하고 SSH로 들어가서 필요한 걸 설치하고
  13. 13. 초기에 AWS를 사용할 때 일단 웹 콘솔에 들어가서 EC2 인스턴스를 하나 만들고 IP 주소를 확인하고 SSH로 들어가서 필요한 걸 설치하고 원하는 작업을 수행
  14. 14. 삭제도 수동으로
  15. 15. 왜 안 되지? 뭘 빼먹었지? 이런 방식이면 언젠간..
  16. 16. 전부 수동으로 관리하다 보면, 실수할 여지가 많고, 숙련되지 않으면 빠르게 수행하기도 어렵다.
  17. 17. 자동화.. 흠..
  18. 18. 자동화.. 흠.. 내가 안 하면 자동이지 남을 시킬까?
  19. 19. 자동화 하면 빠질 수 없는게 바로.. Application Programming Interface
  20. 20. Boto 3 https://boto3.readthedocs.io/en/latest/guide/quickstart.html
  21. 21. EC2를 원하는 스펙으로 생성하는 CLI 프로그램을 제작 >_ Command line interface
  22. 22. http://click.pocoo.org/5/
  23. 23. 시스템 설정, 배포는 Fabric으로 http://www.fabfile.org/
  24. 24. Fabric Fabric은 agent 없이 동작하는 (agentless) 배포 도구
  25. 25. Fabric Fabric은 agent 없이 동작하는 (agentless) 배포 도구
  26. 26. Fabric은 fabtools와 함께 사용하면 매우 효율적으로 사용할 수 있습니다
  27. 27. fabtools
  28. 28. fabtools fabtools는 많은 low-level 행동들을 인터페이스로 제공합니다
  29. 29. fabtools fabtools는 많은 low-level 행동들을 인터페이스로 제공합니다 덕분에 선언적인 배포 코드를 짤 수 있습니다
  30. 30. https://docs.gitlab.com/ee/ci/multi_project_pipeline_graphs.html
  31. 31. 저장소에 코드 푸시 Fabric = 호스트
  32. 32. Fabric 저장소에 코드 푸시 CI 테스트 통과 = 호스트
  33. 33. Fabric CI 테스트 통과 저장소에 코드 푸시 = 호스트
  34. 34. Fabric 배포저장소에 코드 푸시 CI 테스트 통과 = 호스트
  35. 35. Fabric 배포저장소에 코드 푸시 CI 테스트 통과 = 호스트
  36. 36. 인스턴스 식별
  37. 37. 인스턴스 식별 인스턴스에는 식별할 수 있는 Tag 들을 달았습니다
  38. 38. 인스턴스 식별 인스턴스에는 식별할 수 있는 Tag 들을 달았습니다 Fabric을 이용할 때, 이 Tag를 가지고 배포 대상을 추려낼 수 있었습니다
  39. 39. Limited Beta Test를 겪으며
  40. 40. = 호스트
  41. 41. 자동화된 생성, 제거, 배포 자동화의 영역 수동의 영역 Name Type Count server1 m4.large 4 server2 m4.2xlarge 2 server3 m4.large 1 >_ 수동으로 관리되던 인프라 구성 관리
  42. 42. 자동화의 영역 수동의 영역 Name Type Count server1 m4.large 3 server2 m4.2xlarge 2 1 server3 m4.large 1 server4 m4.large 1 >_ 자동화된 생성, 제거, 배포 수동으로 관리되던 인프라 구성 관리 인프라 구성이 바뀌면, 인프라 정보 동기화 필요!!
  43. 43. Fabric 배포저장소에 코드 푸시 GitLab CI 앱 배포 시, Git 저장소에서 필요한 코드를 복제
  44. 44. Fabric 배포저장소에 코드 푸시 셀프 DDoS Attack! 앱 배포 시, Git 저장소에서 필요한 코드를 복제 DDoS attack: Distributed Denial of Service attack GitLab CI
  45. 45. Fabric 배포저장소에 코드 푸시 큰 규모의 인프라가, 저장소 서버에 과부하를 야기!! 셀프 DDoS Attack! DDoS attack: Distributed Denial of Service attack GitLab CI 앱 배포 시, Git 저장소에서 필요한 코드를 복제
  46. 46. 마일스톤 막바지가 되면.. ※ 설치형 GitLab EE를 사용하고 있습니다. GitLab 코드 푸시 GitLab 장애 코드 푸시를 못 함. (쌓임) GitLab이 살아남 배포 (DDoS를 야기)
  47. 47. 앞의 문제들을 해결해야 했습니다 • 인프라 관리 자동화 • 배포 정상화
  48. 48. 인프라 관리 대안
  49. 49. Infrastructure as code
  50. 50. Infrastructure as code
  51. 51. Infrastructure as code t2.micro
  52. 52. • 인프라(코드)의 버전 관리 가능 • AWS 제품별 API(boto)를 직접 만지지 않아도 됨 • 인프라의 모듈화 가능 • 인프라의 생성/복제/제거가 자유로워 짐 • 그 외 코드가 갖는 모든 장점 • Code review • Merge request
  53. 53. 인프라 복제 develop
  54. 54. 인프라 복제 develop nightly
  55. 55. 인프라 복제 develop nightly canary
  56. 56. 인프라 삭제 develop nightly canary $ terraform destroy
  57. 57. 배포 저장소 과부화 대안
  58. 58. Debian Packaging
  59. 59. 〈야생의 땅: 듀랑고〉의 게임 서버는 Python을 사용합니다
  60. 60. Python 프로그램을 배포하는 4가지 방법 • Git+pip • Docker • PEX • dh-virtualenv
  61. 61. pip은 Python 패키지를 설치하는 도구 Python Package Index(https://pypi.org/)로부터 패키지를 내려받아 설치하거나, Git 저장소에서 내려받아 설치할 수 있다. Git+pip
  62. 62. Docker는 컨테이너 가상화 도구 VM과 달리 컨테이너 단위로 환경을 격리해 준다 프로그램과 필요한 의존성을 모아 컨테이너화해서 사용할 수 있다 Docker
  63. 63. PEX (Python EXecutable)는 Python 의존성을 같이 패키징 한 .pex 라는 단일 실행 파일을 만들어주는 도구 PEX https://github.com/pantsbuild/pex
  64. 64. PEX (Python EXecutable)는 Python 의존성을 같이 패키징 한 .pex 라는 단일 실행 파일을 만들어주는 도구 PEX https://github.com/pantsbuild/pex
  65. 65. dh-virtualenv는 Python 의존성을 포함한 Debian 패키지 파일 을 생성하는 도구 Debian 패키지를 빌드하는 debhelper의 빌드 과정에 dh_virtualenv 빌드 시퀀스를 추가하여 동작하는 방식 dh-virtualenv https://github.com/spotify/dh-virtualenv
  66. 66. 부끄럽지만.. pip으로 내부 Git 저장소를 통해 설치하는 방식으로 배포를 하고 있었고, 이게 GitLab에 부하를 일으켰던 원인
  67. 67. 듀랑고의 서버를 이루는 노드는 모두 연결을 맺고 있는데
  68. 68. Docker를 사용하게 되면, 이 때 사용하는 ephemeral ports를 모두 “EXPOSE” 할 수 없었다
  69. 69. PEX로는 당시에 Cython등 의존하고 있는 몇 가지 요소를 미리 설치해 놓을 수 없었고 최종적으로 dh-virtualenv를 사용하기로 결정
  70. 70. Fabric 배포저장소에 코드 푸시 GitLab CI 패키지 빌드 S3 업로드 배포 과정에서 S3에 있는 패키지 설치
  71. 71. Fabric 배포저장소에 코드 푸시 GitLab CI 패키지 빌드 S3 업로드 배포 과정에서 S3에 있는 패키지 설치
  72. 72. Fabric 배포저장소에 코드 푸시 GitLab CI 패키지 빌드 S3 업로드 배포 과정에서 S3에 있는 패키지 설치
  73. 73. Fabric 배포저장소에 코드 푸시 GitLab CI 패키지 빌드 S3 업로드 배포 과정에서 S3에 있는 패키지 설치 S3는 높은 가용성을 가지고 있기 때문에 버틸 수 있다
  74. 74. 추가적인 배포 최적화
  75. 75. OS 설정 의존성 AWS는 EC2 이미지인 AMI를 지원한다. AMI에는 각종 의존성과 OS 설정을 넣어 만들어 놓곤 했는데.. Amazon Machine Image
  76. 76. OS 설정 의존성 만들기가 번거롭다 보니, 쉽게 낡아 버리곤 했다 AWS는 EC2 이미지인 AMI를 지원한다. AMI에는 각종 의존성과 OS 설정을 넣어 만들어 놓곤 했는데.. Amazon Machine Image
  77. 77. Fabric 배포 GitLab
  78. 78. Fabric 배포 GitLab 그러다 보니 배포 과정에 추가 의존성 설치를 하고 있었다. 추가 의존성 설치
  79. 79. Fabric 배포 GitLab 그러다 보니 배포 과정에 추가 의존성 설치를 하고 있었다 배포 속도를 늦추고, 모든 의존성을 한눈에 볼 수 없었다 추가 의존성 설치
  80. 80. 다양한 타입의 머신 이미지를 만들 수 있는 도구
  81. 81. Packer를 이용해 의존성을 한 곳에서 버전 관리 할 수 있었고, AMI를 만들어 사용하기도 편해졌다.
  82. 82. 서비스 오픈을 앞두고
  83. 83. 서비스용 인프라 구축 개발용 VPC
  84. 84. 서비스용 인프라 구축 개발용 VPC 기존에는 개발용 VPC에 모든 인프라를 섞어서 쓰고 있었는데…
  85. 85. 서비스용 인프라 구축 • 기존에는 개발 VPC에 모든 인프라가 뒤섞여 있었음 • 서비스에서는 서버가 개별 VPC에 분리되어야 함 • 개별 VPC는 운영에 필요한 요소도 전부 갖춰야 함
  86. 86. 서비스용 인프라 구축 개발용 VPC
  87. 87. 서비스용 인프라 구축 개발용 VPC module module module
  88. 88. 서비스용 인프라 구축 개발용 VPC module module module 사실 모두 Terraform 모듈화 되어있었고
  89. 89. 서비스용 인프라 구축 개발용 VPC module module module EC2가 아닌 인프라도 관리할 수 있게 되었다 사실 모두 Terraform 모듈화 되어있었고
  90. 90. 서비스용 인프라 구축 개발용 VPC module module module 라이브용 VPC module module module
  91. 91. 서비스용 인프라 구축 개발용 VPC module module module 라이브용 VPC module module module 덕분에 라이브용 VPC를 구축할 때, 원하는 요소를 원하는 규모로 복제할 수 있었다
  92. 92. 참 쉽죠?
  93. 93. = 호스트 더 더 많아진 수량
  94. 94. 배포를..
  95. 95. 배포를..하는데
  96. 96. 배포를..하는데..시간이
  97. 97. 배포를..하는데..시간이..너무 걸린다!
  98. 98. 게다가 병렬 옵션(-P)을 켜면 호스트별 출력이 모두 섞여버려서 실패한 호스트가 있을 경우 찾기가 힘듦 총 머신 수가 많아지면서 간혹 배포에 실패하는 경우의 수도 많아졌다
  99. 99. 사실 fabtools는 Ubuntu 16.04를 지원하지 않을 정도로 낡아 있었고
  100. 100. 관리가 안 되는 것처럼 보여, 내부에서 수정된 버전을 쓰고 있었습니다
  101. 101. Fabric도 Fabric 2.x의 개발에 집중하려는 모양새였습니다
  102. 102. 이 상황에서 당장은 실패한 호스트 목록 표시를 패치 했지만 장기적으로는 다른 대안이 필요하다고 결정
  103. 103. 해결 해야 할 배포 문제들 • 느린 배포 • 지속가능한 배포 도구
  104. 104. 배포 전용 호스트 도입 느린 배포를 해결할
  105. 105. 지속 가능한 배포 도구
  106. 106. • 동작 방식이 기존과 유사 (agentless) • Python으로 되어있어 유사시 직접 고쳐 쓰기 편함 • 커뮤니티 활성 다음과 같은 특징으로 선택하게 됨
  107. 107. 1000여 개의 모듈을 제공 기존의 Fabric 배포를 마이그레이션 하는데 전혀 어려움이 없었다 오히려 코딩량이 더 줄어버릴 정도
  108. 108. 멱등성 멱등성(冪等性, 영어: idempotence)은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더 라도 결과가 달라지지 않는 성질을 의미한다.
  109. 109. 멱등성
  110. 110. 멱등성
  111. 111. 멱등성 첫 번째 실행
  112. 112. 멱등성 첫 번째 실행
  113. 113. 멱등성 두 번째 실행
  114. 114. 멱등성 두 번째 실행
  115. 115. Ansible이 수행을 마치면 출력하는 Play Recap에서 실패한 호스트를 따로 볼 수 있다 실패 호스트는?
  116. 116. Ansible은 실패 호스트를 <playbook filename>.retry 파일을 자동으로 만들어 기록한다. 바로 전 실행 명령어 뒤에 --limit @<playbook filename>.retry 옵션을 붙이면, 실패한 호스트만 재시도할 수 있다 멱등성 덕분에, 혹시나 중복 실행이 가져오는 부작용을 걱정하지 않아도 된다. 실패 호스트는?
  117. 117. 서비스 오픈 이후
  118. 118. terraform applying… terraform applying…
  119. 119. 인프라를 실수 없이 복제하는 일은 Terraform에 맡기고 중요한 초반 이슈를 해결하는데 집중할 수 있었다
  120. 120. 대표적으로…
  121. 121. 대표적으로… 서버 노드가 어떠한 원인으로 죽게 되면, 다른 노드에 전파되어 동반자살 하게 되는 버그였습니다
  122. 122. 오픈 이후 해결되어, 자유로운 종료와 감축이 가능! 이를 바탕으로 무중단 배포를 실현! 자세한 내용은 아래 발표에서 Rolling Update
  123. 123. 구버전 신버전 무중단 배포?
  124. 124. 구버전 신버전 무중단 배포?
  125. 125. 구버전 신버전 무중단 배포?
  126. 126. 아직 Fabric을 사용했다면… 직접 Rolling update 정책을 짰어야 했을 것 Ansible의 잠재력을 통해, 변화되는 배포 상황에 유연하게 대처할 수 있었다
  127. 127. 그 다음?
  128. 128. ChatOps, ClickOps 현재 각 절차는 모두 자동화되어 있어, 다음과 같은 시나리오가 가능 • Jenkins, Rundeck 같은 CI에 연동해 클릭으로 모든 것을 관리 • SlackBot 등을 이용해 채팅으로 관리
  129. 129. 정리
  130. 130. 손으로 관리 Fabric 배포 도구 도입 API 자동화 Terraform으로 인프라 관리 Ansible 배포 도구 도입 작은 인프라 큰 인프라 더 큰 인프라 >_
  131. 131. 손으로 관리 Fabric 배포 도구 도입 API 자동화 Terraform으로 인프라 관리 Ansible 배포 도구 도입 작은 인프라 큰 인프라 더 큰 인프라 >_ 인프라 투명성, 기록 가능
  132. 132. 손으로 관리 Fabric 배포 도구 도입 API 자동화 Terraform으로 인프라 관리 Ansible 배포 도구 도입 작은 인프라 큰 인프라 더 큰 인프라 >_ 규모 대응, 지속가능성
  133. 133. Cloud를 쓰신다면 Terraform과 Packer는 꼭 고려해볼 것을 추천 배포 도구는 본인의 인프라 규모, 방법에 따라 결정 AWS외의 다양한 Cloud 환경을 지원
  134. 134. 감사합니다
  135. 135. WE'RE HIRING!http://what.studio/

×