【レポート】全世界同時リリース、100万DAUを捌き切る！ 『転生したらスライムだった件 魔王と竜の建国譚』における大規模マネージドデータベースの運用事例 #CEDEC2022 #classmethod_game

こんにちは。ここではCEDEC 2022で講演された「全世界同時リリース、100万DAUを捌き切る！ 『転生したらスライムだった件 魔王と竜の建国譚』における大規模マネージドデータベースの運用事例」について興味あるところを中心にまとめてみました。

セッションの概要

全世界同時リリース、100万DAUを捌き切る！ 『転生したらスライムだった件 魔王と竜の建国譚』における大規模マネージドデータベースの運用事例

「転生したらスライムだった件 魔王と竜の建国譚」(以下まおりゅう)では、全世界100万DAU規模の同時リリースとノーメンテナンスの運用を実現しました。 本セッションではこれらのために、特にデータベース部分についてどのように技術選定を行い、各種手法を実現したか、また現在の課題と改善案、既存の手法との比較について紹介します ・各種マネージドサービスの比較と負荷試験に基づいた検証
・Google Cloud Spannerに対するWFS独自のウォームアップとその効果
・特有の問題と、それらに対する手法・コーディング時の注意点
・現在の構成での問題点及び改善案、既存のWFSの手法との比較

内容について

今回のセッションの発表について、印象深いところを中心に取り上げてみました。

ゲームの要件について

今回リリースされた「転生したらスライムだった件 魔王と竜の建国譚」は全世界同時リリースでDAU100万が目標ということで、かなり大規模なゲームをリリースする計画でした。

サーバ構成について

データベース（RDB)の選定ですが、マネージドデータベースを利用することは確定していたものの具体的にどのサービスを利用するかは確定していませんでした。そこで、複数のマネージドデータベースから選定するところから始まりました。

そういえば、AWS ESCやKubernetesを利用する事例はよく聞くようになりましたね。

データベース選定について

過去に実績のあるAWS AuroraやCloud SQLなどを検討しましたが、スペック調整のオペレーションコストがとても手間がかかるという懸念がありました。

【所感】マネージドデータベースを利用することでデータベースのサーバ自体の保守、運用からは解放されます。しかし、最適なコストで運用するためには利用する側がいろいろと作業する必要があります。その際は、ゲームであればメンテナンスに入らないといけない場合がほとんどですね。

Cloud Spanner採用決定するまで

さまざまなマネージドデータベースを比較、検討した結果Cloud Spannerを採用することとなりました。

【所感】このような場合、過去に実績のあるマネージドデータベースを採用する場合もあります。Cloud Spannerといった、これまで経験のないマネージドデータベースを選定する権限をもたせてくれるWFSさんはエンジニアにとってもよい環境だと感じました。この点はぜひ見習いたいです。

また、今ではまた新しいマネージドデータベースのサービスがありますので、これから検討するとまた違った結果になるんでしょうね。

Google Cloud Spannerの負荷試験

Cloud Spannerが本当に運用で利用できるのか、負荷試験などのさまざまな検証を行いました。それらの検証を行った結果、リリース要件としている数値を達成することができましたし、ノーメンテナンスで台数が変更できるなど運用の手間を減らすことができることも分かったので、採用が確定しました。

【所感】ノーメンテでできるというのはほんと強いと感じています。運営側にもユーザ側にもメリットありますね。

データアクセスの偏りをなくす

Google Clound Spannerを採用したら、あとは何も考えなくてもよいかというと、そういう訳ではありません。

そのような気をつける点としては、Cloud Spannerでのアクセスが偏らないように設計しました。というのも、アクセスが特定のノードに偏るとパフォーマンスに影響するためです。そういった偏りが出ないようにプライマリーキーにUUIDを仕様したり、ゲーム中に表示するお知らせといったようなどうしても偏りが出てしまわざるを得ない情報についてはキャッシュを利用してGoogle Clound Spannerにアクセスしないようにするなどの工夫を行いました。

【所感】当たり前ですが、これまでのRDBとはまた違う運用方法が求められる訳ですね。負荷試験などで特性などを調査しておくのは大事ですね。

コーディング注意点リスト

ただ、これまでのリレーショナルデータと同じような扱いはできず、Cloud Spanner特有のさまざまな対応が必要です。必要な対応については発表時のスライドにその回答がありました。

リリース前のウォームアップ

Cloud Spannerはリリース前にウォームアップをする必要があります。これは、ウォームアップしないとアクセスに偏りが発生し、レスポンスタイムが悪化するためです。

ウォームアップ専用ツールの作成

ウォームアップは手動で行うと大変なので「Spanner 温めるくん」というソフトを作成し、一連のウォームアップを自動化しました。「Spanner 温めるくん」で行うことはスライドにある通りで、これを利用することにより高負荷による不具合は発生せず安定したリリースが行えたそうです。

【所感】自動化できるところは自動化する。見落としがちですが大事なことです。

リリース後のオペレーション

リリースした後は運用が行われていきます。運用中にもテーブルのカラム変更や新規テーブルの作成など、データベースの構造の変更が入ります。

【所感】新規テーブルの追加などデータベースの構造変化を行う場合、Auroraなど従来のリレーショナルデータベースを仕様していた場合ではゲームを一度メンテナンスに入れた後に作業を行う必要があります。しかし、今回のCloud Spannerでは、すべてノーメンテナンスで行えました。なかなかこれらの事をノーメンテナンスで行えるのはスゴイですね...。

ノーメンテナンスで行えるとはいえ、それ相応の工夫は必要です。例えば、新規テーブル作成した後はウォームアップが必要といった具合です。

よかったところ

Cloud Spannerを採用して良かったところの紹介です。

【所感】ノーメンテナンスによる台数変更やシャーディング不要というのは、これは従来のリレーショナルデータベースを使った開発をしていた方からみると、かなりうらやましく思えるのではないでしょうか。

まとめ・感想など

このようにCloud Spannerを採用することで、これまでだったらメンテナンスに入らないとできなかった事が、ノーメンテナンスでできるようになった、ということは、大きなメリットだと思います。今まさに、これらで苦労している方々にとっては、とてもうらやましく思えるかも知れません。

個人的には、このようなチャレンジを許容する文化があるWFSさんはよい会社だと思います。このような新しいチャレンジを許容し、経験させることはエンジニアの成長にとって必要不可欠だと考えています。そのような文化の中で育ったエンジニアは、よりよいエンジニアが育ち、そこからまたよいサービスが生まれるのではないかと思います。