非機能要求グレードの歩き方 Vol.2 オンライン編-B2性能目標値

30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、「やらかしがちな」技術的課題について、IPA^[1]の非機能要求グレード^[2]に沿って解説します。
※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。

本記事では、オンライン性能要件における「B.2 性能目標値」に焦点を当てて解説します。

B.2 性能目標値とオンライン性能

オンライン性能要件は、中項目「B.2 性能目標値」の中で定義します。
新規にシステムを構築する場合は、「B.1 業務処理量」に業務タスク1件あたりのオンライン取引数の目安を考慮して設定します。
既存システムを修正する場合は、現行のオンライン取引数を基に、「B.1 業務処理量」と修正内容を踏まえて設定します。

下表は、非機能要求グレード 大項目「B:性能・拡張性」-中項目「B.2:性能目標値」のうち、オンライン性能に関する項目を抜粋したものです。

項番	中項目	小項目	メトリクス (〇: 重要項目)	レベル0/1/2/3/4/5
B.2.1.1	性能目標値	オンライン レスポンス	〇通常時 レスポンス順守率	0:順守率を定めない 1: 60%　2: 80%　3: 90% 4: 95%　5: 99%以上
B.2.1.2	〃	〃	〇ピーク時 レスポンス順守率	〃
B.2.1.3	〃	〃	縮退時 レスポンス順守率	0:縮退をしない[3]: 1: 60%　2: 80%　3: 90% 4: 95%　5: 99%以上
B.2.3.1	〃	オンライン スループット	通常時 処理余裕率	0: 1倍(余裕無し) 1: 1.2倍 2: 1.5倍 3: 2倍 4: 3倍 5: 10倍以上
B.2.3.2	〃	〃	ピーク時 処理余裕率	〃
B.2.3.3	〃	〃	縮退時 処理余裕率	0: 縮退をしない 1: 通常時の1/2の処理が出来る 2: 通常時と同様に処理が出来る

