モバイル向けオンラインゲームを複数タイトル運営する企業。主力タイトルはリリースから3年が経過し、月間アクティブユーザーは数十万人規模。サーバーインフラはAWS上に構築されていましたが、リリース初期に「とにかく動かす」ことを優先した設計が残ったままでした。
直面していた問題は3つ。AWS利用料が毎月増加し続けていること。イベント時のアクセス集中でサーバーが不安定になること。そして新機能の開発速度が、技術的負債のせいで著しく低下していることでした。
開発チームは15名いましたが、インフラ専任は2名。日々の運用に追われ、根本的な改善に手を付ける余裕がありませんでした。CTOは「全面的に作り直すべきか、部分的に改善するべきか」の判断がつかない状態でした。
最大の制約は、ライブサービスを止められないこと。毎日数十万人がプレイしており、メンテナンス時間も月に1回、数時間が限度。「動いているシステムを、動かしたまま作り替える」必要がありました。
次に、技術的負債の正体が見えていなかったこと。「遅い」「高い」「不安定」という症状は分かっていても、何がボトルネックなのかの定量的な分析ができていない状態でした。「なんとなく全部悪い」では、改善の優先順位が決められません。
さらに、新機能の開発スケジュールとの並行が求められました。ゲーム運営では、月次イベントや季節コンテンツのリリースが止められません。基盤改善と新機能開発を同じチームで両立する必要がありました。
同社CTOが、業界のカンファレンスでopen brainのメンバーと知り合ったのがきっかけ。「うちのインフラ、一度見てもらえないか」というカジュアルな相談から始まりました。
すぐに決めたことは、まず2週間の「診断フェーズ」を設けること。現状のアーキテクチャ、コスト構造、パフォーマンスボトルネックを可視化し、「何をどの順番で改善するか」のロードマップを作る。
あえて決めなかったことは、「コンテナ化するか」「サーバーレスにするか」といった技術選定。ボトルネックの正体が見えていない段階でアーキテクチャの結論を出すのは危険と判断しました。
ゲームインフラの改善において最も大切なのは、「何をやらないか」を決めることです。理想のアーキテクチャを追い求めるよりも、現在のボトルネックを正確に特定し、最もコスト対効果の高い施策から着手するほうが、結果として早く・安く・安全に改善できます。
open brain が大切にしているのは、「計測してから判断する」こと。感覚的に「全体的に遅い」と思っていても、実測すると問題の80%は特定の3箇所に集中していることが多い。その3箇所を正確に見つけ出し、影響の大きい順に対処するのが、伴走型支援の基本アプローチです。
また、「作り替える」のではなく「改善する」アプローチには、もう一つの利点があります。チームの学習です。段階的な改善を通じて、インフラチームが「なぜこの設計にするか」を理解しながら進めることで、引き継ぎ後の自走力が格段に高まります。
「インフラコストが高い気がする」「イベント時に不安がある」——この感覚は、改善のきっかけとして十分です。まずは現状を可視化するところから始めましょう。2週間の診断で、「何が問題か」と「どこから手を付けるか」が明確になります。
全面リプレイスは必要ないかもしれません。ピンポイントの改善だけで、大きな効果が出ることは珍しくありません。
NDA対応可。まずは状況のヒアリングからどうぞ。