저장 프로시저 중심 아키텍처에서 벗어나 클라우드 데이터베이스 적응하기

오랜 기간동안 관계형 데이터베이스는 여러 애플리케이션의 데이터베이스로 사용되어 왔습니다. 온라인 게임의 경우에서도 마찬가지로 많은 게임의 주요 데이터베이스로 관계형 데이터베이스가 사용됐습니다. 특히나 한국의 MMORPG 개발 커뮤니티에서는 Microsoft SQL Server와 같은 상용 관계형 데이터베이스를 사용하였고 저장 프로시저(Stored Procedure)를 사용하여 데이터베이스 내에 로직의 일부를 구현하는 방식을 많이 사용해 오고 있습니다.

하지만 이러한 개발 패턴은 최근의 게임 개발 및 운영 환경이 변화하면서 여러 가지 도전을 받고 있습니다. 최근의 온라인, 모바일 게임들은 게임의 볼륨이 확장되면서 개발 및 운영해야할 컴포넌트들이 많이 늘어나고 글로벌로의 서비스를 국내 개발사 또는 국내 퍼블리셔가 직접 서비스를 하는 경우가 많아지게 되면서 다양한 글로벌 리전을 활용할 수 있는 AWS 와 같은 클라우드를 활용하는 경우가 상당 수를 차지하고 있습니다. 이러한 클라우드 중심의 게임 운영 환경에서는 오랜 역사를 가지는 상용 데이터베이스의 경우 클라우드에 최적화되기 어려운 부분이 있기 때문에 데이터베이스 역시 클라우드 최적화된 솔루션을 통해서 최적의 효과를 낼 수 있도록 변경을 해주는 것이 좋겠습니다.

이번 블로그 포스팅에서는 기존에 많이 사용하던 상용 데이터베이스와 저장 프로시저를 통한 게임 데이터베이스 구현이 어떤 형태로 클라우드 환경에 최적화되어 있지 않은지를 구체적으로 살펴보고, 클라우드를 활용한 서비스 환경에서 그러한 문제들을 해결할 수 있는 솔루션은 어떤 것들이 있는지 간략히 살펴보도록 하겠습니다.

상용 데이터베이스의 단점

과거 온프레미스의 환경에서 RDBMS 를 운영하는 경우는 초기 높은 투자비용을 들여 RAID 구성이 되어있는 SAN (Storage Area Network) 환경을 구축하고, 이러한 환경에서 최적의 성능을 발휘하도록 구성이 되어 있는 상용 데이터베이스를 많이 사용하였습니다. 하지만 클라우드 환경에 넘어오면서 모든 인프라스트럭쳐의 구성 요소가 분산 환경에서 구성되고, 쉽게 인스턴스 타입이 변경 가능하고, 다중 가용 영역과 같은 기존에 쉽게 고려하지 못하는 구성이 가능해지면서 일반적인 상용 데이터베이스를 클라우드 환경에 최적화된 형태대로 배포하기 어려워졌습니다. 그러면서 점점 상용 데이터베이스가 가지는 다음과 같은 단점들이 드러나게 되었습니다. 각각 독립적인 단점이라고 하기에는 서로 엮이는 문제들이긴 하지만, 관점에 따라 문제의 차이가 있을 것으로 생각되기에 세부적으로 나눠봤습니다.

