開発ノート：リアルタイムチャット＆ゲームサーバー構築で見えたスケーラビリティの本質

新規モバイルゲームのサーバーロジック構築で学んだスケーラビリティの要件定義

私はモバイルゲーム開発プロジェクトでバックエンドリードを務め、初めて大規模プレイヤー数を見込んだサーバー設計を経験しました。プロジェクト開始時点では「月間1万人同時接続」の想定でしたが、要件定義の曖昧さからTCPコネクション数の上限を低めに見積もってしまい、プロトタイプ段階でサーバーが容易にダウンしました。これを受けて、開発会社と協議し、以下の観点で要件を明確化しました。

1. 接続プロトコル選定：TCPベースのWebSocketとUDPベースの独自RPCのどちらを採用するか。

2. 同時接続数：ピーク時に50,000セッションを捌くための必要スレッド数とメモリ要件。

3. メッセージレイテンシ：100ミリ秒以内に全プレイヤーに情報を配信できるか。

4. フェールオーバー：リージョン障害時の自動切り替え設計。

5. コスト試算：AWS/GCPのインスタンスタイプ別月額費用とデータ転送料金。
   開発会社には、これらの要件をRFPに落とし込み、機能別・工数別に見積もってもらいました。結果として、初期予算として想定していた500万円では不足と判明し、700万円の予算増額を経営層に承認してもらいました。この経験を通じ、スケーラビリティ要件は数値で定量化し、発注前に明確に定義しておくことが追加費用を抑える鍵だと痛感しました。

リアルタイムチャットアプリにおけるWebSocket接続管理の試行錯誤

次に取り組んだのは、社内向けチャットシステムの開発でした。当初はシンプルにWebSocketを一台のサーバーで運用しようとしましたが、ユーザー増加に伴い接続数が急増。セッションアイドルタイムやコネクションタイムアウトの設定が適切でなく、15分後に大量のアイドルコネクションが残り、メモリリークが発生しました。そこで、開発チームとともに次の対策を講じました。

• アイドルタイムアウトの最適化：10分で切断、ハートビート間隔を30秒に設定し、切断後はバックグラウンドで再接続を試行。

• 接続プールの導入：NginxのTCPロードバランサー＋複数ノードでRound Robin負荷分散を実装。

• オフロードサービス：AWS API GatewayのWebSocket機能を検証し、本番フェーズで一部ルームをオフロード。

• コネクション状態管理：Redisを利用したセッションストアで、再起動やスケールアウト時の接続継続性を担保。

• テスト自動化：Artilleryで接続1000並列の負荷テストをCIパイプラインに組み込み、レスポンス95％タイルタイムを50ms以下に設定。
  この改善により、1ノードあたりの同時接続数は1万件→3万件に向上し、コスト相場としてはサーバー台数を3台→2台に削減できました。WebSocketの運用は要件定義と運用ルールの明確化が成否を分けるとの学びを得ました。

コンテナネイティブ開発で得たCI/CDパイプライン最適化の教訓

続いて、ゲームサーバーとチャットAPIをDocker化し、Kubernetes環境へデプロイする案件を経験しました。最初のCI/CDパイプラインは、ビルド→Dockerイメージ作成→テスト→デプロイまで50分かかり、開発の度に待ち時間が発生。これではアジャイル開発の迅速性を損ねるため、以下の改善策を実施しました。

1. キャッシュレイヤーの分割：Dockerfileでマルチステージビルドを活用し、baseイメージとアプリビルドを分離。依存関係キャッシュを有効化。

2. 並列ジョブ実行：Lint→ユニットテスト→統合テストを並列化。GitLab RunnerをK8s上でスケールアウトして実行。

3. 動的テスト選択：変更のあったサービスのみテストを回すGit diff連携で、工数を40％削減。

4. イメージスキャナ統合：TrivyをCIに組み込み、脆弱性検出を自動化。セキュリティレビューのコストと時間を半減。

5. カナリアリリース：Argo Rolloutsを導入し、トラフィック10％→100％と段階的に切り替え、問題発生時は即時ロールバック。
   これらの最適化により、パイプライン時間は50分→12分に短縮し、開発スピードが飛躍的に向上。開発会社への発注時も「CI/CD最適化工数」を明示し、相場として初期設定で20工数（40万〜60万円）を確保することで、スムーズにパイプライン改善が実現しました。

マルチテナントSaaSサービス開発における課金システム統合のチャレンジ

最後に、BtoB向けマルチテナントSaaSプラットフォームの開発ノートを共有します。このプロジェクトでは、複数企業が同一基盤上で動作し、利用量に応じた課金システムを統合する必要がありました。
当初の要件定義では「Stripe連携」を想定していましたが、テナントごとの決済通貨や請求書発行フォーマットの違いで追加工数が発生。結果として、基本的なStripe API呼び出しだけでは対応できず、カスタムプラグインの開発が必要になりました。具体的な対応は以下のとおりです。

• テナントコンテキスト管理：各リクエストでテナントIDをJWTに含め、一つのDBスキーマで複数テナントデータを分離。

• 動的プライシング：各テナントのプラン情報をDBに保持し、Webhookで価格変更を即時反映。

• 複数通貨対応：Stripeマルチ通貨チャージと、為替レート自動取得ロジックを実装。

