Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie AWS Case Study @ JAWS-UG Sapporo
Ähnlich wie AWS Case Study @ JAWS-UG Sapporo (20)
AWS Case Study @ JAWS-UG Sapporo
- 2. 自己紹介 出身： アメリカ（フロリダ州、オーランド） 仕事： ゲーム開発、3Dエンジン開発、システム開発、CEO 言語： C++14、PHP、TypeScript、アセンブラ（x86/x64/ARM) 趣味： デモシーン（Tokyo Demo Festの主催者）、チップチューン、VR、ビール 好きなAWSサービス： EC2 5歳から TI-99/4a のBASIC言語でプログラミングに興味が湧いた 16歳で高校卒業、University of Central Florida大学に入学 1993年 大学インターンでVR開発を始めて、「Virtopia」をSIGGRAPH 1994で公開 1997年 Nintendo 64のエミュレータを作成、ゲーム業界に入る 2000年 日本（東京）へ移動 2005年 沖縄へ移動 2012年 株式会社コールド・フュージョンを設立 → アメリカの Animoto社 と契約でAWSを初利用 2013年 札幌へ移動 2017年 東京ゲームショウに出展、自社オリジナルのスマホゲーム(iOS/Android)を配信 テッダー マイケル (40歳)
- 3. 2012年12月 アメリカの Animoto社 と契約 ー ユーザーの写真のみで、音楽のタイミングに合わせた映像に変えるサービス ー AWSのGPUインスタンスでリアルタイムレンダリングを行い、 ユーザーに出力映像を直接ストリーミング ー ピークの時はG2インスタンス150台程度、S3も大量映像保存 ー 約2週間ごとに新しくエンジンをEC2にデプロイ 2015年3月 アメリカの Sanzaru Games社 と契約 ー Oculus Riftで「VR Sports Challenge」の開発を手伝い 2016年5月 独立して自社ゲームエンジン（3Dレンダリング、ネットワーク等）の開発に集中 2017年6月 「クリスタル・クラッシュ」のゲーム開発を開始 ー クライアント側のゲーム機能とサーバーへのhttps API通信 [C++14] ー サーバー側のアカウント管理(ログイン、ユーザーデータ取得) https API [PHP] ー ロビーサーバーで2人のプレイヤーのリアルタイムゲーム通信 [C++14] 2017年9月 「クリスタル・クラッシュ」を東京ゲームショウ出展と同時にアプリ配信 開発 デザイナ ー 音楽/SFX
- 4. 1) 「coldfusion.co.jp」と「tokyodemofest.jp」 のWeb サーバー (Apache) 2) Mail サーバー (postfix / dovecot / spamassassin / mailman) 3) SQL サーバー (mysql) 4) IRC ボット (eggdrop) 5) git / svn リポジトリ (ssh) 6) ビルドサーバー (buildbot) 7) Crystal Clashロビー/ゲームサーバー AWS事例紹介 ー 構造
- 5. 1) 「coldfusion.co.jp」と「tokyodemofest.jp」 のWeb サーバー (Apache) 2) Mail サーバー (postfix / dovecot / spamassassin / mailman) 3) SQL サーバー (mysql) 4) IRC ボット (eggdrop) 5) git / svn リポジトリ (ssh) 6) ビルドサーバー (buildbot) 7) Crystal Clashロビー/ゲームサーバー AWS事例紹介 ー 構造
- 6. AWS事例紹介 ー 構造 CPU平均 1~4%、ピーク時約 20%、1GB swap プレイヤー368人の中、6524ゲーム行う（1時間ごとに約13ゲーム） (※ CPU 100%使用の2つはコンパイル中)
- 7. AWS事例紹介 ー ビルドサーバー Animoto社で利用した継続的インテグレーションと デプロイの快適さを自社システム開発に取り込んで 、EC2にbuildbot master(サーバー)を設定。
- 8. AWS事例紹介 ー ビルドサーバー Animoto社で利用した継続的インテグレーションと デプロイの快適さを自社システム開発に取り込んで 、EC2にbuildbot master(サーバー)を設定。
- 9. AWS事例紹介 ー ビルドサーバー Animoto社で利用した継続的インテグレーションと デプロイの快適さを自社システム開発に取り込んで 、EC2にbuildbot master(サーバー)を設定。 ➤ gitリポジトリへのコミットとプッシュ ➤ buildbot masterはgitリポの更新を判断、 iMacのbuildbot workerにビルド実行 ➤ 同時に5つのプラットフォームのビルドが行う ➤ ビルド完了したら、テストが行う ➤ テストOKの場合は全ての実行ファイルをDropboxへコピー buildbot worker(クライアント)は社内のiMacで実際コ ンパイルとテストが行う：
- 10. AWS事例紹介 ー ビルドサーバー Animoto社で利用した継続的インテグレーションと デプロイの快適さを自社システム開発に取り込んで 、EC2にbuildbot master(サーバー)を設定。 ➤ gitリポジトリへのコミットとプッシュ ➤ buildbot masterはgitリポの更新を判断、 iMacのbuildbot workerにビルド実行 ➤ 同時に5つのプラットフォームのビルドが行う ➤ ビルド完了したら、テストが行う ➤ テストOKの場合は全ての実行ファイルをDropboxへコピー (希望： EC2でmacOS使いたい！) buildbot worker(クライアント)は社内のiMacで実際コ ンパイルとテストが行う：
- 11. AWS事例紹介 ー ビルドサーバー プラットフォームごとのビルド情報（コンパイラの メッセージ、ログなど）はEC2のbuildbot masterに 転送され、ブラウザで簡単に見れる。
- 12. AWS事例紹介 ー ビルドサーバー プラットフォームごとのビルド情報（コンパイラの メッセージ、ログなど）はEC2のbuildbot masterに 転送され、ブラウザで簡単に見れる。 全てのビルドステップが成功してる場合は青く表示、 エラーが起きた場合（コンパイルエラー、テスト失敗 など）は赤く表示。
- 13. AWS事例紹介 ー デプロイ buildbot master に fastlane ( http://github.com/fastlane )を 取り込んで、ボタン1つで iTunes Connect と Google Play へ直接ビルドとメタデータをアップロード。
- 14. AWS事例紹介 ー デプロイ buildbot master に fastlane ( http://github.com/fastlane )を 取り込んで、ボタン1つで iTunes Connect と Google Play へ直接ビルドとメタデータをアップロード。 10分〜15分程度で新しいビルドは配信され、社員チーム の端末で TestFlight と Google Play からダウンロードして 、確認できる。
- 15. AWS事例紹介 ー デプロイ buildbot master に fastlane ( http://github.com/fastlane )を 取り込んで、ボタン1つで iTunes Connect と Google Play へ直接ビルドとメタデータをアップロード。 10分〜15分程度で新しいビルドは配信され、社員チーム の端末で TestFlight と Google Play からダウンロードして 、確認できる。 buildbot と fastlane のお陰で「クリスタル・クラッシュ」 開発中のチームフィードバックがかなり早く取れて、 約3ヶ月で完成ができた。