텐센트 클라우드와 게임 인프라 아키텍처

 

 

 

 

2부 실시간 온라인 게임 인프라 아키텍처 – 하

 

 

1. 개요

 

지난 2부-상편에서, 세션형 게임을 구성하는 서비스 서버들은 어떤 것들이 있는지 알아보았습니다.

이번 2부-하편에서는 게임 서비스를 구성하는 인프라 아키텍처에 어떤 자원들과 요구사항들이 있는지 살펴보겠습니다.

 

 

2. 게임 서비스의 인프라 아키텍처 구성

 

앞서 구분한 서버들은, 게임을 이루는 서비스를 기준으로 서버들을 구별했습니다.

 

인프라 관점에서는 전체 서비스를 IT 자원들의 개념으로 세분화 합니다. 먼저, 각 서비스들을 처리하기 위해 필요한 자원의 종류와 양을 추정하고, 추정한 결과에 따라 시스템과 자원들을 도출합니다. 각 자원들을 어디에 얼마나 배치할 것인지, 그리고 서로 어떻게 연결 할 것인지, 어떤 구성이 가장 효율적이고 최선의 선택일 것인지, 구축의 용이성과, 운영의 편의성을 함께 고민합니다.

 

 

2.1 컴퓨팅 자원

 

CPU와 메모리 등의 컴퓨팅 자원들이 여기에 속합니다. 게임의 중요 상황들은 모두 컴퓨팅 자원들이 처리 합니다. 보다 많은 게이머를 지원하기 위해서는 고속의 연산 처리와, 많은 양의 네트워크 패킷을 처리할 수 있어야 합니다.

 

게임의 in-game을 처리하는 서버들은 여러 서버를 모아서 클러스터 형태로 구축하며, Game Server Fleet이라고 부르기도 합니다. Game Server Fleet은 다른 서비스 서버에 비해 부하가 크고 처리량이 많기 때문에, 실제 베어메탈 서버를 사용하거나 Dedicated Server 형태로 사용합니다. 다시 말해서 서버가상화 방식을 잘 사용하지 않고 물리서버 형태로 사용하는 경우가 많습니다.

 

클라우드 환경을 이용하여 게임 서비스를 구성하는 경우에도, Game Server Fleet들은 다른 인스턴스(특히 타 사 소유의 인스턴스)로부터 영향을 받지 않도록 Dedicated Server로 구성하는 사례가 많습니다.

 

반복적인 read-write가 많이 발생하거나, 서버들 사이에서 사용자 세션 정보를 자주 공유해야 한다면, cache 서버를 사용할 수 있습니다. 예를 들어, 랭킹 정보 변경은 매우 자주 발생하지만, 스토리지에 즉시 업데이트 해야 할 만큼 중요하지는 않습니다. 이런 랭킹정보의 특징과, 스토리지 서버의 낮은 I/O성능을 고려한다면 write cache 구조를 도입하는 것이 적당합니다. 새로운 랭킹 정보는 Message Queue에 저장해두고, 실제 스토리지에 저장하는 시점을 뒤로 미루어 마치 write cache처럼 구성하기도 합니다.

 

 

2.2 스토리지 자원

 

게임 데이터 저장을 위해서는 스토리지 자원도 필요합니다. 데이터가 얼마나 자주 발생하는지, 얼마나 자주 업데이트 해야 하는지에 따라 스토리지 종류와 스토리지 연결 방식이 달라집니다.

 

가장 빠른 스토리지 타입은 Block Storage 입니다. 또한 가장 빠른 스토리지 연결 방식부터 순서대로 나열하면 DAS, SAN(Fibre연결), iSCSI over Ethernet, NAS 가 될 것입니다. 최고의 IOPS 성능을 원한다면, M.2 NVMe SSD를 DAS형태로 메인보드에 장착하는 방법이 있습니다.

 

게임 데이터를 서로 다른 서버들이 서로 공유해야 한다면, 공유 저장소가 필요합니다.

 

인프라 자원을 사용해서 공유 저장소를 구현하는 방법으로는 NAS나 Object Storage를 사용합니다. 주로 정적인 데이터 공유에 사용합니다. (게임 데이터는 비즈니스 문서 파일과는 성격이 다르기 때문에, 데이터 공유가 필요할 때는 Application 레벨에서 데이터를 공유하는 방법을 더 자주 사용합니다. 예를 들어, DBMS를 사용하거나 NoSQL Database를 사용해서 게임 데이터를 공유하고, 그 하부 인프라로 Block Storage를 사용할 수 있습니다.)

 

