iFunFactory Official Blog

아이펀팩토리가 지난 7월 27일부터 30일까지 나흘간 중국 상하이 뉴인터내셔널엑스포센터에서 열린 ‘차이나조이’에 다녀왔습니다!

차이나조이 2017는 올해로 15번째를 맞이한 아시아 최대 규모의 게임쇼로서 해마다 기록을 갱신하는 규모와 다양한 콘텐츠로 무장하여 세계적인 축제로 자리매김하고 있는 중국 게임 전시회입니다.

올해에도 역시 38도가 넘는 무더위에도 불구하고 수 많은 인파가 차이나조이 2017를 방문했는데요,
대륙의 더위와 세계적인 게이머들의 열정으로 뜨거웠던 그 현장을 아이펀팩토리가 전해 드리겠습니다!

▲차이나조이 행사장 입구

행사장 입구부터 세계적인 게임쇼라는 명성에 걸맞은 어마어마한 규모가 느껴지시나요?

볼거리가 많아 어디부터 갈지 고민하다가 먼저 B2B관으로 향합니다. 

B2B관에 들어가자마자 가장 눈에 들어온 것은 “한국의 대세 캐릭터”인 카카오 프렌즈의 라이언과 무지를 모형으로 내세운 카카오게임즈 부스였습니다. (사랑해요, 라이언) 카카오 게임즈는 카카오톡으로 상당히 많은 유저층을 보유하고 있어 게임 퍼블리싱에서도 상당한 영향력을 차지하고 있지요~

▲카카오 프렌즈 캐릭터를 내세운 카카오 게임즈 부스

차이나조이의 B2B관은 중국 최대 게임쇼답게 다양한 퍼블리셔와 개발사들이 활발하게 교류하는 모습입니다. 

▲중국 게임 개발사 및 퍼블리셔 부스

▲이벤트로 인해 줄이 엄청난 Talking Tom and Friends 부스

스마트 폰이 막 보급될 시기에 대표적으로 즐겼던 게임 Talking Tom 게임의 개발사 부스도 보입니다. (이 게임 아시는 분은 아재 인정!!!) 부스 이벤트 상품으로 증정되는 캐릭터 인형은 인기 폭발! 글쓴이는 줄이 너무 길어서 기다릴 엄두도 못내고 다음 부스로 이동합니다…ㅠㅠ 

올해는 사드 문제로 한중 관계가 예민한 상황에서 차이나조이가 진행이 되었습니다. 그로 인해 이번 차이나조이의 한국기업 공동관은 KOREA PAVILION이 아닌 KOCCA PAVILION으로 진행되었다고 하네요.  아무쪼록 차이나조이를 통해 한국 게임 개발사들에게 좋은 성과가 있기를 기원합니다.

▲한국콘텐츠진흥원 글로벌 게임센터 부스

특히, 이번 차이나조이에서는 중국 게임사에서 참신한 게임들을 많이 선보였는데요, 중국 게임산업의 성장과 잠재력을 다시 한번 실감할 수 있었습니다.

이렇게 B2B관의 여정을 마치고 이제 B2C관으로 이동합니다~!
일반인을 대상으로 하는 B2C관의 규모는 역시나…. 어마어마했습니다. 들어서는 순간부터 인해전술로 발 디딜 틈이 없는 차이나조이의 B2C관!

▲중국의 인구를 실감하게 하는 B2C 입구 현장

이번 차이나조이에서는 하드웨어 업체들이 한층 업그레이드된 제품을 선보이며 게임을 체험 및 시연할 수 있었습니다. 게임인이라면 누구나 알고 있는 CPU의 Intel과 그래픽 카드의 NVIDA가 대표적이었지요. 

▲Intel CPU를 탑재한 VR게임 시연과 메인 PC

▲Intel부스에서 진행된 “오버워치” 게임 대회

Geforce 그래픽 카드로 게임인들에게 유명한 NVIDIA 부스에서도 다양한 무대 행사 및 이벤트가 진행되었습니다.

▲NVIDIA 부스에서 진행된 게임 시연과 무대행사

▲GeForce 그래픽 카드를 탑재한 화려한 PC와 게임 그래픽

“대륙의 실수”라고 불리는 샤오미 부스도 발견! 국내에서는 샤오미 핸드폰, 미밴드 등으로 이미 잘 알려져 있죠. 이번 행사에서는 샤오미 미니 냉장고까지 선보였답니다. 샤오미 전자제품의 범위는 하루가 다르게 넓어지고 있네요. 

▲샤오미 부스와 샤오미 미니 냉장고

또한, 올해 차이나조이 2017은 전체적으로 게임 대회를 방불케 할 만큼 각 행사관마다 게임 대회를 라이브로 진행 한 곳이 많았습니다. 덕분에 글쓴이의 눈은 넘나 즐거웠지요 하핫
DOTA, 왕자영요, 리그 오브 레전드와 같이 게임인들에게 매우 익숙한 AOS 장르의 게임들을 5vs5로 현장에서 생생하게 라이브 중계를 했었는데요. 마치 스포츠 경기를 보는 것 처럼 그 인기가 대단했습니다. 

▲게임 대회를 온 것 같은 차이나조이의 부스별 게임 대회 현장

