AndApp開発における全て #denatechcon

Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved.
AndApp開発の全て
Atsushi Kobayashi
General Manager
Systems Development Dept.
Open Platform Business Unit
DeNA

自己紹介
• 小林篤
⁃ 2011/03にDeNAに入社
⁃ MobageOpenPlatformのAPI/ProxyServer開発に従事
⁃ オープンプラットフォーム事業本部システム開発部部長
• Mobage全般・MobageOpenPlatform、協業Platform事業などの開発責任者
⁃ 一般社団法人JapanPerlAssociation 代表理事
• YAPC(Yet Anoter Perl Conference)などを主催しPerlの普及振興に尽力
⁃ Perl Hacker
• 自作のライブラリが日本の有名企業各所でも利用
⁃ 最近では社内GCP(GoogleCloudPlatform)エバンジェリスト的な活動
も
• 特別エバンジェリスト程詳しくもないですが…
2

AndAppとは
3

AndAppとは
• DeNAが新しく提供するPC向けのアプリケーションプラットフォーム
⁃ スマホでもPCでも遊べる場の提供
• 2016年11月にサービスローンチ
• 現在では11タイトルがリリース済
⁃ 今後続々リリース予定
4

AndAppとは
• 完全ド新規サービスなのでシステムをフルスクラッチで開発
• 本日は本システムの開発の裏側を余すところなくお伝え致します
5

開発現場の過去と現在
6

過去
• 今までの開発手法と技術スタック
⁃ Infra
• 基本オンプレ
• パブリッククラウドを使ってもサーバインスタンスの上にオンプレライクな
環境を構築
⁃ 開発言語はサーバはPerlがメイン
• DeNA内部要素に特化したライブラリが整備されている
• Perlでの開発に慣れ親しんだエンジニアが多い
⁃ JSON Schemaやmicroservice、JWTを積極的に導入
⁃ 認証/認可ではOpenID Connect等の標準仕様に則った設計/開発や
JWT(JSON Web Token)等を積極的に活用
7

現在
• 今の開発手法と技術スタック
⁃ Infra
• GCP(Google Cloud Platform)の中のGoogleAppEngineを積極的に活用しほ
ぼ全てのシステムをGAEで提供
⁃ 開発言語はサーバをgolangに変更
• GAE SE(Standard Environment)でPerlをサポートしていない為
⁃ JSON Schema/microservice/OIDC/JWTなどの技術は引き続き利用
8

過去 to 現在
• 何故変えたのか？
• 変える必要あったのか？
• 変えてどうだったのか
9

何故変えたのか
• 変えたかったから！
10

第一部完
11

何故変えたのか１
• Infra
⁃ 運用という名の苦行
• 運用はとても大切です
⁃ 大規模システムになればなるほど使うサーバ台数が多くなる
• 故障率というのがあってだな
⁃ 台数が多くなるとメンテナンスコストが高くなる
• 故障率（ｒｙ
• セキュリティパッチ等
• オペミスの確率も上がる
⁃ 多数のサーバ管理を効率化する為の自動化するにも工数がかかる
• 歴史的背景等もあるわけです
• 歴史・経験があるからこその独自ツール
• 其の環境でしか使えないナレッジ
12

変える必要があったのか
• 究極変えなくてもやっていける
• ただ既存のテクノロジーの上でヌクヌクしていると、数年後には其の環境
でしかやっていけない人材になってしまう
• 現状維持は退化でしかなく、挑戦し続けることで第一線で戦い続けられる
• フルスクラッチでシステム開発出来る機会なんて早々ない。
• つまり今しかない！
13

何故変えたのか２
• 人の工数は有限
• システムを開発・運用する上でどうしても必要となる工数以外はサービス
を創る工数に回したい・回すべき
• 人間の頭脳を余すところなく最大限モノづくりに投入したい
• 周辺テクノロジーでそれを実現出来るものがある！
• 使わないわけには！
14

技術選定
15

