認可を受けた取引所にとって、「サービスを継続すること」はUXの問題ではなく、認可に関する問題です。 RMO DAX（認定市場運営者－デジタル資産取引所）の枠組みの下、マレーシア証券委員会は、運用レジリエンス、すなわちハードウェア障害、クラウドサービスの停止、サイバー攻撃、またはデータセンターの喪失が発生した場合でも、所定の時間内に取引を復旧させ、顧客資産を保護する能力を求めています。 本記事では、RTO/RPOの階層化やマルチサイトアーキテクチャから、マッチングエンジンやウォレットのフェイルオーバー、バックアップと照合、インシデント対応、顧客資産の保護、テスト、保険、準備金に至るまで、BCP/DR（事業継続計画／災害復旧）設計の全容を解説します。特に、これらの機能を単なるスライド資料ではなく、監査可能なプログラムとして具体化する方法に重点を置いています。

1. 運用レジリエンスに関するSCの要件

SCは、RMO DAXガイドライン、現地検査チェックリスト、およびライセンス更新審査において、運用レジリエンスの3つの層に焦点を当てています。第一に、重要システムには、マッチング、清算、ウォレット、入出金、KYC、顧客サポートなど、特定されたすべての重要な業務機能を網羅した書面によるBCPが必須です。 第二に、プラットフォームは定期的なテストを実施し、完全な記録を保持しなければならず、テスト結果は是正ループに反映される必要があります。第三に、サービス停止中も顧客資産は安全かつ追跡可能でなければならず、プラットフォームは事後にSCおよび監査人に対し、資産が紛失、横領、または誤計上されなかったことを実証できなければなりません。規制当局は「最善の努力」という姿勢を認めず、 各重要機能について、明確に定義されたRTO／RPO目標、責任者、エスカレーション手順、および規制当局と顧客双方への通知スケジュールを要求している。BCP文書は少なくとも年1回見直しを行い、主要なアーキテクチャの変更、上場規則の変更、または主要な外部委託業者の交代後には更新され、要求に応じて所定の期限内にSCに提出されなければならない。 RMO DAXに加え、プラットフォームは資本市場関連法規、AML要件、およびサイバーセキュリティと技術リスク管理に関するSCのガイダンスにも準拠し、文書間の矛盾が生じないよう、レジリエンスを内部統制、情報セキュリティ、およびアウトソーシング・ガバナンスと統合しなければならない。

2. RTO/RPOの階層化

すべてのシステムに1秒未満の復旧が求められるわけではなく、すべてを盲目的にアクティブ・アクティブで運用すると、コストが持続不可能な水準まで押し上げられてしまいます。当社は、ビジネスへの影響度に応じて4つの階層を推奨します。第1階層はコア取引（マッチングエンジン、リアルタイムリスク管理、市場データ、注文ゲートウェイ）であり、RTOは数分、RPOはほぼゼロとされ、マッチングされた取引が失われることがあってはなりません。 ティア2はファンドおよび清算（ウォレット、照合、入金、出金審査）であり、RTOは数十分、RPOは数秒から数分です。わずかな遅延は許容されますが、会計上の誤りは許されません。ティア3は口座およびサポート（ログイン、KYC、チケット、通知）であり、RTOは数時間です。 ティア4は、マーケティング、レポート、BIなどの非重要システムであり、RTOは1日以上です。ティア分けは、技術チームの好みではなく、1時間あたりの実際の損失額、顧客および規制当局の許容範囲、復旧の費用対効果に基づいて行わなければなりません。 各目標は内部SLAに明記し、開示可能な部分は顧客契約書およびステータスページに掲載することで、市場の期待とプラットフォームの能力を一致させる必要があります。 ティア分けは一度設定すればそれで終わりというものではありません。処理量の増加、新製品（先物、収益化）、顧客構成の変化により、以前は非重要だったシステムが重要度を高める可能性があるため、ティア分け表とビジネス影響分析は少なくとも年1回見直す必要があります。

3. アクティブ-アクティブおよびマルチサイトDR