지난 15년간 중국 최대의 게임 전시회로 성장해 온 차이나조이를 통해 중국의 게임산업의 발전을 엿볼 수 있는 좋은 시간이었습니다. 한국과 마찬가지로 중국 또한 게임산업이 하나의 문화 콘텐츠로 자리잡은 것을 느낄 수 있었으며, 앞으로도 게임산업이 세계적으로 발전해가길 바랍니다. 올해 말 국내에서 개최되는 지스타 또한 작년보다 더욱 풍성한 볼거리로 세계적인 게임축제로 거듭나길 기대하며! 차이나조이의 하이라이트, 부스 모델 누나들의 사진을 마지막으로 이번 차이나조이 2017 방문기 포스팅을 마치도록 하겠습니다. 

이번 글에서는 게임 서버 모니터링에 도움이 되는 간단한 테크닉에 대해서 알아보도록 하겠다.

게임 개발 과정은 고난의 연속이다. 출시를 목표로 피곤에 쩔은 몸과 피폐해진 정신을 인내하지만, 클라이언트-서버 개발 완료로 끝날 것이라 생각되었던 그 고난들은 안타깝게도 서비스 출시 이후까지도 계속된다. 단순히 계속되는 정도가 아니라, 많은 이들이 주지하다시피 사실 출시부터가 본격적인 고난의 시작인 경우가 대부분이다.

출시가 끝이 아니라 여정의 시작이 되는 이유는 여러가지가 있는데, 먼저 서비스가 죽지 않고 안정적으로 동작하도록 해야되며, 유저 피드백에 따라 게임의 운영이나 업데이트를 신속하게 조정해야되는 것이 큰 이유 중 하나이다. 출시 후 첫 업데이트에 대해서 사전 계획을 가지고 준비하고 있던 경우라 할지라도, 많은 경우 급작스레 계획이 수정 되곤 한다.

여기서 말하는 유저 피드백은 공식 까페 등에서 유저들이 올리는 글이라기 보다는 KPI 라고 불리우는 객관적인 성능 지표를 의미한다. 까페의 글들은 정량화 되기 어렵고 개인 취향에 따른 것들도 많기 때문이다.

KPI 종류

KPI 는 관점에 따라 1) 재무적인 KPI, 2) 게임 콘텐츠 상의 KPI, 3) 서버 운영에 있어서의 KPI 로 구분할 수 있다. 재무적인 KPI 는 우리가 일반적으로 많이 들었던 수익(revenue), 유료 유저 비율 (paying user rate), 유저당 평균 수익 (ARPU), 유료 유저당 평균 수익 (ARPPU), 유저 생애 가치 (LTV) 등 돈과 직접적인 관련이 있는 중요한 것들이다. 이런 지표들은 회사의 사업담당자가 주로 관심을 갖는 지표이다.

재무적 KPI 가 이익 창출을 위한 궁극적인 KPI 라면, 게임 콘텐츠 상의 KPI 는 게임 안에서 벌어지고 있는 일들에 대한 KPI 로서 재무적 KPI 의 선행 지표격이라고 할 수 있다. 여기에는 일간 활동 사용자수 (DAU), 월간 활동 사용자수 (MAU), 잔존율 (retention rate) 등 게임에 공통적인 KPI 와 게임 콘텐츠 각 단계별 통과 비율 (funnel analysis), 게임내 경제의 인플레이션 흐름 (전체 재화 수준, 혹은 재화별 수준) 등 게임에 따라 다른 의미를 갖게 되는 KPI 로 나눌 수 있다. 이런 지표들은 주로 게임을 설계하는 기획자나 프로듀서가 관심있게 봐야되는 KPI 에 해당한다.

앞의 두 KPI 종류와 다르게 서버 운영에 있어서의 KPI 는 서비스의 안정성에 관련된 KPI 이다. 이 때문에 이 KPI 는 급격한 변화를 목표로 하기 보다는 주로 안정적인 수치 안에서의 관리를 목표로 한다. 여기에는 수용 가능 최대 동접, 클라이언트 패킷에 대한 반응시간, CPU 나 메모리 등의 리소스 사용량, DB 나 캐시와 같은 외부 시스템에 대한 요청 처리량 및 반응 시간 등이 포함된다. 이 KPI 들은 주로 서버 개발자가 주의깊게 살펴봐야되는 지표다.

KPI 모니터링

재무적인 KPI 나 게임 콘텐츠 KPI 에 대해서는 꽤 오래전부터 사람들이 많은 관심을 가져왔고, 많은 상용 솔루션이 나와있다. 그리고 존재하는 솔루션의 전형적인 형태는 클라이언트에 원격 로그용 SDK 를 심고, 로그인, 로그아웃, 결제 등과 같은 주요 이벤트에 대해서 SDK 를 통해서 기록을 남기는 방법이다. 클라이언트 SDK 를 통해서 수집된 내용은 분석 서버에서 통합되어 의미있는 KPI 로 생산되게 된다. 그런데 이런 솔루션들은 주로 일반화된 KPI 가공에 촛점이 맞춰져 있기 때문에 게임에 특화되어있는 지표는 여전히 게임에서 직접 생산해야되는 경우가 많다.

재미있는 것은 서버 관련 KPI 가 안정적인 서비스를 위해서 필수불가결함에도 이를 위한 솔루션들이 거의 존재하지 않는다는 점이다. 그 때문에 많은 경우 서버 개발자는 일반적인 ganglia 나 nagios 등 OS 수준의 모니터링 툴이나 프로세스 모니터링 툴, 혹은 DB 성능 툴들을 대신 사용하곤한다.

하지만, 이런 툴들이 따로따로 존재하는 경우 서비스의 현 상황을 한눈에 파악하기 힘들고, 그리고 앞의 게임 콘텐츠 KPI 에서 설명한 것처럼 일부 커스텀 기능의 추가 때문에 직접 개발해야되는 경우를 피할 수 없는 경우도 종종 있다.

