現代の金融機関は毎日数百万の取引を処理し、このボリュームをサポートする基礎インフラストラクチャは速く、欠陥耐性があり、マイクロ秒まで正確でなければなりません。過去数年間に、イベント主導のアーキテクチャはこれらのシステムを構築するための主なパターンとして現れ、アパッチ・カフカは多くのミッション批判的な貿易処理パイプラインの背骨となっています。 Why Event-Driven Architecture for Trade Processing なぜ貿易処理のためのイベント駆動アーキテクチャ 伝統的なリクエスト応答システムは、資本市場の遅延および通過要件を満たすために苦労します。オーダー提出から決済確認まで、単一の株式取引は、オーダー管理システム、リスクエンジン、交換ゲートウェイ、クリアハウス、およびコンプライアンスチェックアウトを通過します。各ホップは遅延を導入し、呼び出しのすべての同期チェーンは、一つの遅いコンポーネントが全体の流れをブロックする脆弱な依存グラフを作成します。 イベント主導のアーキテクチャは、生産者と消費者を完全に切り離すことによってこの問題を解決します。注文が提出されたとき、システムはイベントを発行します。リスク検証、取引前のコンプライアンスチェック、位置計算機などのダウンストリームサービスは、それぞれ独立して独自のペースでそのイベントを消費します。 Kafka as the Central Nervous System カフカ:中央神経系 Apache Kafka はこのモデルに自然に適合するため、高流量、耐久性、注文されたイベントストリーミングのために設計されました。典型的な貿易パイプラインでは、貿易ライフサイクルの各段階を別々の Kafka トピックとしてモデル化します: order.submitted, order.validated, order.routed, trade.executed, trade.confirmed、 and settlement.initiated. 各トピックは異なる状態の移行を表し、サービスは機能に関連するトピックにのみサブスクリプトします。 最も重要な設計選択肢の1つは分割戦略です。取引システムの場合、楽器識別子またはアカウント識別子による分割は、特定のセキュリティまたはクライアントのすべてのイベントが同じ消費者インスタンスに到着することを保証します。これは、オフオーダー処理が間違ったネット露出を生成する可能性があるポジション追跡にとって非常に重要です。 Building for Resilience: Idempotency and Exactly-Once Semantics Building for Resilience: Idempotency and Exactly-Once Semantics シンポジウム 分散取引システムにおけるより困難な問題の1つは、取引が正確に一度処理されることを保証することです. ネットワークの分割、消費者のクラッシュ、ブローカーのリーダー選挙はすべてメッセージを再配信することを引き起こす可能性があります. 取引処理サービスが有効でない場合は、複数のメッセージが二重予約、間違ったP&L、または決済指示の失敗につながる可能性があります。 トランザクションプロデューサーAPIを通じて導入されたカフカの正確な一回のセマンティクスは、メッセージ層でこの問題を解決します。Idempotent Producersを可能にし、トランザクションに消費変換生産論理を包装することによって、我々は複数のパーティションやトピックにわたって原子の書き込みを保証することができます。実践では、これは、入力トピック、ビジネス論理、および書き込みを単一のカフカ取引内の出力トピックに包装することを意味します。これらのいずれかの部分が失敗する場合、全体の操作は回転し、部分的な状態は下流に表示されません。 アプリケーション層では、注文開始時にグローバルにユニークな取引識別子を割り当て、パイプライン全体でデダプライクションキーとして使用することにより、Idpotenceを強化します。各サービスは、最近処理された取引IDを備えたローカルキャッシュまたは高速キー価値ストアを維持し、ビジネス論理が実行する前にすべてのダプライクが落とされます。 Schema Management and Contract Stability 計画管理と契約安定性 さまざまなグループがさまざまな消費者を所有する複数のチーム環境で、スケジュールの安定性は重要な運用上の懸念となる。注文が通知なしにイベントスケジュールが変更された場合、ダウンストリームの消費者が破綻する。我々は、この問題を Avro スケジュールと Confluent Schema Registry を使用して解決し、CI/CD パイプラインの一部として後方および前方互換性チェックを強制する。 価格、量、および概念的価値などの経済的に敏感なフィールドでは、浮動点のタイプではなく固定点のデシマル表示を使用します. This eliminates rounding errors that accumulate across thousands of trades and ensures that the same numerical value means the same thing to every consumer in the pipeline, regardless of programming language or runtime environment. Operational Patterns: Dead Letter Queues and Circuit Breakers オペレーティングパターン:Dead Letter Queues and Circuit Breakers 強力な契約とトランザクションセマンティクスでさえ、予期せぬメッセージが到着します。市場データフィードは価格の誤りを作り出す可能性があります。 相手方システムは、必要なフィールドが欠けている貿易確認を送信することができます。 これらの例外に対処する構造化された方法がなければ、一つの悪いメッセージは、消費者が繰り返し失敗し、リターンを繰り返す間、全体のパーティションを何時間も停滞させることができます。 私たちは、設定可能な数回のリリース後に処理に失敗するメッセージが、通常 .dlq サフィックスで名前を付けた専用トピックにルーティングされます。警告システムは、DLQ 遅延をモニタリングし、即座に呼び出しチームに通知します。各 DLQ メッセージは、元のトピック、パーティション、オフセット、例外ステックの追跡、およびタイムスタンプで補充されます。 価格設定サービスまたは参照データ API への呼び出しなどの消費者内部の外部サービス呼び出しの場合、Resilience4j のようなライブラリを使用して回路ブレーカーを実装します. If an external service starts failing, the circuit breaker opens and the consumer drops back to a cached or default value rather than blocking indefinitely. This keeps consumer lag from growing during transient downstream failures. Monitoring and Observability in Production 生産における監視と観察性 Kafkaベースの貿易パイプラインの主な健康メトリクスは、消費者のグループがそれぞれのパーティションの頭部からどのくらい遅れているかを測定する消費者グループ遅れである。我々は、遅れが各サービスの予想処理速度に基づいてカリブレートされた限界を超える場合に、中央監視システムにすべての消費者のグループの遅れメトリクスを曝露し、遅れが5秒を超える場合にリスクモーターを起動するべきである。 End-to-end trade latency は、作成タイムスタンプで各イベントをスタンプし、各段階で経過した時間を測定することによって追跡されます。Distributed tracking with OpenTelemetry は、サービスを介して単一の取引の完全な旅程を視覚化することを可能にし、これはボトルネックの識別に不可欠です。実践では、最大の遅延貢献者は通常、データベースの書き込みと同期外部通話ではなく、カフカ自身です。 Looking Ahead 展望前 Kafka に基づくイベント主導のアーキテクチャは、金融取引処理のための強力な基盤であることが証明されていますが、ここで説明されたパターンは、実践的にうまく機能するために、運用規律、スケジュール管理、観測可能なツールへの投資を必要とします。 金融会社がリアルタイムの決済モデルとますます複雑な規制報告要件に向かうにつれて、イベントストリームを再生、監査、および選択的に再処理する能力がさらに有益になります。
