Requests Per Second（RPS）とは？システム性能を測る基本指標を徹底解説

Requests Per Second（RPS）は、WebサービスやAPIサーバーの性能を評価するときによく使われる基本指標です。日本語では「秒間リクエスト数」と表現でき、システムが1秒間に何件のリクエストを処理できるかを示します。たとえば、あるAPIが1秒間に500件のリクエストを安定して処理できる場合、そのAPIの処理能力は500 RPSと表現できます。Webアプリケーション、モバイルアプリのバックエンド、ECサイト、SaaS、マイクロサービス、AI APIなど、リクエストを受け付けて処理する多くのシステムで重要になります。

RPSは、システムがどれだけ多くの処理をこなせるかを把握するために使われます。新しい機能を追加したとき、サーバー台数を増やしたとき、キャッシュを導入したとき、コネクションプールやスレッドプールを調整したとき、データベースを最適化したときなど、性能改善の効果を確認するためにRPSを測定します。RPSが上がれば処理能力が向上した可能性がありますが、同時にレイテンシやエラーレートも確認しなければ、本当に良い改善かどうかは判断できません。

また、RPSは単独で見るよりも、レイテンシ、スループット、CPU使用率、メモリ使用量、データベース負荷、エラーレート、P95/P99応答時間と組み合わせて分析することが重要です。RPSが高くても、応答時間が遅すぎたり、タイムアウトが増えたり、サーバーが不安定になったりしている場合は、実用的な性能とは言えません。本記事では、RPSの基本概念、計算方法、関連指標との違い、計測方法、負荷テスト、API評価、Poolingやキャッシュとの関係、スケーリング、ベストプラクティスまでを体系的に解説します。

1. RPS（Requests Per Second）とは？

RPSとは、Requests Per Secondの略で、1秒間に処理できるリクエスト数を表す指標です。Webサービスでは、ユーザーがページを開く、ボタンを押す、検索する、商品情報を取得する、ログインする、決済処理を行うといった操作がサーバーへのリクエストとして送信されます。RPSは、こうしたリクエストをシステムが1秒あたり何件処理できるかを示します。

RPSは、システムの処理能力を把握するための非常に分かりやすい指標です。たとえば、100 RPSのシステムよりも1,000 RPSのシステムの方が、同じ条件であれば多くのリクエストを処理できます。ただし、RPSの高さだけでシステム品質を判断することはできません。ユーザーにとっては、たくさん処理できることだけでなく、速く応答すること、エラーが少ないこと、安定して利用できることも重要です。

主な特徴

RPSは、WebサービスやAPIの性能評価でよく使われる代表的な指標です。特に、負荷テストやベンチマークでは、システムがどの程度のリクエスト量に耐えられるかを確認するために使われます。サーバー増強、キャッシュ導入、データベース最適化、Pooling設定変更などの効果を比較する際にも有効です。

1.1 RPSの基本イメージ

RPSの基本イメージは、「1秒間にどれだけ多くのリクエストを処理できるか」です。たとえば、あるAPIに10秒間で5,000件のリクエストを送り、そのすべてが処理された場合、平均RPSは500になります。このように、RPSは一定時間内の処理件数を時間で割ることで求められます。

RPSは、サーバー側の処理能力だけでなく、データベース、ネットワーク、外部API、キャッシュ、スレッド数、コネクションプール、アプリケーションコードの効率にも影響されます。つまり、RPSはシステム全体の総合的な処理能力を表す指標です。単一のプログラムだけでなく、インフラ全体の状態を反映する点が特徴です。

1.2 なぜ重要なのか

RPSが重要な理由は、システムがどの程度のアクセス量に耐えられるかを把握できるからです。サービスのユーザー数が増えると、同時に発生するリクエスト数も増えます。RPSを測定していなければ、アクセス増加時にどの時点でシステムが限界を迎えるのか分かりません。その結果、キャンペーン時やピーク時間帯にタイムアウトや障害が発生する可能性があります。

また、RPSはスケーリングや最適化の効果を確認するためにも重要です。サーバーを1台から2台に増やしたとき、RPSがどの程度伸びたのかを確認すれば、スケールアウトの効果が分かります。キャッシュやPoolingを導入した後にRPSが上がれば、処理効率が改善した可能性があります。RPSは、性能改善を感覚ではなく数値で判断するための基本指標です。

2. RPSの計算方法

RPSは、一定時間内に処理したリクエスト数を、その時間で割ることで計算できます。計算式は非常にシンプルですが、実際の性能評価では、成功したリクエストだけを数えるのか、エラーを含めるのか、どの時間範囲で計測するのか、ピーク時と平均時を分けるのかを明確にする必要があります。条件を統一しないと、RPSの比較結果が意味を持たなくなります。

RPSを計算するときは、測定対象の範囲を明確にすることが大切です。単一APIのRPSなのか、システム全体のRPSなのか、特定サーバー1台あたりのRPSなのか、ロードバランサー全体のRPSなのかによって意味が変わります。たとえば、1台のサーバーで500 RPSを処理できる場合でも、5台構成なら単純計算で2,500 RPSに近づく可能性がありますが、データベースや外部APIがボトルネックになると、比例して伸びないこともあります。

2.1 基本式

RPSの基本式は、処理したリクエスト数を計測時間で割る形です。

RPS = 処理リクエスト数 ÷ 計測時間（秒）

