さくらのVPS 1G × AlmaLinux 9.7で判明した「性能の崖」——JMeter負荷テストから導くインフラ最適化の正解

インフラエンジニアにとって、サーバーの「限界点」を正確に把握することは、コスト削減とリスク回避の生命線です。今回は、低コスト運用の定番である「さくらのVPS 1G」と、最新の「AlmaLinux 9.7」を組み合わせ、JMeterで実戦的な負荷テストを敢行しました。

そこで見えてきたのは、設定一つで明暗が分かれる「性能の崖」と、物理リソースのリアルな限界でした。

1. 検証環境スペック

• サーバー: さくらのVPS (v5) 1G TK02（ストレージ変更オプションあり）
• OS: AlmaLinux release 9.7 (Moss Jungle Cat)
• メモリ: 1GB
• 構成: Apache 2.4 / PHP-FPM 8.x / MariaDB
• テスト内容: 300ユーザーによる一斉ログイン・連続アンケート回答

2. 検証したウェブシステムの構成

今回のテストでは、単なる静的ページの表示ではなく、バックエンド（PHP/DB）がしっかり動く「動的ウェブアプリケーション」を対象としました。

テスト対象の機能

• 認証処理: ユーザーID/パスワードによるセッション管理
• データ更新: ユーザーごとの回答データをデータベースへ保存
• 動的生成: ユーザー属性に応じたコンテンツのループ表示

具体的には、「1回のログインで、複数の設問（5つ）に連続して回答するWEBアンケートシステム」を模したシナリオです。ログインから回答完了まで、1ユーザーあたり計8回のリクエストがサーバーへ飛びます。

なぜこのシステムを選んだか？

この構成は、以下のビジネスシーンで非常によく見られる「負荷が集中しやすい」パターンだからです。

• 教育機関: 授業中に生徒が一斉にログインする小テストやアンケート
• 自治体・公共: 予約開始時刻にアクセスが集中する予約フォーム
• 社内システム: 勤怠入力や年末調整など、特定の時期に利用が重なるシステム

3. 負荷テスト結果：秒間「0.2人」の差が命取りに

JMeterでアクセス密度（Ramp-up）を変化させ、サーバーが崩壊するプロセスを可視化しました。

考察：1.2人/秒の「崖」

特筆すべきは、1.0人/秒から1.2人/秒へ、わずか秒間0.2人の負荷が増えただけで、応答時間が10倍以上に悪化した点です。これがインフラにおける「性能の崖」です。

4. ボトルネックの真実：設定変更でどこまで粘れるか

初期設定のApache（150並列）とPHP-FPM（50並列）では、300人のアクセスをさばけません。そこで以下のチューニングを施しました。

• Apache: MaxRequestWorkers を100へ（メモリ保護のためあえて絞る）
• PHP-FPM: pm.max_children を80へ拡張

しかし、設定を最適化しても、物理メモリ1GBという制約下ではSwap（スワップ）が発生し、ディスクI/Oがボトルネックとなってしまいます。

# free -m の実測値。スワップが854MBも発生
Swap:           1999         854        1145

最新のAlmaLinux 9.7であっても、物理的なメモリ不足は魔法のように解決されるわけではありません。

5. ビジネスに活かす：インフラコストとリスクの最適化

今回の検証から、ビジネスを守るための3つの指針が得られました。

① 「なんとなく」のプラン選択をやめる

1GBプランの限界が「秒間1.0アクセス」であることを知っていれば、プロモーション時のアクセス予測に基づき、「事前にプランを上げるべきか」「設定変更で耐えられるか」の科学的な判断が可能になります。

② チューニングによる「延命」と「安定」

設定を最適化することで、過負荷時でも「即座に全停止」するのではなく「低速ながらも一部の処理を継続」するタフなシステムを構築できます。これは顧客の信頼維持に直結します。

③ インフラ投資の適正化

「重いからとりあえずサーバー増強」ではなく、ボトルネックを特定し運用ルール（アクセスの分散）を提案することで、不要なクラウドコストを削減します。

負荷テスト・インフラ診断のご相談

「うちのサイト、次のキャンペーンで耐えられるかな？」

「AlmaLinux 9系への移行でパフォーマンスがどう変わるか不安」

そんな不安を、今回の検証のような実数値に基づいたプロファイリングで解消します。JMeterによる詳細な負荷シナリオ構築から、ミドルウェアの最適化まで、御社の環境に合わせて診断いたします。ご相談はこちら