Post on 21-Jan-2018
<왓 스튜디오 서비스파트>
김찬웅
왓 스튜디오의 DevOps 살펴보기
넥슨 코리아 왓 스튜디오
저작물 인용저작권법 제35조의 3 ‘공정이용’ 조항에 따라 교육과 연구 목적으로 이용하고 있습니다. 혹시 문제가 있을 경우, cwkim@nexon.co.kr 로 연락주시면 적절한 조치를 취하겠습니다.
소개
김찬웅
넥슨, 왓 스튜디오, 백엔드 엔지니어
• NDC15 <그룹웨어에 새 에너지를>
• NDC16 <Find My AndPhone>
• NDC16 <Effective Git>
• NDC17 <왓 스튜디오 서비스파트> ← New!kexplo
http://chanwoong.kimcwkim@nexon.co.kr
kexplo
김찬웅
넥슨, 왓 스튜디오, 백엔드 엔지니어
• NDC15 <그룹웨어에 새 에너지를>
• NDC16 <Find My AndPhone>
• NDC16 <Effective Git>
• NDC17 <왓 스튜디오 서비스파트> ← New!kexplo
http://chanwoong.kimcwkim@nexon.co.kr
kexplo
이 발표에서 다룰 내용• 서비스파트?• DevOps?• 코드!• 빌드!• 테스트!• 배포!• 피드백!
왓 스튜디오
서비스파트?
…
…서비스파트
서비스파트
팀의 “서비스”를 위한 조직
“아니 라이브 중인 게임도 없으면서 무슨 서비스예요?”
꿀 빠는 조직 아닌가요?
“아니 라이브 중인 게임도 없으면서 무슨 서비스에요?”
꿀 빠는 조직 아닌가요?아닙니다.
•외적
• 서비스를 하기 위한 서버 기반 마련
•내적
• 개발에 필요한 도움 제공A/S
서버 프레임워크 개발배포 환경 구축
내부 개발 환경 설정편의 도구 개발테스팅 환경 구축
여러가지 일을 맡다 보니, 다양한 스택의 사람들이 모임
DBA
잡캐
Brogrammer
웹
서버 아키텍트
자료공
물론 이상한 사람들도
※ 합성 아닙니다.
#서비스파트
•외적
• 서비스를 하기 위한 서버 기반 마련
•내적
• 개발에 필요한 도움 제공
서버 프레임워크 개발배포 환경 구축
내부 개발 환경 설정편의 도구 개발테스팅 환경 구축
•외적
• 서비스를 하기 위한 서버 기반 마련
•내적
• 개발에 필요한 도움 제공
서버 프레임워크 개발배포 환경 구축
내부 개발 환경 설정편의 도구 개발테스팅 환경 구축
DevOps
DevOps?
DevOps?
DevOpsDevelopment Operations
개발 운영
DevOps!
•개발 – 빌드 – 테스트 – 배포 –피드백 공정
DevOps 살펴보기
•개발 – 빌드 – 테스트 – 배포 –피드백 공정 소개
•각 공정 단계에서 사용하는 기술과 활용을 넓고 얇게
개발
• Git• Code Review• GitLab• Windows Subsystem for Linux• Docker
개발-빌드-테스트-배포-피드백
Git
https://www.slideshare.net/kexplo/ndc2016-effective-git
개발-빌드-테스트-배포-피드백
코드리뷰
•코드의 기능적, 성능적 취약성을 미리 진단할 수 있음.
•작업자들 간의 코드 이해도 증가.
•잘못된 개발 방향을 미리 진단해, 개발 비용 절감.
개발-빌드-테스트-배포-피드백
현실개발-빌드-테스트-배포-피드백
“리뷰할 시간 없어요”
•마일스톤 막바지에 몰리는 코드 리뷰
•리뷰어의 작업 시간은 공짜가 아니다
•다른 작업물의 맥락을 파악하는 것도 큰 비용
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
리뷰의 가장 큰 걸림돌?
•읽기 힘든 커밋 로그
• (파악할 맥락이) 너무 많은 코드 양
개발-빌드-테스트-배포-피드백
리뷰를 편하게 하자 (1/2)
• “커밋이 읽기 너무 힘들어요”
•커밋은 “좋은 커밋 메시지” 규격에 맞춘다.
• 제목 행의 길이를 제한
• 명령 어조를 사용
• ‘어떻게’ 보다는 ‘무엇’과 ‘왜’를 설명
개발-빌드-테스트-배포-피드백
리뷰를 편하게 하자 (2/2)
• “코드 맥락을 파악하기에 너무 양이 많아요”
•리뷰 코드의 양을 최소화 한다.
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
한 번에 리뷰해야 할 양
개발-빌드-테스트-배포-피드백
GitLab
•서비스형 Git 저장소인 GitHub을 사용하지 않을 경우
•설치형 Git 서비스의 가장 현실적인 대안
개발-빌드-테스트-배포-피드백
• Repository
• Issue Board
• Review
• CI
• Build Pipelines
• Docker Container Registry
https://about.gitlab.com/
개발-빌드-테스트-배포-피드백
Linux와 Python을 사용하는 서버 개발 환경
개발-빌드-테스트-배포-피드백
Linux와 Python을 사용하는 서버 개발 환경
개발-빌드-테스트-배포-피드백
Linux와 Python을 사용하는 서버 개발 환경
…은 모두에게 친절하진 않다.
일단 회사에서 지급하는 PC만 해도 Windows.
사용하는 대상이 ‘프로그래머’가 아닐
경우에는 더 심각해 진다.
개발-빌드-테스트-배포-피드백
리눅스
당연히 Virtual Machine!
https://www.virtualbox.org
개발-빌드-테스트-배포-피드백
하지만…
•파일 수정, 공유의 제약
• Linux에 익숙하지 않으니, Vim, Emacs에 익숙하지 않음
• Samba, rsync, ftp, …. 썩 만족스러운 방법이 없음
개발-빌드-테스트-배포-피드백
하지만…
•파일 수정, 공유의 제약
• Linux에 익숙하지 않으니, Vim, Emacs에 익숙하지 않음
• Samba, rsync, ftp, …. 썩 만족스러운 방법이 없음
아, 맞다. 이건 당연히 안 쓰는거죠
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
돼.
개발-빌드-테스트-배포-피드백
https://blogs.msdn.microsoft.com/msdntaiwan/2016/04/20/developers-can-run-bash-shell-and-user-mode-ubuntu-linux-binaries-on-windows10-cht/
개발-빌드-테스트-배포-피드백
그림 출처: https://gifamerica.com/categories/view/de2da6dc70721cc940d774355e74ad6e341275be/rainbow-throw-up-gif.html
개발-빌드-테스트-배포-피드백
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/
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
•장점
• (베타 지만) VM이 아닌 Linux 환경을 제공 함
• Linux에서 Windows의 파일을 바로 접근 할 수 있음
• Windows의 각 드라이브는 /mnt/<drive>/ 경로로 매핑.
• (Windows) C:\test.txt == (Linux) /mnt/c/test.txt
• VBoxSDK 같은 걸 쓰지 않아도, 자동화 하기 편리함
• > bash.exe –c “echo ‘Hello, World!’”
개발-빌드-테스트-배포-피드백
•덕분에
• Windows에서 본인에게 편한 에디터를 사용.
• Visual Studio, PyCharm, gVim(?), …
• 서버는 Linux 환경을 보장 받음.
• 다른 직군이 쉽게 서버를 로컬 배포할 수 있도록,
GUI로 된 쓰기 편한 자동 설정 도구를 제공
개발-빌드-테스트-배포-피드백
•덕분에
• Windows에서 본인에게 편한 에디터를 사용.
• Visual Studio, PyCharm, gVim(?), …
• 서버는 Linux 환경을 보장 받음.
• 다른 직군이 쉽게 서버를 로컬 배포할 수 있도록,
GUI로 된 쓰기 편한 자동 설정 도구를 제공
개발-빌드-테스트-배포-피드백
•단점은?
개발-빌드-테스트-배포-피드백
•단점은?
개발-빌드-테스트-배포-피드백
•단점은?
개발-빌드-테스트-배포-피드백
•단점은?
개발-빌드-테스트-배포-피드백
•단점은?
개발-빌드-테스트-배포-피드백
•단점은?
개발-빌드-테스트-배포-피드백
미 구현된 OS 기능들이 아직 남아있음
https://blogs.msdn.microsoft.com/wsl/2017/04/11/testing-the-windows-subsystem-for-linux/
개발-빌드-테스트-배포-피드백
기능별 완성도가 다르기에, 사용하려는 기능의 호환성 체크가 필수!
서버에서 사용하는 다른 개발 스택(Couchbase, Redis, …)은
Docker (for Windows)를 이용해서 보충 가능!
개발-빌드-테스트-배포-피드백
Docker for Windows
WSL
Docker client
Windows
개발-빌드-테스트-배포-피드백
$ export DOCKER_HOST=tcp://127.0.0.1:2375
Docker for Windows
WSL
Docker client
Windows
개발-빌드-테스트-배포-피드백
지금 여러분의 마음 잘 압니다
<뭣! 공작소 봉사 조직>발표
개발-빌드-테스트-배포-피드백
개발팀의 요구사항
•서버는 어디에 떠도 상관 없지만, 파일을 윈도우 환경에서
수정하고 싶다.
•수정 반영 실행의 이터레이션이 빨랐으면 좋겠다.
개발-빌드-테스트-배포-피드백
다른 옵션
•서버를 Dockerize
•Docker for Windows를 사용해서 실행
•개발 파일은 Volume mount로 Windows와 매핑
개발-빌드-테스트-배포-피드백
Windows Docker Volume mount의 걸림돌..
•Symbolic Link
•File Socket
개발-빌드-테스트-배포-피드백
Windows Docker Volume mount의 걸림돌
•Symbolic Link
•File Socket
…은 대부분 해결!
개발-빌드-테스트-배포-피드백
미래
•서버의 완벽한 Dockerize를 추진 중
•WSL은 Linux CLI를 사용하기 위한 보조 수단으로 남을 예정
개발-빌드-테스트-배포-피드백
빌드• GitLab CI• Jenkins
개발-빌드-테스트-배포-피드백
GitLab CI
•GitLab에서 제공하는 내장형 CI
•저장소의 .gitlab-ci.yml을 통해 빌드 파이프라인을 구성
•Travis CI를 만져본 경험이 있다면, 비슷하게 사용 가능
•설치형 GitHub+Travis CI같은 경험을 느낄 수 있다.
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
클라이언트 빌드를 뽑다보면…
•Android를 빌드할 땐 xxx를 해야 하고… iOS를 빌드할 땐,
Xcode Project 결과물을 만들고, 인증서를 맞춰주고…
•이번엔 Development 빌드를 뽑아야 하고, 다음엔
Release 빌드를 뽑아야 해
•10일전 커밋으로 새로 빌드해 보자
•결과물을 S3에 모아서 올리도록 하자.
•완료되면 알림을 줘
개발-빌드-테스트-배포-피드백
./build.sh
# 나 한다 빌드
./build.sh
# 나 한다 설정, 이동, 받기, 빌드, 배포, …
다양한 요구사항 지원으로 비대해지는 스크립트개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
정해진 기준
•효율이 상대적으로 높은, Python 스크립트로 재 작성
•3번 이상 들어온 요구사항은 자동화 대상
•기능을 모듈식으로 나누어서 조립해 사용할 수 있게 한다
•명령어를 몰라도 쓸 수 있게 한다
개발-빌드-테스트-배포-피드백
Python CLI 빌드 툴
•Python을 이용하여 빌드용 All-In-One CLI 툴을 제작
•앞에서 정한 ‘기능’이 하위 명령어가 된다.
•쉘에서 간단하게 빌드의 모든 과정을 수행가능!
$ wbuild <update|build|upload|…> [options]
개발-빌드-테스트-배포-피드백
Jenkins
•설치형 오픈소스 CI 도구Continuous Integration
개발-빌드-테스트-배포-피드백
Jenkins
•설치형 오픈소스 CI 도구
플러그인이 엄청나게 많은!
Continuous Integration
개발-빌드-테스트-배포-피드백
Jenkins, MultiJob Plugin
•최소 단위인 Job을 연결해서 Pipeline을 만들어 준다.
•CLI의 기능별 Job을 연결해, 레고 조립하듯 빌드를
만들어내는 커다란 Job을 구축.
개발-빌드-테스트-배포-피드백
환경 설정 Android 빌드 업로드 알림
환경 설정 iOS 어셋 빌드 업로드
개발-빌드-테스트-배포-피드백
환경 설정 Android 빌드 업로드 알림
환경 설정 iOS 어셋 빌드 업로드
개발-빌드-테스트-배포-피드백
환경 설정 Android 빌드 업로드 알림
환경 설정 iOS 어셋 빌드 업로드
개발-빌드-테스트-배포-피드백
사라지지 않는 의존성
“방금 만든 브랜치의 버전의 빌드가 필요해요“
“업로드 저장소를 정리했어요, 업로드만 새로 해주세요“
개발-빌드-테스트-배포-피드백
사라지지 않는 의존성
“방금 만든 브랜치의 버전의 빌드가 필요해요“
“업로드 저장소를 정리했어요, 업로드만 새로 해주세요“
여전히 최소 단위 Job은 프로그래머의 의존성이 필요..
개발-빌드-테스트-배포-피드백
사라지지 않는 의존성
“방금 만든 브랜치의 버전의 빌드가 필요해요“
“업로드 저장소를 정리했어요, 업로드만 새로 해주세요“
여전히 최소 단위 Job은 프로그래머의 의존성이 필요..
어? 그런데 새로운 기능은 아니다!
개발-빌드-테스트-배포-피드백
Jenkins, Build With Parameters Plugin
•주관식, 객관식의 파라미터를 입력 받을 수 있게 해 줌.
•Jenkins의 기능 Job의 재사용성을 늘릴 수 있게 되었음.
•모든 파라미터는 환경변수로 오기 때문에,
자주 쓰는 파라미터는
새로운 빌드 Job으로 생성 가능
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
Android iOS
결과물 업로드 X
알림 X
개발-빌드-테스트-배포-피드백
Android iOS
결과물 업로드 X
알림 X
빌드
개발-빌드-테스트-배포-피드백
Android iOS
결과물 업로드 X
알림 X
빌드
개발-빌드-테스트-배포-피드백
Android iOS
결과물 업로드 X
알림 X
빌드
개발-빌드-테스트-배포-피드백
Android iOS
결과물 업로드 X
알림 X
빌드
개발-빌드-테스트-배포-피드백
Android iOS
결과물 업로드 X
알림 X
빌드
완료
개발-빌드-테스트-배포-피드백
Jenkins, Rebuild Plugin
•앞에서 소개한 ‘Build With Parameters Plugin’와 함께
사용하면 좋은 플러그인
•같은 조건으로 빌드를 재시도할 경우, 파라미터를 다시 넣는
게 꽤 귀찮은 일이다.
•버튼 하나로 해결!
개발-빌드-테스트-배포-피드백
Jenkins, Log Parser Plugin
•로그를 파싱 해서 보기 좋게 정제해 보여준다.
•파싱 룰은 정규식으로 작성 가능
개발-빌드-테스트-배포-피드백
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/
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
매일 자동으로 돌아가는 빌드일 경우
빌드가 깨지면, 대부분 프로그래밍 오류다.
이 경우에 문제를 빠르게 파악하는데 도움이 된다.
문제를 전달하는 사람도 “빌드가 깨졌어요” 보다 더 좋은 정보를
제공해줄 수 있게 된다.
개발-빌드-테스트-배포-피드백
얻은 이점: 최소한의 프로그래머 의존성
•프로그래머는 실제로 빌드에 문제가 생긴 경우를 제외하고,
최소한의 의존성만 가지게 됨
•마일스톤 막바지에 프로그래머를 찾는 일이 적어짐
• 생산성 향상
•프로그래머 없이 원하는 형태의 빌드를 생성 가능
개발-빌드-테스트-배포-피드백
번외: Jenkins, Blue Ocean 1.0
• 발표 자료를 만들다 보니 어느새 정식 버전이!
• 파이프라인 에디터를 지원 한다고 하니, 새로 도입하시는 분들은 고려해
보실 만 하겠습니다.
• 일단 예쁘기도 하고
개발-빌드-테스트-배포-피드백
테스트 • pytest• Travis CI• coveralls.io
개발-빌드-테스트-배포-피드백
pytest: helps you write better programs개발-빌드-테스트-배포-피드백
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)
개발-빌드-테스트-배포-피드백
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)
개발-빌드-테스트-배포-피드백
pytest, parametrize
import pytest
@pytest.mark.parametrize("test_input", [1, 2, 3, 4])
def test_function(test_input):
assert test_input < 5
개발-빌드-테스트-배포-피드백
pytest, parametrize
import pytest
@pytest.mark.parametrize("test_input", [1, 2, 3, 4])
def test_function(test_input):
assert test_input < 5
개발-빌드-테스트-배포-피드백
pytest, parametrize
import pytest
@pytest.mark.parametrize("test_input", [1, 2, 3, 4])
def test_function(test_input):
assert test_input < 5
개발-빌드-테스트-배포-피드백
pytest, parametrize
import pytest
@pytest.mark.parametrize("test_input", [1, 2, 3, 4])
def test_function(test_input):
assert test_input < 5
개발-빌드-테스트-배포-피드백
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
개발-빌드-테스트-배포-피드백
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)
개발-빌드-테스트-배포-피드백
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
개발-빌드-테스트-배포-피드백
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
개발-빌드-테스트-배포-피드백
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()
개발-빌드-테스트-배포-피드백
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()
개발-빌드-테스트-배포-피드백
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
개발-빌드-테스트-배포-피드백
Docker를 fixture로 만들어 사용
• Docker instance를 띄우고, 사용 후 제거하는 fixture.
• 테스트를 위한 1회용 docker같은 느낌으로 쓸 수 있다.
• Unit Test를 넘어서 Integration Test로 확장 가능
개발-빌드-테스트-배포-피드백
활용
# docker fixture POC
@pytest.fixture(scope="function")
def docker():
docker = run_container(blahblah)
yield docker
docker.kill_container()
개발-빌드-테스트-배포-피드백
pytest-cov개발-빌드-테스트-배포-피드백
GitHub Project의 테스트
• Travis CI
• Coverall.io
개발-빌드-테스트-배포-피드백
Travis CI
•GitHub 과 연계하여 무료로 사용할 수 있는 CI
•프로젝트 루트의 .travis.yml를 사용하여 빌드를 구성설정 방법은 문서화가 잘 되어있다.https://docs.travis-ci.com
개발-빌드-테스트-배포-피드백
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
개발-빌드-테스트-배포-피드백
coveralls.io개발-빌드-테스트-배포-피드백
배포• Terraform
개발-빌드-테스트-배포-피드백
AWS에서 EC2 한 대를 띄우려면?
•AWS 콘솔 로그인
•EC2 대시보드 접속
•EC2 인스턴스 선택
• 각종 옵션 설정
•Launch!
개발-빌드-테스트-배포-피드백
AWS에서 EC2 두 대를 띄우려면?
•AWS 콘솔 로그인
•EC2 대시보드 접속
•EC2 인스턴스 선택
• 각종 옵션 설정
•Launch!
×2
개발-빌드-테스트-배포-피드백
AWS에서 EC2 n 대를 띄우려면?
•AWS 콘솔 로그인
•EC2 대시보드 접속
•EC2 인스턴스 선택
• 각종 옵션 설정
•Launch!
×n
개발-빌드-테스트-배포-피드백
AWS에서 EC2 n 대를 띄우..다가 손이 미끄러지면?
•AWS 콘솔 로그인
•EC2 대시보드 접속
•EC2 인스턴스 선택
• 각종 옵션 설정
•Launch!
×n
개발-빌드-테스트-배포-피드백
유일한 AWS 담당자
개발-빌드-테스트-배포-피드백
개발-빌드-테스트-배포-피드백
Bus Factor팀원이 버스에 치였을 때, 프로젝트는 안전할까?
개발-빌드-테스트-배포-피드백
AWS 콘솔을 여러명이 사용하면?
• “이 EC2 인스턴스 누가 만들었어요?”
• “이거 IAM User가 이상한데, 누구거에요?”
• “Inbound 규칙이 다른데, 의도한건가요?”
• “이거 지워도 돼요???”
개발-빌드-테스트-배포-피드백
AWS 콘솔을 여러명이 사용하면?
• “이 EC2 인스턴스 누가 만들었어요?”
• “이거 IAM User가 이상한데, 누구거에요?”
• “Inbound 규칙이 다른데, 의도한건가요?”
• “이거 지워도 돼요???”
개발-빌드-테스트-배포-피드백
그 밖에도…
•보안 문제
•소유 문제
•컨벤션 문제
개발-빌드-테스트-배포-피드백
Terraform
•HashCorp에서 만든 인프라 관리 도구
•AWS의 인프라를 코드로써 다룰 수 있는 것이 특징
• “Infrastructure as code”
•선언적으로 관리하기 때문에 직관적
개발-빌드-테스트-배포-피드백
resource "aws_instance" "example" {
ami = "ami-2757f631"
instance_type = "t2.micro"
}
개발-빌드-테스트-배포-피드백
$ 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>"
개발-빌드-테스트-배포-피드백
$ 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.
# ...
개발-빌드-테스트-배포-피드백
$ 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.
resource "aws_instance" "example" {
ami = "ami-2757f631"
instance_type = "t2.micro"
}
개발-빌드-테스트-배포-피드백
resource "aws_instance" "example" {
ami = "ami-b374d5a5"
instance_type = "t2.micro"
}
개발-빌드-테스트-배포-피드백
$ 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>"
개발-빌드-테스트-배포-피드백
$ 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>"
© AWS re:Invent 2016| GAM401 | Riot Games: Standardizing Application Deployments Using Amazon ECS and Terraform
개발-빌드-테스트-배포-피드백
© AWS re:Invent 2016| GAM401 | Riot Games: Standardizing Application Deployments Using Amazon ECS and Terraform
개발-빌드-테스트-배포-피드백
Game Server
DB
…
Dev
Game Server
DB
…
Production
Game Server
DB
…
Staging
손쉬운 개발 환경 추가
Game Server
DB
…
?
개발-빌드-테스트-배포-피드백
코드로 관리하기 때문에
• 누구든지 인프라 배포 가능
• 똑같은 설정의 인프라를 쉽게 생성 가능
• 버전 관리가 되므로, 인프라의 의도를 전달받을 수 있음
• 사용자의 실수 방지
개발-빌드-테스트-배포-피드백
T-Rex Factor
코드로 관리하기 때문에
• 누구든지 인프라 배포 가능
• 똑같은 설정의 인프라를 쉽게 생성 가능
• 버전 관리가 되므로, 인프라의 의도를 전달받을 수 있음
• 사용자의 실수 방지
• 마지막 작업자를 공룡이 물어가도 안심!
개발-빌드-테스트-배포-피드백
피드백• Sentry• Zeppelin• Kibana• DataDog
개발-빌드-테스트-배포-피드백
클라이언트의 에러를 보는 법?
•한 땀 한 땀 로그를 찍는다
•로그 뷰어에 연결한다
•눈이 빠지게 로그를 찾는다
Android logcat
개발-빌드-테스트-배포-피드백
Sentry
•실시간 에러 트레킹 시스템
개발-빌드-테스트-배포-피드백
© sentry.io
개발-빌드-테스트-배포-피드백
© sentry.io
개발-빌드-테스트-배포-피드백
© sentry.io
개발-빌드-테스트-배포-피드백
© sentry.io
개발-빌드-테스트-배포-피드백
로그 스트리밍 시스템
• (EFK) Elasticsearch, fluentd, Kibana 스택으로 구성
Game Server
Game Server…
Kinesis
Lambda
Lambda
S3 S3 (parquet)EMR
ElasticsearchService
개발-빌드-테스트-배포-피드백
EMR (Zeppelin)
Kibana
•앞에서 모은 로그를 Kibana를 통해 실시간 쿼리
•실시간으로 로그를 통해, 현재 상태를 짐작할 수 있다.
개발-빌드-테스트-배포-피드백
Zeppelin
•정제 해 놓은 로그를 바탕으로 쿼리
•지나간 로그를 바탕으로 통계 등을 내기가 쉽다.
•대시 보드의 접근성이 좋아, 게임 디자이너가 원하는 지표를 직접
쿼리
개발-빌드-테스트-배포-피드백
Datadog
•모니터링 서비스
•서버의 실시간 메트릭을 전송
•원하는 시점의 커스텀 메트릭 그래프를 만들 수 있다.
• 서버 별 동접, 섬 별 동물 수, 서버 간 동기화 빈도, …
• 서버의 상황을 파악하고 새로운 관점을 알게 해준다
개발-빌드-테스트-배포-피드백
© Datadog
개발-빌드-테스트-배포-피드백
What’s NEXT?
ChatOps
•채팅 + 봇 + DevOps
© https://github.com/StackStorm/showcase-ansible-chatops
Hubot ErrBot
다시 서비스파트마지막으로
오픈 소스 활동
•https://github.com/what-studio
•파트 내에서 오픈소스 활동을 적극 권장
업무 공유의 장
•서로의 업무를 공유하는 작은 모임인 SDC를 가짐
•동료가 공룡에게 물려가도 항상 백업 가능한 환경 조성
업무 공유의 장
•서로의 업무를 공유하는 작은 모임인 SDC를 가짐
•동료가 공룡에게 물려가도 항상 백업 가능한 환경 조성
파트원 모두가 DevOps 엔지니어
ServicePart Developer Conference
We’re hiring 같이 일할 이상한 분을 구합니다
감사합니다