김태현
Sr. SW Engineer. (Blizzard Entertainment)
---
글로벌 게임서비스의 무정지, 무점검 서버 개발과 운영의 사례를 소개
1. 무정지 무점검을 위해 적용된 서버 개발 기술들의 소개
2. 무정지 무점검 운영을 위한 서버의 구성과 DevOps 운용 소개
9. 발표자 소개
• Blizzard 클래식팀에서 서버개발 (Sr. SW Engineer)
• 최근까지 Nexon America에서 Sr. Manager, DevOps &
Technology 담당
• NDC 2011,12,17년 우수발표 선정
• 1998년에 머신비전 프로그래머로 커리어 시작 후
• 여러 벤처기업과 NHN, SK컴즈 등에서 온라인 어플개발,
게임서버개발 등 담당
10. .. 의 어떤 게임들은 년이 넘는 역사를 가지고 있습니다
클래식팀의 목표는 이런 블리자드 게임들을 게임팬들이 현대적 컴퓨터 환경
에서 계속 즐길 수 있도록 하는 것입니다
11. 0 ,(.. )
NCS
년 이상된 게임을 현대적 환경에서 지속하기위한 기술적인 어려움을 극복하고자
라고 불리는 새로운 서버스택을 개발 새로운 기능 추가와 관리가 쉽도록 하였
습니다
12. . .
Datastore
Client Game Proxy
Rabbit MQ
Web API
모든 서버 간의 통신은 를 통해 이루어지며 서버 종류는 역할별로
나뉘어져 있고 이중화 되어 을 이룹니다
13. . ,
서버코드는 이 사용되며 네트웍 비동기 엔진은 /+ ++/ & 기반
데이터베이스로 & 을 사용합니다
23. 무정지 무점검을 어렵게 하는 것 패치
일반적인 패치 적용 방식
v2
v2
v2
새 버전의 서버로 업데이트 한 뒤
24. 무정지 무점검을 어렵게 하는 것 패치
일반적인 패치 적용방식
v2
v2
v2
서버를 다시 띄웁니다
25. 무정지 무점검을 어렵게 하는 것 패치
& 의 접근방법
v1
v1
v1
저희가 정지 없이 서버 패치를 한 방법은
26. 무정지 무점검을 어렵게 하는 것 패치
& -) ( ) 의 접근방법
v2
v2
v2
Site B
v1
v1
v1
새 버전으로 준비된 서버들을 미리 준비하고
27. 무정지 무점검을 어렵게 하는 것 & 패치
.) - ( ) 의 접근방법
v2
v2
v2
Site B
기존 서버로의 추가 유입을 막고 )-
새 버전 서버로 유입되도록 바꿉니다 -
28. 무정지 무점검을 어렵게 하는 것 패치
. 의 접근방법
v2
v2
v2
Site B
과 (.- . 을 계속하여
두 개의 ) . 를 뒤집는 & 방식으로
서비스의 중단 없이 패치를 적용합니다
29. 무정지 무점검을 어렵게 하는 것 패치
& - 의 접근방법
v2
v2
v2
Site A
v1
v1
v1
. 이 완료되면 모든 접속이 새 로 붙게 되며 기존
는 됩니다
30. 무정지 무점검을 어렵게 하는 것 패치
& & 의 접근방법 장점
v2
v2
v2
Site A
v1
v1
v1
• . - 마다 완전히 서버를 지우고 & - 을 통해
완전히 새로 서버를 만들기 때문에 항상 클린한 서버를
만들 수 있고 또 하드웨어의 이동도 쉽습니다
• 필요하면 이전 사이트로 롤백이 쉽습니다
• 문제가 있을 때 서비스에 지장없이 조사 가능합니다
31. 무정지 무점검을 어렵게 하는 것 패치
&& 을 가능하게 한 네 가지 기술
1. VM
2. 하위호환 API 시스템
3. 클린로컬
4. CD/CI 자동화
32. 무정지 무점검을 어렵게 하는 것 패치
기술 & )- ( . Site A
& 기반 곧 컨테이너 기반 이므로
새로운 사이트를 만들기가 용이하고
대기 자원 낭비를 줄일 수 있습니다
33. 무정지 무점검을 어렵게 하는 것 & 패치
기술 하위호환 & 시스템
로의 요청은 & 로 이루어지며
모든 요청 처리가 하위 호환 되도록
버전별 & 가 존재합니다 따라서
, .. - 중에도 서비스는 무정지로 동작합니
다
v2
v2
v2
Site B
v1
v1
v1
34. 무정지 무점검을 어렵게 하는 것 패치
기술 클린 로컬
호스트에 설정파일을 두지 않고 로그 파일은 자동으로 수집됩니다
35. 무정지 무점검을 어렵게 하는 것 패치
기술& () ( . 4
빌드가 끝나면 자동으로 플랫폼별 패키지가 만들어집니
다
배포는 원클릭으로 실행되며 ,/4 4
- / 업데이트 체크 테스트 완료 단계로
사람의 개입 없이 모두 자동으로 진행됩니다
37. 무정지 무점검을 어렵게 하는 것
설정변경 재시작 없이 설정값을 바꿀 수 없는
경우
설정 변경을 적용하기 위해 서버를 재시작해야합니다
38. 무정지 무점검을 어렵게 하는 것 설정변경
변경된 설정을 적용하려 서버를 재시작하는 경우
설정 파일이 변경되면 대분의 경우 서버는 설정 파일을 다시 읽기 위해 재시작을
합니다
39. 무정지 무점검을 어렵게 하는 것 설정변경
변경된 설정을 적용하려 서버를 재시작하는 경우
설정이 변할 경우 올바른 동작을 보장할 수 없어
서버를 리로드 하기 위해 서버를 먼저 종료합니다
40. 무정지 무점검을 어렵게 하는 것 설정변경
변경된 설정을 적용하려 서버를 재시작하는 경우
서버를 다시 시작하면서 새로운 설정을 읽고
로직을 새로 시작합니다
41. 무정지 무점검을 어렵게 하는 것 설정변경
설정변경 최악의 시나리오
일부 서버의 설정을 바꾸더라도 전체 서버를 재시작해야 하는 경우도 존재합
니다
대표적으로 다음과 같은 경우입니다
• 서버추가나 삭제로 서버 구성이 변할 경우
• 모든 서버가 같은 설정파일을 공유할 경우
52. 무정지 무점검을 어렵게 하는 것 상수변경
상수 변경이 점검 유발
만약 상수 값을 바꾸려고 하면 코드 변경과 재배포가 필요해집니다
따라서 점검을 요하는 경우가 많습니다
2
53. 무정지 무점검을 어렵게 하는 것 상수변경
& 소개
시스템은 서비스 외부에서 정지 없이 상수 값을 실시간으로 수정가능하게
합니다
2
54. 무정지 무점검을 어렵게 하는 것 상수변경
- . . , 소개
- 시스템은 - 시스템의 일부입니다
- 시스템은 작동중인 서비스에 등록된 함수를 실시간 & 로 호출하고 값
을 얻어올 수 있게 하고 이를 툴을 통해 할 수 있습니다 따라서 개발자 뿐만
아니라 프로듀서 누구든 쉽게 값을 바꾸거나 값을 얻어올 수 있습니다
get, set …
55. 무정지 무점검을 어렵게 하는 것 상수변경
& 소개
노출할 함수를 다음과 같이 코드에서 등록할 수 있습니다 모두 비동기로 호출
됩니다
query.RegisterCB([=](const Arg argv[], size_t argc, blz::shared_ptr<Query::Result> result)
{
QueryConnectionsList(argv, argc, result);
}, "web.connections.list", "Show connected clients", "query");
void WebServer::QueryConnectionsList(const Arg argv[], size_t argc, blz::shared_ptr<Query::Result> result)
{
static const char* s_columns[] =
{
"Id,40",
"Address,120",
};
result->Format("Web Connections", s_columns);
…
}
56. 무정지 무점검을 어렵게 하는 것 상수변경
& 소개
시스템은 & 시스템에 정의된 & 함수를 이용해 값을 설정합니다
Set min = 1
57. 무정지 무점검을 어렵게 하는 것 상수변경
& 소개
시스템으로 변경될 상수는
코드에서는 다음과 같이 등록하도록 구현되어 있습니다
Var::Setting<Time::Tick> m_varChatRequestTimeoutInterval;
Var::Setting<blz::string> m_varMessageOfTheDay;
Var::Setting<u32> m_varMaxHashSize;
Var::Setting<bool> m_varNewbie;
Var::ReadOnly<u8> m_level;
Var::Statistic<u64> m_varConnectCount;
, m_varMessageOfTheDay("Rpc.Chat.MessageOfTheDay", "", "Add MOTD for a game version: [ProgramId]
|[Version]|[Message]")
, m_varConnectCount("JournalClient.ConnectCount", 0)
78. & & 방법론 문화
• 누구나 코드를 수정할 수 있습니다.
• 코드는 Github의 Pull Request, Approval 을 통해 머지됩니다.
• Review & Approval 할 사람을 선택할 수 있습니다.
• 브랜치 전략은 Gitflow를 따르고 있습니다.
• 장애 사항은 모두에게 공유됩니다.
• 장애 대응할 사람이 Passive 하게 정해지지 않습니다. Active하게 담
당합니다. (누가 시키지 않고, 각자 자신이 할 수 있는/잘하는 일을
스스로 맡아서 합니다.)
• QA, 프로듀서, 엔지니어가 아닌 사람도 쉬운 방법을 통해 시스템을
수정할 수 있습니다.
• 실수를 피하거나 두려워 하지 않고 제대로 개선하는 쪽을 선호합
니다.
82. 요약
• CD/CI 자동화로 소프트웨어 변경의 어려움과 배포 리스크 제
거
• 클라우드를 이용해 인프라 자동화
• DevOps 문화로 분업화되었던 소프트웨어 생명주기를 압축 단순화.
• Flush, Var, Query System, Site Flipping 기술 개발
무정지, 무점검 서비스
89. 손정의
“아웃풋쪽이라 할 수 있는 클라우드 측도 매우 중요합니다. 클라우드
측에서는 GPU의 능력을 중심으로 지금부터 2030년까지는 단일 칩
당 연산 능력이 약 200배가 될 것으로 예상하고 있습니다.
물론 이는 원칩당 능력이지만, 그 칩의 수도 클라우드 측에 점점 늘어
가고, 게다가 클라우드 측의 AI칩과 인풋 측의 ARM칩이 매우 고속으
로 5G, 6G, 7G로 통신합니다. 그러면 AI의 진화라는 것은 무서운 기
세로, 지금부터 2차 곡선으로 뻗어 나간다는 것입니다.”
기사 출처 : http://www.hellodd.com/?md=news&mt=view&pid=65594
2018년 7월19일 소프트뱅크 월드2018 행사 발표 내용 중
90. 시대의 개발 모습은
• 메인보드, 모바일 기기에 CPU처럼 AI 칩이 탑재된다면?
• AI 툴킷이 대중화 되고 누구나 쉽게 AI 라이브러리를 쓸 수 있
다면?
• AI와 AI를 연결하는 새로운 네트워크 플랫폼이 생긴다면?
• AI를 이용한 정보공격&변조에 대비해야 한다면?
• …
91. 그리고 시대의
정보 서비스를 개발하고 운영하는 이들의 역할은 무엇일까?
• 더 하기 쉬워지는 DevOps
• 서비스 개발자의 Ops 부담/업무량 감소가 가져올 변화
• 인프라 호스팅의 개발, 운영 부담/업무량 증가가 가져올
변화
• AI 툴킷/모듈/서비스를 이용한 응용서비스 개발과 배포