• 비용 : 상용 데이터베이스의 경우, OS 및 데이터베이스의 라이센스 비용이 높으며, 특히 고급 기능이 추가된 상위 티어를 사용할 경우 라이센스 비용이 많이 들어가게 됩니다. 특히 월드를 여러 개 가지고 있는 MMORPG의 경우 데이터베이스 비용 문제로 인해 데이터베이스 장애 대응을 비동기 복제나 심지어 백업만을 사용하고, 이로 인해 장애 시 데이터 유실을 감수하고 서비스하는 경우도 많습니다.
• 복잡성 : 다양한 기능을 가지고 있고 고성능 하드웨어 환경에서 사용되는 만큼 성능을 최대한 내기 위해서는 그만큼 최적화된 상태로 설정하고 구성을 하기 위해 복잡한 작업이 필요하고 그만큼 전문적인 지식을 필요로 하게됩니다.
• 하드웨어 요구 사항 : 높은 성능과 안정성을 얻기 위해서는 그만큼 최신의 높은 성능의 하드웨어를 필요로 할 수 있고, 이러한 인프라의 경우 사전에 많은 비용의 투자가 필요하게 됩니다. 클라우드 환경에서는 특히나 분산 환경의 특성에 따라 단위 작업의 성능보다는 병렬 처리 성능에서 장점을 보이는데, 이러한 특성이 일반적인 상용 데이터베이스에서 요구하는 하드웨어적인 특성과 다를 수 있습니다.
• 제한된 호환성 : 상용 데이터베이스, 특히 MS SQL Server 의 경우 Microsoft 의 OS 나 개발 환경에서는 잘 통합되지만 일반적인 오픈 소스 데이터베이스에 비해서는 다른 OS 와 개발 환경에서는 호환성에 제약이 있거나 사전에 많은 작업이 필요할 수 있습니다.
• 기술 종속성 : 강력한 기능과 높은 성능을 위해서는 하드웨어, 소프트웨어, 인력적으로 많은 요소들에 대한 사전 투자가 필요로 하고, 이에 따라 쉽게 다른 기술에 대한 투자나 전환이 어려운 종속성을 가지게 됩니다. 실제 서비스 환경에서의 피드백을 바탕으로 지속적으로 변화하여 적응하는 것이 미덕인 클라우드 환경에는 적합하지 않을 수 있습니다.
• 클라우드 비친화적 : 상용 데이터베이스의 기술 기반이 강력한 하드웨어 중심의 인프라스트럭쳐에 기반하는 경우가 많은 만큼 이러한 분산과 네트워크를 바탕으로한 구성 및 스케일링이 자유로운 클라우드 환경의 특징에 맞춰 성능과 가용성을 높이는 최적화가 구성되지 않았기에 클라우드에 친화적이지 않습니다.

저장 프로시저의 단점

상용 데이터베이스의 문제와 함께 앞에서 말한 바와 같이 아직도 많은 MMORPG 프로젝트에서 저장 프로시저를 사용해서 게임 로직 처리를 진행하고 있는데, 이 경우 다음과 같은 문제들도 겪을 수 있습니다.

• 유지 보수 문제 : 비즈니스 로직이 게임 서버와 데이터베이스에 흩어져 있어서 전체적인 로직 파악에 시간이 오래 걸리게 됩니다. 특히나 저장 프로시저에서 쓰이는 언어와 애플리케이션의 언어가 차이가 나는 경우 두 언어를 모두 익혀서 살펴봐야하기에 더 어려움을 겪을 수 있습니다. 서버 구현 코드, 데이터베이스 스키마에 추가로 저장 프로시저 코드도 버전 관리가 필요하며, 이들 간의 의존 관계가 명확히 관리되어야 합니다. 기능 변경 시 서버 구현과 데이터베이스의 저장 프로시저를 모두 수정해야 하는 경우가 많아 관리 부담이 커집니다. 특히 라이브 게임의 경우 잦은 추가 기능 변경으로 인해 이러한 유지보수 부담이 더욱 가중됩니다.
• 데이터베이스 부하 문제 : 비즈니스 로직의 상당 부분을 데이터베이스가 관리하는 경우 데이터베이스에 부하가 증가하게 되어 병목이 될 수 있습니다. 일반적인 상태 비저장형 서비스에 비해서 상태 저장형 서비스인 데이터베이스는 확장이 어려운데, 저장 프로시저에 의한 부담은 병목 현상을 더 빠르게 가져올 수 있습니다.
• 구현의 어려움 : 게임의 경우 기획의 요구 사항에 따라 비즈니스 로직이 굉장히 복잡해질 수 있고 이러한 문제를 해결하기 위해서 객체 지향적인 설계의 이점을 최대한 활용할 필요가 있습니다. 저장 프로시저를 통해 이러한 요구 사항을 구현하기에는 상대적으로 저수준의 언어를 통해서 어렵게 구현해야하는 상황이 생길 수 있습니다.
• 테스트의 어려움 : 저장 프로시저의 경우 일반 애플리케이션에 비해서 테스트를 위한 라이브러리 등의 지원이 미비하기에 반복적인 자동화 테스트를 구축하기가 어렵습니다.
• 안정적 배포의 어려움 : 일반적인 수평적 분산이 잘 되는 상태 비저장형 서비스 등에서 많이 사용되는 단계적 배포가 어렵기 때문에 저장 프로시저를 배포할 경우 배포 중단 및 롤백 등의 안정적인 배포를 위한 작업을 구현하기가 어렵습니다.
• 로깅과 오류 처리의 제한 : 일반적인 애플리케이션에서 많이 쓰이는 고급 로깅 메커니즘이나 오류 처리 기능들을 저장 프로시저에서 직접 활용하기가 어렵습니다.

