[NDC17] 왓 스튜디오 서비스파트

[NDC17] 왓 스튜디오 서비스파트 from Chanwoong Kim

 [NDC17] 왓 스튜디오 서비스파트

1. 1. <왓 스튜디오 서비스파트> 김찬웅 왓 스튜디오의 DevOps 살펴보기 넥슨 코리아 왓 스튜디오
2. 2. 저작물 인용 저작권법 제35조의 3 ‘공정이용’ 조항에 따라 교육과 연구 목적으로 이용 하고 있습니다. 혹시 문제가 있을 경우, cwkim@nexon.co.kr 로 연락 주시면 적절한 조치를 취하겠습니다.
3. 3. 소개
4. 4. 김찬웅 넥슨, 왓 스튜디오, 백엔드 엔지니어 • NDC15 <그룹웨어에 새 에너지를> • NDC16 • NDC16 • NDC17 <왓 스튜디오 서비스파트> ← New! kexplo http://chanwoong.kim cwkim@nexon.co.kr kexplo
5. 5. 김찬웅 넥슨, 왓 스튜디오, 백엔드 엔지니어 • NDC15 <그룹웨어에 새 에너지를> • NDC16 • NDC16 • NDC17 <왓 스튜디오 서비스파트> ← New! kexplo http://chanwoong.kim cwkim@nexon.co.kr kexplo
6. 6. 이 발표에서 다룰 내용 • 서비스파트? • DevOps? • 코드! • 빌드! • 테스트! • 배포! • 피드백!
7. 7. 왓 스튜디오 서비스파트?
8. 8. …
9. 9. … 서비스파트
10. 10. 서비스파트 팀의 “서비스”를 위한 조직
11. 11. “아니 라이브 중인 게임도 없으면서 무슨 서비스예요?” 꿀 빠는 조직 아닌가요?
12. 12. “아니 라이브 중인 게임도 없으면서 무슨 서비스에요?” 꿀 빠는 조직 아닌가요? 아닙니다.
13. 13. • 외적 • 서비스를 하기 위한 서버 기반 마련 • 내적 • 개발에 필요한 도움 제공 A/S 서버 프레임워크 개발 배포 환경 구축 내부 개발 환경 설정 편의 도구 개발 테스팅 환경 구축
14. 14. 여러가지 일을 맡다 보니, 다양한 스택의 사람들이 모임 DBA 잡캐 Brogrammer 웹 서버 아키텍트 자료공
15. 15. 물론 이상한 사람들도 ※ 합성 아닙니다.
16. 16. #서비스파트
17. 17. •외적 • 서비스를 하기 위한 서버 기반 마련 •내적 • 개발에 필요한 도움 제공 서버 프레임워크 개발 배포 환경 구축 내부 개발 환경 설정 편의 도구 개발 테스팅 환경 구축
18. 18. •외적 • 서비스를 하기 위한 서버 기반 마련 •내적 • 개발에 필요한 도움 제공 서버 프레임워크 개발 배포 환경 구축 내부 개발 환경 설정 편의 도구 개발 테스팅 환경 구축 DevOps
19. 19. DevOps?
20. 20. DevOps? DevOps Development Operations 개발 운영
21. 21. DevOps! •개발 – 빌드 – 테스트 – 배포 –피드백 공정
22. 22. DevOps 살펴보기 •개발 – 빌드 – 테스트 – 배포 –피드백 공정 소개 •각 공정 단계에서 사용하는 기술과 활용을 넓고 얇게
23. 23. 개발 • Git • Code Review • GitLab • Windows Subsystem for Linux • Docker 개발-빌드-테스트-배포-피드백
24. 24. Git https://www.slideshare.net/kexplo/ndc2016-effective-git 개발-빌드-테스트-배포-피드백
25. 25. 코드리뷰 •코드의 기능적, 성능적 취약성을 미리 진단할 수 있음. •작업자들 간의 코드 이해도 증가. •잘못된 개발 방향을 미리 진단해, 개발 비용 절감. 개발-빌드-테스트-배포-피드백
26. 26. 현실 개발-빌드-테스트-배포-피드백
27. 27. “리뷰할 시간 없어요” •마일스톤 막바지에 몰리는 코드 리뷰 •리뷰어의 작업 시간은 공짜가 아니다 •다른 작업물의 맥락을 파악하는 것도 큰 비용 개발-빌드-테스트-배포-피드백
28. 28. 개발-빌드-테스트-배포-피드백
29. 29. 리뷰의 가장 큰 걸림돌? •읽기 힘든 커밋 로그 •(파악할 맥락이) 너무 많은 코드 양 개발-빌드-테스트-배포-피드백
30. 30. 리뷰를 편하게 하자 (1/2) •“커밋이 읽기 너무 힘들어요” •커밋은 “좋은 커밋 메시지” 규격에 맞춘다. • 제목 행의 길이를 제한 • 명령 어조를 사용 • ‘어떻게’ 보다는 ‘무엇’과 ‘왜’를 설명 개발-빌드-테스트-배포-피드백
31. 31. https://chris.beams.io/posts/git-commit/ 개발-빌드-테스트-배포-피드백
32. 32. 리뷰를 편하게 하자 (2/2) •“코드 맥락을 파악하기에 너무 양이 많아요” •리뷰 코드의 양을 최소화 한다. 개발-빌드-테스트-배포-피드백
33. 33. 개발-빌드-테스트-배포-피드백
34. 34. 개발-빌드-테스트-배포-피드백
35. 35. 한 번에 리뷰해야 할 양 개발-빌드-테스트-배포-피드백
36. 36. GitLab •서비스형 Git 저장소인 GitHub을 사용하지 않을 경우 •설치형 Git 서비스의 가장 현실적인 대안 개발-빌드-테스트-배포-피드백
37. 37. • Repository • Issue Board • Review • CI • Build Pipelines • Docker Container Registry https://about.gitlab.com/ 개발-빌드-테스트-배포-피드백
38. 38. Linux와 Python을 사용하는 서버 개발 환경 개발-빌드-테스트-배포-피드백
39. 39. Linux와 Python을 사용하는 서버 개발 환경 개발-빌드-테스트-배포-피드백
40. 40. Linux와 Python을 사용하는 서버 개발 환경 …은 모두에게 친절하진 않다. 일단 회사에서 지급하는 PC만 해도 Windows. 사용하는 대상이 ‘프로그래머’가 아닐 경우에는 더 심각해 진다. 개발-빌드-테스트-배포-피드백
41. 41. 리눅스
42. 42. 당연히 Virtual Machine! https://www.virtualbox.org 개발-빌드-테스트-배포-피드백
43. 43. 하지만… •파일 수정, 공유의 제약 • Linux에 익숙하지 않으니, Vim, Emacs에 익숙하지 않음 • Samba, rsync, ftp, …. 썩 만족스러운 방법이 없음 개발-빌드-테스트-배포-피드백
44. 44. 하지만… •파일 수정, 공유의 제약 • Linux에 익숙하지 않으니, Vim, Emacs에 익숙하지 않음 • Samba, rsync, ftp, …. 썩 만족스러운 방법이 없음 아, 맞다. 이건 당연히 안 쓰는거죠 개발-빌드-테스트-배포-피드백
45. 45. 개발-빌드-테스트-배포-피드백
46. 46. 개발-빌드-테스트-배포-피드백
47. 47. 개발-빌드-테스트-배포-피드백
48. 48. 개발-빌드-테스트-배포-피드백
49. 49. 개발-빌드-테스트-배포-피드백
50. 50. 돼. 개발-빌드-테스트-배포-피드백
51. 51. https://blogs.msdn.microsoft.com/msdntaiwan/2016/04/20/developers- can-run-bash-shell-and-user-mode-ubuntu-linux-binaries-on- windows10-cht/ 개발-빌드-테스트-배포-피드백
52. 52. 그림 출처: https://gifamerica.com/categories/view/de2da6dc70721cc940d774355e74ad6e341275be/rainbow-throw-up-gif.html 개발-빌드-테스트-배포-피드백
53. 53. Windows Subsystem for Linux (WSL) • (Bash on Ubuntu on Windows) • Windows 10의 Linux 호환 레이어 • Anniversary Update (build 14393) 부터 지원 https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/ 개발-빌드-테스트-배포-피드백
54. 54. 개발-빌드-테스트-배포-피드백
55. 55. 개발-빌드-테스트-배포-피드백
56. 56. •장점 • (베타 지만) VM이 아닌 Linux 환경을 제공 함 • Linux에서 Windows의 파일을 바로 접근 할 수 있음 • Windows의 각 드라이브는 /mnt/<drive>/ 경로로 매핑. • (Windows) C:test.txt == (Linux) /mnt/c/test.txt • VBoxSDK 같은 걸 쓰지 않아도, 자동화 하기 편리함 • > bash.exe –c “echo ‘Hello, World!’” 개발-빌드-테스트-배포-피드백
57. 57. •덕분에 • Windows에서 본인에게 편한 에디터를 사용. • Visual Studio, PyCharm, gVim(?), … • 서버는 Linux 환경을 보장 받음. • 다른 직군이 쉽게 서버를 로컬 배포할 수 있도록, GUI로 된 쓰기 편한 자동 설정 도구를 제공 개발-빌드-테스트-배포-피드백
58. 58. •덕분에 • Windows에서 본인에게 편한 에디터를 사용. • Visual Studio, PyCharm, gVim(?), … • 서버는 Linux 환경을 보장 받음. • 다른 직군이 쉽게 서버를 로컬 배포할 수 있도록, GUI로 된 쓰기 편한 자동 설정 도구를 제공 개발-빌드-테스트-배포-피드백
59. 59. •단점은? 개발-빌드-테스트-배포-피드백
60. 60. •단점은? 개발-빌드-테스트-배포-피드백
61. 61. •단점은? 개발-빌드-테스트-배포-피드백
62. 62. •단점은? 개발-빌드-테스트-배포-피드백
63. 63. •단점은? 개발-빌드-테스트-배포-피드백
64. 64. •단점은? 개발-빌드-테스트-배포-피드백
65. 65. 미 구현된 OS 기능들이 아직 남아있음 https://blogs.msdn.microsoft.com/wsl/2017/04/11/testing-the-windows-subsystem-for-linux/ 개발-빌드-테스트-배포-피드백
66. 66. 기능별 완성도가 다르기에, 사용하려는 기능의 호환성 체크가 필수! 서버에서 사용하는 다른 개발 스택(Couchbase, Redis, …)은 Docker (for Windows)를 이용해서 보충 가능! 개발-빌드-테스트-배포-피드백
67. 67. Docker for Windows WSL Docker client Windows 개발-빌드-테스트-배포-피드백
68. 68. $ export DOCKER_HOST=tcp://127.0.0.1:2375 Docker for Windows WSL Docker client Windows 개발-빌드-테스트-배포-피드백
69. 69. 지금 여러분의 마음 잘 압니다 <뭣! 공작소 봉사 조직> 발표 개발-빌드-테스트-배포-피드백
70. 70. 개발팀의 요구사항 •서버는 어디에 떠도 상관 없지만, 파일을 윈도우 환경에서 수정하고 싶다. •수정  반영  실행의 이터레이션이 빨랐으면 좋겠다. 개발-빌드-테스트-배포-피드백
71. 71. 다른 옵션 •서버를 Dockerize •Docker for Windows를 사용해서 실행 •개발 파일은 Volume mount로 Windows와 매핑 개발-빌드-테스트-배포-피드백
72. 72. Windows Docker Volume mount의 걸림돌..  •Symbolic Link •File Socket 개발-빌드-테스트-배포-피드백
73. 73. Windows Docker Volume mount의 걸림돌  •Symbolic Link •File Socket …은 대부분 해결! 개발-빌드-테스트-배포-피드백
74. 74. 미래 • 서버의 완벽한 Dockerize를 추진 중 • WSL은 Linux CLI를 사용하기 위한 보조 수단으로 남을 예정 개발-빌드-테스트-배포-피드백
75. 75. 빌드 • GitLab CI • Jenkins 개발-빌드-테스트-배포-피드백
76. 76. GitLab CI •GitLab에서 제공하는 내장형 CI •저장소의 .gitlab-ci.yml을 통해 빌드 파이프라인을 구성 •Travis CI를 만져본 경험이 있다면, 비슷하게 사용 가능 •설치형 GitHub+Travis CI같은 경험을 느낄 수 있다. 개발-빌드-테스트-배포-피드백
77. 77. 개발-빌드-테스트-배포-피드백
78. 78. 클라이언트 빌드를 뽑다보면… •Android를 빌드할 땐 xxx를 해야 하고… iOS를 빌드할 땐, Xcode Project 결과물을 만들고, 인증서를 맞춰주고… •이번엔 Development 빌드를 뽑아야 하고, 다음엔 Release 빌드를 뽑아야 해 •10일전 커밋으로 새로 빌드해 보자 •결과물을 S3에 모아서 올리도록 하자. •완료되면 알림을 줘 개발-빌드-테스트-배포-피드백
79. 79. ./build.sh # 나 한다 빌드 ./build.sh # 나 한다 설정, 이동, 받기, 빌드, 배포, … 다양한 요구사항 지원으로 비대해지는 스크립트 개발-빌드-테스트-배포-피드백
80. 80. 개발-빌드-테스트-배포-피드백
81. 81. 개발-빌드-테스트-배포-피드백
82. 82. 개발-빌드-테스트-배포-피드백
83. 83. 개발-빌드-테스트-배포-피드백
84. 84. 개발-빌드-테스트-배포-피드백
85. 85. 정해진 기준 •효율이 상대적으로 높은, Python 스크립트로 재 작성 •3번 이상 들어온 요구사항은 자동화 대상 •기능을 모듈식으로 나누어서 조립해 사용할 수 있게 한다 •명령어를 몰라도 쓸 수 있게 한다 개발-빌드-테스트-배포-피드백
86. 86. Python CLI 빌드 툴 •Python을 이용하여 빌드용 All-In-One CLI 툴을 제작 •앞에서 정한 ‘기능’이 하위 명령어가 된다. •쉘에서 간단하게 빌드의 모든 과정을 수행가능! $ wbuild <update|build|upload|…> [options] 개발-빌드-테스트-배포-피드백
87. 87. Jenkins •설치형 오픈소스 CI 도구 Continuous Integration 개발-빌드-테스트-배포-피드백
88. 88. Jenkins •설치형 오픈소스 CI 도구 플러그인이 엄청나게 많은! Continuous Integration 개발-빌드-테스트-배포-피드백
89. 89. Jenkins, MultiJob Plugin •최소 단위인 Job을 연결해서 Pipeline을 만들어 준다. •CLI의 기능별 Job을 연결해, 레고 조립하듯 빌드를 만들어내는 커다란 Job을 구축. 개발-빌드-테스트-배포-피드백
90. 90. 환경 설정 Android 빌드 업로드 알림 환경 설정 iOS 어셋 빌드 업로드 개발-빌드-테스트-배포-피드백
91. 91. 환경 설정 Android 빌드 업로드 알림 환경 설정 iOS 어셋 빌드 업로드 개발-빌드-테스트-배포-피드백
92. 92. 환경 설정 Android 빌드 업로드 알림 환경 설정 iOS 어셋 빌드 업로드 개발-빌드-테스트-배포-피드백
93. 93. 사라지지 않는 의존성 “방금 만든 브랜치의 버전의 빌드가 필요해요“ “업로드 저장소를 정리했어요, 업로드만 새로 해주세요“ 개발-빌드-테스트-배포-피드백
94. 94. 사라지지 않는 의존성 “방금 만든 브랜치의 버전의 빌드가 필요해요“ “업로드 저장소를 정리했어요, 업로드만 새로 해주세요“ 여전히 최소 단위 Job은 프로그래머의 의존성이 필요.. 개발-빌드-테스트-배포-피드백
95. 95. 사라지지 않는 의존성 “방금 만든 브랜치의 버전의 빌드가 필요해요“ “업로드 저장소를 정리했어요, 업로드만 새로 해주세요“ 여전히 최소 단위 Job은 프로그래머의 의존성이 필요.. 어? 그런데 새로운 기능은 아니다! 개발-빌드-테스트-배포-피드백
96. 96. Jenkins, Build With Parameters Plugin •주관식, 객관식의 파라미터를 입력 받을 수 있게 해 줌. •Jenkins의 기능 Job의 재사용성을 늘릴 수 있게 되었음. •모든 파라미터는 환경변수로 오기 때문에, 자주 쓰는 파라미터는 새로운 빌드 Job으로 생성 가능 개발-빌드-테스트-배포-피드백
97. 97. 개발-빌드-테스트-배포-피드백
98. 98. Android iOS 결과물 업로드 X 알림 X 개발-빌드-테스트-배포-피드백
99. 99. Android iOS 결과물 업로드 X 알림 X 빌드 개발-빌드-테스트-배포-피드백
100. 100. Android iOS 결과물 업로드 X 알림 X 빌드 개발-빌드-테스트-배포-피드백
101. 101. Android iOS 결과물 업로드 X 알림 X 빌드 개발-빌드-테스트-배포-피드백
102. 102. Android iOS 결과물 업로드 X 알림 X 빌드 개발-빌드-테스트-배포-피드백
103. 103. Android iOS 결과물 업로드 X 알림 X 빌드 완료 개발-빌드-테스트-배포-피드백
104. 104. Jenkins, Rebuild Plugin •앞에서 소개한 ‘Build With Parameters Plugin’와 함께 사용하면 좋은 플러그인 •같은 조건으로 빌드를 재시도할 경우, 파라미터를 다시 넣는 게 꽤 귀찮은 일이다. •버튼 하나로 해결! 개발-빌드-테스트-배포-피드백
105. 105. Jenkins, Log Parser Plugin •로그를 파싱 해서 보기 좋게 정제해 보여준다. •파싱 룰은 정규식으로 작성 가능 개발-빌드-테스트-배포-피드백
106. 106. ok /not really/ # match line starting with 'error ', case-insensitive error /(?i)^error / # list of warnings here... warning /[Ww]arning/ warning /WARNING/ # create a quick access link to lines in the report containing 'INFO' info /INFO/ 개발-빌드-테스트-배포-피드백
107. 107. 개발-빌드-테스트-배포-피드백
108. 108. 매일 자동으로 돌아가는 빌드일 경우 빌드가 깨지면, 대부분 프로그래밍 오류다. 이 경우에 문제를 빠르게 파악하는데 도움이 된다. 문제를 전달하는 사람도 “빌드가 깨졌어요” 보다 더 좋은 정보를 제공해줄 수 있게 된다. 개발-빌드-테스트-배포-피드백
109. 109. 얻은 이점: 최소한의 프로그래머 의존성 •프로그래머는 실제로 빌드에 문제가 생긴 경우를 제외하고, 최소한의 의존성만 가지게 됨 •마일스톤 막바지에 프로그래머를 찾는 일이 적어짐 • 생산성 향상 •프로그래머 없이 원하는 형태의 빌드를 생성 가능 개발-빌드-테스트-배포-피드백
110. 110. 번외: Jenkins, Blue Ocean 1.0 • 발표 자료를 만들다 보니 어느새 정식 버전이! • 파이프라인 에디터를 지원 한다고 하니, 새로 도입하시는 분들은 고려해 보실 만 하겠습니다. • 일단 예쁘기도 하고 개발-빌드-테스트-배포-피드백
111. 111. 테스트 • pytest • Travis CI • coveralls.io 개발-빌드-테스트-배포-피드백
112. 112. pytest: helps you write better programs 개발-빌드-테스트-배포-피드백
113. 113. Unittest vs pytest # built-in unittest def sum(a, b): return a + b def is_odd(num): return num % 2 == 0 class TestFoo(TestCase): def test_sum(self): self.assertEqual(sum(1, 2), 3) def test_odd(self): self.assertTrue(is_odd(10)) # pytest def sum(a, b): return a + b def is_odd(num): return num % 2 == 0 def test_sum(): assert sum(1, 2) == 3 def test_odd(): assert is_odd(10) 개발-빌드-테스트-배포-피드백
114. 114. Unittest vs pytest # built-in unittest def sum(a, b): return a + b def is_odd(num): return num % 2 == 0 class TestFoo(TestCase): def test_sum(self): self.assertEqual(sum(1, 2), 3) def test_odd(self): self.assertTrue(is_odd(10)) # pytest def sum(a, b): return a + b def is_odd(num): return num % 2 == 0 def test_sum(): assert sum(1, 2) == 3 def test_odd(): assert is_odd(10) 개발-빌드-테스트-배포-피드백
115. 115. pytest, parametrize import pytest @pytest.mark.parametrize("test_input", [1, 2, 3, 4]) def test_function(test_input): assert test_input < 5 개발-빌드-테스트-배포-피드백
116. 116. pytest, parametrize import pytest @pytest.mark.parametrize("test_input", [1, 2, 3, 4]) def test_function(test_input): assert test_input < 5 개발-빌드-테스트-배포-피드백
117. 117. pytest, parametrize import pytest @pytest.mark.parametrize("test_input", [1, 2, 3, 4]) def test_function(test_input): assert test_input < 5 개발-빌드-테스트-배포-피드백
118. 118. pytest, parametrize import pytest @pytest.mark.parametrize("test_input", [1, 2, 3, 4]) def test_function(test_input): assert test_input < 5 개발-빌드-테스트-배포-피드백
119. 119. pytest, parametrize import pytest @pytest.mark.parametrize("test_input,expected", [ ("3+5", 8), ("2+4", 6), ("6*9", 54), ]) def test_eval(test_input, expected): assert eval(test_input) == expected 개발-빌드-테스트-배포-피드백
120. 120. pytest, parametrize import pytest @pytest.mark.parametrize("test_input,expected", [ ("3+5", 8), ("2+4", 6), ("6*9", 54), ]) def test_eval(test_input, expected): assert eval(test_input) == expected test_eval("3+5", 8) test_eval(“2+4", 6) test_eval(“6*9", 54) 개발-빌드-테스트-배포-피드백
121. 121. pytest, fixture import pytest @pytest.fixture def smtp(): import smtplib return smtplib.SMTP("smtp.gmail.com") def test_ehlo(smtp): response, msg = smtp.ehlo() assert response == 250 개발-빌드-테스트-배포-피드백
122. 122. pytest, fixture import pytest @pytest.fixture def smtp(): import smtplib return smtplib.SMTP("smtp.gmail.com") def test_ehlo(smtp): response, msg = smtp.ehlo() assert response == 250 개발-빌드-테스트-배포-피드백
123. 123. pytest, fixture finalizer import smtplib import pytest @pytest.fixture(scope="module") def smtp(request): smtp = smtplib.SMTP("smtp.gmail.com") yield smtp # provide the fixture value print("teardown smtp") smtp.close() 개발-빌드-테스트-배포-피드백
124. 124. pytest, fixture finalizer import smtplib import pytest @pytest.fixture(scope="module") def smtp(request): smtp = smtplib.SMTP("smtp.gmail.com") yield smtp # provide the fixture value print("teardown smtp") smtp.close() 개발-빌드-테스트-배포-피드백
125. 125. pytest, fixture finalizer import smtplib import pytest @pytest.fixture(scope="module") def smtp(request): smtp = smtplib.SMTP("smtp.gmail.com") yield smtp # provide the fixture value print("teardown smtp") smtp.close() Teardown flow 개발-빌드-테스트-배포-피드백
126. 126. Docker를 fixture로 만들어 사용 • Docker instance를 띄우고, 사용 후 제거하는 fixture. • 테스트를 위한 1회용 docker같은 느낌으로 쓸 수 있다. • Unit Test를 넘어서 Integration Test로 확장 가능 개발-빌드-테스트-배포-피드백
127. 127. 활용 # docker fixture POC @pytest.fixture(scope="function") def docker(): docker = run_container(blahblah) yield docker docker.kill_container() 개발-빌드-테스트-배포-피드백
128. 128. pytest-cov 개발-빌드-테스트-배포-피드백
129. 129. GitHub Project의 테스트 • Travis CI • Coverall.io 개발-빌드-테스트-배포-피드백
130. 130. Travis CI •GitHub 과 연계하여 무료로 사용할 수 있는 CI •프로젝트 루트의 .travis.yml를 사용하여 빌드를 구성 설정 방법은 문서화가 잘 되어있다. https://docs.travis-ci.com 개발-빌드-테스트-배포-피드백
131. 131. language: python python: - "2.6" - "2.7" - "3.2" - "3.3" - "3.4" # PyPy versions - "pypy" # PyPy2 2.5.0 - "pypy3" # Pypy3 2.4.0 - "pypy-5.3.1" # command to install dependencies install: - pip install . - pip install -r requirements.txt # command to run tests script: pytest 개발-빌드-테스트-배포-피드백
132. 132. coveralls.io 개발-빌드-테스트-배포-피드백
133. 133. 배포 • Terraform 개발-빌드-테스트-배포-피드백
134. 134. AWS에서 EC2 한 대를 띄우려면? •AWS 콘솔 로그인 •EC2 대시보드 접속 •EC2 인스턴스 선택 • 각종 옵션 설정 •Launch! 개발-빌드-테스트-배포-피드백
135. 135. AWS에서 EC2 두 대를 띄우려면? •AWS 콘솔 로그인 •EC2 대시보드 접속 •EC2 인스턴스 선택 • 각종 옵션 설정 •Launch! ×2 개발-빌드-테스트-배포-피드백
136. 136. AWS에서 EC2 n 대를 띄우려면? •AWS 콘솔 로그인 •EC2 대시보드 접속 •EC2 인스턴스 선택 • 각종 옵션 설정 •Launch! ×n 개발-빌드-테스트-배포-피드백
137. 137. AWS에서 EC2 n 대를 띄우..다가 손이 미끄러지면? •AWS 콘솔 로그인 •EC2 대시보드 접속 •EC2 인스턴스 선택 • 각종 옵션 설정 •Launch! ×n 개발-빌드-테스트-배포-피드백
138. 138. 유일한 AWS 담당자 개발-빌드-테스트-배포-피드백
139. 139. 개발-빌드-테스트-배포-피드백
140. 140. Bus Factor 팀원이 버스에 치였을 때, 프로젝트는 안전할까? 개발-빌드-테스트-배포-피드백
141. 141. AWS 콘솔을 여러명이 사용하면? •“이 EC2 인스턴스 누가 만들었어요?” •“이거 IAM User가 이상한데, 누구거에요?” •“Inbound 규칙이 다른데, 의도한건가요?” •“이거 지워도 돼요???” 개발-빌드-테스트-배포-피드백
142. 142. AWS 콘솔을 여러명이 사용하면? •“이 EC2 인스턴스 누가 만들었어요?” •“이거 IAM User가 이상한데, 누구거에요?” •“Inbound 규칙이 다른데, 의도한건가요?” •“이거 지워도 돼요???” 개발-빌드-테스트-배포-피드백
143. 143. 그 밖에도… •보안 문제 •소유 문제 •컨벤션 문제 개발-빌드-테스트-배포-피드백
144. 144. Terraform •HashCorp에서 만든 인프라 관리 도구 •AWS의 인프라를 코드로써 다룰 수 있는 것이 특징 • “Infrastructure as code” •선언적으로 관리하기 때문에 직관적 개발-빌드-테스트-배포-피드백
145. 145. resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" } 개발-빌드-테스트-배포-피드백
146. 146. $ terraform plan + aws_instance.example ami: "ami-2757f631" availability_zone: "<computed>" ephemeral_block_device.#: "<computed>" instance_state: "<computed>" instance_type: "t2.micro" key_name: "<computed>" private_ip: "<computed>" public_dns: "<computed>" root_block_device.#: "<computed>" security_groups.#: "<computed>" source_dest_check: "true" subnet_id: "<computed>" tenancy: "<computed>" vpc_security_group_ids.#: "<computed>" 개발-빌드-테스트-배포-피드백
147. 147. $ terraform apply aws_instance.example: Creating... ami: "" => "ami-2757f631" instance_type: "" => "t2.micro" [...] aws_instance.example: Still creating... (10s elapsed) aws_instance.example: Creation complete Apply complete! Resources: 1 added, 0 changed, 0 destroyed. # ... 개발-빌드-테스트-배포-피드백
148. 148. $ terraform plan Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. No changes. Infrastructure is up-to-date. This means that Terraform did not detect any differences between your configuration and real physical resources that exist. As a result, Terraform doesn't need to do anything.
149. 149. resource "aws_instance" "example" { ami = "ami-2757f631" instance_type = "t2.micro" } 개발-빌드-테스트-배포-피드백
150. 150. resource "aws_instance" "example" { ami = "ami-b374d5a5" instance_type = "t2.micro" } 개발-빌드-테스트-배포-피드백
151. 151. $ terraform plan # ... -/+ aws_instance.example ami: "ami-2757f631" => "ami-b374d5a5" (forces new resource) availability_zone: "us-east-1a" => "<computed>" ebs_block_device.#: "0" => "<computed>" ephemeral_block_device.#: "0" => "<computed>" instance_state: "running" => "<computed>" instance_type: "t2.micro" => "t2.micro" private_dns: "ip-172-31-17-94.ec2.internal" => "<computed>" private_ip: "172.31.17.94" => "<computed>" public_dns: "ec2-54-82-183-4.compute-1.amazonaws.com" => "<computed>" public_ip: "54.82.183.4" => "<computed>" subnet_id: "subnet-1497024d" => "<computed>" vpc_security_group_ids.#: "1" => "<computed>" 개발-빌드-테스트-배포-피드백
152. 152. $ terraform apply aws_instance.example: Refreshing state... (ID: i-64c268fe) aws_instance.example: Destroying... aws_instance.example: Destruction complete aws_instance.example: Creating... ami: "" => "ami-b374d5a5" availability_zone: "" => "<computed>" ephemeral_block_device.#: "" => "<computed>" instance_state: "" => "<computed>" instance_type: "" => "t2.micro" key_name: "" => "<computed>" placement_group: "" => "<computed>" public_ip: "" => "<computed>" root_block_device.#: "" => "<computed>" security_groups.#: "" => "<computed>" source_dest_check: "" => "true" subnet_id: "" => "<computed>"
153. 153. © AWS re:Invent 2016| GAM401 | Riot Games: Standardizing Application Deployments Using Amazon ECS and Terraform 개발-빌드-테스트-배포-피드백
154. 154. © AWS re:Invent 2016| GAM401 | Riot Games: Standardizing Application Deployments Using Amazon ECS and Terraform 개발-빌드-테스트-배포-피드백
155. 155. Game Server DB … Dev Game Server DB … Production Game Server DB …Staging 손쉬운 개발 환경 추가 Game Server DB … ? 개발-빌드-테스트-배포-피드백
156. 156. 코드로 관리하기 때문에 • 누구든지 인프라 배포 가능 • 똑같은 설정의 인프라를 쉽게 생성 가능 • 버전 관리가 되므로, 인프라의 의도를 전달받을 수 있음 • 사용자의 실수 방지 개발-빌드-테스트-배포-피드백
157. 157. T-Rex Factor 코드로 관리하기 때문에 • 누구든지 인프라 배포 가능 • 똑같은 설정의 인프라를 쉽게 생성 가능 • 버전 관리가 되므로, 인프라의 의도를 전달받을 수 있음 • 사용자의 실수 방지 • 마지막 작업자를 공룡이 물어가도 안심! 개발-빌드-테스트-배포-피드백
158. 158. 피드백 • Sentry • Zeppelin • Kibana • DataDog 개발-빌드-테스트-배포-피드백
159. 159. 클라이언트의 에러를 보는 법? •한 땀 한 땀 로그를 찍는다 •로그 뷰어에 연결한다 •눈이 빠지게 로그를 찾는다 Android logcat 개발-빌드-테스트-배포-피드백
160. 160. Sentry •실시간 에러 트레킹 시스템 개발-빌드-테스트-배포-피드백
161. 161. © sentry.io 개발-빌드-테스트-배포-피드백
162. 162. © sentry.io 개발-빌드-테스트-배포-피드백
163. 163. © sentry.io 개발-빌드-테스트-배포-피드백
164. 164. © sentry.io 개발-빌드-테스트-배포-피드백
165. 165. 로그 스트리밍 시스템 •(EFK) Elasticsearch, fluentd, Kibana 스택으로 구성 Game Server Game Server … Kinesis Lambda Lambda S3 S3 (parquet)EMR Elasticsearch Service 개발-빌드-테스트-배포-피드백 EMR (Zeppelin)
166. 166. Kibana •앞에서 모은 로그를 Kibana를 통해 실시간 쿼리 •실시간으로 로그를 통해, 현재 상태를 짐작할 수 있다. 개발-빌드-테스트-배포-피드백
167. 167. Zeppelin • 정제 해 놓은 로그를 바탕으로 쿼리 • 지나간 로그를 바탕으로 통계 등을 내기가 쉽다. • 대시 보드의 접근성이 좋아, 게임 디자이너가 원하는 지표를 직접 쿼리 개발-빌드-테스트-배포-피드백
168. 168. Datadog •모니터링 서비스 •서버의 실시간 메트릭을 전송 •원하는 시점의 커스텀 메트릭 그래프를 만들 수 있다. • 서버 별 동접, 섬 별 동물 수, 서버 간 동기화 빈도, … • 서버의 상황을 파악하고 새로운 관점을 알게 해준다 개발-빌드-테스트-배포-피드백
169. 169. © Datadog 개발-빌드-테스트-배포-피드백
170. 170. What’s NEXT?
171. 171. ChatOps •채팅 + 봇 + DevOps © https://github.com/StackStorm/showcase-ansible-chatops Hubot ErrBot
172. 172. 다시 서비스파트 마지막으로
173. 173. 오픈 소스 활동 •https://github.com/what-studio •파트 내에서 오픈소스 활동을 적극 권장
174. 174. 업무 공유의 장 •서로의 업무를 공유하는 작은 모임인 SDC를 가짐 •동료가 공룡에게 물려가도 항상 백업 가능한 환경 조성
175. 175. 업무 공유의 장 •서로의 업무를 공유하는 작은 모임인 SDC를 가짐 •동료가 공룡에게 물려가도 항상 백업 가능한 환경 조성 파트원 모두가 DevOps 엔지니어 ServicePart Developer Conference
176. 176. We’re hiring 같이 일할 이상한 분을 구합니다
177. 177. 감사합니다