中核となる取引システムは、同一都市またはクラウドリージョン内の2つのデータセンターまたはアベイラビリティゾーンにまたがって、アクティブ-アクティブで稼働させる必要があります。両方で実際のトラフィックを処理し、ロードバランシングは数秒以内にフェイルオーバーを行い、低遅延の同期レプリケーションによって状態の一貫性を強力に維持します。 アクティブ・アクティブ構成は、施設やアベイラビリティゾーン（AZ）の障害には対応できますが、リージョン全体のネットワーク喪失、広範囲にわたるクラウドリージョンの障害、あるいは都市規模の災害には対応できません。そのため、別の地理的エリアにあるリモートDRサイトが必要となります。通常、非同期レプリケーションを採用し、RPO（復旧時点目標）を数秒～数分、RTO（復旧時間目標）を数分～10分程度に設定し、リージョン障害発生後に業務を引き継ぐようにします。 マルチクラウドやハイブリッド展開はベンダーロックインをさらに軽減しますが、クラウド間の遅延、クロックの同期、イメージの一貫性、運用上の複雑さを正直に考慮する必要があります。「マルチクラウド」という名目のために、マッチング性能を犠牲にしてはなりません。 設計原則は「障害を前提とする」ことです。すべてのコンポーネントには対となるコンポーネントがあり、個々の障害は隔離され、人間による夜間修復ではなく自動的にフェイルオーバーされます。トラフィック管理では、ヘルスチェック、重み付けされたカットオーバー、カナリア展開、およびワン・サーキット・ブレーカー方式の緊急停止をサポートし、フェイルオーバー自体が二次的なインシデントを引き起こさないようにする必要があります。

4. マッチングエンジンのフェイルオーバー

マッチングエンジンは、最もステートフルであり、フェイルオーバーが最も困難なコンポーネントです。プライマリはインメモリのオーダーブックとポジションを保持し、ホットスタンバイはライトアヘッドログをリアルタイムで再生しますが、クライアントへのサービス提供は行いません。 プライマリが障害を起こした場合、スタンバイはログの完全性を確認し、プライマリの最後に承認されたポジションに追いついてから初めて昇格します。クライアントはゲートウェイまたは設定センターを介して再接続し、未承認の注文はクライアントによって再送信され、承認済みの取引はログに基づいて決定されます。 昇格処理では、2つのノードがともに自身がプライマリであると誤認する「スプリットブレイン」を防止する必要があります。これが発生すると、注文の重複約定や残高の破損を引き起こします。一般的なパターンは、リースと分散ロックの組み合わせであり、これにより有効なリースと最新のログを保持しているノードのみが昇格できるようになります。旧プライマリは、復旧した際にスタンバイとして再参加し、再同期を行う必要があります。 最悪の場合、一貫性のないデータで取引を再開するよりも、手動による状態確認を伴う一時的な取引停止の方が望ましい。また、マッチングのフェイルオーバーは、下流の清算、リスク管理、ウォレット、市場データ、通知システムとも連携して行わなければならない。そうしないと、マッチングは復旧しても他のシステムが復旧せず、注文は出せるが約定しない、あるいは約定しても残高に反映されないといった「半ば復旧した状態」が生じる。

5. ウォレットおよび秘密鍵の災害復旧

ウォレットの災害復旧における第一の原則は、災害復旧によって鍵のセキュリティが損なわれてはならないということです。 地理的に分散されたバックアップを備えたコールドウォレットのマルチシグは、それ自体がBCPの一部である。いかなる単一の地域、個人、またはプロバイダーも、資産を一方的に移動させてはならない。MPCの鍵シェアは、地域、クラウドプロバイダー、および物理メディアにまたがって保管されるべきであり、シェアの生成、ローテーション、および復旧についてはポリシーに明記し、定期的に監査を行う必要がある。 ホットウォレットノードはマルチインスタンスで稼働させるため、1つの障害が発生してもブロードキャストや受信スキャンがブロックされることはありません。鍵とシェアは、HSM、MPCノード、または署名者といったセキュアドメインから決して外に出ず、DR環境では署名ワークフローとノードの状態が複製されますが、平文の鍵が複製されることは決してありません。 復旧演習では、シナリオ全体を検証する必要があります。つまり、あるリージョン全体が機能停止状態になっても、マルチシグ承認ポリシー、リスク制限、内部者管理が引き続き有効な状態で、プラットフォームが稼働しているリージョンから署名および出金を行えることを確認します。 DRサイトにおけるアクセス権限、承認者、および監査ログは、本番環境と同様に厳格でなければならず、DRがセキュリティ上の弱点とならないようにする必要があります。チェーンレベルの再編成やノード障害に備え、プラットフォームにはノードの冗長性、並列チェーンノード、および最終一貫性に基づく調整機能も必要です。

