はじめに
本書の目的
本書は、2025年版の主要なWebフレームワークのパフォーマンス比較を分かりやすくまとめたものです。Go、Rust、PHP、Node.js、Rubyなど複数の言語と代表的なフレームワークを取り上げ、スループット、レイテンシ、安定性の観点から評価します。開発者やアーキテクトが実運用での選択判断を行う際の参考にすることを目的としています。
対象と範囲
比較対象は、軽量な静的配信からJSON API、データベースを伴う処理までを含む代表的なワークロードです。具体例としては、静的ファイル配信、単純なJSONレスポンス、DBクエリを含むエンドポイント、同時接続の増加に対する挙動などを想定しています。
測定指標の説明
- スループット：単位時間あたりの処理数（リクエスト/秒）。高いほど多くの処理を捌けます。例：同時100接続での処理数。
- レイテンシ：応答時間の分布（中央値や95パーセンタイル）。遅延が小さいほどユーザー体験が良くなります。
- 安定性：エラー率やパフォーマンスの変動幅。長時間負荷をかけた際の挙動も重視します。
テスト環境と手法
実運用に近い結果を得るため、共通のハードウェアまたは同等のクラウド環境で計測し、各フレームワークは同じ条件で動かしました。ベンチマークはウォームアップを行い、複数回実行して平均や分散を報告します。オプションや設定は現実的な運用設定に合わせて調整しています。
本書の読み方
数値は比較の出発点と捉えてください。単純な高速性だけでなく、開発効率や既存エコシステム、運用のしやすさも選択に影響します。第2章以降で詳細な数値と考察を示しますので、用途に応じて読み進めてください。
バックエンドフレームワークの詳細パフォーマンス比較
概要
2025年の計測では、Go + Ginが最速で毎秒4,205リクエスト、平均レイテンシ11.9msを記録しました。Rust + Actixは毎秒3,148リクエストで堅牢な高速性を示します。Laravel Octane（Swoole）はPHPの性能を大幅に改善し、毎秒2,413リクエストを処理しました。Rails APIは中程度で安定、NestJSはNode.js系で優位ですがレイテンシはやや高めです。PHP-FPMはOPCacheの有無で性能に大きな差が出ます。
フレームワーク別の特徴と適用例
- Go + Gin：低レイテンシと高スループットが特徴です。小さなリクエストを大量に捌くマイクロサービスに向きます。
- Rust + Actix：メモリ効率と安全性に優れます。CPU負荷が高い処理や長時間稼働するサービスに適します。
- Laravel Octane（Swoole）：既存のLaravel資産を使いながら性能を伸ばせます。中〜大規模のWebアプリで導入効果が出やすいです。
- Rails API：開発効率を重視するアプリに向きます。トラフィックが極端に高くない業務システムに適しています。
- NestJS：TypeScriptで構造化された開発が可能です。リアルタイム機能やNodeエコシステムを生かす場合に有利です。
- PHP-FPM：手軽に動かせますが、OPCacheで大きく性能が改善します。共有ホスティングやレガシー環境でよく使われます。
実運用での考慮点
単純なRPSだけで選ばないでください。開発速度、運用コスト、メモリ使用量、起動時間、エコシステムの成熟度を合わせて判断する必要があります。したがって、ベンチ結果は重要な参考情報ですが、実際のワークロードでの試験を行い、使い慣れたツールやチームの知見も考慮して選んでください。
フレームワーク選択の指針
概要
高パフォーマンスを最優先するなら、Go + Gin や Rust + Actix を検討してください。これらは低レイテンシや高スループットを必要とする金融システムやゲームサーバーに向きます。一方で、開発効率とパフォーマンスのバランスを重視するなら Rails API や NestJS が適します。スタートアップや要件が変わりやすいプロジェクトで迅速に価値を出せます。
選択時の主な判断基準
- チームの習熟度：得意な言語を優先すると生産性が上がります。例えば、Go経験者がいれば Gin は短期間で安定します。
- レイテンシとスループット：リアルタイム処理が必要なら Rust/Go。バッチ処理やユーザー系APIなら Rails/NestJS で問題ないことが多いです。
- 生態系とライブラリ：外部連携や認証、DBマイグレーションなどの成熟度を確認してください。
- 運用性：コンテナ化、ログ、モニタリングの実装が容易かで選びます。
シナリオ別おすすめ
- 金融取引やゲームサーバー：Rust + Actix、または Go + Gin（低遅延と安定性が重要）。
- 迅速なプロトタイプやMVP：Rails API や NestJS（開発速度が速く変更に強い）。
- マイクロサービス構成：言語混在も可。共通インターフェース（gRPC/HTTP）を決めて分担します。
移行と実運用での注意点
- ベンチマークを実稼働に近い環境で必ず行ってください。実データや同時接続数を想定します。
- ライフサイクル管理（依存更新、メンテナンス）を計画してください。新しい言語導入は運用コストが増えます。
テストと可観測性
- ロードテスト、エンドツーエンドテストを自動化してください。障害時のトレースやメトリクスを早期に整備すると問題発見が速くなります。
（章のまとめは省略）
より広範なフレームワーク性能ランキング
テストの概要
Fortunesテストは単一ハードウェア上でフレームワーク単体の処理能力を測るベンチマークです。今回の結果では、Rust実装の may-minihttp が約127万リクエスト/秒、Cの H2O が約122万リクエスト/秒で上位を占めました。
ランキング（概観）
- Rust — may-minihttp（約127万 req/s）
- C — H2O（約122万 req/s）
- 高性能を謳うC/C++や軽量Rust実装
- GoやJavaの成熟したフレームワーク（安定性重視）
- スクリプト系（Node.js、Python等）— 柔軟性と開発速度を重視
結果の読み方と注意点
このベンチマークは純粋なI/O処理性能を比較します。実運用ではデータベース、外部API、認証、監視などが性能を左右します。したがって、最高スコアが常に最良の選択とは限りません。例えば、高速フレームワークでもDB接続がボトルネックなら全体性能は向上しません。
運用で考えるポイント
- レイテンシとスループットのバランスを検討してください。
- メモリ使用量や開発効率、エコシステムの成熟度も重要です。
- 保守性やセキュリティ対策、デプロイの手間も考慮してください。
推奨の考え方
性能は重要ですが、サービスの要件に合わせて総合的に判断してください。短期的なスコアだけで決めず、運用や開発の観点も評価して選ぶと良いです。
