DORA監査人がロードテストに期待すること

DORAの下で、ロードおよびパフォーマンステストの証拠はレジリエンスレビューの一部です。

システムがボリュームに耐えうることを示す必要があるEUの金融機関のコンプライアンスおよびエンジニアリングチーム向け。

EUのデジタル運用レジリエンス法（DORA）は2025年1月17日から金融機関に適用されています。これは、銀行、保険会社、投資会社、およびその重要なICTプロバイダーが、混乱の中でもデジタルサービスを継続するための一つのルールブックを設定します。デジタル運用レジリエンステストは五つの柱の一つ（ICTリスク管理、インシデント報告、第三者リスク、情報共有とともに）であり、その柱はあなたのロードおよびパフォーマンステストに直接関わっています。

まず一つの明確化ですが、頭字語が異なる意味を持ちます。この記事はEUの規制に関するものです。DevOpsの「DORAメトリクス」（デプロイ頻度、リードタイムなど）についてではありません。全く異なるDORAです。

規制の第25条は、レジリエンスプログラムが活用すべきテスト手法を列挙しています。パフォーマンステストとエンドツーエンドテストは脆弱性評価やペネトレーションテストと並んでそのリストにあります。したがって、審査員があなたのレジリエンステストをレビューする際、ロードおよびストレステストの証拠は妥当な対象となります。

オンライン上の多くのDORA関連情報は脅威主導のペネトレーションテストに集中していますが、この記事はもっと静かな義務を扱います：システムがボリューム下で応答可能であることを示し、監査人が実際に求める証拠を作成し、この仕事に特化して作られたツールでそれを行うことです。LoadViewはクラウドベースのリアルブラウザロードテストプラットフォームであり、以下のセクションではDORA準拠のレビューチェックリストの各項目と、それを提供するLoadViewの機能を対応付けています。

このガイドで扱う内容

1. DORAにおけるロードテストの位置づけ
2. DORA審査員が求める監査証拠
3. LoadViewがDORA運用レジリエンステストを支援する方法
4. なぜプロトコルのみの負荷数値は監査で通用しないのか
5. DORA対応テスト証拠の作成方法
6. まとめ
7. よくある質問

DORAにおけるロードテストの位置づけ

DORAはリスクベースであり、ツールの具体指定はありません。「四半期ごとに500ユーザーロードテストを実施せよ」とは言いません。重要または重要な機能を支えるICTシステムを定期的にテストし、発見に基づいて対処せよと言っています。

パフォーマンスに関する主な規定は二つの条文にあります：

• 第24条が一般的なテスト原則を定めています。金融機関は重要または重要な機能を支えるICTシステムおよびアプリケーションをリスクベースのアプローチで少なくとも年1回テストします。
• 第25条はプログラムで用いることができる手法を列挙しています。パフォーマンステストとエンドツーエンドテストが明示されています。

取引プラットフォーム、支払いAPI、オンラインバンキングポータルの場合、「混乱に耐える」とは負荷による混乱も含みます：マーケットオープン時の急増、給与支払日のピーク、購入トラフィックが3倍になるプロモーションなど。サービスがボリュームにより遅延または停止することは運用レジリエンスのギャップです。DORAはそれを実運用前に検証していることを期待しており、ここで金融サービス向けロードテストがプログラムに役立ちます。

ここでの重要性は手続き的だけでなく実務的です。監督当局はレジリエンスのギャップを修正するよう要求できるため、テストされていない重要システムが見つかると、規制当局のスケジュールで予期せぬ対応作業が発生します。

DORA審査員が求める監査証拠

審査員は意図ではなく証拠に基づいて作業します。レジリエンステストのレビュー中、彼らは次のような証跡を求めるでしょう:

最初の行はチームが最も失点しやすい部分です。文書化されたパフォーマンスSLAがないと、ロードテストに合否基準がなく、監査人は基準のないグラフを見るだけになります。まずは目標を書き留めましょう：重要なトランザクションごとのP95応答時間、エラー率の上限、各システムが処理すべきピーク負荷。

2、3行目はタイミングと深刻度の問題です。各本番リリース前にロードテストを実施すると、顧客がコードを使う前にボリュームがチェックされ、リリースパイプラインに組み込むことで一貫性を保てます。ストレステストはロードテストを超え、予測ピークを超えるまで負荷をかけるので、壊れるポイントが予期せぬものではなく数字として分かります。

4行目は審査員が扱う証拠の中で最も多い種類です。応答時間パーセンタイル、エラー率、生成したロードプロファイルを含むレポートがコアの証拠で、特定リリースに紐づくよう日付とバージョンが必要です。

5行目はテスト結果を予測と結びつけます。キャパシティプランニングの文書で、前回テストで計測された余裕度がどの程度か、いつ成長によって使い切られるかを述べます。6、7行目は実際のプログラムと紙上のものを区別します。ボトルネックが見つかった場合、審査員はその後の対応を求めるため、LoadViewはパフォーマンスボトルネックを特定し、どのレイヤーが遅いか、何を変えたか、再テストの結果を具体的に示します。

LoadViewがDORA運用レジリエンステストを支援する方法

上記の各証拠項目はLoadViewの機能に直接対応しています。以下の表には、審査員が求める証跡とLoadViewの対応機能を対照させており、コンプライアンス要件とツール機能が1対1で対応しています。

