【セミナー】DeNA、ゲームを支えるバックエンドシステムにフォーカスしたセッション「DeNA GAME Techtalk＃1〜モバイルゲームを支える基盤技術〜」を開催

ディー・エヌ・エー（DeNA）<2432>は、3月15日、「DeNA GAME Techtalk＃1〜モバイルゲームを支える基盤技術〜」と題したセミナーを開催した。

ソーシャルゲームにおいてネイティブゲームが主流となっている昨今、それを支えるバックエンドシステムに求められる要件の高さや技術的難易度は高くなっている。本セミナーは、DeNAのゲームを支えるバックエンドシステムにフォーカスした4つのLightning Talksが行われた。

本記事では、Mobage時代からネイティブシフトを経験したDeNAだからこそ語れる"これまでのゲーム開発と現在のネイティブゲーム開発の違い"や、"今後のバックエンドシステムに求められる要件"を元に、現在同社がチャレンジしている内容について語られた本セミナーの模様をレポートする。
 

■Lightning Talk 1. DeNA BaaS戦略に関して

まずは「DeNAのゲーム向け共通基盤の戦略」と題したセッションが行われ、菅原賢太氏（ゲーム事業部 Publish統括部 共通基盤部 部長）が登壇。

DeNA入社後、同社サンフランシスコオフィスで働き、ゲーム向けバックエンドサービスの開発を行っていたという菅原氏から、DeNAがゲーム事業に対してバックエンドサービスの部分でどのように取り組んでいるか語られた。
 
タイトルにある"共通基盤"だが、その定義について「実はDeNAでは、かなり広い意味で使われている」と菅原氏が言うように、ゲームエンジン（Liftエンジン）やUnity向けの共通ライブラリ、ローカライゼーションツール、マスターデータ管理ツールなど、様々なプロダクトを共通基盤として提供している。

その中で今回、菅原氏がフォーカスしたのが、アプリゲーム向けの基盤サービス。DeNAでは、アプリゲーム向けの基盤サービスを大きく2つのカテゴリに分類しているそうだ。

1つはログインボーナスなどゲームサービスに依存するビジネスロジックを提供する機能群。そしてもう1つがゲームシステムに依らない、Google/Apple等のプラットフォームやバックエンド業務と連携する機能群"MBaaS"。

菅原氏は「ゲームを作る側は、あまり配信先やプラットフォームの種別による違いを気にしたくないので、極力ゲームはゲーム開発にフォーカスできるようにという形で」と分類されている理由を説明した。

そしてDeNAでのアプリゲーム事業におけるMBaaSについて、「実はそんなに機能はなくシンプルです」と菅原氏。

ユーザー管理（アプリユーザー認証、MBaaS利用ユーザー管理）、仮想通貨管理（ゲーム内通貨の残高や取引履歴の管理、決済レポート作成）、プッシュ通知、アナリティクス（ゲーム内で発生した各種アクティビティのログをイベントとして蓄積し分析を可能に）、NGワードチェック、問い合わせ管理といった提供機能を紹介した。

次に「DeNAはグローバルを意識しています。MBaaSの話をする上で、今回戦略というのが私の中にありますので、中国の話をさせてください」と、中国でのアプリ配信事情およびDeNAでの中国ゲーム事情について話を進めた。

「知っている方はご存知の通りですが、中国のゲーム配信は政府での所定の手続きを行った上でライセンスを取得しないと出すことができません」と、まず中国でのアプリ配信事業について触れた菅原氏。

「だからゲームを開発しても配信までに2～3ヵ月かかったり、ライセンスを取るために例えば中国国内にサーバーを置かなければならなかったり」と、様々な制約があるという。

また、「AppleのAppStoreでの配信であったとしても、ライセンスを保持していないと配信できない。中国にはGoogle Playは存在しておらず、その代わり20～30くらいのAndroidマーケットが存在しており、それぞれに対応する必要がある」と続けた。