데이터 안정성과 비즈니스 영속성 관점에서, 가급적이면 컴퓨팅 자원과 스토리지 자원을 물리적으로 분리된 공간에 배치하는 것이 좋습니다. 예를 들어, IDC의 5층에 있는 랙에 컴퓨팅 자원을 배치하고, 6층 랙에 스토리지 자원들을 분리 배치하는 방식입니다. 이렇게 분리한 자원은 SAN등을 이용하여 고속의 Fibre network로 연결합니다.

 

 

2.3 네트워크 자원

 

서버와 서버 사이, 서버와 스토리지 연결, 서버팜과 외부 인터넷을 연결하는 통신 설비와 장비들이 네트워크 자원에 속합니다. 물리적인 설비들과 케이블, L2, L3 레벨의 장비들이 있고, 관점에 따라서는 L4~L7 처리를 하는 서버나 장비들도 네트워크 자원의 일부로 포함하기도 합니다. 인터넷 ISP업체와 연결한 인터넷 라인도 네트워크 자원의 일부입니다.

 

게임 서비스를 안정적으로 운영하려면, 항상 전체 네트워크 상황을 모니터링 하고 관리해야 합니다. 관리용 네트워크는 서비스 네트워크와 분리하여 별도 네트워크로 구성하는 것이 좋습니다.

 

 

2.4 보안 자원

 

게임 서비스를 위한 보안 자원에는, 외부의 접근과 해킹시도를 차단하는 Firewall, DDoS공격을 방어하는 Anti-DDoS장비, 웹 애플리케이션을 보호하는 WAF, 침입을 탐지하고 차단하는 IDS/IPS가 있고, 내부 네트워크를 보호하기 위한 기타 접근제어 제품들이 있습니다.

 

Firewall은, IP주소나 Port를 기준으로 사전에 정의된 규칙과 비교를 통해 패킷을 통과시킬지, 또는 버릴지 결정합니다.

Anti-DDoS는, DDoS 공격을 감지하고 공격 패킷을 차단하여, 백엔드의 서비스 서버에게 DDoS 공격이 전달되지 않도록 보호 합니다.

WAF는 HTTP또는 HTTPS요청에 포함된 취약점 공격 유형들을 탐지하고 차단하여, 내부의 WEB/WAS 서버를 보호합니다.

On-Premis 환경에서는, 이러한 여러 보안 기능들을 하나의 장비로 통합한, UTM 제품들을 많이 사용하고 있습니다.

 

 

2.5 모니터링, 관리, 장애 대비

 

게임 서비스를 안정적이고 지속적으로 유지하기 위해서는 각 서비스들을 구성하고 있는 인프라 시스템의 여러 지표들을 모니터링 하고 관리할 수 있어야 합니다. 자원들의 사용량을 모니터링하고, 향후 자원 확장이 필요한 시점을 예측할 수 있어야 합니다. 주요 지표들의 변화가 위험 수준에 도달하거나 장애가 발생한 경우, 시스템에 의해 즉시 알람이 동작하고, 주요 관계자에게 알림이 발송되어야 합니다.

 

부득이 장애가 발생하더라도 데이터 손실을 최소화 하고 혼란을 방지 하려면, 사전에 장애 수준에 따른 대응계획을 수립 해 두어야 합니다. 먼저, 서비스의 중요도와 장애 유형에 따라 RPO(Recovery Point Objective)와 RTO(Recovery Time Objective)를 설정해야 합니다.

 

RPO(Recovery Point Objective)는 장애 발생 이전의 어느 시점으로 복구할 것인지 즉, ‘복구 목표 시점’을 뜻하며, 데이터 손실 범위와 관련이 있습니다. 대체로 RTO가 길면 데이터 손실이 늘어나며, RTO가 짧으면 비용이 증가합니다.

 

RTO(Recovery Time Objective)는 장애가 발생한 이후, ‘복구 목표 시간’을 뜻하며, 서비스 다운타임과 관련이 있습니다. RTO가 길면 서비스 다운타임이 길어지고, RTO가 짧으면 비용이 늘어납니다.

 

