APサーバーの役割と特性
APサーバー(Tomcat / JBoss / WebLogic / Node.js)はビジネスロジックを実行する中核コンポーネントだ。セッション管理・DBアクセス・外部 API 呼び出しを行い、CPU とメモリの両方を消費する CPU バウンド & メモリバウンドな特性を持つ。JVM ベースでは GC(ガベージコレクション)が CPU スパイクの主因となることが多く、スケールアップ前に GC チューニングで解決できる場合も多い。
ボトルネックになるリソース
| リソース | 症状 | 確認方法 |
|---|---|---|
| CPU | GC 実行時のスパイク・ビジネスロジックの演算量増加 | top / jstat -gcutil |
| ヒープメモリ | OutOfMemoryError・Full GC 頻発・応答遅延 | jstat -gcutil PID 1000 / GC ログ |
| スレッドプール | リクエスト待ち行列増加・タイムアウト急増 | Tomcat Manager / JMX / thread dump |
| DB コネクションプール | コネクション待ち・DB 側接続数上限エラー | コネクションプール監視メトリクス |
スケールアップの内容と効果
① ヒープメモリ増強
Full GC が頻発(頻度 > 1回/分、STW > 500ms)している場合は、まずヒープメモリの拡張を試みる。
export CATALINA_OPTS="-Xms4g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
# -Xms: 初期ヒープ(-Xmx と同値にしてメモリ確保を1回に)
# -Xmx: 最大ヒープ(物理メモリの 50〜75% が目安)
# GC ログ出力(Java 11+)
# -Xlog:gc*:file=/var/log/tomcat/gc.log:time,uptime:filecount=5,filesize=20m
■ 最適ヒープサイズの目安
推奨 -Xmx = 物理メモリ × 0.50〜0.75
例:32GB 搭載 → -Xmx20g〜24g。残りは OS・ネイティブメモリ・Metaspace に充てる。
② CPU コア数増強(スレッドプール対応)
Tomcat の同時処理数は maxThreads で制限されている。同時リクエスト × 1スレッドの CPU 使用率がコア数上限に達するとリクエストが待ち行列に積まれる。
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="400"
minSpareThreads="25"
acceptCount="200"
connectionTimeout="20000"
maxConnections="8192" />
⚠️ maxThreads を増やしすぎない
CPU コア数が追いつかなければコンテキストスイッチが増加して逆効果。一般的に maxThreads ≤ CPUコア数 × 2〜4 が目安です。
スケールダウンの考え方
| 削減項目 | リスク | 安全に削減できる条件 |
|---|---|---|
| ヒープメモリ削減 | Full GC 頻度が増加 | Old Gen 使用率ピークが上限の 50% 以下 |
| CPU コア削減 | GC 並列処理が遅くなる | CPU P95 使用率 40% 以下 |
| maxThreads 削減 | リクエスト待ち時間増加 | アクティブスレッドのピークが maxThreads の 50% 以下 |
スケールアップ vs スケールアウト
APサーバーはステートレスに設計できればスケールアウトと相性が良い。セッションを APサーバー内に持つ場合は、Redis へのセッション外出しを先に対応する。
✅ スケールアップを優先するケース
GC チューニングで解消できないほどヒープが不足している、または計算ロジックが CPU を長時間占有するバッチ処理がある場合は、スケールアウトよりスケールアップが効率的です。
判断指標(監視メトリクス)
| メトリクス | 確認コマンド | スケールアップの目安 |
|---|---|---|
| CPU 使用率 | top / mpstat | P95 ≥ 70% |
| Full GC 頻度 | jstat -gcutil PID 1000 10 | > 1回/分 または STW > 500ms |
| Old Gen 使用率 | GC ログ / JMX | ピーク時 80% 超え |
| アクティブスレッド数 | Tomcat Manager | maxThreads の 80% 超えが常態化 |
まとめ
| 項目 | 要点 |
|---|---|
| 主なボトルネック | ヒープ枯渇による Full GC、スレッドプール枯渇、CPU 過負荷 |
| スケールアップ前にまず | GC チューニング(G1GC 移行・ヒープ比率調整)を実施 |
| ヒープ目安 | 物理メモリの 50〜75%。Old Gen ピーク < 上限の 70% |
| スレッド目安 | maxThreads ≤ CPUコア数 × 2〜4 |
| スケールアウト移行 | セッション Redis 外出し後にロードバランサー配下へ追加 |