SEC Reg SCIが容量およびストレステストに期待するもの

Reg SCIの下で、容量およびストレステストの証拠は年次SCIレビューの一部です。

米国の取引所、清算機関、その他Regulation SCIの対象となる市場インフラのコンプライアンスおよびシステムチーム向け。

SECのRegulation Systems Compliance and Integrity（Reg SCI）は、2015年11月3日の遵守日から米国市場インフラの中核技術を規制しています。市場の基盤を運営する事業体に対し、システムが能力的で、回復力があり、利用可能であることを維持し、それを証明することを求めています。容量およびストレステストはその義務の中心付近に位置しています。

ルール1001(a)が基盤です。これは、SCIシステムが十分な容量、整合性、回復力、可用性、およびセキュリティを持つことを合理的に確保するための書面による方針と手続きを求めています。ルール1001(a)(2)は、これらの方針がカバーすべき内容として、現在および将来の容量計画およびシステムが正確かつタイムリーで効率的にトランザクション処理できることを確認する定期的な容量ストレステストを挙げています。

オンラインの多くのReg SCIに関する解説は法律事務所によって書かれており、コンプライアンスの要約のような読み物です。本稿は、その要約では省略されるエンジニアリング側を扱います：SCIレビューが期待する容量およびストレステストの証拠とは何か、その証拠を生成するために設計されたツールでの作成方法です。LoadViewはクラウドベースの負荷およびストレステストプラットフォームで、以下のセクションではSCIのレビュアーが求める各項目とそれを生成するLoadViewの機能を対応付けています。

このガイドがカバーする内容

1. Regulation SCIが適用される対象
2. 容量およびストレステストがReg SCIにおいて位置する場所
3. SCIレビューが期待する証拠
4. LoadViewがReg SCI容量およびストレステストをサポートする方法
5. 小規模すぎるテストやプロトコルのみのテストがレビュアーを満足させない理由
6. Reg SCI対応のテスト証拠を作成する方法
7. 容量およびストレステストの実施頻度
8. Reg SCIが報告を求める内容
9. 記録の保管期間
10. 要点
11. よくある質問

Regulation SCIが適用される対象

Reg SCIはすべての市場参加者に適用されるわけではありません。市場全体が依存するシステムを運営する「SCIエンティティ」と定義される特定の集団に適用されます：

• 全国証券取引所、登録済み清算機関、FINRA、MSRBを含む自主規制機関。
• SCI代替取引システム、すなわちNMS株または非NMS株でボリュームしきい値を超える大規模なATS。
• プランプロセッサーおよび特定の免除された清算機関。

義務はシステムの中心度に応じてスケールします。ルール1000はシステムを「SCIシステム」と「重大SCIシステム」というより厳しいサブセットに分類し、市場への影響が最も大きいシステムに最も重い要件を課しています。2023年にSECは対象エンティティの範囲を拡大する改正案を提案したため、現在の境界付近にいる企業はその提案を注視し、範囲外と見なすべきではありません。

容量およびストレステストがReg SCIにおいて位置する場所

テスト作業を駆動し相互に補完し合う規則の三つの部分があります：

• ルール1001(a)：容量および回復力。方針はSCIシステムに十分な容量があることを確保しなければならず、現在および将来の容量計画と定期的な容量ストレステストを含まなければなりません。これは負荷およびストレステストの直接的な根拠です。
• ルール1003(b)：年次SCIレビュー。各SCIエンティティはReg SCI遵守状況を最低年1回、客観的かつ資格のある人員によって実施し、システム侵入テストと統制評価を含みます。容量テストの証拠はそのレビューで調査される一部です。
• ルール1004：事業継続と災害復旧テスト。SCIエンティティはBC/DR計画を最低12カ月ごとにテストし、指定されたメンバーや参加者も含みます。

取引所のマッチングエンジン、清算システム、市場データフィードにとって「十分な容量」とは固定数値ではありません。メッセージレートは変動が激しい日に上昇し、オプション取引量は満期近くで急増し、単一のニュースイベントで注文トラフィックは通常のセッションを大幅に超えることがあります。Reg SCIはSCIエンティティに余裕を計画させ、その容量計画を実測に基づかせることを求めており、実際の急増時に限界を見つけることを期待していません。

SCIレビューが期待する証拠

SCIレビューは証拠資料から作業します。容量および回復力を調査する際、以下の記録を探すことが予想されます:

最初の行はプログラムが最も遅れを取る部分です。文書化された性能SLAがなければ、ストレステストに合否ラインがなく、レビュアーには基準のないチャートしか示されません。まず目標を記述してください：システムごとの最大メッセージレート、そのレートでのレイテンシ上限、および失敗と見なすエラー率の限度です。

