RPS (Requests per second)（RPS: アールピーエス）

2025年10月17日

RPS (Requests per second)（RPS: アールピーエス）

英語表記: RPS (Requests per second)

概要

RPS（Requests per second）は、システムやサーバーが1秒間に処理できるリクエスト（要求）の数を表す、非常に重要な性能指標です。この指標は、「情報の単位（ビット, バイト, KiB, MiB）」のカテゴリの中でも特に「計測とモニタリング指標」に位置づけられ、システムの負荷耐性や処理能力を客観的に測るために用いられます。ウェブサイトのアクセス集中時や、API連携の処理能力を評価する際に、システムが安定して応答できるかを確認する鍵となる数値だと考えてください。

詳細解説

RPSの目的と位置づけ

RPSは、私たちが扱うデータ量（ビットやバイト）がどれだけ大きくても、それを「時間あたりでどれだけ効率よく処理できるか」を定量的に評価するために不可欠な指標です。これは、単にデータ容量を測るのではなく、システムの「活動量」を測る「トランザクション指標」の代表格と言えます。

RPSを測定する最大の目的は、システムのスループット（単位時間あたりの処理量）を把握し、ボトルネックを特定することです。例えば、ECサイトでセールが始まったとき、ユーザーからの「商品検索」「カートに追加」「購入手続き」といったリクエストが爆発的に増加します。このとき、システムが事前に計測されたRPSを上回るリクエストを受け付けてしまうと、応答遅延が発生したり、最悪の場合システムダウンにつながったりします。

RPSの構成要素と動作原理

RPSの計算は非常にシンプルです。特定の計測時間内にサーバーが受け付け、正常に処理を完了したリクエストの総数を、その計測時間（秒）で割って算出します。

$$RPS = \frac{総リクエスト数}{計測時間（秒）}$$

この「リクエスト」には、ウェブページへのアクセス、データベースへの問い合わせ、APIコールなど、クライアント（利用者側）からサーバー（システム側）へのあらゆる要求が含まれます。

RPSが高いほど、そのシステムは短時間で多くの要求を処理できる、つまり処理能力が高いと評価されます。ただし、重要なのは「単に高いRPSを出すこと」ではありません。RPSを計測する際には、同時にレスポンスタイム（応答時間）も計測し、適切な応答時間を維持しつつ、どれだけのRPSを達成できるかというバランスが非常に重要になってきます。応答時間が長すぎる状態でのRPSは、ユーザー体験を損なうため、実用的な性能とは言えません。

このようにRPSは、システムがどれだけの「トランザクション」（ここではリクエストの処理）をこなせるかを測るための、まさに基本中の基本となる「計測とモニタリング指標」なのです。システムの健全性を判断する上で、この指標を見逃すわけにはいきませんね。

分類との関連性：なぜ「計測とモニタリング指標」なのか

この概念が「情報の単位」のカテゴリに属しているのは、RPSが「時間あたりの処理量」というレートを単位として扱っているからです。ビットやバイトがデータの量を表すように、RPSは「処理の密度」を表します。

特に「計測とモニタリング指標」という中間カテゴリにおいては、システムのパフォーマンスを数値化するための最も直接的な指標として機能します。システムのキャパシティプランニング（必要なリソースの見積もり）を行う際には、将来の予測されるアクセス量（リクエスト数）から必要なRPSを逆算し、それに見合ったサーバーやネットワークリソースを準備する必要があります。これは、ITインフラの設計において、非常に戦略的な判断を下すための根拠となるため、エンジニアにとっては必須の知識と言えます。

具体例・活用シーン

RPSは、私たちが日常的に利用するサービスの裏側で常に意識されている数値です。

1. 負荷試験における目標設定

新しいオンラインサービスを公開する前には、必ず「負荷試験」を実施します。このとき、「目標RPS」を設定します。例えば、「最大ユーザー数が見込まれる時間帯に、毎秒1,000リクエスト（1,000 RPS）を処理しても、すべてのレスポンスタイムが1秒以内であること」といった具合です。

負荷試験ツール（JMeterやLoadRunnerなど）を使って、実際にサーバーに大量のリクエストを送りつけ、RPSを徐々に上げていきます。もしRPSが目標値に達する前にレスポンスタイムが急激に悪化したり、エラーが発生したりすれば、そのシステムにはボトルネックがある、という判断になります。

2. アナロジー：高速道路の料金所

RPSを理解するための分かりやすい比喩として、「高速道路の料金所」を考えてみましょう。

この料金所をシステム、料金を支払う車をリクエストと見立てます。

RPSが高い状態: 料金所のブースがたくさん開いており、車がスムーズに通過できている状態です。1秒間に多くの車（リクエスト）をさばけています。
RPSが低い状態: ブースが少なく、車線が渋滞している状態です。処理能力が低いため、車（リクエスト）が待たされてしまいます（レスポンスタイムの悪化）。
システムダウン: あまりにも車が集中しすぎた結果、料金所全体が機能停止してしまうような状況です。

料金所の運営側は、将来の交通量予測（予測アクセス量）に基づき、必要なブースの数（サーバーのスペックや台数）を計画します。これがまさに、RPSを基準にしたキャパシティプランニングなのです。このように、RPSは単なる技術的な数値ではなく、いかに効率よく処理を行うかという「運用効率」そのものを表していると理解すると、非常に腑に落ちますね。

3. モニタリングでの活用

サービス提供中も、RPSはリアルタイムでモニタリングされています。通常のRPSの変動パターン（例：平日の昼間は500 RPS、深夜は50 RPSなど）を把握しておき、異常な急上昇（DoS攻撃や予期せぬ集中アクセス）や急降下（システム障害の兆候）が発生した場合に、即座にアラートを出す設定が一般的です。これは、システムを安定稼働させるための生命線とも言える指標です。

資格試験向けチェックポイント

RPSは、特に基本情報技術者試験や応用情報技術者試験において、システムの性能評価や負荷分散の文脈で頻繁に出題されます。

1. 性能指標としての位置づけ

RPSはスループットの一種である: スループットとは「単位時間あたりの処理量」を指します。RPSは、リクエストという「処理」を単位時間（秒）で測るため、スループットの具体的な指標として正しく理解しておきましょう。
レイテンシ（遅延）との関係: RPSを高く保つためには、レイテンシ（リクエストが送信されてからレスポンスが返ってくるまでの時間）を短くする必要があります。このトレードオフの関係性を問う問題は頻出です。

2. 計算問題のパターン

基本的なRPSの計算式（総リクエスト数÷時間）を理解しておくことが重要です。

例: 「あるサーバーが1分間に36,000件のトランザクションを処理した場合のRPSを求めよ。」
- 36,000件 ÷ 60秒 = 600 RPS
- このように、時間単位の換算ミスを誘う問題が多いので、必ず秒に直す習慣をつけましょう。

3. キャパシティプランニングの知識

ITパスポートや基本情報技術者試験では、RPSを用いて必要なサーバー台数やネットワーク帯域を計算させる、キャパシティプランニングの基礎知識が問われます。

「現状のサーバー1台あたりの最大RPSが100であるとき、目標とするRPS 500を達成するには最低何台必要か？」といった、非常に実践的な応用力が試されます。

4. 関連用語の識別

RPSと混同しやすい用語として、TPS（Transactions per second）があります。RPSが個々のHTTPリクエスト単位で計測されることが多いのに対し、TPSはより複雑な「一連の業務処理」（例：銀行口座からの引き落としと振り込みを完了させる一連の流れ）を単位として計測されます。どちらも「トランザクション指標」に属しますが、その定義域の違いを理解しておくと、試験で有利になります。