BLOG
게임? 데이터베이스? 이 둘은 어떻게 함께 사용될까요? 보통 데이터베이스는 보험 회사에서 보험 계리표를 유지하기 위해 사용하지 않나요? 이제는 머 엔터프라이즈 개발자가 되어야 하는 건가요?
많은 사람들이 이미 일반적으로 데이터베이스가 무엇인지는 알고 있지만, 이를 여러분의 게임이나 게임 개발 프로세스에 어떻게 적절히 쓸 수 있을지에 대해선 궁금하실 겁니다.
데이터베이스가 필요하신가요?
기본적으로 데이터가 있는 장소라면 어디에서든 데이터베이스를 사용할 수 있습니다. 게임 사용자는 다른 플레이어의 데이터에 액세스하여 게임을 보다 생생하고 살아있게 보이도록 할 수 있습니다. 또한 현실 세상의 정보를 사용하여 게임 플레이어들이 사회적 소통을 하고 게임 아이템을 거래할 수 있게도 할 수 있습니다. 뿐만 아니라 플레이어가 새로운 실행 파일을 다운로드 하지 않고도 컨텐츠 업데이트를 보다 쉽게 제공받을 수 있습니다.
데이터베이스는 데이터를 저장할 수 있는 중앙 온라인 장소입니다. 게임 서버 디스크에 데이터를 저장하는 것도 가능합니다. 그리고 실제로 디스크상의 큰 플랫 파일이 있다고 가정하면 게임 서버의 디스크에 데이터를 저장할 수 있습니다. 그리고 실제로 디스크에 큰 플랫 파일로 모든 것을 저장하는 일부 게임(일부 주요 상용 릴리스)도 있습니다. 그러나 일반적으로 게임 서버에서 게임 로직을 실행하고 실제로 데이터를 저장할 데이터베이스를 보유하는 것이 좋습니다. 여기에는 이유가 있습니다.
플랫 파일을 수천 또는 수백만 명이 동시 읽기를 하게 되면 성능 향상이 더뎌집니다. 쓰기 충돌(Write Contention) 및 디스크 오류는 의도하지 않은 손상 가능성을 높입니다. 플랫 파일에는 문제가 발생했을 때 데이터 중복성이 없을 수 있으며 문제를 복구하기 위한 좋은 전략도 없습니다. 데이터가 커질수록 액세스 속도가 느려지고 하드웨어 및 코드 용량을 넘어서 커질 수 있습니다. 플랫 파일도 기본적으로 검색할 수 없으므로 데이터 또는 데이터 패턴을 찾으려면 많은 작업과 코드가 필요합니다.
윗 문단에 나열한 것들이 데이터베이스가 처음 개발된 이유입니다. 이런 종류의 기술은 스스로 복제하기가 매우 어렵습니다. 게다가 여러분이 만들고 싶어하는건 게임이지, 데이터베이스가 아닙니다.
게임 서버가 없어도 데이터베이스는 여전히 유용합니다. 이 경우 게임 사용자는 일반적으로 데이터베이스와 거의 직접적으로 통신합니다. 실제로 중앙 데이터베이스만으로 구동되는 턴 기반 멀티 플레이어 게임을 만들 수 있습니다. 게임이 멀티 플레이어가 아닌 경우 데이터베이스를 사용하여 캐릭터 데이터 저장, 새로운 컨텐츠 제공, 메트릭 저장, 설정 저장, 플레이어 프로파일, 게임 저장, 아이템 인벤토리 등을 사용할 수 있습니다.
앞서 나열한 목록은 일부분으로 중앙 데이터베이스가 사용될 수 있는 항목은 훨씬 더 많습니다. 데이터베이스는 흥미롭고 새로운 게임 경험을 할 수 있는 많은 잠재력을 가지고 있습니다. 그리고 개발 파이프 라인에서 데이터베이스를 사용하여 개발 작업을 보다 쉽게 수행할 수 있는 방법에 대해서는 아직 얘기를 꺼내지도 않았습니다. 사실, 만약 소스 컨트롤이나 위키를 사용하고 있으시다면 이미 데이터베이스를 사용하고 있는 것입니다. 데이터베이스를 사용자 지정 도구 체인에 추가하면 데이터 공유, 일관성, 속도 및 안정성을 비롯하여 위와 같이 게임과 유사한 많은 이점이 있습니다.
SQL 대 NoSQL
NoSQL에 대해 들어 보셨을 수도 있고 SQL과 어떻게 다른지, 어떤 문제가 해결되는지 궁금해 하실 겁니다. 그리고 더 중요한 것은 이것이 게임과 어떻게 관련이 있는지 궁금하실 수 있습니다.
SQL은 “구형” 데이터베이스 기술입니다. 실제로 SQL은 데이터베이스 유형이 아니며 데이터베이스를 쿼리하는 데 사용되는 언어로, “구조적 쿼리 언어”의 약어입니다.
SQL이라는 이름은 종종 특정 종류의 데이터베이스와 관련이 있습니다. SQL은 일반적으로 행과 열로 구성되어 특별히 정의된 테이블에 모든 것을 저장 하는 관계형 데이터베이스를 쿼리 하는 데 사용됩니다. 열은 항목의 속성을 나타내며 항목은 행입니다. 스프레드 시트는 관계형 데이터베이스와 유사하지만 실제로는 관계형 데이터베이스의 UI 일뿐입니다. 이 디자인은 몇 가지 장점과 단점을 제공합니다.
단점은 이 테이블 모델에 유연성이 없다는 것입니다. 먼저 데이터의 구조를 미리 정의 해야 합니다(이 구조를 ‘스키마’라고도 부릅니다). 따라서 각 열 또는 속성이 무엇을 나타내는 지를 미리 지정해야 합니다.
나중에 열을 추가할 수 있지만 모든 항목에 대해 각 열의 값이 있어야 합니다. 예를 들어 무기, 갑옷, 물약 등과 같은 다양한 게임 아이템을 저장하는 “아이템” 테이블을 추가할 수 있습니다. 다음으로 피해, 방어 및 힘과 같은 각 속성에 대한 열을 만들어야 합니다. 그러나 모든 것들이 이치에 맞는 것은 아닙니다. 예를 들어, 갑옷은 데미지값을 갖고 있진 않으니 말이죠.
이 문제에 대한 몇 가지 해결책이 있습니다. 각 항목 유형에 대해 별도의 테이블을 작성하고 기본 항목에서 이를 참조하여 공유 속성(예 : 비용)을 파악해 스페이스를 절약할 수 있습니다. 또는 의미가 없는 열에 NULL 값을 사용할 수 있습니다. 어느 쪽이든, 그것은 복잡함 또는 비대화의 여분 레이어입니다.
이제 게임이 한동안 실행되어 많은 아이템이 생성되었다고 가정해 보겠습니다. 또한 방패에 기능을 추가하여 다른 플레이어를 강타할 수 있도록 설정했습니다. 이제 실제로 쉴드에 데미지 속성이 필요합니다. 그럼 무엇을 해야 할까요? 데미지 속성은 포션에 필요하지 않더라도 아이템 테이블에 데미지를 추가해야 할까요? 아이템에서 참고할 수 있는 “데미지” 테이블인 새로운 유형의 테이블을 만들면 될까요? 그러면 그 후 이전 스키마를 사용하는 모든 기존 항목을 어떻게 업데이트하나요? 속성을 추가하는 과정에서 아무것도 바꾸지 않고 이 모든 것을 해야 합니다.
여기는 NoSQL 데이터베이스가 들어오는 곳입니다. 다시 말하지만 ‘NoSQL’는 용어의 조합입니다. 대부분의 사람들이 NoSQL이라고 할 때 실제로 의미하는 것은 키-값 데이터베이스, 문서 데이터베이스, 비 관계형 데이터베이스, 객체 데이터베이스 또는 그 변형입니다. 이들 중 일부는 SQL로 쿼리할 수도 있으므로 NoSQL 데이터베이스를 처음에 호출하는 것은 잘못된 일입니다! 또한 NewSQL 을 시작해서도 안됩니다.
전문 용어를 제외하고, 여기서 초점은 이러한 데이터베이스가 사전에 스키마가 필요하지 않다는 것입니다. 즉, 데이터는 게임 오브젝트 속성이 저장된 방식과 일치하며 속성이 추가됨에 따라 쉽게 변경할 수 있습니다. 따라서 게임 아이템을 표현하는 예제에서 모든 아이템은 그 아이템에 어떤 속성이 있는지에 대한 목록을 가질 수 있으며, 속하지 않은 것은 제거할 수 있습니다. 쉴드 데미지와 같은 새로운 속성을 추가 해야 할까요? 문제 없습니다. 이제 쉴드 속성을 업데이트하여 데미지 속성을 포함시키면 됩니다. 아주 간단합니다!
물론 TANSTAAFL 입니다. 비 관계형 데이터베이스가 제대로 수행하지 못하는 몇 가지 사항이 있는데, 특히 범위가 지정된 쿼리입니다. 데이터베이스에 플레이어와 플레이어의 점수를 저장한다고 가정해 봅시다. 다른 플레이어와 가장 가까운 10명의 플레이어를 확인하려고 했을 때, 관계형 데이터베이스에서는 수준이 별도의 열에 저장되어 있으며 그에 따라 플레이어를 빠르게 정렬하므로 매우 빠른 쿼리입니다. 비 관계형 데이터베이스에서는 일반적으로 모든 단일 플레이어 레코드를 스캔하고 가장 가까운 10개의 트랙을 추적해야 합니다. 아쉽게도 이는 효율성이나 확장성이 별로 좋지 않습니다.
비 관계형 데이터베이스에 대해 또 다른 문제들이 있지만 이는 데이터베이스의 여러 복사본이 필요할 때 발생하는 문제일 뿐입니다. 세계의 다양한 지역에서 더 빠르게 액세스할 수 있도록 다른 지역에 데이터베이스를 보유하려는 경우 이는 중요한 아키텍처 균형점입니다. 최종적인 일관성은 결국 별도의 지역에 있는 모든 데이터가 일치한다는 것을 의미하지만 한 지역에서 쿼리 한 데이터가 다른 지역과 다르지 않을 것이라는 보장은 없습니다. 이는 일반적으로 데이터가 최신 상태인지 신경 쓰지 않고 “빠른 액세스”를 할 때나, 데이터가 최신 상태를 보장하는 경우에는 “느리지만 일관성 있는”액세스를 통해 해결되지만, 모든 지역을 먼저 확인 해야 합니다. 반면 관계형 데이터 베이스는 조작이 일관된 데이터를 반환하도록 보장하는 ACID라고 불리는 기능이 있습니다. 이것을 “거래”를 통해 제공하는 비 관계형 데이터베이스가 있지만 그것은 다른 주제입니다.
결론은 플레이어 및 아이템 속성과 같은 것의 경우 비 관계형 데이터베이스가 종종 훌륭한 선택이라는 것입니다. 그러나 고득점 테이블이나 분류하고자 하는 다른 데이터 또는 플레이어가 소유한 항목에 대해 의심의 여지가 없는 인벤토리인 경우 관계형 데이터베이스가 적합합니다.
글을 마치며…
오늘 글을 통해 게임 산업에 있어 데이트베이스의 새롭고 고유한 용도를 함께 알아본 시간이 유익하셨기를 바랍니다. 온라인으로 데이터를 중앙 집중화하고 플레이어가 이를 공유할 수 있게 되면, 많은 가치를 얻을 수 있습니다. 혹시 질문이 있으신가요? 다음에 배우시고자 하는 내용이 있다면 AWS subreddit에 들러 의견을 남겨 주세요!
원문 URL: https://aws.amazon.com/ko/blogs/gametech/managed-databases-for-awesome-games/
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.