非機能要件は、「小項目」ごとに、文章で「レベル」が分かるよう具体的に記述しましょう！
(再掲、大事なことなので繰り返し言います。詳細Vol.1を参照ください）

以降、小項目ごとに解説します。

B.2.1 オンラインレスポンス

	小項目 B.2.1 オンラインレスポンス
説明	オンラインシステム利用時に要求されるレスポンス。 システム化する対象業務の特性をふまえ、どの程度のレスポンスが必要かについて確認する。ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に順守率を決める。具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：Webシステムの参照系/更新系/一覧系など）
メトリクス	B.2.1.1: 通常時レスポンス順守率 B.2.1.2: ピーク時レスポンス順守率 B.2.1.3: 縮退時レスポンス順守率

レスポンスは、主に処理データ量、リクエスト頻度(スループット)、システムリソース量によって決まります。更新処理には排他待ちも影響します。

📌%ile(パーセンタイル)を定義

・レスポンス要件は、レスポンス特性が異なるオンライン取引の分類毎に定めます。
・レスポンス時間は、「レスポンス2秒(90%ile)」のように、順守率(%ile)を添えて定義する必要があります。「n秒以下」といった表現は望ましくありません。スパイク的な高負荷時でも「n秒以下」を実現するには過剰なシステムリソースが必要となるからです。
　定める時間がどこからどこまでの時間を指すのかを明確にすることも重要です。
(似た用語にTAT（ターンアラウンドタイム）やRTT（ラウンドトリップタイム）などがあります。)
・「メトリクス」にあるように、通常時、ピーク時、縮退時ごとにレスポンス要件を定めることが必要です。なお、コストが増えますがサービスレベルを重視して、ピーク時かつ縮退時の要件で他の条件を包含すると定義しても構いません。

B.2.3 オンラインスループット

	小項目 B.2.3 オンラインスループット
説明	オンラインシステム利用時に要求されるスループット。 システム化する対象業務の特性をふまえ、単位時間にどれだけの量の作業ができるかを確認する。更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に処理余裕率を決める、具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：データエントリ件数/時間、頁めくり回数/分、TPSなど）
メトリクス	B.2.3.1: 通常時処理余裕率 B.2.3.2: ピーク時処理余裕率 B.2.3.3: 縮退時処理余裕率 B.2.1.3: 縮退時レスポンス順守率

📌１分は１時間の1/60ではない

オンラインスループット要件は、ピーク１時間の取引件数やrps(リクエスト/秒)などで表現しますが、このスループットの単位時間(１時間or１分or1秒)を明確にすることが重要です。
同じrpsの値でも、平均した単位時間が１時間か１分かによって、要求スループットが異なってくるからです。

ランダムに発生するリクエスト(ポアソン過程)の単位時間あたり発生件数は、一定ではなくポアソン分布になります。
例えば、極端に集中する時刻が無く人が断続的に操作する業務(ポアソン過程相当)のレスポンス目標が数秒の場合、要求される定常処理能力(rps)は、ピーク１時間の平均rpsの数割増しになります。（参考：以下の「あったら怖い本当の話」）
なお、銀行のATMや店舗端末などの同時利用数に上限がある環境では、インターネットのような不特定多数からランダムに発生するリクエストよりも、集中度は低くなります。

あったら怖い本当の話

※　実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。

性能要件

・ピーク時: 1時間36万件、レスポンス2秒(90%ile)

性能設計

・スループット要件を、ピーク1時間のリスエスト数より100rpsと算出。

$$\begin{alignedat}{3} \textbf{1時間36万件より}&: \mathbf{100rps} &= (360,000件 / 3600秒&) \end{alignedat}$$

・結果：100rpsの定常負荷の下でレスポンス2秒を満たすように性能設計し、
　　　　100rpsの定常負荷試験を実施し、2秒越えが90%ileに収まることを確認した。

😱36万件/時に耐えるはずが、予想30万件/時の日にレスポンス遅延

予想ではピーク1時間30万件/時となる日に、33万件/時の負荷が発生し、レスポンス数十秒の処理が大量に発生し、2秒(90%ile)の要件を満たせませんでした。

敗因

業務量に相当する同時利用者数は30万件/時の際の想定どおりでしたが、レスポンス遅延によりリトライ操作が増えたことで取引量が1割増えた結果、33万件/時の取引が発生していました。
33万件/時の負荷が発生した1時間の間、定常100rpsの処理能力に対して、平均92rps、ピーク1分平均110rpsの負荷が発生していました。
100rpsを超える負荷が断続的に発生(※)したことにより、ほとんどの処理のレスポンスが数十秒となっていました。
※　例えば、ピーク1分平均110rpsのタイミングでは、10件/秒ペースで滞留が増えて600件滞留し、滞留がはけるまでの約135秒間レスポンス遅延が継続していました。）

$$\begin{alignedat}{3} \mathbf{135秒} &= ピーク1分(60秒) + 滞留600件 / (処理能力100rps - 1時間平均負荷92rps) \end{alignedat}$$

性能試験では、負荷試験ツールを用いて一定の負荷(100rps)を定常的に発生させており、実際のオンライン処理要求は一定ではなく、揺らぎ(ランダム到着の場合ポアソン分布)があること見逃していました。

再発防止

まず、過去ログを分析し、以下の集中度となっていたことを把握しました。

ピーク1時間	ピーク1時間平均負荷	ピーク1分平均負荷	1秒スパイク負荷
障害時33万件	92rps	110rps	119rps
要件　36万件	100rps	120rps	130rps

要件の「2秒90%ile」を満たす考え方として、ピーク1分の時間帯に発生した1秒スパイク取引でも3秒(2秒を若干超)以内に処理できるように、定常的に125rpsを目標に、必要な対応を実施しました。

$$\begin{alignedat}{3} \textbf{定常スループット目標}&: \mathbf{125rps} &= 120rps + (130rps -120rps) / (3-1)秒 \end{alignedat}$$

さらに、歯止めとして、月次で、ピーク日ピーク1時間の「1分集中度」と「1秒スパイク」が設計許容内に収まっているかを確認する運用を追加しました。

まとめ

本記事では、オンラインの性能目標は、性能特性の異なる取引群毎に、レスポンスには単位時間を添えて、スループットには順守率(%tile)を添える必要があることを説明しました。

最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。興味がある方は募集要領をご覧ください。（参考：NTTデータ金融分野の取り組み）

脚注

1. IPA: 独立行政法人 情報処理推進機構 (Information-technology Promotion Agency, Japan)

2. 非機能要求グレード:
   参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
   活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の　06‗活用シート.xls
   

3. 「レベル0:縮退をしない」は、障害時サービス停止すると捉えると、レスポンス順守率としては考慮不要となるので、最も容易なレベル0としていることを理解できます