이런 이유들 때문에 게임 콘텐츠 KPI 및 서버 운영 관련 KPI 를 모니터링 하는 툴을 직접 만들어야되는 경우 손쉽게 적용할 수 있는 구조로 다음과 같은 두 가지 방법을 생각할 수 있다.

방법1: 게임 서버에 내부 카운터를 유지하는 방법

이 방법은 게임내의 정보를 카운터로 노출하고 외부에서는 이를 단순히 그래프로 표시해주는 방법이다. 주로 후처리 없이 지속적으로 변동되는 휘발성 정보를 기반으로 하는 경우에 해당하며 다음과 같은 두 가지 layer 로 구성된다.

　　1. 기초 데이터 생성 layer: 게임 서버는 주기적으로 주요 지표들을 (이를 counter 라고 부르겠다) 특정 DB 에 저장하는 역할을 한다.
　　2. 표시 (presentation) layer: 앞에서 DB 에 저장된 데이터를 읽어들여 그래프로 표시해준다. 보통 dashboard 형태가 된다. Django 나 Flask 와 같은 framework 을 이용해 쉽게 구성할 수 있다.

기초 데이터 생성 layer 를 위해 게임 서버는 counter 라는 hash map 이나 dictionary 를 관리한다. 그리고 기초데이터에 해당되는 주요 숫자가 바뀌게 되면 이를 반영해준다. 예를 들어, 각 패킷 별로 처리 지연 시간을 보고 싶다면, counter 에 <패킷 이름, 패킷 개수, 처리 지연 시간의 누적값> 을 관리할 수 있을 것이다. 그리고 이를 통해서 각 패킷별 처리 시간의 평균과 표준 편차를 DB 에 저장할 수 있을 것이다.

이런 형태로 모니터링 될 수 있는 데이터는 CPU/메모리 등 OS 리소스 사용량, 앞에서 예를 든 것처럼 패킷 별 처리시간, 패킷 별 트래픽량, DB 요청 숫자 및 반응 시간 등이 있을 수 있다.

방법 2: 로그 분석을 이용한 방법

앞의 방법은 별도의 가공이 필요없는 데이터를 기반으로 하였으나, KPI 생성을 위해 가공이 필요한 데이터를 기반으로 하는 경우는 이를 로그로 저장하고 로그를 분석해야된다. 이 때는 다음과 같은 세 가지 계층 구조를 갖게 된다.

　　1.기초 데이터 생성 layer: 게임 서버는 주요 상황에 대해서 유실되지 않는 방법으로 로그를 남긴다. DB 에 저장하는 것도 가능하고 파일로 남기는 것도 가능하다. 로그인, 로그아웃, 결제 등을 로그로 남기는 것을 생각할 수 있겠다.
　　2. KPI 생성 layer: 기초 데이터를 읽어들여 KPI 를 생성하는 작업을 한다. 예를 들어 로그인 정보를 통해 평균 플레이 시간이나, 잔존율 등을 계산 할 수 있을 것이다. 매번 KPI 를 계산하는 것이 큰 부하를 줄 수 있으므로 한번 계산된 KPI 는 DB 에 저장하는 역할도 한다. 
　　3. 표시 (presentation) layer: 앞의 방법1 에서와 마찬가지로 생성된 KPI 를 표시해주는 dashboard 라고 생각하면 된다.

주의할 점은 위의 두 방법이 상호 배타적인 방법이 아니라 데이터의 성격상 후처리가 필요한지 여부에 따라 구분이 될 뿐이라는 점이다. 그리고 많은 경우 모니터링 툴은 두가지 데이터 형태 모두를 필요로 한다. 따라서 “표시 layer” 로 언급된 dashboard 는 두 방법에 의한 데이터를 모두 표시하는 것이 일반적이다.

아이펀팩토리 문대경 대표

무덥고 습한 날씨도 아이펀팩토리를 막을 수 없다!
아이펀팩토리가 유명 게임 개발사 KOG에서 진행된 아이펀팩토리 설명회를 위해
대프리카라고 불리우는 더위의 종결지, 대구에 다녀왔습니다.

KOG는 액션 RPG ‘엘소드’로 유명한 게임 개발사로서, 그 인지도에 걸맞게 쾌적한 근무환경 조성과 교육 프로그램 운영에 힘쓰고 있다고 해요. 그 일환으로 매 주 진행되는 사내 세미나에 저희 아이펀팩토리가 외부 강연자로 초청 받아 한 걸음에 다녀왔답니다! 

개성 넘치는 KOG 회사 전경과 아이펀팩토리의 기술 공유까지! 알찬 KOG 방문기 시작합니다. 

▲ 각 층마다 다른 컨셉으로 꾸며진 KOG의 입구! 센스 넘치죠?

▲ 직원들을 위한 휴식공간과 사내 도서관~ (울 회사도 머지않아..!! 불끈!)

사내 교육을 중시하는 기업인 만큼 업무에 관련된 전문 서적부터 핫한 베스트 셀러까지 다양한 종류의 책들이 빼곡히 채워져있습니다. 

▲ 휴식공간 한 편에는 아이펀팩토리 세미나 안내도 보이구요~

자, 이제 본격적으로 아이펀팩토리의 세미나를 들으러 가볼까요?

먼저 아이펀팩토리 세미나는 1부와 2부로 나뉘어서 진행 되었는데요,
첫 번째 순서에서는 아이펀팩토리의 박근환 테크니컬 디렉터께서 서버 개발 프레임워크, 아이펀 엔진에 대해 설명해 주셨습니다.

