MBaaS for Global and China
Naoto Ikeno @ikenox_
GCPUG Tokyo September 2019

⾃⼰紹介
• 池野直⼈ @ikenox_
• 2017年04⽉ DeNAに新卒⼊社
• 2017年04⽉ 〜 2019年04⽉ : オートモーティブ事業部
• Anycaにてバックエンド開発/運⽤ @ オンプレ×Perl5
• 2019年04⽉ 〜 現在 : ゲーム・エンターテインメント事業本部
• 内製MBaaS「LCX」の開発 @ GCP×Java11 今⽇はこのお話👈

本⽇のお話
• DeNAでは現在、ゲーム向けの内製MBaaS「LCX」を新規開発中
• MBaaS = Mobile Backend as a Service (例: FCM)
• 本⽇はLCXにおけるGCPの利⽤事例を紹介します
• LCXとは何なのか
• LCXはなぜGCP&Alibaba Cloudのマルチクラウド対応か、またそれをどのように実現し
ているか
• LCXでGAE/Java11を選択した理由、その恩恵や現時点での課題について
• おまけ: GAE/Java11でのネイティブバイナリ実⾏の話

About LCX

ゲーム開発における課題①: ⾞輪の再発明
• ゲーム内通貨の管理(課⾦)、ログイン、プッシュ通知など、ゲームの種類によらず必要となる
機能群がある。各ストアのAPIと連携が必要な部分も多い。実装の負担も⼤きめ
• ゲームごとに似たようなものを1から実装していることになる。使い回せるのでは？
各ゲームごとに実装
ゲーム開発者の実装範囲

ゲーム開発における課題②: 中国市場への進出
• DeNAの戦略: 中国は市場規模が⼤きく競合が少ない。⽇本でヒットしたタイトルを中国でも
リリースしたい
• しかし中国には数多くの独⾃Android App Storeが存在(40以上！)、APIもそれぞれ独⾃
• そのため⽇本のゲームを中国に持っていく際には、各ストア⽤に多くの新規実装が必要
• ゲームごとにこれを⾏うのは現実的ではない
中国以外(⽇本など) 中国

これらの課題を解決するためのMBaaS = LCX
• これらの課題を解決し、ゲームの迅速な開発とパブリッシングを実現するための
Mobile Backend as a Service = LCX
• ゲーム側は詳細の実装不要、必要に応じてLCXのAPIを呼び出すだけで各種機能を実現
ゲーム開発者の実装範囲 LCX

これらの課題を解決するためのMBaaS = LCX
• ストアごとの差異はLCXが抽象化して隠蔽、中国へのパブリッシングの際もゲーム側の改修不要
• コンセプトとしてはFCMに似ている
• 守備範囲がプッシュ通知だけではない＆中国市場もカバー
ゲーム開発者の実装範囲 LCX

これらの課題を解決するためのMBaaS = LCX
• ストアごとの差異はLCXが抽象化して隠蔽、中国へのパブリッシングの際もゲーム側の改修不要
• コンセプトとしてはFCMに似ている
• 守備範囲がプッシュ通知だけではない＆中国市場もカバー
ゲーム開発者の実装範囲 LCX

LCX on Multi Cloud Platform

クラウドの選定
• LCXでは、どのクラウドを利⽤するか？
• ⾃分たちとしてはGCPを使いたい
• インフラを頑張らなくてもスケールしやすくて、社内で運⽤実績や知⾒もあるApp
EngineやDatastoreを使いたい

中国とGoogle
• 中国ではGoogleが使えない
• グレートファイアウォール
• GCPも例外ではない、中国国内からはGCPにアクセスできない
• 例えば、App Engineのドメイン *.appspot.com はブロック対象
• 現状だと独⾃ドメイン経由ならアクセスできるが、今後も⼤丈夫な保証は無い
• LCXを中国で運⽤する際、クラウドはどうするか？

クラウドプラットフォームの選択肢
• 中国事情の前提のもと、クラウドプラットフォームの主な選択肢は以下
1. AWSを使う(中国リージョンが存在する)
2. LCXをマルチクラウド上で動作させる
• 中国以外: GCP
• 中国: Alibaba Cloud
• 結果的には、2を選択
• LCXをマルチクラウド上で動作させることに

マルチクラウド対応という選択
• 結局、運⽤や開発は中国チームによって独⽴して⾏われる部分も多い
• LCXは、DeNA中国オフィスのチームとの共同開発プロジェクト。
中国固有のロジック部分の開発や、中国での運⽤は中国チームが担当
• 40個以上のアプリストアとの連携や中国政府との連携など、⽇本チームによる開発・運
⽤は⾮現実的
• 中国でのゲーム配信の際には、現実的には中国国内にサーバーが必要
• 中国に関してはサーバーやデータを他と共有せず独⽴して運⽤せざるを得ない

