クラウド時代にもTPS、CPU、メモリ、IOPSの算出は必要か？

性能と容量の算出について話すと、いつも似たような質問が出ます。

「TPSはどれくらいに設定すべきですか？」
「CPUは何個必要ですか？」
「メモリはどれくらい必要ですか？」
「IOPSはどのように計算しますか？」
「同時接続者500人を受け入れるには、サーバーは何台必要ですか？」

しかし、実務をしてみると、こんな考えが浮かびます。

どうせ計算しても間違えるのではないか？

その通りです。ほとんどの場合、間違えます。

特に、サービスがまだ作られていない状態や、実際のユーザーの行動パターンが分からない状態で計算されたTPS、CPU、メモリ、IOPS、ネットワークの数値は、ほとんど正確ではありません。

では、クラウドではこのような計算をしなくても良いのでしょうか？

「クラウドはAuto Scalingができるから、ただ拡張可能にすれば良いのではないか？」
「どうせ間違える計算なら、最初から深く悩まなくても良いのではないか？」

この質問に対する私の考えはこうです。

正確な容量算出は不可能に近い。

しかし、容量算出自体が無意味なわけではない。

容量算出は、正解を当てるための計算ではなく、仮定を数値で示し、検証可能な初期設計を作成するためのプロセスである。

1. 容量算出はなぜ頻繁に間違えるのか？

容量算出が間違える最大の理由は、計算式が不足しているからではありません。

入力値が不正確だからです。

例えば、次のような要件があると仮定してみましょう。

전체 사용자 3,000명
동시 접속자 500명
이 사용자를 처리할 수 있는 아키텍처 설계

一見すると、かなり明確に見えます。

しかし、この情報だけではTPSを計算することはできません。

なぜなら、「同時接続者500人」という言葉が実際に何を意味するのか不明確だからです。

500人がログインだけして画面を見ている状態かもしれません。

500人が30秒に1回ボタンを押している状態かもしれません。

500人が1秒に1回APIリクエストを送っている状態かもしれません。

ユーザー1人の業務リクエストが内部的にAPIを1つ呼び出すこともあれば、APIを5つ呼び出すこともあります。

つまり、同時接続者数だけでは実際の負荷を知ることはできません。


条件	実際の負荷
500人がログインのみ維持	TPSが非常に低い
500人が30秒ごとに1回リクエスト	約16.7 TPS
500人が10秒ごとに1回リクエスト	約50 TPS
500人が1秒ごとに1回リクエスト	約500 TPS
業務1件が内部APIを5つ呼び出す	API基準で最大2,500 RPSが可能

そのため、容量算出の最初の段階は、サーバーのスペックを選ぶことではありません。

要件をより正確な負荷モデルに変換することです。

2. 同時接続者とTPSは異なる

性能算出で最もよくある誤解はこれです。

同時接続者500人 = 500 TPS

このように見てはいけません。

同時接続者は、特定の時点でシステムに接続しているユーザー数です。
TPSは、1秒あたりに処理される業務トランザクション数です。
RPSは、1秒あたりのAPIリクエスト数です。

この3つは互いに異なります。

전체 사용자 수: 서비스를 사용할 수 있는 전체 사용자 규모
동시 접속자 수: 특정 시점에 접속 중인 사용자 수
TPS: 초당 처리되는 업무 트랜잭션 수
RPS: 초당 API 요청 수

性能モデリングでは、同時性、スループット、滞留時間の関係を説明する際に、リトルの法則をよく参照します。リトルの法則は、システム内の平均作業数Lが、到着率λと平均滞留時間Wの積であるという関係を説明します。つまり、L = λWの形で表現されます。

実務では、これを次のように単純化して使用できます。

업무 TPS ≒ 동시 사용자 수 / (평균 응답시간 + Think Time)

API RPS ≒ 업무 TPS × 업무 1건당 API 호출 수

DB QPS ≒ 업무 TPS × 업무 1건당 DB 쿼리 수

ここでThink Timeは、ユーザーが次の行動を起こすまでに待つ時間です。

例えば、ユーザーがリストを見て、内容を読み、次のボタンを押すまでにかかる時間がThink Timeです。

この値を無視すると、実際よりもはるかに過度なTPSが計算されます。

3. クラウドでは計算せずに拡張可能にすれば良いのか？

半分は正しく、半分は間違っています。

クラウド環境では、以前のようにサーバーを正確に何台購入すべきかといった容量算出の重要性は低下しました。