▲ 아이펀팩토리 박근환 테크니컬 디렉터의 아이펀 엔진 소개

“Great Technology for Great Games” 라는 아이펀팩토리의 철학과 함께 게임 개발의 기술적인 측면에서 허들을 낮추는 것을 목표로 하는 아이펀 엔진에 대한 기능과 특성들에 대해 자세히 설명해 주셨답니다.

다음으로는 아이펀팩토리의 문대경 CEO의 아이펀 디플로이에 대한 설명이 이어졌습니다.

▲ 아이펀팩토리 문대경 CEO의 아이펀 디플로이 소개

▲ 모든 순서가 끝나고 KOG 개발자 분들과의 질의응답 시간~ 폭풍 질문 환영이요! 

질의응답 시간을 통해 KOG 직원 분들과 개발에 대한 의견을 나눌 수 있는 유익한 시간이 되었답니다.

지역 개발사를 대상으로 진행된 첫  번째 아이펀팩토리 설명회가 이렇게 마무리 되었습니다! (짝짝짝~)
이번 설명회를 계기로 KOG와 아이펀팩토리가 함께 기술 공유의 시너지 효과를 이룰 수 있기를 기대해봅니다.
마지막으로, 저희 아이펀팩토리의 기술력에 관심을 갖고 좋은 자리를 마련해주신 대구 KOG 관계자 분들과 참석해 주신 개발자 분들께 감사의 말씀을 드리며 오늘의 포스팅은 여기서 이만 마치겠습니다.

감사합니다!

안녕하세요, 아이펀팩토리 사업팀입니다.

본격적인 여름을 앞두고 있는 6월의 마지막 주!
저희 아이펀팩토리는 사계절 온화한 날씨를 자랑하는 샌프란시스코에 다녀왔습니다.
그 이유는 바로 지난 6월 27일, 28일 이틀간 미국 샌프란시스코 웨스트필드에서 개최된 ‘PG Connects(Pocket gamer connects)’에 참가하기 위해서랍니다.

PG Connects는 모바일 게임업계에서 국제적으로 권위 있는 행사 중 하나로서 2014년을 시작으로 하여 영국, 미국, 인도, 핀란드 등 여러 유럽 국가에서 개최된 세계적인 모바일 게임 컨퍼런스입니다.
인디 개발자부터 글로벌 기업에 이르기까지 열정 가득한 게임인들이 한 자리에 모여 모바일 게임산업의 발전과 미래 경향에 대한 의견을 나누는 공유의 장이라고 할 수 있습니다.  

샌프란시스코에서 열린 이번 행사 역시, 다양한 주제의 강연과 부스 행사를 통해 모바일 게임 산업의 트렌드를 직접 확인하고 세계 게임인들과 함께 네트워킹 할 수 있는 값진 시간이었는데요, 
그 열기의 현장을 아이펀팩토리가 생.생.하.게 전해 드리겠습니다!

자, 행사장으로 함께 가보실까요?!

▲ 길고 긴 비행 끝에 도착한 행사장 입구! 반갑다 PG Connects!

▲ 짠! PG Connects 행사장 전경입니다.

▲ 부스 공간에서는 다양한 이벤트와 VR체험이 이루어지고 있었습니다.

▲ 행사장 한 켠에 자리한 자유로운 분위기의 비즈매칭 공간!

PG Connects에서는 세션과 전시 두 가지 모두 이루어지지만, 특히 비즈매칭을 통한 사업 미팅  또한 매우 활발하게 이루어지는 모습이었습니다. 오픈된 분위기에서 자유롭게 네트워킹이 이루어지는 점이 국내 게임행사와는 사뭇 다른 모습이었답니다. 

▲ 알찬 주제의 세션도 빠질 수 없죠! 모두가 집중하는 모습입니다. 

▲ 여기서 만나니 더 반가운 삼성! 인디 게임 베스트 작품을 삼성에서 후원한다고 하네요. 

이번 PG Connects를 통해 글로벌 모바일 게임 퍼블리싱 전략과 기회에 대해 살펴보고, 인디 개발자에게 필요한 창의력, 생산력, 지속 가능성에 이르기까지의 모든 과정을 함께 고민하고 공유할 수 있는 뜻깊은 시간이었습니다. 다음 PG Connects는 핀란드 헬싱키에서 열린다고 하니 관심 있으신 분들은 참고해주세요!
이상, 샌프란시스코에서 열린 PG Connects 현장이었습니다.  

웹/게임 서비스 구조의 변화

---

