トレーディングシステムの作成とその開発用ツールの作成について多くのことを書いています（ 仲介システムAPIからトレーディングターミナル内のロボットデザイナーまで）。 今日は、アルゴリズム取引システムのアーキテクチャの設計に焦点を当てます-これは、NMRQLヘッジファンドの定量アナリストであるStuart Reedが執筆したTuring Financeブログ資料のトピックです。
著者は、彼の記事で、ISO / IEC / IEEE 42010の要件を満たすソフトウェア取引アーキテクチャのアーキテクチャ作成の原則と、ソフトウェアエンジニアリングアーキテクチャシステムの記述に関する標準について説明しています。 これらの標準によれば、アーキテクチャ記述にはさまざまな標準化されたアーキテクチャアプローチが含まれ、設計決定とシステム要件の関係をサポートする必要があります。 この記事の翻訳版をご紹介します。
ソフトウェアの選択
システムアーキテクチャとは何かに関する論争はまだ進行中です。 この記事のトピックの文脈において、著者はこれを内部インフラストラクチャとして理解することを提案します。そのアプリケーションコンポーネントは機能要件を満たし、インストール、デプロイ、起動できます。 非機能要件は、システム自体の品質を通じて評価できます。
すべての機能要件が満たされていても、これはシステムが効率的に組み立てられることを意味しません。 機能以外の要件も考慮する必要があります。 このアイデアを例で説明します。 次の図を想像してみてください。あなたが自分で購入または構築した取引システムが正しい取引決定を下します。 ただし、リスク管理組織も会計レポートも割り当てられないように設計されています。 そのようなシステムは、ニーズを完全に満たすとは言えません。
建築コンセプト
抽象レベルでは、システムの概念と基本的なメカニズムが説明されています。 深く詳細な調査が必要です。 この段階で、トレーディングシステムはイベントドライバアーキテクチャに「パッケージ化」されます。 これは、4つの層と2つの別々のアプローチに分かれています。 それぞれが独自の参照と独自のパターンを使用します。 パターンは、特定のタスクを達成するために一般的に受け入れられている構造です。
イベント管理アーキテクチャは、イベントを検出、生成、および破棄したり、それらに応答したりできるようにするアーキテクチャです。 イベントには、リアルタイムの市場動向、複雑なイベントやトレンド、何らかの方法で注文された取引シグナルなどがあります。
取引システムアーキテクチャの概念を図に示します。
参照アーキテクチャ
構造の比phorを使用する場合、参照アーキテクチャは耐力壁の設計と同じです。 さまざまなデザインの部屋を作成するために使用できます。 主なことは、建築基準の基本的な要件を満たしていることです。 リファレンスアーキテクチャは、特定の要件を持つ特定のアーキテクチャソフトウェアを作成するために使用できる一般的な構造とメカニズムを記述する一種のモデルです。
アルゴリズム取引システムのアーキテクチャは、参照として空間アーキテクチャ（SBA）と基本モデルビューコントローラ（MVC）パターンを使用します。 運用データストレージ（ODS）、抽出、変換、読み込み（ETL）、企業データウェアハウジング（データウェアハウス）などのプラクティスも適しています。
- Model-view-controller-アプリケーションモデル、ユーザーインタラクション、およびインターフェイスを3つの部分に分割するパターン。
- 空間アーキテクチャは、十分に相互接続されていないプロセス要素が、割り当てられた連想メモリを介して相互作用するインフラストラクチャを確立します（下図）。
モデルビューコントローラー
空間アーキテクチャ
構造的アプローチ
構造を構築する段階で、取引システムのコンポーネントとサブコンポーネントが決定されます。 構造により、これらのコンポーネントが物理インフラストラクチャ内でどのように展開されるかが決まります。 UMLダイアグラム（統合モデリング言語の図）は、含まれるコンポーネントとそれらのデプロイ方法を示します。 図は、展開図を示しています：共通および各レイヤー。
建築戦術
Tacticsは、モデルの品質属性を扱います。 システムが品質要件に適応しようとする方法の最も簡単な例は、継続的なクエリによる運用データセットの操作です。 これらのコンポーネントは、ODSを継続的に分析して、複雑なイベントを検出および取得できます。 アーキテクチャで使用される戦術のリストは次のとおりです。
- イベントキュー内の分解パターン。
- キューの専用メモリとイベントの順序。
- ODS用の連続クエリ言語（CQL）。
- 着信情報のデータフィルター。
- 輻輳を回避するための着信接続とエクスポート接続の配布のためのアルゴリズム。
- Active Queue Management（AQM）および輻輳通知システム。
- システムを拡張する機能を備えた消費リソースの計算。
- すべての単一障害に対するアクティブなバックアップ。
- ODSの復元構造のインデックス作成と最適化。
- ODSの定期的なバックアップとクリーンアップスクリプトをスケジュールします。
- すべてのデータベースへのトランザクションストーリー。
- エラー検出のための各行のチェックサム。
- 時代遅れのイベントを無視するタイムスタンプ付きイベント。
- 取引イベントの最大数に対する注文確認ルールの確立。
- 自動取引コンポーネントは、分析にインメモリデータベースを使用します。
- 接続をアクティブにするユーザーインターフェイスの2レベル認証。
- 接続するユーザーインターフェイスの暗号化。
- MVCで調査を管理するための観察パターン。
このリストは、記事の著者が取引システムのアーキテクチャを開発する過程で特定できた少数の設計ソリューションのみを提供します。 リストは完全にはほど遠い。 各詳細レベルで、機能要件と非機能要件を満たすための新しい戦術が追加されます。 この図は、分解パターン、フィルターパターン、および連続クエリコンポーネントを説明する3つの図を示しています。
「行動的な」外観
このアーキテクチャの概要は、システムのコンポーネントとレイヤーがどのように相互作用するかを示しています。 スクリプトを開発してシステムをテストし、すべてが最初から最後までどのように機能するかを理解するときに非常に役立ちます。 この概要は、シーケンス図とアクティビティ図で構成されています。 後者は、取引システムの内部プロセスと、トレーダー自身がそれと対話する方法を示しています。 そのような図の例を以下に示します。
テクニックとフレームワーク
トレーディングシステムのソフトウェア部分のアーキテクチャを開発する最後のステップは、それを実装するために使用できる適切なテクニックとフレームワークを見つけることです。 ここでの一般的なルールは、既存の手法から可能なすべてを絞り出し、それらが機能的および非機能的要件を満たしていることを確認することです。 この場合のフレームワークは参照アーキテクチャです。 たとえば、JBossフレームワークはJEEリファレンスアーキテクチャを実装しています。 以下は、取引システムのアーキテクチャを作成するために使用できるいくつかのテクニックとフレームワークのリストです。
- CUDAはNVidiaの製品です。 彼女は、財務モデリングの計算で高いパフォーマンスをサポートする複数の製品を一度に持っています。 たとえば、CPUではなくGPUでモンテカルロをシミュレートするために、パフォーマンスを50倍向上させることができます。
- Apache riverは、分散システムを作成するためのツールキットです。 彼は、SBAパターンベースのアプリケーションのフレームワークとしてアプリケーションを見つけました。
- Apache Hadoop-このツールは、ビッグデータの問題に対する興味深いソリューションを提供します。 クラスター環境に展開して、CUDAテクノロジーをサポートできます。
- AlgoTraderは、オープンアクセスのアルゴリズム取引プラットフォームです。 自動取引コンポーネントが発生する場所に展開できます。
- FIX Engineは、財務情報交換プロトコル（FIX、FAST、およびFIXatdl）をサポートするスタンドアロンアプリケーションです。
コンポーネント（技術またはフレームワーク）には、互換性を確保するためのAPIが必要であることに注意してください。
おわりに
提案されたアーキテクチャのバージョンは、アルゴリズム取引システムの最も一般的な要件を満たしています。 このようなシステムの場合、主な負荷は、実際にはさまざまな組み合わせで機能する3つの要素によって支えられます。
- 外部環境および交換システムへの依存。
- 非機能要件。
- アーキテクチャ上の制約の進化。
提案されたアーキテクチャは、ケースからケースへの移動に基づいて適合させる必要があります。 特定の組織、規制要件、および地域の制限に準拠する必要があります。 簡単に言えば、この記事では、個々のニーズに合わせてカスタマイズする必要がある有用なリンクのリストのみを紹介しました。