スタートアップがスマホアプリゲームをAzureのサービスで運用した話
•Als PPTX, PDF herunterladen•
8 gefällt mir•1,941 views
Japan Azure User Group (JAZUG)6周年セッション
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (12)
Ähnlich wie スタートアップがスマホアプリゲームをAzureのサービスで運用した話
Ähnlich wie スタートアップがスマホアプリゲームをAzureのサービスで運用した話 (20)
スタートアップがスマホアプリゲームをAzureのサービスで運用した話
- 1. スタートアップが スマホアプリゲームを Azureのサービスで 運用した話 Japan Azure User Group (JAZUG) 6周年総会 事例セッション 2016/9/3 Kiyoaki Tsurutani
- 2. 自己紹介 ▪ 鶴谷 清明（つるたに きよあき） ▪ 経歴 ▪ 金融系SI業界 （～2011/9） ▪ 株式会社gloops （2011/10～2014/6） ▪ 株式会社クラウドナイン （2014/7～2016/5）←ここでCTOの頃の話 ▪ フリーランス （2016/6～） ▪ https://www.facebook.com/k.tsurutani ▪ kiyoaki.tsurutani@gmail.com
- 3. クラウドナインについて ▪ 株式会社クラウドナイン ▪ https://cloud9-plus.com/ ▪ スマートフォンゲームアプリ開発・運営をしている会社 ▪ 2014/7に設立 ▪ 2015/11に「ワールドギミック」というゲームをリリース ▪ https://site.world-gimmick.com/ ▪ 2016/4 クルーズ株式会社が出資
- 4. 今回いただいた「お題」 内容としては ▪ 各ソリューションのご紹介(公にできる範囲で大丈夫です。アーキテクチャが分かる程度にテクノ ロジー寄りにお話しいただけますと幸いです) ▪ Azureを使い始めた理由 ▪ Azure の良かったところ、苦労したところ ▪ Azure にこんな機能がほしい、期待するところ をそれぞれお話しいただけると宜しいかと思っております。
- 6. ワールドギミックについて
- 7. ワールドギミックについて
- 10. CTOって？ ▪ https://ja.wikipedia.org/wiki/最高技術責任者 ▪ 短期間の（戦略的な）技術的方向性決定 ▪ 研究開発のビジネス的な監督 ▪ 企業内でのソフトウェアの利用 ▪ 技術的な意思決定をする人
- 12. Azureを使い始めた理由 ▪ クラウドナインの創立時、エンジニア5人全員C#er ▪ → 言語はC#に決定 ▪ ちなみにフレームワークはクライアント側はUnityで、サーバー側はASP.NET MVCとWeb APIに ▪ 言語がC#ならスキーマからモデル自動生成できるし、Visual Studioのスキーマ比較便利だ し、SQL Server使いたい ▪ → DBはSQL Serverに決定
- 13. Azureを使い始めた理由 ▪ WebアプリケーションサーバーはAzure Websites(現WebApps)の方が管理が楽だった ▪ インフラエンジニアもいなかった ▪ → Azure Websites使いたい
- 14. Azureを使い始めた理由 ▪ VMに構築するより、SQL Databaseの方が管理が楽だった ▪ DBAやインフラエンジニアもいなかった ▪ クエリストア等のSQL Server 2016の便利機能が、早めにSQL Databaseで使えるように なった ▪ → SQL Database使いたい
- 15. Azureを使い始めた理由 ▪ 性能上限が満たせれば、VMではなくサービスのみで構築したい ▪ WebsitesからSQL Databaseへのquery/secを測定してみた ▪ https://github.com/kiyoaki/AzurePerformanceTesting ※2015/3測定（現在はもっと大きいインスタンスがあるし性能上限高いと思われる） P3(800DTU) Entity Framework 2015-03-11 12:21:09 PID[3920] Information 10000 rows written in 11046ms 2015-03-11 12:21:15 PID[3920] Information 10000 rows read in 5221ms P3(800DTU) Dapper 2015-03-11 12:20:24 PID[3920] Information 10000 rows written in 6216ms 2015-03-11 12:20:26 PID[3920] Information 10000 rows read in 2112ms P3(800DTU) Raw ADO.NET 2015-03-11 12:21:41 PID[3920] Information 10000 rows written in 4968ms 2015-03-11 12:21:44 PID[3920] Information 10000 rows read in 2137ms
- 16. Azureを使い始めた理由 ▪ JMeterで負荷テストも行った結果、ブラウザゲームと違ってアプリなのでAPIのアクセス頻度は 少なめだし、一時的に使うデータをRedisに持っていけば大丈夫だろうと判断 ▪ ちなみに当時、負荷テストを行ってボトルネックになるのはDBのMax concurrent workers だった ▪ https://azure.microsoft.com/ja-jp/documentation/articles/sql-database- service-tiers/
- 17. Azureを使い始めた理由 ▪ 創立時のエンジニアのスキル ▪ 過去の資産が無いスタートアップの1本目のプロダクトという、オンプレみたいな超高価なモノ以 外なんでも選べる状況 ▪ ネットワークやOSやミドルウェアの管理をしたくない！
- 19. 良かったところ（お気に入りの機能） Azure SQL Database Query Performance Insight https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-query-performance/ SQL Database Advisor https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-advisor-portal/
- 21. 良かったところ（お気に入りの機能） Application Insights の設定: 依存関係の追跡 https://azure.microsoft.com/ja-jp/documentation/articles/app-insights-asp-net-dependencies/
- 22. 良かったところ（お気に入りの機能） ▪ Application Insights: 言語、プラットフォーム、統合 ▪ https://azure.microsoft.com/ja-jp/documentation/articles/app-insights- platforms/ ▪ 色々な言語で使えるし、VMでもオンプレでも使える ▪ アプリケーションのメトリクス収集は、SDKを組み込んで関数呼び出したり ▪ サーバーのメトリクス収集は、エージェントをインストール
- 23. 良かったところ（全体的に） ▪ パフォーマンス、プロビジョニング、スケーリング、フェイルオーバー、モニタリング、アラート等オペ レーション問題なし ▪ パフォーマンスについては、BOTによって短時間に40万アカウントほどアカウント作成＆チュートリアルの ガチャを回された時があったが、一部のDatabaseのCPU使用率が60%になる程度で耐えた ▪ BOTアカウントを自動で検知して弾くロジックを実装して、BOTは去った ▪ ○イアンティックも大変だっただろうと察する ▪ プロビジョニングやアプリケーションのデプロイ簡単 ▪ Visual StudioやSQL Server Management Studioによく統合されている
- 24. 苦労したところ ▪ どのPaaSでも同様ですけど、データストアへの接続は、ごくたまに瞬断する ▪ DBはEntityFrameworkのSqlAzureExecutionStrategyを使えばOK ▪ https://msdn.microsoft.com/ja- jp/library/system.data.entity.sqlserver.sqlazureexecutionstrategy(v=vs.113).aspx ▪ RedisはStackExchange.Redisの設定をabortConnect=falseにしておけばOK ▪ https://azure.microsoft.com/ja-jp/documentation/articles/cache-dotnet-how-to-use- azure-redis-cache/ ▪ 2014年当時、AWSじゃなくて大丈夫？と周囲が不安がる
- 29. オペレーションしやすい環境
- 30. オペレーションしやすい環境 ▪ プロビジョニング ▪ スケーリング ▪ フェイルオーバー ▪ モニタリング ▪ アラート ▪ etc
- 31. ビジネスに適した開発プロセス
- 32. ビジネスに適した開発プロセス ▪ リリース計画 ▪ テスト計画 ▪ GitHubフロー ▪ CI ▪ デプロイ方法 ▪ etc
- 35. 例えば、こういうのはお任せしたい ▪ CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来 ▪ http://hb.matsumoto-r.jp/entry/2016/07/23/000533
- 38. 6年間、サービスが継続するか
- 41. Welcome 幸せなロックイン
- 42. ご清聴ありがとうございました
Hinweis der Redaktion
- 私がスタートアップで、スマホアプリゲームを、Azureのサービスで運用したときの話をします。よろしくお願いします。
- まずは自己紹介です。鶴谷清明と申します。金融系SI業界でエンジニア人生をスタートして、5年前に今日の会場であるgloopsへ入社しました。gloopsでブラウザゲームを色々作って運用して、2年前に独立してクラウドナインという会社を作りました。今日話すのは、そこでCTOをしていた頃の話です。ちなみに現在はフリーランスになっています。何か良い案件があればメールしてください。
- クラウドナインについてですが、スマートフォンゲームアプリを開発、運営している会社です。去年「ワールドギミック」というゲームをリリースしました。
- 今回いただいた、このセッションの「お題」はこんな感じだったので、これに沿ってお話しします。
- ではまず、ソリューション、というか開発したゲームの紹介です。
- サーバー構成や開発プロセスの紹介に入る前にまずはゲーム自体を紹介します。 これは3人でマルチプレイ中の動画です。右が味方で左が敵です。この動画の敵は結構強くて、ガーディアンリンクやタイムキーパーっていう手強いギミックが発動してます。 最初に攻撃した味方はリンク破壊スキルを持っているので、リンクの中心の敵を攻撃してリンクを破壊しました。 次に攻撃した味方はタイムキーパー破壊のスキルを持っているので、タイムキーパーを1撃で破壊しました。 キャラクターはみんなシールドが張っていて、シールドを壊さないとコンボ数も必殺技ゲージも溜まらないのですが シールドブレイクのスキルを持っているキャラが味方にいるので楽にブレイクしていってます。 こんな感じで攻撃していくと、黄色い矢印のゲージが溜まっていって、バーストアタックという必殺技みたいなものが使えるようになります。 バーストアタックごとにゲージ回復値があって、連続してバーストアタックを決めていくと、バーストチェインというタップ連打でダメージを与える攻撃ができるようになります。 たくさんチェインするほど長い時間タップ連打できて、マルチプレイの場合はタップ数が合計されてダメージに反映されます。 これがバーストチェインです。 動画を全部見ていると21分もかかるので、ゲームの紹介はこのぐらいにしておいて、次のスライドへいきます。
- サーバー構成はこんな感じです。クライアント側はUnityで、サーバー側はASP.NET Web APIです。 管理画面にはASP.NET MVCを使っていたりもします。 図の右の方、データストアには、SQL DatabaseとRedis Cacheを使っていて、監視やアラートはApplication Insightsを使っています。 図の上の方、AssetBundleというゲームで使う画像や音源ファイル等を圧縮したものを、JenkinsでビルドしてStorageにアップロードしてAkamaiのCDN経由で提供しています。 図の下の方、マルチプレイのコマンド同期にPhotonクラウドを使っています。 図へ入れ忘れましたが、ユーザーの行動分析などにBigQueryを使っていたり、メール送信にSendGridを使っていたりもします。
- 前のスライドの構成が、開発環境、テスト環境、申請環境、本番環境の4つあって、この流れで開発を行っています。 だいたい開発に着手したバージョンが本番環境へリリースされるまでの期間は1.5ヶ月程度です。 開発環境だけはAssetBundleをAkamaiのCDNを通していない、とか、本番環境だけはデプロイメントスロット経由でデプロイしていたりスケールが違うっていうぐらいで、各環境ほぼ完全に同じ構成が用意されてます。
- 次はAzureを使い始めた理由についてお話したいと思います。
- が、その前に、CTOってどんな人なのかっていうと、基本的に、技術的な意思決定をする人のことです。
- で、自分が意思決定する時に何を判断基準にしているかというと、主に3つあって、やりたいことを実現するまでの「速さ」と「品質」と、その実現までにかかる、実現してから維持するのにかかるコストの「安さ」です。 個人的には「速さ」を一番重視していて、品質もすごく大事ですが、最初に捨てるのは「安さ」です。 これはビジネスの特性によって優先順位が変わってくると思います。 たとえば、人月で利益を上げるビジネスなら「速さ」があまり要らなかったりとか、競合が多くて成熟した市場だと、「安さ」と「品質」つまり効率の勝負になっていたりすると思います。
- Azureを使い始めた理由に話を戻すと、クラウドナインを創立した時に集まってくれたエンジニアは全員C#が得意なエンジニアでした。なので、迷わずC#を使うことにしました。リレーショナルデータベースは、色々と開発環境に統合されていて使い勝手の良いSQL Serverを使うことにしました。ここまでは即決でした。
- Webアプリケーション・サーバーは開発環境でAzure Websitesを使っていて、プロビジョニングやデプロイやモニタリングや、オペレーションに関することが何もかも自分でVMで構築するより楽だったので 本番でもこれを使いたいなーと思っていました。
- Databaseについても同様で、管理が楽だし、開発中にクエリストアというSQL Serverだと2016の新機能が早めにSQL Databaseで使えるようになったりして、本番でもこれを使いたいなーと思っていました。
- 性能上限が満たせれば、本番でも使えるので、測定してみようと思いましたが、PaaSなのでOSにログインする系の性能測定ツールは使えるはずもなく、エンドポイントに対してガンガンクエリを発行するだけのツールを作って測定してみたりもしました。
- また、リリース前にゲームのAPIに対する負荷テストも行って、機能ごとのDatabaseの分割を増やすように変更したりもしましたが、めちゃくちゃヒットしないかぎり大丈夫そうだし、めちゃくちゃヒットしたらその時に考えようということで、開発やテスト環境と同様に、本番もAzureのサービスばかりのインフラで構成することに決めました。
- Azureを使い始めた理由を突き詰めると、創立時のエンジニアがみんなC#が得意なエンジニアばかりだったこととか、過去の資産がないスタートアップの1本目のプロダクトっていう、なんでも選べる状況だったりとか、ネットワークやOSやミドルウェアの管理をしたくない！という強い想いとか、こんな感じの理由でAzureのサービスをインフラとして選択したように思います。
- では、続きましてAzureの良かったところ、苦労したところについて。
- いくつか良い感じだなと思った機能を紹介します。 SQL Databaseのアドバイザー機能なんですが、これはリソースを多く消費しているクエリを確認できたり、不足しているインデックスや不要なインデックスを教えてくれたり、自動でインデックスを作成する機能を有効化しておけば勝手にインデックス作成してくれたり、パラメーター化すべきクエリを教えてくれたりする機能です。 ただ、ワールドギミックの開発では、エンジニアがみんな、自分が実装したAPIがDBへ発行するクエリの実行プランを実装中に確認したりしていたので、SQL Databaseのパフォーマンスアドバイザーのお世話になることはほとんど無かったのですが、場合によっては結構役立つのではないかなと思います。
- 次に、Application Insightsというのは、サーバーやアプリケーションのモニタリングツールなんですが、プロアクティブ検出という機械学習で勝手に異常値検知してアラートしてくれる機能があります。監視項目の異常値検知はナイスな機械学習の応用分野だなと想いました。
- あと開発環境ではApplication Insightsの依存関係モジュールを有効化しておくと、アプリケーション・サーバーの依存関係にあるクライアントやサーバーに対するアクセス、例えばHTTPアクセスやDBアクセスの平均レスポンスタイムとか、アクセス数とか、エラー率とか、色々と自動で収集してくれます。本番環境では依存関係モジュールを有効化しておくと通信量が増えすぎて微妙だったんですが、今はテレメトリの送信を間引けるようになっているかも？しれません。 ちなみに、ワールドギミックではAPIリクエストのテレメトリ送信をOwinのMiddlewareで実装していたのですが、独自で送信数を間引くロジックを実装してアプリケーション・サーバーの通信帯域を節約していました。
- ちなみに、Application Insightsは、まだプレビューですが、色々な言語や環境で使えます
- その他、良かったところとしては、アプリケーションエンジニアしかいない状況でもオペレーションに関して全く問題なかったというところと パフォーマンスについては、BOTによって短時間に40万アカウントほどアカウント作成からチュートリアルガチャ回すところまで、アクセスされた時があったんですが、ユーザーアカウントに関するテーブルが含まれるデータベースと、ユーザーの所持キャラに関するテーブルが含まれるデータベースのCPU使用率が高まった程度で耐えてました。 BOTアカウントを自動検知して弾くロジックを実装してBOTは去りましたが、○ケモンGoのBOTはDDoSレベルだったと思うので大変だっただろうなと思います。 あと、プロビジョニングやアプリケーションのデプロイが簡単なところとか、開発環境にAzureのサービスがよく統合されているし、されていっていたところが良い感じでした。
- 苦労したところというのは、特になかったんですが、サービスの低層部分、ホストOSの更新とか、各種ドライバの更新とか、フェイルオーバーとかによって、たまーに内部ネットワークが短い時間、切断したりします。 データストアへの再接続処理は、よく使われるライブラリには実装されていて、それを使うだけで大丈夫です。 あと、2014年当時は、AWSじゃなくて大丈夫か？と周囲の人に不安がられました。
- 最後に、Azureにこんな機能ほしいと期待するところ
- というか、アプリケーションエンジニアはクラウドプラットフォームに何を求めるのか、について私の考えをお話します。
- Webサービスの開発において、速さと品質を上げるために必要なこととして
- オペレーションしやすい環境とか、ビジネスに適した、よく整備された開発プロセスとかがあると思います。
- オペレーションしやすい環境、これは
- プロビジョニング、スケーリングがしやすかったり、フェイルオーバーを勝手にしてくれたり、モニタリングやアラートが設定しやすかったりする環境とかのことだと思っていて
- ビジネスに適した開発プロセス、これは
- リリース計画、テスト計画、主にその反復期間とかが適切で、そのリリースサイクルや必要な品質に合わせて考えられたブランチの使い方とか、各環境へ適切な頻度で勝手にまたは任意でデプロイされる環境とかのことだと思っていて
- アプリケーションエンジニアがクラウドプラットフォーマーに求めるのは、オペレーションしやすい環境だと思います。
- ハードウェア、ネットワーク、OS、ミドルウェアの面倒を見て欲しいし
- 先月末に、はてなブックマークのホットエントリーになっていたブログ記事ですが、こういうOSのチューニングなどは全て任せたいと思います。
- ちなみに、スタートアップはVMで運用すれば、各クラウドプラットフォームのスタートアップ支援制度で無料枠を2年ぐらいずつ利用して、プラットフォームを渡り歩くことができますけど
- 6年間、VMを管理、つまりOSやミドルウェアを管理してまで、無料枠を使い続けたいか
- そもそも6年間自分たちがスタートアップで開発するサービスが継続するのか、というのもあると思います。
- VMで2年、本番環境を運用してしまうと、オペレーションや開発やソースコードに、PaaSへ移行できない何かが作りこまれることもあります。現在フリーランスで入っている企業も本当はPaaSへ移行したいけど難しいという、そんな状況だったりします。
- ハードウェア、ネットワーク、OS、ミドルウェア クラウドプラットフォームに任せて楽になりたい
- 私としては、クラウドのインフラについては「Welcome 幸せなロックイン」と思っています。
- ご清聴ありがとうございました