Auto Scaling、Managed Database、Load Balancer、CDN、Queue、Serverlessなどのサービスを活用すれば、需要の変化にずっと柔軟に対応できます。

しかし、だからといって計算が不要なわけではありません。

計算が必要な理由は次のとおりです。

초기 인프라 규모를 정하기 위해
Auto Scaling의 최소/최대 용량을 정하기 위해
비용 범위를 예측하기 위해
DB, Storage, Network 병목을 미리 찾기 위해
부하테스트 기준을 만들기 위해
요구사항을 검증 가능한 숫자로 바꾸기 위해

AWS Well-Architectedの性能効率性の観点からも、クラウドのリソースを効率的に使用して性能要件を満たし、その効率性を維持することが重要な原則として扱われています。

また、AWSはクラウド負荷テストを、予想されるユーザー負荷を現実的な条件で測定し、本番環境に近い環境でメトリクスを分析するプロセスとして説明しています。つまり、計算だけで終わらせるのではなく、実際と類似した環境で負荷をかけ、検証する必要があるという意味です。

したがって、クラウドでの容量算出は次のように捉えるべきです。

정확한 예측: 거의 불가능
대략적인 초기 산정: 필요
확장 가능한 설계: 필수
부하테스트 검증: 필수
운영 지표 기반 보정: 필수

4. 3,000ユーザーと同時接続者500人の例

では、例を挙げてみましょう。

要件は次のとおりです。

전체 사용자: 3,000명
피크 동시 접속자: 500명

ここに次の仮定を追加します。

사용자 1명은 평균 10초에 한 번 주요 업무 요청을 수행
업무 1건은 내부 API 4개를 호출
업무 1건당 DB read 3회
업무 1건당 DB write 1회
평균 응답 크기 50KB
평균 요청 크기 5KB
피크 여유 계수 2배

すると、業務TPSは次のように計算できます。

업무 TPS = 500명 / 10초 = 50 TPS

業務1件が内部的にAPIを4つ呼び出す場合、API RPSは次のとおりです。

API RPS = 50 TPS × 4 = 200 RPS

ピーク余裕係数2倍を反映すると次のとおりです。

피크 API RPS = 200 × 2 = 400 RPS

DBリクエスト量は次のように計算できます。

DB read/sec = 50 TPS × 3 × 2 = 300 read/sec
DB write/sec = 50 TPS × 1 × 2 = 100 write/sec

Network Outは次のように計算できます。

Network Out = 400 RPS × 50KB
            = 20,000KB/s
            ≒ 20MB/s
            ≒ 160Mbps

この値は正解ではありません。

しかし、設計の出発点としては十分に意味があります。

これで私たちは漠然と「500人同時接続可能にしてください」と言うのではなく、次のように言えるようになります。

피크 기준 약 400 API RPS를 처리할 수 있어야 한다.
DB는 초당 read 300회, write 100회 수준을 초기 기준으로 본다.
응답 트래픽은 약 160Mbps 이상을 예상한다.
이 값은 부하테스트를 통해 검증하고 보정한다.

このように変えることが容量算出の核心です。

5. CPUはどのように算出するか？

CPUの算出は、計算式だけで正確に当てるのは困難です。

アプリケーション言語、フレームワーク、クエリ方式、キャッシュ使用の有無、JSONシリアル化コスト、暗号化、外部API呼び出しの有無によって大きく異なります。

そのため、CPUは通常、次の方法で算出します。

1. 기준 인스턴스 또는 컨테이너를 정한다.
2. 부하테스트를 통해 해당 단위가 처리 가능한 RPS를 측정한다.
3. 목표 RPS를 단위 처리량으로 나눈다.
4. 장애, 배포, 피크 여유를 반영한다.

例えば、次のようなテスト結果が出たと仮定してみましょう。

2 vCPU / 4GB 컨테이너 1개
CPU 사용률 60~70%
p95 응답시간 300ms 이하
에러율 1% 이하
처리량 100 RPS

前述のピークAPI RPSが400 RPSであれば、単純計算は次のとおりです。

필요 컨테이너 수 = 400 RPS / 100 RPS = 4개

しかし、実務では4個にぴったり合わせることはありません。

障害状況、デプロイ中の容量減少、特定のAZ障害、トラフィック急増を考慮して余裕を持たせます。

