20191226 LEGACYLAND에서 살아남는 법

1. LEGACYLAND에서 살아남는 법
26. Dec. 2019
jongwon.han@hbsmith.io
(AWS KRUG #architecture 소모임)
1

2. 발표자 소개
• 한종원
• Python과 Cloud Infra, Lean/Agile 방법론 그리고 애플의 제품을 사랑.
• 2012년 석사 학위를 마치고, startup을 시작
• '의미가 있는 일을, 올바르게 하고 싶다.’
• 경력
• (현) DevOps 전문 스타트업 ‘HBsmith’ 대표
• 택시 O2O 서비스 스타트업 ‘Kanizsa Lab’의 backend server / infra devops 담당
• Cloud computing 전문 스타트업 'A2 company' co-founder (‘KINX’에 인수합병)
• NEXON 'MapleStory 국내 Live Team'에서 DBA, SA로 근무 (산업 기능 요원)
2
https://www.linkedin.com/in/addnull/
https://hbsmith.io

3. Contents
• 발표 대상
- Infra, backend 관련 legacy 해결법을 찾는 분
- Public cloud 를 적극적으로 활용하는 또는 하고 싶은 분
- 개발 관련 밤샘 토론을 즐기는 분
3
(예상 토론 시간: 30분)

4. Zombie와 Legacy 특징 비교
4
🧟🧟
Zombie Legacy
시체인데 돌아다님 동작하긴 하는데 어떻게 동작하는지 잘 모름
잘 안 죽음 버그 수정이나 기능 추가가 힘듦
죽었다고 생각했는데, 다시 움직임 버그를 지난 번에 고쳤는데, 다시 문제가 발생함
전염성이 있음 전파성이 있음
도시와 문명을 파괴함 개발팀, 개발자의 멘탈을 파괴하는 야근을 발생함

5. 개발팀, 개발자의 멘탈을 파괴하는 야근
5
음…

6. 나에게 Legacy란?
• 재현 가능하지 않은 모든 것
• "디버깅 작업은 '인지된 도전과 인지된 기술 사이의 경기' (..중략..) 발생한 문제를
재현할 수 있다면 반드시 해결할 수 있다.”, Effective Debugging
• (가설) 그럼 계속 재현 가능하도록 유지하면 어떨까?
6

7. RULE #0 작게 만들기
7
계속 재현 가능하기 위한 개발 규칙들

8. RULE #0 작게 만들기
8
https://youtu.be/UUJKiTcnGK0
한 줄로 짤 코드를
누가 열 줄로 만들
어놨어요?
음… ???

9. RULE #0 작게 만들기
• Lego처럼 개발하고 조립하자
9

10. RULE #0 작게 만들기
• Lego 같은 AWS
-> 220개의 서비스 집합
(2019년 12월 기준)
10
‘어디서부터 시작해야
하는 거지?'

11. RULE #0 작게 만들기
• ‘먼저 서버 1대부터 추가’
11
EC2

12. RULE #0 작게 만들기
• ‘EC2 하나에 모두 설치!’
12
EC2

13. RULE #0 작게 만들기
• ‘RDS라는 full-managed DB를 써볼까?’
13
EC2
RDS

14. RULE #0 작게 만들기
• ‘EC2 disk 공간이 더 필요하네 (늘리고, 늘리고, 늘리고…)’
14
EC2
RDS

15. RULE #0 작게 만들기
• ‘S3라는 무제한 용량의 storage를 쓰면 되겠군.’
15
EC2
RDS S3

16. RULE #0 작게 만들기
• AWS 3대장
16
EC2 RDSS3

17. RULE #0 작게 만들기
• ‘아, 서버 HA(이중화)도 해야지, ELB란게 필요하네.’
17

18. RULE #0 작게 만들기
• ‘비동기 작업을 하려면 SQS를 쓰면 되네.’
18

19. RULE #0 작게 만들기
• ‘Mobile App push 알림을 위해서 SNS도 추가하자.’
19

20. RULE #0 작게 만들기
• ‘가끔 있는 비동기 작업을 위해서는 Lambda가 낫겠다.’
20

21. RULE #0 작게 만들기
• AWS 3대장도 네트워크(VPC)가 없으면 무용지물
• VPC는 infrastructure의 뼈대
- public/private subnet
- public/private route table
- internet gateway (for public subnet)
- nat gateway (for private subnet)
• VPC는 network traffic 흐름과
instance(EC2, RDS 등)의 위치를 결정
21
(이미지 출처: https://kr.pinterest.com/pin/
93238654757169806/)

22. RULE #0 작게 만들기
• AWS 3대장과 VPC
22
EC2 RDSS3

23. RULE #0 작게 만들기
• 작은 것들이 모여서
큰 시스템을 구성
23
(MSA: Microservices
architecture)

24. RULE #1 여러 번 반복 실행
24
계속 재현 가능하기 위한 개발 규칙들

25. RULE #1 여러 번 반복 실행
25

26. RULE #1 여러 번 반복 실행
• 모든 computing tier(EC2, Lambda 등)는
매일 “blue-green deployment”로 교체 (daily continuous deployment)
26

27. RULE #1 여러 번 반복 실행
• 매일 정해진 시간에
provisioning / deprovisioning 을 반복
27

28. RULE #1 여러 번 반복 실행
• 반복의 장점
• 불필요한 과정, 잘못된 과정을 좀 더 빨리 찾아내 수정할 기회가 생긴다.
(예: 오래되어 배포 중단된 3rd party library 문제)
• 반복할 수 있다는 건, 재현할 가능성이 높다는 의미
(‘반복 가능함’과 '재현 가능함’은 다른 의미)
28

29. RULE #2 IaC와 자동화
29
계속 재현 가능하기 위한 개발 규칙들

30. RULE #2 IaC와 자동화
• “사람의 기억과 손은 믿을 수 없다”
• DevOps 개발팀이 겪는 3R problem
• Repeatability
• Reproducibility
• Reliability
30
“내 개발 환경에서는 문제없었는데…”
“어제까지 문제없었는데…”
“실행하면 가끔씩 다른 결과가 나오네…”

31. RULE #2 IaC와 자동화
• 다수의 개발자로 이뤄진 DevOps 개발팀 위해 언제, 어디서나, 누구나 동일한 결
과가 나오는 실행 가능한 방법이 필요
• 즉, 모든 server infra, application의 config, provisioning 과정을 문서가 아닌
code로 관리
31
(IaC: Infrastructure as Code)

32. RULE #2 IaC와 자동화
• IaC (Infrastructure as Code)란?
IT system 관리를 모두 code화 시킨다는 아이디어
• 모든 것이 “실행 가능한 code”이므로 3R problem 해결
32
config
tool
(IaaS와 헷갈릴 수 있으니 조심)
(사람이 아닌 기계가 대신 실행할 수 있음)

33. RULE #2 IaC와 자동화
• EC2 서버 1EA 생성도 모두 자동화 (Python script)
33

34. RULE #2 IaC와 자동화
• ‘johanna’는 AWS CLI 기반으로 AWS infra 전체 또는 일부를 provisioning, de-
provisioning 할 수 있는 CLI
• 100% Python3 script 로 작성되어 있으며 OSS 로 공개 개발 (since 2016)
34
https://github.com/HardBoiledSmith/johanna/

35. RULE #2 IaC와 자동화
• IaC의 단점
- 결국 이것도 또 하나의 개발 프로젝트
- “꼭 필요한가?”라는 내부 고객의 질문에 답을 해야함
- IaC 유지 보수하는 비용(돈과 시간)을 들여서 더 득이 되는가? (ROI)
- 제대로 해본 사람이 적다.
35
<- IaC가 더 커질 수 있음
<- 본 프로젝트는 요 정도 인데

36. RULE #3 Full managed service 사용
36
계속 재현 가능하기 위한 개발 규칙들

37. RULE #3 Full managed service 사용
• Cloud 인프라 Abstraction level
• SaaS: Software 통채로 대여
• PaaS: Platform 까지 대여
• IaaS: Infrastructure만 대여
• On-Premises: Cloud 안 씁니다..
37
이미지 출처
http://www.hostingadvice.com/how-to/iaas-vs-paas-vs-saas/

38. RULE #3 Full managed service 사용
• ‘EC2에 DBMS를 설치하지 않고, 왜 RDS를 왜 쓰나요?'
• ‘EC2에 DBMS를 설치해서 쓰는게 더 싸지 않나요?”
38
이미지 출처
https://aws.amazon.com/blogs/database/part-1-role-of-the-dba-when-
moving-to-amazon-rds-responsibilities/
-> Platform 보다는 Application(business logic)에 더 집중할 수 있음
-> IT 기업에서 가장 비싼 자원은 개발자의 시간
-> 즉, legacy 가 될만한 요소
들을 알아서 관리해줌

39. RULE #3 Full managed service 사용
• (잠깐! PPL 입니다.) 인공지능 QA 자동화 서비스 'HBsmith'
39
실제 고객사 서비스의 사용자처럼 동작하는
‘hbsmith’ bot을 작성해서 QA 업무를 대체함
https://hbsmith.io

40. RULE #3 Full managed service 사용
• (잠깐! PPL 입니다.) 인공지능 QA 자동화 서비스 'HBsmith'
40
(실제 서비스 제공 예시)
https://hbsmith.io

41. RULE #4 발표와 토론
41
계속 재현 가능하기 위한 개발 규칙들

42. RULE #4 발표와 토론
42

43. RULE #4 발표와 토론
• 나이, 학벌, 경력, 시간, 장소를 뛰어넘는 문화
43

44. RULE #4 발표와 토론
• 끝 없이 공부하는 순도 높은 열정의 동종 업계 동료들 (경쟁이 아닌 협력)
44

45. RULE #4 발표와 토론
45

46. Wrap-up
• RULE #0 작게 만들기
• RULE #1 여러 번 반복 실행
• RULE #2 IaC와 자동화
• RULE #3 Full managed service 사용
• RULE #4 발표와 토론
46

47. 자문자답 - ‘이 일(개발)을 30년동안 할 수 있을까?’
• 끝없는 Legacy와의 사투
47
흐흐… 혼동, 파괴, 망가…
난 널 그렇게 만들
지 않았어 ㅠㅜ

48. 감사합니다
jongwon.han@hbsmith.io
010-9166-6855
48