이미 저장 프로시저를 사용한 개발에 익숙하진 경우 이러한 문제들이 잘 느껴지지 않고, 큰 문제가 되지 않는다고 생각될 수 있지만, 이러한 문제점들로 인해서 여러 가지 개발 환경, 프레임워크 등에서의 개선과 혁신이 어려움을 겪는 경우가 많이 있습니다. 또한 유지 보수와 관련된 문제들의 경우 개발 초기 코드베이스가 작은 경우에는 크게 문제가 되지 않겠지만, 게임이 출시되기 직전으로 많은 컨텐츠들에 대한 완성이 필요하고, 테스트가 필요한 환경이나 출시 이후에 라이브 서비스 단계로 넘어가게 되면 여러 가지 유지 보수에 따른 문제가 크게 다가오는 것을 느끼게 됩니다.

게임 개발 환경의 변화

이러한 여러 가지 대안 방법 외에도 실제적으로 온라인 게임의 전체 시장 중에서 모바일 게임이 차지하는 비중이 크게 늘어나고 그에 따른 비동기 인터랙션 방식의 모바일 게임 서비스 구축이 많아지면서, 기존 MMORPG나 실시간의 빠른 인터랙션이 필요한 게임을 위한 개발 환경 외에 일반적인 웹서비스의 개발 환경 바탕으로 많은 게임들이 개발되고 있습니다. 이러한 웹 서비스 기반의 개발 환경은 기존의 게임 개발 환경과는 다르게 .NET 이나 Java, Node.js 등의 개발 환경에서 개방형 웹 프레임워크를 적극적으로 활용하여 개발 생산성을 높이는 방향으로 게임을 개발하는 경우가 많습니다. 이를 통해 빠르게 게임 백엔드를 개발하여 시기에 맞게 성공적으로 게임을 출시할 수 있도록 만들어 주었습니다. 또한 이러한 프레임워크를 바탕으로한 개발 문화는 기존의 게임 개발 경험이 없이 웹 서비스를 개발하던 인력이라도 게임 백엔드 개발 인력으로 사용할 수 있도록 해주는만큼 좀 더 쉽게 인력 수급이 가능한 업계 환경을 만들 수 있게 되었습니다. 이러한 프레임워크를 보게 되면 많은 프레임워크에서 오픈 소스 데이터베이스를 사용할 수 있도록 구성되어 있고 저장 프로시저 대신 객체 관계 모델 (Object-Relation Mapping, ORM) 방식을 통해서 DB와 연동할 수 있도록 제공하고 있습니다.