6. バックアップ、照合、および復旧

バックアップは、RPO（復旧時点目標）と検証可能な復旧可能性の両方を満たす必要があります。本番環境のデータベースでは、フルバックアップと増分バックアップを取得し、継続的なログ転送を行います。さらに、台帳、取引、および入出金記録は、規制上のトレーサビリティ要件を満たすのに十分な保存期間を持つWORMまたはオブジェクトロック型ストレージに書き込まれます。 バックアップだけでは不十分です。バックアップからシステムを再構築し、照合を行うことができなければなりません。バックアップから完全な環境を復元した後、オンチェーン残高、ユーザー残高、取引、および資金移動を1行ずつ照合し、これら4つが一致するようにします。不一致がある場合は、特定のトランザクションまで追跡可能でなければなりません。 独立したレポートを生成する自動化された日次照合を実行し、DR環境において「バックアップからの完全な環境再構築」を定期的に演習する必要があります。そうしなければ、復旧可能性は不明確となります。バックアップのセキュリティも同様に重要です。オフラインのコピーは暗号化され、保管を分割し、オフサイトに保管する必要があります。これにより、ランサムウェアが本番環境とバックアップを同時に暗号化することを防ぎます。 復旧プロセスでは職務分掌を徹底し、単一の管理者がバックアップとログの両方を削除できないようにする必要があります。復旧時間そのものは、特にデータ量が増加するにつれて、RTO（復旧目標時間）に対して検証されなければなりません。シャーディング、スナップショット、並列復元は、復旧時間を抑制するための一般的な対策です。

7. DDoS、クラウド障害、およびサイバー対応

DDoSは、東南アジアの取引所におけるサービス停止の最も頻繁な原因であり、その発生頻度とピーク時の規模はともに増加し続けています。 防御は多層的に構築すべきです。上流のアンチDDoSスクルービングでボリューム型攻撃を吸収し、CDNとWAFでアプリケーション層のCC攻撃を軽減し、APIゲートウェイできめ細かなレート制限と異常トラフィックのブロックを実施し、バックエンドサービスはスクルービング済みのオリジンにのみ公開されます。 クラウドリージョンのサービス停止には、マルチサイトおよびリージョン間のフェイルオーバーで対応します。切り替え時にはDNSのTTLを短く設定するとともに、単一障害点を回避するため、DNSプロバイダーおよび証明書の可用性自体も監視する必要があります。 侵入やランサムウェア対策における基本原則は、最小権限の原則、ネットワークのセグメンテーション、鍵のローテーション、特権アクセスの承認、およびオフラインバックアップです。本番環境が暗号化されていても、クリーンなオフラインコピーがあれば復旧が可能となり、データ流出の影響を最小限に抑えることができます。 すべての外部依存関係には、フォールバックと機能低下時の切り替え策が必要です。決済パートナーがダウンした場合は、決済経路を切り替えたり、法定通貨のオンランプを一時停止したりします。KYCプロバイダーがダウンした場合は、KYC処理を手動審査キューに振り分けます。フィードに異常が見られた場合は、市場データソースを切り替え、影響を受ける銘柄の取引を停止します。 ノードに異常が発生した場合は、チェーンノードを切り替え、確認閾値を引き上げる。各機能低下時の対応策はランブックに明記し、当直スタッフがストレス下で即興対応するのではなく、手順に従って行動できるようにすべきである。

8. インシデント対応とコミュニケーション