たとえば、30秒間で15,000件のリクエストを処理した場合、RPSは500です。計算式としては、15,000 ÷ 30 = 500となります。このように、RPSは一定時間あたりの処理件数を表すため、システムの処理能力を直感的に把握できます。

ただし、実務では単純な平均RPSだけでなく、時間帯ごとのRPSも見る必要があります。たとえば、1分間の平均RPSが500でも、最初の10秒は100 RPSで、後半は900 RPSだった場合、負荷のかかり方は大きく異なります。時系列でRPSを見ることで、急激な負荷変動や処理能力の頭打ちを把握しやすくなります。

2.2 成功リクエストと失敗リクエスト

RPSを計算するときは、成功したリクエストだけを見るのか、失敗したリクエストも含めるのかを決める必要があります。たとえば、1秒間に1,000件のリクエストを受け付けても、そのうち300件がエラーで失敗している場合、単純に1,000 RPSと表現すると誤解を招く可能性があります。この場合、成功RPSは700、総リクエストRPSは1,000と分けて見るべきです。

性能評価で重要なのは、安定して成功するRPSです。システムが大量のリクエストを受けても、エラーが多ければ実用的な処理能力とは言えません。そのため、RPSを測るときは、HTTP 2xxや3xxの成功数、4xxや5xxのエラー数、タイムアウト数を分けて集計することが重要です。成功RPSとエラーレートをセットで見ることで、実際の処理能力を正しく評価できます。

2.3 平均RPSとピークRPS

平均RPSは、一定期間内のリクエスト数を平均した値です。一方、ピークRPSは、最もリクエストが集中した時間帯のRPSを示します。通常運用では平均RPSが重要ですが、キャンペーン、セール、通知配信、SNS拡散などがあるサービスではピークRPSも非常に重要です。

たとえば、1日の平均RPSが200でも、昼休みや夜の時間帯に2,000 RPSまで上がるサービスがあります。この場合、平均RPSだけを基準にサーバーを設計すると、ピーク時に障害が発生する可能性があります。RPSを評価するときは、平均値だけでなく、ピーク値、時間帯別の変動、曜日別の傾向も確認することが重要です。

3. RPSとスループットの関係

RPSは、スループットを表す具体的な指標の一つです。スループットとは、一定時間内にシステムが処理できる量を示す広い概念です。WebサービスではRPS、メッセージキューでは秒間メッセージ数、バッチ処理では分間処理件数、データ処理では秒間レコード数などで表現されます。つまり、RPSはWebやAPIにおけるスループット指標と考えることができます。

RPSとスループットは近い意味で使われますが、文脈によって使い分けることがあります。API性能を話すときはRPSが分かりやすく、システム全体やデータ処理全般を話すときはスループットという表現が使われやすいです。どちらも処理能力を表す指標ですが、RPSは「リクエスト数」に焦点を当てている点が特徴です。

3.1 スループットとは

スループットとは、単位時間あたりに処理できる作業量を示す指標です。Webサーバーであればリクエスト数、データベースであればクエリ数、メッセージ処理基盤であればメッセージ数、動画変換システムであれば変換本数などが対象になります。処理の種類によって単位は変わりますが、考え方は同じです。

スループットを見ることで、システムがどれだけの負荷に対応できるかを把握できます。ただし、スループットが高くても、処理時間が非常に長い場合やエラーが多い場合は、良い性能とは言えません。スループットは、レイテンシやエラーレートと組み合わせて評価する必要があります。

3.2 RPSはWeb向けの代表的なスループット指標

RPSは、WebサービスやAPIにおける代表的なスループット指標です。HTTPリクエストをどれだけ処理できるかを示すため、APIサーバー、Webアプリケーション、マイクロサービス、ロードバランサーの性能評価でよく使われます。特に、REST APIやGraphQL APIの負荷テストでは、RPSが主要な測定項目になります。

RPSを使うことで、アプリケーションの処理能力を分かりやすく表現できます。たとえば、「このAPIは最大1,000 RPSまで安定して処理できる」と言えば、性能の目安が明確になります。ただし、そのRPSがどのレイテンシやエラーレートで達成されたのかも併記しなければ、実用的な評価にはなりません。

3.3 RPSだけでは性能全体を判断できない

RPSは重要な指標ですが、RPSだけでは性能全体を判断できません。たとえば、RPSが高くても、P99レイテンシが数秒以上になっていれば、ユーザー体験は悪い可能性があります。また、RPSを上げるためにサーバーがCPU限界で動いている場合、少しの負荷増加で障害が発生する可能性があります。

性能評価では、RPS、平均応答時間、P95/P99レイテンシ、エラーレート、CPU使用率、メモリ使用量、DB負荷を総合的に見ることが重要です。RPSは処理能力を示す便利な指標ですが、安定性や品質を含めた評価には複数指標が必要です。

4. RPSとレイテンシの違い

RPSとレイテンシは、どちらもシステム性能を評価する重要な指標ですが、意味は異なります。RPSは1秒間に何件処理できるかを示す「処理量」の指標です。一方、レイテンシは1件のリクエストにどれだけ時間がかかるかを示す「応答時間」の指標です。RPSが高いシステムでも、1件あたりの応答が遅い場合があります。