최근에는 이러한 웹 개발 프레임워크와 더불어 애플리케이션의 기능을 세부적으로 나누어 많은 수의 개별 서비스로 나누어 개발하고 이 서비스간의 커뮤니케이션을 통해 전체 애플리케이션을 이루는 마이크로서비스 형태의 개발 패러다임도 게임 개발에 많이 도입되고 심지어 단일 게임 환경에 많은 수의 사용자가 동시에 접속하여 인터랙션을 해야하는 MMORPG와 같은 환경에서도 각 게임 컨텐츠에 대해서 마이크로서비스를 나누고, 이를 결합하여 전체적인 게임 서비스를 구축하려는 시도가 많아지고 있습니다. 이를 통해서 MMORPG 에서도 마이크로서비스를 사용함으로 얻을 수 있는 장점들을 얻을 수 있을 것입니다. 플레이어 수가 증가할 때 병목이 되는 특정 서비스 (예: 채팅, 거래 시스템)만 독립적으로 확장할 수 있을 것입니다. 게임의 다양한 기능들 (인벤토리 관리, 퀘스트 시스템 등)을 독립적으로 분리하여 개발할 수 있기에 더 빠르게 기능을 추가하고 업데이트할 수 있으며, 특정 한 서비스의 문제가 전체 게임에 영향을 미치지 않도록 격리할 수 있습니다. 또한, 각 서비스에 적합한 기술 스택으로 개발을 할 수 있고, 독립적인 서비스를 개발 및 배포하여 기존보다 더 빠르게 개발 및 배포를 할 수 있게 될 것입니다.

대안

위의 문제점들을 겪고 있거나 새로운 도전을 하는 경우 그에 대한 대안으로 크게 세 가지 관점에서 대안을 찾을 수 있을 것 같습니다.

대안 1. 오픈 소스 데이터베이스 사용하기

오픈 소스 데이터베이스를 사용하게 되는 경우, 기본적으로 상용 데이터베이스에 대한 라이센스 비용의 부담을 덜 수 있습니다. 상용 데이터베이스의 경우 처럼, 다양한 읽기 복제, 장애 대응 환경 구축 등을 고도화하기 위하여 고성능 버전의 상위 티어를 사용할 필요도 없기에 오히려 실제적인 운영 메커니즘에 영향을 주는 기능들에 대한 도입에 따른 비용 제약이 완화될 수 있습니다. 또한 MySQL 이나 PostgreSQL 과 같은 오픈 소스 데이터베이스의 경우 상대적으로 구성이 간편하고, 사용사 커뮤니티도 굉장히 크기 때문에 전문 인력에 대한 요구 사항도 그만큼 낮아지게 됩니다. 그 광범위한 커뮤니티만큼 개발 환경에 대한 지원도 다양하기 때문에, 특정 기술 스택에 대한 종속성을 줄일 수 있기에 단순 데이터베이스의 비용적인 고려 사항 외에 개발 및 운영 인력, 서비스 기술 스택과 애플리케이션 인프라스트럭쳐에 대한 부분까지 광범위하게 영향을 미치게 됩니다.

오픈 소스 데이터베이스를 사용하는 경우 가장 우려하는 부분이 데이터베이스 성능에 대한 문제일 것 같습니다. 하지만 이러한 우려는 기우가 될 수 있는데, 쉽게 커스터마이징하여 클라우드에 최적화할 수 있는 오픈 소스 데이터베이스들이 기존 상용 데이터베이스들에 비해 훨씬 클라우드에 최적화되게 개발이 되고 이를 통해 분산 스토리지, 네트워크 병렬 처리, 서비스 형태의 컴포넌트의 장점들을 통해 충분히 좋은 성능을 발휘하고 있습니다. 특히나 분산 스토리지 기반의 서비스인 Amazon Aurora 의 경우 많은 수의 클라이언트로 부터 동시에 요청을 처리하는 상황에서 꾸준한 성능을 내어 주기 때문에 MMORPG 와 같은 쓰기 요청이 많이 발생하는 워크로드에서 좋은 성능을 보여주게 됩니다.

다음은 Amazon Aurora PostgreSQL 와 Amazon RDS for PostgreSQL 의 성능 비교 그래프로 클라이언트 수가 늘어남에도 성능이 유지되는 모습을 볼 수 있습니다.