GoogleAppEngine
• 運用コスト等を最大限抑えることが第一のお題
• パブリッククラウドで提供されるフルマネージドサービスをフル活用する
べく様々なサービスの検討を開始
ではないんです
16

GCP ManagedVM
• 本検討の少し前にGCPのManagedVMというサービスがβ提供始まった
• 簡単に言うとManagedVMは好きなプログラミング言語をランタイムに選
べるGAEみたいなもの
• DeNAのエンジニアはPerlに慣れ親しんでいるので開発言語をPerlのまま
でGCP ManagedVMを利用すれば丁度いい感じにマネージドされる環境を
構築できるんじゃないか
• ということでPerl on ManagedVMという技術スタックで一部システムの
開発を先行させる
• なので、他のパブリッククラウドのサービスを細かく調べてはいません
⁃ ある程度情報は持ってる、何ができそうかのイメージはあるが精緻に
は調べてない
17

GCP ManagedVM
• 実際にManagedVM上で開発してみるも、GCPの各サービスやAPIとつな
ぐのにライブラリの開発から必要だった！
⁃ そらそうだ
• βサービスということもありGAEほどこなれておらずtry&errorがかなり多
くなってしまった
⁃ βですし…
• パフォーマンスも思った以上に出ず、チューニングにかなり工数が取られ
そうだった
• ManagedVMは人類には早かった
⁃ ちなみに今はGoogleAppEngine FlexibleEnvironmentと名称等が変
わっております
18

Google Container Engine(GKE)
• ManagedVMで１機能作るのに並行してGKEでも１機能作り始めた
• GAE系ではネットワーク周りの制限が一部あるので、その制限を受けられ
ない機能を開発する場合は違う技術選定をする必要がある
• Google Compute Engine(GCE)をつかう事も当然できるがお題に反する
• GKEを活用して上手く構成を組めればフルマネージドサービスに近いシス
テム構築が可能ではある
• 色々試行錯誤し実際に開発したが…
• もっと楽にできないのかっ！何気にめんどくさい！
19

Firebase
• GKEでは通知関連のシステムを作ろうとしていたのでGCPファミリーにな
ったFirebaseの利用を検討
• 通知の基盤としてはFirebaseを活用し、周辺APIをGAEで作ることでフル
マネージド！
20

と、言う感じで
• 幾つかの試行錯誤の上、我々が求めるものを一番満たしてくれるのはGAE
のStandard Environmentだという結論に至る
• サクッとGAE/go＋Firebaseでシステム開発を始めたわけではなく、幾つ
かの試行錯誤と失敗を積み重ねました
• ただ、あるテクノロジーが有用なのかどうか、その場のニーズに合うかど
うかを見極めるには実際に使ってみるのが一番
21

GAE SEに決めてから
• GAE SEにすると意思決定した後に開発言語を再選定する必要があった
⁃ Java7
⁃ PHP
⁃ Python 2.7
⁃ Go
• 今までPerlというLL言語を利用していたので折角ならLL以外で。
• ということでPHPとPythonは除外
• Perlエンジニア的にはGoが一番良いというウワサとJavaが嫌いという同
しようもない理由でGoとしました（え
⁃ 実際Perl Hacker達は最近ではGoを使うことが多いですね
⁃ GAEとの相性も良い
• Footprintが軽くspin-upしてくる時間がJavaと比べると圧倒的
22

システムアーキテクチャ
23

AndApp System Overview
24

基本構成
• 機能単位でコンポーネントを分割
⁃ User / Notification / 分析 / 決済などの単位
• コンポーネント毎にGAEのサービスとして配置
• データストアにはDatastoreを利用
⁃ RDBMSを使わない選択！
• Go
⁃ WebApplicationフレームワークにはGinを採用（一部echo）
⁃ DatastoreライブラリとしてはGoonを採用
• 分析用途としてはBigQueryを採用
• Log管理はStackdriver Logging
• 監視はStackdriver
• システムメトリックスはGCPのコンソール
• Theフルマネージド
25