実務では、RPSとレイテンシを必ずセットで見る必要があります。たとえば、あるAPIが2,000 RPSを処理できても、平均応答時間が3秒であればユーザー体験は悪いかもしれません。逆に、応答時間が速くても、同時アクセスが少し増えただけでRPSが伸びない場合、処理能力に課題があります。処理量と応答速度の両方を見ることで、システム性能を正しく評価できます。

4.1 RPSは処理量

RPSは、一定時間内に処理できるリクエスト数を示します。つまり、システムの処理量や処理能力を表す指標です。アクセスが多いサービスでは、RPSが低いとリクエストをさばききれず、待ち時間やエラーが発生する可能性があります。

RPSは、サーバー台数、CPU性能、メモリ、ネットワーク、データベース、キャッシュ、アプリケーションコードの効率によって変わります。性能改善を行うときは、どの要素がRPSの上限を決めているのかを分析する必要があります。RPSは結果の指標であり、その背後には複数のボトルネックが存在します。

4.2 レイテンシは応答時間

レイテンシは、リクエストを送ってから応答が返るまでの時間です。ユーザー体験に直結する指標であり、Webページの表示速度、API応答速度、アプリの操作感に影響します。レイテンシが低いほど、ユーザーはサービスを速いと感じやすくなります。

レイテンシを見るときは、平均値だけでなくP95やP99も重要です。一部のユーザーだけが遅い応答を体験している場合、平均値では問題が見えにくくなります。高負荷時にRPSが上がっても、P99レイテンシが悪化している場合は、性能改善ではなく過負荷に近づいている可能性があります。

4.3 両方を同時に見る重要性

RPSとレイテンシは、トレードオフの関係になることがあります。負荷を上げると、ある地点まではRPSが増えますが、システムが限界に近づくとレイテンシが急激に悪化します。この限界点を把握することが、性能設計では重要です。

理想的なシステムは、高いRPSを維持しながら、低いレイテンシと低いエラーレートを保てるシステムです。そのためには、負荷テストでRPSを段階的に上げ、レイテンシがどの時点で悪化するかを確認する必要があります。RPSだけを追うのではなく、ユーザーが実際に体感する応答時間と一緒に評価することが大切です。

5. RPSが重要になる場面

RPSは、WebサービスやAPIの性能を確認する多くの場面で重要になります。特に、新規サービスのリリース前、キャンペーン実施前、サーバー増強後、キャッシュ導入後、データベース最適化後、Pooling設定変更後には、RPSを測定してシステムが十分な処理能力を持っているかを確認する必要があります。

RPSを事前に把握していないと、ユーザー数が増えたときにどの程度まで耐えられるのか分かりません。結果として、アクセス集中時にサービスが遅くなったり、タイムアウトが発生したり、データベースが過負荷になったりする可能性があります。RPSは、システムの限界と余裕を把握するための基本指標です。

5.1 Webサービスの負荷測定

Webサービスでは、ユーザーのアクセス量に応じて大量のリクエストが発生します。トップページ表示、検索、ログイン、商品一覧、記事閲覧、コメント投稿など、すべてがサーバーへのリクエストになります。RPSを測定することで、現在のサーバー構成がどの程度のアクセスに耐えられるかを確認できます。

Webサービスの負荷測定では、単一ページだけでなく、実際のユーザー行動に近いシナリオを使うことが重要です。トップページだけを大量に叩いても、ログインや検索、DB書き込みの負荷は分かりません。RPSは、実際の利用パターンを反映した負荷テストで測定することで、より現実的な指標になります。

5.2 APIサーバーの性能評価

APIサーバーでは、RPSは非常に重要な評価指標です。モバイルアプリ、Webフロントエンド、外部連携サービス、AIアプリなどがAPIを呼び出すため、APIがどれだけのリクエストを処理できるかはサービス全体の品質に影響します。APIのRPSが不足すると、フロントエンドやモバイルアプリが遅く感じられます。

API性能評価では、エンドポイントごとにRPSを測定することが重要です。軽い参照系APIと重い検索API、書き込みAPI、決済APIでは処理コストが異なります。システム全体の平均RPSだけを見るのではなく、重要APIごとにRPS、レイテンシ、エラーレートを確認する必要があります。

5.3 スケーリング効果の確認

サーバー台数を増やす、コンテナ数を増やす、オートスケーリングを導入する、データベースを分散するなどのスケーリング施策では、RPSを測定して効果を確認します。理想的には、サーバー台数を2倍にすれば処理能力も2倍に近づきます。しかし、実際にはデータベース、キャッシュ、外部API、ネットワークがボトルネックになり、比例して伸びないことがあります。

スケーリング効果を見るときは、サーバー台数とRPSの関係を確認します。1台で500 RPS、2台で950 RPS、4台で1,600 RPSのように、台数を増やすほど伸び率が下がる場合、どこかに共通ボトルネックが存在する可能性があります。RPSは、スケーリングが本当に効果を出しているかを判断するために有効です。

6. RPSを左右する要因

RPSは、さまざまな要因によって変化します。アプリケーションコードの効率、データベースクエリ、キャッシュ、ネットワーク、CPU、メモリ、スレッド数、コネクションプール、外部API、ロードバランサーなどが影響します。RPSが低い場合、単にサーバーを増やすだけでは解決しないことがあります。

RPSを改善するには、どこがボトルネックになっているかを特定する必要があります。CPUが限界なのか、DBクエリが遅いのか、接続待ちが発生しているのか、外部APIが遅いのか、キャッシュが効いていないのかによって対策は異なります。RPSは最終的な結果であり、原因分析には複数のメトリクスが必要です。