오픈 소스 데이터베이스에 대한 우려가 있는 경우 Amazon Aurora MySQL 오해와 진실을 통해서 성능과 기능적인 우려를 불식시키고 Amazon Aurora MySQL의 여러 관리 도구를 SQL Server Management Studio 와 비교하기를 통하여 도구적인 대안을 확인하실 수 있겠습니다.

대안 2. 저장 프로시저 사용하지 않기

기존에는 인프라스트럭쳐의 제약에 의해서 저장 프로시저를 사용하여 얻게 되는 네트워크 트래픽 및 라운드 트립 회수의 감소에 따른 네트워크 성능 최적화, 캐싱의 재활용에 따른 쿼리 성능 최적화가 기본 인프라스트럭처의 성능이 월등히 올라 버린 최근에는 그 중요도가 예전만큼은 되지 않고 있습니다. 특히나 vCPU 의 개수, 각종 기능에 따른 라이센스 비용이 차이가 나는 상용 데이터베이스가 아닌 소프트웨어 비용 자체는 무료인 오픈 소스 데이터베이스 엔진을 사용하고 되는 경우 고성능 인프라스트럭쳐 사용의 제약이 상용 데이터베이스를 사용하는 경우에 비해 많이 줄어든 상황입니다. 이런 상황을 고려했을 때 로직의 분리에 따른 유지 관리 문제, 별도의 언어를 사용하는 전문가가 필요한 구현 상의 문제, 다양한 익숙한 테스트 프레임워크를 활용한 테스트 커버리지 문제, 데이터베이스 배포에 따른 안정성 확보 문제, 로깅 및 오류 처리의 다양성 부족 문제를 겪으면서 까지 저장 프로시저를 사용할 필요성이 줄어들었습니다. 대신 애플리케이션에서 비즈니스 로직 및 게임 로직을 전체적으로 구현하고, 데이터베이스의 저장 프로시저는 CRUD 형식의 단순한 요청만 처리한다든지, 또는 ORM 과 같이 객체의 변화를 데이터베이스에 쿼리로 변경하여 반영해주는 프레임워크를 사용하는 형식을 이용하게 되면 개발 속도와 함께 운영, 유지 보수 면에서도 많은 장점을 얻을 수 있게 됩니다. 저장 프로시저를 사용하지 않음으로써 얻을 수 있는 장점을 살펴보면 다음과 같습니다.

• 저장 프로시저 작성을 위한 별도의 전문가를 필요로 하지 않습니다. 일반적인 개발 언어와 표준적인 SQL 을 다를 수 있는 사람이 훨씬 더 쉽게 구할 수 있게 됩니다.
• 데이터베이스가 아닌 서버에 담긴 비즈니스 로직 위주로 테스트할 수 있고, 이를 통해 손쉽게 단위 테스트를 진행할 수 있게 됩니다.
• 일반적인 애플리케이션 개발 환경의 경우 저장 프로시저에 비해 훨씬더 강력한 개발 환경이 제공되기 때문에 개발 단계에서의 라이브러리 활용, 프레임워크 활용이 가능하고, 이에 대한 커뮤니티의 많은 지원을 받을 수 있습니다. 디버깅의 경우도 일반 애플리케이션 개발 환경이 훨씬 많은 도구들을 제공하는만큼 디버깅 난이도도 훨씬 쉬워질 수 있습니다.
• 부득이하게 비즈니스 로직을 애플리케이션 서비스와 데이터베이스에 중복 구현할 필요가 없기 때문에 버전 관리, 배포 관리의 부담이 훨씬 줄어듭니다.

대안 3. 관리형 데이터베이스 사용하기

클라우드 환경에서는 다양한 데이터베이스 관련된 서비스들을 관리형으로 제시해주고 있습니다. AWS 에서도 많은 종류의 데이터베이스들을 관리형으로 제공해주고 있고 이들 중에서는 게임에서도 많이 쓰이는 RDB 들에 대한 관리형 서비스인 Amazon RDS와 함께 인 메모리 캐시를 위해 사용되는 Amazon ElastiCache for Redis, 기존의 RDB 에서는 손쉽게 얻어내기 힘든 NoSQL 서비스들을 관리형으로 제공해주는 Amazon DynamoDB 등 다양한 관리형 서비스를 제공하고 있습니다.