そんな制約がある中で、菅原氏は「DeNAの中国でのゲーム事業の側面で言うと、弊社には中国オフィスがあり、そこが配信ライセンスを保有しています。中国国内においては、そのライセンスを保持した中国オフィスを拠点に、開発されたゲームを中国オフィスがパブリッシャーとなって配信している形です」と、DeNAが中国でアプリゲーム配信を行っている唯一の日本企業であると明かした。

「日本のゲームデベロッパーさんの中でも中国に拠点を持って配信できているところはなく、中国の会社、アライアンスパートナーを経由して配信するケースがほとんどだと思います」と、中国ゲーム事業において同社は強みを持っているとした。

ちなみに中国で配信しているゲームアプリも、MBaaSのようなプロダクト"LCM"を用意し、ゲームアプリを配信しているとのことだ。


▲LCMのほかにも、DeNAではこれまで様々なMBaaSがあったことも紹介された。

このように、色々なMBaaSが乱立していることを踏まえ、「やはりグローバルで勝てるアプリを、なるべく多く配信したいという思いがあります。日本の市場がなかなか厳しくなった状況で、少し整理する必要がある」と、菅原氏は今後の展望を明かした。

菅原氏によると、「先程お話した通り、ゲームサービスとMBaaSは切り離して考えるんですが、MBaaSの部分については、日本及び中国を除く世界向けに配信するアプリは日本で開発運営を行うLCDを、中国向けに配信するゲームは中国にて開発運用を行うLCMを使っていく想定でいる」とのことだ。



また、グローバル市場向けアプリ配信の基本ポリシーについては、「やはりゲーム側からすると、ワンソースコードでパブリッシュしたいところはあるが、そこでパブリッシュパイプラインの中でバンドルIDを中国向けと世界向けで変えることで、1つのアプリから複数のマーケットに対して対応していきたい」とのこと。


▲その他、MBaaSのインターフェースの互換についても触れられた。

最後に菅原氏は、「今後DeNAとしては、やはりMBaaSの領域を強化し、なるべくグローバルで、特に中国での効率的なアプリ配信を実現していきたいと考えている」とコメント。もちろんMBaaSだけでなく、「様々な共通基盤のプロダクトもタイトルラインナップのために強化していく」方針とのことだ。
 

■Lightning Talk 2. DeNAでのグローバルBaaS

続いて登壇したのは、ゲーム事業部 Publish統括部 共通基盤部の小原裕 (Hiro Obara) 氏。

「LCD DeNA Global BaaS」と題し、グローバル配信であるが故に発生する要件や課題について紹介すると共に、それらに対してどのように取り組んでいるかを、タイトルの状況や開発ロードマップを含めて語られた。



「菅原からMBaaSについて話がありましたが、私からは"LCD"というMBaaSについてお話させていただければと思います」と切り出した小原氏は、まずLCDがどのようなものなのか説明。

LCDはMBaaSの一種で、ゲームシステムに依らないGoogle Play/Apple等の配信プラットフォームや、バックエンド業務と連携する機能群を提供するゲームアプリ基盤サービスとのこと。LCDはLowest Common Denominatorという英語の略で、2014年9月から運用を開始している。

また、LCDは「数多く配信しているゲームアプリに必要な最小の機能を提供することで、ゲームやサードパーティのアプリなどの依存性を無くして、ゲーム開発をしやすくすること」（小原）を目的に作られたもので、中国、韓国を除く全世界でアプリが配信されているとのこと。

次に、LCDというグローバルなMBaaSを提供する上で必要な機能、サービス要件について。

まずサービスを提供する上での要件として挙げられたのが、24時間営業。「日本だけでの配信なら日本のプレイヤーの生活のパターンに合わせられるが、世界各地での配信となると時差の関係があるため、24時間プレイヤーに対応する状態」と小原氏。

また、世界各国の100以上の通貨に対応する必要があり、購入された課金＆仮想通貨の管理やレポーティングも必要だとした。

