NDC 2018 발표 자료입니다. 세션때 발표한 내용에 더불어 Q&A 일부를 추가했습니다.

1.
재현 가능한 게임 인프라
김민규
DEVSISTERS
!1
Packer, Terraform, Vault를 이용해 만드는

2. 발표자 소개
•Cookierun for Kakao
•Solitaire Decked:Out
•AWS 서버 접속용 오픈소스 툴 Eclair 개발
•공용 서비스팀 서버 인프라 설계 및 관리

3. 목차
•옛날 옛적 손으로 관리하던 인프라
•Terraform - 원하는 인프라의 상태를 정의하자
•Packer - 서버 이미지를 찍어내는 빵틀
•Vault - 안전한 패스워드 관리
•찾아온 변화들

4. 옛날 옛적 이야기

5. Cookierun for Kakao 시절
•Autoscale Group으로 관리되는 서버
•인프라 작업은 AWS Web Console을 통해
•어렵고 위험한 배포 과정

6. 손으로 관리하는 인프라의 문제
의도 된 것입니다
아니 이게 왜 이래요;
버그 아닌가요?

7. 손으로 관리하는 인프라의 문제
아 이건 이유가 있어서
바꿔둔 건가요?

8. 손으로 관리하는 인프라의 문제
•이건 좀 이상한데... 실수일까 의도한 걸까?
•그래서 지금 어디가 어떻게 되어있는거야?
•이건 누가 건드렸어요?
•에이 잘돌아가는데 냅두자...

9. 문서를 잘 쓰면 되지 않나요?
•의도와 실행이 다를 수 있음.
•한명이라도 제대로 안쓰면 작동하지 않음
•바빠요

10. 늘어가는 일들
•쿠키런 하나만 만들던 때는 지났다
•더 많은 게임들, 더 많은 내부 툴들
•같은 인프라를 다른 지역에 띄우기, 다른 계정에 띄우기
•대부분 다 비슷한 구성인데 일은 n배로....

12. 인프라 코드화의 욕구
•Operation 팀이 따로 없는 소규모 회사
•Operation을 개발과 병행하면서 해야 한다
•이대로는 힘들지 않을까?

14. HCL
•Hashicorp Configuration Language
•JSON compatible
•nginx config와 유사
•https://github.com/hashicorp/hcl

15. 코드로 정의하는 인프라
sample.tf

16. 1. sample이라는 이름의
2. aws_instance를 만들어 주세요
3. config는 이렇게요
코드로 정의하는 인프라
sample.tf
type name
config

17. 코드로 정의하는 인프라
$ terraform plan

18. 코드로 정의하는 인프라
$ terraform apply

19. 코드로 정의하는 인프라

20. Terraform이 하는 일
•내가 원하는 설정을 코드로 정의
•인프라의 현재 상태를 체크
•둘의 차이를 메꾸기 위한 작업을 실행
Config State Infrastructure
Resource Resource Resource

21. •resource "TYPE" "NAME" { config } 으로 원하는 리소스를 정의
•$ terraform plan
인프라에 어떤 변화가 일어날지 검토
•$ terraform apply
코드의 변화를 인프라에 적용
기본 사용법

22. 다른 리소스 참조하기

23. 동일한 리소스 반복 생성하기

24. 동일한 리소스 반복 생성하기

25. Module
sample-module/main.tf sample.tf

26. Module
$ terraform apply

27. 어라? 어디서 본 것 같은 기분이
•"${resource.name.attr}" 으로 다른 리소스 참조
•동일한 리소스를 여러개 생성하기 위한 count
•input을 받아 리소스들을 생성하고 output을 만드는 module

28. 어라? 어디서 본 것 같은 기분이
•"${resource.name.attr}" 으로 다른 리소스 참조
•동일한 리소스를 여러개 생성하기 위한 count
•input을 받아 리소스들을 생성하고 output을 만드는 module
변수
반복문
함수

29. 프로그래밍 하듯 작성 가능
•변수, 반복문, 함수와 유사함
•공통 부분을 모듈화시키는 것이 가능.
•노력을 통해 반복작업을 줄일 수 있다.