6.1 アプリケーション処理

アプリケーションコードの効率は、RPSに大きく影響します。不要なループ、重い計算、同期処理の多用、無駄なオブジェクト生成、過剰なログ出力などがあると、1リクエストあたりの処理時間が長くなり、結果としてRPSが低下します。コードの改善だけでRPSが大きく向上するケースもあります。

アプリケーション処理を改善するには、プロファイリングが有効です。どの関数が時間を使っているのか、どの処理でCPUを消費しているのか、どこで待ちが発生しているのかを確認します。RPS改善では、推測で最適化するのではなく、実際に遅い処理を特定して改善することが重要です。

6.2 データベース処理

データベース処理は、RPSのボトルネックになりやすい領域です。APIの処理時間の多くがDBクエリに使われている場合、アプリケーションサーバーを増やしてもRPSは伸びにくくなります。遅いSQL、インデックス不足、N+1問題、ロック待ち、コネクションプール不足などがRPS低下の原因になります。

DB処理を改善するには、クエリ実行時間、インデックス利用状況、接続待ち時間、ロック待ち、スロークエリログを確認します。特に高RPSを求めるAPIでは、DBアクセス回数を減らす、キャッシュを活用する、読み取り専用レプリカを使う、クエリを最適化するなどの施策が必要になります。

6.3 ネットワークと外部API

ネットワーク遅延や外部APIの応答速度もRPSに影響します。アプリケーションが外部サービスに依存している場合、その外部APIが遅いと、リクエスト処理全体が遅くなります。外部APIの遅延が増えると、スレッドや接続が長時間占有され、結果としてRPSが下がることがあります。

外部APIに依存する処理では、タイムアウト設定、リトライ制御、サーキットブレーカー、非同期処理、キャッシュが重要になります。外部サービスが遅い場合に自社サービス全体が巻き込まれないようにする設計が必要です。RPSを安定させるには、内部処理だけでなく外部依存も含めて分析する必要があります。

7. RPSとPoolingの関係

Poolingは、RPSを向上させるためによく使われる最適化手法です。コネクションプールを使えば、データベース接続の作成コストを削減できます。スレッドプールを使えば、タスクごとにスレッドを作成する負荷を抑え、同時実行数を制御できます。HTTPコネクションプールを使えば、外部APIや内部サービスとの接続再利用によって通信コストを削減できます。

ただし、Poolingを導入すれば必ずRPSが上がるわけではありません。プールサイズが小さすぎると待ち時間が増え、大きすぎると下流システムへ過剰な負荷をかける可能性があります。RPSを改善するには、プール設定を実際の負荷に合わせて調整する必要があります。

7.1 コネクションプール

コネクションプールは、データベース接続を再利用する仕組みです。リクエストごとに新しい接続を作ると、接続確立のコストが発生します。コネクションプールを使えば、既存の接続を再利用できるため、1リクエストあたりの処理時間を短縮し、RPSを向上させやすくなります。

しかし、コネクションプールの最大接続数を増やしすぎると、データベース側が過負荷になる可能性があります。アプリケーションサーバーが複数ある場合、各サーバーの最大プール数を合計した接続数がDB上限を超えないように設計する必要があります。RPS改善では、アプリ側だけでなくDB側の処理能力も考慮することが重要です。

7.2 スレッドプール

スレッドプールは、処理用スレッドを再利用し、同時実行数を制御する仕組みです。スレッドを毎回作成するコストを減らし、リクエスト処理を効率化できます。適切なスレッドプール設定は、RPSの安定化に貢献します。

ただし、スレッド数を増やしすぎると、コンテキストスイッチやメモリ消費が増え、逆にRPSが低下することがあります。CPUバウンド処理とI/Oバウンド処理では適切なスレッド数が異なるため、処理内容に応じて設定する必要があります。スレッドプールは、RPS向上とシステム安定性のバランスを取るために重要です。

7.3 HTTP接続再利用

HTTP接続再利用は、外部APIや内部マイクロサービスとの通信でRPSを改善する可能性があります。毎回TCP接続やTLSハンドシェイクを行うと通信コストが増えます。接続を再利用できれば、通信開始までの時間を短縮し、より多くのリクエストを処理しやすくなります。

マイクロサービス環境では、サービス間通信が多いため、HTTP接続再利用の効果が大きくなる場合があります。ただし、接続数やタイムアウト設定を誤ると、接続枯渇や待ち時間増加が発生します。RPSを安定させるには、HTTPクライアントの接続プール設定も重要です。

8. RPSとキャッシュの関係

キャッシュは、RPSを向上させる代表的な手段です。頻繁に参照されるデータや計算結果をキャッシュしておけば、毎回データベースや外部APIへ問い合わせる必要がなくなります。その結果、1リクエストあたりの処理時間が短くなり、同じサーバー構成でもより多くのリクエストを処理できる可能性があります。

ただし、キャッシュは万能ではありません。キャッシュの整合性、更新タイミング、メモリ使用量、キャッシュミス時の負荷集中を考慮する必要があります。RPSを上げるためにキャッシュを使う場合は、ヒット率、ミス率、キャッシュ取得時間、元データ取得時間を計測し、実際に効果が出ているか確認することが重要です。

8.1 キャッシュヒット率