ローカライゼーションについても、「LCDのシステムメッセージは、日本語や英語だけでなく、使っているプレイヤーが理解しやすいように11ヵ国語に訳して提供している」（小原）とのこと。

その他、「e.g. GDPR、COPPA、特定商取引法、資金決済法など、各国の法律や規則をきちんと把握しなければならない」ことや、「タイトル数が増えてくると、開発チームや会社もアメリカや日本、中国、フランス、イギリスなど各国にまたがります。彼らからのLCDに関する問い合わせにも対応しています」と、小原氏は法律的な要件やデベロッパーズサポートについても触れた。


▲LCDがどのようなものかを簡単に示した図。

そして、現在LCDで提供されているサービスについて、「菅原の話にあったMBaaSの機能とほとんど一緒ですが」（小原）とした上で、ユーザー管理、ゲーム内仮装通貨管理、アナリティクス、NGワードチェック、CSツールといった特徴を紹介していった。



最後に小原氏から、LCDが今後の展望について語られた。

まず、DeNAがグローバル配信を重要視している側面から、「ゲーム側のほうではアメリカだったり、日本、中国など配信先のマーケットを気にすることなくゲーム開発を行い、そのまま希望のマーケットへ配信していけるように、LCDのほうでそういったマーケットの差を吸収していこうと思っている」とのこと。

また、ゲームエンジンに関しては、「昔はUnityなども持っていましたが、現状はゲームの数も少なくiOS、AndroidのSDKしか提供していません。ですので、今後はまたUnityのSDKも再開する予定です」とした。

他にもLCDシステム関連について、

・マルチテナント型システムからシングルテナント型システムへの変更
・LCD5周年を機に改めてシステムの見直しを図る
・LCDに限らずDeNA全体として新しい技術を積極的に開拓

といった展望を掲げた小原氏。最後に「今後LCDは世界に向けて配信する予定です」とメッセージを送った。
 

■Lightning Talk 3. DeNAのゲームサーバ技術の変遷とこれから

かつてはオンプレ、Perl、MySQLのイメージが強かったDeNAだが、ソーシャルゲーム黎明期から今日に至るまでに、ゲームサーバを構成する要素技術も移り変わってきた。

そこで、同セッションでは、「DeNAのゲームサーバの変遷とこれから」と題し、ゲーム事業部 Publish統括部 副統括部長の北澤慶郎氏が、DeNAの今までのゲームサーバを構成する要素技術の変遷と、これから目指していく未来像について紹介していった。



「先程までは事業や戦略の話など色々ありましたが、技術面に絞ったお話をします」と切り出した北澤氏は、これまでのゲームサーバ技術の変遷を「振り返ると大体こんな感じで4分割できます」と、以下のように分類し、各時期に活用した技術を紹介していった。



まずはブラウザ～ネイティブアプリ黎明期。どういう技術が使われていたかというと、Perl、MySQL、Server Side Rendering HTML。

これについて北澤氏は、「DeNAと言えば、昔はPerlという感じでしたが、それがまさにこの頃。MySQLもお馴染みですし、HTMLもサーバーサイドでいわゆるテンプレートエンジンに変数を突っ込んで開発するといった、よくあるWebの技術です」と紹介した。

その中で、「PerlやHTMLの部分はそれほど特殊なことはないのですが、やばいのがここです」とピックアップしたのがMySQL。

「MySQLはどういうことをやっていたかというと、いわゆるMaster-Slave構成からの垂直、水平分割を全てやり、Shardingと言われる1つのゲームタイトルで複数のデータベースを分割して、それをアプリケーションレイヤーで全部振り分けて複数DBを扱います。さらに厳密なトランザクションも守りながら、Shardまたぎをどうコミットするかというのをやっていました」と北澤氏。

「このブラウザ全盛期の頃、会社としても色々な経験になりました」と振り返った。

