SAP-C02-081 · セクション 10 / タスク 2.5

Performance Objectiveを測定可能な指標へ落とす

レイテンシー / スループット / IOPS / リクエストレート / 同時実行数 / パフォーマンス目標

ゴール

「速いシステムにしたい」

「大量アクセスに耐えたい」

「ストレージ性能を高くしたい」

これだけでは、構成候補を比較できません。

例えば、

レスポンスを速くしたい

という要求でも、

何の処理を
どの負荷で
何ミリ秒以内に
何%のリクエストについて
達成するのか

によって必要な設計は変わります。

パフォーマンス設計では、曖昧な要求を、

業務目標
↓
対象処理
↓
負荷条件
↓
測定する指標
↓
統計方法
↓
閾値
↓
測定可能なパフォーマンス目標

へ変換します。

目標は、「性能が高い」ではなく、「どの状態なら性能要件を満たしたと言えるか」を数値で表せることです。

1. 指標と目標値を分ける

最初に、

何を測るか

と、

どの値なら合格か

を分けます。

例えば、

レイテンシー

は指標です。

一方、

ピーク時3,000リクエスト/秒の負荷で
決済APIのp95レイテンシーを
300ミリ秒以下にする

はパフォーマンス目標です。

つまり、

要素	例
対象	決済API
負荷条件	3,000リクエスト/秒
指標	レイテンシー
統計方法	p95
閾値	300ミリ秒以下

まで決めることで、構成候補を比較できる状態になります。

2. レイテンシーは「1回の処理にどれだけ時間がかかるか」

レイテンシーは、ある処理の開始から完了までにかかる時間を表します。

例えば、

API要求
↓
処理
↓
応答

について、

250ミリ秒

というように表します。

ただし、「レイテンシー300ミリ秒以下」だけでは不十分な場合があります。

どこからどこまでを測るのかを明確にします。

利用者
↓
API
↓
アプリケーション
↓
データベース
↓
利用者へ応答

全体を対象とするのか、

アプリケーション
↓
データベース

だけを対象とするのかで意味が変わります。

したがって、

対象範囲
+
時間

を組み合わせて定義します。

3. 平均値だけでは遅いリクエストを隠すことがある

次の結果を考えます。

平均レイテンシー
150ミリ秒

p99レイテンシー
1,200ミリ秒

平均だけを見ると高速に見えます。

しかしp99が1,200ミリ秒なら、一部の利用者は大幅に遅い応答を経験しています。

そのため、

平均300ミリ秒以下

と、

p99 300ミリ秒以下

は同じ要件ではありません。

例えば、

リクエストの99%を
500ミリ秒以内に完了する

なら、

p99レイテンシー
≤ 500ミリ秒

という形で評価できます。

パフォーマンス目標では、平均なのか、最大なのか、p95 / p99などのパーセンタイルなのかまで確認します。

4. スループットは「一定時間にどれだけ処理できるか」

スループットは、単位時間あたりに完了できる仕事量やデータ量を表します。

例えば、

500 MB/s

10,000レコード/秒

2TBを60分以内

などです。

夜間バッチについて、

1件を100ミリ秒以内

よりも、

午前6時までに2TBすべてを処理

が重要なら、中心となる判断軸はスループットです。

つまり、

1処理の速さ
→ レイテンシー

一定時間に完了する総量
→ スループット

と分けます。

5. IOPSとスループットは同じではない

ストレージでは、

IOPS

と、

スループット

を混同しないことが重要です。

IOPSは、1秒あたりの入出力操作数です。

例えば、

8 KiBのランダムI/O
25,000回/秒

なら、操作回数が重要なのでIOPSが主要な指標になります。

一方、

大きなデータを
連続して高速転送する

場合は、MB/sやGB/sなどのスループットが重要になることがあります。

概念的には、

I/O操作数
×
1回のI/Oサイズ
↓
転送されるデータ量

という関係があります。

そのため、

IOPSが高い
=
必ずスループットも十分

ではありません。

逆も同様です。

ここでは必要な性能を数値化するところまでとし、その数値からどのストレージ方式を選ぶかは別の判断として扱います。

6. リクエストレートは「どれだけ要求が入ってくるか」

リクエストレートは、単位時間あたりに到着する要求数を表します。

例えば、

8,000リクエスト/秒

です。

これはシステムへ与えられる負荷を表す重要な条件です。

例えば、

p95レイテンシー
≤ 200ミリ秒

という目標があっても、

10リクエスト/秒

での結果と、

10,000リクエスト/秒

での結果では意味が違います。

そのため、

10,000リクエスト/秒でも
p95レイテンシー
≤ 200ミリ秒

のように、負荷条件とレイテンシー条件を組み合わせて評価する必要があります。

7. リクエストレートとスループットを混同しない

APIでは、どちらも「1秒あたり○件」と表せることがあります。

しかし意味は異なります。

リクエストレート
→ システムへ入ってくる要求量

スループット
→ システムが完了できる仕事量

例えば、

到着
10,000リクエスト/秒

完了
6,000リクエスト/秒

なら、

リクエストレート
10,000/秒

スループット
6,000/秒

となります。

正常状態で待ち行列や制限がほとんどなければ、近い値になる場合があります。

しかし、

処理能力不足
スロットリング
待ち行列
下流依存の遅延

などがあると、両者は一致しません。

8. 同時実行数は「今いくつ処理中か」

同時実行数は、同時に処理中で、まだ完了していない仕事の数を表します。

例えば、

平均リクエストレート
4,000リクエスト/秒

平均処理時間
0.25秒

の安定した処理では、

4,000
×
0.25
≈
1,000

となり、概算で約1,000件が同時処理中になります。

つまり、

リクエストレート

と、