중요 시스템들은 이중화 구성을 하고, 아키텍처를 유연하게 유지하는 것이 좋습니다. 그래야만 평상시에는 시스템 확장과 유지보수가 편리하고, 장애 발생 시에는 장애 요소를 서비스로부터 분리하여 더 이상 장애가 전파되는 것을 막을 수 있습니다.

 

 

2.6 재해복구(Disaster Recovery) 시스템

 

중요한 게임 서비스를 하고 있다면, 재해복구(DR) 시스템 구축을 고려하는 것도 좋습니다. (DR센터 라고 부르기도 합니다.)
재해복구(DR) 시스템은, 외부의 위험(장애나 재해)으로부터 서비스의 연속성을 확보할 수 있는 방법중의 하나 입니다. 비상 상황에도 서비스를 유지할 수 있도록, 지리적으로 떨어진 곳에 예비 시스템을 구축합니다.

 

외부의 위험에는 여러 가지 형태가 있습니다. 예를 들어, ISP업체와의 Lastmile 구간에 장애가 발생할 수도 있고, 드물게는 해저 광케이블이 단절되는 일도 있으며, 극단적인 경우로 도시 전체에 정전이 발생할 수도 있습니다. 이런 외부 장애나 재해들은 그 범위가 국지적인 수준을 넘어서기 때문에, DR 시스템으로 대응해야 합니다.

 

재해복구 DR센터의 site 수준은 크게 세 가지로 구분할 수 있습니다. 장애 발생으로부터, 복구까지 얼마나 긴 시간을 감내할 수 있는지에 따라 Hot site, Warm site, Cold site로 구분합니다. Hot site는 RTO(Recovery Time Objective)가 거의 0에 가까운 수준이며, Warm site는 대략 1~3시간, Cold site는 18~24시간 이상인 경우를 말합니다.

 

재해복구 site를 어느 수준으로 구축할 것인지는, 소요 비용과 예상 피해금액의 정도에 따라 결정합니다. Hot Site가 재해 대응 수준은 가장 높지만, 데이터들을 DR센터에 실시간으로 복제해야 하는 어려움이 있고, 비용 또한 가장 많이 소요됩니다. DR은 구축 뿐만 아니라 운영에도 많은 비용이 소요되기 때문에, 우리는 지출 가능한 비용을 고려해서, DR센터를 어느 수준으로 구축할지 결정해야 합니다.

 

퍼블릭 클라우드를 활용하면 DR센터 구축과 운영이 보다 편리해집니다. 퍼블릭 클라우드가 가진 장점들은 다음과 같습니다.

 

지리적으로 떨어진 곳에 직접 방문하지 않아도, 원격지에서 DR 환경을 구축할 수 있습니다. 글로벌 지역에 DR을 구축하는 것도 가능합니다.

 

DR site 운영에 필요한 전산 인력 비용을 절감할 수 있습니다.

• 장애 발생 시 Auto Scaling으로 필요한 자원을 빠르게 확장 가능합니다.
• 평상시 DR 자원을 최적화 하고 비용을 최소화 할 수 있습니다.
• 멀티 클라우드를 활용한다면, DR의 수준을 더욱 높일 수 있습니다.

 

DR센터는 구축뿐만 아니라 운영이 중요합니다. 정기적으로 재해 상황을 시뮬레이션 하고 DR센터로의 전환이 제대로 수행 되는지 점검하는 활동을 수행해야 합니다. 점검 과정에서 발견한 문제점들은 지속적으로 개선해야 합니다.

 

 

 

 

수고하셨습니다. 2부-하편에서는 게임 서비스를 구성하는 인프라 아키텍처에 대해 알아보았습니다.

다음 3부에서는 텐센트 클라우드의 제품들 중에서, 게임 서비스 아키텍처에 활용 가능한 솔루션들을 살펴보겠습니다.

 

 

 

 

기술 블로그 내용 중에 궁금한 점이 있다면, 질문하기를 통해 문의 해 주세요.

 

 

 

 

 

참고링크

• • 이 콘텐츠는 저작권법에 의해 보호받는 저작물로 메가존클라우드에 저작권이 있습니다.
  • 이 콘텐츠는 사전동의 없이 2차 가공 및 영리 목적으로의 이용을 금합니다.