ここで特に重要なLoadViewの特徴は二つあります。一つはテストが実際のブラウザで実行されるため、レポートの数値は顧客が実際に体験する時間であり、これがレポートの信頼性を支えています。もう一つは、テスト全体が生のリクエストのセットではなくユーザージャーニーとしてスクリプト化されているため、第25条にあるエンドツーエンドテストがログイン、トランザクション、確認と実際のセッションに即したテストになっています。次の二つのセクションでこれらを詳述します。

なぜプロトコルのみの負荷数値は監査で通用しないのか

生のHTTPリクエストを発するロードテストは大きなスループット数を報告できます。しかし顧客向け金融サービスにおいて、その数値はサーバーの性能を示すものであり、顧客の体験を示すものではありません。JavaScript処理、サードパーティの不正検知、SSOリダイレクト、画面表示確認を含みません。

顧客が負荷下で取引できるかを審査員が尋ねる場合、求められるのは顧客体験に関する証拠であり、単なるオリジンのリクエスト頻度ではありません。リアルブラウザロードテストは実際のChromiumインスタンスを使用してテストを実施するため、レポートの応答時間は顧客が体験する時間になります。言い換えれば、テストはページを顧客のブラウザが行う通りに読み込み—スクリプト処理、リダイレクト、レンダリングを実行—サーバーへの単なるpingではありません。

銀行や決済プロバイダーにとって、これは「APIが200msで応答した」という状態と「不正スコアリング呼び出しがキューで9秒かかったため、ログインから確認までのフローが9秒かかった」という状態の違いです。後者はサービスを劣化させます。これはまさにレジリエンスレビューが検出したいものであり、したがって実ユーザーフローに対するトランザクション同時実行テストが、プロトコルレベルのスループットチャートより強力な証拠を生み出します。

ページを実行せずに「1秒あたり100,000リクエスト」と報告するツールはHTTPスループットを測定しており、ログイン画面で顧客が体験する速度を測っているわけではありません。顧客向けレジリエンスを評価する監査人は後者の数値を求めます。

プロトコルレベルのテストはサーバーを測定し、LoadViewのリアルブラウザテストは顧客が通るログインから確認までのフローを測定します。

DORA対応テスト証拠の作成方法

この柱を満たすために新しいツールカテゴリーは必要ありません。証拠リストに対応し、監査人に提出できる記録ができるテストが必要です。LoadViewにおける手順は以下の通りです：

1. 重要な機能ごとにパフォーマンス要件を作成する。トランザクションごとに応答時間のパーセンタイルとエラー率の上限を設定し、承認を得てテストに合否基準として入力し、結果が自動的に評価されるようにする。
2. テストをリアルユーザーフローとして記録する。 EveryStepレコーダーを使い、実ブラウザでクリック単位で実際のジャーニー（ログイン、取引、確認）をキャプチャし、その後ウェブアプリケーションロードテストでロード下で再実行し、生のHTTPコールを単に再生するよりリアルにする。
3. 予測ピークまでテストし、さらにそれを超えてテストする。 負荷カーブタイプを設定し、ロードテストで仮想ユーザを予測ピークに保ち、ストレステストでそれを越える段階的カーブで実施し、「耐えられるか」と「どこで壊れるか」の両方を数字で把握する。
4. サービス提供地域から負荷を投入する。 顧客がEUに広がっているなら、30以上の地理分散ロード注入ゾーンから実行し、ユーザの実際のロケーションでパフォーマンスを測る。
5. レポートを保存する。 パーセンタイル、エラー率、ロードプロファイル、ウォーターフォール、タイムスタンプを含むパフォーマンスレポートをエクスポートし、リリース記録とともに保管し、それが審査員が読むファイルになる。
6. スケジュールおよび変更後に再テストする。 重要機能については少なくとも年1回、重要なパスに変更があったリリース後、また取引量の成長によって前回テストのキャパシティ上限に近づいた時に再実施する。実行をスケジュールしCI/CDパイプラインに組み込むことで、手動でのリマインダーではなく自動的なテスト周期を維持できる。

このように扱うことで、証拠はテストの副産物として自然に構築されます。LoadViewは完全にクラウドホスト型のため、負荷発生インフラのセットアップや監査人への説明を要せず、成果物はDORAレビュアーが求める順序で揃います。

DORAの適用範囲は依存する重要ICT第三者プロバイダーにも及びます。決済ゲートウェイ、IDサービス、データAPIが重要経路にある場合、その負荷下の挙動もレジリエンスの一部となるため、これらのエンドポイントへのAPIロードテストにより、自ら運用しないサービスでも同様の証拠を保持できます。

DORA審査員が求める証拠をLoadViewがどのように生成するかをご覧ください。LoadViewデモを予約し、ピークボリュームに合わせたテストの規模を計測し、監査人が求めるレポートをエクスポートしましょう。

まとめ

DORAはロードテストのチェックリストを明確には示しませんが、レジリエンステストの柱と第25条の手法によりパフォーマンスおよびロードテストが監査対象となります。重要または重要な機能を支えるシステムが顧客向けサービスをボリューム下でも提供し続けるかが評価基準です。

審査員が求める7つの証跡を作成し、プロトコルレベルのスループットではなくリアルブラウザの結果に基づき、取引量増加に伴い再テストを行います。LoadViewは単一のスクリプト化されたテストからこれらの証跡をすべて生成できるよう設計されており、パフォーマンステストのレジリエンスレビューは既に保管している記録を渡すだけの作業になります。

よくある質問