APサーバーの役割と特性

APサーバー(Tomcat / JBoss / WebLogic / Node.js)はビジネスロジックを実行する中核コンポーネントだ。セッション管理・DBアクセス・外部 API 呼び出しを行い、CPU とメモリの両方を消費する CPU バウンド & メモリバウンドな特性を持つ。JVM ベースでは GC(ガベージコレクション)が CPU スパイクの主因となることが多く、スケールアップ前に GC チューニングで解決できる場合も多い。

ボトルネックになるリソース

リソース症状確認方法
CPUGC 実行時のスパイク・ビジネスロジックの演算量増加top / jstat -gcutil
ヒープメモリOutOfMemoryError・Full GC 頻発・応答遅延jstat -gcutil PID 1000 / GC ログ
スレッドプールリクエスト待ち行列増加・タイムアウト急増Tomcat Manager / JMX / thread dump
DB コネクションプールコネクション待ち・DB 側接続数上限エラーコネクションプール監視メトリクス

スケールアップの内容と効果

① ヒープメモリ増強

Full GC が頻発(頻度 > 1回/分、STW > 500ms)している場合は、まずヒープメモリの拡張を試みる。

Shell — JVM ヒープ設定
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 使用率がコア数上限に達するとリクエストが待ち行列に積まれる。

XML — server.xml(Connector)
<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 / mpstatP95 ≥ 70%
Full GC 頻度jstat -gcutil PID 1000 10> 1回/分 または STW > 500ms
Old Gen 使用率GC ログ / JMXピーク時 80% 超え
アクティブスレッド数Tomcat ManagermaxThreads の 80% 超えが常態化

まとめ

項目要点
主なボトルネックヒープ枯渇による Full GC、スレッドプール枯渇、CPU 過負荷
スケールアップ前にまずGC チューニング(G1GC 移行・ヒープ比率調整)を実施
ヒープ目安物理メモリの 50〜75%。Old Gen ピーク < 上限の 70%
スレッド目安maxThreads ≤ CPUコア数 × 2〜4
スケールアウト移行セッション Redis 外出し後にロードバランサー配下へ追加