続いてネイティブアプリ（第1世代）で使われていた技術について。ネイティブアプリに入った時期に、どういうことをしていたのか？ 北澤氏は「さっきとあまり変わらないですが」と、MySQLはそのままに、Perl ⇒ Rubyに、Server Side Rendering HTML ⇒ RESTful APIに代わったことを紹介。

Perlに代わって使われたRubyに関して、北澤氏は「WebのシステムでRubyならRailsだろうと普通は思うけど、実際には表側のいわゆるクライアントから直接受けるAPIはSinatraで、管理画面はRailsでやってた」ことを明かした。

ちなみに、なぜ両方使っていたかというと、「2012年～13年はやはりブラウザ全盛期で、すごいトラフィックを捌いていたわけですが、同じことをRailsでやるのは無理だろうと思い、表側はSinatraで、管理画面についてはRailsが最適だろうということで分けていた」とその理由を説明した。

ブラウザ～ネイティブアプリ黎明期から使われているMySQLは、やっていることも、苦労の仕方も一緒ながら、「ここで新たな難しさに直面した」と北澤氏。

「表側はSinatra、裏側はRailsと両方あり、それぞれで難しいことをする。さらにRailsやアクティブレコードで、当時の2012年〜2013年のActiveRecordでアプリケーションレイヤーで複数DBみたいなのがかなり難易度の高いところにありました」（北澤）と、最終的にはActiveRecordという非常に高機能なものを使うのでさらに難しくなったそうだ。

そしてRESTful APIについて。データフォーマットはJSONだが、「IDLは独自のIDLを勝手に定義して、その中でJSON Schemaを内包。クライアントだけIDLからの自動生成みたいなことをしています」（北澤）とのことだ。

次に、2015年～2016年あたりを指すネイティブアプリ（第2世代）。第1世代から大きく変わらず、Rudy、MySQL、RESTful APIが使われている。

ただし変わった部分もある。

「皆さんもご存知であろう、グローバル大ヒットタイトルはすごいインストール数なんですけど、それも全てRailsでさばいています。この頃だとRailsもまあまあ重い部分を自分で外せたりできていたので、何とかできています」と、Rubyは表側のAPIもRailsになったという。

MySQLは昔から変わらずやっていることは同じだが、「この頃になると少し傾向が変わってきた」と北澤氏。

「昔のブラウザのソーシャルゲーム全盛期って、かなりソーシャル要素が強く、基本システムとしては非同期だけど、マルチプレイみたいにお互いに影響を受けるものだった。それがこの頃からゲーム全体がいわゆるシングルプレイの割合が増えてきて、Shardingでお互いに影響し合うみたいな難しさは量としては減ってきた。その分、単純にグローバル化が進む中で規模がどんどん大きくなったという難しさがあった」と振り返った。

RESTful APIも大体一緒とのこと。データフォーマットがProtocol Buffersになっているが、IDLは独自のIDLで、「この独自IDLはJSON」と北澤氏。「IDLって、大体作ったら自動生成したくなるけど、クライアントとサーバーの一部を自動生成みたいにしている」と説明した。

ゲームサーバの変遷を振り返ったところで、ここからは今後の展望について。北澤氏は「まだリリースしておらず開発中ですが」と前置きし、次の世代でどんな技術を活用していくのかを明かした。



まず、Google App Engine / Golangについて、北澤氏は「他社の方がよく発信しているものです。弊社だとAndAppというサービスがあり、その辺が結構同じGoogle App Engineで行っている」とし「大体普通のAPIサーバーだったらこれで問題ないです。問題ないどころかRails等と比べて実行効率は段違いに良さそうだし、オートスケールの性能とかもかなり良さそうなので、基本これで良いのではと考えています」と続けた。

次にGoogle Cloud Spanner。これは、アプリケーションレイヤーで複数DBを扱う必要がなく「相当楽です」と北澤氏。さらに「Spannerって勝手に内部的にShardっぽいものを持って、勝手にShardを分割してくれるんですけど、さらに減ってきたら勝手にShardを統合してくれる……そこは最高過ぎて、使えるなら使った方が良い」とした。