キャッシュヒット率は、リクエストがキャッシュから処理された割合を示します。ヒット率が高いほど、データベースや外部APIへのアクセスを減らせます。これにより、レイテンシが下がり、RPSが向上しやすくなります。

ただし、ヒット率が高いだけで良いとは限りません。古いデータを返してしまう場合や、キャッシュ更新が複雑すぎる場合は、システム全体の信頼性に影響します。RPS改善を目的にキャッシュを導入する場合でも、データの正確性と更新設計を同時に考える必要があります。

8.2 DB負荷削減

キャッシュを使うことで、データベースへのアクセス回数を減らせます。DBがRPSのボトルネックになっている場合、キャッシュは非常に効果的です。特に、商品一覧、設定情報、ランキング、マスターデータ、記事コンテンツのように頻繁に読まれるデータは、キャッシュの効果が出やすいです。

DB負荷が下がると、アプリケーション全体のRPSが向上する可能性があります。ただし、キャッシュミスが集中すると、一時的にDBへ大量アクセスが発生することがあります。これを避けるためには、キャッシュの有効期限、事前更新、ロック制御、バックグラウンド更新などを設計する必要があります。

8.3 キャッシュとRPS改善

キャッシュによるRPS改善は、リクエスト処理の中でどれだけ重い処理を省略できるかに依存します。DBクエリや外部API呼び出しが重い場合、キャッシュの効果は大きくなります。一方で、処理の大部分がアプリケーション内の計算や認証処理である場合、キャッシュだけではRPSが大きく改善しないこともあります。

キャッシュを導入した後は、RPSだけでなく、レイテンシ、DB負荷、メモリ使用量、キャッシュヒット率、エラーレートを確認します。キャッシュによってRPSが上がっても、メモリ使用量が過剰に増えたり、データ不整合が発生したりする場合は、設計を見直す必要があります。

9. RPSの計測方法

RPSを計測する方法には、アクセスログ分析、負荷テストツール、APMツール、クラウド監視サービス、ロードバランサーのメトリクスなどがあります。目的によって使う方法は変わります。開発中やリリース前の性能評価では負荷テストツールを使い、本番環境では監視ツールやログ分析を使うのが一般的です。

RPS計測では、どの地点で測るかも重要です。ロードバランサーで測るRPS、アプリケーションサーバーで測るRPS、特定APIで測るRPS、成功リクエストだけのRPSでは意味が異なります。計測地点を明確にしないと、結果の解釈を間違える可能性があります。

9.1 アクセスログ分析

アクセスログには、リクエスト時刻、URL、ステータスコード、処理時間、ユーザーエージェント、IPアドレスなどが記録されます。ログを集計することで、秒単位や分単位のRPSを計算できます。本番環境の実際の利用状況を把握するには、アクセスログ分析が有効です。

アクセスログ分析では、成功リクエストとエラーリクエストを分けて集計することが重要です。また、API別、時間帯別、ユーザー種別別にRPSを見ることで、どの機能に負荷が集中しているかが分かります。ログは過去の実データを分析できるため、容量計画やピーク対策にも役立ちます。

9.2 負荷テストツール

負荷テストツールを使うと、意図的に大量のリクエストを発生させ、システムがどの程度のRPSに耐えられるかを確認できます。JMeter、k6、Gatling、Locustなどのツールが代表的です。これらを使うことで、同時ユーザー数、リクエスト頻度、シナリオ、テスト時間を指定して負荷をかけられます。

負荷テストでは、RPSだけでなく、応答時間、エラーレート、CPU使用率、メモリ使用量、DB接続数も同時に記録します。RPSが高くても、レイテンシやエラー率が悪化していれば実用的ではありません。負荷テストは、RPSの限界値と安定稼働できる範囲を確認するために重要です。

9.3 APMと監視ツール

APMとは、アプリケーション性能監視のことです。APMツールを使うと、RPS、レイテンシ、エラーレート、トレース、DBクエリ時間、外部API呼び出し時間などを可視化できます。本番環境で継続的にRPSを監視するには、APMやクラウド監視サービスが有効です。

APMを活用すると、RPSの急増や急減を検知できます。たとえば、RPSが急増してレイテンシも悪化している場合、アクセス集中や障害の兆候かもしれません。逆に、RPSが急減している場合、フロントエンド、DNS、ロードバランサー、認証基盤などに問題がある可能性があります。RPS監視は、障害検知にも役立ちます。

10. 負荷テストでRPSを評価する方法

負荷テストでRPSを評価する場合、単に大量のリクエストを送ればよいわけではありません。実際のユーザー行動に近いシナリオを作り、段階的に負荷を上げ、どの時点でレイテンシやエラーレートが悪化するかを確認する必要があります。RPSは、システムの限界を知るためだけでなく、安定して運用できる範囲を決めるために使います。

負荷テストでは、ウォームアップ時間、テスト時間、同時ユーザー数、リクエスト間隔、データ量、キャッシュ状態を明確にすることが重要です。条件が曖昧だと、結果を再現できません。また、RPSの数値だけを追うのではなく、ユーザー体験に近い応答時間とエラー率を同時に確認します。

10.1 段階的に負荷を上げる

RPS評価では、いきなり最大負荷をかけるのではなく、段階的に負荷を上げる方法が有効です。たとえば、100 RPS、300 RPS、500 RPS、1,000 RPSのように段階的に増やし、それぞれの段階でレイテンシ、エラーレート、CPU使用率、DB負荷を確認します。