• 請求書生成：PDFジェネレータ（wkhtmltopdf）とテンプレートエンジンで、各テナントのフォーマットに合わせてカスタマイズ。

• レポートダッシュボード：利用量や支払いステータスを可視化し、追加課金やデータ提供を促進。
  当初見積もりの工数150工数（相場：200万〜250万円）に対して、追加要件対応で30工数（50万〜80万円）が増加しました。しかし、開発会社との密なコミュニケーションと、要件定義フェーズでの「プラグイン拡張力」を評価し合うことで、追加費用増加を15％以内にとどめることができました。

モニタリングとアラートの整備

リアルタイムゲームやチャットシステムでは、障害発生時の即応体制が重要です。まず、すべてのサーバーインスタンスにPrometheusを導入し、CPU使用率やメモリ消費、WebSocket接続数、レスポンスタイムなどを細かく収集します。次に、Grafanaダッシュボードを構築し、チーム全員がリアルタイムに状況を確認できるようにしました。さらに、Alertmanagerを併用し、閾値を超えた場合はSlackとメールにアラートを飛ばします。例えば、WebSocket接続数がノードあたり90％を超えたら自動スケールアウトをトリガーし、メモリリーク傾向を検知したら即時原因調査チケットをJiraに起票する仕組みを整備しました。また、インフラだけでなく、アプリケーションログもFluentd→Elasticsearchパイプラインで集約し、検索性を高めることで障害の一次切り分けを迅速化。テストフェーズで発見できなかったレアケースも、本番障害ログから再現できるようになり、バグ修正にかかる追加費用を大幅に圧縮できました。

パフォーマンスチューニングと最適化

障害対応と並行して、パフォーマンスチューニングも継続的に実施しました。初期リリース時のCPUプロファイルでは、シリアライズ処理とJSONデコードに大半の時間を要していたため、MessagePack形式のバイナリシリアライズを導入。結果、1リクエストあたりの処理時間を平均8ms→3msに改善しました。次に、ゲーム内イベント通知処理で多用するPub/SubモデルをRabbitMQからNATS Streamingへ切り替え、メッセージ配信遅延を50ms→10msに短縮。さらに、ゴルーチンのリークが原因でスループットが低下していた箇所には、Contextキャンセルの徹底を導入し、アイドル状態のゴルーチンを削減しました。これらの作業は合計で約30工数（相場：50万～80万円）でしたが、開発会社との契約時に「パフォーマンス改善オプション」として明示していたため、追加予算の承認がスムーズでした。

コスト管理と予算遵守

大規模同時接続を支えるインフラは費用増加が懸念されますが、運用中はAWS Cost Explorerでインスタンス利用状況を毎日チェック。オートスケーリングのポリシーをチューニングし、ピーク以外の時間帯はノードを自動縮小。年間インフラ費用は当初見積もりの月50万円→月30万円に削減できました。また、CI/CDパイプラインのGitLab Shared Runner利用料もモニタリングし、ジョブ実行時間を最適化。ランタイム時間が長いジョブはセルフホストRunnerへ移行し、ランニングコストを半減しました。これらのコスト削減策は、発注時に「運用コスト最適化要件」として契約書に含め、開発会社と合意済みだったため、予算超過トラブルはゼロでした。さらに、

チームコミュニケーションとドキュメンテーション

複数開発会社が関わるプロジェクトでは、情報共有の徹底が成功の鍵です。私はConfluence上に「サービス設計書」「API仕様書」「シーケンス図」「OSコマンド集」「トラブルシュート手順」を常時更新し、全員がアクセスできるナレッジベースを運用しました。加えて、Swagger UIでAPIドキュメントを自動生成し、最新のエンドポイントを即時反映。コード変更時のレビューコメントはGitLab Merge Requestで一元管理し、未対応の指摘が残らないようにチェックリスト化しました。週次でキャッチアップ会議を開き、進捗と課題、リスクを共有。開発会社にも各週のチケット消化率をレポートしてもらい、相場感外の遅延がないかを監視。これにより、コミュニケーションコストを約20％削減でき、認識齟齬から発注ミスに至るリスクを大幅に低減しました。

プロジェクト成果とROI分析

最終的に、リアルタイムゲーム＆チャットサーバー構築プロジェクトは以下の成果を達成しました。

• 同時接続数：1万→5万（スケールアウト＋最適化）

• 平均レスポンスタイム：100ms→20ms（MessagePack＋Pub/Sub切替）

• ダウンタイム：年間20時間→0.5時間（モニタリング＋自動復旧）

• インフラコスト：月50万円→月30万円（オートスケーリング最適化）

• 開発会社費用：初期見積500万円→追加200万円（スコープ調整と予備予算内対応）
  これらを金額効果に換算すると、年間約600万円の価値を創出し、1年半で全投資を回収可能と試算しました。

次期フェーズへの展望

次期フェーズでは、エッジコンピューティングを活用したゲームロジック分散や、WebRTCを使った低遅延マルチプレイヤー機能を検討中です。開発会社選びは、既存実装の知見を活かせるベンダーを優先し、予算（工数）はPoC20工数、本番80工数、相場120万～180万円を想定しています。また、発注書には必ず「既存モニタリングとの互換性」「追加APIリソース管理」を明記し、費用超過リスクを抑える計画です。今後も継続的にKPIドリブンで改善を図り、システム開発の教訓をさらに積み上げていきます。