2行目と3行目はタイミングと重大度に関します。ストレステストは主要な変更前に容量を確認し、予想ピークを超えて押し進めることで、破綻点をサプライズではなく数値として記録します。4〜7行目は進行中の記録です：日付入りのレポート、現在および将来の容量計画、レビュアーが「どう対処したか」と問う時の修正と再テストの記録、そしてボリューム増加に合わせたペース管理です。

LoadViewがReg SCI容量およびストレステストをサポートする方法

リストの各行はLoadViewの機能に直接マッピングされます。表はレビュアーが求める証拠と、それを生成するLoadViewの機能の対応を示します。

SCIシステムは2層にまたがり、LoadViewは両方をカバーします。注文受付ゲートウェイ、市場データのフィード、清算インターフェースにはAPIロードテストがエンドポイントのスループットを駆動します。SCIエンティティとその参加者の運営するウェブ向けシステム（メンバーポータル、発行者および参加者のダッシュボード、ステータスおよび報告サイト）にはリアルブラウザロードテストがユーザーの実際の体験を測定します。そして高同時接続ロードテストが両層に渡り取引所規模のメッセージレートを実現します。

小規模すぎるテストやプロトコルのみのテストがレビュアーを満足させない理由

二つのテストの近道がSCIレビューの証拠としての信頼性を損ないます。

一つ目は現実的なピークを下回るテストです。平均的なセッション付近で頭打ちとなる容量テストは、変動の激しいオープンや満期日の急増についてほとんど情報を提供しません。Reg SCIは現在および将来のボリュームをカバーする容量を求めているため、テストは予測されたピーク付近およびそれを超える必要があります。これにはトランザクションの同時実行テストが信頼できる証拠を提供します。

二つ目は発信元のみを測定することです。対象のウェブ向けシステムに対してプロトコルのみのテストで生のHTTPリクエストを送信するのはスループットしか報告せず、メンバーが見る画面は計測しません。JavaScript、認証リダイレクト、レンダリングされた画面をスキップします。リアルブラウザテストは実際のChromium環境でフローを動作させるため、レポート中の応答時間はメンバーが負荷時に実際に体験する時間であり、これが「急増時に作業を続けられるか」の判断に重要な数字です。

「1秒間に100万メッセージ」という報告をするツールは生のスループットを示すだけで、マッチングエンジンがレイテンシ限界内に収まったかやメンバーポータルが使い続けられたかは示しません。証拠は規則が重視するものを測定する必要があります。

プロトコルレベルのテストはエンドポイントを測定し、リアルブラウザテストは負荷下のメンバー向けワークフローを測定します。

Reg SCI対応のテスト証拠を作成する方法

容量義務を満たすために新しいカテゴリのツールは必要ありません。証拠リストにマッチするテストとレビュアーに提出できる記録が必要です。LoadViewでの手順は次のとおりです：

1. システムごとの容量および性能要件を書き出す。ピークメッセージレート、レイテンシ上限、エラー率限度を設定し承認を得て合否閾値として登録し、結果が自動的に評価されるようにする。
2. 実際のインターフェースに合ったテストを構築する。注文および市場データのエンドポイントはウェブアプリロードテストとAPIテストで駆動し、メンバー向けポータルはEveryStepレコーダーでスクリプトし、参加者が使う方式でウェブ層をテストする。
3. 予測ピークまでテストし、さらに超える。容量テストでは負荷曲線タイプを設定して予測ピークで保ち、ストレステストではそれを超える段階的曲線を使い、「耐えられるか」と「どこで破綻するか」をカバーする。
4. サービスする地域から負荷を注入する。複数の米国地理分散ロード注入ゾーンから実行し、メンバーが実際に接続する場所でレイテンシを測定する。
5. レポートを保持する。パーセンタイル、スループット、エラー率、負荷プロファイル、タイムスタンプ付きの性能テストレポートをエクスポートしてSCIレビューに備える。同じレポートを使って性能ボトルネックの特定も行う。
6. スケジュールに従って再テスト、変更後、BC/DRのために実施する。主要なシステム変更後やメッセージレート増加に伴い容量ストレステストを繰り返し、CI/CDパイプラインに組み込む。負荷テストと並行して災害復旧テストを実施し、ルール1004の演習は既に負荷テスト済みのシステムで行う。

LoadViewは完全にクラウドホストされているため、負荷生成インフラの構築やレビュアーへの説明が不要であり、証拠資料はSCIレビューの検査順序に合致しています。