BCPは、技術面と同様にプロセスと組織体制も重要です。プラットフォームはインシデント指揮システムを確立すべきです。当直のSREまたは運用エンジニアが第一対応者となり、深刻度に応じて「ウォー・ルーム」が開設され、技術対応、内部コミュニケーション、外部コミュニケーション、法務・コンプライアンス、およびカスタマーサポートの各役割が、エスカレーションのタイムラインと意思決定権限とともに明確に定義されます。 深刻度は通常、影響度、財務リスク、および規制上の重要度によって設定されます。P1のインシデントでは、数分以内に全関係者が対応に当たり、所定の時間枠内での経営陣の関与が求められます。 対外的なコミュニケーションは、約束された時間内（例えば、重大なインシデントの確認後30分から60分以内）に、ステータスページ、アプリのプッシュ通知、公式ソーシャルチャネル、およびメディアを通じて発信され、影響、進捗状況、および復旧予定時刻（ETA）を説明し、情報不足によるパニックや噂の拡散を防ぐ必要があります。 セキュリティ委員会（SC）への報告は、ライセンスおよびガイドラインの期限に従わなければなりません。すなわち、所定の期間内に初期通知を行い、解決後に根本原因分析と是正措置を報告し、重大なインシデントについては事後検討を積極的に行います。 内部的には、事後検証および監査人・規制当局への対応がコンプライアンスに準拠していたことを後日証明するために、完全なタイムライン、意思決定ログ、対応記録、およびコミュニケーションログを保持すること。

9. サービス停止時の顧客資産の保護

顧客資産の保護は、オペレーショナル・レジリエンスの究極の目的である。第一に、資産の分離が必須である。顧客の法定通貨および暗号資産は、プラットフォームの自己資産とは別々に保管され、コールドウォレットの比率、ホットウォレットの制限、マルチシグポリシーは、一般から検証可能でなければならない。 第二に、サービス停止中においても、プラットフォームは重要な入金の確認や出金の承認を完了できるか、あるいは遅延や補償ルールを明確に公表し、プラットフォームのダウンによってオンチェーン入金が失われることがないようにしなければならない。 第三に、プラットフォームは、定期的なマークルツリーによる準備金証明、独立したカストディ報告書、あるいは100％の裏付けを証明する監査意見書などの仕組みを通じて、サービス停止前後の支払能力を証明できる必要があります。 第四に、事後紛争を防ぐため、利用規約において、不可抗力、チェーンレベルの異常、第三者の障害を含む、サービス停止、ロールバック、および補償に関する責任を明確に定義しなければならない。 第五に、サービス停止中に取引ができず損失を被った顧客に対しては、単なる「システムメンテナンス中」という曖昧な対応ではなく、事象の性質に応じたリスク準備金や保険によって賄われる、明確なクレームおよび補償の窓口を設ける必要がある。これらすべてをポリシーに盛り込むことが第一歩だが、真の試練は、実際に事象が発生した状況下でそれを実行に移せるかどうかである。

10. テストと継続的改善

一度もテストされたことのないBCPなど存在しない。 テストは多層的に実施すべきである。第1層は机上演習であり、経営陣や主要な役割を担う者がインシデントシナリオをシミュレートし、プロセス、役割、および連絡テンプレートを検証する。第2層はコンポーネントのフェイルオーバー演習であり、カナリアテストやオフピーク時間帯にデータベース、ノード、またはアベイラビリティゾーンを物理的に停止させ、アラート、自動フェイルオーバー、およびロールバックを検証する。 第3層はフルスタックのDR切り替えであり、本番システム全体を一定期間DRサイトに移行し、その後元に戻すもので、マッチング、ウォレット、清算、ゲートウェイ、通知を網羅する。第4層はレッド・ブルー／パープルチーム活動およびカオスエンジニアリングであり、意図的に障害を注入したり攻撃をシミュレートしたりして、隠れた弱点を明らかにする。 すべての演習には、計画、観測指標、ロールバック計画、事後検証が必要です。課題リストには、責任者と期限を明記し、是正措置に反映させます。適切な実施頻度は、四半期ごとの机上演習、四半期に1～2回のコンポーネント演習、少なくとも年1回のフルスタック・カットオーバー、さらに主要なアーキテクチャ変更後の臨時の演習です。 演習記録は、SCの現地検査における証拠として、数年間保存しておく必要があります。

