무정지&무점검 서버 개발과 운영 사례

글로벌 게임플랫폼에서
무정지&무점검 서버 개발과 운영 사례
김태현(TAEHYUN KIM)
Sr. SW Engineer.(Blizzard Entertainment)

2017년 3월1일 AWS 장애 당시 화면
장애 당시 화면. 대부분의 서비스가 Closed 상태로 표시되어있다.

장애난 서비스들 (2017년 3월1일 AWS S3 장애)

손실규모
https://www.foxbusiness.com/markets/amazon-finds-the-cause-of-its-outage-a-typo
“54 of the internet's top 100 retailers saw website performance slow by 20% or
more. …”
“The AWS outage cost companies in the S&P 500 index $150 million, accordin
g to Cyence Inc., …

더 좋은 방법은 없을까…?

발표자 소개
• Blizzard 클래식팀에서 서버개발 (Sr. SW Engineer)
• 최근까지 Nexon America에서 Sr. Manager, DevOps
& Technology 담당
• NDC 2011,12,17년 우수발표 선정
• 1998년에 머신비전 프로그래머로 커리어 시작 후
• 여러 벤처기업과 NHN, SK컴즈 등에서 온라인 어플개
발, 게임서버개발 등 담당

Classic Team
Blizzard 의 어떤 게임들은 20년이 넘는 역사를 가지고 있습니다.
클래식팀의 목표는 이런 블리자드 게임들을 게임팬들이 현대적 컴퓨터 환경
에서 계속 즐길 수 있도록 하는 것입니다.

NCS (New Classic Server)
NCS
20년 이상된 게임을 현대적 환경에서 지속하기위한 기술적인 어려움을 극복하고자
NCS라고 불리는 새로운 서버스택을 개발, 새로운 기능 추가와 관리가 쉽도록 하였
습니다.

Server structure
Datastore
Client Game Proxy
Rabbit MQ
Web API
모든 서버 간의 통신은 RabbitMQ 를 통해 이루어지며 서버 종류는 역할별로
나뉘어져 있고 이중화 되어 Farm을 이룹니다.

Software Stack
서버코드는 C++ 이 사용되며, 네트웍/비동기 엔진은 libuv & Rabbit MQ 기반,
데이터베이스로 MySQL 을 사용합니다.

Source Code Management
SCM은 Git과 Github 을 사용합니다.

CD/CI
CD/CI 는 Jenkins로 organize 되며, 인프라는 Openstack 위에서 VM 으로 구현
되어 있습니다. 최근 Docker 로 containerize 중입니다.

Monitoring
모니터링은 Guardian 이라는 자체 제작 시스템을 사용합니다. Guardian 은
web 기반의 모니터링/인벤토리 툴이며 서버와 직접 통신이 가능한 특징이 있
습니다.

Telemetry
데이터 분석을 위한 Telemetry 는 ELK stack 을 활용합니다.

여기까지 사용 기술 소개
무정지&무장애를 어렵게 하는 다섯 가지 문제와 해결방법
소개로

무정지&무점검을 어렵게 하는 것들? 첫번째
버전
버전

무정지&무점검을 어렵게 하는 것 I
1. 패치
• 바이너리 교체를 해야 해서
• 로직 재시작을 해야해서
• 새 데이터 로드를 해야해서
• 하위 호환이 안되어서
V2v1
서버에 패치를 적용하기 위해 서버를 내리는 경우가 많습니다.

무정지&무점검을 어렵게 하는 것 I - 패치
일반적인 패치 적용 방식
v1
v1
v1
점검이 시작되면

무정지&무점검을 어렵게 하는 것 I – 패치
모든 서버를 중지하고

v2
v2
v2
새 버전의 서버로 업데이트 한 뒤

일반적인 패치 적용방식
v2
v2
v2
서버를 다시 띄웁니다.

Classic Team 의 접근방법
v1
v1
v1
저희가 정지 없이 서버 패치를 한 방법은

New Classic Team 의 접근방법
v2
v2
v2
Site B
v1
v1
v1
새 버전으로 준비된 서버들을(Site B) 미리 준비하고

v2
v2
v2
Site B
기존 서버로의 추가 유입을 막고(Drain)
새 버전 서버로 유입되도록 바꿉니다(Redirect).

v2
v2
v2
Site B
Draining 과 Redirecting을 계속하여
두 개의 Site 를 뒤집는(Flip) 방식으로
서비스의 중단 없이 패치를 적용합니다.

v2
v2
v2
Site A
v1
v1
v1
Flip 이 완료되면 모든 접속이 새 Site 로 붙게 되며 기존
Site는 deactivate 됩니다.

