글로벌 게임 서비스를 운영은 단일 지역에서 서비스할 때와 달리, 서버 스케일과 지리적인 이슈가 있어 문제 해결이 어렵다. 이러한 문제를 해결하려면 멀티 클라우드를 사용해야 하는데, 그렇다면 이슈와 업무가 크게 증가한다.
크래프톤에서 엔지니어로 근무하고 있는 송민욱 개발자는 <뉴스테이트 모바일> 서비스를 준비하며 겪었던 일을 설명하며, 글로벌 서비스를 위한 클러스터 구성에 대한 조언을 남겼다. 강연은 ▲<뉴스테이트 모바일>이 멀티 클라우드, 멀티 쿠버네티스를 사용하는 이유는 무엇인가요? ▲Istio Multicluster Mesh를 사용해도 될까요? ▲인프라 동적 배포 파이프라인은 어떻게 만들어야 하나요? 세 주제에 초점을 맞추어 진행됐다.
강연자 : 송민욱
소속 : 크래프톤
발표자 소개
현재 크래프톤 / PUBG Studio에서 <뉴스테이트 모바일>의 DevOps 엔지니어 역할을 맡고 있으며, 인프라+서비스의 자동화된 배포와 운영에 관련된 업무를 수행하고 있습니다.
# 멀티 클라우드를 사용해야 하는 이유
먼저, <뉴스테이트 모바일>은 클라우드 벤더로 AWS와 Azue, TencentCloud 3개와 클라우드리전 17개를 사용하고 있다. 쿠버네티스 클러스터는 50개 정도를 사용하고, 대다수의 인프라를 쿠버네티스로 운영하고 있다.
그렇다면 왜 <뉴스테이트 모바일>은 멀티 클라우드와 멀티 쿠버네티스를 사용하게 됐을까?
<뉴스테이트 모바일>과 비슷한 게임으로는 <배틀그라운드>, <리그 오브 레전드>를 꼽을 수 있다. 공통적으로 '세션 기반 게임'이라는 특징을 가지고 있다. 세션 기반 게임은 인게임 플레이가 일어나는 세션 서버와 아웃게임 플레이를 하는 서버로 분리된 형태의 게임을 뜻한다. 주로 전략 시뮬레이션이나 FPS와 같은 실시간 응답을 하는 게임이 해당 구조를 취한다.
이런 장르의 게임은 인게임 플레이를 하는 세션 서버가 사용자와 가까워야 한다. 그래서 글로벌 서비스를 운영하는 게임은 세션 서버를 이용자와 가까이 두기 위해 여러 리전(지역) 서버를 두고, 매치메이킹이나 계정 정보, 친구 내역 등을 담당하는 아웃게임 서버는 한 곳에서 관리하기도 한다.
하지만, 어떤 클라우드를 사용하더라도 단일로는 모든 지역을 커버할 순 없다. 아래의 표를 보면 알 수 있다. 규모가 큰 리전도 각자 달라, 특정 지역에 사용자가 많은 게임이라면 그 지역에 많은 서버를 보유한 클라우드를 사용하는 것이 유리하다. 그렇기에 <뉴스테이트 모바일>은 멀티 클라우드를 사용하기로 결정했다.
어떤 클라우드를 사용해도 단일로는 모든 지역을 커버할 수 없다
멀티 클라우드를 사용하면 '클라우드 네이티브'와 '쿠버네티스 네이티브' 중 하나를 목표로 개발해야 한다. 클라우드 네이티브는 클라우드에서 제공하는 서비스를 최대한 활용하는 것을 뜻한다. 손이 가는 요소를 클라우드에 위임하고 게임 개발에 집중할 수 있으나, 특정 클라우드에 종속되거나 멀티 클라우드 환경에서 개발과 관리 난이도가 증가하는 문제가 있을 수 있다. 모든 클라우드가 '동일한' 기능을 제공하지 않기 때문이다.
따라서 <뉴스테이트 모바일>은 쿠버네티스 네이티브를 지향하기로 결정했다. 다양한 인프라 벤더를 지원하기에 높은 수준으로 워크로드를 컨트롤할 수 있기 때문이다.
쿠버네티스를 사용하면 싱글과 멀티 클러스터 중 하나를 선택해야 한다. 크래프톤은 멀티 클러스터 환경을 채택했다. 싱글 클러스터는 'Cluster Scope' 리소스에 문제 발생 시 전체 클러스터로 문제가 전파되고, 이슈 원인 판단이 어려우며 성능 한계가 존재하기 때문이다. 그렇기에 대형 클러스터를 적게 운영하기보단, 작은 클러스터를 많이 운영하는 방안을 선택했다.
# Istio Multicluster Mest 사용해도 될까요? "NO!"
두 번째 주제는 ServiceMest나 Istio 도입을 고려하고 있거나, 이미 도입한 멀티클러스터 기능에 대해 알아보고 있는 개발자들에게 도움이 될 수 있는 내용이다.
본격적인 설명에 앞서 서비스 메쉬와 모놀리틱, 마이크로서비스 아키텍처를 알아볼 필요가 있다. 우선 모놀리틱은 비즈니스 로직 구현이 어렵지만, 컴포넌트 간 메시지 교환을 쉽게 구현할 수 있다. 반면 마이크로서비스는 각 컴포넌트의 비즈니스 로직은 쉽게 구현할 수 있지만 마이크로서비스간 메시지 교환이 힘든 문제가 있다.
복잡한 마이크로서비스는 다양한 메시징 정책을 적용할 필요가 있는데, 이를 직접 구현하면 개발자들이 메시징 통제 기능을 개발하느라 비즈니스 로직 구현에 집중하지 못할 수 있다. 서비스 간 메시지를 통제하는 로직이 각 서비스 내부에 숨겨져 이슈 파악 또한 어려워진다.
그렇기에 크래프톤은 서비스 간 커뮤니케이션을 제어하고 관리하는데 특화된 '서비스 메쉬'라는 인프라 계층을 추가했다. 이를 위해 Istio라는 오픈소스 프로젝트를 사용했는데, 서비스 코드 수정 없이 트래픽 관리, 추척, 보안 기능을 실행할 수 있다.
하지만 결론적으로, 해당 방식으로 인프라를 구성하자 게임 규모가 커지면서 버지니아 리전의 아웃게임 클러스터에 계속해서 문제가 발생했다. 문제의 원인은 아웃게임의 Istio Control Plane이 주시하는 대상이 너무 많았던 것이었다.
이를 줄이려 해도 Istio가 Namespace 단위로만 필터링이 가능해 할 수 없었다. 결국 런칭 1주일 전 Istio Multicluster를 제거하고 전통적인 커뮤니케이션 방식으로 선회했다. 송민욱 개발자는 "아직 사용하지 않는 것이 좋다"라며 "네트워크 미들웨어는 특히 검증된 것과 기능을 사용해야 한다. 저희처럼 검증되지 않은 기능을 사용했다 실수하는 일이 없다면 좋겠다"라고 밝혔다.
# 계층화된 파이프라인의 장점
다음 주제는 인프라를 배포하고 관리하는 개발자에게 도움이 될 내용이다. 인프라를 배포할 때 정적으로 배포하는 것이 아닌, 동적으로 쉽게 생성하고 삭제하는 구조를 만드는 방법이다.
크래프톤은 처음에 클러스터를 정적으로 생성하고 관리했다. 그러다 보니 관리 방법이 Git이나 사내 위키에 분산되어 남아 있었고, 구전으로 전해지는 경우도 있었다. 이런 절차에서는 똑같이 클러스터를 만드는 업무를 수행해도 사람마다 결과가 달라지며, 히스토리를 모르면 인프라를 만들기 어려워진다.
그래서 인프라 배포 과정을 모두 Jenkins로 파이프라인화하는 작업을 시작했다. 구전으로 전해지거나 사람이 손으로 UI를 클릭하는 과정을 전부 API 호출로 바꾸는 데 시간이 걸렸지만, 인프라를 쉽게 관리하고 배포할 수 있게 되었다.
파이프라인에도 변화를 줬다. 먼저, 유기적인 파이프라인에도 분명 장단점이 있다. 스텝이 유기적으로 연결되어 있어, 새로운 요구사항이 들어와도 직접 절차를 우선 진행해 보고 코드로 그 절차를 유사하게 구현할 수 있다. 그러나 너무 유기적이기에 앞선 스텝이 달라졌을 때 '사이드 이펙트'를 예측하기 어렵다.
그렇기에 새로운 기능을 추가할 때마다 3~4명이 이를 리뷰해도 정확히 어떤 문제가 발생할지 예상하기 어렵다. 배포와 삭제 절차가 달라 역순으로 진행할 수 없다는 것도 단점이다.
유기적인 파이프라인의 예시. 장점도 있지만 단점도 있다
따라서 배포 과정을 개선했다. 인프라 요소를 명확한 레이어로 구분하고, 배포와 삭제를 대칭으로 만들어 계층화했다.
계층화된 파이프라인은 실제 구현된 파이프라인까지 단순하게 표현할 수 있다. 삭제를 배포의 반대로 구성해 새로운 기능을 추가할 때 작업자의 부담도 덜 수 있다. 이렇게 동적 배포 파이프라인을 유기적에서 계층적으로 개선해 버전 업그레이드나 테스트와 관련한 요구사항을 쉽게 받을 수 있게 되었다. 결과적으로는 개발 사이클이 빨라졌다.
Istio Multicluster Mest를 사용해 문제가 발생했던 내용에 대한 세부 내용과 계층화된 파이프라인 구성을 위한 자세한 이야기는 아래 동영상에서 확인할 수 있다.
디스이즈게임 댓글 ()
페이스북 댓글 ()
디스이즈게임
