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

<왓 스튜디오 서비스파트>
김찬웅
왓 스튜디오의 DevOps 살펴보기
넥슨 코리아 왓 스튜디오

저작물 인용
저작권법 제35조의 3 ‘공정이용’ 조항에 따라 교육과 연구 목적으로 이용
하고 있습니다. 혹시 문제가 있을 경우, cwkim@nexon.co.kr 로 연락
주시면 적절한 조치를 취하겠습니다.

김찬웅
넥슨, 왓 스튜디오, 백엔드 엔지니어
• NDC15 <그룹웨어에 새 에너지를>
• NDC16 <Find My AndPhone>
• NDC16 <Effective Git>
• NDC17 <왓 스튜디오 서비스파트> ← New!
kexplo
http://chanwoong.kim
cwkim@nexon.co.kr
kexplo

이 발표에서 다룰 내용
• 서비스파트?
• DevOps?
• 코드!
• 빌드!
• 테스트!
• 배포!
• 피드백!

왓 스튜디오
서비스파트?

서비스파트
팀의 “서비스”를 위한 조직

“아니 라이브 중인 게임도 없으면서 무슨 서비스예요?”
꿀 빠는 조직 아닌가요?

“아니 라이브 중인 게임도 없으면서 무슨 서비스에요?”
꿀 빠는 조직 아닌가요?
아닙니다.

• 외적
• 서비스를 하기 위한 서버 기반 마련
• 내적
• 개발에 필요한 도움 제공
A/S
서버 프레임워크 개발
배포 환경 구축
내부 개발 환경 설정
편의 도구 개발
테스팅 환경 구축

여러가지 일을 맡다 보니, 다양한 스택의 사람들이 모임
DBA
잡캐
Brogrammer
웹
서버 아키텍트
자료공

물론 이상한 사람들도
※ 합성 아닙니다.

•외적
•내적

•외적
•내적
DevOps

DevOps?
DevOps
Development Operations
개발 운영

DevOps!
•개발 – 빌드 – 테스트 – 배포 –피드백 공정

DevOps 살펴보기
•개발 – 빌드 – 테스트 – 배포 –피드백 공정 소개
•각 공정 단계에서 사용하는 기술과 활용을 넓고 얇게

개발
• Git
• Code Review
• GitLab
• Windows Subsystem for Linux
• Docker
개발-빌드-테스트-배포-피드백

Git
https://www.slideshare.net/kexplo/ndc2016-effective-git

코드리뷰
•코드의 기능적, 성능적 취약성을 미리 진단할 수 있음.
•작업자들 간의 코드 이해도 증가.
•잘못된 개발 방향을 미리 진단해, 개발 비용 절감.

현실

“리뷰할 시간 없어요”
•마일스톤 막바지에 몰리는 코드 리뷰
•리뷰어의 작업 시간은 공짜가 아니다
•다른 작업물의 맥락을 파악하는 것도 큰 비용

리뷰의 가장 큰 걸림돌?
•읽기 힘든 커밋 로그
•(파악할 맥락이) 너무 많은 코드 양

리뷰를 편하게 하자 (1/2)
•“커밋이 읽기 너무 힘들어요”
•커밋은 “좋은 커밋 메시지” 규격에 맞춘다.
• 제목 행의 길이를 제한
• 명령 어조를 사용
• ‘어떻게’ 보다는 ‘무엇’과 ‘왜’를 설명

https://chris.beams.io/posts/git-commit/

리뷰를 편하게 하자 (2/2)
•“코드 맥락을 파악하기에 너무 양이 많아요”
•리뷰 코드의 양을 최소화 한다.

한 번에 리뷰해야 할 양

GitLab
•서비스형 Git 저장소인 GitHub을 사용하지 않을 경우
•설치형 Git 서비스의 가장 현실적인 대안

• Repository
• Issue Board
• Review
• CI
• Build Pipelines
• Docker Container
Registry
https://about.gitlab.com/

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로 된 쓰기 편한 자동 설정 도구를 제공

•단점은?

미 구현된 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 어셋 빌드 업로드

사라지지 않는 의존성
“방금 만든 브랜치의 버전의 빌드가 필요해요“
“업로드 저장소를 정리했어요, 업로드만 새로 해주세요“

여전히 최소 단위 Job은 프로그래머의 의존성이 필요..

여전히 최소 단위 Job은 프로그래머의 의존성이 필요..
어? 그런데 새로운 기능은 아니다!

Jenkins, Build With Parameters Plugin
•주관식, 객관식의 파라미터를 입력 받을 수 있게 해 줌.
•Jenkins의 기능 Job의 재사용성을 늘릴 수 있게 되었음.
•모든 파라미터는 환경변수로 오기 때문에,
자주 쓰는 파라미터는
새로운 빌드 Job으로 생성 가능

Android iOS
결과물 업로드 X
알림 X

Android iOS
알림 X
빌드

Android iOS
알림 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)

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 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 두 대를 띄우려면?
•Launch!
×2

AWS에서 EC2 n 대를 띄우려면?
•Launch!
×n

AWS에서 EC2 n 대를 띄우..다가 손이 미끄러지면?
•Launch!
×n

유일한 AWS 담당자

Bus Factor
팀원이 버스에 치였을 때, 프로젝트는 안전할까?

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-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>"

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
•실시간 에러 트레킹 시스템

로그 스트리밍 시스템
•(EFK) Elasticsearch, fluentd, Kibana 스택으로 구성
Game Server
Game Server
…
Kinesis
Lambda
Lambda
S3 S3 (parquet)EMR
Elasticsearch
Service
EMR (Zeppelin)

Kibana
•앞에서 모은 로그를 Kibana를 통해 실시간 쿼리
•실시간으로 로그를 통해, 현재 상태를 짐작할 수 있다.

Zeppelin
• 정제 해 놓은 로그를 바탕으로 쿼리
• 지나간 로그를 바탕으로 통계 등을 내기가 쉽다.
• 대시 보드의 접근성이 좋아, 게임 디자이너가 원하는 지표를 직접
쿼리

Datadog
•모니터링 서비스
•서버의 실시간 메트릭을 전송
•원하는 시점의 커스텀 메트릭 그래프를 만들 수 있다.
• 서버 별 동접, 섬 별 동물 수, 서버 간 동기화 빈도, …
• 서버의 상황을 파악하고 새로운 관점을 알게 해준다

다시 서비스파트
마지막으로

오픈 소스 활동
•https://github.com/what-studio
•파트 내에서 오픈소스 활동을 적극 권장

업무 공유의 장
•서로의 업무를 공유하는 작은 모임인 SDC를 가짐
•동료가 공룡에게 물려가도 항상 백업 가능한 환경 조성

업무 공유의 장
•서로의 업무를 공유하는 작은 모임인 SDC를 가짐
•동료가 공룡에게 물려가도 항상 백업 가능한 환경 조성
파트원 모두가 DevOps 엔지니어
ServicePart Developer Conference

We’re hiring 같이 일할 이상한 분을 구합니다

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

Similar to [NDC17] 왓 스튜디오 서비스파트 (20)

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