自己紹介
CEDEC+KYUSHU講演履歴
2018 大規模モバイルオンラインゲームを支えるソフトウェアアーキテクチャ開発とその使用例
2019 大規模モバイルオンラインゲームにおける安定運用のための仕組み
2020 ソースコードレビューのススメ
2021 個人情報の保護となりすまし対策 ~KLabのゲーム内通貨の払戻のシステムの場合~
2022 表も裏もすべて見せます! KLab謹製大規模オンラインゲームの リアルタイムチャットマイクロサービス
2023 大規模モバイルオンラインゲーム開発における チーム組成とワークフロー最適化
山田 雅人
KLab 株式会社
サーバリーダー
KLabGames事業本部
エンジニアリング本部 技術広報グループ
自己紹介
● 2016年インフラエンジニアとして入社
● オンプレミス/AWSを用いたインフラの構築・運用を担当
● 現在はモバイルオンラインゲーム用インフラの新規開発に従事
髙橋 慶充
KLab 株式会社
インフラエンジニア
エンジニアリング本部 インフラグループ
4
KLabについて
5
ミッション:「世界と自分をワクワクさせろ」
ビジョン:「エンターテインメントで、世界中のユーザーをひとつにつなげる」
社会に感動と喜びを提供できるような、サービス・技術を創造しています。
設立 2000年8月1日
資本金 61億8134万円(2024年9月末現在)
株式公開市場 東京証券取引所・プライム市場(3656)
代表者
代表取締役社長CEO 森田 英克
代表取締役副会長 五十嵐洋介
所在地
本社(東京都港区、六本木ヒルズ森タワー)
大阪事業所、福岡事業所、仙台事業所
主要関連会社
可来软件开发(上海)有限公司 (KLab China Inc.)
株式会社グローバルギア
従業員数 正社員 415名(2024年9月末現在)
主力:ゲーム事業
アニメ、コミック、ゲームなど、
世界中で人気の高いIPを原作とした
モバイルオンラインゲームを
国内外に展開。
現在155の国と地域で配信
その他:
スマートフォン関連のアプリケーション、
サービス及びサーバインフラの企画、
開発、提供、新規事業開拓など
会社紹介:KLab(クラブ)株式会社
6
コーポレートサイト紹介
KLab 検索
本日のアジェンダ
1. はじめに
2. 開発環境の用途
3. 開発用Web APIサーバへのニーズ
4. 最新システムの紹介
5. 最新システムとニーズの答え合わせ
6. まとめ
本日のアジェンダ
1. はじめに
2. 開発環境の用途
3. 開発用Web APIサーバへのニーズ
4. 最新システムの紹介
5. 最新システムとニーズの答え合わせ
6. まとめ
規模感の話
• 人数:100人未満
• 開発用サーバ環境数:250環境
• 開発用サーバ費用:75,000円/月
大体こんな感じでやってます。
はじめに
• サーバ数すごく多い
• その割には費用安い
と思いませんか?
サーバ数多くない?
ざっくり構成図
リバースプロキシ:nginx
アプリケーションサーバ:uWSGI
Webサーバ
RDBサーバ
KVSサーバ
MySQL
Redis
リバースプロキシ:nginx
アプリケーションサーバ:uWSGI
ざっくり構成図
Webサーバ
RDBサーバ
KVSサーバ
250用意する!
MySQL
Redis
250環境の内訳
• 共用:200環境
• 個人用:50環境
共用:200環境
• 毎日ROMのビルドと一緒にサーバのデプロイ
• 一日最低2回(5-10回の時もある)
• ビルド単位でサーバは独立
ROMに対してサーバは1対1
惜しみなくサーバを占有します
個人:50環境
• 占有してコーディングやコンテンツ作り用
• 作業中に他人の成果確認用
• 並行して別の作業をしたい時用
なんとなく今の環境使いたくない程度で
新しいサーバが使える気軽さ
よくあるサーバインフラとの比較
共用サーバ(10台ぐらい)
– VM/EKS/ECSを使っていくつか環境を用意
コンテナ on ローカルマシン
– Dockerなどでローカルマシンでコンテナを動かす
共用サーバ
メリット
• ネットワーク越しのサポートがしやすい
• 非エンジニアにも使いやすい
デメリット
• 個人の作業が他人に影響しやすい
• 気軽に環境を量産できない
共用サーバ
メリット
• ネットワーク越しのサポートがしやすい
• 非エンジニアにも使いやすい
デメリット
• 個人の作業が他人に影響しやすい
• 気軽に環境を量産できない
ネットワーク越しのサポートがしやすい
壊れました!
ネットワーク越しのサポートがしやすい
SSHで
サーバ見てみよう 壊れました!
ネットワーク越しのサポートがしやすい
SSHで
サーバ見てみよう 壊れました!
気軽に確認
共用サーバ
メリット
• ネットワーク越しのサポートがしやすい
• 非エンジニアにも使いやすい
デメリット
• 個人の作業が他人に影響しやすい
• 気軽に環境を量産できない
非エンジニアにも使いやすい
新しいサーバ
用意してください!
非エンジニアにも使いやすい
新しいサーバ
用意してください!
新しく起動!
非エンジニアにも使いやすい
新しいサーバ
用意してください!
新しく起動!
つかえるように
なりました
非エンジニアにも使いやすい
新しいサーバ
用意してください!
新しく起動!
つかえるように
なりました
難易度低い
共用サーバ
メリット
• ネットワーク越しのサポートがしやすい
• 非エンジニアにも使いやすい
デメリット
• 個人の作業が他人に影響しやすい
• 気軽に環境を量産できない
個人の作業が他人に影響しやすい
あ、壊しちゃった
個人の作業が他人に影響しやすい
あ、壊しちゃった
え!なんか壊れた!
個人の作業が他人に影響しやすい
あ、壊しちゃった
え!なんか壊れた!
巻き込み事故
デプロイしまーす
個人の作業が他人に影響しやすい
デプロイしまーす
作業待ち
ヒマだ・・・
個人の作業が他人に影響しやすい
作業待ち
ヒマだ・・・
デプロイしまーす
個人の作業が他人に影響しやすい
他人待ちで
待機発生!
共用サーバ
メリット
• ネットワーク越しのサポートがしやすい
• 非エンジニアにも使いやすい
デメリット
• 個人の作業が他人に影響しやすい
• 気軽に環境を量産できない
気軽に環境を量産できない
サーバ増やさないと
待ち時間が多いです!
気軽に環境を量産できない
サーバ増やさないと
待ち時間が多いです!
でも予算が・・・
気軽に環境を量産できない
サーバ増やさないと
待ち時間が多いです!
費用の承認
明後日になりそう
気軽に環境を量産できない
サーバ増やさないと
待ち時間が多いです!
費用の承認
明後日になりそう
今すぐ
増やしたいのに
気軽に環境を量産できない
サーバ増やさないと
待ち時間が多いです!
気軽に環境を量産できない
サーバ増やさないと
待ち時間が多いです!
今忙しいから
後にして!
気軽に環境を量産できない
サーバ増やさないと
待ち時間が多いです!
今忙しいから
後にして!
今すぐ
増やしたいのに
共用サーバ
メリット
• ネットワーク越しのサポートがしやすい
• 非エンジニアにも使いやすい
デメリット
• 個人の作業が他人に影響しやすい
• 気軽に環境を量産できない
コンテナ on ローカルマシン
メリット
• 個人の作業が他人に影響しにくい
• 費用が安い
デメリット
• 非エンジニアには操作が難しい
• ネットワーク越しのサポートがしづらい
コンテナ on ローカルマシン
メリット
• 個人の作業が他人に影響しにくい
• 費用が安い
デメリット
• 非エンジニアには操作が難しい
• ネットワーク越しのサポートがしづらい
個人の作業が他人に影響しにくい
あ、壊しちゃった
個人の作業が他人に影響しにくい
あ、壊しちゃった
大丈夫作業続けられる
個人の作業が他人に影響しにくい
あ、壊しちゃった
大丈夫作業続けられる
巻き込み事故
起こさない
デプロイしまーす
個人の作業が他人に影響しにくい
デプロイしまーす
大丈夫作業続けられる
個人の作業が他人に影響しにくい
デプロイしまーす
大丈夫作業続けられる
他人待ちで
作業
止まらない!
個人の作業が他人に影響しにくい
コンテナ on ローカルマシン
メリット
• 個人の作業が他人に影響しにくい
• 費用が安い
デメリット
• 非エンジニアには操作が難しい
• ネットワーク越しのサポートがしづらい
→マシン代とDockerの費用ぐらい
※Docker Desktop不要の人もいる
費用が安い
💰9 💰9
・・・・・
※
→マシン代とDockerの費用ぐらい
※Docker Desktop不要の人もいる
費用が安い
💰9 💰9
・・・・・
※
極端に費用が
上がらない
コンテナ on ローカルマシン
メリット
• 個人の作業が他人に影響しにくい
• 費用が安い
デメリット
• 非エンジニアには操作が難しい
• ネットワーク越しのサポートがしづらい
非エンジニアには操作が難しい
is 何?
触ったことない
コンテナ on ローカルマシン
メリット
• 個人の作業が他人に影響しにくい
• 費用が安い
デメリット
• 非エンジニアには操作が難しい
• ネットワーク越しのサポートがしづらい
ネットワーク越しのサポートがしづらい
壊れました!
ネットワーク越しのサポートがしづらい
SSHはムリだから
画面共有かな? 壊れました!
ネットワーク越しのサポートがしづらい
SSHはムリだから
画面共有かな? 壊れました!
ネットワーク
越えるの大変
コンテナ on ローカルマシン
メリット
• 個人の作業が他人に影響しにくい
• 費用が安い
デメリット
• 非エンジニアには操作が難しい
• ネットワーク越しのサポートがしづらい
比較してみると
共用サーバ VS コンテナ on ローカルマシン
一長一短あります。
なのでイイ感じに組み合わせて使うことになりそう
→両方のメリットを兼ね備えたものにしたい
なんとかメリットだけを享受したい
• ネットワーク越しのサポートがしやすい
• 非エンジニアにも使いやすい
• 個人の作業が他人に影響しにくい
• 費用が安い
新しいサーバインフラ
柔軟に大量のサーバインフラを作れるようにして
「早く、安く、使いやすい」を実現し
モバイルオンラインゲーム開発を支えます
適当に250用意してもニーズにあっていなければ
ゲーム開発に貢献できません。
どんなニーズがあったのか
開発環境の用途を整理しつつ
KLabの実例を紹介します。
どんな感じで250用意すればよいか?
本日のアジェンダ
1. はじめに
2. 開発環境の用途
3. 開発用Web APIサーバへのニーズ
4. 最新システムの紹介
5. 最新システムとニーズの答え合わせ
6. まとめ
開発環境の用途を確認する
開発環境なんだから「開発」用ですよね
「開発」ってどういうこと?という確認をします
フローから見ていきます
KLabのゲーム開発フロー
1. プロトタイプ作成
a. 十分にゲームの面白さを検証
2. コア機能開発
a. ゲームのサイクルを確認
3. 量産開発
a. ゲーム全体を作り上げていく
4. 仕上げ
a. ローンチできるようにブラッシュアップする
試行錯誤つよめ
再現性重視
KLabのゲーム開発フロー
1. プロトタイプ作成
a. 十分にゲームの面白さを検証
2. コア機能開発←この辺りで必要になる
a. ゲームのサイクルを確認
3. 量産開発
a. ゲーム全体を作り上げていく
4. 仕上げ
a. ローンチできるようにブラッシュアップする
KLabのゲーム開発フロー
試行錯誤つよめ
再現性重視
このあたりで必要になる
割と試行錯誤強めの段階で
サーバが必要になってくる
試行錯誤とは?
アセット、マスタデータ、プログラム
これは何度も作っては確認して作り直し
より豊かなゲーム体験を追求する
試行錯誤するために大切なこと
「最新版」で「全部入り」の状態にできればOK
とにかく素早く確認できることが大事
再現性とは?
アセット、マスタデータ、プログラム
が一意に決まること
モバイルオンラインゲームの特徴
短期間で新しいコンテンツ/機能を供給する
今週と来週で遊べるコンテンツが異なる
「常に最新版」ではなく
最新のものは今週に見せてしまうと
「ネタバレ」=不具合
→厳密なバージョン管理からの再現性が必要
モバイルオンラインゲームの特徴
短期間で新しいコンテンツ/機能を供給する
今週と来週で遊べるコンテンツが異なる
「常に最新版」ではなく
最新のものは今週に見せてしまうと
「ネタバレ」=不具合
→厳密なバージョン管理からの再現性が必要
数日単位でコンテンツが更新がされる
モバイルオンラインゲームの特徴
短期間で新しいコンテンツ/機能を供給する
→ずっと試行錯誤と再現性が必要とされる
むしろサービス開始してからが本番
→真剣に考える価値がある
フローから考える開発環境の用途
• 試行錯誤
→ゲーム体験を作り上げていく場所
• 再現性
→ローンチ後の再現性を担保する場所
→ものづくりができてテストができる場所といえる
従来の開発環境の考え方
KLabでは従来開発環境とは
本番環境をほぼそのまま再現でき
本番環境と同様の状況で開発を進められる
→再現性を重視していた
最新の開発環境の考え方
KLabでは現在開発環境とは
従来の考え方に加えて
試行錯誤が高速にできることを重視
→試行錯誤も重視
試行錯誤と再現性を別々に追求
試行錯誤できることと再現性は利害衝突しやすい
試行錯誤できることを重視すると再現性が下がる
再現性を重視すると試行錯誤しづらくなる
開発環境の新旧比較
開発環境 開発環境
(作業用)
開発環境
(テスト)
旧 新
日々の作業専用
はやい
シンプルだが
用途によっては
不向き
テスト専用
再現性が高い
作業もテストも
実施
分離
開発環境の新旧比較
開発環境
(作業用)
開発環境
(テスト)
検収環境 本番環境
コンテンツを
素早く作る
作ったものを
順次テスト
最終確認 遊んでもらう
開発環境 検収環境 本番環境
コンテンツ作り
テスト
最終確認 遊んでもらう
旧
新
改めて本日のお題
開発環境:日々の作業用←こちらがメイン
開発環境:テスト用←こちらはおまけ
本日のアジェンダ
1. はじめに
2. 開発環境の用途
3. 開発用Web APIサーバへのニーズ
4. 最新システムの紹介
5. 最新システムとニーズの答え合わせ
6. まとめ
開発用Web APIサーバへのニーズ
1. スケジュール
2. 職種
3. 費用
開発用Web APIサーバへのニーズ
1. スケジュール
2. 職種
3. 費用
並行に開発する
• 複数の機能を平行に開発
• 依存関係も複雑
スケジュール
B機能
A機能
12/6 12/13
11/25
11月終盤あたり
両方修正したい
機能の関係
B機能
A機能
12/6完成
12/13完成
11月終盤あたり
両方修正したい
試行錯誤中のものを何度もマージはつらい
完成済みだけマージしたい
複数のものを一つのサーバ環境に入れたくない
何度もマージはつらい
B機能
A機能
B機能
A機能
B機能
機能単位で分ける
B機能
A機能
B機能
B機能
12/6完成
12/13完成
短い間隔で成果物を確認したい
平行に進む複数の機能開発の成果物を
短い間隔で確認したい
さらに合流もその後も成果物を毎日確認したい
短い間隔で成果物を確認したい
B機能
A機能
12/6 12/13
11/25
毎日最新
確認したい
毎日最新
確認したい
短い間隔で成果物を確認したい
B機能
A機能
12/6 12/13
11/25
全部合流した全部入り
毎日最新
確認したい
毎日最新
確認したい
毎日最新
確認したい
短い間隔で成果物を確認したい
B機能
A機能
12/6 12/13
11/25
全部合流した全部入り
毎日最新
確認したい
毎日最新
確認したい
毎日最新
確認したい
もっともっと環境が必要
B機能
A機能
B機能
B機能
12/6完成
12/13完成
全部入り
みんなで使う
成果物をデイリーで共有できる
リポジトリの最新状態を毎日展開する
• 最新クライアント
• 最新アセット
• 最新サーバ
都度独立した環境に展開される
→以前のものとの比較ができる
以前の成果物との比較
やっぱり昨日のほうが良かったなとか普通にある
何がどう変わったかというのが実機で体験できる
これもゲーム作りにおいてとても重要
開発用Web APIサーバへのニーズ
1. スケジュール
2. 職種
3. 費用
いろいろしたい VS 安定環境が欲しい
CLエンジニア
プランナー
アーティスト
安定環境が欲しい
プログラムの
試行錯誤したい
SVエンジニア インフラ
エンジニア
破壊的変更をしたい
テスター
いろいろしたい VS 安定環境が欲しい
CLエンジニア
プランナー
アーティスト
安定環境が欲しい
プログラムの
試行錯誤したい
SVエンジニア インフラ
エンジニア
破壊的変更をしたい
テスター
無理!
いろいろしたい VS 安定環境が欲しい
CLエンジニア
プランナー
アーティスト
安定環境が欲しい
プログラムの
試行錯誤したい
SVエンジニア インフラ
エンジニア
破壊的変更をしたい
テスター
分割!
独立した一環境を最低一人一つ確保
機能単位でも職種ごとにも分ける必要がある
ということは個人ごとに分けられたほうが良い
独立した環境というのがとても大切
一つの環境を共用すると
他人の作業待ちや他人の環境破壊の問題がある
非エンジニアが使いやすい
プランナー
アーティスト
簡単に操作したい
テスター
サポートしてほしい
非エンジニアが使いやすい
プランナー
アーティスト
簡単に操作したい
オンラインで
サポート
SVエンジニア
テスター
サポートしてほしい
Web/Chatの
インターフェース
オンラインのサポート
KLabではリモート多めのハイブリッド勤務
トラブルがあった際にどこからでも
トラブルシューティングできる必要がある
スピード感持って作業していると
思わぬところで環境が壊れます
開発環境操作のUI
サーバを自由自在に使うには
新規の起動やデプロイが必要
専門知識がなくても起動やデプロイができる
→わかりやすいUIが必要
わかりやすいといえばWebやChat
Web UI/Chat UI
GithubActions Slack
Bot
Bot
確認待ち状態でも作業を進めたい
プランナー
アーティスト
作業中のものを
ほかの人に見せたい
SVエンジニア
今すぐ見せてほしい
CLエンジニア
見せている間に
別作業したい
確認待ち状態でも作業を進めたい
プランナー
アーティスト
作業中のものを
ほかの人に見せたい
SVエンジニア
確認中は
即時起動できる
別の環境で作業
今すぐ見せてほしい
CLエンジニア
見せている間に
別作業したい
必要な時に短時間で使えるようになる
新しい環境を短時間で作成して
新しい環境ですぐに作業を開始できる
5分では遅すぎたので目標1分以内
いくつもの環境を柔軟に作れる
作業を効率よく進めるためにはとても大事
開発用Web APIサーバへのニーズ
1. スケジュール
2. 職種
3. 費用
費用面
• 一人当たり1000円未満
• 定額使い放題
• 管理コストが安い
一人当たり1000円未満
• Docker Team=$9/月
• t3.micro = $24/月
これ以下に何とかしたい
��
定額使い放題
ある程度の段階は許容
環境増えても一定金額
管理コストが低い
インフラエンジニアがつきっきりだと
インフラ費用以上のコストがかかる
これは本末転倒
ニーズのまとめ
1. スケジュール
– 機能ごとに独立した環境
– 毎日独立した環境に展開
2. 職種
– 作業者個人ごとに独立した環境
– 試行錯誤しやすい環境
– 非エンジニアにもわかりやすいUI
– 独立した環境を素早く提供できること
3. 費用
– 一人当たり数百円程度に抑えられること
– 定額使い放題
– 管理コストが安いこと
1. スケジュール
– 機能ごとに独立した環境
– 毎日独立した環境に展開
2. 職種
– 作業者個人ごとに独立した環境
– 試行錯誤しやすい環境
– 非エンジニアにもわかりやすいUI
– 独立した環境を素早く提供できること
3. 費用
– 一人当たり数百円程度に抑えられること
– 定額使い放題
– 管理コストが安いこと
ニーズのまとめ
ニーズを整理してみた
1. 早い
– 試行錯誤しやすい環境
– 独立した環境を素早く提供できる
2. 安い
– 一人当たり1000円以内に抑えられる
– 定額使い放題
– 管理コストが安い
3. 使いやすい
– 独立した環境
– 非エンジニアにもわかりやすいUI
このあと
具体的にどのようなインフラを作ったか
というお話をします
本日のアジェンダ
1. はじめに
2. 開発環境の用途
3. 開発用Web APIサーバへのニーズ
4. 最新システムの紹介
5. 最新システムとニーズの答え合わせ
6. まとめ
ニーズを実現する新システム
今回のニーズである「早い、安い、使いやすい」を
実現するために新システムを用意しました
新システム
dev-shareの誕生です
dev-shareとは
dev-shareとは
200コンテナ
dev-shareとは
1台で50,000円
(KVS/DB込み)
dev-shareとは
2台で75,000円
(KVS/DB込み)
dev-shareとは
コンテナを使った共用サーバ形式で
コストパフォーマンスと効率を追及したシステム
システム全体構成
システム全体構成
Web APIサーバ
デイリーで朝夕2回
最新バージョンのゲームロジックを展開
開発メンバーの個人環境を提供
EC2の共用サーバが合計2台
システム全体構成
KVS1系統、RDB1系統を
Web APIサーバ2台で共有
KVSはElastiCache
Web APIサーバのメモリを
最大限活用したい
RDBはAurora
本番環境と環境を合わせたい
KVS/RDB
システム全体構成
Web APIサーバ上のオペレーションを
Web UIで自動実行できる
仮想環境作成
ゲームロジック展開等
ワークフロー実行
Github Actions
Web APIサーバ構成
1サーバ上にコンテナによる
複数の仮想環境を持つ共用サーバ
Docker Composeでコンテナ管理
Web APIサーバ構成
共用の
リバースプロキシ
仮想環境毎にある
アプリケーションサーバ
(Python/uWSGI)
Web APIサーバ構成
URLのディレクトリ名で
リクエスト転送先を判別
各人独立な実行環境
仮想環境毎に
論理的に分離
各人独立な実行環境
論理的に独立
開発者で環境作成・削除できる
仮想環境削除は
コンテナ削除するだけ
仮想環境作成は
コンテナ起動するだけ
削除にかかる時間は10秒
作成にかかる時間は
ゲームロジック展開含めて45秒
開発者で環境作成・削除できる
開発者で環境を
気軽に作ってすぐ壊せる
共用環境でのオペミス防止策
(例)自分の環境の
apiコンテナを再生成
共用環境でのオペミス防止策
誤って他の人の環境で
オペレーションする危険
共用環境でのオペミス防止策
基本オペレーションは
ツールで実行
引数なしでオペレーション
共用環境でのオペミス防止策
環境変数を参照して
オペレーション対象を判別
環境変数で
自分の環境を指定
ログイン時に自動で設定される
コストパフォーマンスが高い
コストパフォーマンスが高い
環境で使っているリソースのみ割り当てるので
サーバリソースの無駄が少ない
コストパフォーマンスが高い
コストパフォーマンスが高い
サーバリソースが許す限り
環境を増やせる
コストパフォーマンスが高い
ぎりぎりまで
サーバリソースと費用の効果を
高めることができる
コストパフォーマンスが高い
インスタンスタイプt3.xlargeで
1台あたり環境を200以上用意できる
開発者1人で複数環境を所持できる
インフラ費用内訳
Web APIサーバ兼
Github Actions Runner
EC2 × 2台
t3.xlarge
ストレージ150GiB
KVS ElastiCache × 1台
cache.t2.medium
RDB Aurora × 1台
db.t3.medium
合計 75,000円
使っている技術の目玉
dev-shareの効率を飛躍的に上げている技術
1. bind mount
2. 仮想メモリ(swap)
使っている技術の目玉
dev-shareの効率を飛躍的に上げている技術
1. bind mount
2. 仮想メモリ(swap)
Dockerにおけるbind mount
「ホストマシン」上のファイルやディレクトリを
コンテナ内にマウントします
bind mountの使用目的
1. 素早いゲームロジックの更新
2. ホストマシンでオペレーションできる
bind mountの使用目的
1. 素早いゲームロジックの更新
2. ホストマシンでオペレーションできる
素早いゲームロジックの更新
ゲームロジックが
コンテナに内包されている
よくある構成
素早いゲームロジックの更新
よくある更新
更新を反映するには
イメージの再ビルドが必要
反映完了までに
時間がかかる
素早いゲームロジックの更新
ゲームロジックが
コンテナに内包されていない
dev-shareの構成
素早いゲームロジックの更新
dev-shareの更新
更新の反映は
コンテナ再生成のみ
数秒で反映完了
bind mountの使用目的
1. 素早いゲームロジックの更新
2. ホストマシンでオペレーションできる
ホストマシンでオペレーションできる
非SV/インフラエンジニアも
開発用Web APIサーバを利用
非SV/インフラエンジニアには
コンテナ操作は敷居が高い
ゲームロジック更新
トラブルシュート
ホストマシンでオペレーションできる
コンテナを
直接操作しなくて済む
オペレーションに
コンテナスキルが
必須でなくなる
ホストマシンでオペレーションできる
SVエンジニアの
サポートコストも下がる
※KLabの場合
コンテナ操作説明が
不要になる
使っている技術の目玉
dev-shareの効率を飛躍的に上げている技術
1. bind mount
2. 仮想メモリ(swap)
仮想メモリ(swap)の活用
Web APIサーバのインスタンスタイプは
t3.xlargeでメモリ容量は16GiBです
メモリ16GiBで200コンテナ立ち上げると
メモリの空きが枯渇し、無応答になってしまいます
仮想メモリ(swap)の活用
そこで仮想メモリ(swap)の登場です
swapを16GiB確保すると、メモリ容量と合計して
32GiBのメモリリソースを確保することができます
スペックアップ不要となり200環境を用意するのに
必要なインスタンス費用を節約することができます
swapの懸念
swap領域はストレージにあり、メモリと比較して
アクセス速度が遅くなります
200コンテナ立ち上げるとメモリが足りず
常時swapを使うので、性能低下が気になります
swapの懸念
ですが、開発環境では問題となりません
本当にメモリが必要なのは…
本当にメモリが必要なのは…
200コンテナ立ち上がっているが
その内、同時に利用されているのは…
本当にメモリが必要なのは…
本当にメモリが必要なのは…
メモリを使うのは一部のコンテナで
残りはスワップアウトされても
気にならない
dev-shareのデメリット
これまでdev-shareの良いところを説明して
きましたが、全てが優れているわけではありません
共用サーバならではのデメリットもあります
インスタンス障害で全員を巻き込む
リソースを食い潰すような使い方をすると
他利用者に影響が及んでしまう
サーバリソースを利用者間で共有
インスタンス障害で全員を巻き込む
1コンテナあたりの
利用できるサーバリソースを制限
CPU/メモリ/ストレージ使用率を監視
インスタンス障害で全員を巻き込む
ハードウェア起因の障害は
防ぎようがない…
インスタンス障害で全員を巻き込む
すぐ復旧できなさそうであれば
バックアップから素早く復旧
死活監視で
素早く検知・対応
独立の維持が人依存となる
物理的には繋がっているので
やろうと思えば干渉できる
独立の維持が人依存となる
例えば、開発者1が
独立していない
共通リソースを参照する
実装にすると
独立の維持が人依存となる
開発者2の環境でも
共通リソースを
参照するようになり
独立の維持が人依存となる
共通リソースが変更されると
開発者1、開発者2両方の
環境に影響するようになる
独立の維持が人依存となる
独立が壊れる
独立性の維持が人依存となる
• これまでのプロジェクトはメンバーが独立の
意義を理解しているか不安があった
• そのため、論理的独立を壊されないように
物理的独立(1人1VM)で制限していた
独立性の維持が人依存となる
• 今回のプロジェクトは、これまでの経験を通して
メンバーが独立の意義を理解しているだろう
• 物理的独立(1人1VM)で制限しなくても
論理的独立を壊されないだろう
本日のアジェンダ
1. はじめに
2. 開発環境の用途
3. 開発用Web APIサーバへのニーズ
4. 最新システムの紹介
5. 最新システムとニーズの答え合わせ
6. まとめ
1. 早い
• 試行錯誤しやすい環境
– ゲームロジックの更新を数秒で反映
– 開発者で環境を気軽に作ってすぐ壊せる
• 独立した環境を素早く提供できる
– 45秒で独立した仮想環境を提供
2. 安い
• 一人当たり1000円以内に抑えられる
– 一人当たり750円
• 定額使い放題
– 75,000円で400環境まで使い放題
• 管理コストが安い
– リモートサーバなのでオンラインサポート可能
– 開発者でできる環境の作成とデプロイ
– コンテナ隠蔽で非SV/インフラエンジニアが楽
3. 使いやすい
• 独立した環境
– 論理的に独立した仮想環境
• 非エンジニアにもわかりやすいUI
– オペレーションはGithub ActionsのWeb UIで
本日のアジェンダ
1. はじめに
2. 開発環境の用途
3. 開発用Web APIサーバへのニーズ
4. 最新システムの紹介
5. 最新システムとニーズの答え合わせ
6. まとめ
まとめ
開発用のWeb APIサーバには
• 本番と異なるニーズがある
• 工夫次第でゲームの開発のスピードは上がる
• コスパの高い手段がある
💡
まとめ
一見ゲームの面白さには無関係なサーバインフラ
裏ではゲームの開発の土台となり
しっかりとゲームを面白くすることを支えています
まとめ
まだまだ工夫の余地はあると思いますが
KLabのチャレンジが皆様の参考になれば
とてもうれしく思います
まとめ
KLabとは違うけどこんな工夫をしているよ
こんなニーズを重視しているよ
などありましたら
質問など是非お話ができればと思います。
🤝

【公開用】モバイルオンラインゲーム開発を支える早く、安く、使いやすいサーバインフラ構築