Classic Team 의 접근방법 - 장점
v2
v2
v2
Site A
v1
v1
v1
• Deploy 마다 완전히 서버를 지우고 terraform 을 통해 완
전히 새로 서버를 만들기 때문에 항상 클린한 서버를 만
들 수 있고 또 하드웨어의 이동도 쉽습니다.
• 필요하면 이전 사이트로 롤백이 쉽습니다.
• 문제가 있을 때 서비스에 지장없이 조사 가능합니다.

Flipping 을 가능하게 한 네 가지 기술
1. VM
2. 하위호환 API 시스템
3. 클린로컬
4. CD/CI 자동화

기술1 - VM (container) Site A
VM 기반 (곧 컨테이너 기반)이므로
새로운 사이트를 만들기가 용이하고
대기 자원 낭비를 줄일 수 있습니다.

기술2 - 하위호환 API 시스템
Server로의 요청은 API 로 이루어지며,
모든 요청 처리가 하위 호환 되도록
버전별 API 가 존재합니다. 따라서
Flipping중에도 서비스는 무정지로 동작합니다.
v2
v2
v2
Site B
v1
v1
v1

기술3 - 클린 로컬
호스트에 설정파일을 두지 않고 로그 파일은 자동으로 수집됩니다.

기술4 - CD/CI Automation
빌드가 끝나면 자동으로 플랫폼별 패키지가 만들어집니
다.
배포는 원클릭으로 실행되며 (Jenkins)
Site 업데이트, 체크, Flip, 테스트, 완료 단계로
사람의 개입 없이 모두 자동으로 진행됩니다.

무정지&무점검을 어렵게 하는 것 II
설정을...

무정지&무점검을 어렵게 하는 것 II
2. 설정변경 - 재시작 없이 설정값을 바꿀 수 없는
경우
설정 변경을 적용하기 위해 서버를 재시작해야합니다.

무정지&무점검을 어렵게 하는 것 II – 설정변경
변경된 설정을 적용하려 서버를 재시작하는 경우
설정 파일이 변경되면 대분의 경우 서버는 설정 파일을 다시 읽기 위해 재시작을
합니다.

무정지&무점검을 어렵게 하는 것 II -설정변경
설정이 변할 경우 올바른 동작을 보장할 수 없어
서버를 리로드 하기 위해 서버를 먼저 종료합니다.

무정지&무점검을 어렵게 하는 것 II - 설정변경
서버를 다시 시작하면서 새로운 설정을 읽고
로직을 새로 시작합니다.

무정지&무점검을 어렵게 하는 것 II – 설정변경
설정변경 – 최악의 시나리오
일부 서버의 설정을 바꾸더라도, 전체 서버를 재시작해야 하는 경우도 존재합
니다.
대표적으로 다음과 같은 경우입니다.
• 서버추가나 삭제로 서버 구성이 변할 경우
• 모든 서버가 같은 설정파일을 공유할 경우

Flush system 소개
설정파일이 로컬에 존재하지 않습니다.

Flush system 소개
설정이 변경된 후 Flush 명령을 서버에 보내면
Flush
Flush
Flush

Flush system 소개
서버는 Config 서버에 있는 config 파일들을 읽어오고
config.server

Flush system 소개
Flush 코드를 실행하여 설정 내용을 업데이트 한 뒤 바뀐 설정으로 동작합니다.
이를 가능하게 하기 위해
설정은 Google protobuf 프로토콜을
이용해서 동작 관련 자료구조를을
정의했습니다.

Flush system 소개
특정 설정 파일의 선택적 Flush도 가능합니다.

Flush system 소개
특정 서버만 선택적 업데이트도 역시 가능합니다.