なぜDatastore
• GCP上でRDBSを利用するとするとCloudSQLが選択肢に入る
⁃ GCE上にMySQLを立てるとかもできるけど趣旨に反する
• ただCloudSQLが思った以上にパフォーマンスが出ない
⁃ 途中でパフォーマンス改善はあったものの
• PokemonGoでの実績
• 郷に入っては郷に従え
26

開発体制
27

チーム構成
• 大まかな機能単位でチーム構成
⁃ 一人チームもあれば２〜３人チームもあり、最大でも１チーム５名程
度
⁃ 総開発人員数は２５名程
• Microserviceでの開発を行っており、１機能１コンポーネント１リポジト
リ１サービスという形の開発を行っているので開発そのものは複数のチー
ムに分かれて実施可能
28

チームを細切れにしてもワークした理由
• チームメンバーが多く、かつチームが細切れだと空中分解しかねない
• そうさせないために
⁃ 各チームのリードエンジニア陣をあつめたDSを実施
⁃ 共通基盤チームを用意しライブラリや開発作法ほ基本統一
⁃ JSON Schemaを活用しI/Fの可視化とValidationで利用
⁃ Documentのフォーマットを決めDocument Firstでの開発
29

GAE+microservice
• なにげに相性が良い
• １コンポーネントがGAEの１サービスとなり、他コンポーネントに基本影
響されずに管理が可能
⁃ オンプレなどではどのサーバにどのコンポーネントをdeployするか
⁃ LBやProxyの設定をどのようにするかの管理が複雑…
• ただし1プロジェクトあたりの利用可能Service数が20なので要注意
⁃ 相談すれば上限突破してくれるかも
⁃ 現時点で我々は26サービスを利用している
30

コスト
31

コスト is 何？
• 一番イメージしやすいのは
⁃ サーバ購入費
⁃ データセンター関連の諸費用
• 忘れがちなのが人件費
• なかなか思いつかないのはコミュニケーションコスト
32

コスト(サーバ・DC)
• 当然必要な台数を用意する必要があるので初期費用がかかります
• パブリッククラウドって一般的にはこういう初期費用をかけずに利用でき
るのがウリだったりしますよね
• オンプレでサーバを用意する場合、例えば他サービスで余ったサーバを回
してもらう、減価償却切れのサーバを回してもらうとすれば初期費用はお
さえらえれるかもしれない
• DCのコスト（ラック・電源・ネットワーク・etc）はどうしてもかかって
いく。規模によってはボリュームディスカウント効くけど
⁃ 前職ではサービス規模に対して結構な額になったり
33

コスト(人件費)
• 何かを安定的に維持するには人が必要
• サービス開発以外にInfraをお守りする必要がありそこで働く人のコスト
が発生する
• 規模が大きくなれば必要とする人も多く必要になってくる
34

コスト(コミュニケーション)
• 情報共有はとても大切
⁃ 大規模開発になりチームが細切れだったりチーム人数が多ければ特に
• とても大切だし必要なんだけど関係者が膨れ上がるとそれはコストになる
• 営業・企画・デザイナー・エンジニア・QA・法務・などなど関係者が膨
らんでくるともう大変
• 密室ではなくシンプルに出来るところはする
35

まとめ
36

まとめ
• 既存の技術や運用にとらわれない事
• モノづくりに集中出来る環境を如何に用意できるか
• 今回の例は実はかなりチャレンジング
⁃ もっとスモールスタートしてもいい
⁃ つまり既存のシステム・サービスの一部から始めるもよい
• 新しい取り組みに失敗はつきもの
⁃ 失敗を許容しよう、そこから学ぼう
• 振り返ろう
⁃ やって満足しない。課題はいっぱいある
• 一番大切なことは
⁃ めいいっぱい楽しむこと。ワクワクしよう！
37

AndApp開発における全て #denatechcon

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to AndApp開発における全て #denatechcon

Similar to AndApp開発における全て #denatechcon (20)

More from DeNA

More from DeNA (20)

Recently uploaded

Recently uploaded (12)

AndApp開発における全て #denatechcon