평상시 최소 용량: 2~3개
피크 예상 용량: 4~6개
Auto Scaling 최대 용량: 8~10개

このように設計するのが現実的です。

6. メモリはどのように算出するか？

メモリはアプリケーションの構造によって大きく異なります。

おおよその計算式は次のとおりです。

필요 Memory =
OS/Runtime 기본 사용량
+ 애플리케이션 Heap
+ 커넥션/세션당 메모리
+ 내부 캐시
+ 버퍼 20~30%

しかし、クラウドアーキテクチャにはより重要な原則があります。

アプリケーションサーバーは可能な限りステートレスに設計すべきである。

セッションをサーバーメモリに保存すると、サーバー数を増やすのが難しくなります。

特定のユーザーのセッションが特定のサーバーに紐付けられるためです。

したがって、セッション情報は次のような方法で分離するのが良いでしょう。

JWT
Redis / ElastiCache
Database Session Store
외부 인증 서비스

こうすることで、APIサーバーはいつでも増減できます。

クラウドで拡張可能な構造を作るには、メモリ算出よりも先に状態管理方式を点検する必要があります。

7. IOPSはどのように算出するか？

IOPSの算出は特に注意が必要です。

DBクエリ数とディスクIOPSは1対1で対応しません。

SELECT 1回が常にディスクリード1回を意味するわけではありません。

キャッシュに上がっていればディスクを読み込まないこともありますし、逆にジョイン、ソート、一時テーブル、インデックスアクセスによってより多くのI/Oが発生することもあります。

書き込みも同様です。

INSERTまたはUPDATE 1回が単純なIOPS 1回で終わるわけではありません。

トランザクションログ、インデックス更新、レプリケーション、チェックポイント、ストレージ層の動作まで影響を受けます。

そのため、初期のIOPS算出は次のようなレベルでアプローチするのが良いでしょう。

DB read/sec = 업무 TPS × 업무당 read 쿼리 수 × 피크 계수
DB write/sec = 업무 TPS × 업무당 write 쿼리 수 × 피크 계수
예상 IOPS = read/write 요청량 × 보정계수

例えば、前の例では次のとおりです。

업무 TPS: 50
피크 계수: 2
업무당 read: 3
업무당 write: 1

read 요청 = 50 × 2 × 3 = 300/sec
write 요청 = 50 × 2 × 1 = 100/sec

この値は、DBインスタンスとストレージを選択する初期基準です。

最終的な判断は、必ずDBモニタリングと負荷テストで行う必要があります。

確認すべき指標は次のとおりです。

DB CPU 사용률
DB Connection 수
Read IOPS / Write IOPS
Disk Queue Depth
Buffer Cache Hit Ratio
Slow Query
Lock Wait
Replication Lag
p95 / p99 Query Latency

DBはアプリケーションサーバーのように無限に簡単に増やせる領域ではありません。

したがって、クラウド設計においてもDBのボトルネックは必ず別途扱う必要があります。

8. ネットワークはどのように算出するか？

ネットワークの計算は比較的単純です。

Network Out = RPS × 평균 응답 크기
Network In = RPS × 평균 요청 크기

例えば、次のようだと仮定してみましょう。

피크 API RPS: 400
평균 응답 크기: 50KB
평균 요청 크기: 5KB

すると、次のように計算できます。

Network Out = 400 × 50KB = 20,000KB/s ≒ 160Mbps
Network In = 400 × 5KB = 2,000KB/s ≒ 16Mbps

ただし、ここには注意点があります。

静的ファイル、画像、動画、添付ファイルのダウンロードがAPIサーバーを経由して行われると、ネットワーク算出が大きく変わります。

そのため、一般的なクラウドアーキテクチャでは、静的リソースを次のように分離します。

정적 파일: S3 또는 Object Storage
전송 최적화: CloudFront / CDN
동적 요청: API Server

こうすることで、APIサーバーはビジネスロジック処理に集中し、大容量トラフィックはCDNとオブジェクトストレージが担当することになります。

9. Auto Scalingは計算を代替しない

Auto Scalingがあるから計算は不要だと考えるかもしれません。

しかし、Auto Scalingにも基準が必要です。

AWS EC2 Auto Scalingのターゲット追跡ポリシーは、CPU使用率、ネットワーク、ALBリクエスト数/ターゲット、ユーザー定義のCloudWatchメトリクスなどの目標指標を基準に容量を調整します。AWSドキュメントでは、ターゲット追跡が目標メトリクス値に基づいてAuto Scalingグループの容量を自動調整すると説明されています。

