AWS
AWS構成事例カタログ
金融 / 資本市場マルチAZECS/Fargate

資本市場 OMS（注文管理システム）

受注・約定と発注・出来を分離する低レイテンシー証券取引基盤

可用性 (SLA目標)

99.9% 以上（取引時間帯の継続性を重視）

RTO（目標復旧時間）

数分（Auto Zone Shift / Active-Standby 切替）

RPO（目標復旧時点）

ほぼ 0 目標（注文イベントログとDB更新の整合性に依存）

概算コスト

月 800,000 円〜（ECS、Redis、DB、閉域接続、監視を含む）

構成概要

可用性レベル
マルチAZ
コンピューティング
ECS/Fargate
想定システム規模
大規模（相場急変時の高負荷・低レイテンシー注文処理）
コスト感
¥¥¥高コスト

使用AWSサービス

  • Amazon ECS / AWS Fargate
  • Amazon ElastiCache for Redis
  • Amazon DynamoDB
  • Amazon Aurora
  • AWS Auto Zone Shift
  • AWS Direct Connect
  • Amazon S3
  • AWS Step Functions
  • Amazon CloudWatch
  • AWS CloudTrail
  • AWS KMS
  • AWS IAM

概要

投資家・トレーダーからの注文受付と約定管理を担う OMS を、受注・約定系と発注・出来系に分離したクラウドネイティブ構成です。処理層間は Amazon ElastiCache for Redis Streams などの低レイテンシーメッセージングで連携し、取引所や EMS に近い発注・出来処理を独立スケールさせます。レイテンシーを最優先する場合はクロスAZ通信を抑える Active/Standby、可用性と柔軟性を重視する場合は Active/Active を選択します。

★ 設計のポイント

  • ▸受注・約定と発注・出来を分離し、負荷特性に合わせて独立スケール
  • ▸Redis Streams を低レイテンシーなメッセージング基盤として活用
  • ▸Auto Zone Shift により AZ 障害時のトラフィック退避を設計に組み込む
  • ▸取引所近接が必要な領域は Outposts へ転用できる設計余地を持たせる

システム構成図

AWS CloudLatency-Optimized Multi-AZ LaneExecution VenuesAWS Outposts Option / Exchange ProximityInvestors / Market / Back OfficeAvailability Zone 1Availability Zone 2failoverordersprices洗い替え個人投資家トレーダー機関投資家OMS アルゴリズムFIX / APIバックシステムCloudFrontRoute 53Auto Zone Shift start eventZonal shifthealth signalEventBridgeStep FunctionsLambdafailoverALB受注・約定Weborder entryAuroraElastiCachefor Redis発注 / 出来order routeexecutionALB受注・約定standbydegradedAuroraElastiCachefor Redis発注 / 出来standbyfallbackS3残高・清算・繰越注文AWS Batch夜間処理Step Functions情報ベンダー 相場情報feedstreamingExecution Management System (EMS)smart order routing取引所 Matching Engineexecutionfills

周辺・運用機能（クロスカッティング / 全体に適用）

監視・運用

CloudWatchCloudWatchCloudTrailCloudTrailSystems ManagerSystems Manager

セキュリティ・統制

IAMIAMKMSKMSAWS ConfigAWS ConfigSecurity HubSecurity Hub

取引処理

ECSECSElastiCacheElastiCacheDynamoDBDynamoDBAuroraAurora

連携・保全

Direct ConnectDirect ConnectS3S3Step FunctionsStep Functions
リージョンVPCプライベートパブリック概念図 / アイコン: AWS Architecture Icons

コピーしてすぐ使える IaC

AWS Samples の資本市場 OMS 事例をカタログ化したものです。レイテンシー優先か可用性優先かにより、AZ間通信、Redis、DB同期、Outposts採用判断が変わります。

金融ワークロードアーキテクチャ解説 [資本市場 OMS]

この形式のテンプレートはインライン表示を省略しています。