Flush system 소개
//------------------------------------------------------------------------------
Void MatchMakerUtilImpl::FlushSeason(const blz::function<void(bool)>& callback)
{
m_loader.LoadConfigAsync([=](bool res)
{
if (res)
{
auto config = m_loader.GetConfig<classic::protocol::config::Seasons>("matchmaker_seasons.pb");
if (config)
{
m_seasonsByProgramId.clear();
for (auto& s : config->season())
{
auto& map = m_seasonsByProgramId[programId];
auto& info = map[s.id()];
auto& bucketInfo = s.bucket_info();
. . .
}
Flush 코드의 예

Flush system 소개
설정의 예
#Season 1
season {
id: 1
start_time_epoch: 1501607149
igr_multi: 1
}
#Season 2
season {
id: 2
start_time_epoch: 1532467800
igr_multi: 2
bucket_info {
bucket : 0
cut_off : 0
award_product_id : 12345
}
bucket_info {
bucket : 1
cut_off : 100
award_product_id : 23456
}

무정지&무점검을 어렵게 하는 것 III
사라진 전 개발자. 계획안된 변경.
그 값을 바꿔야 한다.
바꿨어야 했어
…

무정지&무점검을 어렵게 하는 것 III
3. 상수 변경
코드를 짜다보면 반드시 상수가 만들어집니다.

무정지&무점검을 어렵게 하는 것 III – 상수변경
상수 변경이 점검 유발
만약 상수 값을 바꾸려고 하면 코드 변경과 재배포가 필요해집니다.
따라서 점검을 요하는 경우가 많습니다.
2

무정지&무점검을 어렵게 하는 것 III - 상수변경
Var system 소개
Var 시스템은 서비스 외부에서 정지 없이 상수 값을 실시간으로 수정가능하게
합니다.
2

Var system 소개
Var 시스템은 Query 시스템의 일부입니다.
Query 시스템은 작동중인 서비스에 등록된 함수를 실시간 RPC로 호출하고 값
을 얻어올 수 있게 하고, 이를 툴을 통해 할 수 있습니다. 따라서 개발자 뿐만
아니라 QA, 프로듀서 누구든 쉽게 값을 바꾸거나 값을 얻어올 수 있습니다.
get, set …

Query system 소개
노출할 함수를 다음과 같이 코드에서 등록할 수 있습니다. 모두 비동기로 호출
됩니다.
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);
…
}

Var system 소개
Var 시스템은 Query 시스템에 정의된 set 함수를 이용해 값을 설정합니다.
Set min = 1

Var system 소개
Var시스템으로 변경될 상수는
코드에서는 다음과 같이 등록하도록 구현되어 있습니다.
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)

무정지&무점검을 어렵게 하는 것 IV

무정지&무점검을 어렵게 하는 것 IV - 스케일링
4. 스케일링
서비스 규모의 변경에 따라 서버의 규모도 증가합니다.
( 예: Scale out)

스케일링으로 인한 점검
만약 서버 구성과 관련한 설정이 존재할 경우

무정지&무점검을 어렵게 하는 것 IV
서버 구성을 업데이트 하기 위해 설정이 바뀌고 서버의 점검을 유발할 수 있습
니다.

서버 구성을 업데이트 하기 위해 설정이 바뀌고 서버의 점검을 유발할 수 있습
니다.

무정지&무점검을 어렵게 하는 것 IV – 스케일링
서버가 늘어날 경우, 서버 간의 새로운 연결이 필요한 경우도 있습니다.
그럴 때 새로운 접속을 받아들이기 위해 서버를 재시작 하기도 합니다.

설정에 서버구성을 두지 않음
NCS에는 서버 구성 관련 설정이 기본적으로 존재하지 않고, 만에하나 있더라
도 Flush system으로 서버 재시작 없이 수정가능합니다.

MQ를 통한 서버 통신으로 직접연결 설정 불필요
NCS는 서버간의 통신을 MQ를 통하도록 하여 서버간 직접 통신이 필요 없기
때문에
스케일링이 되더라도 서버를 재시작 할 필요가 없도록 되어있습니다.

무정지&무점검을 어렵게 하는 것 V

무정지&무점검을 어렵게 하는 것 V
5. 장애
장애는 피할 수 없습니다. 장애에 견디고 복구 가능한지가 중요합니다.

무정지&무점검을 어렵게 하는 것 V – 장애
Health Check 구현
모든 서비스는 Health Check 프로토콜을 구현하고 있습니다.
Health Check이 실패할 경우를 모니터링하여 장애를 감지합니다.

무정지&무점검을 어렵게 하는 것 V - 장애
Health Check 코드 예
auto healthCheck = [&](blz::string& meta)
{
return rabbitMq.IsReady() && s.IsReady() && igrSettings.IgrEnabled();
};

Pool에서 이중화
그리고 SPOF를 피하기 위해 동종 서비스들은 개념적으로 Pool 에 담겨 있습니다.
장애 감지시 Pool 에서 제거됩니다.
제거되더라도 풀의 다른 서비스들은 계속 서비스가 가능합니다.

서버 종류별 Pool
그리고 서비스 종류별로 Pool 을 두고 있습니다.

원인 모를 장애시의 대처 방식
만약 예상치 못한 이유로 서비스 전체나 상당부분이 불안정한 경우가 발생한
다면

무정지&무점검을 어렵게 하는 것 V - 장애
원인 모를 장애시의 대처 방식
이 때는 troubleshoot 을 해서 고치는데 시간을 쓰기 보다는
서버를 다시 배포합니다. 배포를 하면 Site 가 교체(Flip) 되도록 되어 있습니다.
Deactivated
Activated

무정지&무점검을 위한 Classic Team의 DevOps

DevOps의 다양한 형태
조직으로서의 DevOps
개발 방법론의
DevOps
문화로서의 DevOps

Classic Team 의 DevOps 소개
문화로서의 DevOps

Classic Team DevOps – 역할
SDE
LiveOps
SDE
SRE
LiveOps
SDE
SRE
SDE
SRE
CD/CI
개발 모니터링
조사수정
엔지니어가 모든 역할을 다 합니다.

Classic Team DevOps – 방법론 & 문화
• 누구나 코드를 수정할 수 있습니다.
• 코드는 Github의 Pull Request, Approval 을 통해 머지됩니다.
• Review & Approval 할 사람을 선택할 수 있습니다.
• 브랜치 전략은 Gitflow를 따르고 있습니다.
• 장애 사항은 모두에게 공유됩니다.
• 장애 대응할 사람이 Passive 하게 정해지지 않습니다. Active하게
담당합니다. (누가 시키지 않고, 각자 자신이 할 수 있는/잘하는
일을 스스로 맡아서 합니다.)
• QA, 프로듀서, 엔지니어가 아닌 사람도 쉬운 방법을 통해 시스템
을 수정할 수 있습니다.
• 실수를 피하거나 두려워 하지 않고 제대로 개선하는 쪽을 선호합
니다.

배포 파이프라인
빌드
Dev
배포
Site
flip
Dev
Test
Prod
배포
Low
pop
Site
flip
Live
Test
High
pop
site
flip

테스트 서버 운영 전략
• No test build. 모든 빌드는 라이브를 염두한다.
• 테섭과 라이브의 배포 방식이 같다.
• 테섭의 운영 방식도 라이브와 같다.
• 여러개의 테스트 환경을 갖고 있고 필요시 생성한다.
• Dev, PTR, Prod 로 나뉜다.

Classic 팀이 무정지&무점검을 위해 접근한 방법
은
무정지, 무점검 서비스

요약
• CD/CI 자동화로 소프트웨어 변경의 어려움과 배포 리스크
제거
• 클라우드를 이용해 인프라 자동화
• DevOps 문화로 분업화되었던 소프트웨어 생명주기를 압축 단순
화.
• Flush, Var, Query System, Site Flipping 기술 개발
무정지, 무점검 서비스

DevOps의 미래에 대해 생각해 볼 것 들

Serverless
개발자
사용자
개발자는 서비스할 코드를 serverless 에 등록하고
사용자는 등록된 코드를 리모트로 실행합니다.
Serverless

마치 소프트웨어와 하드웨어가 분리되었듯

Serverless로 하나의 거대한 지구 컴퓨터와
소프트웨어가 분리

서버리스로 가면서 서버 장애에 대한 부담도 클라
우드로 넘어가고 있음
개발자 부담 IDC 호스팅 부
담
클라우드 호스팅 부담

그리고 AI
이미지출처 : Microsoft

손정의
“아웃풋쪽이라 할 수 있는 클라우드 측도 매우 중요합니다. 클라우드
측에서는 GPU의 능력을 중심으로 지금부터 2030년까지는 단일 칩
당 연산 능력이 약 200배가 될 것으로 예상하고 있습니다.
물론 이는 원칩당 능력이지만, 그 칩의 수도 클라우드 측에 점점 늘어
가고, 게다가 클라우드 측의 AI칩과 인풋 측의 ARM칩이 매우 고속으
로 5G, 6G, 7G로 통신합니다. 그러면 AI의 진화라는 것은 무서운 기
세로, 지금부터 2차 곡선으로 뻗어 나간다는 것입니다.”
기사 출처 : http://www.hellodd.com/?md=news&mt=view&pid=65594
2018년 7월19일 소프트뱅크 월드2018 행사 발표 내용 중

AI 시대의 Software 개발 모습은?
• 메인보드, 모바일 기기에 CPU처럼 AI 칩이 탑재된다면?
• AI 툴킷이 대중화 되고 누구나 쉽게 AI 라이브러리를 쓸 수 있
다면?
• AI와 AI를 연결하는 새로운 네트워크 플랫폼이 생긴다면?
• AI를 이용한 정보공격&변조에 대비해야 한다면?
• …

Serverless 그리고 AI 시대의 DevOps
정보 서비스를 개발하고 운영하는 이들의 역할은 무엇일까?
• 더 하기 쉬워지는 DevOps
• 서비스 개발자의 Ops 부담/업무량 감소가 가져올 변화
• 인프라 호스팅의 개발, 운영 부담/업무량 증가가 가져올
변화
• AI 툴킷/모듈/서비스를 이용한 응용서비스 개발과 배포

Serverless & AI 라는 새로운 세상

감사합니다.
연락 : thkim.cdecl@gmail.com

무정지&무점검 서버 개발과 운영 사례

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 무정지&무점검 서버 개발과 운영 사례

Similar a 무정지&무점검 서버 개발과 운영 사례 (20)

Último

Último (8)

무정지&무점검 서버 개발과 운영 사례

Notas del editor