容量およびストレステストの実施頻度

Reg SCIは一部の頻度を定め、一部はリスクに基づく判断に任せています。年次の項目は規則で定められ、容量テストのリズムは「定期的（periodic）」という規則の基準内で設定できます。

規則で容量テストは「定期的(periodic)」とされ、固定間隔ではありません。したがって、レビュアーが受け入れる答えは、自己のリスク評価で裏付けられ、記録でその実施が示されるものです。実際には多くのエンティティはSCIレビューと合わせて年1回以上容量ストレステストを行い、急増や急激な変動があるシステムではより頻繁に行い、重大変更前や指数リバランスや大規模IPOのような既知のピークイベント前には必ず実施します。レビュアーは特定の間隔よりも、そのリズムがリスクに合致し保持されているかを重視します。

Reg SCIが報告を求める内容

テスト証拠は引き出しにしまわれたままになりません。いくつかのReg SCI義務はこれをSECに提出するかメンバーに共有するものに変換します。

Form SCI上のSCIイベント

容量起因の障害は「システム障害」と呼ばれ、システムコンプライアンス問題やシステム侵害と並ぶSCIイベントの三つのタイプの一つです。ルール1002により、責任あるSCI担当者がSCIイベント発生の合理的根拠を持った時点ですぐにSECに通知し、24時間以内にForm SCIで書面通知を提出、イベント解決まで更新を続けて、解決後および調査終了後に最終報告を行います。影響がないか極めて軽微なイベントは代わりに四半期ごとに報告し、期末から30日以内に提出します。ルール1002(c)は主要イベントの影響を受けるメンバーまたは参加者に速やかに情報共有することも要求しています。

容量テストはこれの両面を支えます。報告対象の障害発生の可能性を下げ、もし発生してもテスト履歴が最終報告の根本原因記録の一部となります。

四半期ごとの重大なシステム変更

四半期ごとに30日以内に、SCIエンティティは完了済み、進行中、および計画中の重大なシステム変更を報告します（ルール1003(a)）。各変更時に実施する容量テストがそれが出荷前にチェックされた証拠です。

年次SCIレビュー報告書

SCIレビューはまず経営陣に提出され、その後60日以内にSECに報告書と経営陣の回答を添えて提出されます（ルール1003(b)）。容量およびストレステストのレポートはレビューが依拠する証拠の一部です。

記録の保管期間

テストレポートはレビュアーが求める時に存在してこそ証拠となります。ルール1005が保管の最低基準を定めています。

SCIエンティティはReg SCI遵守を示す記録を作成し保管保持します。SCI SROの場合は既存のSRO記録保持規則（ルール17a-1）に連結されますが、SROでないSCIエンティティにはこれが直接適用されます。いずれにせよ、標準は少なくとも5年間にわたって記録を保存し、最初の2年間は容易にアクセスできる場所に保管することです。

容量関連では、以下を保存する必要があります：

• 日付入り性能レポート、応答時間、スループット、エラー率、およびそれらを発生させた負荷プロファイル。
• 各テストの合否評価に使った容量および性能要件。
• 容量計画文書とそれを支える成長仮定。
• テストで発見されたボトルネックに対する修正経路：変更点と再テスト結果。
• 関連するForm SCI提出書類およびSCIレビュー報告書そのもの。

テスト設定と結果を一元管理し、必要な時にエクスポートできることが5年の保管義務を単なる作業から参照可能な資産に変えます。LoadViewは完了したテスト結果を保存し、実行ごとのレポートをエクスポートできるため、提出する証拠は2年、3年、5年後にも同じものを取り出せます。

LoadViewがSCIレビューで求められる容量およびストレステストの証拠をどのように生成するかをご覧ください。LoadViewデモの予約をしてピークメッセージレートに合ったテストを設計し、レビュアーが求めるレポートをエクスポートしましょう。

要点

Reg SCIはテストチェックリストを示しませんが、ルール1001(a)(2)で容量計画と定期的な容量ストレステストを文書化することを定めており、年次SCIレビューで結果を検査します。市場が依存する重要なシステムとは、実際のボリューム下でトランザクションを正確かつタイムリーに処理できるものです。

容量およびレイテンシ目標を設定し、APIおよびウェブ層で予測ピークおよびそれ以上までテストし、日付入りレポートを記録し、メッセージレートの増加に応じて再テストします。LoadViewはそれら全ての証拠を、元々実行したいテストから生成するため、SCIレビューは既に保持している記録を提出するだけで済みます。

よくある質問