段階的に負荷を上げることで、どの時点から性能が悪化するかを把握できます。最初はRPSが増えても応答時間が安定しているかもしれませんが、ある地点を超えるとP99レイテンシが急激に悪化することがあります。この境界が、システムの実用的な限界を示す重要なポイントです。

10.2 限界RPSを確認する

限界RPSとは、システムが許容できるレイテンシとエラーレートを保ちながら処理できる最大RPSです。単にリクエストを受け付けられる最大値ではなく、実用的に安定処理できる値として考える必要があります。たとえば、2,000 RPSまで処理できてもエラーレートが10%なら、安定した限界とは言えません。

限界RPSを確認することで、現在のシステムがどれだけのアクセス増加に耐えられるかが分かります。また、オートスケーリングのしきい値やサーバー増強計画を決める材料にもなります。限界RPSは一度測って終わりではなく、機能追加やデータ量増加に応じて定期的に見直す必要があります。

10.3 安定RPSを定義する

安定RPSとは、長時間運用してもレイテンシやエラーレートが許容範囲内に収まるRPSです。限界RPSより少し低い値として定義されることが多く、本番運用で安全に処理できる目安になります。たとえば、限界が1,500 RPSでも、安定運用の目安は1,000〜1,200 RPSに設定する場合があります。

安定RPSを定義することで、容量計画やアラート設計がしやすくなります。現在のRPSが安定RPSの80%を超えたらスケールアウトする、90%を超えたら警告を出すといった運用が可能になります。RPSは、性能評価だけでなく運用設計にも活用できる指標です。

11. RPS改善方法

RPSを改善するには、アプリケーション、データベース、キャッシュ、Pooling、ネットワーク、インフラの複数領域を見直す必要があります。単にサーバーを増やすだけでは、根本的なボトルネックが残る場合があります。RPS改善では、まず計測し、ボトルネックを特定し、効果の大きい箇所から改善することが重要です。

RPS改善の基本は、1リクエストあたりの処理時間を短縮すること、同時処理能力を高めること、不要な処理を減らすことです。軽い処理を高速に返せるようになれば、同じリソースでより多くのリクエストを処理できます。ただし、RPSを上げることだけを目的にして、データ整合性やセキュリティを犠牲にしてはいけません。

11.1 コード最適化

コード最適化では、不要な処理、重複処理、非効率なループ、過剰なシリアライズ、無駄なログ出力を削減します。特に、全リクエストで共通して実行される処理は、少しの改善でもRPSに大きく影響します。認証処理、入力検証、レスポンス生成、JSON変換などは、改善対象になりやすい領域です。

コード最適化では、推測ではなくプロファイリングを使うことが重要です。開発者が重いと思っている処理と、実際にCPU時間を使っている処理が異なることは珍しくありません。RPS改善では、実測データに基づいてボトルネックを特定し、効果の大きい改善から取り組むべきです。

11.2 DB最適化

DB最適化は、RPS改善で非常に重要です。多くのWebサービスでは、API処理時間の大部分がデータベースアクセスに使われます。SQLの改善、インデックス追加、N+1問題の解消、不要なクエリ削減、トランザクション時間短縮、読み取りレプリカ活用によって、RPSが大きく改善する場合があります。

DB最適化では、スロークエリログや実行計画を確認することが重要です。どのクエリが遅いのか、インデックスが使われているのか、ロック待ちが発生しているのかを分析します。DBがボトルネックの場合、アプリケーションサーバーを増やしてもRPSは伸びにくいため、DB側の改善が優先されます。

11.3 キャッシュと非同期処理

キャッシュは、RPS改善に効果的な手段です。頻繁に参照されるデータをキャッシュすれば、DBや外部APIへのアクセスを減らせます。これにより、応答時間が短くなり、同じリソースでより多くのリクエストを処理できるようになります。

非同期処理もRPS改善に役立ちます。ユーザーへの応答に必須でない処理をバックグラウンド化すれば、リクエストの応答を速くできます。メール送信、ログ集計、通知処理、重い分析処理などは、キューに入れて非同期に処理できる場合があります。ただし、非同期化では整合性や失敗時の再処理も設計する必要があります。

12. RPSとスケーリング

RPSは、スケーリング戦略を考えるうえで重要な指標です。アクセス量が増えたとき、サーバーを増やすべきか、DBを分散すべきか、キャッシュを導入すべきか、コードを最適化すべきかを判断する材料になります。RPSの推移を監視していれば、将来的に必要なインフラ容量を予測しやすくなります。

スケーリングには、垂直スケーリングと水平スケーリングがあります。垂直スケーリングはサーバーの性能を上げる方法で、水平スケーリングはサーバー台数を増やす方法です。どちらもRPS改善に役立ちますが、ボトルネックによって効果は異なります。RPSを測定しながら、最適なスケーリング方法を選ぶことが重要です。

12.1 垂直スケーリング

垂直スケーリングとは、サーバーのCPU、メモリ、ディスク、ネットワーク性能を強化する方法です。1台あたりの処理能力が上がるため、RPSが改善する可能性があります。小規模から中規模のシステムでは、比較的簡単に実施できるスケーリング方法です。

