はじめに

こんにちは、DeNA のエンジニアの橋本侑樹です。2019年に新卒入社し、現在に至るまで DeNA の次世代ゲーム基盤のひとつであり、認証や課金などゲーム横断的に使われる機能を提供する LCX という社内向けサービスの運用・開発を行ってきました。本記事では、中国でスマートフォン向けゲームを配信するときに乗り越えなければならない課題に対し、それを乗り越えるために LCX チームがやってきたエンジニアリング上の工夫を紹介します。

（この記事は DeNA Advent Calendar 2021 の一部で。 DeNA TechCon 2021 Autumn の発表を再構築したものです。）

LCX の概略

LCX はモバイル・バックエンド・アズ・ア・サービス（mBaaS）と呼ばれる、複数のゲームタイトルに対して共通機能を提供するサービスです。提供している共通機能には、Google や Apple のアカウントでのサインインを提供する認証機能、アプリ内決済をハンドリングする課金機能などがあります。LCX は共通機能の中でも特にストアの抽象化に特化しており、Apple や Google などで提供されている API を統一的に呼び出すためのインターフェースを提供しています。

このような mBaaS は過去にも DeNA で開発・運用されてきましたが、LCX とそれらの最も特徴的な違いは、LCX はスマートフォン向けゲームを中国を含め全世界で配信することを使命として開発されているということです。

「スマートフォン向けゲームを中国を含む全世界で配信する」という挑戦

「面白いスマートフォンゲームを、より多くの人に楽しんでもらいたい。」
これはすべてのスマートフォンゲームに携わる人の共通の思いだと信じており、また DeNA の一社員である私も同じ思いを持っています。

しかし、実際には全世界でスマートフォン向けゲームを配信するためには、言語・翻訳の壁はもちろん、それに加え、各地域の法令を遵守し、それぞれの環境に合わせて配信を行う必要があります。例えば、日本で配信するのであれば「資金決済に関する法律」に従ってゲーム内通貨を管理する必要がありますし、アメリカで配信するのであれば「子供向けアプリに関するポリシー（COPPA）」を、ヨーロッパに配信するのであれば「一般データ保護規則（GDPR）」を遵守する必要があります。DeNA は今までに、アメリカ、ヨーロッパなど各国のこれら法令に対応し、スマートフォンゲームを配信してきました。

一方、中国のスマートフォン向けゲーム配信については、さらに高い壁が存在します。ひとつは法規制の壁、もうひとつは配信ストアの壁です。以下の節ではこれらの壁についてより詳しく説明を与えます。

法規制の壁

中国では、ゲームを販売・配信するためには「版号」と呼ばれる当局の許可が必要で、この許可は中国の国内会社しか取得できません。したがって、日本を含む外国の企業は、中国でゲームを直接販売・配信することができず、中国現地でパートナー企業を探し、その企業によって販売・配信を行う必要があります。

また、中国市場でゲームを配信する際には、中国政府の法令に迅速に対応する必要があります。たとえば、アプリ仕様時には実名認証を行い、未成年者に関してはゲームをまたいで合算した使用時間が一定値以下になるようにする必要があります。しばしば、法令が公布されてから施行されるまでのリードタイムが短いことがあり、法令に関する理解や対応するための機能を開発・運用するノウハウが必要となります。

ストアの壁

日本、アメリカ、ヨーロッパなどで配信する際には、iOS は Apple AppStore、 Android は Google Play をサポートするだけで、かなりの割合のユーザにゲームを配信することができますが、中国では Google Play を使用することができないため、 Android 向けに大小合わせて 50 を越える中国独自のストアが存在します。したがって中国でスマートフォン向けゲームを配信するためには、それぞれのストアの仕様や特性を理解した開発・運用を行う必要があります。
また、同様に Android 用の通知機能である、Firebase Cloud Messaging (FCM) が使えないため、プッシュ通知サービスについても中国国内で展開しているものを使用する必要があります。

「開発は共同、運用は独立」というソリューション

前章で紹介したように、中国でスマートフォン向けゲームを配信するためには、（１）法令で規制されているため（２）独特の市場環境に対応するために、現地の提携会社と密な連携をとる必要があります。DeNA は早い時期から中国市場を念頭においており、中国現地の会社と良好な提携関係を維持してきており、この強みを活かして DeNA は中国の提携会社と共同でゲーム共通基盤、すなわち LCX を開発することで、より効率的にスマートフォン向けゲームを提携会社が販売・配信できることを目指しました。

一方で、中国での運用時には（１）提携会社が運用を行うため運用主体が異なる（２）地域固有の法令対応、および抽象化の対象とするストアが異なるという２点から、リリースサイクルを日本チームとは分離し、独立して運用を行うことに決定しました。

運用経験に合わせたクラウド選定

運用主体が異なることは、開発・運用のノウハウにも差があることを意味します。日本チームは Google Cloud を使ったクラウドネイティブ mBaaS の運用経験があったのに対し、中国チームには Alibaba Cloud のノウハウが蓄積されていました。そこで、LCX ではアプリケーションの開発は日本チームと中国チームの共同で行うが、運用時にはノウハウのたまっているクラウド上で独立して行うことに決定しました。
多くの場合マルチクラウド構成にする目的は、一つのクラウドベンダーで障害が起こっても別のクラウドベンダー上のアプリケーションでカバーできるという冗長性を得るためですが、LCX は運用主体の違いからマルチクラウド構成にするという珍しいパターンだと考えられます。