ただし、導入する上での固有のノウハウがかなり多いそうで、「MySQL時代に鍛えられた猛者でも、このノウハウをまた覚えないといけないという所が大変。それでもShardingなどをアプリケーションレイヤーで管理しなくて良いのはすごくメリットだと思う」と北澤氏は述べた。

3つ目に、RESTful APIに代わるRPCについて。RPCは、データフォーマットがProtocol Buffers、そしてIDLは独自IDLではなくProtobuf Schemaになっている。

「これってgRPCじゃんという感じですが、Protobuf Schemaの書き方等はgRPCとほぼ同じです。そこからgRPCと同様にサーバーコード、クライアントコードを自動生成しています。自動生成の仕方は参考にしているgRPCにかなり近いです」と北澤氏。ただ、「ちょっと自前実装しまくっているので、さっさとどこかでgRPCに置き換えたいと考えているとのことだった。

最後に北澤氏は、「ざっといままでの変遷をまとめましたが、昔を思い出しながらスライドを作る中で、結構その時代ごとに使う武器が変わっていて、適切な判断だったかというと100点ではないかなと思いますが、市場の進化に合わせてちょっと遅れてたり、先取っていたりしているなと感じました。歴史を辿ると、どんどん変わっているけど、意外と市場と同じことをやっていて、何となくみんなが同じ方向を見ている。これからも市場の進化を見ながら流れについていけるんじゃないかなと思っています」とまとめた。


 

■Lightning Talk 4. ゲームローカライズフローを支える基盤ツール開発

この日、最後に登壇したのは、立浪千尋氏（ゲーム事業部 Publish統括部 共通基板部 オペレーションサービスグループ）。「ゲームローカライズフローを支える基盤ツール開発」と題したセッションを行い、アプリのグローバル展開において避けて通れないローカライズフローを支援するためのDeNAのローカライズ支援ツール「LION」において、どのような課題に取り組んでいるかを紹介していった。



まずは"ゲームの制作とローカライズフロー"について。「エンジニアやプランナーを始め、各職種がそれぞれのフローに則って制作が進んでいきます」とゲーム制作フローについて説明した立浪氏。

各職種の中で、実際にグローバル展開していく場合においては、「プランナーが実際にゲームの言語で作ったテキストはたくさんあって、それを修正していくわけですが、まずはローカライゼーションコーディネーターが翻訳のスケジュールを出したり、誰に翻訳をお願いするかというところをコントロールします」と立浪氏。

そこから実際に様々な言語に翻訳する翻訳者に依頼が行き、翻訳が回ってさらに言語QAなどを重ねるなど品質を上げていくのが、ローカライズでは一般的とのことだ。



さらに詳しく見ると、「ゲームのローカライズフローはテキストを言語で作るといいましたが、ローカライズは全ての文字列に対してユニークなID、ラベルを付与して日本語でデータを作成します。それを元に各言語に翻訳していく」（立浪）ようだ。

その中で、言語によっては「日本語から直接翻訳するのが難しい」という立浪氏は、翻訳者の手配が簡単ではない言語があると明かした。

例としては、日本語を英語に訳す場合は比較的多くの翻訳者が対応できるが、「日本語からフランス語、ドイツ語などに訳すとなるとできる人がなかなかいない」（立浪）。そこで良く行われるのが、まず日本語を英語に訳し、そこから各言語に翻訳するという手法とのこと。

これがいわゆるゲームのローカライズフローとなっているが、モバイルゲームの事情が絡まってくると、ここからさらに運用というフェーズが始まるという。

運用が始まると、そのゲームでイベント開発だったり大きなUI回収等があると、先ほど説明された事と同様のフローがそこでまた発生。モバイルゲームの運用においては、ずっと繰り返していくイメージだ。