マルチクラウド対応という選択
• 以上のことから、無理にクラウドプラットフォームを統⼀することによるメリットは⼩さい
と判断
• お互い⾃分達が開発や運⽤の実績があるクラウドプラットフォームを利⽤することに
• ⽇本チーム: GCP
• 中国チーム: Alibaba Cloud
• では、どのようにしてマルチクラウドで動作させるのか？

LCX on Multi Cloud Platform
• ⾔語はJava
• 中国、⽇本ともに馴染みがある
• 1つのコードをMulti Cloud上で動かす
• GCP: GAE/Java11
• Alibaba Cloud: マネージドKubernetes
• GAE/Java11(2nd-gen)はApp Engine API⾮依存
• そのため、GAE/Java11の上で動作するアプリはほとん
どそのまま他のプラットフォームでも動く！
中国中国以外
Some icons in this page are from http://icons8.com/

LCX on Multi Cloud Platform
• ただし、各クラウド固有のサービスを利⽤する部分に
ついては実装が完全に分かれることになる
• GCPを使う限りGoogle Cloud APIには依存するこ
とになるし、Alibaba側も固有のAPIを利⽤
• データベースは互いに性質が⼤きく異なるものを採⽤
• GCP: Datastore (NoSQL)
• Alibaba Cloud: DRDS (RDBMS)
• どのようにして異なるクラウド上で共通の動作を担保
するか？
GCP Alibaba
DB
Cloud
Datastore
Alibaba
DRDS
Async
Task
Cloud
Pub/Sub
Message
Service
Big
Data
BigQuery
On-prem
Cluster
Logging
Stackdriver
Logging
Alibaba
Log Service
利⽤サービスの違い

• Clean Architectureの考え⽅を適⽤
• ソースコードの⼤半は共通利⽤しつつ、クラウド
依存の部分のみ個別に実装
• Adapter Pattern, Repository Pattern
• interfaceは共通で、実装は２つ存在
• GCP⽤、Alibaba Cloud⽤
• Common modulesから⾒た際のインターフェー
スは共通なので、クラウドの違いによる処理の分
岐は現れない
LCX on Multi Cloud Platform
userRepository.save(user);

LCX on Multi Cloud Platform
GCPで動作させる場合
Alibaba Cloudで動作させる場合

LCX on Multi Cloud Platform
• Clean Architectureの考え⽅を活かして、GCPとAlibaba Cloudの両⽅への対応を実現
• 共有コード内にはクラウド依存の⽂脈のコードが現れない
• 必要な部分のみ異なる実装で動く
• GAE/Java11のApp Engine API⾮依存の特性もマルチクラウド対応の助けに
• 今のところ⼤きな問題は発⽣していないが、まだまだ開発段階のため今後も注視が必要

LCX with App Engine Java 11

LCX on GCPの構成 (仮)
• 機能ごとにApp Engineのサービスを分けたりはしていない。単⼀サービスで全機能を提供
• キャッシュどうするかなど、未確定の部分あり
App
Engine
Cloud
Pub/Sub
Cloud
Datastore
Logging Monitoring
Cloud
Dataflow
BigQuery
Cloud
Storage

App Engine Java 11
• LCXでは、実⾏環境としてGAE/Java11を選択
• GAE/Java11
• App Engine 2nd-gen Runtimeのうちのひとつ
• App Engine API⾮依存
• 2019年06⽉にβリリース1
• GCPのプロダクトのβ期間は平均すると6ヶ⽉ほど2
• 何事もなければ、2020年初頭にはGeneral Availability？
1 https://cloud.google.com/appengine/docs/standard/java11/release-notes
2 https://cloud.google.com/products/#product-launch-stages
Some icons in this page are from http://icons8.com/

App Engine Java 11
• GAE/Java11はLCXの要件にマッチ
• LCXの主な業務は各種App Store APIのwrapping
• 処理⾃体は単純なものが多く、App Engineの各種制約が問題になりにくい
• App Engineなのでスケーラビリティが⾼い
• ハイトラフィックに対応しやすい
• 2nd-genでApp Engine API⾮依存なのでポータビリティが⾼い
• マルチクラウドに対応しやすい
• GAE/Java11はまだβだが、スケジュールには⼗分余裕があると判断

GAE/Java8 ⇒ Java11 で良くなった点
• App Engine API⾮依存の恩恵
• 別のプラットフォームでも動作しやすい（LCXにとって嬉しい）
• 利⽤するフレームワークも⾃由に選べる
• LCXでは、Spin-upが⽐較的速い＆開発時にHot ReloadできるQuarkusを採⽤
• ローカルでの開発時やテスト時にも、App Engineを意識する必要がほとんどない
• App Engine専⽤のDevelopment Serverが不要に。普通にJARを作って起動するだ
け