11. 保険、引当金、および第三者への依存

技術的対策だけではあらゆる損失をカバーすることはできません。保険と引当金は、レジリエンスの最後の砦となります。リスク引当金は通常、取引手数料、清算剰余金、および専用資本の一定割合から積み立てられ、プラットフォームの停止、情報漏洩、内部者による不正行為に起因する顧客の損失を補填するために使用されます。その資金調達方法、使用条件、および承認プロセスは公表されるべきです。 商業保険は多層的に構成可能です。キーの漏洩や盗難に対する犯罪・保管保険、攻撃や事業中断に対するサイバー賠償責任保険、経営陣の意思決定に対する役員賠償責任（D&O）保険などがあり、その補償限度額はコールドウォレットの保有高、1日の取引高、および規制当局の期待値に合わせて設定されます。 サードパーティへの依存関係もBCPに組み込む必要があります。クラウドプロバイダー、DDoS対策ベンダー、KYC、決済インフラ、市場データフィード、ブロックチェーンノード、法定通貨ゲートウェイは、すべて潜在的な障害点となり得ます。 契約書には、SLA、データの所有権、解約および移行条件、緊急時の協力体制を明記すべきです。重要なプロバイダーについては、代替案を確保するとともに、自社のレジリエンス（SOC 2、ISO 27001、規制当局からのライセンス）を証明する証拠が必要です。重要な第三者については、定期的に再評価および見直しを行い、プラットフォーム自体が堅牢であっても、単一のサプライヤーの障害によってすべてがダウンしてしまう事態を防ぐ必要があります。

12. SoonTechのBCP/DR実装

マレーシアの認可事業者向けSoonTechのホワイトラベル取引所プラットフォームは、運用レジリエンスを最優先の機能として位置付けています。マッチングエンジンは、WALレプリケーションとリースベースのリーダー選出によるプライマリ・ホットスタンバイフェイルオーバーをサポートしており、クライアントのRTO/RPO目標に合わせて構成されたアクティブ・アクティブまたはリモートDRトポロジーのいずれにも展開可能です。 ウォレット層はMPCおよびマルチシグソリューションと統合されており、キーシェアは地域やプロバイダー間で分散され、DR環境における署名ワークフローでもセキュリティ基準を低下させることなく、同一のポリシーが維持されます。 組み込みのバックアップ、WORM（Write Once Read Many）保存、および自動照合モジュールにより、オンチェーン残高、台帳、取引、資金移動にわたる毎日の4ウェイ照合がサポートされ、エクスポート可能な監査レポートが生成されます。 監視およびインシデント対応モジュールは、インフラ、アプリケーション、ビジネス指標、オンチェーンイベントを網羅しており、重大度に基づくアラート、ウォー・ルームツール、ステータスページ、および顧客通知テンプレートにより、連絡までの時間を短縮します。 コンプライアンス面では、本プラットフォームは、SCの現地検査で求められるBCP文書テンプレート、演習記録、インシデント報告書フォーマット、データ保持インターフェースを提供し、顧客のSOC、カストディアン、保険会社との連携が可能です。 SoonTechのデリバリーチームは、単にソフトウェアを引き渡すだけでなく、ビジネス影響分析、RTO/RPOの階層化、アーキテクチャレビュー、訓練の実施支援、規制当局向けの資料作成を通じて、クライアントと協力します。

13. 企業向け導入の推奨事項

マレーシアの RMO DAX ライセンスを申請中、または保有しているプラットフォームについては、4 段階のプロセスを推奨します。第 1 段階はビジネス影響度分析です。重要なビジネス機能、依存関係、単一障害点、および許容可能な最大ダウンタイムを特定し、階層化されたインベントリを作成します。 ステップ2は目標アーキテクチャです。ティアごとにアクティブ・アクティブ、ウォームDR、またはコールドバックアップを選択し、非重要システムへの過剰投資を避けつつ、中核システムが規制要件および顧客の期待を満たすようにします。 ステップ3はプロセスとポリシーです。インシデント対応、コミュニケーション、テスト、バックアップ・リカバリ、およびサードパーティ管理を実行可能なランブックにまとめ、当直エンジニア全員にトレーニングを実施します。ステップ4は、演習、モニタリング、監査、事後分析を通じた継続的な検証です。これにより、BCPが単発のプロジェクトではなく、継続的な運用能力となります。 経営陣の支援が重要です。レジリエンスは、資本、保険、コンプライアンスと並んで経営会議の議題となるべきであり、それはプラットフォームがインシデントを乗り切れるかどうかを決定づけるからです。プロセスや演習を伴わない派手なアーキテクチャ、あるいは決して実践されない文書化という、両極端を避けましょう。この両者の組み合わせこそが、SCが求めるものであり、実際に顧客を保護するものです。

