SAP-C02-122 · セクション 14 / タスク 3.3

Business RequirementをSLA / KPIへ変換する

ビジネス要件 / SLA / KPI / レイテンシー / スループット / 可用性 / 測定可能な目標値

既存ソリューションのパフォーマンスを改善するとき、最初からCPU、メモリ、I/Oなどの内部状態を分析するのではありません。

まず確認するのは、ビジネスとして何を成功とするのかです。

ビジネス要件
↓
成功条件
↓
KPI
↓
目標値
↓
必要ならSLA

このページでは、曖昧なビジネス要件を、関係者が同じ基準で評価できるKPI・目標値・SLAへ変換する判断を扱います。

レイテンシーやスループット自体の意味、詳細なパフォーマンス目標の作り方、ベースラインやボトルネック分析はここでは再講義しません。

ゴール

ビジネス要件から成功条件を取り出せる
成功条件に対応するKPIを選べる
1つのビジネス要件を複数KPIへ分解できる
内部KPIと顧客とのSLAを区別できる
KPIに測定可能な目標値を設定する必要性を説明できる
SLAが可用性だけに限定されないことを判断できる
SLAの対象範囲と評価期間を明確にできる
ビジネス要件からKPI・目標値・SLAまでの対応関係を保持できる
内部KPI未達とSLA違反を別基準で判定できる

1. ビジネス要件から始める

例えば、ECサイトで次の要件があるとします。

大型キャンペーン中も
購入離脱を増やさず
必要な注文量を処理し
注文機能を利用可能に保つ

この文章には複数の成功条件が含まれています。

購入処理が遅すぎない
+
必要な処理量をさばける
+
注文機能を利用できる

この段階で重要なのは、AWSサービスを先に選ぶことではありません。

「何を満たせばビジネス要件を達成したと言えるか」を分解し、その成功条件を測定できる形へ変換します。

2. 1つのビジネス要件に複数KPIが必要なことがある

上の例では、成功条件ごとにKPIの候補が異なります。

成功条件	KPIの候補
購入処理が遅すぎない	レイテンシー
必要な注文量を処理できる	スループット
注文機能を利用できる	可用性

つまり、

1つのビジネス要件
=
1つのKPI

とは限りません。

複数の成功条件を持つ要件なら、要件達成を確認するために複数のKPIが必要になる場合があります。

3. KPIは「成功しているか」を継続的に確認する指標

KPIは、ビジネス要件や成功条件に対して、現在の状態が期待どおりかを確認するために使います。

例えば注文サービスなら、

注文APIの応答時間
注文成功率
必要な注文処理量
注文機能の可用性

などを内部KPIとして継続的に監視できます。

重要なのは、取得できるメトリクスを無条件にKPIへ昇格させることではなく、どの成功条件を確認するためのKPIなのかを明確にしておくことです。

4. KPIには測定可能な目標値が必要

KPIを選んだだけでは、要件を満たしたか判定できません。

注文APIのレイテンシーを監視する

だけでは、何をもって成功とするのかが未定です。

そこで、関係者が同じ結論を出せるように、KPIへ測定可能な目標値を対応付けます。

KPI
+
測定可能な目標値
↓
達成 / 未達を判定できる

ここでの責任は、ビジネス上の成功条件を数値で判定可能にするところまでです。詳細な負荷条件や統計方法を含むパフォーマンス目標の作り方は既習として扱います。

5. KPIとSLAは同じものではない

内部で監視するKPIと、顧客など外部関係者と合意するSLAは目的が異なります。

観点	KPI	SLA
主な目的	目標達成や改善状況を内部で判断する	提供するサービス水準を関係者間で合意する
利用例	注文API応答時間、注文成功率	顧客と合意した月間可用性など
未達時の扱い	改善判断や運用上の対応へつなげる	合意した条件に基づきSLA違反を判断する

同じ指標を内部KPIとして監視しながら、別途顧客と合意した水準をSLAとして扱うこともできます。

6. SLAは可用性だけに限定されない

SLAというと、

月間可用性 99.95%

のような可用性条件を思い浮かべやすいですが、合意対象は可用性だけとは限りません。

例えば顧客との契約で、

購入APIの応答時間を
合意した水準以内に保つ

ことを明示するなら、その性能条件もサービスレベルの合意対象になり得ます。

したがって、

SLA
=
可用性だけ

とは判断しません。

7. SLAは数値だけ決めても完成しない

例えば、

可用性 99.95%

という値だけでは、どの範囲をどの期間で評価するのかが分かりません。

少なくとも、

対象サービス
+
評価期間
+
合意する水準

を明確にし、同じ条件で達成・違反を判断できるようにします。

数値の厳しさだけでなく、何に対する数値なのかを定義することが重要です。

8. 内部KPIのしきい値と外部SLAの違反条件は分ける

運用上は、顧客SLAより厳しい内部KPIを設定する場合があります。

内部KPI
↓
早めに悪化を検知して改善するための基準

顧客SLA
↓
外部と合意したサービス水準を判定する基準

そのため、内部KPIが未達になったからといって、自動的に顧客SLA違反になるとは限りません。

逆に、SLA違反にはまだ達していなくても、内部KPI未達なら改善候補として扱えます。

9. ビジネス要件からSLAまでの対応関係を残す

改善案を比較するとき、KPIやSLAが単独で存在すると、後から「何のための数値か」が分からなくなります。

そこで、

ビジネス要件
↓
成功条件
↓
KPI
↓
目標値
↓
必要なSLA

という対応関係を保持します。

これにより、改善案がどのビジネス成果へ寄与するのか、どの数値が変われば要件達成に近づくのかを追跡できます。

10. よくある誤判断

誤判断	正しい判断
1つのビジネス要件にはKPIを1つだけ設定する	複数の成功条件があれば複数KPIへ分解する
KPIを選べば要件達成を判定できる	測定可能な目標値まで対応付ける
KPIとSLAは同義	内部判断と外部合意という目的を分ける
SLAは可用性だけ	合意するサービス水準によって性能条件も対象になり得る
99.95%という値だけでSLAが完成する	対象サービスと評価期間を含めて定義する
内部KPI未達なら即SLA違反	それぞれの基準で別に判定する

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

ビジネス要件を確認
        ↓
何を満たせば成功？
        ↓
成功条件を分解
        ↓
どのKPIで確認する？
        ↓
どの水準なら達成？
        ↓
測定可能な目標値
        ↓
外部と合意する必要がある？
        ↓
必要ならSLAへ
        ↓
要件 → KPI → 目標値 → SLA
の対応関係を保持

サービスや改善手段を先に選ぶのではなく、ビジネス要件を測定可能な判断基準へ変換してから改善案を比較します。

まとめ

ビジネス要件は、そのままではパフォーマンス改善の成否を判定できないことがあります。

そこで、

ビジネス要件
↓
成功条件
↓
KPI
↓
測定可能な目標値
↓
必要ならSLA

へ変換します。

1つの要件に複数KPIが必要な場合があり、内部KPIと外部SLAは目的と判定基準を分けます。また、SLAは可用性だけに限定せず、対象範囲・評価期間・合意水準を明確にします。

SAP-C02では、「どのメトリクスを取れるか」ではなく、「何を成功とし、それをどのKPI・目標値・SLAで判定するか」を先に決めることが重要です。

主要AWS公式資料

AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.3
AWS Well-Architected Framework — 主要業績評価指標（KPI）をビジネス目標へ結び付ける考え方
AWS Well-Architected Framework — Service Level Agreements（SLA）とワークロード目標

理解確認

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

理解確認6問へ →