2000년대 초/중반에 웹 서비스나 게임 서비스를 만든다고 하면 영속적인 데이터 저장소 (데이터베이스나 SAN와 애 플리케이션 계층처럼 2계층이나 데이터 저장소 – 비지니스 로직 – 프리젠테이션의 3계층 형식으로 구성하는게 흔했다. 하지만 요즘은 여러 곳에서 경험하고 있다시피, 여러 개의 작은 서비스로 쪼개서 서비스끼리 통신하는 형태로 구성하 는 마이크로서비스로 만드는 경우가 많아졌으며, AWS 같은 클라우드 플랫폼들은 이런 구조를 권장한다.

즉, 유저와 서비스가 통신하는 것으로 끝나는게 아니라 유저와 서비스 1, 2, … 그리고 서비스 1과 서비스 2, … N 이 통 신하게 되는 것이다. 그런데 서버/클라이언트 구조의 모노리딕 서비스를 만들던 시절이랑 똑같은 문제는 여전히 남아 있다.

• 서비스에 접속한 유저/다른 서비스가 주장하는 유저/서비스가 맞는가 (authentication)
• 해당 유저/서비스가 요청한 기능을 실행해도 좋은가 (authorization)

많은 경우,

• 서비스에 접속한 유저 (이제부터 유저는 다른 서비스와 상호 교환가능한 단어로 생각하자) 가 그 유저가 맞는지를 인증 한다. 즉 ID/PW를 데이터베이스 비교하거나, Kerberos 나 LDAP 같은 외부 인증 서비스에 확인한다.
• 유저가 요청한 내용이 허용되는 내용인지를 유저의 종류나 역할 (role) 정보를 데이터베이스에서 확인하거나, 외 부 서비스 (역시나 Kerberos나 LDAP 류)에 묻는다.

같은 구현을 만든다. 이렇게 만든 서비스가 규모가 커가면 이 부분에서 병목이 생기리란 점은 쉽게 예측 가능하다. 우선 저런 인증 및 권한 시스템 자체에 부하가 걸린다. 비슷하게, 데이터베이스에 권한 시스템을 만든다면 데이터베이스 의 부하가 오를 것이다. 다음으로, 간과하기 쉬운 부분인데 지연 시간이 오르기 시작한다. 10G를 넘어 40G 이상이 대 세가 되어가는 데이터 센터 내의 통신이 빠르다곤 하지만 네트워크 요청의 응답 지연 시간은 여전히 분산 시스템 전체 의 성능에서 꽤 중요한 요소다. 마이크로 서비스 구조는 그 자체가 다른 시스템에 뭔가를 요청하는 시간이 들 수 밖에 없고, 이로 인한 지연 시간은 다음과 같은 경우 모두에서 올 수 있다 — 그리고 모두 성능에 악영향을 준다:

• 네트워크 사용이 짧은 시간에 몰리는 특성
• 하드웨어/OS 오버헤드 (스위치, 라우터, …, OS 의 네트워크 스택)
• 다른 서비스 (데이터베이스, Kerberos, …) 에 보낸 요청이 대기열에서 기다리는 시간
• 인증 서비스가 정말로 외부에 있는 경우 외부 인증 서비스까지 다녀오는 시간:

물론 이 중 많은 부분은 최적화하거나 개선할 수 있고, 적절한 캐시 계층은 많은 부하를 최소화하리라 생각된다. 그렇지만, 인증 / 권한 확인에 들어가는 부하와 지연 시간을 제거할 방법은 없을까?

인증토큰

---

많은 시스템들에서 토큰 기반의 인증/권한관리 시스템을 구현한다. 토큰에는 대략 다음과 같은 정보가 포함된다.

• 토큰 소유자가 누구인지
• 토큰 소유자가 무엇을 할 수 있는지 (혹은 그 중에 이 토큰으로 무엇을 할 수 있는지)
• 누가/언제 토큰을 만들었는지 (그리고 언제 만료되는지)

토큰을 전달받은 마이크로 서비스는 토큰의 정보를 이용해서,

• 인증 처리: 토큰 소유자가 누구인지가 토큰에 들어있다.
• 권한 확인: 토큰 소유자가 할 수 있는 일이 무엇인지 들어있다.

즉, 인증/권한 서비스에 접근하지 않고도 토큰을 들여다보는 것만으로 토큰을 받은 서비스가 알아서 할 수 있게 된다.

토큰을 어째서 신뢰해도 좋은가?

위에서 설명한 토큰의 내용 중에 의도적으로 포함하지 않은 부분이 있다. 인증 토큰이 유효하다는 걸 증명하기 위해서 메시지 인증 코드 (Message Authentication Code) 를 붙인다. 이 MAC 코드는 암호화를 하는 것은 아니고, MAC이 붙어있는 메시지가 변경 사항이 없다 는 점만 확인할 수 있다. 그래서 토큰의 신뢰성은 a. MAC 알고리즘을 믿을 수 있 는가? b. 토큰을 다른 유저가 접근할 수 없는가? 두 가지 요소가 결정짓는다.

우선 MAC 알고리즘 부분을 살펴보자. 크게 두 종류의 알고리즘이 있는데, 토큰을 어떤 주체와 주고 받을지에 따라서 선택할 수 있는 알고리즘이 다르다. 같은 운영 주체 안에서만 쓴다면 비밀 값 을 하나 정해서 안에서 공유할 수 있다. 이 경우에는 암호학적인 해시함수를 이용한 HMAC 을 이용한다. 보통 SHA1, SHA-2 (SHA-256, SHA-512, …) 나 심지 어 MD5 알고리즘을 이용한다. 해시 값 자체를 이용하는게 아니라 조금 다른 생성 방식을 쓰기 때문에 아직 MD5가 현역 인 거의 마지막 분야다. 그리고 몇 번의 해시 함수와 XOR 연산 외에는 없기 때문에 엄청나게 빠르다.

하지만 여러 운영 주체가 토큰을 교환하는 경우가 있다. 예를 들어서 Google 이 발급한 토큰을 사용해서 내 서비스에 접근하는데, Google 과 내 서비스가 특정 비밀 키를 합의하기는 어렵다. 그래서 HMAC 말고 공개적으로 확인할 수 있 는 다른 대안이 필요하다. 이 경우에는 전자 서명 알고리즘을 이용한다. 즉, 토큰 내용의 해시 값에 암호학적인 서명을 추가한다. (암호학적인 해싱 + RSA, DSA, ECDSA, 혹은 EdDSA 등의 공개키 알고리즘으로 서명) 다만 이 경우 서명과 서명 확인 모두 일반적인 해싱보다 훨씬 (대략 수십에서 수천배 정도)느리다.

알고리즘의 선택에 따라 HMAC 자체의 구조 혹은 공개키 알고리즘이 제공하는 보안성 만큼 믿을 수 있다. 만약 해당 토큰이 노출되면 토큰 자체의 기밀성은 없기 때문에 토큰을 탈취한 쪽이 인증/권한을 뺏어갈 수 있다.

사례 분석: OpenStack Keystone

IaaS 혹은 그 이상을 구축할 수 있게 해주는 오픈소스 구현체인 OpenStack 에는 Keystone 이라는 인증 및 권한 처리 를 담당하는 서비스가 있다. Ubuntu Linux 와 유사하게 매년 두 번 릴리즈하는데, 2012년의 두 개의 릴리즈 (Essex, Folsom) 동안에는 토큰을 사용하긴 하지만 토큰 자체를 항상 Keystone API에 확인받는 구조였다. 즉, 위에서 언급했 던 외부 서비스에 확인하는 방식으로 동작했다. 오픈스택 자체가 상호연관된 수많은 마이크로서비스로 만들어져있고, 하나의 API 서비스가 여러 개의 인스턴스가 분산 환경에서 동작하기에 Keystone API와 이 API가 사용하는 데이터베 이스 단의 부하가 꽤 컸다. 실제로 VM을 띄우는 노드가 수십개 수준일 때에도 상당한 양의 CPU 싸이클이 Keystone API와 데이터베이스에서 소진되는 걸 경험했다.

그래서 이 다음 릴리즈인 2013년의 Grizzly 버전에서는 공개키 인프라스트럭처 (PKI) 기반의 토큰 기능을 제공하기 시작했다. 예상할 수 있는 바처럼, Keystone 에서 토큰을 발급하고나면, Nova 나 Neutron 같은 다른 OpenStack 서비스에서는 공개키 서명을 확인해서 토큰을 검증하기 때문에 전반적인 API호출 수가 줄어든다.

개념 확장하기

---

인증 토큰은 단순하면서도 강력한 개념이다. 그래서 같은 개념을 사용해서 네트워크 기반 서비스에서 활용하는 일이 적지 않다.

좀 더 안전한 쿠키 / 클라이언트 세션

웹 사이트에서 보낸 쿠키를 클라이언트에서 변조해도 웹 사이트에서 이를 확인할 방법이 없다. 그래서 쿠키 데이터를 직렬화 (serialize) 할 때 MAC으로 HMAC 이나 전자 서명을 추가한다. 웹 서버에서 다시 쿠키를 받았을 때, MAC 내 용과 쿠키 내용을 비교하고, 이 내용에 대해서 변조된게 있는지 확인하는 방식으로 처리한다. 그리고 이런 기능을 이용 하면 분산 서버들이 공유 캐시나 공유 데이터베이스, 혹은 로드밸런서 수준의 sticky session 을 사용하지 않아도 세션 을 만들 수 있다.

실제로 여러 웹 프레임워크에서 이런 기능을 제공한다:

• Python itsdangerous: MAC과 만료 시한을 포함한 데이터를 만들 수 있게 도와주는 라이브러리. 해당 기능을 이 용해서 flask 의 세션을 구현한다.
• Rails: Rails의 세션 구현 역시 이런 기능을 이용한다.

이런 구현이 널리 쓰이는 것은 공유 세션 저장소를 만드는 것은 데이터베이스를 쓰거나 memcached 나 redis를 써도 해당 부분에 대해서 고가용성을 확보하면서 성능을 올리는게 그리 쉬운 일이 아니라서 그렇다.

메일에 보내는 URL에 특정 정보를 포함시키기

일부 이메일 리스트 등에서 탈퇴 처리를 위한 링크를 보낼 때가 있다. 해당 링크에는 서명 혹은 암호화를 하고 만료 시한을 지정한 정보를 지정하는 경우가 있다. 즉, 링크 내용의 일부를 디코딩하고, 암호화한 경우 복호화까지 하면,

• 유저가 하려는 행동을 알 수 있다. 예를 들어 이메일 리스트에서 탈퇴, 혹은 패스워드 재설정
• 유저에게 특정 시간까지만 이를 허용한다: 만료 시한을 데이터의 일부분으로 넣으면 기간이 지난 링크는 사용할 수 없다.
• 유저가 의도한 유저인지 알 수 있다. MAC을 포함해서 보내면 데이터를 변조한 경우 알 수 있다.

분산 서비스에 토큰을 적용해보자

---

인증 토큰을 이용하면,

• 공유 저장소의 사용을 줄이거나 (클라이언트 세션, 이메일 내의 링크 데이터)
• 서비스 요소간의 (불필요한) 통신을 줄이거나 (서비스 내 인증 토큰)
• 분산 처리를 쉽게 하거나 (특정 서버와 계속 통신하지 않아도 되는 인증 토큰)

하는 등의 이득을 볼 수 있다. 다만 인증 토큰의 무효화 처리 (revocation) 은 쉽지 않으니, 만료 처리나 블랙리스트 처 리를 구현해서 좀 더 편하게 분산 서비스를 만들어봅시다.

아이펀팩토리 김진욱 CTO

게임 서비스 시 서버 측면에서 성능상 문제가 되는 부분은 DB와 관련된 부분일 것이다. 과거에는 거의 모든 게임 데이터 관리 및 최종 동기화 등을 RDBMS에 의존하였기 때문에 쿼리 최적화는 게임 서버 최적화에서 매우 중요한 부분이었다. 최근에는 성능상의 이유로 캐시나 NoSQL 을 이용하는 경우가 많지만, 결제 관련 내용이나 사용자 간 거래 등 atomic 한 처리가 필요한 데이터들을 관리하는 데는 여전히 RDBMS를 사용하는 경우도 많다. 또한 이러한 결제나 거래 관련 데이터들은 통계 처리 등의 이유로 복잡한 쿼리의 대상이 되는 경우가 많기에 아직도 RDBMS 쿼리 튜닝은 게임 서버 성능 최적화에서 적지 않은 비중을 차지한다.

쿼리 최적화시에는 실행 시간을 기반으로 한 프로파일링이 크게 의미가 없다. 쿼리의 실행 시간에 가장 큰 영향을 주는 요소들은 RDBMS가 설치된 머신의 스펙과 쿼리의 대상이 되는 레코드의 수, 그리고 인덱스 접근/ 사용 방식과 중첩 쿼리의 실행 순서 등 쿼리 자체의 실행 과정이다. 이 중 머신의 스펙과 대상 레코드의 수는 최적화의 대상으로 보기는 어렵다. 따라서 최적화의 대상은 쿼리 실행 과정인데, 이는 단순히 실행 시간만을 측정해서는 알 수 없기 때문이다.

따라서 여러 RDBMS(Mysql, Mariadb, Oracle, Postgresql 등)에서는 어떠한 쿼리가 주어지면 해당 쿼리를 어떤 순서로 어떤 데이터를 활용하여 처리하겠다는, 쿼리 계획(query plan) 을 보여주는 기능을 제공한다.

Mariadb 에서는 쿼리 계획을 확인하는 명령어를 두 개 제공한다. EXPLAIN과 ANALYZE가 그것이다. EXPLAIN는 예상되는 실행 계획을 보여주고, ANALYZE는 쿼리를 실제 실행한 후 실행한 쿼리 계획을 보여준다. 언뜻 보기엔 ANALYZE가 더 유용해 보이지만, 쿼리 실행 시 디비에 부하가 가해질 수 있고, 레코드가 늘어나거나 하면 실행 계획 또한 바뀔 수 있으므로 실 서비스에서 실행시와 동일한 정보를 알려주지는 않는다. 두 명령어가 제공하는 쿼리 계획에 대한 정보는 같다.

Mariadb는 (10.0.1 이후부터) SELECT, UPDATE, DELETE 쿼리의 실행 계획을 조회하는 기능을 제공한다. UPDATE와 DELETE의 경우 각각 수정/삭제할 대상 레코드를 어떻게 찾느냐에 대한 계획을 보여주기에 실행 계획은 SELECT의 그것과 큰 차이가 없다.

EXPLAIN을 이용하여 쿼리 계획을 보는 방법은 간단하다. 실행할 쿼리 앞에 EXPLAIN을 붙여 주면 된다.

EXPLAIN을 실행하면 위와 같은 결과가 출력된다. JOIN이나 서브 쿼리가 포함되어 여러 단계의 처리가 필요한 경우, 각 단계별로 실행 계획을 보여준다.

쿼리 계획에는 다음 항목들이 표시된다.

● id : 대상 쿼리문에 JOIN이 포함되어 있을 때, 어떠한 순서로 테이블이 JOIN되는지를 나타내는 값이다.

● select_type : 각 단계를 실행할 때 어떤 종류의 SELECT가 실행되었는지를 나타낸다. 최적화 시에는 크게 중요하지는 않으나, 값이 DEPENDENT SUBQUERY, 혹은 DEPENDENT UNION 인 경우 의존성 등의 문제로 쿼리가 특정 순서로만 실행되어야 함을 뜻하므로 비효율적인 쿼리일 가능성이 있다.

● table : 해당 단계에서 접근하는 테이블의 이름이다. 실제 테이블, 혹은 임시 테이블일 수 있다.

● type : 테이블 내에서 접근이 필요한 레코드를 어떻게 찾았는지에 대한 정보이다.
인덱스 접근 여부 및 방식 등에 대한 내용도 포함하므로 쿼리 최적화 시 반드시 확인해야 할 값이다. 몇 가지 중요한 값에 대해서만 부연 설명하겠다.
　○ system : 테이블 내에 레코드가 1개 이하인 경우이다. 이 경우에는 레코드를 더 추가한 후 다시 쿼리 계획을 확인하는 것이 좋다.
　○ const, eq_ref : 해당 단계가 PK 나 유니크 인덱스 검색을 이용해 레코드에 접근함을 뜻한다. 일반적으로 가장 빠른 검색 방법이다.
　○ ref : 인덱스를 이용하여 동등 비교 연산을 통해 레코드에 접근함을 뜻한다. 위의 두 개만은 못하지만, 역시 매우 빠른 검색 방법이다.
　○ fulltext : 전문 인덱스(Fulltext Index) 를 이용하여 레코드에 접근함을 뜻한다. 전문 인덱스는 일반적인 비교 연산으로 접근이 어려운 경우에 주로 사용되므로 최적화하기 어려운 경우가 많다.
　○ range: 인덱스를 이용하여 값 비교 연산 ( , BETWEEN 등 )을 이용하여 레코드에 접근함을 뜻한다.
　○ index : index 전체를 스캔해야만 필요한 레코드에 접근할 수 있음을 뜻한다. 풀 테이블 스캔보다는 빠르지만, 인덱스가 매우 큰 경우 등에는 비효율적이다.
　○ ALL : 인덱스를 이용하여 필요한 레코드를 검색할 수 없어, 전체 테이블을 스캔해야만 함을 뜻한다. 당연히 테이블 내 레코드 수에 따라 실행 시간이 매우 길어지므로 적절한 인덱스 추가나 HINT 문 사용 등을 통해 최적화하는 것이 좋다.

● possible_keys : 레코드에 접근하기 위해 사용할 수 있는 키, 혹은 인덱스 목록을 보여준다. 실제로 사용된다는 의미가 아니므로 실제로 어떠한 키가 사용되었는지는 key 항목을 확인해야 한다.

● key, key_len : 레코드에 접근하기 위해 어떠한 index를 참조하는지, 인덱스 중 몇 바이트를 참조했는지에 대한 정보이다. key_len 은 둘 이상의 컬럼으로 구성된 인덱스를 참조했을 경우에만 의미가 있다.

● ref: 인덱스 검색 시 비교 연산 등에 사용되는 기준값을 보여준다. 최적화 시에는 큰 의미는 없다.

● rows : 필요한 레코드들을 추려내는 과정에서 몇 개의 레코드에 접근해야 하는지를 예측하여 보여준다.

● extra : 이상의 항목 외의 특이 사항들이 있다면 해당 내용을 표시해준다. 예를 들어, 접근해야 하는 컬럼이 모두 인덱스에 포함되어 있어 인덱스 검사만으로 필요한 값을 반환할 수 있다면 Using index 가 표시된다. 때에 따라 성능에 영향을 줄 수 있는 값들이 있으므로, 최적화 시에 이 컬럼이 비어 있지 않다면 확인할 것을 권한다.

한 가지 유의할 점은, MariaDB는 쿼리 계획을 만들 때 인덱스의 크기나 수, 레코드의 수 등을 같이 고려하므로 같은 쿼리라 하더라도 실행 계획 조회 시점에 따라 실행 계획이 달라질 수 있다. 그러므로 유효한 데이터를 얻기 위해서는 될 수 있는 한 실 서비스에서, 혹은 실 서비스와 최대한 비슷한 환경에서 실행 계획을 조회하는 것이 좋다.

지금까지 RDBMS 의 쿼리를 최적화할 때 쿼리 계획 조회가 왜 필요한지, 그리고 MariaDB 에서 쿼리 계획 조회 시 어떠한 정보들을 알 수 있는지에 대해 알아보았다. 쿼리 계획은 최적화에 필요한 모든 정보를 제공하지는 않지만 기본이 되는 정보를 제공해 주기에, 쿼리 최적화 시 꼭 한번은 쿼리 계획을 확인할 것을 권하고 싶다.

아이펀팩토리 아이펀 디플로이 테크니컬 디렉터 민영기

미세먼지가 물러간 5월의 화창한 봄날!
봄 타고 있는 아이펀팩토리 사업팀 여자 1호입니다.

오늘은 지난 5월 16일, 17일 이틀동안
삼성동 코엑스에서 개최된 Unite’17 Seoul 현장 소식을 들고 왔답니다!

특히 이번 행사에서는 아이펀팩토리 박근환TD가 강연자로 참가,
‘클라이언트 개발자, 서버 개발 시작하기’ 라는 핫한 주제로 열띤 강연이 진행 되었어요.
강연영상과 발표자료는 아래 링크를 통해 보실 수 있습니다!

☞ 유나이트 강연영상 보러가기

☞ 유나이트 발표자료 보러가기

자, 그럼 박근환TD 효과(?)로 한층 더 뜨거웠던 Unite’17 Seoul 현장! 저와 함께 가보실까요?!

▲ 평일 오전이었음에도 많은 분들이 오셨네요. 유니티 유나이트의 꾸준한 인기!

▲짠~! 유나이트 후원기업으로 참여한 저희 아이펀팩토리 로고가 네임택 랜야드에 뙇!

네임택을 목에 걸고 가장 먼저 박근환 TD의 ‘클라이언트 개발자, 서버 개발 시작하기’ 강연을 들으러 갑니다. 총총~

▲ 박근환 TD님의 강연을 듣기 위해 강연장 앞으로 길게 늘어선 줄이 엄청나죠? 인기폭발!

▲ 서버도 개발하고 싶은 클라이언트 개발자를 위한 세션입니다.

▲ 귀에 쏙쏙 들어오게 설명해주시는 아이펀팩토리 박근환 TD님!

▲ 서버 개발을 위해 서버 엔진이 필요한 이유!

▲ 강연장을 가득 메운 열기가 느껴지시나요?!

▲ 자리가 없어 서서 듣는 분들까지 초집중! 그만큼 유익하고 알찬 시간이었답니다.

강연을 듣고나서는 다양한 이벤트를 즐기러 부스를 돌아다닐 차례! 고고고~!

▲ 1층 그랜드볼룸 앞 부스에서는 여러 기업들의 제품 설명과 다양한 이벤트가 진행중이었어요

▲ 자유롭게 게임 체험하고 쉴 수도 있는 게임존! 이 곳이 바로 천국

▲ 2층 VR존에서는 요즘 대세인 VR을 맘껏 체험해 볼 수 있었답니다. 넘나 재미난 것!

이상으로 유익한 강연과 다양한 이벤트로 알찼던 유나이트 2017 현장이었습니다.
앞으로도 게임업계 종사자들 및 학생들이 지식을 공유하고 즐길 수 있는 유나이트가 되길 바랍니다!