サーバーのインフラ構成を理解する（Part 2）

インフラ初心者がさくらクラウドで運用されているゲームサーバーの構成を学んだ記録です。
今回は Batch Server、CDN Origin、Admin Server について学びました。

---

Batch Server

バッチ処理とは

処理の種類	タイミング	例
リアルタイム処理	ユーザーの操作時に即座に実行	ガチャを引く、カード強化
バッチ処理	決まった時間にまとめて実行	ランキング集計、データアーカイブ

バッチ（Batch） = 「まとめて処理する」という意味。

スペックの特徴

Batch Server は他のサーバーと比べて メモリが多い。

サーバー	コア	メモリ
Front Server	4	8GB
Batch Server	4	24GB

理由:

1. 大量データをまとめて処理するため（ランキング集計で数十万件を一度にメモリに載せる等）
2. Archive DB が同居しているため（PostgreSQL はメモリをキャッシュに使う）

DB が同居している構成

Batch Server の中にはバッチ処理だけでなく、Archive DB（古いデータの保管場所） も入っている。

┌─────────────────────────────────┐
│ Batch Server │
│ ┌───────────┐ ┌───────────┐ │
│ │ Archive │ │ Web DB │ │
│ │ DB │ │ │ │
│ └───────────┘ └───────────┘ │
│ ┌───────────────────────────┐ │
│ │ バッチ処理（cronジョブ等）│ │
│ └───────────────────────────┘ │
└─────────────────────────────────┘

これは一般的？

ケースバイケース。

パターン	向いている環境
分離（処理とDBを別サーバー）	大規模・高負荷
同居（1台にまとめる）	中規模・アクセス頻度が低い場合

Archive DB は「古いデータの保管場所」で普段はあまりアクセスしないため、同居させてもパフォーマンス問題が起きにくい。合理的な判断。

---

CDN Origin

CDN とは

CDN = Content Delivery Network（コンテンツ配信ネットワーク）

世界中に「コピー置き場（エッジサーバー）」を持ち、ユーザーに一番近い場所からコンテンツを返す仕組み。

【CDN なしの場合】
アメリカのユーザー ──────────────→ 東京のサーバー
遠い！遅い！

【CDN ありの場合】
アメリカのユーザー → アメリカの CDN → キャッシュあれば即返す
↓
キャッシュなければ
↓
東京のサーバー（Origin）

CDN サービスの例

種類	例
技術名（一般名詞）	CDN
サービス名（固有名詞）	AWS CloudFront、さくら WebAccel、Cloudflare

Origin Server とは

CDN のキャッシュ元となるサーバー。

• AWS では CloudFront + S3 という構成が一般的
• 自前サーバーを Origin にすることも可能
• 「CDN Origin」という専用リソースがあるわけではなく、ただの普通のサーバー

キャッシュの仕組み

項目	説明
TTL（Time To Live）	キャッシュの有効期限。期限切れで Origin から再取得
キャッシュ対象	静的ファイル（画像、JS、CSS等）が基本
容量	CDN 側が自動管理。古いものから消える（LRU）
コスト	主に 転送量課金（配信したデータ量で決まる）

スペックの特徴

CDN Origin は 低スペックでOK。

サーバー	コア	メモリ
Front Server	4	8GB
CDN Origin	2	2GB

理由:

• 静的ファイルを返すだけ（ゲームロジックなし、DB操作なし）
• CDN がキャッシュしてくれるので、Origin への直接アクセスは少ない

---

Admin Server

役割

役割	内容
監視	Zabbix で全サーバーの死活監視・メトリクス収集
管理画面	運営用の管理ツール（ユーザー管理、データ確認等）
デプロイ	Ansible で他サーバーへのデプロイ実行
ログ収集	Fluentd でログを集約

中身の構成

┌─────────────────────────────────────────────────────────┐
│ Admin Server │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Zabbix Server │ │
│ │ - 全サーバーの死活監視 │ │
│ │ - メトリクス収集（CPU, メモリ, DB等） │ │
│ │ - 異常時は Slack に通知 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 管理画面 (Node.js + Nginx) │ │
│ │ - ユーザーデータ確認・編集 │ │
│ │ - KPI / 統計レポート │ │
│ │ - プレゼント配布 │ │
│ │ - メンテナンスモード設定 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Ansible（他サーバーへのデプロイ実行） │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Fluentd（ログ収集） │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘

Zabbix による監視

Zabbix Agent が各サーバーにインストールされ、Admin Server（Zabbix Server）にデータを送信。

┌─────────────────────────────────────────────────────┐
│ Admin Server (Zabbix Server) │
│ - 全サーバーの状態を収集 │
│ - 異常があれば Slack に通知 │
└─────────────────────────────────────────────────────┘
▲
│ データ送信
│
┌───────┴───────┬───────────────┬──────────────────────┐
│ Front Server │ DB Server │ Realtime Server │
│ (zabbix-agent)│ (zabbix-agent)│ (zabbix-agent) │
└───────────────┴───────────────┴──────────────────────┘

ネットワーク構成（セキュリティ）

Admin Server は Local Switch のみ に接続。外部からは VPC Router のポートフォワード経由でアクセス。

運営スタッフ（外部）
│
▼ 特定ポートに SSH 接続
┌─────────────────────────────────────┐
│ VPC Router（ポートフォワーディング）│
└─────────────────────────────────────┘
│
▼
Admin Server（内部ネットワーク）

なぜこの構成？

構成	セキュリティ
Global Switch に直接接続	インターネットから直接攻撃される可能性
Local Switch + ポートフォワード	VPC Router で守られる。特定ポートのみ許可

管理系サーバーは直接公開せず、VPC Router 経由でアクセスさせるのがセキュリティ的に良い構成。

---

ネットワーク設計の考え方

フラット型 vs セグメント分離型

内部ネットワークの設計には2つのアプローチがある。

パターン	構成	向いている環境
フラット型	1つのスイッチに全サーバーを繋ぐ	小〜中規模、シンプルな運用
セグメント分離型	役割ごとにスイッチ/VLANを分ける	大規模、セキュリティ重視

フラット型の例

Local Switch
├── Front Server x7
├── VS Server
├── Realtime Server
├── Batch Server
├── DB Servers
└── Admin Server
↑
全部が同じネットワーク内

メリット:

• 構成がシンプル、管理が楽
• サーバー間の通信設定が不要

デメリット:

• 1台が侵害されると、内部で横移動しやすい

セグメント分離型の例

App Switch
├── Front Server
├── VS Server
└── Realtime Server
│ ファイアウォールで制限
▼
DB Switch
├── Master Auth DB
└── Transaction DB
│
▼
Management Switch
├── Admin Server
└── Batch Server

こうすると「Front は DB にアクセスできるが、Realtime は DB に直接アクセスできない」のような細かい制御が可能。

中小規模での現実的な判断

「外壁は堅く、内部はシンプルに」 という設計方針が一般的。

• VPC Router で外部からのアクセスを厳しく制限（外壁は堅く）
• 内部は1つのスイッチでフラットに（内部はシンプルに）
• チームの規模に対して複雑すぎる構成は逆効果