ただし、垂直スケーリングには限界があります。どれだけ高性能なサーバーにしても、いずれ物理的・コスト的な上限に到達します。また、単一サーバーに依存すると障害時の影響が大きくなります。RPSが大きく増えるサービスでは、水平スケーリングと組み合わせる必要があります。

12.2 水平スケーリング

水平スケーリングとは、サーバー台数を増やして処理能力を高める方法です。ロードバランサーでリクエストを複数サーバーへ分散すれば、システム全体のRPSを増やしやすくなります。クラウド環境やコンテナ環境では、水平スケーリングが一般的な手法として利用されます。

ただし、水平スケーリングでも、共有リソースがボトルネックになるとRPSは伸びません。データベース、キャッシュ、外部API、ファイルストレージ、認証基盤などが共通で使われる場合、それらの処理能力も確認する必要があります。水平スケーリングはアプリケーション層には効果的ですが、全体最適化が必要です。

12.3 オートスケーリング

オートスケーリングは、負荷に応じてサーバー台数を自動的に増減させる仕組みです。RPSやCPU使用率、メモリ使用量、キュー長などをトリガーにして、必要なときにインスタンスやコンテナを増やします。アクセスが増える時間帯だけリソースを増やせるため、コスト最適化にもつながります。

オートスケーリングでは、スケールアウトのタイミングが重要です。RPSが急増してからサーバーを増やしても、起動に時間がかかる場合は遅延やエラーが発生します。そのため、RPSの増加傾向を見て早めにスケールする、ウォームアップ時間を考慮する、最小台数を確保するなどの設計が必要です。

13. RPS計測でよくある失敗

RPS計測では、いくつかのよくある失敗があります。代表的なのは、平均RPSだけを見る、エラーレートを無視する、実ユーザーに近いシナリオを使わない、テスト条件を記録しない、キャッシュ状態を考慮しないといったものです。これらの失敗があると、RPSの数値は出ても、実際の性能判断には使いにくくなります。

また、テスト環境と本番環境の差にも注意が必要です。テスト環境では十分なRPSが出ていても、本番ではデータ量、ユーザー行動、外部API、ネットワーク、ログ出力、監視エージェントなどの影響で性能が変わることがあります。RPS計測では、数値そのものだけでなく、測定条件を明確にすることが重要です。

13.1 エラーを含めて高RPSと判断する

よくある失敗の一つは、エラーを含めた総リクエスト数だけを見て高RPSと判断することです。たとえば、1,000 RPSを受け付けていても、そのうち300 RPSがタイムアウトやHTTP 5xxで失敗しているなら、安定した処理能力は700 RPS以下と考えるべきです。

RPSを評価するときは、成功RPS、失敗RPS、エラーレートを分けて見る必要があります。性能評価で重要なのは、ユーザーに正常な応答を返せる処理能力です。エラーを大量に出しながら高RPSを達成しても、実用的な性能とは言えません。

13.2 レイテンシを無視する

RPSが高くても、レイテンシが悪化している場合は注意が必要です。システムが限界に近づくと、RPSは一時的に高く見えても、待ち時間が増えてユーザー体験が悪化します。特にP95やP99レイテンシが悪化している場合、一部ユーザーに大きな遅延が発生している可能性があります。

RPS計測では、必ずレイテンシを同時に確認するべきです。平均応答時間、P95、P99、最大応答時間を見ることで、RPS上昇がユーザー体験を犠牲にしていないか判断できます。RPSだけを追うと、過負荷状態を性能向上と誤解する危険があります。

13.3 テスト条件が不統一

テスト条件が不統一だと、RPSの比較結果は信頼できません。たとえば、導入前はキャッシュが空の状態で測り、導入後はキャッシュが温まった状態で測ると、プーリングやコード改善の効果ではなくキャッシュ状態の違いが結果に反映されます。サーバースペック、DBデータ量、ネットワーク状態、同時ユーザー数が異なる場合も同様です。

RPSを比較する場合は、測定条件をできるだけ揃え、記録として残すことが重要です。テスト日時、サーバー構成、アプリバージョン、DB状態、キャッシュ状態、負荷ツール設定、テストシナリオを残しておけば、後から結果を再現しやすくなります。性能評価では、数値と同じくらい条件管理が重要です。

14. RPS監視とアラート設計

RPSは、負荷テストだけでなく本番運用の監視にも活用できます。RPSを継続的に監視することで、アクセス増加、異常トラフィック、障害、外部要因による変化を検知できます。通常よりRPSが急増している場合はキャンペーン効果や攻撃の可能性があり、急減している場合はフロントエンド、DNS、ロードバランサー、認証基盤の障害が疑われます。

RPS監視では、単純なしきい値だけでなく、通常パターンとの比較も重要です。サービスには曜日や時間帯によるアクセス傾向があります。普段の夜間ピークが1,000 RPSのサービスで1,200 RPSになっても問題ないかもしれませんが、深夜に突然1,200 RPSになると異常かもしれません。RPSは時系列と文脈で見る必要があります。

14.1 時系列監視

時系列監視では、RPSを時間の流れに沿って確認します。分単位、秒単位、時間単位でRPSの変化を可視化することで、ピーク時間帯、急増、急減、周期性を把握できます。RPSのグラフを見ることで、ユーザー行動やシステム負荷の傾向が分かります。

時系列監視では、RPSと同時にレイテンシやエラーレートを重ねて見ると効果的です。RPSが上がったときにレイテンシも上がっているなら、システムが負荷に押されている可能性があります。RPSは変わらないのにエラーレートだけ上がっている場合は、特定機能や下流システムに問題があるかもしれません。