30. 인프라를 코드로 만들면 뭐가 좋아요?

31. 인프라를 코드로 만들면 뭐가 좋아요?
•저장소에 있는 코드 == 현재 인프라의 상태
•커밋 메시지로 작업자의 의도 파악 가능
•코드 개발에서 사용하던 모든 선진문화를 가져올 수 있다.
•Git / Text-based Search / Code Review

32. AWS뿐만 아니라
•수많은 다른 Provider들
•Azure, GCP, DigitalOcean, Naver Cloud, Datadog
•실제로 Datadog 대시보드를 Terraform으로 관리 중
•서로 다른 Provider의 정보를 참조하는 코드를 짤 수 있다.

33. Build Automated Machine Images

34. Packer가 하는 일
Shell Script Devsisters AMIBase AMI

35. Machine Image?

36. 어떻게 만들어요? - AWS의 경우
인스턴스를 띄우고 이것저것 깔고 이미지를 만들어요

37. 상세하게 들여다보면
•임시 Keypair를 생성
•EC2 Instance를 생성
•로컬에서 접속가능한 방화벽 룰도 설정
•SSH로 접속 후 설정한 Shell Script에 따라 인스턴스 세팅
•AMI 생성
•만들었던 리소스 전부 파괴

38. 이미지를 미리 준비해두면
•인스턴스 생성 때 셋업하는것에 비해 셋업 시간이 빨라진다
•빠른 부팅 속도 = 인스턴스가 늘어날 때 더 유연한 대처 가능

39. 원하는 것
데브시스터즈의 모든 서버가 공통으로 필요한 컴포넌트

40. Devsisters AMI에 넣는 것들
•SSH 접속용 CA
•Docker Daemon
•Datadog Agent
•유용하게 사용하는 CLI 도구들 (htop, dstat, jq)

41. 게임서버도 구워두면 안될까요?
•한번 build하는데 5분 - 7분
•하위 환경에서 Docker Image만 바꾸는데 5분이 걸리는건 아깝다.
•배포 주기가 긴 프로덕션에서는 적용해볼 생각이 있음.

43. 해결하고 싶은 문제
•게임 서버가 정상적으로 작동하기 위해서는 Secret이 필요하다
•ex) DB Password, API Secret
•자동으로 서버가 기동하려면 기동 시점에는 Secret을 알아야 함

44. 옛날 옛적에
•Cookierun for Kakao 시절
•chef + Autoscaling Group으로 서버 구성
•chef 저장소에 인프라의 모든 패스워드가 들어있었음

45. Secret in Code
•코드에 secret을 같이 커밋
•당연히 유출되면 망한다
•누군가 퇴사하면 모든 비밀번호를 교체해야 한다.
•회사 규모가 커지면 비용이 기하급수적으로 증가

47. Vault
•요청자가 적합한 권한을 갖고 있으면 secret을 내려준다.

48. Vault EC2 Auth
•EC2의 PKCS#7 서명을 이용
•모든 EC2 인스턴스에 존재
•AWS만 서명할 수 있고
공개된 Public Key를 이용해 검증

49. Vault EC2 Auth
1. EC2 Metadata API를 호출해
PKCS#7 서명을 받아옴
2. Vault에 해당 서명을 전송
3. Vault는 공개된 Public Key를
이용해 서명이 유효한지 검증
4. 유효하다면 해당 EC2의 정보를 읽고
권한을 가진 토큰 부여

50. 무슨 소리에요?
이 코드는 EC2에서 실행했을때만 패스워드를 받을 수 있다!

51. 무슨 소리에요?
•코드가 유출되어도 EC2 Metadata가 없기 때문에 Secret을 획득 불가
•따라서 커밋해도 안전하다!

52. 그 외의 매력적인 기능
•Signed SSH Certificates
•제한된 시간 동안만 서버들에 SSH 가능하도록 인증서로 서명하기
•Dynamic Secret
•한번만 쓸 수 있는 접속 유저정보

