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の機能を対応付けています。
このガイドがカバーする内容
- Regulation SCIが適用される対象
- 容量およびストレステストがReg SCIにおいて位置する場所
- SCIレビューが期待する証拠
- LoadViewがReg SCI容量およびストレステストをサポートする方法
- 小規模すぎるテストやプロトコルのみのテストがレビュアーを満足させない理由
- Reg SCI対応のテスト証拠を作成する方法
- 容量およびストレステストの実施頻度
- Reg SCIが報告を求める内容
- 記録の保管期間
- 要点
- よくある質問
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レビュー証拠 | LoadViewがそれを生成する方法 |
|---|---|
文書化された容量および性能要件 | 応答時間とトランザクションごとのエラー率にパス/フェイル閾値を設定し、すべての実行が承認された基準で評価されるようにする。 |
主要なシステム変更前の容量ストレステスト | CI/CDパイプラインからテストをトリガーし、容量チェックが添付されていなければ変更を出荷できないようにする。 |
ピークおよびピーク超過のストレステスト | 予想ピークで保持し、さらに超える段階的な負荷曲線でテストを構成し、限界を探る。 |
応答時間、スループット、およびエラー率のテストレポート | タイムスタンプ付きの性能レポートをエクスポートし、応答時間パーセンタイル、スループット、エラー率、各要素のウォーターフォールを含む。 |
現在および将来の容量計画の文書 | レイテンシが上昇しエラーが発生し始める負荷レベルを測定上限として読み取り、予測メッセージレート増加と対比して記録する。 |
ボトルネック発見時に取られた措置 | ウォーターフォールおよび階層タイミングを用い、遅延成分を特定、修正し、同じテストを再実施して比較記録を作成する。 |
ボリューム増加に応じた定期的な再テスト | 定期的なテストをスケジュールしパイプラインに保持しておき、再テストが自動で成長を追跡するようにする。 |
SCIシステムは2層にまたがり、LoadViewは両方をカバーします。注文受付ゲートウェイ、市場データのフィード、清算インターフェースにはAPI負荷テストがエンドポイントのスループットを駆動します。SCIエンティティとその参加者の運営するウェブ向けシステム（メンバーポータル、発行者および参加者のダッシュボード、ステータスおよび報告サイト）にはリアルブラウザ負荷テストがユーザーの実際の体験を測定します。そして高同時接続負荷テストが両層に渡り取引所規模のメッセージレートを実現します。
小規模すぎるテストやプロトコルのみのテストがレビュアーを満足させない理由
二つのテストの近道がSCIレビューの証拠としての信頼性を損ないます。
一つ目は現実的なピークを下回るテストです。平均的なセッション付近で頭打ちとなる容量テストは、変動の激しいオープンや満期日の急増についてほとんど情報を提供しません。Reg SCIは現在および将来のボリュームをカバーする容量を求めているため、テストは予測されたピーク付近およびそれを超える必要があります。これにはトランザクションの同時実行テストが信頼できる証拠を提供します。
二つ目は発信元のみを測定することです。対象のウェブ向けシステムに対してプロトコルのみのテストで生のHTTPリクエストを送信するのはスループットしか報告せず、メンバーが見る画面は計測しません。JavaScript、認証リダイレクト、レンダリングされた画面をスキップします。リアルブラウザテストは実際のChromium環境でフローを動作させるため、レポート中の応答時間はメンバーが負荷時に実際に体験する時間であり、これが「急増時に作業を続けられるか」の判断に重要な数字です。
「1秒間に100万メッセージ」という報告をするツールは生のスループットを示すだけで、マッチングエンジンがレイテンシ限界内に収まったかやメンバーポータルが使い続けられたかは示しません。証拠は規則が重視するものを測定する必要があります。
プロトコルレベルのテストはエンドポイントを測定し、リアルブラウザテストは負荷下のメンバー向けワークフローを測定します。
Reg SCI対応のテスト証拠を作成する方法
容量義務を満たすために新しいカテゴリのツールは必要ありません。証拠リストにマッチするテストとレビュアーに提出できる記録が必要です。LoadViewでの手順は次のとおりです：
- システムごとの容量および性能要件を書き出す。ピークメッセージレート、レイテンシ上限、エラー率限度を設定し承認を得て合否閾値として登録し、結果が自動的に評価されるようにする。
- 実際のインターフェースに合ったテストを構築する。注文および市場データのエンドポイントはウェブアプリ負荷テストとAPIテストで駆動し、メンバー向けポータルはEveryStepレコーダーでスクリプトし、参加者が使う方式でウェブ層をテストする。
- 予測ピークまでテストし、さらに超える。容量テストでは負荷曲線タイプを設定して予測ピークで保ち、ストレステストではそれを超える段階的曲線を使い、「耐えられるか」と「どこで破綻するか」をカバーする。
- サービスする地域から負荷を注入する。複数の米国地理分散ロード注入ゾーンから実行し、メンバーが実際に接続する場所でレイテンシを測定する。
- レポートを保持する。パーセンタイル、スループット、エラー率、負荷プロファイル、タイムスタンプ付きの性能テストレポートをエクスポートしてSCIレビューに備える。同じレポートを使って性能ボトルネックの特定も行う。
- スケジュールに従って再テスト、変更後、BC/DRのために実施する。主要なシステム変更後やメッセージレート増加に伴い容量ストレステストを繰り返し、CI/CDパイプラインに組み込む。負荷テストと並行して災害復旧テストを実施し、ルール1004の演習は既に負荷テスト済みのシステムで行う。
LoadViewは完全にクラウドホストされているため、負荷生成インフラの構築やレビュアーへの説明が不要であり、証拠資料はSCIレビューの検査順序に合致しています。
容量およびストレステストの実施頻度
Reg SCIは一部の頻度を定め、一部はリスクに基づく判断に任せています。年次の項目は規則で定められ、容量テストのリズムは「定期的（periodic）」という規則の基準内で設定できます。
活動 | 最小実施頻度 | 根拠またはトリガー |
|---|---|---|
SCIレビュー | 少なくとも暦年に1回 | ルール1003(b)で規定 |
BC/DR計画テスト | 少なくとも12カ月に1回 | ルール1004で規定；指定されたメンバーおよび参加者を含む |
容量ストレステスト | 定期的 | ルール1001(a)(2)のリスク評価で設定 |
重要なシステム変更前にテスト | すべての重要な変更時 | 本番環境に到達する前 |
ボリューム増加時に再テスト | 直近の測定限界に近づき次第 | 容量計画のトリガー |
規則で容量テストは「定期的(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レビューは既に保持している記録を提出するだけで済みます。
よくある質問
Regulation SCIは容量およびストレステストを要求していますか？
実質的にそうです。ルール1001(a)はSCIシステムに十分な容量、整合性、回復力、可用性およびセキュリティがあることを保証するための合理的に設計された方針と手続きを要求し、ルール1001(a)(2)はそれら方針に現在および将来の容量計画と定期的な容量ストレステストを含むことを規定しています。Loadおよびストレステストはその証拠を実際に生成する方法です。
Regulation SCIの下でSCIエンティティとは誰ですか？
SCIエンティティには、全国証券取引所、登録済み清算機関、FINRA、MSRBなどの自主規制機関、ボリュームしきい値を満たすSCI代替取引システム、プランプロセッサーおよび特定の免除された清算機関が含まれます。SECは2023年に対象エンティティの拡大を提案しているため、その境界付近の企業は注視する必要があります。
SCIレビューはどのようなテスト証拠を求めますか？
SCIレビューが通常求めるのは、文書化された容量および性能要件、主要なシステム変更前の容量ストレステスト、ピークおよびピーク超過のストレステスト、応答時間・スループット・エラー率を示すテストレポート、現在および将来の容量計画文書、ボトルネック発見時の対応記録、およびボリューム増加に伴う定期的な再テストなどです。
SCIエンティティはどのくらいの頻度でテストを行う必要がありますか？
ルール1003(b)は年に少なくとも1回のSCIレビューを規定し、ルール1004は指定メンバーおよび参加者を含む事業継続および災害復旧計画のテストを少なくとも12カ月ごとに要求します。容量ストレステストは定期的に行い、主要システム変更後とボリューム増加に伴い実施する必要があります。
SCIイベントはいつSECに報告しなければなりませんか？
ルール1002によれば、責任あるSCI担当者がシステム障害、システムコンプライアンス問題、システム侵害などのSCIイベントが発生した合理的根拠を得たら、SCIエンティティは速やかにSECに通知し、24時間以内にForm SCIで書面報告を提出し、イベント終了まで更新し続け、解決後に最終報告を提出します。影響がないか軽微なイベントは四半期ごとに期末から30日以内に報告します。
Reg SCIのテスト記録はどれだけ長く保管しなければなりませんか？
ルール1005はSCIエンティティにReg SCI遵守を示す記録を最低5年間作成・保管し、最初の2年間は容易にアクセスできる場所に置くことを要求しています。容量関連では日付入りテストレポート、テスト毎の要件、容量計画文書、修正記録、関連Form SCIおよびSCIレビュー提出書類が含まれます。
LoadViewはRegulation SCIコンプライアンスをどのように支援しますか？
LoadViewはSCIレビューが求める容量およびストレステストの証拠を提供します。リアルブラウザでウェブ向けSCIシステムに対して負荷およびストレステストを実行し、APIテストで注文・市場データエンドポイントに負荷をかけ、ピークおよびピーク超過の負荷を設定可能な負荷曲線で形成し、複数の米国地域から負荷を注入し、応答時間、スループット、エラー率を含むタイムスタンプ付き性能レポートをエクスポートしてレビュー用に保存します。