AndApp開発における全て #denatechcon
- 1. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. AndApp開発の全て Atsushi Kobayashi General Manager Systems Development Dept. Open Platform Business Unit DeNA
- 2. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 自己紹介 • 小林 篤 ⁃ 2011/03にDeNAに入社 ⁃ MobageOpenPlatformのAPI/ProxyServer開発に従事 ⁃ オープンプラットフォーム事業本部 システム開発部 部長 • Mobage全般・MobageOpenPlatform、協業Platform事業などの開発責任者 ⁃ 一般社団法人JapanPerlAssociation 代表理事 • YAPC(Yet Anoter Perl Conference)などを主催しPerlの普及振興に尽力 ⁃ Perl Hacker • 自作のライブラリが日本の有名企業各所でも利用 ⁃ 最近では社内GCP(GoogleCloudPlatform)エバンジェリスト的な活動 も • 特別エバンジェリスト程詳しくもないですが… 2
- 3. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. AndAppとは 3
- 4. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. AndAppとは • DeNAが新しく提供するPC向けのアプリケーションプラットフォーム ⁃ スマホでもPCでも遊べる場の提供 • 2016年11月にサービスローンチ • 現在では11タイトルがリリース済 ⁃ 今後続々リリース予定 4
- 5. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. AndAppとは • 完全ド新規サービスなのでシステムをフルスクラッチで開発 • 本日は本システムの開発の裏側を余すところなくお伝え致します 5
- 6. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 開発現場の過去と現在 6
- 7. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 過去 • 今までの開発手法と技術スタック ⁃ Infra • 基本オンプレ • パブリッククラウドを使ってもサーバインスタンスの上にオンプレライクな 環境を構築 ⁃ 開発言語はサーバはPerlがメイン • DeNA内部要素に特化したライブラリが整備されている • Perlでの開発に慣れ親しんだエンジニアが多い ⁃ JSON Schemaやmicroservice、JWTを積極的に導入 ⁃ 認証/認可ではOpenID Connect等の標準仕様に則った設計/開発や JWT(JSON Web Token)等を積極的に活用 7
- 8. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 現在 • 今の開発手法と技術スタック ⁃ Infra • GCP(Google Cloud Platform)の中のGoogleAppEngineを積極的に活用しほ ぼ全てのシステムをGAEで提供 ⁃ 開発言語はサーバをgolangに変更 • GAE SE(Standard Environment)でPerlをサポートしていない為 ⁃ JSON Schema/microservice/OIDC/JWTなどの技術は引き続き利用 8
- 9. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 過去 to 現在 • 何故変えたのか？ • 変える必要あったのか？ • 変えてどうだったのか 9
- 10. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 何故変えたのか • 変えたかったから！ 10
- 11. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 第一部完 11
- 12. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 何故変えたのか１ • Infra ⁃ 運用という名の苦行 • 運用はとても大切です ⁃ 大規模システムになればなるほど使うサーバ台数が多くなる • 故障率というのがあってだな ⁃ 台数が多くなるとメンテナンスコストが高くなる • 故障率（ｒｙ • セキュリティパッチ等 • オペミスの確率も上がる ⁃ 多数のサーバ管理を効率化する為の自動化するにも工数がかかる • 歴史的背景等もあるわけです • 歴史・経験があるからこその独自ツール • 其の環境でしか使えないナレッジ 12
- 13. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 変える必要があったのか • 究極変えなくてもやっていける • ただ既存のテクノロジーの上でヌクヌクしていると、数年後には其の環境 でしかやっていけない人材になってしまう • 現状維持は退化でしかなく、挑戦し続けることで第一線で戦い続けられる • フルスクラッチでシステム開発出来る機会なんて早々ない。 • つまり今しかない！ 13
- 14. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 何故変えたのか２ • 人の工数は有限 • システムを開発・運用する上でどうしても必要となる工数以外はサービス を創る工数に回したい・回すべき • 人間の頭脳を余すところなく最大限モノづくりに投入したい • 周辺テクノロジーでそれを実現出来るものがある！ • 使わないわけには！ 14
- 15. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 技術選定 15
- 16. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. GoogleAppEngine • 運用コスト等を最大限抑えることが第一のお題 • パブリッククラウドで提供されるフルマネージドサービスをフル活用する べく様々なサービスの検討を開始 ではないんです 16
- 17. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. GCP ManagedVM • 本検討の少し前にGCPのManagedVMというサービスがβ提供始まった • 簡単に言うとManagedVMは好きなプログラミング言語をランタイムに選 べるGAEみたいなもの • DeNAのエンジニアはPerlに慣れ親しんでいるので開発言語をPerlのまま でGCP ManagedVMを利用すれば丁度いい感じにマネージドされる環境を 構築できるんじゃないか • ということでPerl on ManagedVMという技術スタックで一部システムの 開発を先行させる • なので、他のパブリッククラウドのサービスを細かく調べてはいません ⁃ ある程度情報は持ってる、何ができそうかのイメージはあるが精緻に は調べてない 17
- 18. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. GCP ManagedVM • 実際にManagedVM上で開発してみるも、GCPの各サービスやAPIとつな ぐのにライブラリの開発から必要だった！ ⁃ そらそうだ • βサービスということもありGAEほどこなれておらずtry&errorがかなり多 くなってしまった ⁃ βですし… • パフォーマンスも思った以上に出ず、チューニングにかなり工数が取られ そうだった • ManagedVMは人類には早かった ⁃ ちなみに今はGoogleAppEngine FlexibleEnvironmentと名称等が変 わっております 18
- 19. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. Google Container Engine(GKE) • ManagedVMで１機能作るのに並行してGKEでも１機能作り始めた • GAE系ではネットワーク周りの制限が一部あるので、その制限を受けられ ない機能を開発する場合は違う技術選定をする必要がある • Google Compute Engine(GCE)をつかう事も当然できるがお題に反する • GKEを活用して上手く構成を組めればフルマネージドサービスに近いシス テム構築が可能ではある • 色々試行錯誤し実際に開発したが… • もっと楽にできないのかっ！何気にめんどくさい！ 19
- 20. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. Firebase • GKEでは通知関連のシステムを作ろうとしていたのでGCPファミリーにな ったFirebaseの利用を検討 • 通知の基盤としてはFirebaseを活用し、周辺APIをGAEで作ることでフル マネージド！ 20
- 21. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. と、言う感じで • 幾つかの試行錯誤の上、我々が求めるものを一番満たしてくれるのはGAE のStandard Environmentだという結論に至る • サクッとGAE/go＋Firebaseでシステム開発を始めたわけではなく、幾つ かの試行錯誤と失敗を積み重ねました • ただ、あるテクノロジーが有用なのかどうか、その場のニーズに合うかど うかを見極めるには実際に使ってみるのが一番 21
- 22. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 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. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. システムアーキテクチャ 23
- 24. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. AndApp System Overview 24
- 25. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 基本構成 • 機能単位でコンポーネントを分割 ⁃ User / Notification / 分析 / 決済などの単位 • コンポーネント毎にGAEのサービスとして配置 • データストアにはDatastoreを利用 ⁃ RDBMSを使わない選択！ • Go ⁃ WebApplicationフレームワークにはGinを採用（一部echo） ⁃ DatastoreライブラリとしてはGoonを採用 • 分析用途としてはBigQueryを採用 • Log管理はStackdriver Logging • 監視はStackdriver • システムメトリックスはGCPのコンソール • Theフルマネージド 25
- 26. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. なぜDatastore • GCP上でRDBSを利用するとするとCloudSQLが選択肢に入る ⁃ GCE上にMySQLを立てるとかもできるけど趣旨に反する • ただCloudSQLが思った以上にパフォーマンスが出ない ⁃ 途中でパフォーマンス改善はあったものの • PokemonGoでの実績 • 郷に入っては郷に従え 26
- 27. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. 開発体制 27
- 28. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. チーム構成 • 大まかな機能単位でチーム構成 ⁃ 一人チームもあれば２〜３人チームもあり、最大でも１チーム５名程 度 ⁃ 総開発人員数は２５名程 • Microserviceでの開発を行っており、１機能１コンポーネント１リポジト リ１サービスという形の開発を行っているので開発そのものは複数のチー ムに分かれて実施可能 28
- 29. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. チームを細切れにしてもワークした理由 • チームメンバーが多く、かつチームが細切れだと空中分解しかねない • そうさせないために ⁃ 各チームのリードエンジニア陣をあつめたDSを実施 ⁃ 共通基盤チームを用意しライブラリや開発作法ほ基本統一 ⁃ JSON Schemaを活用しI/Fの可視化とValidationで利用 ⁃ Documentのフォーマットを決めDocument Firstでの開発 29
- 30. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. GAE+microservice • なにげに相性が良い • １コンポーネントがGAEの１サービスとなり、他コンポーネントに基本影 響されずに管理が可能 ⁃ オンプレなどではどのサーバにどのコンポーネントをdeployするか ⁃ LBやProxyの設定をどのようにするかの管理が複雑… • ただし1プロジェクトあたりの利用可能Service数が20なので要注意 ⁃ 相談すれば上限突破してくれるかも ⁃ 現時点で我々は26サービスを利用している 30
- 31. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. コスト 31
- 32. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. コスト is 何？ • 一番イメージしやすいのは ⁃ サーバ購入費 ⁃ データセンター関連の諸費用 • 忘れがちなのが人件費 • なかなか思いつかないのはコミュニケーションコスト 32
- 33. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. コスト(サーバ・DC) • 当然必要な台数を用意する必要があるので初期費用がかかります • パブリッククラウドって一般的にはこういう初期費用をかけずに利用でき るのがウリだったりしますよね • オンプレでサーバを用意する場合、例えば他サービスで余ったサーバを回 してもらう、減価償却切れのサーバを回してもらうとすれば初期費用はお さえらえれるかもしれない • DCのコスト（ラック・電源・ネットワーク・etc）はどうしてもかかって いく。規模によってはボリュームディスカウント効くけど ⁃ 前職ではサービス規模に対して結構な額になったり 33
- 34. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. コスト(人件費) • 何かを安定的に維持するには人が必要 • サービス開発以外にInfraをお守りする必要がありそこで働く人のコスト が発生する • 規模が大きくなれば必要とする人も多く必要になってくる 34
- 35. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. コスト(コミュニケーション) • 情報共有はとても大切 ⁃ 大規模開発になりチームが細切れだったりチーム人数が多ければ特に • とても大切だし必要なんだけど関係者が膨れ上がるとそれはコストになる • 営業・企画・デザイナー・エンジニア・QA・法務・などなど関係者が膨 らんでくるともう大変 • 密室ではなくシンプルに出来るところはする 35
- 36. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. まとめ 36
- 37. Copyright (C) 2013 DeNA Co.,Ltd. All Rights Reserved. まとめ • 既存の技術や運用にとらわれない事 • モノづくりに集中出来る環境を如何に用意できるか • 今回の例は実はかなりチャレンジング ⁃ もっとスモールスタートしてもいい ⁃ つまり既存のシステム・サービスの一部から始めるもよい • 新しい取り組みに失敗はつきもの ⁃ 失敗を許容しよう、そこから学ぼう • 振り返ろう ⁃ やって満足しない。課題はいっぱいある • 一番大切なことは ⁃ めいいっぱい楽しむこと。ワクワクしよう！ 37