この構成を選ぶ理由

OMS はレイテンシー、スケーラビリティ、可用性が衝突しやすいため、受注・約定と発注・出来の分離を軸に、AZ戦略を業務要件で選びます。

選定フロー

1

レイテンシー要件を確認する

クロスAZ通信の遅延も許容できないほど低レイテンシーが必要か。

必要 → AZ Active/Standby許容 → Multi-AZ Active/Active
2

取引所近接要件を確認する

取引所/EMSにネットワーク的に近い配置が必要か。

必要 → Outposts / 近接拠点連携不要 → リージョン配置

代替案との比較

候補コスト運用保守負荷スケーラビリティ選定すべきケース
Multi-AZ Active/Active採用
高標準化しやすい高い可用性と拡張性を重視するOMS
AZ Active/Standby
高切替設計が複雑中クロスAZ遅延を極小化したい場中処理
Outposts 近接配置
非常に高キャパシティ制約と拠点運用が必要限定的取引所/EMS近接が最優先の執行処理

採用時のトレードオフ

!

レイテンシー vs 可用性

クロスAZ通信を避けるほどレイテンシーは下がりますが、障害時は全体切替か部分縮退かの判断が難しくなります。
!

低レイテンシー基盤は再処理設計が重要

Redis Streams を使う場合でも、注文イベントの保持、重複排除、順序性、S3アーカイブとの照合を設計する必要があります。

🛡 セキュリティ・コンプライアンスのポイント

•注文、約定、ポジション、顧客情報のアクセス権限をサービス単位で分離する
•取引イベントログを S3 に保全し、監査・再処理・照合に利用できるようにする
•閉域接続、セキュリティグループ、KMS、IAM で取引所/EMS連携を保護する
•CloudWatch メトリクスで注文遅延、キュー滞留、約定不整合、AZ退避状態を監視する

🏛 エンタープライズ設計観点・統制

業務領域

証券取引

プラットフォーム

AWS Native + Outposts Option

重要度

ミッションクリティカル（場中注文・約定管理）

DR方式

Multi-AZ Active/Active または AZ Active/Standby

接続方式

取引所 / EMS 近接接続 + 閉域接続

データ分類

機密（注文・約定・ポジション・顧客情報）

✔ データ活用・統制の設計目標

  • •場中処理の低レイテンシーと障害時継続性の優先順位を明確化する
  • •注文イベント、約定イベント、ポジション更新の順序性と冪等性を保証する
  • •夜間バッチでバックシステムから受け取る確定データとの洗い替え手順を定義する
  • •AZ障害時にレイテンシー優先で全体切替するか、可用性優先で部分縮退するかを事前に決める

⚠ 前提条件・留意事項

  • •超低レイテンシーが必要な市場接続では、リージョン配置だけでなく Outposts やコロケーションとの役割分担を検討する
  • •Redis Streams の保持期間、再送、重複排除、バックプレッシャー制御をアプリケーションで設計する
  • •取引所・清算機関・バックシステムとの接続仕様は各社ごとに異なる

✓ メリット

  • •受注・約定と発注・出来を分けることで負荷特性ごとにスケールできる
  • •Redis Streams により低レイテンシーなイベント連携が可能
  • •Auto Zone Shift を使ったAZ退避設計を組み込みやすい
  • •Outposts や近接拠点への転用余地がある

✗ デメリット

  • •レイテンシー、可用性、整合性のトレードオフ設計が難しい
  • •Redis Streams の再処理、保持、重複排除をアプリ側で考慮する必要がある
  • •取引所・清算機関・バックシステムとの個別接続要件が大きい

→ 主なユースケース

  • •証券会社のクラウドネイティブ OMS
  • •相場急変時にもスケールする注文受付・約定管理
  • •取引所近接とクラウド弾力性を両立したい資本市場システム
金融証券OMS低レイテンシーRedis StreamsECSAuto Zone ShiftOutposts
← 他の構成パターンを見る