이러한 관리형 서비스들을 사용함으로써 앞서서 문제가 되었던 데이터베이스 관련된 전문 관리 인력에 대한 문제와 함께 관리형 서비스에서 제공해주고 있는 다양한 동적 프로비저닝 방법을 통하여 기존의 월드를 확장하기 위해서 오랜 기간 준비가 필요하지 않고 필요할 경우에 빠르게 월드를 찍어낼 수 있는 상황을 만들 수 있으며, 이를 통해서 서비스 확장에 대비한 불필요한 대기 리소스의 낭비를 줄일 수 있습니다. 더 나아가서는 기존에 인프라 추가 확충과 관련하여 수동으로 준비했던 많은 일들을 API 를 통해서 자동화할 수 있게 되면서 기존과는 다른 형태의 게임 컨텐츠의 일환으로써의 월드 확장에 대한 개념을 게임 내에 소개할 수 있게도 되었습니다. Amazon Aurora MySQL을 활용한 클라우드 답게 데이터베이스 운영하기를 확인하시면 Amazon Aurora가 관리형 서비스로 제공하는 기능들을 확인하고, 관리형 서비스로 부터 얻을 수 있는 장점을 더 확실히 이해하실 수 있을 것으로 생각됩니다.

또한 단순히 RDB 를 관리형 데이터베이스로 사용하는 것 외에도 다양한 종류의 데이터베이스 (인 메모리 데이터베이스, NoSQL 데이터베이스) 들에 대해서도 관리형 서비스를 통해서 운영을 할 수 있게 되는만큼 운영 부담에 의해서 각 워크로드에 맞는 최적의 데이터베이스를 사용하지 못하거나 각각의 서비스를 아주 제한적으로 사용하던 것들도 해소함으로써, 각 워크로드에 맞는 데이터베이스를 손 쉽게 선정할 수 있게 됩니다.

서비스 예시

이미 많은 게임들이 오픈 소스로 데이터베이스를 사용하여 서비스를 구축 및 서비스함으로써 실제 오픈소스 데이터베이스로 충분히 고성능의 서비스를 개발할 수 있다는 것을 보여주고 있습니다.

• 카카오게임즈 – 오딘: 발할라 라이징에서 오픈 소스 데이터베이스를 활용한 MMORPG 의 사례 공유를 확인할 수 있습니다.
• 아마존 게임즈 – 뉴월드(New World)에서 MMORPG 의 월드 데이터 저장을 위해 NoSQL 인 DynamoDB 를 사용한 사례 공유를 확인할 수 있습니다.
• Second Dinner – Marvel Snap에서 AWS 상에서의 서버리스 개발을 활용하여 소규모 개발 스튜디오가 대규모 처리를 손쉽게 확장한 사례를 찾아보실 수 있겠습니다. 이를 통해 새로운 개발 게임 백엔드 파라다임의 도입이 성공한 사례를 확인하실 수 있습니다.

결론

앞서 살펴봤 듯이 게임 서비스에서 데이터베이스로 상용 데이터베이스를 사용하고 저장 프로시저를 사용하는 것은 기존과는 달라진 클라우드 위주의 서비스 운영과 게임 개발 환경의 변화에 따라 어려움을 겪고 있습니다. 특히나 저장 프로시저 사용 상의 단점은 처음엔 잘 드러나지 않지만, 운영이 장기화되면서 의존성 문제와 관리 부담 문제로 점점 어려움이 될 수 있는 부분이 많이 있습니다. 클라우드 환경에서는 오픈 소스 데이터베이스와 관리형 데이터베이스들이 충분히 매력적인 선택이 될 수 있는만큼 상용 데이터베이스와 저장 프로시저를 적극 사용하는 데이터베이스 중심 아키텍처 대신 다른 다양한 데이터베이스를 살펴보고, 이를 게임 개발에 적용하여 효율적인 개발을 할 수 있도록 검토해 볼 필요가 있습니다.