つまり、Auto Scalingを設定するには、次の質問に答える必要があります。

CPU 60%를 목표로 할 것인가?
ALB RequestCountPerTarget 100을 목표로 할 것인가?
p95 응답시간을 Custom Metric으로 쓸 것인가?
최소 인스턴스 수는 몇 개인가?
최대 인스턴스 수는 몇 개인가?
Scale-out은 얼마나 빠르게 할 것인가?
Scale-in은 얼마나 보수적으로 할 것인가?

結局、Auto Scalingも容量算出の結果を必要とします。

ただし、違いがあります。

以前の方式の容量算出は「サーバー何台で十分か？」に近いものでした。

クラウド方式の容量算出は「どのような基準でどれだけ拡張し、どの時点でボトルネックが生じるか？」に近いものです。

10. 3,000ユーザー / 同時接続者500人基準の推奨アーキテクチャ

要件が「3,000ユーザー、同時接続者500人」であれば、次のような構造を基本アーキテクチャとして提案できます。

사용자
  ↓
Route 53 / DNS
  ↓
CloudFront + WAF
  ↓
Application Load Balancer
  ↓
ECS / EKS / Auto Scaling Group
  ↓
Stateless API Server
  ↓
Redis / ElastiCache
  ↓
RDS / Aurora Multi-AZ
  ↓
S3 / Object Storage

非同期処理が必要な業務がある場合は、次の構成を追加します。

API Server
  ↓
SQS / EventBridge / Kafka
  ↓
Worker Auto Scaling
  ↓
Database / External API

核心は、すべてのリクエストを同期処理に押し込まないことです。

例えば、次のような作業は非同期化の対象です。

이메일 발송
문자 발송
대용량 리포트 생성
이미지 처리
외부 API 연동
결제 후 후속 처리
로그 분석
AI 추론 작업

このような作業をキューベースで分離することで、ユーザーが感じる応答時間を短縮し、瞬間的なトラフィックもより安定的に吸収できます。

Google Cloud Well-Architected Frameworkも、セキュリティ、効率性、復元性、高性能、コスト最適化、持続可能性の観点からクラウドトポロジーを設計および運用するための推奨事項を提供しています。結局、クラウドアーキテクチャは性能だけでなく、コスト、運用、安定性まで一緒に考慮する必要があります。

11. どのように扱うのが良いか？

もし「TPS、CPU、メモリ、IOPS、ネットワークを計算して、3,000ユーザーと同時接続者500人を処理するアーキテクチャを設計せよ」というテーマで講演依頼を受けた場合、単純な計算式に頼るのは危険です。

実務的には次の流れが良いでしょう。

1. 사용자 수와 동시 접속자의 차이
2. 동시 접속자를 TPS/RPS로 변환하는 방법
3. 업무 시나리오 정의
4. API 호출 수, DB 쿼리 수, 응답 크기 추정
5. CPU, Memory, IOPS, Network 초기 산정
6. 확장 가능한 클라우드 아키텍처 설계
7. Auto Scaling 정책 설계
8. 부하테스트 수행
9. 병목 분석
10. 비용과 안정성 균형 조정

必ず強調すべきメッセージはこれです。

容量算出は正解を当てる問題ではない。

仮定を立て、数値で表現し、負荷テストで検証し、運用指標で補正するプロセスである。

特に「同時接続者500人」という要件は、次の質問に分解する必要があります。

500명은 로그인 세션 기준인가, 활성 사용자 기준인가?
사용자는 몇 초마다 요청하는가?
업무 1건은 API 몇 개를 호출하는가?
API 1건은 DB 쿼리를 몇 번 발생시키는가?
평균 응답 크기는 얼마인가?
p95 응답시간 목표는 얼마인가?
장애 상황에서도 500명을 처리해야 하는가?
피크는 5분인가, 1시간인가, 하루 종일인가?
정적 파일 트래픽은 API 서버가 처리하는가, CDN이 처리하는가?

これらの質問に答えずにCPU、メモリ、IOPSから計算すると、ほとんどの場合、意味のない数字になります。

12. 簡単な容量算出コード

講義や実習では、以下のような簡単な計算機を作成して見せると良いでしょう。

import math