GAE/Java11利⽤の際の課題
• 現状、DatastoreのクエリのRemote cacheingの決定打が無い
• 1st-genでは使えていたApp Engine付属のMemcacheが利⽤不可
• 代替案
• Memorystore for RedisにServerless VPC Access経由でつなぐ
• ただし現状、Objectify(DatastoreのJava Client Library)が明⽰的にRedisをサ
ポートしているわけではない
• GCEインスタンス上でMemcachedを建ててServerless VPC Access経由でつなぐ
• せっかくGAEがサーバーレスなのに
• ほかにもStackdriver連携など、現時点だと不便な点がいくつか
• このへんはググると⾊々な⼈が語ってくれています

GAE/Java8じゃだめなんですか
• 現状だと、1st-genのGAE/Java8を使ったほうが⾊々⼿軽で便利な側⾯もある
• 1st-genは、App Engine周辺エコシステムにべったり依存しているが故の便利さがある
• Java8⾃体はまだしばらく⽣き続ける。GAE/Java8のベースであるOpenJDK 8は、Red Hat
が2023年までサポート1
• しかし、GAE/Java8がいつまでサポートされるかは今のところ不明
• App Engineに関するアップデートも今後は2nd-gen向けのものがメインになっていくはず
で、メインストリームから取り残されるリスクもある
• 現状⾟い部分はGoogleも把握しているはず
1 https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support/

GAE/Java8じゃだめなんですか
• 総合的に⾒ると、今からならGAE/Java11が良いと判断
• 各種ライブラリのGoogle Cloud API対応も少しずつ進んでいたりして、エコシステムも
確実に整ってきている
• LCXだと、マルチクラウド対応のような事情もあり、GAE/Java11がより適している

GAE/Java11の可能性: ネイティブコンパイルJava
• GAE/Java11ではJavaのネイティブバイナリが動く
• 近年になってJavaをネイティブコンパイルする技術が登場(GraalVM)
• ネイティブコンパイルしたJavaのSpin-upは10xオーダーで速い
• ⼀般的に、JavaはGoと⽐べてSpin-upが遅い
• 構成にもよるが、LCXだと現状10〜20sec程度かかってしまっている
• 急なスパイクに耐えるための待機インスタンスが必要
• もしSpin-upを速くできれば、待機インスタンスを減らせてコスト削減につながる
• LCXでも、ネイティブコンパイルJava on GAE/Java11を⼀瞬検討した(後述)

• 動かしてみる
• ネイティブバイナリを作ってgcloud app deploy
• app.yamlのentrypointでネイティブバイナリを指定
• GAE/Java11に空のアプリケーションをデプロイして、Spin-up timeを測定1
• 通常(JVM)の場合: 約 5sec
• ネイティブバイナリの場合: 約 0.5sec！
• サンプルコード: https://github.com/ikenox/quarkus-appengine-example
GAE/Java11の可能性: ネイティブコンパイルJava
1 Instance typeはF1、5回ずつ測定した平均、Stackdriver logging上に記録されるlatencyを測定値としている
entrypoint: './target/quarkus-appengine-example-1.0-SNAPSHOT-runner'

GAE/Java11の可能性: ネイティブコンパイルJava
• とはいえ、LCXでの利⽤(プロダクション利⽤)はまだ厳しい印象
• GraalVM⾃体、Production releaseされたのはごく最近
• 既存のJavaの資産が現状使えないことも多い1
• リフレクションを使ってたりするとそのままだとコンパイルが通らない
• GAE公式にネイティブバイナリを動かすTutorialがあったりするわけではない。単に事
実として動くという状態
• GAE/Java11上では他⾔語のバイナリも動く2。話の程度としてはそれと同等か
• でも今後の動きによっては、Spin-upが早いサーバーレスJavaという夢が実現するかも…
1 https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
2 https://github.com/ikenox/rust-on-appengine-se

まとめ
• LCXにおけるGCPの利⽤事例でした
• LCXは中国展開を視野に⼊れ、マルチクラウドに対応する道を選択。コアロジックは共
有しつつ、GCPとAlibaba Cloudの両⽅で動作
• ハイトラフィック・マルチクラウドというLCXの要件的に、スケーラブルでポータブル
なGAE/Java11を選択
• App Engine API⾮依存の恩恵を受けている部分もあれば、現時点で課題も存在
GAE/Java11はもう少し⾜元の整備が必要な感じもあるが、今後に期待
• LCXのローンチに向け、引き続き開発を進めていきます

おわり