53. 구체적으로 어떻게 좋아졌나요?
•아무것도 없던 다른 환경 인프라를 띄우는데 30분 이내로 처리 가능
•누구나 적극적인 인프라 개선작업 가능
•해당 오픈소스에 직접 기여

54. 환경이 다르다는건 뭘까?
•네트워크가 다름 (VPC)
•서비스 Region이 다름 (ap-northeast-1, us-east-1)
•AWS 계정이 다름 (Test, Production)

55. 다른 환경에 동일한 인프라 추가하기
•AWS 계정, Region과 VPC를
정의하는 core 모듈을 추가
•게임 모듈에서는
추가된 core를 불러서 쓰도록 구현

56. Core Module
•작업의 기초가 되는 AWS Account, AWS Region, VPC를 정의
•나머지 모듈은 Core의 Output에 의존

57. 적극적인 인프라 개선작업
•처음 세팅해야하는 Variable 전부 제거
•커밋 로그를 보고 이전 컨텍스트를 아는 사람 찾기가 수월해짐
•거대한 테라폼 모듈은 관리 가능한 단위 모듈로 분해
•어렵고 복잡한 작업 (IAM Policy 등)은 잘 해둔 사람이 짜놓은 모듈 쓰기

58. 오픈 소스 프로젝트
•슬프게도 아직 코드를 열어봐야 하는 경우가 종종 있다.
•https://github.com/hashicorp/terraform
•https://github.com/hashicorp/vault
•https://github.com/hashicorp/packer

59. 아직 남아있는 숙제
•기존 인프라 Terraform으로 완전히 옮겨오기
•전사 공용으로 사용할 수 있는 리소스 이름 규칙
•Vault로 받아온 Secret을 좀 더 접근하기 어렵게

60. 아직 남아있는 숙제
•기존 인프라 Terraform으로 완전히 옮겨오기
•전사 공용으로 사용할 수 있는 리소스 이름 규칙
•Vault로 받아온 Secret을 좀 더 접근하기 어렵게

61. Q&A
Q: Terraform state file 관리는 어찌하나요?
A: 현재는 Remote State로 S3를 사용하고 있습니다. 속도의 경우 Consul
이 확실히 빠른데, State에 Sensitive Data가 들어가는 일이 없잖이 있고,
Versioning 기능도 굉장히 유용해서 S3으로 결정했습니다.

62. Q&A
Q: 플랜을 해봐야 테라폼의 코드가 최신화되지않은 것을 알수있는데,
인프라 적용시점과 코드가 그에따라 커밋되고 푸쉬되는 시점은 언제인가요?
A: 작업자는 Apply까지 마친 후에 푸쉬합니다. 저장소에 있는 코드 상태가
인프라의 현재 상태를 나타내는걸 목적으로 하고 있습니다.

63. Q&A
Q: 기존에 존재하는 테라폼으로 구현되지않은 일부 인프라가 있고 약간의
연결만 있어도 콘솔과 사용을 병행하게되면 실제 환경과 테라폼 코드가 맞
지 않는 환경이 발생할 수 있는데 예방대책이 있나요?
A: 기본적으로 테라폼은 Apply 전에 현재 인프라 상태를 다시 한번 확인해
상태를 갱신하긴 합니다. 하지만 말씀하신 문제가 있어서 테라폼으로 관리
하는 리소스는 코드로만 수정하도록 하는게 이상적입니다. Strict하게 한다
면 AWS 콘솔에 접속하는 계정을 Readonly로만 설정하는 방법도 있겠지
만, 현재 적용하고 있지는 않습니다.

64. Q&A
Q: 테라폼 모듈화는 어떤 단위로 하셨나요?
A: 인프라 상에서 큰 의미를 갖는 단위 (게임 서버, 데이터베이스, 캐시 서
버) 를 한 모듈로 만듭니다. 다만 모듈과 모듈 사이의 관계 (Security Group
Rule) 등은 한 모듈에 들어있으면 의존성이 복잡하게 얽히기 쉬워서, 루트
모듈에 작성했습니다.

65. 감사합니다