インターフェースによるマルチクラウド実装と弱点

多くのクラウドサービスについては、インターフェースによる抽象化と依存性の注入によって、クラウドサービスを出し分けています。 例えば非同期キューを例にとると、Queue というインターフェースに対して、Google Cloud を使う場合には Google Cloud PubSub SDK を使って実体クラスを実装し、Alibaba Cloud を使う場合には Alibaba Cloud MNS のクライアントライブラリを使って実装することで、ビジネスロジックからはどちらのクラウドを使っているかを意識することなく開発が可能となります。

実際にほとんどのクラウドサービスの呼び出しは、インターフェースによる抽象化と依存性の注入によって出し分けを行っています。しかし、この実装方針はある種の問題をはらんでいます。日本チームと中国チームは共通の振る舞いをするようにインターフェースを実装するわけですが、日本チームは Alibaba Cloud での開発経験がなく、逆に中国チームは Google Cloud での開発経験がありません。したがって、どちらかのクラウドについてはよくわからない状態でインターフェースを切る必要があり、また２つの実体クラスの振る舞いをあわせることも容易ではないという弱点があります。

Java API によるマルチクラウド実装

永続化層（データベース）では、「インターフェースによる抽象化と依存性の注入」という実装による弱点はより深刻なものになります。例をあげると、 Google Cloud と Alibaba Cloud のそれぞれのマネージドデータベースである Google Cloud Spanner と PolarDB は少しずつ文法が違います。例えば、PolarDB の VARCHAR 型は Spanner だと STRING という型になります。したがって、単にテーブルをひとつ増やしたいときでさえ、日中の開発者は互いに協調して開発をする必要があり、少しでも協調が崩れてしまうとスキーマ違反でどちらかのアプリケーションが動かなくなる可能性すらあります。このことはアプリケーションの柔軟性と保守性に深刻な悪影響を及ぼします。

そこで、LCX では永続化層に関してさらに一層の抽象化を介した実装を行いました。Java には言語機能として永続化層を抽象化した JPA/JDBC という API があり、Google Cloud Spanner と Alibaba Cloud PolarDB のいずれもこの API を満たすライブラリが提供されています。LCX は永続化層の実装クラスからはそれぞれのクラウドサービスのクライアントを呼ぶのではなく、共通の Java API を呼ぶようにすることで、それぞれのマネージドデータベースの詳細を知らずとも、共通で使える永続化層の実体クラスの開発を可能にしました。先程スキーマ言語の違いを例示しましたが、データベースの DDL も JPA の機能を使って生成することが可能で、これにより日本チーム・中国チームのいずれの開発者ももう一方のクラウドプロダクトのデータベース方言を意識することなく、データベーススキーマを変更する事が可能です。

しかし、Java API を使った方法も銀の弾丸ではありません。JPA/JDBC は抽象化、すなわち詳細を捨てているため、その API では表現しきれない機能については使えないことに注意が必要です。例えば Google Cloud Spanner には INTERLEAVE というデータの物理的な配置を適切に設定することでデータアクセスを高速化する機能がありますが、これは古き良き RDBMS を想定して作られた API である JPA/JDBC の表現能力の外側にあるため、LCX では使用していません。また、実クラスの実装をライブラリに委譲している関係上、設定できるパラメータに制限があることもあります。実際に Spanner のクライアントライブラリを直接使った場合には設定できるタイムアウト値が、JPA/JDBC 経由だと設定できずに諦めた実装もあります。

このような代償こそありますが、JPA によるロジックの共通化はこれらのデメリットを補って余りあるメリット、すなわち複数のチームが同じコードベース上でマルチクラウド開発するための柔軟性と機動性をもたらしてくれました。

共通ロジックと地域専用ロジックの分離

中国での mBaaS の運用には、中国政府の要求に迅速に対応することが不可欠であり、またそれぞれのチームが抽象化したい対象のストアが異なることから地域固有のロジックが必要になることがあります。LCX では、エントリーポイントによって各クラウドのクライアントライブラリを出し分けているだけでなく、地域固有のロジックの出し分けも行っています。これによって、変更の頻度が多い地域固有のロジックについては、もう一方のチームへの副作用を考慮せずに修正することができ、より柔軟な運用が可能となっています。

まとめ

中国を含め全世界にスマートフォン向けゲームを配信するためには、日本と中国の２チームによる共同開発・独立運用という体制が必要となります。LCXでは日本チームと中国チームが互いのノウハウを活用するために、インターフェースによる抽象化、さらには言語が提供するインターフェースをも利用することで、インフラや地域固有のロジックによる摩擦を極限まで減らしました。かくして LCX は「世界のどこでも使える」インターフェースとその実体をゲームに提供することを実現しました。

DeNAでは今年、2021年度新卒エンジニア・2022年度新卒内定エンジニアの Advent Calendar もあります！ 本 Advent Calendar とは違った種類、違った視点での記事をぜひお楽しみください！

▼DeNA 2021年度新卒エンジニア・2022年度新卒内定エンジニアによる Advent Calendar 2021 https://qiita.com/advent-calendar/2021/dena-21x22