「それぞれの開発で同じフローを繰り返し、開発や翻訳が並行して進むタイミングでオーバーラップしていきます。こうしてモバイルゲームのローカライズにおける開発では、そもそも繰り返されることでどんどんテキストデータが増えていきます」と立浪氏。ここで、まずどの文字列が追加、更新されたか管理するだけでも相当大変であるとした。

加えて、「増え続ける各テキスト間の整合性を担保しなければいけないところ」「関わる職種が多岐に渡りることによるコミュニケーションコスト」も難しいと語った。


▲その他、モバイルゲームのローカライズにおける課題を紹介。

これら課題を解決するために開発されたのが、ローカライズ支援ツール「LION」だった。LIONとは、Webアプリケーションのローカライズフロー支援ツール。

機能としては、いわゆるデータ管理が主で、テキストデータをしっかり一元管理してデータベースにしている。「翻訳メモリというのは、すでに翻訳されている別の文字列から、似たような言葉を翻訳しようとしている時にしっかりピックアップできること」と立浪氏。

「LION」は、文字列での管理がしっかりとIDと言語に従って差分抽出できるようになっており、利用タイトルはそのテキストを「LION」に置いておけば、後は翻訳されたものを取り出すだけでゲームに反映できるという。

また、各種集計作業や翻訳の提出・差し戻し・受け入れ、メールベースコミュニケーションからの脱却など、各職種をまたいだワークフローをシステム化している。これにより翻訳作業と品質の管理に集中できるようにすることでのコミュニケーションコストの削減を図った。他にも、翻訳ツールとしての一般的な機能も備わっているという。

「LION」の概要、機能を紹介したところで、次に「LION」の開発における取り組みについて。「まず一番は、ローカライズ部門の悩みをしっかり吸い上げるというところ。実務者に徹底的にヒアリングすること」と立浪氏。

それでも、後になって必要な要件が発覚することも多々あるとし、「立ち戻って考えることは必要かなと思ってやっています」とコメントした。

他にも、SPA化したスプレッドシートUI、翻訳メモリや重複文字列の簡単なピックアップなどフロントの作り込みによる翻訳作業の効率化や、ゲームアプリ側の作りについても「これは「LION」開発というより、ローカライズフレンドリーな作りになっているかを考えていかなければいけないよねというところで、弊社ローカライズ推進部と一緒にチェックシートを作り、これを満たしているとローカライズしやすいという指針を整理しています」と、立浪氏は語った。

そして今後の展望については、「そもそも運用タイトルのつなぎ込みの検証中なので、現状バンバン回しているというより、これからやっと使っていくというタイミングです」（立浪）。

機能としては、「まず文字列のチェック系の機能を拡充していきたいと思っています。例えば文字数、行数はツール上ですぐチェックできるだとか、UIからはみ出していても言語QAに回る前に翻訳中に検知できたりするであったり、また基本的なスペルチェックなどの部分もも拡充していきたい」とした。

そしてアプリのデバック機能との連携に関して「実機で見たときに表示が崩れているという場合、実際どの文字列が崩れているのかを実機で確認できる状態を作りたいです」と立浪氏。

続けて最終的に将来目指したいこととして、「いわゆる実機プレイしながら翻訳者が翻訳できる状態。これが実現できたら本当に良いなという夢みたいな話ですが、いつか実現さえたいと思っています。あとは昨今機械翻訳の精度も上がってきているので、そことの連携も視野に入れて今後も開発していきたい」と述べた。

最後に立浪氏は、「世界各地でおもしろいゲームを届けるためのローカライズは、さまざまな手作業、課題が存在していて、モバイルアプリの運用も合わさるとさらに複雑化しています。

そこで発生する手作業や課題を克服するために、いま「LION」を開発しています。この改題解消のための機能を提供していきますが、まだまだ必要な機能もあります。今後も「LION」を使ってローカライズの品質向上、効率化を実現して、グローバルにアプリを配信していきたいと思っています」とメッセージを送った。