More Related Content Similar to MBaaS for Global and China (20) 2. ⾃⼰紹介
• 池野直⼈ @ikenox_
• 2017年04⽉ DeNAに新卒⼊社
• 2017年04⽉ 〜 2019年04⽉ : オートモーティブ事業部
• Anycaにてバックエンド開発/運⽤ @ オンプレ×Perl5
• 2019年04⽉ 〜 現在 : ゲーム・エンターテインメント事業本部
• 内製MBaaS「LCX」の開発 @ GCP×Java11 今⽇はこのお話👈
3. 本⽇のお話
• DeNAでは現在、ゲーム向けの内製MBaaS「LCX」を新規開発中
• MBaaS = Mobile Backend as a Service (例: FCM)
• 本⽇はLCXにおけるGCPの利⽤事例を紹介します
• LCXとは何なのか
• LCXはなぜGCP&Alibaba Cloudのマルチクラウド対応か、またそれをどのように実現し
ているか
• LCXでGAE/Java11を選択した理由、その恩恵や現時点での課題について
• おまけ: GAE/Java11でのネイティブバイナリ実⾏の話
6. ゲーム開発における課題②: 中国市場への進出
• DeNAの戦略: 中国は市場規模が⼤きく競合が少ない。⽇本でヒットしたタイトルを中国でも
リリースしたい
• しかし中国には数多くの独⾃Android App Storeが存在(40以上！)、APIもそれぞれ独⾃
• そのため⽇本のゲームを中国に持っていく際には、各ストア⽤に多くの新規実装が必要
• ゲームごとにこれを⾏うのは現実的ではない
中国以外(⽇本など) 中国
7. これらの課題を解決するためのMBaaS = LCX
• これらの課題を解決し、ゲームの迅速な開発とパブリッシングを実現するための
Mobile Backend as a Service = LCX
• ゲーム側は詳細の実装不要、必要に応じてLCXのAPIを呼び出すだけで各種機能を実現
ゲーム開発者の実装範囲 LCX
8. これらの課題を解決するためのMBaaS = LCX
• ストアごとの差異はLCXが抽象化して隠蔽、中国へのパブリッシングの際もゲーム側の改修不要
• コンセプトとしてはFCMに似ている
• 守備範囲がプッシュ通知だけではない＆中国市場もカバー
ゲーム開発者の実装範囲 LCX
9. これらの課題を解決するためのMBaaS = LCX
• ストアごとの差異はLCXが抽象化して隠蔽、中国へのパブリッシングの際もゲーム側の改修不要
• コンセプトとしてはFCMに似ている
• 守備範囲がプッシュ通知だけではない＆中国市場もカバー
ゲーム開発者の実装範囲 LCX
16. 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/
17. 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
利⽤サービスの違い
18. • Clean Architectureの考え⽅を適⽤
• ソースコードの⼤半は共通利⽤しつつ、クラウド
依存の部分のみ個別に実装
• Adapter Pattern, Repository Pattern
• interfaceは共通で、実装は２つ存在
• GCP⽤、Alibaba Cloud⽤
• Common modulesから⾒た際のインターフェー
スは共通なので、クラウドの違いによる処理の分
岐は現れない
LCX on Multi Cloud Platform
userRepository.save(user);
19. LCX on Multi Cloud Platform
GCPで動作させる場合
Alibaba Cloudで動作させる場合
20. LCX on Multi Cloud Platform
• Clean Architectureの考え⽅を活かして、GCPとAlibaba Cloudの両⽅への対応を実現
• 共有コード内にはクラウド依存の⽂脈のコードが現れない
• 必要な部分のみ異なる実装で動く
• GAE/Java11のApp Engine API⾮依存の特性もマルチクラウド対応の助けに
• 今のところ⼤きな問題は発⽣していないが、まだまだ開発段階のため今後も注視が必要
22. LCX on GCPの構成 (仮)
• 機能ごとにApp Engineのサービスを分けたりはしていない。単⼀サービスで全機能を提供
• キャッシュどうするかなど、未確定の部分あり
App
Engine
Cloud
Pub/Sub
Cloud
Datastore
Logging Monitoring
Cloud
Dataflow
BigQuery
Cloud
Storage
23. 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/
24. App Engine Java 11
• GAE/Java11はLCXの要件にマッチ
• LCXの主な業務は各種App Store APIのwrapping
• 処理⾃体は単純なものが多く、App Engineの各種制約が問題になりにくい
• App Engineなのでスケーラビリティが⾼い
• ハイトラフィックに対応しやすい
• 2nd-genでApp Engine API⾮依存なのでポータビリティが⾼い
• マルチクラウドに対応しやすい
• GAE/Java11はまだβだが、スケジュールには⼗分余裕があると判断
25. GAE/Java8 ⇒ Java11 で良くなった点
• App Engine API⾮依存の恩恵
• 別のプラットフォームでも動作しやすい（LCXにとって嬉しい）
• 利⽤するフレームワークも⾃由に選べる
• LCXでは、Spin-upが⽐較的速い＆開発時にHot ReloadできるQuarkusを採⽤
• ローカルでの開発時やテスト時にも、App Engineを意識する必要がほとんどない
• App Engine専⽤のDevelopment Serverが不要に。普通にJARを作って起動するだ
け
26. 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連携など、現時点だと不便な点がいくつか
• このへんはググると⾊々な⼈が語ってくれています
27. 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/
29. 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を⼀瞬検討した(後述)
30. • 動かしてみる
• ネイティブバイナリを作って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'
31. 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