同時実行数

は同じ数字ではありません。

同じ4,000リクエスト/秒でも、

平均処理時間
0.1秒

なら同時実行数は小さくなり、

平均処理時間
2秒

なら大きくなります。

9. 同時利用者数・リクエストレート・同時実行数を分ける

「5,000人が同時に利用している」という情報だけから、

5,000リクエスト/秒

とは判断できません。

同時利用者数は、その時点でサービスを利用している利用者数です。

一方、リクエストレートは、その利用者たちが単位時間あたりに何回要求を送るかで決まります。

例えば5,000人が同時利用していて、

1利用者あたり
平均10秒に1回要求

するなら、概算では、

5,000
÷
10秒
=
500リクエスト/秒

です。

さらに、平均処理時間が0.2秒なら、

500リクエスト/秒
×
0.2秒
≈
100

となり、サーバー側では概算100件が同時実行中になります。

したがって関係は、

同時利用者数
+
1利用者あたりの要求頻度
↓
リクエストレート

リクエストレート
+
平均処理時間
↓
同時実行数

と分けます。

処理時間はリクエストレートを決める条件ではなく、リクエストレートから同時実行数を見積もる条件です。

10. リソース指標と業務パフォーマンスを分ける

次の2つは意味が違います。

CPU使用率
60%

注文APIのp95レイテンシー
250ミリ秒

CPU使用率は、システム内部の状態を理解するために有用です。

しかし利用者が求めているのが、

注文を300ミリ秒以内に完了

であれば、CPU使用率だけでは要件達成を判断できません。

例えば、

CPU 30%

でも、

データベース待ち
外部API待ち
ストレージI/O待ち

によって利用者の応答が遅いことがあります。

したがって、

内部リソースの状態

と、

業務・利用者から見たパフォーマンス

を分けます。

CPU使用率やメモリ使用率などの内部指標は原因分析に役立ちますが、パフォーマンス要件の達成判定は、業務目標と直接結び付いた指標で行います。

11. パフォーマンス目標の基本形

実際のシナリオでは、次の形に落とすと判断しやすくなります。

対象
+
負荷条件
+
指標
+
統計方法
+
閾値

例えば、

決済API

ピーク時
3,000リクエスト/秒

エンドツーエンドレイテンシー

p95

300ミリ秒以下

です。

これを1文にすると、

ピーク時3,000リクエスト/秒の負荷で、
決済APIのエンドツーエンドレイテンシーを
p95で300ミリ秒以下にする

となります。

別のワークロードなら、

夜間バッチ
↓
2TB
↓
60分以内

のように、スループットを中心とした目標になります。

また、

小さいランダムI/O
↓
25,000 IOPS

のように、IOPSが中心となる場合もあります。

同じ「高性能」という要求でも、測る指標はワークロードによって変わります。

12. 1つのワークロードに複数の目標が必要なこともある

例えばAPIについて、

p95レイテンシー
≤ 200ミリ秒

だけを設定しても、負荷条件がなければ十分ではありません。

逆に、

10,000リクエスト/秒を受付可能

だけでも、利用者が何秒待たされるか分かりません。

そのため、

10,000リクエスト/秒
+
p95レイテンシー200ミリ秒以下

のように、複数の条件を同時に設定する場合があります。

重要なのは、

指標をたくさん設定すること

ではなく、業務要件を満たしたかを判定するために必要な指標を選ぶことです。

13. よくある誤判断

誤判断	正しい判断
「高速」がパフォーマンス目標	数値で判定可能な条件へ変換する
レイテンシーの平均だけ見ればよい	要件に応じてp95 / p99など分布も確認する
IOPSとスループットは同じ	操作数とデータ量という異なる軸
リクエストレートとスループットは常に同じ	到着量と完了量を分ける
同時実行数＝リクエスト/秒	平均処理時間にも依存する
同時利用者数＝同時実行数	利用者の要求頻度と処理時間を分けて考える
CPU使用率が低ければ性能は十分	業務レベルの指標で要件達成を判定する
5,000同時利用者＝5,000リクエスト/秒	1利用者あたりの要求頻度が必要
サービスを選んでから目標を決める	先に満たすべきパフォーマンス条件を定義する

14. SAP-C02での判断フロー

パフォーマンス要件を確認
        ↓
どの業務処理が重要？
        ↓
利用者が求めるのは
1処理の速さ？
処理総量？
I/O回数？
        ↓
レイテンシー
スループット
IOPS
を選ぶ
        ↓
どの程度の要求が来る？
        ↓
リクエストレートを定義
        ↓
平均処理時間から
必要な同時実行数を評価
        ↓
どの負荷条件で
成立する必要がある？
        ↓
平均？
p95？
p99？
        ↓
閾値を数値化
        ↓
測定可能な
パフォーマンス目標

まとめ

パフォーマンス設計では、

速い
大量アクセスに耐える
高性能なストレージ

という要求をそのまま構成選択へ使いません。

まず、

レイテンシー
スループット
IOPS
リクエストレート
同時実行数

のどの軸で表すべきかを判断します。

そのうえで、

対象
+
負荷条件
+
指標
+
統計方法
+
閾値

まで具体化します。

SAP-C02では、「どのサービスが速いか」より先に、「このワークロードで何をどこまで満たせばパフォーマンス要件を達成したと言えるか」を明確にすることが重要です。

主要AWS公式資料

AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 2.5: パフォーマンス目標を満たすソリューションを設計する
AWS Well-Architected Framework パフォーマンス効率の柱
PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する
Amazon CloudWatch メトリクスの概念
AWS Lambda 関数のスケーリングについて
Amazon EBS I/O の特性およびモニタリング

理解確認

このページの内容を7問で確認します。

理解確認7問へ →