14.2 しきい値設定

RPSのアラートでは、しきい値設定が重要です。たとえば、通常時の最大RPSが1,000で、安定RPSの目安が1,500なら、1,300を超えた段階で警告、1,500を超えたら重大アラートにする設計が考えられます。ただし、サービスの特性によって適切なしきい値は異なります。

しきい値は固定値だけでなく、過去平均との差分で設定する方法もあります。通常の3倍以上のRPSが発生した場合にアラートを出す、特定時間帯の通常範囲を超えた場合に通知するなど、異常検知の考え方を取り入れると実用的です。RPSアラートは、多すぎるとノイズになり、少なすぎると異常を見逃すため、運用しながら調整する必要があります。

14.3 異常トラフィック検知

RPS監視は、異常トラフィック検知にも役立ちます。突然RPSが急増した場合、正当なアクセス増加だけでなく、ボット、スクレイピング、DDoS攻撃、バグによるリトライループなどの可能性があります。単純なアクセス増加と異常トラフィックを見分けるには、IP、ユーザーエージェント、エンドポイント、地域、ステータスコードをあわせて分析します。

異常トラフィックが疑われる場合は、レート制限、WAF、ボット対策、キャッシュ、サーキットブレーカーなどの対策が必要になります。RPSはトラフィック量を示す基本指標であり、セキュリティや安定運用の観点でも重要です。

15. RPSのベストプラクティス

RPSを活用するためには、計測条件を統一し、レイテンシやエラーレートとあわせて分析し、継続的に監視することが重要です。RPSはシンプルな指標ですが、解釈を誤ると性能判断を間違える可能性があります。高いRPSを達成することだけを目的にするのではなく、安定して正常な応答を返せるRPSを把握することが大切です。

また、RPSは開発、テスト、運用のすべての段階で活用できます。開発段階では改善前後の比較、リリース前には負荷テスト、本番運用では監視とアラート、事業成長時には容量計画に使えます。RPSを継続的に計測することで、システムの成長に合わせた性能改善がしやすくなります。

15.1 単独で判断しない

RPSは重要ですが、単独で判断してはいけません。RPSが高くても、レイテンシが高い、エラーレートが高い、CPUが限界、DBが過負荷という状態では、良い性能とは言えません。RPSは、処理能力の一面を示す指標にすぎません。

性能評価では、RPS、レイテンシ、P95/P99、エラーレート、CPU使用率、メモリ使用量、DB接続数、キャッシュヒット率を組み合わせて見る必要があります。複数指標を組み合わせることで、処理能力、応答速度、安定性、リソース効率を総合的に判断できます。

15.2 実運用に近い条件で測る

RPSを測るときは、実運用に近い条件で測定することが重要です。単純なリクエストだけを大量に送っても、本番の負荷を正しく再現できない場合があります。実際のユーザーは、ログイン、検索、一覧表示、詳細表示、更新、決済、通知など、複数の処理を組み合わせて利用します。

実運用に近い負荷シナリオを作ることで、現実的なRPSを把握できます。また、データ量、キャッシュ状態、外部API、DB接続、認証処理も本番に近づける必要があります。RPSの数値は、測定条件によって大きく変わるため、現実に近い条件で評価することが大切です。

15.3 継続的に計測する

RPSは一度測れば終わりではありません。機能追加、ユーザー数増加、データ量増加、インフラ変更、ライブラリ更新、アーキテクチャ変更によって、RPSは変化します。継続的に計測することで、性能劣化を早期に発見できます。

継続的なRPS計測では、主要APIのRPS、レイテンシ、エラーレートを定点観測します。リリース前後で数値が悪化していないかを確認し、異常があれば原因を調査します。RPSは、システム性能の健康状態を確認するための基本指標として、継続的に活用するべきです。

おわりに

Requests Per Second（RPS）は、WebサービスやAPIの性能を測る基本指標です。日本語では「秒間リクエスト数」と表現でき、システムが1秒間にどれだけのリクエストを処理できるかを示します。RPSを測定することで、システムの処理能力、スケーリング効果、最適化施策の成果、ピーク負荷への耐性を把握できます。

ただし、RPSだけでシステム性能を判断することはできません。RPSが高くても、レイテンシが遅い、P99が悪い、エラー率が高い、CPUやDBが限界に達している場合は、実用的な性能とは言えません。RPSは、レイテンシ、スループット、エラーレート、CPU使用率、メモリ使用量、DB接続数、キャッシュヒット率と組み合わせて分析することが重要です。

RPSは、Poolingやキャッシュとも密接に関係します。コネクションプールやスレッドプールを適切に設計すれば、リソース再利用によってRPSを改善できる可能性があります。キャッシュを活用すれば、DBや外部APIへのアクセスを減らし、同じサーバー構成でもより多くのリクエストを処理しやすくなります。ただし、設定を誤ると待ち時間やリソース過剰消費につながるため、必ず計測と比較が必要です。

RPSを正しく活用するには、実運用に近い条件で負荷テストを行い、成功RPSとエラーレートを分けて集計し、平均値だけでなく時間帯別やピーク時の変化も確認することが大切です。継続的にRPSを監視し、システムの成長や負荷変動に合わせて最適化を続けることで、安定したWebサービスやAPI基盤を構築できます。