def estimate_capacity(
    concurrent_users: int,
    think_time_sec: float,
    avg_response_time_sec: float,
    api_calls_per_business_tx: int,
    peak_factor: float,
    avg_response_kb: float,
    avg_request_kb: float,
    db_reads_per_tx: int,
    db_writes_per_tx: int,
    rps_per_app_instance_at_target: int,
    ha_buffer: float = 1.25,
):
    # 業務TPSの計算
    # ユーザーがリクエスト後、次のリクエストまで待つ時間を含む
    business_tps = concurrent_users / (think_time_sec + avg_response_time_sec)

    # API RPSの計算
    api_rps = business_tps * api_calls_per_business_tx

    # ピーク係数を反映
    peak_api_rps = api_rps * peak_factor

    # DBリクエスト量の計算
    db_read_per_sec = business_tps * db_reads_per_tx * peak_factor
    db_write_per_sec = business_tps * db_writes_per_tx * peak_factor

    # ネットワーク帯域幅の計算
    network_out_mbps = peak_api_rps * avg_response_kb * 8 / 1024
    network_in_mbps = peak_api_rps * avg_request_kb * 8 / 1024

    # アプリインスタンス数の計算
    required_instances = math.ceil(
        (peak_api_rps / rps_per_app_instance_at_target) * ha_buffer
    )

    return {
        "business_tps": round(business_tps, 2),
        "api_rps": round(api_rps, 2),
        "peak_api_rps": round(peak_api_rps, 2),
        "db_read_per_sec": round(db_read_per_sec, 2),
        "db_write_per_sec": round(db_write_per_sec, 2),
        "network_out_mbps": round(network_out_mbps, 2),
        "network_in_mbps": round(network_in_mbps, 2),
        "required_app_instances": required_instances,
    }

result = estimate_capacity(
    concurrent_users=500,
    think_time_sec=10,
    avg_response_time_sec=0.5,
    api_calls_per_business_tx=4,
    peak_factor=2,
    avg_response_kb=50,
    avg_request_kb=5,
    db_reads_per_tx=3,
    db_writes_per_tx=1,
    rps_per_app_instance_at_target=100,
)

for key, value in result.items():
    print(f"{key}: {value}")

予想される結果は次のようになります。

business_tps: 47.62
api_rps: 190.48
peak_api_rps: 380.95
db_read_per_sec: 285.71
db_write_per_sec: 95.24
network_out_mbps: 148.81
network_in_mbps: 14.88
required_app_instances: 5

この結果を見て「サーバーは必ず5台で十分だ」と判断してはいけません。

この値は初期仮定に基づく出発点です。

実際の講義では、この値を基準に負荷テストを実施し、次の指標を観察する形で進めると良いでしょう。

CPUUtilization
MemoryUtilization
RequestCount
TargetResponseTime
HTTPCode_ELB_5XX
HTTPCode_Target_5XX
DB CPU
DB Connections
ReadIOPS / WriteIOPS
p95 / p99 Latency
Queue Depth

結論：計算は間違える。それでも計算は必要だ。

性能と容量の算出は、ほとんどの場合間違えます。

特に、実際のユーザー行動、データサイズ、クエリパターン、コード性能を知らない状態で計算された値は、正解にはなり得ません。

しかし、だからといって容量算出が無用なわけではありません。

クラウド時代の容量算出は、サーバー数を正確に合わせる作業ではありません。

仮定を数値で示し、アーキテクチャ設計の基準線を作成し、負荷テストと運用指標で検証するためのプロセスです。

まとめると次のとおりです。

계산만 믿으면 위험하다.
계산 없이 설계하면 더 위험하다.
클라우드에서는 확장 가능하게 설계해야 한다.
하지만 확장 기준을 만들기 위해 초기 산정은 반드시 필요하다.
최종 답은 계산식이 아니라 부하테스트와 운영 데이터가 준다.

したがって、「3,000ユーザーと同時接続者500人を処理するアーキテクチャ」を設計する際には、このようにアプローチするのが最も現実的です。

1. 동시 접속자를 TPS/RPS로 변환한다.
2. 업무 시나리오와 API 호출 구조를 정의한다.
3. CPU, Memory, IOPS, Network를 초기 산정한다.
4. Stateless, CDN, Cache, Queue, Auto Scaling 기반으로 설계한다.
5. 부하테스트로 검증한다.
6. 운영 지표를 보고 보정한다.

正確に当てるのが目標ではありません。

間違えることを前提に、早く検証し、安全に拡張できる構造を作ることが目標です。