よくある質問

Q1：RTOとRPOは誰が設定すべきですか？

A: 事業部門、コンプライアンス部門、技術部門が共同で定義し、経営陣の承認を得る必要があります。技術部門は実現可能性やコストに関するデータを提供しますが、単独で目標を設定すると、事業や規制上の現実から乖離してしまいます。目標はSLAに盛り込まれ、大きな変更があった後に再検討されます。

Q2: アクティブ・アクティブ構成では、遠隔地のDRサイトは不要になりますか？

A: いいえ。アクティブ・アクティブ構成は、データセンターやアベイラビリティゾーンの障害には対応できますが、都市規模の災害や広範囲にわたるクラウドリージョンの障害には対応できません。コアシステムと連携する認可取引所では、地域的な障害に備えるため、依然として遠隔地のDRサイトが必要となるのが一般的です。

Q3：DRサイトは通常時にもトラフィックを処理すべきですか？

A: 理想的には「はい」です。本番トラフィックのごく一部を流すか、定期的なテストを通じて、バージョン、構成、データがプライマリと常に同期した状態を保つためです。アイドル状態のコールドスタンバイは、実際に必要になった際に切り替えに失敗することが多いため、ウォームスタンバイやアクティブ・アクティブ・スタンバイの方が信頼性が高いです。

Q4: DRは鍵漏洩のリスクを高めますか？

A: 適切に設計されていれば、その心配はありません。DRでは署名ワークフローとノードがレプリケートされ、平文の鍵がレプリケートされることは決してありません。MPCのシェアは同一のマルチシグポリシーのもとでリージョン間で共有されるため、DRによってセキュリティ水準が低下することはありません。また、単一のリージョンでの障害によって出金が完全にブロックされるリスクを排除します。

Q5: テストは実稼働中のユーザーに影響を与えますか？

A: コンポーネント単位のテストは、セカンドレベルでのロールバック機能を備えたカナリア環境または利用の少ない時間帯に実行されます。完全な切り替えについては、まずステージング環境またはシャドウ環境で検証を行った上で、スケジュールされます。本番環境に手を加える前には必ず隔離環境で検証を行い、ユーザーに影響が及ぶ可能性がある場合は事前に告知してください。

Q6：システム障害によるユーザーの損失は誰が負担しますか？

A: 責任の所在は顧客契約で定義されています。プラットフォームの障害による損失は、リスク準備金および保険でカバーされます。プラットフォームシステムのリスクをユーザーに転嫁してはなりません。補償は、インシデントの性質、契約条件、および規制要件に基づいて行われます。

結論

運用上のレジリエンスは、認可を受けた取引所の基本能力です。規制当局が求めているのは、見栄えの良い文書ではなく、検証可能な復旧体制です。 RTO/RPOの階層化、マルチサイトアーキテクチャ、マッチングおよびウォレットのフェイルオーバー、バックアップと照合、インシデント対応プロセス、顧客資産の保護、定期的な訓練、そして保険と準備金を閉ループとして結びつけることで、プラットフォームは顧客を保護し、検査に合格し、実際に障害が発生した際にも運用を継続することができるのです。 技術はあくまで一部に過ぎません。プロセス、人材、訓練、そして継続的な改善も同様に重要です。

🌐 SoonTechで、安全かつスケーラブルなWeb3プラットフォームを構築しましょう。

ホワイトラベル暗号資産取引所、予測市場、MPCウォレット、マッチングエンジン、流動性統合、コンプライアンス向けのソリューションをご覧ください。